AWS-misconfiguraties zijn configuratie-, eigenaarschaps- en controleproblemen die cloudrisico’s creëren wanneer ze niet hetzelfde tempo volgen als de omgeving zelf, ondanks de krachtige beveiligingsdiensten die AWS biedt.
Amazon Web Services (AWS) werkt volgens het Shared Responsibility-model: AWS beveiligt de onderliggende cloudinfrastructuur, terwijl de klant verantwoordelijk blijft voor onder meer identiteit, dataclassificatie, netwerktoegang, logging, workloadconfiguratie en toegangsbeleid. Voor Belgische organisaties komt daar een extra laag bij, omdat GDPR en NIS2 niet vragen om één technische instelling, maar om aantoonbare beheersing van risico’s, incidentrespons, logging, continuïteit en toegang tot gevoelige data.
De zeven problemen hieronder zijn daarom geen theoretische lijst. Het zijn configuratiefouten die in AWS-accounts vaak ongemerkt meegroeien met teams, automatisering en tijdelijke uitzonderingen. De rode draad is dat beveiliging niet alleen achteraf moet detecteren wat misging, maar al bij provisioning moet voorkomen dat risicovolle keuzes mogelijk zijn.
1. Te brede IAM-rechten en langlevende access keys
Identity and Access Management (IAM) is een van de belangrijkste controlevlakken in AWS. Wanneer gebruikers, rollen of policies te brede rechten krijgen, wordt een kleine fout snel een groot incident. Policies met Action: "*" en Resource: "*" lijken handig tijdens ontwikkeling, maar maken het moeilijk om later te bewijzen wie werkelijk welke rechten nodig heeft.
Een tweede risico is het gebruik van langlevende access keys voor mensen, scripts of externe tools. Sleutels die buiten AWS terechtkomen, bijvoorbeeld in een repository, lokaal profiel of buildlog, blijven bruikbaar tot ze worden ingetrokken. In veel omgevingen is het veiliger om menselijke toegang via AWS IAM Identity Center te regelen en workloads tijdelijke credentials te laten gebruiken via rollen en AWS Security Token Service (STS).
De praktische best practice is om least privilege niet als een eenmalige opschoonactie te behandelen. Gebruik managed policies waar ze passen, beperk custom policies tot concrete acties en resources, en evalueer periodiek ongebruikte rechten met IAM Access Analyzer. Policy boundaries kunnen helpen om ontwikkelteams autonomie te geven zonder dat zij buiten afgesproken grenzen kunnen gaan.
Deze auditcommand toont welke IAM-gebruikers access keys hebben. Het commando wijzigt niets en is geschikt als eerste inventarisatie.
Example — access keys per IAM-gebruiker inventariseren
aws iam list-users --query 'Users[].UserName' --output text | tr '\t' '\n' | while read user; do
aws iam list-access-keys --user-name "$user" \
--query 'AccessKeyMetadata[].{User:`'$user'`,AccessKeyId:AccessKeyId,Status:Status,Created:CreateDate}' \
--output table
done
De uitkomst is geen volledige risicobeoordeling, maar wel een startpunt. Let vooral op actieve sleutels voor menselijke accounts, oude sleutels zonder duidelijke eigenaar en accounts die eigenlijk via federatie of rollen zouden moeten werken.
2. Publieke S3-buckets en onbedoeld gedeelde data
S3 is robuust, maar de beveiliging valt of staat met bucketbeleid, objectrechten, accountinstellingen en dataclassificatie. Een bucket kan onbedoeld publiek worden door een permissieve bucket policy, oude ACL’s, replicatie-instellingen of een uitzondering die ooit tijdelijk bedoeld was. Voor organisaties met persoonsgegevens of bedrijfsgevoelige data is dit direct relevant voor GDPR, omdat toegang, encryptie, logging en bewaartermijnen aantoonbaar moeten zijn.
De eerste verdedigingslaag is S3 Block Public Access op account- en bucketniveau. Daarna volgen versleuteling met AWS Key Management Service (KMS), duidelijke bucket policies, server access logging of CloudTrail data events waar nodig, en lifecyclebeleid dat aansluit op bewaartermijnen. Een veelgemaakte fout is alleen naar de bucketnaam kijken; objectniveau, cross-account policies en oude ACL’s verdienen dezelfde aandacht.
Met deze veilige read-only check ziet u of Block Public Access op accountniveau is ingesteld. Het account-id wordt dynamisch opgehaald, zodat er geen harde waarde in het commando hoeft te staan.
Example — S3 Block Public Access controleren
ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
aws s3control get-public-access-block --account-id "$ACCOUNT_ID"
Als deze instelling ontbreekt of niet volledig is ingeschakeld, betekent dat niet automatisch dat data publiek staat. Het betekent wel dat een belangrijke preventieve guardrail ontbreekt. In volwassen omgevingen wordt deze instelling centraal afgedwongen, zodat individuele teams haar niet per ongeluk kunnen omzeilen.
3. Open security groups, inclusief vergeten IPv6-regels
Security groups worden vaak snel aangepast om een deployment of troubleshooting te versnellen. Het bekende risico is inbound toegang vanaf 0.0.0.0/0, maar IPv6 wordt regelmatig over het hoofd gezien. Een regel met ::/0 kan dezelfde brede blootstelling veroorzaken voor resources met IPv6-connectiviteit, ook wanneer het IPv4-beleid strenger lijkt.
De juiste aanpak hangt af van de workload. Publieke webendpoints horen meestal achter een load balancer, met beperkte poorten en aanvullende bescherming via AWS WAF waar relevant. Beheerpoorten zoals SSH en RDP horen niet breed open te staan; gebruik liever AWS Systems Manager Session Manager, bastionpatronen met strikte toegang, of VPN- en zero-trustoplossingen.
Deze audit zoekt naar security group-regels die inbound verkeer vanaf het volledige IPv4- of IPv6-internet toestaan. Het commando brengt alleen configuratie in beeld en past niets aan.
Example — brede inbound security group-regels vinden
aws ec2 describe-security-groups \
--query 'SecurityGroups[?IpPermissions[?IpRanges[?CidrIp==`0.0.0.0/0`] || Ipv6Ranges[?CidrIpv6==`::/0`]]].{GroupId:GroupId,GroupName:GroupName,VpcId:VpcId}' \
--output table
De prioriteit ligt bij regels die toegang geven tot beheerpoorten, databases, message brokers en interne applicaties. Een poort die bewust publiek is, moet nog steeds een eigenaar, logging, monitoring en duidelijke rechtvaardiging hebben.
4. Onvolledige logging en detectie
Zonder consistente logging wordt incidentrespons giswerk. CloudTrail, AWS Config, GuardDuty en Security Hub vullen elkaar aan: CloudTrail registreert API-activiteiten, Config bewaakt configuratiewijzigingen, GuardDuty detecteert verdacht gedrag en Security Hub brengt bevindingen uit meerdere standaarden samen, waaronder AWS Foundational Security Best Practices. De CIS Benchmarks en de AWS Well-Architected Security Pillar bieden nuttige referentiepunten om te bepalen welke controles minimaal verwacht mogen worden.
Voor Belgische en Europese organisaties is logging ook een governancevraag. GDPR vereist passende beveiligingsmaatregelen en incidentbeheersing; NIS2 legt extra nadruk op risicomanagement, continuïteit en melding van incidenten voor organisaties die onder het toepassingsgebied vallen. Dat betekent niet dat het inschakelen van één AWS-service compliance oplevert, maar wel dat centrale logging, bewaartermijnen, toegang tot logs en integriteit van logbestanden aantoonbaar geregeld moeten zijn.
Een praktische aanpak is om CloudTrail organisatiebreed in te richten, logs naar een apart beveiligingsaccount te sturen, logbestanden met KMS te versleutelen en wijzigingen aan logging zelf te alarmeren. In multi-accountomgevingen voorkomt dit dat elk team zijn eigen interpretatie van logging hanteert.
Deze controle laat zien welke trails aanwezig zijn in de actieve regio. Voor een volledige beoordeling moet ook worden nagegaan of organization trails, multi-region logging en log file validation zijn ingeschakeld.
Example — CloudTrail-configuratie bekijken
aws cloudtrail describe-trails --include-shadow-trails \
--query 'trailList[].{Name:Name,HomeRegion:HomeRegion,IsMultiRegion:IsMultiRegionTrail,LogValidation:LogFileValidationEnabled}' \
--output table
Als trails per account en per regio verschillen, ontstaat meestal een detectiegat. Het risico is groter wanneer dezelfde omgeving gevoelige data verwerkt of externe toegangspaden heeft.
5. Publieke snapshots en AMI’s die buiten beeld blijven
Een onderschat probleem is het per ongeluk delen van EBS-snapshots, RDS-snapshots of AMI’s. Teams controleren vaak S3 en security groups, maar vergeten opslagartefacten die na migraties, tests of incidentonderzoek zijn blijven bestaan. Een gedeelde snapshot kan gevoelige data bevatten, zelfs wanneer de oorspronkelijke database of instance inmiddels is verwijderd.
In een praktijkcase bij een cloudmigratie werd een tijdelijke database-snapshot gedeeld met een extern account voor troubleshooting. De share bleef actief nadat het project was afgerond. De belangrijkste les is dat tijdelijke uitzonderingen een einddatum, eigenaar en detectieregel nodig hebben; anders worden ze onderdeel van de permanente aanvalsvlakte.
Deze read-only controle toont EBS-snapshots in het account waarvoor create volume permissions publiek zijn gezet. Dezelfde denkwijze moet ook worden toegepast op RDS-snapshots en AMI launch permissions.
Example — publieke EBS-snapshots detecteren
aws ec2 describe-snapshots --owner-ids self \
--query 'Snapshots[?CreateVolumePermissions[?Group==`all`]].{SnapshotId:SnapshotId,StartTime:StartTime,Description:Description}' \
--output table
Wanneer publieke of cross-account shares worden gevonden, hoort de beoordeling te beginnen met datagevoeligheid en blast radius. Een snapshot met persoonsgegevens of productiegegevens vraagt een andere urgentie dan een lege testdisk, maar beide moeten verklaarbaar zijn.
6. Encryptie zonder goed sleutelbeheer
Encryptie is pas effectief wanneer sleutelbeheer, toegangsbeleid en operationele procedures kloppen. Veel AWS-diensten ondersteunen encryptie met AWS KMS, maar de keuze tussen AWS-managed keys en customer managed keys heeft gevolgen voor auditbaarheid, scheiding van taken en toegang door andere accounts. Vooral in gereguleerde omgevingen is het belangrijk te weten wie sleutels mag gebruiken, wie ze mag beheren en hoe sleutelgebruik wordt gelogd.
Voor dataresidentie en GDPR is encryptie geen vervanging voor dataclassificatie of locatiekeuzes. Teams moeten weten in welke regio data wordt opgeslagen, welke replicatie is geactiveerd, hoe back-ups worden bewaard en welke derde partijen toegang kunnen krijgen. In België is dit vaak een gesprek tussen security, legal, procurement en platformteams, niet alleen een vinkje in de console.
Een sterke basis bestaat uit standaardversleuteling voor S3, EBS, RDS en logopslag, beperkte KMS key policies, rotatie waar passend, en alerting op ongebruikelijke sleutelactiviteiten. Daarbij is het verstandig om sleutelbeheer niet te versnipperen over tientallen accounts zonder centrale richtlijnen.
7. Geen schaalbare guardrails in multi-accountomgevingen
Wat in één AWS-account beheersbaar lijkt, wordt in een multi-accountomgeving snel inconsistent. Nieuwe accounts, tijdelijke sandboxen, CI/CD-rollen en projectteams kunnen allemaal eigen uitzonderingen introduceren. Zonder centrale guardrails verschuift beveiliging naar handmatige reviews achteraf, en die houden zelden gelijke tred met provisioning.
AWS Organizations, Control Tower en Service Control Policies (SCP’s) helpen om grenzen op organisatieniveau af te dwingen. Denk aan het blokkeren van publieke S3-instellingen, het beperken van regio’s, het verplichten van centrale logging of het voorkomen dat accounts CloudTrail uitschakelen. SCP’s verlenen zelf geen rechten, maar bepalen de maximale ruimte waarbinnen accountrechten kunnen werken.
Deze voorbeeld-SCP illustreert hoe het uitschakelen van Block Public Access kan worden geweigerd. Gebruik dit niet blind in productie; test beleid altijd in een aparte organizational unit en controleer of bestaande automatisering niet onverwacht wordt geraakt.
Example — SCP die het aanpassen van S3 Block Public Access beperkt
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyChangingAccountPublicAccessBlock",
"Effect": "Deny",
"Action": [
"s3:DeleteAccountPublicAccessBlock",
"s3:PutAccountPublicAccessBlock"
],
"Resource": "*"
}
]
}
Guardrails werken het best wanneer ze worden gecombineerd met infrastructure as code-controles. Tools zoals cfn-nag, Checkov of Open Policy Agent kunnen CloudFormation, Terraform of Kubernetes-manifesten beoordelen voordat ze worden uitgerold. AWS Config kan daarna drift detecteren wanneer de werkelijke omgeving afwijkt van de gewenste staat.
Van snelle fixes naar structurele beveiliging
Niet elk risico verdient dezelfde prioriteit. Een bruikbaar besliskader is om per bevinding te kijken naar preventie, detectie en respons, en de prioriteit te bepalen op basis van datagevoeligheid en blast radius. Een publieke opslaglocatie met persoonsgegevens en externe toegang vraagt sneller actie dan een interne testresource zonder gevoelige data, ook als beide als “high” in een tool verschijnen.
In de eerste dagen leveren enkele acties vaak veel risicoreductie op: root-account controleren en beveiligen, ongebruikte access keys verwijderen, S3 Block Public Access afdwingen, brede security group-regels beoordelen, CloudTrail en GuardDuty centraal inschakelen, en publieke snapshots controleren. Daarna hoort de focus te verschuiven naar organisatiebrede standaarden, zoals account vending, SCP’s, centrale logarchieven, KMS-richtlijnen en policy-as-code in de deployment pipeline.
Readynez behandelt AWS-beveiliging in trainingscontexten vanuit die praktische volgorde: eerst voorkomen waar dat kan, dan detecteren wat afwijkt, en vervolgens responsprocessen oefenen. Die volgorde sluit aan bij hoe cloudteams risico in echte omgevingen moeten verkleinen zonder elke release handmatig te blokkeren.
Een korte zelftest voor uw AWS-omgeving
Deze zelftest is bedoeld als snelle oriëntatie, niet als volledige audit. De vragen helpen om te bepalen waar vervolgonderzoek nodig is en waar guardrails ontbreken.
- Zijn er actieve access keys voor menselijke IAM-gebruikers, en hebben die een duidelijke eigenaar?
- Is S3 Block Public Access op accountniveau ingeschakeld in alle relevante accounts?
- Bestaan er inbound security group-regels voor
0.0.0.0/0 of ::/0 op gevoelige poorten?
- Zijn CloudTrail, GuardDuty, AWS Config en Security Hub centraal ingericht in plaats van per team verschillend?
- Worden EBS-, RDS-snapshots en AMI’s structureel gecontroleerd op publieke of ongewenste cross-account shares?
- Worden IaC-templates vóór deployment gecontroleerd op publieke opslag, brede IAM-policies en open netwerkregels?
Wanneer meerdere antwoorden onzeker zijn, is dat meestal geen toolingprobleem maar een governanceprobleem. De oplossing ligt dan in eigenaarschap, standaardpatronen en automatische controles die voor alle teams gelden.
Waar AWS-beveiliging in de praktijk sterker van wordt
AWS-beveiliging wordt betrouwbaarder wanneer teams minder afhankelijk zijn van handmatige oplettendheid. De belangrijkste verschuiving is van losse correcties naar herhaalbare guardrails: identity federation in plaats van losse sleutels, centrale logging in plaats van lokale trails, policy-as-code vóór deployment, en SCP’s die bekende misconfiguraties al bij de bron blokkeren.
De meest effectieve volgende stap is een korte, risico-gebaseerde review van bestaande accounts, gevolgd door een plan dat quick wins verbindt met structurele platformkeuzes. Wie daarvoor gerichte begeleiding zoekt, kan Readynez gebruiken om AWS-securityvaardigheden rond IAM, monitoring, compliance en cloud governance verder te ontwikkelen zonder de praktijkcontext uit het oog te verliezen. For a deeper dive, see How to become AWS Certified Solutions Architect (SAA-C02) - Training,.
