Безопасная делегация создания ролей IAM в AWS

Быстрые ссылки

• Полный доступ к IAM приводит к эскалации привилегий

• Решение: Permission Boundaries (границы разрешений)

• Альтернатива: отдельные учётные записи для разработки и production

Проблема: полный доступ к IAM позволяет эскалацию привилегий

Если вы дадите сотруднику или группе blanket-доступ к консоли IAM (например, политику IAMFullAccess), это может показаться удобным — пользователь сможет создавать роли и сервисные аккаунты самостоятельно. Но у такой настройки есть критическая проблема: сотрудник сможет изменить собственные права, назначить себе AdministratorAccess или создать новые аккаунты с повышенными правами.

Простой сценарий:

• вы создаёте нового пользователя и назначаете ему IAMFullAccess;
• пользователь входит в консоль и редактирует свои политики, добавляя AdministratorAccess;
• теперь пользователь обладает полными правами в аккаунте.

Это серьёзный риск безопасности. Решения существуют — основное и самый надёжный подход — permission boundaries. Альтернативно (или дополнительно) стоит рассмотреть логическое разделение сред через AWS Organizations.

Решение: Permission Boundaries (границы разрешений)

Кратко: permission boundary — это политика, которая «обрезает» максимально возможные права создаваемых ролей. Эффективные права получаются как пересечение (intersection) прав, заданных в политике, и прав, определённых в границе разрешений.

Ключевые моменты:

• Граница разрешений ограничивает возможности ролей, которые создаёт сотрудник. Роль не сможет выйти за пределы этой границы ни при каких условиях.
• Вы можете дать сотруднику право создавать роли и политики, но запретить ему менять или удалять границы разрешений.
• Практически: разрешайте создавать роли только с предустановлённой границей разрешений (через условие iam:PermissionsBoundary).

Пример: создаём границу, дающую полный доступ только к одному бакету S3. Любая роль, создаваемая пользователем, не сможет получить доступ к другому S3.

Вы можете вручную назначить permission boundary для пользователя в разделе Policy Usage. Однако технически граница применяется к ролям, создаваемым сотрудником, а не к его собственному пользователю. Это позволяет давать сотруднику права read/write для S3 в его рабочем окружении, но при этом роли, созданные им для сервисов (например, EC2), будут иметь только read-права, если это задано в границе.

Ниже — пример пользовательской IAM-политики, дающей право создавать роли и политики, но с условием, что создаваемые роли будут иметь определённую границу разрешений. Вставьте в условие ARN вашей boundary-политики.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "VisualEditor0",
      "Effect": "Allow",
      "Action": [
        "iam:DetachRolePolicy",
        "iam:CreateRole",
        "iam:AttachRolePolicy"
      ],
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "iam:PermissionsBoundary": "arn:aws:iam::515436951152:policy/S3AccessBoundary"
        }
      }
    },
    {
      "Sid": "VisualEditor1",
      "Effect": "Allow",
      "Action": [
        "iam:CreateInstanceProfile",
        "iam:GetRole",
        "iam:GetPolicyVersion",
        "iam:GetInstanceProfile",
        "iam:ListRoleTags",
        "iam:GetPolicy",
        "iam:AddRoleToInstanceProfile",
        "iam:CreatePolicy",
        "iam:PassRole",
        "iam:ListPolicyVersions",
        "iam:ListAttachedRolePolicies",
        "iam:CreatePolicyVersion",
        "iam:ListRolePolicies",
        "iam:GetRolePolicy",
        "iam:DeletePolicyVersion"
      ],
      "Resource": [
        "arn:aws:iam::515436951152:role/service-*",
        "arn:aws:iam::515436951152:policy/service-*",
        "arn:aws:iam::515436951152:instance-profile/service-*"
      ]
    },
    {
      "Sid": "VisualEditor2",
      "Effect": "Allow",
      "Action": [
        "iam:ListPolicies",
        "iam:GetServiceLastAccessedDetailsWithEntities",
        "iam:ListRoles",
        "iam:GetServiceLastAccessedDetails"
      ],
      "Resource": "*"
    }
  ]
}

Что делает эта политика и почему она безопасна:

• даёт права CreateRole, AttachRolePolicy, DetachRolePolicy — то есть сотрудник может создавать ролит и прикреплять политики;
• условие iam:PermissionsBoundary гарантирует, что все создаваемые роли содержат указанную границу и не смогут выйти за её пределы;
• политике разрешено создавать собственные политики, но даже они не превысят границу;
• набор прав также включает необходимые read-only операции, чтобы работать с консолью IAM и управлять ролями;
• дополнительно разрешается работать только с ресурсами, у которых префикс service- — это защищает от изменения существующих политик или ролей, созданных администратором.

Важно: используйте разные префиксы для ролей/политик, если у вас несколько границ разрешений.

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

Если сотрудник попытается создать роль без границы или с границей, выходящей за пределы разрешённой, система выдаст ошибку — нельзя создать роль вне разрешённой boundary.

Когда роль создана, даже если пользователь дал ей AmazonS3FullAccess, из-за границы она будет иметь доступ только к тому бакету, который определён в S3AccessBoundary.

Пользователь может редактировать политики внутри ролей, но не может изменить границы разрешений. Попытка редактировать permission boundary выдаст ошибку.

Когда всё настроено — сотрудники могут самостоятельно создавать сервисные роли, не обращаясь к администраторам, и при этом не угрожают безопасности общесистемных ресурсов.

Альтернатива: отдельные окружения разработки и production

Если у вас смешаны development и production в одном аккаунте, управление правами усложняется. Один рабочий подход — разделять окружения логически, с помощью AWS Organizations и отдельной дочерней учётной записи под каждую среду (prod, dev, staging, test).

