Delegering av rolleopprettelse på en trygg måte

Team arbeider raskere når de kan opprette egne IAM-roller og policyer, men ubegrenset IAM-tilgang er farlig: En utvikler kan gi seg selv administratorrettigheter. Utfordringen er å la team bygge roller og samtidig garantere at rollene holder seg innenfor sikre grenser. Tillatelsesgrenser gjør dette mulig, i et scenario som ofte testes på eksamen.

Uten sikkerhetsmekanismer tilsvarer det i praksis å gi noen iam:CreateRole og iam:AttachRolePolicy full administratortilgang. De kan opprette en rolle med AdministratorAccess og anta den. Denne veien til privilegieeskalering er nettopp det sikker delegering må stenge, samtidig som legitim oppretting av roller fortsatt er mulig.

Løsningen er å kreve at alle roller en delegert bruker oppretter, har en bestemt tillatelsesgrense. Selv om brukeren knytter AdministratorAccess til den nye rollen, begrenser tillatelsesgrensen de effektive tillatelsene. Den opprettede rollen kan aldri overskride det grensen tillater, og risikoen for eskalering nøytraliseres.

En policy for sikker delegering bruker to betingelseskontroller: Den ene sikrer at den nye rollen har den påkrevde grensen (via iam:PermissionsBoundary), og den andre hindrer brukeren i å endre eller slette selve grensen. Begge er nødvendige, ellers kan en oppfinnsom utvikler ganske enkelt fjerne grensen etterpå.

Denne betingelsen tvinger alle CreateRole-kall til å knytte til den navngitte grensen. Uten den blir opprettingshandlingen avvist.

De må også nekte den delegerte brukeren å redigere grensepolicyen eller koble den fra roller. Legg til eksplisitte Deny-setninger for handlinger som iam:DeleteRolePermissionsBoundary og iam:CreatePolicyVersion mot grense-ARN-en. Ellers kan sikkerhetsmekanismen fjernes i det stille, slik at hele utformingen undergraves.

Delegeringspolicyer begrenser ofte banen eller navngivingen av roller en bruker kan opprette, for eksempel bare under /developers/. Dette samler rollene i et kjent navneområde, gjør dem enkle å revidere og hindrer innblanding i privilegerte roller andre steder i kontoen.

Selv med en tillatelsesgrense må De følge med på den nye rollens tillitspolicy. En utvikler kan opprette en rolle som stoler på en ekstern konto. Begrens hvem de kan angi som betrodde principaler, eller kombiner delegering med SCP-er og Access Analyzer slik at uventet ekstern tillit oppdages og blokkeres.

Gjøres dette riktig, får teamene reell selvbetjening: De kan opprette og administrere roller fritt innenfor grensen, mens sikkerhetsteamet kan være trygt på at ingen rolle kan overskride taket. Denne balansen mellom hurtighet og sikkerhet er nettopp det SCS-C02-eksamenen ber Dem utforme.

I miljøer med flere kontoer bør De kombinere tillatelsesgrenser per identitet med SCP-er for hele kontoen. SCP-en setter et tak for hele kontoen, mens tillatelsesgrenser finjusterer grensene per delegert bruker. Ved å legge begge lag oppå hverandre får De forsvar i dybden, slik at et gap i den ene kontrollen fanges opp av den andre.

Sikker delegering av oppretting av roller krever at De: krever en tillatelsesgrense på alle opprettede roller, beskytter grensen mot endring eller fjerning med eksplisitte avslag, avgrenser baner/navn og begrenser tillit på nye roller. Legg til SCP-er for tak på kontonivå. Dette lukker veier til privilegieeskalering samtidig som teamene beholder selvbetjening.

Sikker delegering av oppretting av IAM-roller innebærer å kreve en tillatelsesgrense på alle opprettede roller via betingelsen iam:PermissionsBoundary, nekte endringer i denne grensen, avgrense rollebaner/-navn og begrense tillitspolicyer på nye roller. Kombiner med SCP-er for tak på kontonivå for å lukke veier til privilegieeskalering og samtidig muliggjøre selvbetjening.