В чём разница между IAM policy, bucket policy и ACL

IAM policy назначается пользователям, ролям и группам и описывает, что эти субъекты могут делать в сервисах AWS, в том числе с S3. Bucket policy вешается прямо на bucket как ресурс и управляет тем, кто и как может обращаться именно к этому bucket’у (включая другие аккаунты и публичный доступ). ACL — старый и более грубый механизм прав на bucket и объекты, сейчас его по возможности отключают и используют только для редких спецкейсов.

Все три механизма — IAM policy, bucket policy и ACL — управляют доступом к S3, но делают это на разных уровнях: IAM описывает права «кто что может», bucket policy — правила доступа «для какого ресурса», а ACL — примитивные права на сами bucket’ы и объекты.

• IAM policy (identity-based policy) назначается на сущности IAM: User, Group, Role, то есть описывает, что конкретный principal может делать в различных сервисах, включая S3.
• Эти политики хранятся в IAM, пишутся в JSON, поддерживают условия (Condition), контекстные ключи и тонкую грануляцию действий, например s3:GetObject, s3:PutObject, s3:ListBucket.
• Типичный сценарий — задать доступ разработчикам, сервисным ролям и приложениям к нескольким bucket’ам и другим ресурсам AWS по принципу наименьших привилегий, чтобы каждый субъект имел только действительно необходимые права.
• Bucket policy (resource-based policy) прикрепляется непосредственно к bucket’у, то есть описывает, кто (через поле Principal) и какие действия может выполнять именно с этим ресурсом.
• Синтаксис bucket policy почти такой же, как у IAM policy, но акцент смещён: это политика ресурса, а не пользователя, и она особенно удобна для кросс-аккаунтного доступа (другие AWS-аккаунты) и публичного чтения (например, раздача статических файлов).
• Через bucket policy легко централизованно описать, какие внешние субъекты могут обращаться к bucket’у, независимо от того, какие IAM-политики настроены у этих субъектов в их собственных аккаунтах.
• ACL (Access Control List) — более старый механизм, который задаёт права непосредственно на уровне bucket’а или отдельного объекта, выдавая разрешения конкретным AWS-аккаунтам или предопределённым группам (например, AllUsers или AuthenticatedUsers).
• ACL сильно ограничены: нет условий, нет тонкой логики, права трудно поддерживать в больших системах; поэтому в современных проектах обычно включают режим S3 Object Ownership = Bucket owner enforced, который фактически отключает объектные ACL, и управляют доступом через IAM и bucket policy.
• ACL сейчас оставляют только для специфических сценариев, вроде совместного владения объектами между аккаунтами наследием старых интеграций, когда по каким-то причинам нельзя полноценно перейти на политики.
• Как они работают вместе: при проверке доступа в S3 объединяются IAM policy субъекта, resource-based политики (bucket policy) и ACL; доступ будет разрешён только если есть явный Allow и нигде не сработал явный Deny, при этом Deny всегда имеет приоритет.
• На практике архитектуру доступа обычно строят так: IAM policy определяет, что в принципе может делать пользователь или сервис, bucket policy открывает этим (и внешним) субъектам доступ к конкретному bucket’у, а ACL стараются не использовать, чтобы конфигурация оставалась предсказуемой и легко управляемой.

Пример простой bucket policy, которая даёт указанному аккаунту право читать объекты из конкретного bucket’а: