Спроектируйте подход к управлению IAM для организации с несколькими облачными аккаунтами/проектами/подписками (landing zone), командами разработки с разным уровнем доверия и требованиями аудита. Однозначного решения нет — обсудите варианты и компромиссы.

Короткий ответ

Типичный подход — разделение ресурсов по отдельным аккаунтам/проектам на команду или окружение, централизованное управление identity через SSO/федерацию, использование организационных политик (SCP/organization policies) для общих ограничений и делегирование IAM внутри каждого аккаунта владеющей им команде; конкретная степень централизации против автономии команд — предмет компромисса, а не готовый рецепт.

Как это работает подробнее

landing zone задаёт baseline — обязательные guardrails на уровне организации (запрет отключения логирования, запрет публичных bucket, обязательное шифрование), которые применяются ко всем аккаунтам независимо от локальных IAM-настроек; внутри каждого аккаунта команда получает достаточную автономию для управления своими ролями в рамках этих guardrails.

Пример кода

example.txtКопировать

Organization root
 +-- OU "Production"   (SCP: deny отключения логирования, deny публичных bucket, require MFA)
 |     +-- account: payments-prod
 |     +-- account: web-prod
 +-- OU "Sandbox"       (SCP: разрешены эксперименты, ограничен бюджет через budget alert)
       +-- account: team-x-sandbox

Что использовать на практике

• Рекомендация. решение о степени изоляции зависит от размера организации, требований комплаенса и зрелости команд в самостоятельном управлении доступом; централизованный логин и единый источник правды для identity обязательны почти всегда, а степень централизации самих IAM-политик — варьируется.
• Проверка. попытка отключить логирование или создать публичный bucket в любом аккаунте под OU «Production» должна быть заблокирована на уровне организации независимо от локальных IAM-прав пользователя в этом аккаунте.
• Компромисс. сильная централизация IAM снижает риск ошибок конфигурации и упрощает аудит, но создаёт узкое место и замедляет работу команд; высокая автономия ускоряет команды, но увеличивает риск несогласованных или слишком широких прав в отдельных аккаунтах; правильный баланс зависит от зрелости организации и требований регулятора и должен явно обсуждаться с заинтересованными сторонами, а не выбираться по умолчанию.

Подводные камни

• Риск. централизовать абсолютно весь IAM в одной команде платформы, превращая её в узкое место для любого изменения прав
• Риск. давать полную автономию без организационных guardrails, из-за чего в одном из аккаунтов рано или поздно появляется критичная ошибка конфигурации
• Риск. не планировать регулярный аудит неиспользуемых прав и ролей.