Come le SCP si combinano con le autorizzazioni IAM

L'accesso in un'organizzazione è regolato da due livelli: il limite degli SCP impostato da AWS Organizations e le autorizzazioni IAM concesse all'interno dell'account. Comprendere come si combinano è una delle idee più frequentemente verificate nell'ambito della governance, perché il risultato dipende dal consenso di entrambi.

La regola è semplice ma rigorosa: un'azione è consentita solo se autorizzata sia dagli SCP applicabili sia dalle policy IAM dell'account. L'autorizzazione effettiva è l'intersezione. Uno SCP senza un allow IAM corrispondente non concede nulla; un allow IAM bloccato da uno SCP non concede nulla.

Se lo SCP consente un'azione ma nessuna policy IAM la concede, il risultato è negato a causa del deny implicito di IAM. Lo SCP ha reso l'azione soltanto possibile; deve comunque essere IAM a concederla effettivamente. Molti studenti dimenticano che lo SCP è un limite massimo, non una concessione.

Al contrario, se una policy IAM consente un'azione ma uno SCP la nega, il risultato è negato. Il deny dello SCP impone un limite all'account indipendentemente da quanto siano permissive le policy IAM. È così che un'organizzazione applica limiti rigidi che gli amministratori locali non possono ignorare.

La richiesta è consentita solo quando sia lo SCP sia una policy IAM consentono l'azione e non esiste alcun deny esplicito in nessun punto. Questa logica dell'intersezione è simile al funzionamento dei permission boundary, che possono applicarsi contemporaneamente e restringere ulteriormente le autorizzazioni.

In un ambiente completamente governato si sommano diversi limiti: lo SCP (a livello di account), il permission boundary (a livello di identità), qualsiasi session policy (a livello di sessione) e la identity policy (la concessione). L'autorizzazione effettiva è l'intersezione di tutti i limiti più la concessione, meno qualsiasi deny esplicito.

Immagini una policy IAM che concede s3:* ed ec2:*, un permission boundary che consente solo s3:* e uno SCP che consente solo s3:GetObject. L'autorizzazione effettiva è soltanto s3:GetObject, cioè l'intersezione dei tre livelli. Ogni limite riduce ulteriormente le autorizzazioni.

In ogni livello, un Deny esplicito presente in una qualsiasi policy, nello SCP, nel boundary, nella sessione, nell'identità o nella risorsa blocca immediatamente l'azione. Nessuna combinazione di allow può annullarlo. Quando analizza uno scenario, cerchi prima qualsiasi deny esplicito; se ne trova uno, la risposta è deny.

Le policy basate sulle risorse possono concedere l'accesso all'interno dello stesso account indipendentemente dalla identity policy, ma gli SCP continuano a porre un limite all'account del principal. Per l'accesso tra account, si applicano i controlli di entrambi gli account e le policy di entrambe le parti. La regola dell'intersezione si estende, ma l'idea fondamentale resta valida: ogni limite applicabile deve consentire l'azione.

Quando l'accesso in un'organizzazione non riesce in modo imprevisto, proceda dall'interno verso l'esterno: verifichi che la identity policy conceda l'azione, quindi controlli il permission boundary, poi gli SCP dell'account e di ogni OU padre, quindi qualsiasi session policy e infine cerchi un deny esplicito in tutti i livelli. Il primo limite che non include l'azione, o qualsiasi deny, è la causa del problema.

SCP e IAM si combinano tramite intersezione: un'azione richiede un allow da entrambi, oltre agli eventuali limiti di boundary e sessione, senza alcun deny esplicito. SCP e boundary limitano soltanto; le policy IAM concedono. Per consentire un'azione, ogni limite deve permetterla e deve esistere almeno una concessione.

Verifichi la logica della combinazione.

SCP e IAM si combinano tramite intersezione: un'azione è consentita solo se entrambi la permettono, oltre agli eventuali limiti del permission boundary e della session policy, senza alcun deny esplicito. SCP e boundary limitano soltanto; le policy IAM concedono. Un deny esplicito in qualsiasi livello prevale sempre su ogni allow.