Flusso decisionale della valutazione delle policy

Quando una richiesta raggiunge AWS, il motore IAM esegue un preciso flusso di valutazione per decidere se consentirla o negarla. Memorizzare quest'ordine è una delle attività più utili per l'esame SCS-C02, perché le domande con scenari complessi dipendono da quale tipo di policy prevalga quando ne sono coinvolte diverse.

Il punto di partenza è sempre una negazione implicita. Se nulla nella valutazione concede l'accesso, la richiesta viene negata. Questo approccio di negazione predefinita significa che è necessario consentire esplicitamente un'azione in qualche punto affinché possa essere eseguita; il silenzio equivale a una negazione.

La regola più importante è una sola: un Deny esplicito in qualsiasi punto di una policy applicabile prevale su ogni Allow. Indipendentemente dal numero di istruzioni che concedono l'azione, un solo Deny corrispondente la blocca. È così che i guardrail e gli SCP impongono limiti rigidi che le policy di livello inferiore non possono superare.

AWS esegue la valutazione secondo questo ordine concettuale: 1) verifica la presenza di un Deny esplicito in qualsiasi policy (SCP, boundary, policy di identità, di risorsa o di sessione): se lo trova, nega l'accesso. 2) Se si applica uno SCP e questo non consente l'azione, la nega. 3) Verifica la presenza di un Allow nelle permission boundary, nelle policy di sessione e nelle policy di identità o di risorsa. Qualsiasi lacuna produce una negazione implicita.

Le Service Control Policies (SCP) in AWS Organizations definiscono le autorizzazioni massime per un account. Un'azione deve essere consentita dallo SCP e da una policy IAM per poter essere eseguita. Gli SCP non concedono mai l'accesso autonomamente: si limitano a fissare un tetto o a negare l'accesso. Se lo SCP non consente un'azione, nessun Allow IAM può porvi rimedio.

Una permission boundary è una policy avanzata che limita le autorizzazioni massime di uno specifico utente o ruolo. Le autorizzazioni effettive sono l'intersezione tra la boundary e la policy di identità. Come gli SCP, una boundary può solo limitare; non amplia mai ciò che concede una policy basata sull'identità.

Quando un ruolo viene assunto con una policy di sessione, tale policy restringe ulteriormente le autorizzazioni solo per quella sessione. Anche in questo caso il risultato è un'intersezione: la sessione non può fare più di quanto consentano sia le policy del ruolo sia la policy di sessione. Le policy di sessione consentono di ridurre l'ambito delle autorizzazioni al momento dell'assunzione del ruolo.

Per le richieste all'interno dello stesso account, un Allow basato sulla risorsa può concedere l'accesso anche senza un Allow basato sull'identità (unione). Per le richieste tra account, sono necessari entrambi. Inoltre, un Deny esplicito presente in una qualsiasi di queste policy prevale sempre. La policy di risorsa partecipa allo stesso flusso di valutazione generale.

Supponiamo che una policy di identità consenta s3:DeleteObject, ma che uno SCP neghi tutti gli elementi s3:Delete* nell'ambiente di produzione. Il risultato è accesso negato, perché il Deny esplicito dello SCP prevale sull'Allow dell'identità. Al contrario, se lo SCP consente l'azione ma nessuna policy di identità la concede, l'accesso viene comunque negato per negazione implicita. Entrambi i livelli devono concordare per consentire l'azione.

Gli scenari d'esame combinano SCP, boundary, policy di identità e policy di risorsa, quindi chiedono quale sarà il risultato. Il metodo più affidabile consiste nel cercare prima qualsiasi Deny esplicito, verificare che lo SCP consenta l'azione, verificare che la boundary e la sessione la consentano e confermare l'esistenza di un Allow di identità o di risorsa. Se tutto coincide e non è presente alcun Deny, la risposta è consentire l'accesso.

Tenga a mente questa checklist: (1) È presente un Deny esplicito? Nega l'accesso. (2) Lo SCP consente l'azione? In caso contrario, nega l'accesso. (3) La boundary o la sessione consentono l'azione? In caso contrario, nega l'accesso. (4) È presente un Allow di identità o di risorsa? Se sì e non c'è alcun Deny, consente l'accesso; altrimenti si applica la negazione implicita. La applichi in modo meccanico: anche le domande con più policy diventano semplici.

Verifichi il flusso di valutazione.

La valutazione IAM parte dalla negazione implicita e un Deny esplicito prevale sempre. Per consentire un'azione non deve esserci alcun Deny esplicito, lo SCP deve consentirla, le permission boundary e le policy di sessione (intersezioni) devono consentirla e deve esistere un Allow di identità o di risorsa. Gli SCP e le boundary limitano soltanto le autorizzazioni; non le concedono mai.