Cosa limita un permission boundary

Un permission boundary è una funzionalità avanzata di IAM che imposta le autorizzazioni massime che un utente o un ruolo può avere. Non concede nulla autonomamente; limita ciò che le policy basate sull'identità possono consentire effettivamente. I permission boundary sono un argomento frequente d'esame perché permettono di delegare in sicurezza la gestione delle autorizzazioni.

Una policy basata sull'identità concede autorizzazioni; un permission boundary le limita. Le autorizzazioni effettive sono l'intersezione delle due: un'azione è consentita solo se entrambe la policy basata sull'identità e il boundary la autorizzano. Un boundary può ridurre, ma mai ampliare, ciò che concede la policy basata sull'identità.

Supponiamo che la policy basata sull'identità di un utente consenta l'accesso completo a S3 ed EC2, ma che il suo permission boundary consenta solo S3. L'utente può eseguire solo azioni S3, perché il boundary ne limita le autorizzazioni. Rimuovendo il boundary, le autorizzazioni EC2 tornano a essere effettive. Il boundary impone silenziosamente un limite massimo.

Questa policy del boundary consente solo azioni S3 e CloudWatch. A prescindere dal contenuto della policy basata sull'identità, l'utente non può mai superare i limiti di questi servizi.

Il principale caso d'uso è la delega sicura. Si vuole consentire agli sviluppatori di creare i propri ruoli IAM, ma si teme che concedano autorizzazioni eccessive. Richiedendo che ogni ruolo creato includa un permission boundary, si garantisce che tali ruoli non possano mai superare il boundary, indipendentemente dall'ampiezza della policy associata.

Sia i boundary sia gli SCP limitano le autorizzazioni, ma differiscono per ambito. Un permission boundary si applica a un singolo utente o ruolo ed è configurato in IAM. Un SCP si applica a interi account all'interno di un'organizzazione. L'esame verifica la scelta dello strumento corretto: per singola identità si usa un boundary, per l'intero account si usa un SCP.

Nel flusso di valutazione, un Deny esplicito prevale comunque su tutto, inclusi i boundary. In caso contrario, il boundary agisce da limite massimo: l'azione deve avere un Allow sia nella policy basata sull'identità sia nel boundary. In alcuni casi, le policy basate sulle risorse possono concedere accesso indipendentemente dal boundary; è una particolarità da ricordare.

Un'idea errata frequente è che aggiungere un'azione a un boundary la conceda. Non è così. Se la policy basata sull'identità non include l'autorizzazione, il fatto che il boundary la consenta non ha alcun effetto. La policy basata sull'identità deve concederla e il boundary deve inoltre consentirla affinché l'azione abbia esito positivo.

Una particolarità verificata dall'esame: i permission boundary limitano ciò che le policy basate sull'identità di un principal possono fare, ma in alcuni casi non limitano l'accesso concesso a quel principal da una policy basata sulle risorse. Pertanto, un boundary che limita un ruolo a S3 potrebbe comunque consentire al ruolo di ricevere accesso a SQS tramite una policy della coda. Progetti tenendo conto di questa lacuna.

Per imporre che i principal delegati associno sempre un boundary, si scrive una policy delle autorizzazioni con una condition che richieda che iam:PermissionsBoundary corrisponda a un ARN di boundary specifico per qualsiasi ruolo creato. In questo modo si impedisce a uno sviluppatore di creare ruoli senza questa protezione, eliminando la falla nella delega.

Un permission boundary limita le autorizzazioni massime di un singolo utente o ruolo: l'accesso effettivo è l'intersezione tra il boundary e la policy basata sull'identità. Non concede mai autorizzazioni autonomamente. Il suo scopo principale è la delega sicura della creazione di ruoli IAM, applicata richiedendo il boundary tramite la condition iam:PermissionsBoundary.

Un permission boundary imposta le autorizzazioni massime di un singolo utente o ruolo; l'accesso effettivo è l'intersezione tra il boundary e la policy basata sull'identità. Non concede mai autorizzazioni autonomamente e un deny esplicito prevale comunque. Il suo scopo principale è la delega sicura, applicata tramite la condition iam:PermissionsBoundary.