IAM misconfigurations

Почему конфиги IAM — отдельная категория

Ранее в этом юните ты разобрал модель облачной идентичности, написание least-privilege-политик и то, как работают assume-роли и федерация. Этот урок — о том, где всё это ломается в продакшене: не через эксплуатируемый код, а через права, по отдельности защитимые, а в сумме катастрофические.

Это различие — суть всего. SQL-инъекция — это баг: код делает то, чего автор не задумывал. Конфиг IAM — это выданное право: система делает ровно то, что говорит политика, а политика говорит слишком много. Сканеры, ищущие искажённый ввод, не находят ничего, потому что искажать нечего. CloudTrail показывает чистый 200 на каждом вызове, потому что каждый вызов был авторизован. Ущерб нанесён целиком внутри границ права, которое ты выписал. Поэтому ревью IAM читается как достижимость, а не синтаксис: вопрос никогда не «валидна ли эта политика?» — он «каково транзитивное замыкание всего, до чего этот принципал может дотянуться?».

Два сценария доминируют в реальных инцидентах, и зрелый инженер учится видеть оба как пути, а не утверждения: эскалация привилегий (право, позволяющее принципалу выдать себе больше) и confused deputy (доверенный сервис, действующий по вводу атакующего своей собственной властью, а не властью атакующего).

Эскалация привилегий: когда право позволяет выдать себе больше

Эскалация привилегий — это конфиг, при котором у принципала есть право, которое, используемое по назначению, позволяет ему получить права, которые ему никогда не давали. Самое важное для распознавания — iam:PassRole.

PassRole существует по легитимной причине: когда ты создаёшь Lambda-функцию, EC2-инстанс или ECS-задачу, что-то должно прикрепить исполнительную роль, чтобы воркод мог вызывать API AWS. PassRole — это право передать роль сервису. Ловушка — в области ресурса. Политика с iam:PassRole на ресурсе-wildcard означает не «передай свою узкую роль» — она означает передай любую роль в аккаунте, включая админскую. Соедини это с любым сервисом, исполняющим код (lambda:CreateFunction + lambda:InvokeFunction или ec2:RunInstances), — и у тебя готова целая лестница:

PassRole — заголовок, но семейство большое, и зрелый навык — распознавать паттерн, а не зубрить список. Любое из этих — одношаговая эскалация, если выдано на wildcard:

Защита — не «запретить эти действия»: они несущие. Это сужение по ресурсу плюс permissions boundary. Сузь PassRole до точного ARN роли, нужной воркоду; никогда не wildcard. Затем оберни любую идентичность, способную создавать или прикреплять права, в permissions boundary — потолок, который принципал не может превысить, какую бы политику он себе ни выдал. Boundary — это то, что превращает AttachUserPolicy из «прикрепить админа» в «прикрепить что угодно, ограниченное boundary».

Confused deputy: когда доверенный сервис действует по вводу атакующего

Второй сценарий тоньше, потому что атакующий никогда не касается твоего аккаунта напрямую. Confused deputy — это привилегированный компонент, обманом заставленный злоупотребить своей собственной властью в пользу менее привилегированного вызывающего. Классический облачный случай: ты даёшь стороннему SaaS (инструменту мониторинга, бэкап-вендору) право assume-роли в твоём аккаунте, чтобы он читал твои данные. Вендор принимает одну роль, чтобы обслуживать всех своих клиентов.

Вот ловушка. Вызову assume-роли вендора нужны лишь id целевого аккаунта и имя роли — и то и другое может угадать вредоносный другой клиент того же вендора. Клиент B просит вендора «мониторить аккаунт 1234 / роль MyAuditRole». Вендор, как и спроектировано, принимает эту роль. Теперь вендор — deputy — читает твой аккаунт по поручению клиента B. Вендор не был скомпрометирован; он сделал ровно свою работу. Он был запутан в том, чей запрос он обслуживает.

Фикс — общий секрет, вшитый в доверительную связь: ExternalId. Настраивая вендора, ты договариваешься о пер-тенантном секрете и кладёшь "sts:ExternalId": "твоё-уникальное-значение" условием в trust-политику роли. Теперь вендор должен предъявить твой ExternalId, чтобы принять твою роль, — а клиент B, который может угадать id аккаунта и имя роли, не может угадать секрет, который ему не давали. Тот же принцип обобщается: confused deputy побеждается привязкой решения об авторизации к идентичности исходного запрашивающего, а не только к идентичности deputy. В твоих собственных сервисах эквивалент — пробрасывать и проверять идентичность конечного пользователя до самого ресурса, никогда не позволяя привилегированному бэкенду действовать по сырой, подверженной влиянию атакующего цели.

Как зрелый инженер ревьюит изменение IAM: думай в blast radius

Объединяющая мысленная модель — blast radius (радиус поражения): если долгоживущая учётка ровно этого принципала утечёт атакующему завтра, каково транзитивное замыкание всего, до чего он дотянется? Не «для чего эта роль» — а чем она может стать. Деплой-ключ, способный передать любую роль, имеет blast radius во весь аккаунт, хотя его работа — пушить один сервис.

Этот сдвиг меняет то, как ты читаешь политики. Ты перестаёшь искать синтаксические ошибки и начинаешь трассировать достижимость: позволяет ли какое-то право этому принципалу получить другую идентичность (эскалация)? Позволяет ли какая-то trust-политика внешней стороне одолжить власть этого аккаунта, не доказав, что она — предполагаемая сторона (confused deputy)? Контроли чисто ложатся на эти два вопроса — least-privilege-сужение по ресурсу и permissions boundary ограничивают, чем принципал может стать; ExternalId и проброс идентичности на каждый запрос ограничивают, по чьему поручению deputy может действовать. Default-deny — пол под обоими: каждое право начинается с «нет» и расширяется лишь до названного ресурса по названной причине.