Privilege Escalation via IAM: как происходит эскалация привилегий через IAM и как её предотвратить

Эскалация привилегий через IAM — одна из наиболее недооценённых, но чрезвычайно опасных атак на облачную инфраструктуру. В отличие от классических уязвимостей, связанных с сервером или приложением, здесь проблема возникает в неправильных правах, ролях и политиках, настроенных внутри облачной платформы. В AWS это IAM, в Azure — Azure AD + RBAC, в Google Cloud — IAM Permissions. Проблема одна и та же: злоумышленник получает возможность повысить свои привилегии и фактически захватывает облако компании.

В этой статье мы подробно рассмотрим, что такое эскалация привилегий через IAM, какие ошибки конфигурации позволяют злоумышленникам получить полный доступ к облаку, какие реальные векторы атак встречаются в AWS/Azure/GCP, и как защитить инфраструктуру от таких угроз.

Что такое Privilege Escalation via IAM

Эскалация привилегий через IAM — это процесс, при котором атакующий получает доступ к аккаунту или роли с ограниченными правами, а затем использует ошибки конфигурации IAM для увеличения своих возможностей вплоть до административного уровня. В результате злоумышленник может:

• Создавать или изменять роли и политики;
• Выдавать себе более высокие права;
• Получать доступ к критическим ресурсам;
• Отключать системы мониторинга и журналирования;
• Удалять данные и выполнять вредоносные действия;
• Организовать постоянный скрытый доступ к облаку.

Часто такой тип атак остаётся незамеченным, поскольку злоумышленник использует «легальные» API-вызовы, которые выглядят как нормальная административная активность.

Почему IAM — это критическая зона риска

Identity and Access Management — это сердце любой облачной безопасности. Именно через IAM происходит аутентификация пользователей, распределение ролей, назначение прав на ресурсы и управление рабочими процессами автоматизации.

Ошибки в IAM приводят к следующим рискам:

• Минимальная уязвимость превращается в полный захват облака.
• Ошибку сложно заметить при обычном мониторинге.
• Атаки проходят без эксплойтов и вредоносного кода.
• Злоумышленник может легализовать своё присутствие, создавая «скрытые» роли.

И самое неприятное — это абсолютно не зависит от используемого облака. AWS, Azure, Google Cloud — везде строгая настройка IAM имеет решающее значение.

Как злоумышленники получают начальный доступ

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

• Утечку ключей доступа (AWS Access Keys, Azure SP Keys);
• Компрометацию учетной записи сотрудника;
• Слабые политики MFA;
• Приложение или сервис, использующий роль IAM;
• Ошибки в CI/CD, утекшие переменные окружения;
• Компрометацию контейнера или виртуальной машины с подключённой ролью.

После получения доступа злоумышленник изучает права и ищет способы увеличить их.

Ключевые ошибки конфигурации, приводящие к эскалации привилегий

Ниже рассмотрены типичные IAM-проблемы, которые позволяют атакующему повысить свои привилегии.

1. Роли, которые могут назначать или изменять свои собственные права

Фатальная ошибка — разрешать роли изменение IAM-политик, содержащих её саму. Это позволяет злоумышленнику выдать себе полный доступ:

• iam:PutRolePolicy
• iam:AttachRolePolicy
• iam:UpdateAssumeRolePolicy

Любой из этих методов часто ведёт к эскалации до Admin.

2. Слишком широкие политики с “*”

Например:

<code>
{
  "Effect": "Allow",
  "Action": "*",
  "Resource": "*"
}
</code>

Эта политика равна «полный доступ ко всему». Встречается чаще, чем кажется.

3. Разрешение assume-role на админские роли

Если атакующий может выполнить:

<code>
sts:AssumeRole
</code>

он может «перескочить» в другую роль, иногда обладающую намного большими правами. Да, это самая популярная реальная атака.

4. Сервисные аккаунты с привилегиями выше, чем им требуется

Например, серверless‑функция или контейнер имеет «админские» разрешения, хотя должна выполнять только простые операции.

Если злоумышленник получает доступ к окружению — он получает и роль.

5. Политики, позволяющие создание новых ключей

Например:

• iam:CreateAccessKey
• iam:UpdateLoginProfile

Позволяют злоумышленнику создать себе постоянный доступ к учётке.

8 реальных сценариев эскалации привилегий через IAM

