Несколько команд разработчиков развертывают рабочие нагрузки в общем производственном аккаунте AWS. Недавно члены одной команды разработчиков завершили работу инстанса EC2, принадлежащего другой команде. Разработчики используют федерацию SAML через AWS Organizations для принятия ролей. Вы должны запретить разработчикам управлять инстансами, принадлежащими другим командам, при этом позволяя им управлять своими собственными инстансами. Какая стратегия соответствует этим требованиям?

Правильный ответ позволяет разработчикам управлять только своими ресурсами, используя теги сессий и политику IAM с условием deny. Передача атрибута DevelopmentUnit как тега сессии (aws:PrincipalTag) во время федерации SAML позволяет идентифицировать команду разработчика. Затем политика IAM, прикрепленная к принятой роли, использует условие StringNotEquals для тега ресурса DevelopmentUnit и aws:PrincipalTag/DevelopmentUnit, чтобы запретить действия, если теги не совпадают. Это эффективно блокирует управление ресурсами, принадлежащими другим командам. Неправильные варианты: Создание отдельных OU и SCP с StringNotEquals для DevelopmentUnit не является оптимальным, так как SCP применяются ко всем аккаунтам в OU, а не к конкретным пользователям, и могут быть переопределены более разрешительными политиками IAM. SCP с allow и StringEquals не обеспечит запрет на управление чужими ресурсами, так как SCP не могут напрямую управлять разрешениями пользователей на основе тегов сессий и могут быть переопределены. Создание отдельных политик IAM и их назначение через STS не обеспечивает механизм запрета на управление чужими ресурсами; это только разрешает доступ к своим. Требуется явный запрет.