Delegare in sicurezza la creazione dei ruoli

I team lavorano più velocemente quando possono creare autonomamente i propri ruoli e le proprie policy IAM, ma un accesso IAM senza restrizioni è pericoloso: uno sviluppatore potrebbe concedersi i privilegi di amministratore. La sfida consiste nel consentire ai team di creare ruoli, garantendo al contempo che tali ruoli rimangano entro limiti sicuri. I permission boundary lo rendono possibile; è uno scenario frequente negli esami.

Senza protezioni, concedere a qualcuno iam:CreateRole e iam:AttachRolePolicy equivale di fatto a concedergli l'accesso amministrativo. Potrebbe creare un ruolo con AdministratorAccess e assumerlo. Questo percorso di escalation dei privilegi è esattamente ciò che la delega sicura deve bloccare, pur consentendo la creazione legittima di ruoli.

La soluzione consiste nel richiedere che qualsiasi ruolo creato da un utente delegato abbia associato uno specifico permission boundary. Anche se l'utente associa AdministratorAccess al nuovo ruolo, il boundary ne limita le autorizzazioni effettive. Il ruolo creato non può mai superare ciò che il boundary consente, neutralizzando il rischio di escalation.

Una policy di delega sicura usa due verifiche delle condizioni: una garantisce che il nuovo ruolo abbia il boundary richiesto (tramite iam:PermissionsBoundary), mentre l'altra impedisce all'utente di modificare o eliminare il boundary stesso. Sono necessarie entrambe, altrimenti uno sviluppatore ingegnoso potrebbe semplicemente rimuovere il boundary in seguito.

Questa condizione obbliga ogni chiamata CreateRole ad associare il boundary indicato. In sua assenza, l'operazione di creazione viene negata.

È inoltre necessario impedire all'utente delegato di modificare la policy del boundary o di scollegarla dai ruoli. Aggiunga istruzioni Deny esplicite per azioni come iam:DeleteRolePermissionsBoundary e iam:CreatePolicyVersion sull'ARN del boundary. In caso contrario, la protezione può essere rimossa silenziosamente, vanificando l'intero progetto.

Le policy di delega spesso limitano il percorso o la denominazione dei ruoli che un utente può creare, ad esempio consentendoli solo in /developers/. In questo modo i ruoli vengono confinati in uno spazio dei nomi noto, risultano facili da controllare e non possono interferire con ruoli privilegiati presenti altrove nell'account.

Anche con un boundary, presti attenzione alla trust policy del nuovo ruolo. Uno sviluppatore potrebbe creare un ruolo considerato attendibile da un account esterno. Limiti i principal considerati attendibili che può impostare, oppure combini la delega con SCP e Access Analyzer per individuare e bloccare trust esterni imprevisti.

Se implementata correttamente, la delega offre ai team un vero self-service: possono creare e gestire liberamente i ruoli entro i limiti del boundary, mentre il team di sicurezza può stare tranquillo sapendo che nessun ruolo può superare il limite massimo. Questo equilibrio tra velocità e sicurezza è esattamente ciò che l'esame SCS-C02 richiede di progettare.

Negli ambienti con più account, abbini i boundary per singola identità agli SCP applicati all'intero account. L'SCP imposta un limite massimo per tutto l'account, mentre i boundary perfezionano i limiti per ogni utente delegato. La combinazione dei due offre defense in depth, così una lacuna in un controllo viene rilevata dall'altro.

La delega sicura della creazione dei ruoli richiede di: richiedere un permission boundary per ogni ruolo creato, proteggere il boundary da modifiche o rimozioni con deny espliciti, limitare percorsi e nomi e limitare il trust dei nuovi ruoli. Applichi inoltre gli SCP per definire limiti massimi a livello di account. In questo modo si chiudono i percorsi di escalation dei privilegi, preservando al contempo il self-service dei team.

Verifichi la delega sicura.

Delegare in sicurezza la creazione di ruoli IAM significa richiedere un permission boundary per ogni ruolo creato tramite la condition iam:PermissionsBoundary, negare le modifiche a tale boundary, limitare percorsi e nomi dei ruoli e limitare le trust policy dei nuovi ruoli. Abbini gli SCP per definire limiti massimi a livello di account e chiudere i percorsi di escalation dei privilegi, consentendo al contempo il self-service.