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

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

Без защитных ограничений предоставление кому-либо iam:CreateRole и iam:AttachRolePolicy фактически означает предоставление прав администратора. Такой пользователь может создать роль с AdministratorAccess и принять её. Именно этот путь повышения привилегий должно закрывать безопасное делегирование, не препятствуя законному созданию ролей.

Решение заключается в том, чтобы требовать: любая роль, создаваемая делегированным пользователем, должна иметь подключённую определённую границу разрешений. Даже если он подключит к новой роли AdministratorAccess, граница ограничит её фактические разрешения. Созданная роль никогда не сможет превысить предел, установленный границей, что устраняет риск повышения привилегий.

Безопасная политика делегирования использует две проверки условий: одна гарантирует, что новая роль имеет требуемую границу (через iam:PermissionsBoundary), а другая запрещает пользователю изменять или удалять саму границу. Нужны обе проверки, иначе изобретательный разработчик сможет просто удалить границу позднее.

Это условие заставляет каждый вызов CreateRole подключать указанную границу. Без неё действие создания будет отклонено.

Также необходимо запретить делегированному пользователю изменять политику границы или отсоединять её от ролей. Добавьте явные операторы Deny для таких действий, как iam:DeleteRolePermissionsBoundary и iam:CreatePolicyVersion, указав ARN границы. Иначе защитный механизм можно незаметно удалить, что сведёт на нет всю схему.

Политики делегирования часто ограничивают путь или имена ролей, которые пользователь может создавать, например разрешают создавать их только в /developers/. Это помещает роли в известное пространство имён, упрощает их проверку и не позволяет вмешиваться в привилегированные роли в других частях аккаунта.

Даже при наличии границы обратите внимание на политику доверия новой роли. Разработчик может создать роль, которой доверяет внешний аккаунт. Ограничьте перечень принципалов, которых он может указывать как доверенных, или сочетайте делегирование с SCP и Access Analyzer, чтобы обнаруживать и блокировать неожиданное внешнее доверие.

При правильной реализации делегирование предоставляет командам полноценное самообслуживание: они свободно создают и управляют ролями в пределах границы, а команда безопасности может быть уверена, что ни одна роль не превысит установленный предел. Именно такой баланс скорости и безопасности требуется спроектировать на экзамене SCS-C02.

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

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

Безопасное делегирование создания ролей IAM означает обязательное требование границы разрешений для каждой созданной роли через условие iam:PermissionsBoundary, запрет изменений этой границы, ограничение путей и имён ролей и ограничение политик доверия новых ролей. Сочетайте этот механизм с SCP для установки верхних пределов на уровне аккаунта, чтобы закрыть пути повышения привилегий и сохранить самообслуживание.