Hvordan SCP-er kombineres med IAM-tillatelser

Tilgang i en organisasjon styres av to nivåer: SCP-taket som settes av AWS Organizations, og IAM-tillatelsene som gis i kontoen. Å forstå hvordan de kombineres, er et av de mest testede temaene innen styring, fordi resultatet avhenger av at begge tillater handlingen.

Regelen er enkel, men streng: En handling er bare tillatt hvis den er tillatt av både de relevante SCP-ene og kontoens IAM-policyer. Den effektive tillatelsen er snittet av disse. En SCP uten en tilsvarende IAM-tillatelse gir ingenting; en IAM-tillatelse som blokkeres av en SCP, gir heller ingenting.

Hvis SCP-en tillater en handling, men ingen IAM-policy gir tillatelse til den, blir resultatet nektet på grunn av IAMs implisitte nektelse. SCP-en gjorde bare handlingen mulig; IAM må fortsatt faktisk gi tillatelsen. Mange elever glemmer at SCP-en er et tak, ikke en tillatelse.

Omvendt blir resultatet nektet hvis en IAM-policy tillater en handling, men en SCP nekter den. SCP-ens nektelse setter en grense for kontoen, uansett hvor sjenerøs IAM er. Slik håndhever en organisasjon absolutte begrensninger som lokale administratorer ikke kan omgå.

Forespørselen blir tillatt bare når både SCP-en og en IAM-policy tillater handlingen, og det ikke finnes noen eksplisitt nektelse noe sted. Denne snittlogikken tilsvarer hvordan tillatelsesgrenser fungerer, og begge kan gjelde samtidig og begrense tillatelsene ytterligere.

I et fullstendig styrt miljø legges flere grenser oppå hverandre: SCP-en (kontonivå), tillatelsesgrensen (identitetsnivå), eventuell sesjonspolicy (sesjonsnivå) og identitetspolicyen (tillatelsen). Den effektive tillatelsen er snittet av alle grensene pluss tillatelsen, minus enhver eksplisitt nektelse.

Se for Dem en IAM-policy som gir s3:* og ec2:*, en tillatelsesgrense som bare tillater s3:*, og en SCP som bare tillater s3:GetObject. Den effektive tillatelsen er bare s3:GetObject, altså snittet av alle tre lagene. Hver grense reduserer tillatelsene ytterligere.

På tvers av alle lag blokkerer en eksplisitt nektelse i en policy, SCP, grense, sesjon, identitet eller ressurs handlingen umiddelbart. Ingen kombinasjon av tillatelser kan overstyre den. Når De analyserer en oppgave, bør De først lete etter en eksplisitt nektelse. Hvis De finner en, er svaret nektet.

Ressursbaserte policyer kan gi tilgang innenfor samme konto uavhengig av identitetspolicyen, men SCP-er setter fortsatt en grense for prinsipalens konto. Ved tilgang på tvers av kontoer gjelder kontrollene og policyene i begge kontoene. Snittregelen blir utvidet, men hovedideen består: Alle relevante grenser må tillate handlingen.

Når tilgang uventet mislykkes i en organisasjon, bør De arbeide utover: Bekreft at identitetspolicyen gir tillatelse til handlingen, kontroller deretter tillatelsesgrensen, så SCP-ene på kontoen og i hver overordnede OU, deretter eventuell sesjonspolicy, og til slutt alle lag for en eksplisitt nektelse. Den første grensen som ikke inkluderer handlingen, eller enhver nektelse, er årsaken.

SCP-er og IAM kombineres ved hjelp av snitt: En handling trenger en tillatelse fra begge, i tillegg til eventuelle grenser og sesjonsgrenser, uten noen eksplisitt nektelse noe sted. SCP-er og grenser begrenser bare; IAM-policyer gir tillatelser. For å tillate en handling må alle grenser tillate den, og minst én tillatelse må finnes.

SCP-er og IAM kombineres ved hjelp av snitt: En handling er bare tillatt hvis begge tillater den, i tillegg til eventuelle grenser fra tillatelsesgrensen og sesjonspolicyen, uten noen eksplisitt nektelse noe sted. SCP-er og grenser begrenser bare; IAM-policyer gir tillatelser. En eksplisitt nektelse i ethvert lag trumfer alltid alle tillatelser.