Hoe SCP's samengaan met IAM-machtigingen

Toegang in een organisatie wordt beheerd door twee lagen: het door AWS Organizations ingestelde SCP-plafond en de IAM-machtigingen die binnen het account zijn verleend. Begrijpen hoe deze samenwerken is een van de belangrijkste toetsbare onderwerpen binnen governance, omdat de uitkomst van beide afhankelijk is.

De regel is eenvoudig maar strikt: een actie is alleen toegestaan als deze wordt toegestaan door zowel de toepasselijke SCP's als het IAM-beleid van het account. De effectieve machtiging is de doorsnede. Een SCP zonder overeenkomende IAM-toestaan-machtiging verleent niets; een door een SCP geblokkeerde IAM-toestaan-machtiging verleent ook niets.

Als het SCP een actie toestaat maar geen IAM-beleid deze verleent, wordt het resultaat geweigerd door de impliciete weigering van IAM. Het SCP maakte de actie alleen mogelijk; IAM moet deze nog daadwerkelijk verlenen. Veel leerlingen vergeten dat een SCP een plafond is en geen verlening.

Omgekeerd wordt een actie geweigerd als een IAM-beleid deze toestaat maar een SCP deze weigert. De weigering van het SCP beperkt het account, ongeacht hoe ruim IAM is ingesteld. Zo dwingt een organisatie harde grenzen af die lokale beheerders niet kunnen omzeilen.

Alleen wanneer zowel het SCP als een IAM-beleid de actie toestaan en er nergens een expliciete weigering bestaat, wordt het verzoek toegestaan. Deze doorsnedelogica lijkt op de werking van machtigingsgrenzen, en beide kunnen tegelijk van toepassing zijn, waardoor machtigingen verder worden beperkt.

In een volledig beheerde omgeving stapelen meerdere beperkingen zich op: het SCP (accountniveau), de machtigingsgrens (identiteitsniveau), eventueel het sessiebeleid (sessieniveau) en het identiteitsbeleid (verlening). De effectieve machtiging is de doorsnede van alle beperkingen plus de verlening, verminderd met elke expliciete weigering.

Stel je een IAM-beleid voor dat s3:* en ec2:* verleent, een machtigingsgrens die alleen s3:* toestaat en een SCP dat alleen s3:GetObject toestaat. De effectieve machtiging is alleen s3:GetObject, de doorsnede van alle drie de lagen. Elke beperking verkleint de machtigingen verder.

In elke laag blokkeert een expliciete weigering in een beleid, SCP, grens, sessie, identiteit of resource de actie onmiddellijk. Geen combinatie van toestaan-machtigingen kan deze omzeilen. Zoek bij het analyseren van een scenario eerst naar een expliciete weigering; als je die vindt, is het antwoord weigeren.

Brongebaseerd beleid kan onafhankelijk van het identiteitsbeleid toegang binnen hetzelfde account verlenen, maar SCP's beperken nog steeds het account van de principal. Voor toegang tussen accounts zijn de besturingselementen van beide accounts en het beleid aan beide kanten van toepassing. De doorsnederegel wordt uitgebreider, maar het kernidee blijft hetzelfde: elke toepasselijke beperking moet de actie toestaan.

Wanneer toegang binnen een organisatie onverwacht mislukt, werk je van binnen naar buiten: controleer eerst of het identiteitsbeleid de actie verleent, controleer daarna de machtigingsgrens, vervolgens de SCP's op het account en elke bovenliggende OU, daarna eventueel het sessiebeleid en zoek tot slot in alle lagen naar een expliciete weigering. De eerste beperking die de actie niet toestaat, of elke weigering, is de oorzaak.

SCP's en IAM werken samen via een doorsnede: een actie heeft een toestaan-machtiging nodig van beide, plus eventuele beperkingen van een grens en sessie, zonder ergens een expliciete weigering. SCP's en grenzen beperken alleen; IAM-beleid verleent. Om een actie toe te staan, moet elke beperking deze toestaan en moet er minstens één verlening bestaan.

SCP's en IAM werken samen via een doorsnede: een actie is alleen toegestaan als beide deze toestaan, plus eventuele beperkingen van een machtigingsgrens en sessiebeleid, zonder ergens een expliciete weigering. SCP's en grenzen beperken alleen; IAM-beleid verleent. Een expliciete weigering in welke laag dan ook heeft altijd voorrang op elke toestaan-machtiging.