Un'azienda utilizza AWS Organizations e prevede di aggiungere circa 1.000 account in più. Attualmente, solo il team di sicurezza centrale può creare ruoli IAM. Per ridurre i colli di bottiglia, i team applicativi devono essere in grado di effettuare il provisioning dei propri ruoli IAM, ma i ruoli devono essere limitati nell'ambito e non devono consentire l'escalation dei privilegi. Qual è la soluzione con il minor overhead operativo?

La soluzione più efficiente è creare un SCP e un IAM permissions boundary. L'SCP, allegato alla root dell'organizzazione, può limitare le azioni IAM consentite a livello di organizzazione, impedendo l'escalation dei privilegi. Il permissions boundary, applicato ai ruoli creati dai team applicativi, definisce il set massimo di permessi che il ruolo può avere, anche se la policy di identità del ruolo concede più permessi. Questo permette ai team di creare i propri ruoli mantenendo un controllo centralizzato sui limiti massimi di accesso, riducendo il sovraccarico operativo rispetto alla revisione manuale o alla gestione di un gran numero di gruppi IAM. Le altre opzioni sono meno ideali: Creare gruppi IAM per ogni team con policy e utenti IAM aumenta il sovraccarico di gestione e non risolve direttamente il problema dell'escalation dei privilegi nella creazione di nuovi ruoli. Delegare la creazione dei ruoli con revisioni trimestrali introduce un processo manuale e un potenziale collo di bottiglia, oltre a non garantire la prevenzione dell'escalation dei privilegi. Inserire ogni account nella propria OU con SCP specifiche per i servizi richiesti è utile per la governance generale, ma non affronta direttamente la limitazione dei permessi dei ruoli IAM creati all'interno di tali account.