Tillitspolicyer og hvem som kan anta roller

En tillitspolicy er dokumentet som er knyttet til en rolle, og som nøyaktig definerer hvilke principal-er som har lov til å anta den. Den fungerer som en portvakt: Selv om en tillatelsespolicy gir omfattende tilgang, kan ingen bruke rollen med mindre tillitspolicyen navngir dem. På eksamen er feil i tillitspolicyer en vanlig årsak til både manglende tilgang og farlig brede tillatelser.

Elementet Principal i en tillitspolicy kan referere til:

• AWS — en konto-, bruker- eller rolle-ARN (Amazon Resource Name).
• Service — en AWS-tjeneste, for eksempel lambda.amazonaws.com.
• Federated — en SAML-leverandør eller en leverandør av webidentitet.

Det er viktig å velge riktig principal-type og være spesifikk for å unngå å gi mer tillit enn tilsiktet.

Antakelse på tvers av kontoer krever at begge sider samtykker. Rollens tillitspolicy i målkontoen må tillate den anropende principal-en, og denne principal-en må ha en identitetspolicy som tillater sts:AssumeRole på rollens ARN. Hvis én av delene mangler, blokkeres forespørselen. Dette toveis håndtrykket er en klassisk felle på eksamen.

Denne tillitspolicyen lar en bestemt rolle i konto 111122223333 anta rollen. Det er strengere og sikrere å angi en nøyaktig ARN enn å angi hele kontoen.

Når De angir en principal som arn:aws:iam::ACCOUNT:root, stoler De på hele kontoen: Enhver principal der som også har tillatelse til sts:AssumeRole, kan anta rollen. Dette er bredt. Der det er mulig, bør De angi den nøyaktige bruker- eller rolle-ARN-en for å følge prinsippet om minste privilegium og redusere tillitsflaten.

Tillitspolicyer støtter blokker med Condition som begrenser hvem som kan anta en rolle, og hvordan det kan skje. Vanlige nøkler omfatter sts:ExternalId (for å hindre forvirret stedfortreder-problemet), aws:MultiFactorAuthPresent (krever MFA) og aws:SourceIp. Betingelser lar Dem bare tillate antakelse under bestemte, verifiserbare omstendigheter.

Et effektivt mønster er å kreve MFA før en sensitiv rolle kan antas. Betingelsen i tillitspolicyen kontrollerer at den anropende sesjonen ble autentisert med MFA. Det betyr at selv en stjålet langsiktig legitimasjon ikke kan anta den privilegerte rollen uten den andre faktoren, noe som gjør jobben betydelig vanskeligere for angripere.

Noen roller er tjenesteknyttede roller, forhåndsdefinert av AWS med en tillitspolicy De ikke kan redigere. De lar en tjeneste administrere ressurser på Deres vegne med nøyaktig den tilliten AWS krever. Det er viktig å kjenne dem igjen fordi tillatelsene og tilliten deres er strengt kontrollert og knyttet til tjenestens livssyklus.

Det innebærer vanligvis lavere risiko å stole på en intern principal (samme konto) enn å stole på en ekstern konto eller en tredjeparts SaaS-leverandør. Ved ekstern tillit bør De alltid kombinere en spesifikk principal med betingelser som ExternalId. Betrakt enhver erklæring om ekstern tillit som et inngangspunkt en angriper gjerne vil utnytte.

IAM Access Analyzer gjennomgår automatisk tillitspolicyer og ressurspolicyer for å finne roller som kan antas av eksterne kontoer eller offentligheten. Den markerer utilsiktet tillit på tvers av kontoer eller offentlig tillit, slik at De kan stramme den inn. Gjennomgang av funn i Access Analyzer er et anbefalt og eksamensrelevant tiltak for å oppdage for bred tillit.

For å utforme tillit på en sikker måte bør De angi den mest spesifikke principal-en som er mulig, legge til betingelser som ExternalId og MFA der det er hensiktsmessig, foretrekke roller fremfor tillit til kontorotbrukeren og gjennomgå løsningen med Access Analyzer. Husk at tillitspolicyen svarer på hvem, mens tillatelsespolicyene svarer på hva; begge må stemme overens for at tilgangen skal fungere og fortsatt følge prinsippet om minste privilegium.

En tillitspolicy definerer hvilke principal-er som kan anta en rolle, og fungerer som portvakt uavhengig av tillatelsespolicyene. Antakelse på tvers av kontoer krever et toveis håndtrykk: tillitspolicyen samt anroperens tillatelse til sts:AssumeRole. Foretrekk spesifikke principal-ARN-er fremfor kontorotbrukeren, legg til betingelser som ExternalId og MFA, og revider med IAM Access Analyzer.