Выгоды:

• IAM-пользователи в учётной записи разработки не имеют доступа к ресурсам production;
• проще давать разработчикам более широкие права в dev (например, S3FullAccess), зная, что это не повлияет на prod;
• централизованная оплата (consolidated billing) упрощает учёт затрат.

Замечания:

• это не заменяет permission boundaries как метод ограничения прав; это скорее стратегическая мера по снижению уровня риска;
• всё ещё рекомендуется применять границы разрешений и IAM-хорошие практики в prod-окружениях.

Пошаговое руководство (микро-SOP) для безопасной делегации прав

1. Определите набор ресурсов, к которым можно допускать роль (например, конкретный S3-бакет).
2. Создайте политику boundary (например, S3AccessBoundary) с минимально необходимыми правами.
3. Создайте политику DelegatePermissions (пример JSON выше), в которой условие iam:PermissionsBoundary ссылается на ARN вашей boundary.
4. Ограничьте Resource в DelegatePermissions префиксами (например, service-) для ролей и политик, которые могут создавать сотрудники.
5. Назначьте DelegatePermissions соответствующим IAM-пользователям или группам.
6. Проверьте: от имени сотрудника создайте роль без boundary — должно выдать ошибку.
7. Проверьте: создайте роль с boundary — роль должна работать, но её права ограничены.
8. Автоматизируйте аудит: настраивайте CloudTrail/Config/Access Analyzer для контроля попыток обхода.

Контрольный список для администратора

• Создана и протестирована boundary-политика
• Создана политика делегирования (DelegatePermissions) с условием iam:PermissionsBoundary
• В DelegatePermissions ограничены ресурсы префиксом service-
• Пользователям назначены только нужные группы/роли
• Включён CloudTrail для аудита действий IAM
• Настроен IAM Access Analyzer и оповещения о изменениях
• Выполнено тестирование сценариев обхода прав

Матрица рисков и способы смягчения

• Риск: сотрудник получает полные права -> Смягчение: не давать IAMFullAccess, использовать permission boundaries, MFA для консоли управления
• Риск: созданная роль использует другие сервисы для эскалации -> Смягчение: ограничить права ролей, включить мониторинг CloudTrail
• Риск: ошибочное назначение boundary администратором -> Смягчение: тестовая проверка, peer-review изменений IAM

Когда permission boundaries не решают проблему (контрпримеры)

• Сценарий: у сотрудника есть возможность изменять саму boundary-политику (ARN), тогда он сможет изменить границу. Вывод: запрещайте изменение boundary-политик для неподходящих ролей.
• Сценарий: внешняя служба с широкими правами использует роль, созданную сотрудником — необходимо контролировать доверенные политики и use-case для pass-role.

Практические рекомендации и рекомендации по безопасности

• Применяйте принцип наименьших привилегий: политика должна давать только те действия, которые нужны для работы сервисной роли.
• Разделяйте окружения: dev и prod в разных учётных записях упрощают ограничение ущерба.
• Используйте префиксы (например, service-) при создании ролей и политик для разграничения областей ответственности.
• Включите автоматические проверки конфигураций (AWS Config), чтобы обнаруживать роли без границ.
• Ограничьте iam:PassRole — разрешайте передавать только те роли, которые явно нужны сервисам.

Чек-лист для разработчиков (рole-based)

• Разработчик:

  • умеет создавать локальные роли для тестирования в dev-аккаунте;
  • не может редактировать или удалять permission boundaries;
  • знает, как указать boundary при создании роли.

• Проектный менеджер / тимлид:

  • имеет доступ к созданию и пересмотру boundary-политик;
  • проводит ревью политик, которые создаются командой.

• Оператор/DevOps:

  • умеет настраивать DelegatePermissions и тестировать аудит.

Flowchart принятия решения (Mermaid)

flowchart TD
  A[Нужно делегировать создание ролей?] -->|Да| B{Роль влияет на prod-ресурсы?}
  B -->|Нет| C[Делегировать в dev-учётной записи]
  B -->|Да| D{Можно ли задать boundary?}
  D -->|Да| E[Создать boundary и DelegatePermissions]
  D -->|Нет| F[Требуется контроль администратором]
  A -->|Нет| G[Сохраняем текущие права]

Полезные команды и сниппеты

Пример AWS CLI: прикрепление policy (DelegatePermissions) к пользователю

aws iam attach-user-policy --user-name alice --policy-arn arn:aws:iam::515436951152:policy/DelegatePermissions

Проверка списка ролей и их границ

aws iam list-roles --query 'Roles[].[RoleName, PermissionsBoundary]' --output table

Критерии приёмки

• Пользователь с DelegatePermissions может создать роль только если в ней указана требуемая permission boundary;
• Попытки создать роль без границы приводят к отказу;
• Роли, созданные сотрудником, не имеют доступа к ресурсам вне границы;
• Аудит (CloudTrail) фиксирует все операции с IAM от пользователя.

Краткое резюме

Permission boundaries дают вам гибкий и безопасный способ делегировать создание ролей в AWS, позволив сотрудникам работать автономно, но не выходить за пределы заранее определённых ограничений. В сочетании с разделением окружений (AWS Organizations) и стандартными практиками безопасности (наименьшие привилегии, аудит, контроль iam:PassRole) вы получите управляемую и безопасную модель делегирования прав.

Важно: всегда тестируйте изменения в тестовой среде и проводите peer-review критичных IAM изменений.

Notes: если вы управляете большим количеством команд или границ, стандартные операционные процедуры и автоматические проверки (Infrastructure-as-Code, CI/CD, IAM linting) значительно упрощают поддержку и уменьшают человеческие ошибки.