Villkor, jokertecken och policyvariabler

Utöver åtgärd och resurs erbjuder IAM kraftfulla verktyg för att göra policyer precisa och dynamiska: conditions, wildcards och policy variables. När Ni behärskar dessa kan Ni bevilja exakt den åtkomst som behövs under exakt rätt omständigheter, vilket är kärnan i principen om minsta privilegium och ett återkommande provtema.

Ett Condition-block innehåller ett eller flera tester som alla måste vara sanna för att statementet ska tillämpas. Varje test kopplar en operator till en condition key och ett värde, till exempel StringEquals för aws:PrincipalTag. Flera nycklar i samma block kombineras med AND; flera värden för samma nyckel kombineras med OR.

Globala condition keys förekommer ständigt på provet:

• aws:SourceIp — begränsa efter anroparens IP-intervall.
• aws:SecureTransport — kräv TLS.
• aws:MultiFactorAuthPresent — kräv MFA.
• aws:PrincipalOrgID — begränsa till Er organisation.

Servicespecifika nycklar (som s3:prefix) ger ännu finare kontroll.

Ett klassiskt mönster nekar åtkomst om begäran inte använder TLS. Detta villkor i en bucket policy blockerar alla anrop som inte använder HTTPS och säkerställer att data under överföring alltid är krypterade. På provet är detta ett vanligt svar på frågan "kräv kryptering under överföring för S3".

Operatorer anger hur värden jämförs: StringEquals, StringLike (stöder wildcards), IpAddress, DateGreaterThan, Bool och Null med flera. Om IfExists läggs till i en operator godkänns testet när nyckeln saknas. Det är viktigt att välja rätt operator för att få den avsedda logiken.

Wildcards (* för valfri teckenföljd, ? för ett tecken) gör policyer kortfattade men kan bevilja för bred åtkomst. s3:Get* omfattar alla läsrelaterade åtgärder; s3:* omfattar allt i S3. Använd den snävaste wildcarden som uppfyller behovet och var misstänksam mot breda wildcards i alla policyer Ni granskar.

Resource ARN:er accepterar också wildcards, till exempel arn:aws:s3:::logs/2024/* för att begränsa åtkomsten till ett prefix. Det gör att en policy kan rikta sig mot en mapp eller ett mönster utan att varje objekt behöver listas. Men en Resource som bara är "*" ger åtkomst i hela kontot, så ifrågasätt alltid om en sådan omfattning verkligen behövs.

Policy variables infogar begärandekontext vid utvärderingen med syntaxen ${...}. Den mest användbara är ${aws:username}, som gör att en policy kan ge varje användare åtkomst endast till deras egna resurser. Variabler gör att en enda återanvändbar policy kan fungera olika för olika principals och på ett elegant sätt skala principen om minsta privilegium.

Detta statement låter varje användare hantera endast objekt under en mapp som har fått användarens användarnamn som namn, ett kraftfullt mönster där samma policy används för alla.

Attribute-Based Access Control (ABAC) använder taggar i conditions och jämför principalens taggar (aws:PrincipalTag) med resursens taggar (aws:ResourceTag). När de matchar beviljas åtkomst. ABAC skalar utmärkt: Ni beviljar åtkomst efter tagg i stället för att skriva en ny policy för varje projekt, en modern bästa praxis som provet lyfter fram.

Kombinera dessa verktyg medvetet: använd conditions för att villkora åtkomst utifrån MFA, IP, TLS eller organisationstillhörighet; använd wildcards sparsamt och snävt; använd policy variables och tags för skalbar, principalspecifik åtkomst enligt principen om minsta privilegium. Tillsammans gör de det möjligt för en väl utformad policy att tillämpa exakt, kontextmedveten åtkomst för många identiteter och resurser.

Conditions styr när statements tillämpas utifrån context keys (aws:SourceIp, aws:SecureTransport, aws:MultiFactorAuthPresent, aws:PrincipalOrgID) med operatorer som StringLike och Bool. Wildcards (* och ?) gör policyer kortfattade men kan bevilja för bred åtkomst. Policy variables som ${aws:username} och taggbaserad ABAC ger skalbar, principalspecifik åtkomst enligt principen om minsta privilegium.