Рассмотрим наиболее распространённые и практически применимые сценарии атак.

1. Получение админских прав через изменение IAM‑политики

Если роль может выполнять PutRolePolicy, злоумышленник просто добавляет полномочия Admin.

2. Захват через assume‑role

Если роль A имеет право assumir роль B, а роль B — админская, атакующий получает полный доступ буквально одним API-вызовом.

3. Создание новой роли с администраторами

Некоторые организации запрещают изменять текущие роли, но разрешают создавать новые. Атакующий создаёт новую роль с правами AdministratorAccess и получает доступ.

4. Добавление себя в группу администраторов

Если разрешена операция:

<code>
iam:AddUserToGroup
</code>

— злоумышленник просто добавляет свой аккаунт в группу «Admin».

5. Добавление SSH-ключей в VM, которая использует роль IAM

Атакующий получает root‑доступ к машине → машина имеет роль с высокими привилегиями → происходит эскалация в облаке.

6. Злоупотребление доверительными политиками

В AWS злоумышленник может изменить assume‑role‑policy так, что любая внешняя учётка сможет брать роль.

7. Создание бэкдоров с помощью новых ключей доступа

Злоумышленник добавляет себе новый ключ и создаёт скрытый доступ, который не отслеживается пользователем.

8. Использование сервисных аккаунтов CI/CD

CI-пайплайны часто имеют слишком высокие права. Их компрометация = полный захват облака.

Инструменты, которые используют злоумышленники

Существуют известные наборы инструментов, помогающие искать пути эскалации:

• Pacu — фреймворк для AWS атак;
• ScoutSuite — аудит конфигураций облаков;
• CloudSploit — сканер безопасности;
• Cartography (от Lyft) — анализ графа ресурсов и IAM‑отношений;
• IAM-Viz — визуализация отношений IAM;
• GCP IAM Recommender — выявляет опасные права;
• Azucar — анализ Azure.

Большинство атак начинаются с анализа доступных прав и поиска широких или ошибочных политик.

Как защититься от Privilege Escalation via IAM

Теперь перейдём к практическим шагам по защите.

1. Принцип минимальных привилегий (Least Privilege)

Каждый пользователь, сервис или функция должны иметь только те права, которые необходимы для выполнения задач — не больше.

2. Запрет wildcard‑доступа “*”

Политики с Action: «*» или Resource: «*» должны быть полностью исключены, если это не корневой аккаунт (и даже там крайне нежелательно).

3. Запрет критичных операций в ролях

Опасные операции включают:

• iam:PutRolePolicy
• iam:AttachRolePolicy
• iam:UpdateAssumeRolePolicy
• iam:CreateAccessKey
• iam:AddUserToGroup

Если их можно выполнить — эскалация почти гарантирована.

4. Использование анализаторов IAM

Облака предоставляют встроенные инструменты, например:

• AWS IAM Access Analyzer
• Azure Privileged Identity Management
• GCP IAM Recommender

Они автоматически находят опасные конфигурации.

5. Включение MFA для всех пользователей

Особенно для административных аккаунтов.

6. Мониторинг IAM событий

Подозрительные действия:

• Создание новых ролей;
• Изменение trust policies;
• Создание новых ключей доступа;
• Добавление себя в группы;
• Логины в нерабочее время.

Любое из этих действий может указывать на эскалацию.

7. Разделение обязанностей

Администраторы, разработчики и CI/CD должны иметь разные наборы прав. Никто не должен иметь полный доступ ко всему.

8. Регулярный аудит IAM политик

Настройка IAM — это не разовая задача. Права необходимо регулярно пересматривать, так как сервисы меняются, появляются новые ресурсы, меняются процессы.

Заключение

Эскалация привилегий через IAM — это одна из самых опасных атак, поскольку она происходит без эксплойтов, без вредоносного кода и часто без следов. Ошибки IAM встречаются повсеместно, и злоумышленники активно ими пользуются. Понимание механизмов этой атаки и корректная настройка IAM — критически важные элементы облачной безопасности.

Компании должны применять принцип минимальных привилегий, регулярно проводить аудит ролей и политик, включать мониторинг IAM и защищать административный доступ с помощью MFA.

Правильно настроенный IAM — это надёжный барьер, который делает облачную инфраструктуру значительно более устойчивой к атакам и снижает риск полного компрометации.