Anatomie van een IAM-policydocument

In AWS worden machtigingen uitgedrukt in beleidsregels: JSON-documenten die toegang tot acties op resources verlenen of weigeren. Een beleidsregel vloeiend kunnen lezen is een essentiële SCS-C02-vaardigheid, omdat vrijwel elke toegangsvraag neerkomt op wat een beleidsregel toestaat, weigert of niet afdekt. In deze les ontleden we de structuur stap voor stap.

Een beleidsregel bevat een veld Version (gebruik "2012-10-17") en een element Statement, dat uit één instructie of een array met instructies bestaat. Elke instructie is een onafhankelijke regel. AWS evalueert elke instructie, zodat één document sommige acties kan toestaan en andere expliciet kan weigeren.

Elke instructie heeft een Effect van Allow of Deny. AWS weigert standaard: zonder overeenkomende Allow wordt een verzoek geweigerd. Een overeenkomende Deny wint altijd van Allow. Het herkennen van het Effect van elke instructie is het eerste wat u moet controleren bij het beoordelen van toegang.

Het element Action vermeldt de API-bewerkingen waarop de instructie van toepassing is, geschreven als service:bewerking, bijvoorbeeld s3:GetObject. Jokertekens zijn toegestaan, zoals s3:* of s3:Get*. Het tegenovergestelde, NotAction, komt overeen met elke actie behalve de vermelde acties en is eenvoudig verkeerd te gebruiken. Daarom toetst het examen dit zorgvuldig.

Het element Resource benoemt op welke resources de acties van toepassing zijn, met behulp van ARN's (Amazon Resource Names). Bijvoorbeeld een specifieke bucket en de objecten daarin. De waarde "*" betekent alle resources. NotResource komt overeen met alles behalve de vermelde ARN's. Het bereik van resources strikt beperken is essentieel voor minimale machtigingen.

Deze identiteitsbeleidsregel staat alleen het lezen van objecten uit één bucket toe. Let op de actie, de specifieke ARN op objectniveau en het expliciete Allow-effect.

Een optioneel blok Condition beperkt wanneer een instructie van toepassing is, met behulp van contextsleutels en operators. U kunt bijvoorbeeld alleen toegang toestaan als het verzoek TLS gebruikt (aws:SecureTransport) of afkomstig is van een bekend IP-adres. Met voorwaarden voegt u fijnmazige, contextafhankelijke controle toe die verder gaat dan alleen actie en resource.

Identiteitsgebaseerde beleidsregels laten het element Principal weg, omdat ze al aan een principal zijn gekoppeld. Resourcegebaseerde beleidsregels, zoals een S3-bucketbeleidsregel, bevatten Principal om aan te geven op wie de regel van toepassing is. Als u ziet of een beleidsregel een Principal bevat, weet u welk type u leest.

Jokertekens zoals "Action": "*" en "Resource": "*" verlenen samen volledige beheerderstoegang. Het examen toont vaak een beleidsregel met te ruime machtigingen en vraagt u deze aan te scherpen. Vervang de jokertekens door specifieke acties en ARN's en pas minimale machtigingen toe.

Een ARN heeft de vorm arn:partition:service:region:account:resource. Sommige services laten de regio of het account weg; S3 laat beide weg voor het bucketgedeelte. Als u ARN's nauwkeurig leest, kunt u bepalen of een beleidsregel gericht is op één resource, één account of alles. Dat heeft direct invloed op de hoeveelheid verleende toegang.

Analyseer elke beleidsregel als volgt: controleer het Effect, lees de Action (let op NotAction en jokertekens), beperk het bereik van de Resource (let op "*") en controleer eventuele Condition-elementen. Onthoud dat een expliciete weigering wint van toestaan en dat weigeren de standaard is. Met oefening kunt u binnen enkele seconden bepalen hoe ver de daadwerkelijke toegang van een beleidsregel reikt, precies wat het examen vereist.

Een IAM-beleidsregel is JSON met een Version en een Statement-array. Elke instructie heeft een Effect (Allow/Deny), Action (of NotAction), Resource via ARN's (of NotResource) en een optionele Condition. Resourcegebaseerde beleidsregels voegen een Principal toe. Weigeren is de standaard, een expliciete weigering wint altijd en jokertekens wijzen op te ruime machtigingen die moeten worden beperkt.