Модель облачной идентичности

Принципал: кто спрашивает

Каждое решение об авторизации начинается с принципала — сущности, делающей запрос. В облачной IAM-модели принципал почти никогда не человек, набирающий пароль. Это идентичность, которая уже прошла аутентификацию и теперь несёт набор короткоживущих учёток: IAM-роль, принятая EC2-инстансом; Kubernetes service account, обменянный на облачный токен через workload identity; CI-задача, федерировавшаяся по OIDC-токену; execution-роль Lambda. Логин уже состоялся; к моменту вычисления политики платформа знает, какой принципал спрашивает. IAM — это слой авторизации, а не аутентификации: он отвечает на вопрос «можно ли этому уже-известному принципалу выполнить это действие над этим ресурсом», и именно с этого различия начинается бо́льшая часть путаницы.

Это важно по зрелой причине: принципалы обычно машины, и они долгоживущие по замыслу, но короткоживущие по учётке. У роли нет пароля; принципал принимает её и получает учётки, истекающие через час. Поэтому интересная поверхность атаки — не «угадать пароль», а «кому разрешено стать этим принципалом», и это управляется отдельной политикой, к которой мы перейдём.

Два вопроса политики: identity против resource

Облачная платформа задаёт один и тот же запрос с двух сторон, и обе должны согласиться.

• Identity-политика крепится к принципалу (роли, пользователю, группе). Она говорит, что может этот принципал: «роль report-writer может s3:PutObject в reports-bucket». Читайте как предложение, начинающееся с актора.
• Resource-политика крепится к самому ресурсу (S3-бакету, SQS-очереди, KMS-ключу). Она говорит, кто может действовать над этим ресурсом: «этот бакет разрешает arn:aws:iam::111:role/report-writer читать». Читайте как предложение, начинающееся с объекта.

Один и тот же доступ можно выразить с любой из сторон, и именно комбинация делает межаккаунтный доступ работающим без правки ролей в чужом аккаунте. Если у бакета аккаунта A есть resource-политика, называющая роль аккаунта B, а у роли B есть identity-политика, разрешающая действие, запрос проходит — в одиночку ни одна сторона не смогла бы выдать его через границу аккаунтов. Это же — самый частый источник «почему оно это читает?»: грант живёт на ресурсе, а не на идентичности, поэтому чтение только политики роли никогда этого не объяснит.

Trust-политика: кто может стать этим принципалом

У роли есть дверь, и trust-политика — это замок на ней. Это resource-политика, живущая на роли и отвечающая на вопрос, которого identity-политика вообще не касается: кому в принципе разрешено принять эту роль? Identity-политика говорит, что роль может, когда вы уже внутри; trust-политика говорит, можете ли вы войти.

Это разделение — весь движок облачной федерации. Задача GitHub Actions, предъявляющая OIDC-токен, может стать deploy-ролью только потому, что trust-политика этой роли говорит: «принципалы, федерированные от этого OIDC-провайдера, с этим claim sub, могут меня принять». Человек из вашего SSO-каталога становится admin-ролью, потому что trust-политика доверяет провайдеру идентичности. Ошибитесь в trust-политике — доверьте * или OIDC sub с небрежным wildcard вроде repo:org/* — и вы отдали роль всему интернету, как бы туго ни была закручена её identity-политика. Trust-политика — это та часть, о существовании которой джуны забывают, а сеньоры ревьюят первой, потому что это и есть настоящая граница аутентификации для машинного принципала.

Как решение вычисляется на самом деле

Вот правило, которое растворяет загадки. Облачная авторизация — deny by default, и вычисление — это не «найти подходящий allow», а фиксированный приоритет:

1. Старт — неявный deny. Ни одно утверждение не подходит → запрос отклонён. Ничего не разрешено, пока что-то не выдаст грант.
2. Явный Deny всегда побеждает. Если любая применимая политика — identity, resource, boundary или организационный ограничитель — содержит подходящий Deny, запрос отклонён, точка. Никакой allow его не перебьёт.
3. Явный Allow снимает неявный deny — но только в пределах потолка. Permission boundary или организационный ограничитель (SCP) могут урезать достижимое, даже когда identity-политика говорит Allow; эффективное право — это пересечение выданного и того, что разрешает потолок.

Так что реальное вычисление таково: deny, пока (какая-то политика разрешает) И (ни одна не запрещает) И (грант внутри каждого применимого потолка). Этот порядок объясняет, почему чрезмерно широкий Allow * гораздо менее опасен, чем боятся, когда его ограничивает boundary, — и почему один залётный Deny способен сломать деплой, у которого «очевидно есть права».

Чтение реального гранта: межаккаунтный доступ в одном слиянии

Прокрутим стартовую загадку через модель. Ваша роль в аккаунте B может s3:ListBucket на бакете в аккаунте A. Проследим:

• Trust-политика роли B разрешает вашему EC2-инстансу / CI-задаче принять её. Аутентификация машинного принципала: готово.
• Identity-политика роли B разрешает s3:ListBucket на arn:...:bucket-in-A. Сторона гранта со стороны B: есть.
• Resource-политика бакета A разрешает arn:aws:iam::B:role/yours делать s3:ListBucket. Сторона гранта со стороны A: есть.
• Нигде нет Deny, и действие лежит внутри permission boundary роли B и организационных ограничителей A.

Обе стороны согласились, ни один deny не вмешался, потолок разрешил → разрешено. Причина, по которой чтение одной роли не сработало, в том, что половина гранта жила на ресурсе в другом аккаунте. Зрелая привычка — для любого неожиданного доступа спросить: «покажите мне каждую политику в слиянии — обе идентичности, оба ресурса, boundary, организационный ограничитель, — а не только ту, которую я ожидал».