AWS IAM zonder hoofdpijn: een praktische gids
IAM is het onderdeel van AWS dat iedereen te laat serieus neemt. Je rolt een account uit, geeft jezelf admin, en zes maanden later heeft elke developer zijn eigen access key en heeft de CI-pipeline een user met PowerUserAccess. Dan gaat er iets mis en begin je van voor af aan.
Dit artikel legt het IAM-mentale model uit en geeft concrete regels die je direct kunt toepassen.
Het mentale model: vier objecten
IAM draait om vier concepten die je in volgorde moet begrijpen.
Users zijn menselijke of machine-identiteiten met een naam in IAM. Ze kunnen een wachtwoord hebben (voor de console) en access keys (voor de CLI of API). In een goed opgezet account heb je minimale IAM users. Mensen loggen in via SSO (Identity Center), machines via roles.
Groups zijn verzamelingen users waaraan je policies koppelt. Handig voor handmatig beheer, maar als je SSO gebruikt via Identity Center verliest het grotendeels zijn nut.
Roles zijn de kern van hoe je access regelt in productie. Een role heeft geen wachtwoord en geen access key. Hij werkt via tijdelijke credentials (STS). Een EC2-instance neemt een role aan, een Lambda-functie neemt een role aan, een developer die via Identity Center inlogt neemt een role aan. Alles is een role.
Policies zijn JSON-documenten met statements die access verlenen of weigeren. Ze koppel je aan users, groups of roles.
Waarom roles voor alles in productie
Access keys zijn statisch. Ze verlopen niet tenzij je ze handmatig roteert. Ze lekken via git, via logs, via gedeelde scripts. In 2024 waren gelekte access keys nog steeds een van de meest voorkomende oorzaken van AWS-beveiligingsincidenten.
Roles werken met tijdelijke credentials via STS: standaard 1 uur geldig, maximaal 12 uur. Een gelekte tijdelijke credential is een klein probleem. Een gelekte access key is een groot probleem.
De regel is simpel: geen access keys in productie. Als een applicatie of service AWS-resources nodig heeft, geef je hem een role. Als een developer toegang nodig heeft, gebruik je Identity Center met permission sets (die ook roles zijn, onder de motorkap).
Permission boundaries versus SCPs
Dit is het stuk waar de meeste mensen het spoor bijster raken.
SCPs (Service Control Policies) werken op het niveau van je AWS Organizations-structuur. Je koppelt ze aan organizational units of accounts. Ze zetten een maximum op wat een identiteit in dat account kan doen, ongeacht welke policies die identiteit heeft. Een SCP is een plafond, geen vloer. Hij geeft niets toe; hij beperkt alleen.
Permission boundaries werken op het niveau van een individuele IAM-entiteit (user of role). Je zet een boundary op een role, en die role kan nooit meer doen dan wat de boundary toestaat, ook al heeft de role policies die meer zouden geven. Handig als je developers zelf roles wil laten aanmaken binnen een veilig kader.
In de praktijk: SCPs voor account-brede guardrails (bijv. “niemand mag resources buiten eu-west-1 aanmaken”), permission boundaries voor gedelegeerd rolbeheer.
AWS managed versus customer-managed policies
AWS levert kant-en-klare policies zoals AmazonS3ReadOnlyAccess en PowerUserAccess. Ze zijn handig om mee te beginnen, maar in productie wil je ze niet direct gebruiken.
AWS kan de inhoud van managed policies wijzigen zonder aankondiging. Als AmazonEC2FullAccess morgen een nieuwe actie bevat die je niet wil toestaan, heb je een probleem.
Customer-managed policies zijn policies die je zelf definieert en beheert. Ze staan onder versiebeheer, je weet precies wat erin zit, en wijzigingen ga je bewust aan. Gebruik AWS managed policies als startpunt voor inspiratie, kopieer de relevante statements naar je eigen policy, en beheer het zelf.
IAM Access Analyzer: vind wat je niet gebruikt
Access Analyzer heeft twee functies die het waard zijn.
Unused access analysis laat zien welke permissions een role in de afgelopen 90 dagen niet heeft gebruikt. Als een Lambda-role s3:DeleteObject heeft maar die actie nooit heeft aangeroepen, staat die in de unused-lijst. Dat is een directe aanwijzing om de policy te verkleinen.
External access findings laat zien welke resources van buiten je account bereikbaar zijn: S3-buckets met een bucket policy die publiek staat, KMS-keys die met andere accounts gedeeld worden, enzovoort.
Zet Access Analyzer aan in elke regio die je gebruikt. Het is gratis voor de basic findings. De unused access analysis kost iets, maar voor de meeste accounts is dat marginaal.
Wil je IAM van de grond af leren? Bekijk het aanbod van AWS security-trainingen voor cursussen die verder gaan dan de theorie.
Drie regels om vandaag toe te passen
Als je nu een AWS-account beheert dat organisch is gegroeid:
- Inventariseer alle access keys via IAM > Users > filter op “has access key”. Zet een deadline: alle keys die ouder zijn dan 90 dagen worden geroteerd of verwijderd.
- Schakel IAM Access Analyzer in. Bekijk de external access findings als eerste prioriteit.
- Maak een policy-naamgevingsconventie:
<team>-<resource>-<access-level>, bijv.data-s3-readonly. Zo zie je in een overzicht direct wat iets doet.
IAM is geen eenmalige taak. Plan elke drie maanden een half uur in om de unused access findings door te lopen en policies bij te schaven.