Un'organizzazione utilizza AWS Organizations con account separati per finanza e marketing. L'applicazione di elaborazione dati del team finanziario (nell'account finanziario) usa Lambda e memorizza dati riservati in una tabella DynamoDB. Il team di marketing (in un account diverso) deve avere accesso solo ad attributi specifici di quella tabella DynamoDB. In che modo un architetto di soluzioni dovrebbe fornire al team di marketing l'accesso limitato richiesto?

L'opzione corretta prevede la creazione di un ruolo IAM nell'account finanziario con una policy che specifica l'accesso granulare (a livello di attributo) alla tabella DynamoDB, utilizzando condizioni IAM. Questo ruolo avrà una trust policy che consente all'account di marketing di assumerlo. Successivamente, nell'account di marketing, si crea un ruolo IAM che ha l'autorizzazione ad assumere il ruolo creato nell'account finanziario. Questo è il metodo standard e più sicuro per l'accesso cross-account con autorizzazioni specifiche. Le altre opzioni sono meno adatte: Le Service Control Policy (SCP) limitano le autorizzazioni massime, ma non concedono autorizzazioni. Non possono concedere accesso granulare a risorse specifiche. Le policy basate sulle risorse per DynamoDB non supportano la specificazione di attributi individuali per l'accesso granulare. I permissions boundary definiscono le autorizzazioni massime che una policy basata sull'identità può concedere, ma non concedono di per sé l'accesso granulare necessario.