AWS IAM Access Control: Beleid, Rollen & Best Practices

AWS Identity and Access Management (IAM) is de dienst die authenticatie en autorisatie regelt voor elke API-aanroep naar uw AWS-omgeving. Het bepaalt wie kan inloggen, welke acties zij mogen uitvoeren en op welke resources — over elke AWS-dienst, in elke regio, voor elk account. IAM correct inrichten is niet optioneel; volgens AWS' eigen post-incidentanalyses zijn foutief geconfigureerde IAM-beleidsregels betrokken bij het merendeel van de cloud-beveiligingsinbreuken die publiekelijk bekend worden. Dit artikel behandelt de architectuur van IAM, de logica voor beleidsevaluatie, praktische patronen voor het opschalen van access control, en de operationele fouten die Opsio's SOC herhaaldelijk tegenkomt in honderden AWS-accounts.

Belangrijkste Inzichten

• AWS IAM is de fundamentele dienst voor het beheren van wie wat mag doen op elke AWS-resource, en foutieve IAM-configuraties zijn de meest voorkomende oorzaak van cloud-beveiligingsincidenten.
• Effectief IAM vereist het combineren van identity policies, resource policies, permission boundaries en Service Control Policies — niet alleen het koppelen van managed policies aan gebruikers.
• Organisaties die onder NIS2, AVG of DPDPA 2023 vallen, moeten IAM-configuratie behandelen als een compliancemaatregel, niet louter als operationeel gemak.
• ABAC (attribute-based access control) op basis van tags is inmiddels het aanbevolen schaalpatroon voor organisaties met meer dan een handvol accounts, maar de meeste teams kiezen standaard nog voor RBAC.
• De grootste IAM-fouten die Opsio's SOC onderzoekt zijn geen privilege escalations — het zijn verouderde credentials en te ruim geautoriseerde service-rollen die niemand reviewt.

Hoe AWS IAM Werkt: Het Kernmodel

IAM werkt op basis van een default-deny-model. Elke AWS API-aanvraag wordt geëvalueerd aan de hand van een reeks beleidsregels, en tenzij de evaluatie een expliciet Allow oplevert — zonder dat een Deny dit overschrijft — wordt de aanvraag afgewezen. Het begrijpen van deze evaluatieketen is het allerbelangrijkste concept in AWS access control.

Principals, Actions, Resources en Conditions

Elk IAM-beleidsstatement heeft vier componenten:

