Un'azienda utilizza AWS Organizations e Control Tower per la governance e un Transit Gateway per la connettività VPC multi-account. Il team dell'applicazione ha distribuito un'applicazione web (Lambda + RDS) in un account applicativo. I DBA in un account DBA separato gestiscono centralmente i database e utilizzano un'istanza EC2 nell'account DBA per accedere a un'istanza RDS nell'account applicativo. Il team dell'applicazione memorizza le credenziali del DB in AWS Secrets Manager nell'account applicativo e attualmente condivide i segreti manualmente con i DBA. I segreti sono crittografati con la chiave Secrets Manager predefinita gestita da AWS nell'account applicativo. Progettare una soluzione che dia ai DBA l'accesso al database senza la condivisione manuale dei segreti.

L'opzione corretta utilizza un modello di assunzione di ruolo IAM cross-account, che è il metodo più sicuro e scalabile per concedere l'accesso tra account AWS. Il ruolo DBA-Secret nell'account applicativo ha i permessi per leggere il segreto e la sua trust policy consente al ruolo DBA-Admin nell'account DBA di assumerlo. L'istanza EC2 dei DBA assume il ruolo DBA-Admin, che poi assume DBA-Secret per accedere al segreto. L'opzione RAM non è adatta perché AWS Secrets Manager non supporta la condivisione di segreti tramite RAM. L'opzione che modifica le policy della chiave KMS è meno flessibile e potrebbe esporre la chiave a più entità del necessario, inoltre la chiave è gestita da AWS, rendendo la modifica delle policy più complessa. L'opzione SCP non è appropriata perché le SCP sono guardrail a livello di organizzazione che definiscono le autorizzazioni massime, non concedono l'accesso direttamente.