Vad en behörighetsgräns begränsar

En behörighetsgräns är en avancerad IAM-funktion som anger de maximala behörigheter som en användare eller roll någonsin kan ha. Den beviljar ingenting i sig själv, utan begränsar vad identitetsbaserade policyer faktiskt kan tillåta. Behörighetsgränser är ett vanligt provområde eftersom de möjliggör säker delegering av behörighetshantering.

En identitetsbaserad policy beviljar behörigheter, medan en behörighetsgräns begränsar dem. De effektiva behörigheterna är snittet av de två: en åtgärd tillåts endast om både identitetspolicyn och gränsen tillåter den. En gräns kan minska, men aldrig utöka, det som identitetspolicyn beviljar.

Anta att en användares identitetspolicy tillåter full åtkomst till S3 och EC2, men att användarens behörighetsgräns endast tillåter S3. Användaren kan då göra endast S3-åtgärder, eftersom gränsen begränsar behörigheterna. Ta bort gränsen, så blir EC2-behörigheterna effektiva igen. Gränsen verkställer i tysthet ett maximum.

Den här gränspolicyn tillåter endast åtgärder för S3 och CloudWatch. Oavsett vad identitetspolicyn anger kan användaren aldrig överskrida dessa tjänster.

Det huvudsakliga användningsområdet är säker delegering. Ni kanske vill att utvecklare ska kunna skapa egna IAM-roller, men oroar er för att de ska bevilja för omfattande behörigheter. Genom att kräva att varje roll de skapar har en behörighetsgräns kan ni garantera att rollerna aldrig överskrider gränsen, oavsett hur omfattande den kopplade policyn är.

Både gränser och SCP:er begränsar behörigheter, men de skiljer sig åt i omfattning. En behörighetsgräns gäller för en enskild användare eller roll och anges i IAM. En SCP gäller för hela konton i en organisation. Provet testar om ni väljer rätt verktyg: en gräns används per identitet och en SCP för hela kontot.

I utvärderingsflödet vinner ett uttryckligt Deny fortfarande över allt annat, inklusive gränser. I övrigt fungerar gränsen som ett tak: åtgärden måste ha ett Allow i både identitetspolicyn och gränsen. Resursbaserade policyer kan i vissa fall bevilja åtkomst oberoende av gränsen, vilket är en viktig detalj att komma ihåg.

En vanlig missuppfattning är att en åtgärd beviljas genom att den läggs till i en gräns. Så är det inte. Om identitetspolicyn saknar behörigheten har det ingen effekt att gränsen tillåter den. Identitetspolicyn måste bevilja åtgärden och gränsen måste också tillåta den för att åtgärden ska lyckas.

En detalj som testas på provet är att behörighetsgränser begränsar vad en principals identitetsbaserade policyer kan göra, men att de i vissa fall inte begränsar åtkomst som en resursbaserad policy beviljar den principalen. En gräns som begränsar en roll till S3 kan alltså fortfarande tillåta att rollen får åtkomst till SQS via en köpolicy. Ta hänsyn till denna lucka i designen.

För att säkerställa att delegerade principaler alltid kopplar en gräns skriver ni en behörighetspolicy med ett villkor som kräver att iam:PermissionsBoundary är lika med en specifik ARN för behörighetsgränsen för alla roller de skapar. Då kan en utvecklare inte skapa roller utan denna skyddsmekanism, vilket täpper till luckan i delegeringen.

En behörighetsgräns begränsar de maximala behörigheterna för en enskild användare eller roll: den effektiva åtkomsten är snittet av gränsen och identitetspolicyn. Den beviljar aldrig något på egen hand. Dess huvudsakliga syfte är säker delegering av skapande av IAM-roller, vilket verkställs genom att gränsen krävs via villkoret iam:PermissionsBoundary.

En behörighetsgräns anger de maximala behörigheterna för en enskild användare eller roll; den effektiva åtkomsten är snittet av gränsen och identitetspolicyn. Den beviljar aldrig något på egen hand, och ett uttryckligt deny vinner fortfarande. Dess huvudsakliga syfte är säker delegering, som verkställs via villkoret iam:PermissionsBoundary.