• Principal — de entiteit die de aanvraag doet (IAM-gebruiker, IAM-rol, gefedereerde identiteit, AWS-dienst)
• Action — de specifieke API-operatie (s3:GetObject, ec2:RunInstances, iam:CreateUser)
• Resource — de ARN('s) waarop de actie van toepassing is
• Condition — optionele beperkingen (bron-IP, MFA-status, tijdstip, resource-tags)

Een beleid is een JSON-document met één of meer statements, elk met een Effect van Allow of Deny. De kracht — en de complexiteit — komt voort uit de manier waarop meerdere beleidsregels samenwerken tijdens de evaluatie.

De Beleidsevaluatieketen

Wanneer een principal een aanvraag doet binnen een AWS Organization, verloopt de evaluatie in deze volgorde:

1. Service Control Policies (SCP's) — guardrails op organisatieniveau die de maximale permissies voor lidaccounts bepalen

2. Resource-based policies — gekoppeld aan de resource zelf (bijv. S3 bucket policies, KMS key policies)

3. IAM permission boundaries — de maximale permissies die een IAM-entiteit kan hebben, ongeacht diens identity policies

4. Session policies — meegegeven bij het aannemen van een rol, waarmee de sessie verder wordt beperkt

5. Identity-based policies — de beleidsregels die gekoppeld zijn aan de IAM-gebruiker, -groep of -rol

Een expliciet Deny op welk niveau dan ook overschrijft alle Allow-statements. Dit gelaagde model zorgt ervoor dat u organisatiebrede guardrails kunt afdwingen (via SCP's), zelfs als individuele accountbeheerders bredere toegang proberen te verlenen.

Dit begrijpen is geen theoretische exercitie — Opsio's NOC traceert regelmatig access-denied-fouten terug naar SCP-beperkingen waarvan accountbeheerders het bestaan niet kenden. Als u een 403 op een API-aanroep probeert te debuggen terwijl het identity policy duidelijk Allow zegt, controleer dan eerst de SCP's.

IAM-Bouwstenen in de Praktijk

IAM Users vs. IAM Roles vs. Gefedereerde Identiteiten

IAM-gebruikers zijn langlevende identiteiten met permanente credentials. Ze bestaan nog en werken nog, maar voor menselijke operators moeten ze als legacy worden beschouwd. AWS' huidige aanbeveling — en Opsio's operationele standpunt — is om menselijke toegang te federeren via IAM Identity Center (voorheen AWS SSO), dat tijdelijke credentials uitgeeft via SAML 2.0 of OIDC.

IAM-rollen zijn de werkpaarden van modern AWS IAM. Een rol heeft geen permanente credentials; in plaats daarvan nemen principals de rol aan en ontvangen tijdelijke beveiligingstokens (via AWS STS). Rollen worden gebruikt voor:

• Cross-account toegang (een workload in Account A neemt een rol aan in Account B)
• Service-to-service toegang (een EC2 instance profile, een Lambda execution role)
• Menselijke toegang via federatie (een rol aannemen na authenticatie via uw IdP)

Gefedereerde identiteiten authenticeren via een externe identity provider (Okta, Azure AD / Entra ID, Google Workspace) en nemen IAM-rollen aan. Dit is het patroon dat elke organisatie met meer dan tien engineers zou moeten gebruiken voor console- en CLI-toegang.

IAM-Beleid: Managed, Inline en Custom

AWS managed policies (bijv. ReadOnlyAccess, PowerUserAccess) worden onderhouden door AWS en dekken veelvoorkomende patronen. Ze zijn handig maar vaak te ruim voor productiegebruik. AdministratorAccess is het meest gekoppelde managed policy dat Opsio's SOC aantreft bij auditbevindingen — en het is vrijwel nooit gerechtvaardigd voor dagelijkse operaties.

Customer managed policies zijn de juiste standaardkeuze. Schrijf ze zelf, stem ze af op uw werkelijke workloads, versiebeheer ze in Git en deploy ze via Infrastructure as Code (Terraform, CloudFormation of CDK).

Inline policies worden direct in een gebruiker, groep of rol ingebed. Ze hebben een strikte 1:1-relatie. Gebruik ze alleen wanneer een beleid niet per ongeluk aan een andere entiteit mag worden gekoppeld — wat zelden voorkomt.

Service Control Policies (SCP's)

SCP's zijn de krachtigste — en meest verkeerd begrepen — laag in de IAM-stack. Ze verlenen géén permissies; ze definiëren de maximale grens van wat een principal in een lidaccount kan doen. Een SCP die s3:DeleteBucket ontzegt, betekent dat niemand in dat account een bucket kan verwijderen, zelfs met AdministratorAccess.

Praktische SCP-patronen die Opsio voor klanten uitrolt:

• Regiobeperkingen — alle acties weigeren buiten eu-west-1 (Ireland), eu-central-1 (Frankfurt) en ap-south-1 (ter handhaving van datasoevereiniteit voor AVG en DPDPA)
• Guardrail-SCP's — voorkomen dat CloudTrail wordt uitgeschakeld, VPC flow logs worden verwijderd of de audit-IAM-rol wordt gewijzigd
• Service deny-list — diensten blokkeren die de organisatie niet gebruikt (bijv. Lightsail, GameLift) om het aanvalsoppervlak te verkleinen

AWS-beveiligingsguardrails

RBAC vs. ABAC: Het Juiste Model Kiezen

RBAC (Role-Based Access Control)

RBAC in AWS betekent het aanmaken van afzonderlijke IAM-rollen per functie — DevOps-Engineer, Data-Analyst, Security-Auditor — en het koppelen van beleidsregels aan die rollen. Het is intuïtief en werkt goed wanneer:

• U minder dan circa 20 afzonderlijke rollen hebt
• Teams duidelijk gescheiden zijn
• Account-wildgroei beperkt is

Het nadeel is combinatorische explosie. Als u 5 functies hebt, 4 omgevingen (dev/staging/prod/sandbox) en 3 projecten, kunt u 60 roldefinities nodig hebben — elk met eigen beleidsregels.

ABAC (Attribute-Based Access Control)

ABAC gebruikt tags op zowel principals als resources om autorisatiebeslissingen te nemen. In plaats van 60 rollen schrijft u een kleiner aantal beleidsregels met condities zoals:

```json

"Condition": {

"StringEquals": {

"aws:ResourceTag/Project": "${aws:PrincipalTag/Project}",

"aws:ResourceTag/Environment": "${aws:PrincipalTag/Environment}"

}

}

```

Hiermee kan een ontwikkelaar met tags Project=payments, Environment=dev alleen de resources benaderen die dezelfde tags dragen — zonder project- of omgevingsspecifieke rollen aan te maken.

De IAM-documentatie van AWS beveelt ABAC expliciet aan als het voorkeursmodel voor opschaling. In de praktijk hanteren de meeste organisaties die Opsio beheert een hybride aanpak: RBAC voor brede functiescheiding, ABAC voor fijnmazige resourceafbakening binnen die rollen.

Het operationele aandachtspunt: ABAC werkt alleen als uw tagging-discipline op orde is. Als teams resources niet consistent taggen, falen de condities op onvoorspelbare manieren — te open of te gesloten. Dwing tagging af met SCP's en AWS Config-regels voordat u op ABAC inzet.

tag-governance en FinOps

IAM Best Practices: Wat Er Werkelijk Toe Doet

Het AWS Well-Architected Framework's Security Pillar definieert IAM best practices over vijf gebieden. Hier is wat wij in de praktijk het belangrijkst zien — geen theorie:

1. Elimineer Langlevende Access Keys

Elke access key is een credential die kan worden buitgemaakt. Opsio's SOC heeft incidenten onderzocht waarbij access keys gecommit naar publieke GitHub-repositories binnen minuten werden misbruikt door geautomatiseerde scanners. De oplossing:

• Gebruik IAM-rollen met tijdelijke credentials voor alle workloads (EC2 instance profiles, ECS task roles, Lambda execution roles)
• Federeer menselijke toegang via IAM Identity Center
• Dwing voor de zeldzame gevallen waarin access keys onvermijdelijk zijn (legacy-integraties) rotatie af via de AWS Config-regel access-keys-rotated met een maximale leeftijd van 90 dagen

2. Dwing MFA Af — Overal Waar Het Ertoe Doet

MFA op het root-account is een basisvereiste. Maar dwing MFA ook af voor:

• Alle menselijke IAM-gebruikers (als u ze nog hebt)
• Het aannemen van gevoelige rollen (iam:AssumeRole met Condition: { "Bool": { "aws:MultiFactorAuthPresent": "true" }})
• De IAM Identity Center-authenticatiestroom (pushnotificatie-MFA, geen SMS)

3. Pas Least Privilege Iteratief Toe

Niemand krijgt least privilege in één keer goed. De praktische aanpak:

1. Begin met AWS managed policies die iets ruimer zijn dan nodig

2. Schakel IAM Access Analyzer in om te monitoren welke permissies daadwerkelijk worden gebruikt

3. Genereer na 30-90 dagen een least-privilege-beleid op basis van CloudTrail-toegangsactiviteit

4. Vervang het ruime beleid door het gegenereerde beleid

5. Herhaal dit elk kwartaal

De beleidsgeneratiefunctie van IAM Access Analyzer is oprecht nuttig en wordt te weinig benut. Het leest CloudTrail-logs en produceert een afgebakend beleid dat alleen overeenkomt met de acties en resources die daadwerkelijk zijn aangeroepen.

4. Gebruik Permission Boundaries voor Gedelegeerd Beheer

Als u ontwikkelaars of teamleads toestaat IAM-rollen aan te maken (bijv. voor Lambda-functies), stel dan een permission boundary in die begrenst wat die aangemaakte rollen kunnen doen. Zonder dit kan een ontwikkelaar een rol aanmaken met AdministratorAccess — wat een privilege-escalatiepad is.

5. Audit Continu, Niet Jaarlijks

Een jaarlijkse IAM-review is een afvinkexercitie. Doe in plaats daarvan het volgende:

• Draai IAM Access Analyzer continu om externe en ongebruikte toegang te detecteren
• Monitor afwijkende IAM API-aanroepen via CloudTrail + Amazon GuardDuty
• Gebruik AWS Config-regels om niet-conforme IAM-configuraties automatisch te signaleren
• Stuur bevindingen naar een centraal SIEM of de alertingpipeline van uw SOC

24/7 SOC-monitoring

IAM in een Multi-Account AWS Organization

Enkelvoudige AWS-omgevingen zijn in productie steeds zeldzamer. AWS Organizations, gecombineerd met IAM Identity Center, is het standaardpatroon voor het beheren van toegang over tientallen of honderden accounts.

IAM Identity Center (Voorheen AWS SSO)

IAM Identity Center biedt één centraal punt om menselijke toegang over alle accounts in uw organisatie te beheren. Gebruikers authenticeren éénmalig (via uw bedrijfs-IdP of de ingebouwde directory) en ontvangen tijdelijke credentials voor het account en de permission set die zij selecteren.

Permission sets in IAM Identity Center zijn abstracties die IAM-rollen aanmaken in elk doelaccount. U definieert ze eenmalig centraal en wijst ze per account toe aan gebruikers of groepen. Dit is aanzienlijk eenvoudiger dan het onafhankelijk beheren van IAM-rollen in elk account.

Cross-Account Role Assumption

Voor service-to-service toegang over accounts heen (bijv. een CI/CD-pipeline in het tooling-account die deployt naar productie) is het patroon:

1. Maak een rol aan in het doelaccount met een trust policy die de rol van het bronaccount toestaat

2. De bron-workload roept sts:AssumeRole aan om tijdelijke credentials te verkrijgen

3. Gebruik external ID's om confused-deputy-aanvallen te voorkomen wanneer derde partijen betrokken zijn

Opsio configureert cross-account toegang via een hub-and-spoke-model: een centraal beveiligingsaccount bevat audit-rollen die kunnen lezen (maar niet schrijven) in alle lidaccounts. Dit ontwerp ondersteunt zowel SOC-operaties als het verzamelen van compliancebewijs.

multi-accountstrategie

Compliancedimensies: NIS2, AVG en DPDPA 2023

IAM-configuratie wordt direct aangehaald in elk belangrijk complianceframework dat Opsio tegenkomt:

NIS2-richtlijn (EU) — Artikel 21 vereist "beleid inzake toegangscontrole" inclusief beheer van geprivilegieerde toegang. Organisaties die als essentiële of belangrijke entiteiten zijn geclassificeerd, moeten aantonen dat IAM-maatregelen in verhouding staan tot het risico, dat geprivilegieerde toegang wordt gemonitord en dat toegangsreviews regelmatig worden uitgevoerd. Voor de Nederlandse markt is hierbij ook afstemming met de Autoriteit Persoonsgegevens relevant. In AWS vertaalt dit zich naar SCP's, CloudTrail, IAM Access Analyzer en gedocumenteerde toegangsreviewprocedures.

AVG (GDPR) — Artikel 32 vereist "het vermogen om de voortdurende vertrouwelijkheid, integriteit, beschikbaarheid en veerkracht van verwerkingssystemen en -diensten te waarborgen," wat door toezichthouders — waaronder de Autoriteit Persoonsgegevens — wordt geïnterpreteerd als inclusief identiteits- en toegangsbeheer. Verwerkingsverantwoordelijken moeten aantonen dat toegang tot persoonsgegevens beperkt is tot personeel dat deze nodig heeft — wat betekent dat IAM-beleidsregels specifiek moeten worden afgebakend tot bepaalde DynamoDB-tabellen, S3-prefixes of RDS-instanties die persoonsgegevens bevatten.

DPDPA 2023 (India) — Sectie 8-verplichtingen voor data fiduciaries omvatten het implementeren van "redelijke beveiligingsmaatregelen." Voor Indiase bedrijven die workloads draaien in ap-south-1 (Mumbai) of ap-south-2 (Hyderabad) betekent dit gedocumenteerde IAM-maatregelen, audit trails en bewijs van periodieke review — vergelijkbaar in strekking met de vereisten van Artikel 32 AVG.

De rode draad: alle drie de frameworks vereisen niet alleen dat maatregelen bestaan, maar dat ze worden gemonitord en gereviewed. IAM-configuratie zonder CloudTrail-logging en periodieke toegangsreview voldoet aan geen van alle.

Veelvoorkomende IAM-Fouten Die Opsio's SOC Tegenkomt

Gebaseerd op daadwerkelijke incidenten en auditbevindingen over onze beheerde accounts:

1. Wildcard resource-ARN's in productiebeleid — "Resource": "*" is acceptabel tijdens prototyping. In productie betekent het dat een gecompromitteerde principal toegang heeft tot elke resource van dat type in het account.

2. Service-rollen met AdministratorAccess — Lambda-functies en ECS-taken moeten nauwkeurig afgebakende execution roles hebben. Admin-toegang toekennen "omdat het makkelijker is" maakt van elke applicatiekwetsbaarheid een volledige accountcompromittering.

3. Geen SCP-guardrails op lidaccounts — Zonder SCP's kan elke accountbeheerder zichzelf alles toekennen. SCP's zijn het enige mechanisme dat zelfs de account-rootgebruiker beperkt (in lidaccounts).

4. Verouderde IAM-gebruikers en access keys — We treffen routinematig IAM-gebruikers aan voor medewerkers die maanden of jaren geleden de organisatie hebben verlaten. Gebruik de AWS Config-regel iam-user-unused-credentials-check en stel deze in op signalering bij credentials die 45 dagen niet zijn gebruikt.

5. Resource-based policies negeren — S3 bucket policies, KMS key policies en SQS queue policies kunnen onafhankelijk van identity policies toegang verlenen. Een S3-bucket met "Principal": "*" in het bucket policy is publiekelijk toegankelijk, ongeacht hoe strak uw IAM-rollen zijn geconfigureerd.

Aan de Slag: Een Praktische Volgorde

Voor organisaties die IAM-governance nog niet hebben geformaliseerd, is dit de volgorde die het snelst resultaat oplevert:

1. Schakel CloudTrail in in alle accounts, alle regio's, met logging naar een gecentraliseerde S3-bucket in een log-archiefaccount

2. Schakel IAM Access Analyzer in in elk account (het is gratis)

3. Migreer menselijke toegang van IAM-gebruikers naar IAM Identity Center met MFA

4. Deploy basis-SCP's — weiger ongebruikte regio's, bescherm audit-infrastructuur, vereist versleuteling

5. Audit bestaande IAM-rollen en -beleidsregels — gebruik de bevindingen van Access Analyzer om ongebruikte rollen en te ruim geconfigureerde beleidsregels te identificeren

6. Implementeer Infrastructure as Code voor alle IAM-resources — geen ClickOps meer in de IAM-console

cloudmigratie en modernisering

Deze volgorde werkt of u nu 2 accounts hebt of 200. Het verschil zit in hoe lang stap 5 duurt.

Veelgestelde Vragen

Wat zijn IAM access controls?

IAM access controls zijn de beleidsregels, rollen en mechanismen binnen AWS Identity and Access Management die bepalen welke principals (gebruikers, rollen, diensten) welke acties mogen uitvoeren op welke resources. Ze werken op basis van een default-deny-model: tenzij een beleid een actie expliciet toestaat, wordt deze geweigerd. Controls omvatten identity-based policies, resource-based policies, permission boundaries, session policies en Service Control Policies op organisatieniveau.

Is IAM RBAC of ABAC?

AWS IAM ondersteunt beide. Role-based access control (RBAC) wordt gerealiseerd door IAM-rollen aan te maken met specifieke permissiesets en deze toe te wijzen aan gebruikers of groepen. Attribute-based access control (ABAC) gebruikt tags op principals en resources om dynamische autorisatiebeslissingen te nemen. AWS beveelt ABAC aan voor opschaling over meerdere accounts, omdat het het aantal benodigde afzonderlijke beleidsregels vermindert. De meeste productieomgevingen gebruiken een hybride van beide.

Wat is IAM-toegang in AWS?

IAM-toegang in AWS verwijst naar het geauthenticeerde en geautoriseerde vermogen van een principal — een IAM-gebruiker, gefedereerde identiteit of IAM-rol — om te communiceren met AWS-diensten en -resources. Elke API-aanroep naar AWS wordt geëvalueerd aan de hand van IAM-beleidsregels. Toegang wordt alleen verleend wanneer van toepassing zijnde beleidsregels een expliciet Allow opleveren en geen enkel beleid een expliciet Deny produceert.

Wat zijn de 4 pijlers van IAM?

De vier pijlers die vaak worden aangehaald in identiteitsbeheer zijn: authenticatie (bewijzen wie je bent), autorisatie (wat je mag doen), administratie (identiteiten en beleidsregels op schaal beheren) en auditing (loggen en reviewen van toegangsactiviteit). In AWS-termen vertalen deze zich naar IAM-authenticatiemechanismen, IAM-beleidsregels, AWS Organizations/IAM Identity Center en AWS CloudTrail.

Hoe verhoudt AWS IAM zich tot NIS2-compliance?

NIS2 vereist dat essentiële en belangrijke entiteiten toegangsbeleid implementeren dat in verhouding staat tot het risico, incidentresponsecapaciteiten onderhouden en verantwoording afleggen over geprivilegieerde toegang. AWS IAM biedt de technische maatregelen — MFA, least-privilege-beleid, SCP's, CloudTrail-logging — maar compliance vereist gedocumenteerde processen, periodieke toegangsreviews en bewijs dat deze maatregelen actief worden bewaakt. Een managed SOC kan de kloof overbruggen tussen het hebben van de maatregelen en het bewijzen dat ze werken.