Betingelser, jokertegn og policyvariabler

I tillegg til handling og ressurs tilbyr IAM effektive verktøy for å gjøre policyer presise og dynamiske: conditions, wildcards og policy variables. Når De behersker disse, kan De gi nøyaktig den tilgangen som trengs, under nøyaktig de riktige omstendighetene. Dette er selve kjernen i minste privilegium og et tilbakevendende tema på eksamen.

En Condition-blokk inneholder én eller flere tester som alle må være sanne for at setningen skal gjelde. Hver test kombinerer en operator med en condition key og en verdi, for eksempel StringEquals på aws:PrincipalTag. Flere nøkler i én blokk kombineres med AND; flere verdier for én nøkkel kombineres med OR.

Globale condition keys dukker stadig opp på eksamen:

• aws:SourceIp — begrens etter IP-området til den som kaller.
• aws:SecureTransport — krev TLS.
• aws:MultiFactorAuthPresent — krev MFA.
• aws:PrincipalOrgID — begrens til organisasjonen Deres.

Tjenestespesifikke nøkler (som s3:prefix) gir enda finere kontroll.

Et klassisk mønster avslår tilgang med mindre forespørselen bruker TLS. Denne bucket-policy-betingelsen blokkerer alle kall som ikke bruker HTTPS, slik at data under overføring alltid er kryptert. På eksamen brukes dette ofte som svaret på «krev kryptering under overføring for S3».

Operatorer angir hvordan verdier sammenlignes: StringEquals, StringLike (støtter wildcards), IpAddress, DateGreaterThan, Bool og Null, blant andre. Hvis De legger til IfExists i en operator, blir testen bestått når nøkkelen mangler. Det er avgjørende å velge riktig operator for å oppnå ønsket logikk.

Wildcards (* for enhver sekvens, ? for ett tegn) gjør policyer kortere, men kan gi for brede tillatelser. s3:Get* dekker alle leseorienterte operasjoner; s3:* dekker alt i S3. Bruk det smaleste wildcardet som dekker behovet, og vær skeptisk til brede wildcards i alle policyer De gjennomgår.

Ressurs-ARN-er støtter også wildcards, for eksempel arn:aws:s3:::logs/2024/* for å begrense til ett prefiks. Dette lar en policy rette seg mot en mappe eller et mønster uten å liste opp hvert objekt. Men en Resource som bare er "*" gir tilgang i hele kontoen, så vurder alltid om en slik bredde virkelig er nødvendig.

Policy variables setter inn konteksten for forespørselen under evalueringen ved hjelp av syntaksen ${...}. Den mest nyttige er ${aws:username}, som lar én policy gi hver bruker tilgang bare til egne ressurser. Variabler gjør at én gjenbrukbar policy kan oppføre seg forskjellig for hver principal, og gir en elegant måte å skalere minste privilegium på.

Denne setningen lar hver bruker bare administrere objekter under en mappe som er oppkalt etter brukernavnet, et kraftig mønster med én policy for alle.

Attribute-Based Access Control (ABAC) bruker tagger i betingelser og sammenligner taggene til principalen (aws:PrincipalTag) med taggene til ressursen (aws:ResourceTag). Når de samsvarer, gis tilgang. ABAC skalerer svært godt: De gir tilgang basert på tagger i stedet for å skrive en ny policy for hvert prosjekt. Dette er en moderne anbefalt praksis som eksamen fremhever.

Kombiner disse verktøyene bevisst: Bruk conditions til å styre tilgang basert på MFA, IP, TLS eller organisasjonstilhørighet; bruk wildcards sparsomt og snevert; bruk policy variables og tags for skalerbart, per-principal minste privilegium. Til sammen lar de én gjennomarbeidet policy håndheve presis, kontekstbevisst tilgang på tvers av mange identiteter og ressurser.

Conditions styrer når setninger gjelder, basert på kontekstnøkler (aws:SourceIp, aws:SecureTransport, aws:MultiFactorAuthPresent, aws:PrincipalOrgID), ved hjelp av operatorer som StringLike og Bool. Wildcards (* og ?) gjør policyer kortere, men kan gi for brede tillatelser. Policy variables som ${aws:username} og tag-basert ABAC gir skalerbart minste privilegium per principal.