Beslutningsflyten ved policy-evaluering

Når en forespørsel når AWS, kjører IAM-motoren en presis evalueringsflyt for å avgjøre Allow eller Deny. Å huske denne rekkefølgen er noe av det mest verdifulle De kan gjøre for SCS-C02-eksamen, fordi krevende scenariospørsmål avhenger av hvilken policytype som vinner når flere er involvert.

Utgangspunktet er alltid et implisitt avslag. Hvis ingenting i evalueringen gir tilgang, blir forespørselen avslått. Denne tilnærmingen med avslag som standard betyr at De må tillate en handling eksplisitt et sted for at den skal lykkes; taushet betyr avslag.

Den aller viktigste regelen er at et eksplisitt Deny hvor som helst i en relevant policy overstyrer alle Allow. Uansett hvor mange setninger som gir tilgang til handlingen, blokkerer ett samsvarende Deny den. Slik håndhever guardrails og SCP-er harde begrensninger som policyer på lavere nivå ikke kan overstyre.

AWS evaluerer i denne konseptuelle rekkefølgen: 1) se etter et eksplisitt Deny i en policy (SCP-er, grenser, identitet, ressurs, sesjon) — hvis det finnes, avslås forespørselen. 2) Hvis en SCP gjelder og ikke tillater handlingen, avslås den. 3) Se etter en Allow i permission boundaries, session policies og identity/resource policies. Ethvert manglende ledd fører til et implisitt avslag.

Service Control Policies (SCPs) i AWS Organizations angir de maksimale tillatelsene for en konto. En handling må være tillatt av SCP-en og av en IAM-policy for å lykkes. SCP-er gir aldri tilgang på egen hånd; de setter bare en øvre grense eller avslår. Hvis SCP-en ikke tillater en handling, kan ingen IAM-Allow redde den.

En permission boundary er en avansert policy som begrenser de maksimale tillatelsene til en bestemt bruker eller rolle. De effektive tillatelsene er snittet av grensen og identitetspolicyen. I likhet med SCP-er kan en boundary bare begrense; den utvider aldri det en identitetsbasert policy gir.

Når en rolle antas med en session policy, begrenser denne policyen tillatelsene ytterligere for akkurat denne sesjonen. Resultatet er igjen et snitt: Sesjonen kan ikke gjøre mer enn det både rollepolicyene og session policy tillater. Session policies er måten De begrenser tilgangen på når rollen antas.

For forespørsler i samme konto kan en resource-based Allow gi tilgang selv uten en identity Allow (union). På tvers av kontoer kreves begge. Og hele veien vinner et eksplisitt Deny i noen av disse fortsatt. Ressurspolicyen inngår i den samme overordnede flyten.

Anta at en identitetspolicy tillater s3:DeleteObject, men at en SCP avslår alle s3:Delete*-handlinger i produksjon. Resultatet er: avslått, fordi det eksplisitte SCP-avslaget overstyrer identitetstillatelsen. Motsatt: Hvis SCP-en tillater handlingen, men ingen identitetspolicy gir tillatelse, avslås den også på grunn av implisitt avslag. Begge lag må tillate handlingen.

Oppgaver på eksamen kombinerer SCP-er, boundaries, identitets- og ressurspolicyer og spør deretter om utfallet. Den pålitelige metoden er først å se etter et eksplisitt avslag, bekrefte at SCP-en tillater handlingen, bekrefte at boundary og session tillater den, og bekrefte at det finnes en identity- eller resource-Allow. Hvis alt stemmer uten avslag, er svaret tillat.

Husk denne sjekklisten: (1) Finnes det et eksplisitt avslag? Avslå. (2) Tillater SCP-en handlingen? Hvis ikke, avslå. (3) Tillater boundary/session handlingen? Hvis ikke, avslå. (4) Finnes det en identity- eller resource-Allow? Hvis ja og det ikke finnes noe avslag, tillat; ellers er det et implisitt avslag. Bruk metoden mekanisk, så blir selv spørsmål med mange policyer enkle å løse.

IAM-evalueringen starter med implisitt avslag, og et eksplisitt Deny vinner alltid. For å tillate en handling må det ikke finnes noe eksplisitt avslag, SCP-en må tillate den, permission boundaries og session policies (snitt) må tillate den, og det må finnes en identity- eller resource-Allow. SCP-er og boundaries begrenser bare; de gir aldri tilgang.