Diversi team di sviluppo distribuiscono carichi di lavoro di produzione in un account AWS di produzione condiviso. Recentemente, i membri di un team di sviluppo hanno terminato un'istanza EC2 appartenente a un altro team. Gli sviluppatori utilizzano la federazione SAML tramite AWS Organizations per assumere i ruoli. È necessario impedire agli sviluppatori di gestire le istanze appartenenti ad altri team, consentendo loro di gestire le proprie istanze. Quale strategia soddisfa questi requisiti?

Questa soluzione utilizza i tag di sessione AWS STS per implementare un controllo degli accessi basato sugli attributi (ABAC). Passando l'attributo DevelopmentUnit come tag di sessione, questo tag viene associato alle credenziali temporanee assunte dallo sviluppatore. La policy IAM sul ruolo assunto può quindi utilizzare aws:PrincipalTag/DevelopmentUnit per confrontare il tag del principale (lo sviluppatore) con il tag DevelopmentUnit della risorsa EC2. Una condizione StringNotEquals con un'azione di negazione impedisce agli sviluppatori di agire su istanze che non corrispondono al loro DevelopmentUnit, garantendo che possano gestire solo le proprie risorse. Le opzioni errate: Creare OU e SCP per ogni unità di sviluppo non è la soluzione più granulare o scalabile per questo problema, poiché richiederebbe la gestione di molti SCP e OU. Un SCP con un'azione di autorizzazione e StringEquals non negherebbe esplicitamente l'accesso alle risorse di altri team; gli SCP sono principalmente per negazioni ampie. Assegnare policy IAM separate per ogni unità di sviluppo e far corrispondere il nome dell'unità di sviluppo al ruolo IAM assunto non è dinamico come l'ABAC con i tag di sessione e non impedirebbe esplicitamente la gestione di risorse non proprie senza una negazione esplicita.