Компания использует AWS Organizations и Control Tower для управления, а также Transit Gateway для подключения VPC из нескольких аккаунтов. Команда разработчиков развернула веб-приложение (Lambda + RDS) в аккаунте приложения. Администраторы баз данных (DBA) в отдельном аккаунте DBA централизованно управляют базами данных и используют инстанс EC2 в аккаунте DBA для доступа к инстансу RDS в аккаунте приложения. Команда разработчиков хранит учетные данные базы данных в AWS Secrets Manager в аккаунте приложения и в настоящее время вручную делится секретами с DBA. Секреты зашифрованы с помощью ключа Secrets Manager, управляемого AWS по умолчанию, в аккаунте приложения. Разработайте решение, которое предоставит DBA доступ к базе данных без ручного обмена секретами.

Правильный ответ использует кросс-аккаунтный доступ IAM, что является стандартным и безопасным способом предоставления доступа между аккаунтами AWS. Роль DBA-Secret в аккаунте приложения имеет разрешения на чтение секрета. Роль DBA-Admin в аккаунте DBA имеет разрешение на принятие (sts:AssumeRole) роли DBA-Secret. Инстанс EC2 в аккаунте DBA принимает роль DBA-Admin, которая затем может принять DBA-Secret для чтения секрета, обеспечивая безопасный доступ без ручного обмена. Неправильные варианты: Использование AWS RAM для совместного использования секрета Secrets Manager невозможно, так как Secrets Manager не является поддерживаемым типом ресурса для RAM. Предоставление роли DBA-Admin в аккаунте DBA прямых разрешений на доступ к секретам и ключу KMS в аккаунте приложения, а также изменение политик ключей KMS, является менее гибким и сложным для управления, чем принятие роли. Использование SCP для разрешения доступа к секретам не является правильным подходом, так как SCP ограничивают разрешения, но не предоставляют их. Кроме того, SCP применяются ко всем сущностям в аккаунте и не подходят для гранулированного контроля доступа.