Amazon SAA-C03: Beveiliging, IAM, KMS & Governance — Studiegids

By Laurynas Brazys · 18 July 2026 · #amazon #saa-c03 #certification #exam-prep #study-guide

Onderdeel van de AWS SAA-C03 — Complete studiegids. Oefen met geverifieerde antwoorden in het Amazon-examencentrum, of doe getimede oefentests op ExamRoll.io.

Basisprincipes van Identiteit: Users, Roots, Groups en Roles

Identity and Access Management is het controlepaneel (control plane) waar elke workload doorheen gaat, en het leidende principe is least privilege (minimale rechten): verleen alleen wat nodig is, alleen voor zolang het nodig is, en geef de voorkeur aan identiteiten die kortstondige credentials produceren boven identiteiten met statische secrets.

De root user is de eigenaar van het account, heeft onbeperkte permissies en kan niet worden beperkt door IAM policies of SCP’s. Dat maakt het de meest gevoelige credential in de omgeving, en deze moet als een ‘break-glass’-procedure worden behandeld. Bij een nieuw account: activeer een hardware of virtueel MFA-apparaat op de root, stel een lang, uniek wachtwoord in, verwijder eventuele historische root access keys en registreer alternatieve contacten voor facturering, operations en beveiliging zodat herstel mogelijk is. Na de initiële setup — het aanmaken van een IAM admin-identiteit, het configureren van de facturering en het instellen van de accountalias — wordt de root niet meer gebruikt, behalve voor de beperkte set taken waarvoor AWS dit expliciet vereist (het sluiten van het account, het wijzigen van de accountnaam, het herstellen van verwijderde IAM-permissies, het inschakelen van MFA Delete en een handvol S3/CloudFront root-ondertekende operaties). Het dagelijks gebruiken van de root user is onjuist omdat het niet kan worden beperkt door een policy, het moeilijk te herleiden is in CloudTrail wanneer het wordt gedeeld, en een enkele compromittering onherroepelijke controle geeft.

Dagelijkse menselijke toegang verloopt via IAM-identiteiten die worden beperkt door policies gebaseerd op het principe van minimale rechten (least privilege). Koppel managed policies aan groups, niet aan individuele users: een Administrators-groep met AdministratorAccess eraan gekoppeld, en benoemde users die daarin zijn geplaatst, levert één centraal punt voor wijzigingen op en vermijdt het anti-patroon van het plakken van identieke policies op elke user. Beperk de scope van resources met expliciete ARN’s in plaats van *.

Roles dienen een heel ander doel. Ze worden aangenomen (assumed) door principals — services, EC2-instances, Lambda-functies, gefedereerde gebruikers, cross-account aanroepers — en produceren tijdelijke STS-credentials die automatisch rouleren. Omdat die credentials niet kunnen lekken in een Git-commit en binnen minuten tot uren verlopen in plaats van te blijven bestaan totdat ze handmatig worden gerouleerd, zijn roles de standaardidentiteit voor alles wat niet-menselijk is.

Twee Policies per Role: Permissions en Trust

Elke role wordt beheerst door twee onafhankelijke documenten, en het vergeten van een van beide is een klassieke foutoorzaak.

De permissions policy (identity-based) declareert wat de role kan doen zodra deze is aangenomen. De trust policy (resource-based, gekoppeld aan de role zelf) declareert wie de role mag aannemen. Het koppelen van AmazonS3ReadOnlyAccess aan een role bereikt niets als geen enkele principal sts:AssumeRole erop mag aanroepen, en omgekeerd, een permissieve trust policy zonder een permissions policy levert een role op die kan worden aangenomen maar niets nuttigs kan doen.

Een Lambda execution role toont het service-principal-patroon — de service zelf, en niet de accounteigenaar, is de aanroepende partij (caller):

AssumeRolePolicyDocument:              # trust policy
  Version: "2012-10-17"
  Statement:
    - Effect: Allow
      Principal: { Service: lambda.amazonaws.com }
      Action: sts:AssumeRole
Policies:                              # permissions
  - PolicyName: ReadOrders
    PolicyDocument:
      Statement:
        - Effect: Allow
          Action: dynamodb:GetItem
          Resource: arn:aws:dynamodb:*:*:table/Orders

Workload-Identiteit: Instance Profiles, Task Roles, IRSA, Roles Anywhere

Elke credential die in een template, omgevingsvariabele of op een laptop staat, is een toekomstig datalek. Het canonieke AWS-patroon vervangt statische access keys door kortstondige, automatisch gerouleerde credentials die via roles worden geleverd.

Voor EC2 is het leveringsmechanisme het instance profile — een dunne container die een IAM-role aan een instance koppelt zodat de Instance Metadata Service (IMDSv2) tijdelijke credentials aan de SDK kan verstrekken. De standaard ‘credential provider chain’ vindt deze zonder configuratie, dus boto3.client('s3') werkt gewoon en de applicatiecode krijgt nooit een credential te zien. IMDSv2 (HttpTokens: required) moet worden afgedwongen om exfiltratie van credentials via SSRF te voorkomen. Credentials rouleren ongeveer elke zes uur, en intrekking is een simpele aanpassing van de role.

AppRole:
  Type: AWS::IAM::Role
  Properties:
    AssumeRolePolicyDocument:
      Statement:
        - Effect: Allow
          Principal: { Service: ec2.amazonaws.com }
          Action: sts:AssumeRole
    Policies:
      - PolicyName: S3DocAccess
        PolicyDocument:
          Statement:
            - Effect: Allow
              Action: [s3:GetObject, s3:PutObject]
              Resource: arn:aws:s3:::docs-bucket/*
AppInstanceProfile:
  Type: AWS::IAM::InstanceProfile
  Properties:
    Roles: [!Ref AppRole]

Voor ECS is het analogon de task role; voor Lambda is het de execution role; voor EKS-pods is het IRSA (IAM Roles for Service Accounts) of EKS Pod Identity. In elk geval bemiddelt AWS zelf de credentials tegen een role en krijgt de workload nooit een langdurig secret te zien.

Het ‘inbakken’ van access keys in een AMI, user-data script of .env-bestand is onjuist om drie concrete redenen: keys rouleren nooit automatisch, ze kunnen niet worden beperkt tot de sessiecontext, zoals een source VPC endpoint, en als de instance wordt gecompromitteerd of een AMI per ongeluk wordt gedeeld, lekt de credential permanent.

Voor workloads buiten AWS — on-premise servers, andere clouds, CI-runners — die tijdelijke AWS-credentials nodig hebben zonder ingebedde keys, gebruikt IAM Roles Anywhere X.509-certificaten van een private CA (AWS Private CA of uw eigen) als vertrouwensanker (trust anchor). De workload presenteert zijn clientcertificaat en ontvangt kortstondige STS-credentials:

aws_signing_helper credential-process \
  --certificate /etc/pki/client.pem \
  --private-key /etc/pki/client.key \
  --trust-anchor-arn arn:aws:rolesanywhere:...:trust-anchor/... \
  --profile-arn arn:aws:rolesanywhere:...:profile/... \
  --role-arn arn:aws:iam::111122223333:role/OnPremWorkload

Dit lost hetzelfde anti-patroon op dat instance roles en Secrets Manager binnen AWS oplossen.

Menselijke Toegang op Schaal: Identity Center, SAML, Directory Service

Het provisioneren van IAM-users per account is op enige schaal onbeheerbaar. AWS IAM Identity Center (de opvolger van AWS SSO) is de aanbevolen toegangsdeur voor medewerkers: één centrale directory die federeert naar elk account in een Organization en tijdelijke, op roles gebaseerde sessies uitgeeft via permission sets — IAM-roles op basis van templates die zijn gekoppeld aan IdP-groepen. Gebruikers authenticeren eenmalig in de Identity Center-portal en nemen vervolgens permission sets aan in elk toegewezen account.

Identity Center integreert met externe IdP’s (Okta, Entra ID/Azure AD, Google Workspace, ADFS) via SAML 2.0 en SCIM voor geautomatiseerde in-, door- en uitstroomprocessen (joiner/mover/leaver), en met on-premise Active Directory via AWS Directory Service AD Connector (een proxy) of AWS Managed Microsoft AD (een volledige replica in AWS). Voor mobiele of webapps die AWS moeten aanroepen vanuit niet-geauthenticeerde of door derden geauthenticeerde gebruikers, wisselt Amazon Cognito de externe identiteit in voor tijdelijke STS-credentials, waardoor opnieuw ingebedde, langdurige keys worden vermeden.

Cross-Account Access

Cross-account access wordt geregeld via rollen, niet via gedeelde gebruikers, en vereist toestemming van beide kanten. Het doelaccount (B) maakt een rol aan waarvan het vertrouwensbeleid (trust policy) Account A (of een specifieke principal daarin) benoemt. De aanroeper in A moet ook de sts:AssumeRole-permissie hebben die gericht is op de ARN van die rol. Toestemming van slechts één kant is onvoldoende. Dit resulteert in kortstondige credentials en een duidelijk CloudTrail-audittraject in beide accounts.

Wanneer een derde partij (een SaaS-leverancier) de principal is die de rol aanneemt, voeg dan een ExternalId-conditie toe om het confused deputy-probleem te voorkomen, en overweeg om MFA te vereisen:

{
  "Effect": "Allow",
  "Principal": { "AWS": "arn:aws:iam::222222222222:root" },
  "Action": "sts:AssumeRole",
  "Condition": {
    "StringEquals": { "sts:ExternalId": "a1b2c3-unique-token" },
    "Bool": { "aws:MultiFactorAuthPresent": "true" }
  }
}

Voor service-to-service aanroepen tussen accounts wordt het werk gedaan door resourcebeleid (resource policies). Om een SNS-topic in Account A een Lambda in Account B te laten aanroepen:

aws lambda add-permission \
  --function-name ProcessNotification \
  --statement-id AllowSNSInvoke \
  --action lambda:InvokeFunction \
  --principal sns.amazonaws.com \
  --source-arn arn:aws:sns:us-east-1:111111111111:my-topic

De --principal sns.amazonaws.com is de service principal (SNS zelf roept Lambda aan), en --source-arn beperkt het vertrouwen tot een specifiek topic om het confused deputy-probleem te voorkomen.

Voor het delen van S3-data binnen een Organization is de naïeve aanpak — het opsommen van elke account-ARN in het bucketbeleid — niet schaalbaar en faalt zodra een nieuw account wordt toegevoegd. Het correcte patroon is aws:PrincipalOrgID:

{
  "Effect": "Allow",
  "Principal": "*",
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::reports-bucket/*",
  "Condition": {
    "StringEquals": { "aws:PrincipalOrgID": "o-abcd1234ef" }
  }
}

Elke principal in elk account binnen die organization is toegestaan; ieder ander wordt geweigerd. Let op: Principal: "*" zonder de conditie zou de bucket openbaar maken — de condition key is wat de reikwijdte beperkt. De identiteitskant is ook van belang: gebruikers in lidaccounts (member accounts) hebben ook s3:GetObject nodig, toegekend door hun eigen IAM-beleid (tenzij ze account root zijn), omdat voor toegang tussen accounts beide kanten de aanroep moeten toestaan.

Specifiek voor S3, sinds 2023 schakelt de standaard Object Ownership-instelling Bucket owner enforced ACL’s volledig uit, waardoor bucketbeleid het enige autorisatiemechanisme voor de bucket is. Wanneer objecten voorheen door andere accounts werden geüpload, kunnen historische object-ACL’s of de bucket-owner-full-control canned ACL nog steeds een rol spelen.

Organizations en Service Control Policies

AWS Organizations voegt accounts samen in een boomstructuur van OU’s, met een managementaccount aan de basis (root). Service Control Policies (SCP’s) zijn guardrails die gekoppeld worden aan de root, een OU, of een individueel account. Ze zijn van toepassing op elke IAM-gebruiker en -rol in het account — inclusief de account root — maar niet op het managementaccount zelf. Daarom mogen workloads daar nooit draaien.

Het cruciale denkmodel: SCP’s kennen nooit permissies toe. Ze definiëren de maximale set van acties die in een account zijn toegestaan. Een actie is alleen toegestaan als deze wordt verleend door een identiteits- of resourcebeleid en niet wordt geblokkeerd door een SCP in het pad van het account. Als een ontwikkelaar AdministratorAccess heeft, maar een SCP ec2:RunInstances buiten ap-southeast-2 verbiedt, dan mislukt het starten van een instance in us-east-1. Omgekeerd doet een SCP die s3:* toestaat op zichzelf niets — de gebruiker heeft nog steeds een IAM-beleid nodig dat s3:* verleent. SCP’s filteren wat IAM al heeft toegestaan; ze zijn plafonds, geen vloeren.

Typische toepassingen van SCP’s zijn onder meer region lockdown, het verbieden van het uitschakelen van CloudTrail of GuardDuty, het verbieden van het verwijderen van KMS-sleutels buiten een break-glass-rol, en het afdwingen van encryptie. Om versleutelde EBS bij het opstarten af te dwingen, combineer je twee mechanismen: schakel EBS encryption by default in voor de regio (een accountinstelling per regio, zodat gebruikers geen scripts hoeven aan te passen), plus een SCP als de auditeerbare guardrail:

{
  "Effect": "Deny",
  "Action": "ec2:RunInstances",
  "Resource": "arn:aws:ec2:*:*:volume/*",
  "Condition": { "Bool": { "ec2:Encrypted": "false" } }
}

Omdat SCP’s van toepassing zijn op het hele account, kunnen ze niet worden omzeild door een gecompromitteerde beheerder in een lidaccount. Tag policies dwingen gestandaardiseerde tag-sleutels en hoofdlettergebruik af (CostCenter, niet costcenter), zodat kostentoewijzing en ABAC betrouwbaar werken. Organizations ondersteunt ook gedelegeerd beheer (delegated administration): in plaats van beveiligingsdiensten vanuit het managementaccount te draaien, delegeer je een lidaccount (bijv. een “security”- of “audit”-account) als beheerder voor GuardDuty, Security Hub, IAM Access Analyzer of Config. Dit waarborgt de scheiding van verantwoordelijkheden.

KMS: Sleutels, Key Policies en Eigendomsmodellen

KMS maakt onderscheid in sleutelmateriaal op basis van eigendom en beheer:

Een CMK wordt beheerd door een key policy — een resource-based policy die aan de sleutel is gekoppeld. In tegenstelling tot bijna elke andere AWS-resource, kunnen IAM policies alleen geen toegang verlenen tot een KMS-sleutel, tenzij de key policy eerst delegeert aan IAM:

{
  "Sid": "EnableIAMPolicies",
  "Effect": "Allow",
  "Principal": { "AWS": "arn:aws:iam::111122223333:root" },
  "Action": "kms:*",
  "Resource": "*"
}

Zonder die statement maakt geen enkele IAM policy de sleutel bruikbaar. Zowel de key policy als de IAM policy van de aanroeper moeten de operatie toestaan — dit is de meest voorkomende fout bij encryptie. Het toekennen van kms:Decrypt in een IAM policy is noodzakelijk maar niet voldoende; als de key policy niet delegeert aan IAM of de principal niet benoemt, mislukt de decryptie met AccessDenied, zelfs voor een administrator.

Voor services die KMS namens jou gebruiken (EBS, S3, RDS, Lambda), heeft de aanroepende rol doorgaans kms:GenerateDataKey, kms:Decrypt en vaak kms:CreateGrant nodig. Voor een EKS managed node group die EBS-volumes versleutelt met een CMK, moet de service-linked role van Auto Scaling in de key policy verschijnen met kms:CreateGrant, anders mislukken de lanceringen van instances stilzwijgend.

Rotatie van een customer-managed CMK moet expliciet worden ingeschakeld — veel professionals gaan er onterecht van uit dat alle KMS-sleutels automatisch roteren:

aws kms enable-key-rotation --key-id alias/my-cmk
aws kms get-key-rotation-status --key-id alias/my-cmk

Rotatie behoudt dezelfde key ID en alias; het achterliggende materiaal verandert, maar eerdere ciphertext blijft decodeerbaar omdat KMS oud materiaal bewaart om bestaande ciphertexts te decoderen, terwijl nieuwe schrijfacties vers materiaal gebruiken. Geïmporteerd materiaal roteert nooit automatisch. KMS dwingt een verplichte wachttijd voor verwijdering af van 7–30 dagen; koppel dit aan een EventBridge-regel die ScheduleKeyDeletion of DisableKey in CloudTrail matcht en richt deze op een SNS-topic voor een serverless, poll-vrij waarschuwingspatroon:

{
  "source": ["aws.kms"],
  "detail-type": ["AWS API Call via CloudTrail"],
  "detail": { "eventName": ["ScheduleKeyDeletion", "DisableKey"] }
}

External Key Stores (XKS) breiden het model uit wanneer regelgevers eisen dat sleutelmateriaal fysiek in een door de klant beheerde HSM verblijft. KMS stuurt cryptografische operaties door naar een XKS-proxy die communiceert met de on-prem HSM; als de HSM offline is, mislukt de decryptie — beschikbaarheid wordt de verantwoordelijkheid van de klant.

Multi-Region Keys (MRK’s) delen dezelfde key ID en materiaal over meerdere Regions, zodat ciphertext die in us-east-1 is geproduceerd, direct in eu-west-1 kan worden gedecodeerd. Dit is het juiste patroon voor DynamoDB Global Tables, S3 Cross-Region Replication met SSE-KMS, en DR-scenario’s waarbij een standby-Region versleutelde back-ups moet kunnen lezen. Standaard single-Region sleutels zouden decryptie en vervolgens her-encryptie vereisen op het moment van replicatie.

Cross-Account Delen van Versleutelde Resources

Het delen van versleutelde AMI’s en EBS-snapshots is een van de meest voorkomende oorzaken van fouten bij cross-account toegang, omdat het vier gecoördineerde acties vereist: (1) gebruik een customer-managed CMK — AWS-managed keys kunnen niet worden gedeeld; (2) voeg het doelaccount toe als principal in de key policy met kms:Decrypt, kms:DescribeKey, kms:CreateGrant en kms:ReEncrypt*; (3) pas de launch/share-permissies van de AMI of snapshot aan om dat account op te nemen; en (4) zorg ervoor dat de IAM principal in het doelaccount ook die KMS-acties heeft. De deelactie lijkt te slagen als je stap 2 overslaat, maar het ontvangende account kan niet decoderen. Aannemen dat alleen het delen van de AMI voldoende is, is de klassieke valkuil.

S3 Server-Side Encryptie Modi

Wanneer een vereiste automatische jaarlijkse rotatie, CloudTrail-auditeerbaarheid en minimalisering van sleutelkosten specificeert, is het antwoord SSE-KMS met de AWS-managed aws/s3-sleutel — deze roteert jaarlijks zonder extra kosten en elke GenerateDataKey/Decrypt-aanroep wordt gelogd. SSE-S3 is goedkoper, maar laat geen spoor van sleutelgebruik achter. Een customer-managed CMK kost $1/maand extra en roteert alleen als je rotatie inschakelt.

Het verwarren van SSE-S3 en SSE-KMS is de klassieke valkuil bij PHI (Protected Health Information). SSE-S3 versleutelt data, maar biedt geen key policy, geen zichtbaarheid in CloudTrail en geen manier voor een complianceteam om de sleutel te beheren — het voldoet dus niet aan enige vereiste die “beheren”, “controleren”, “auditen” of “toegang tot de sleutel intrekken” vermeldt. Omgekeerd is het kiezen voor SSE-KMS wanneer de enige vereiste “encrypt at rest met minimaal beheer” is, over-engineering.

Het inschakelen van SSE-KMS voorkomt op zichzelf niet dat onbevoegden kunnen lezen. Als de bucket policy s3:GetObject toestaat en de key policy kms:Decrypt toekent aan dezelfde principal, is het object leesbaar. Encryptie at rest beschermt tegen fysieke compromittering van media en voegt een tweede autorisatiecontrole toe via de key policy — het is geen vervanging voor correct afgebakende bucket policies, IAM policies, VPC endpoint policies en aws:PrincipalOrgID-condities.

Encryptie en TLS afdwingen op S3

Een bucket “standaard versleuteld” maken is niet genoeg — clients kunnen de encryptie-header weglaten of overschrijven. Twee beveiligingsmaatregelen moeten gelaagd worden toegepast: standaard bucket-encryptie (vult de header in als de client deze weglaat) en een op ‘deny’ gebaseerde bucket policy die PutObject zonder de vereiste header weigert, plus een statement dat niet-TLS-toegang weigert:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyUnEncryptedObjectUploads",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::phi-bucket/*",
      "Condition": {
        "StringNotEquals": { "s3:x-amz-server-side-encryption": "aws:kms" }
      }
    },
    {
      "Sid": "DenyInsecureTransport",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": ["arn:aws:s3:::phi-bucket", "arn:aws:s3:::phi-bucket/*"],
      "Condition": { "Bool": { "aws:SecureTransport": "false" } }
    }
  ]
}

De aws:SecureTransport-conditie dwingt HTTPS af, wat voldoet aan “versleuteld tijdens overdracht” (encrypted in transit). Gecombineerd met SSE-KMS met een CMK die eigendom is van het compliance-team, is dit het canonieke patroon voor de opslag van PHI.

Encryptie ‘in Transit’ versus ‘at Rest’

Encryptie ‘at rest’ (KMS-versleutelde EBS, RDS-opslag, S3-objecten) en encryptie ‘in transit’ (TLS ‘on the wire’) zijn onafhankelijke controles die verschillende dreigingen aanpakken — diefstal van schijven versus onderschepping op het netwerk. Het inschakelen van KMS op een RDS-instance beschermt de onderliggende opslag; het doet niets voor een client-naar-database-sessie, die standaard onversleuteld kan zijn. Voor RDS MySQL vereist ‘in-transit’-bescherming het downloaden van de RDS CA-bundel, het instellen van require_secure_transport=ON in de parameter group, en het verbinden van clients met --ssl-ca=rds-combined-ca-bundle.pem. Het als voldoende beschouwen van “encryptie at rest staat aan” is een veelvoorkomende fout bij audits.

Secrets Manager en Parameter Store

Statische databasewachtwoorden in configuratiebestanden, omgevingsvariabelen of CloudFormation-parameters zijn de belangrijkste vector voor het lekken van credentials. AWS Secrets Manager slaat secrets versleuteld op met KMS, stelt ze beschikbaar via de door IAM gecontroleerde GetSecretValue-actie, en — cruciaal — roteert ze automatisch via een Lambda-rotatiefunctie. Voor RDS, Aurora, Redshift en DocumentDB levert AWS een beheerde rotatie-Lambda die verbinding maakt met de database, een nieuw wachtwoord genereert, zowel het secret als de DB-gebruiker atomair bijwerkt, en strategieën voor één of meerdere gebruikers ondersteunt. Voor andere systemen schrijf je een Lambda die de vierstaps-levenscyclus implementeert: createSecret, setSecret, testSecret, finishSecret.

import boto3, json
secret = json.loads(
    boto3.client('secretsmanager')
         .get_secret_value(SecretId='prod/aurora/app')['SecretString'])
conn = pymysql.connect(host=secret['host'],
                       user=secret['username'],
                       password=secret['password'])

Applicaties cachen de waarde kortstondig (met behulp van de AWS SDK caching library) en maken opnieuw verbinding bij een authenticatiefout. Rotatie is onzichtbaar en er is geen deployment nodig om een wachtwoord te wijzigen.

SSM Parameter Store SecureString is het alternatief wanneer rotatie niet vereist is en kosten de doorslaggevende factor zijn:

Een retriever van een SecureString-parameter heeft zowel ssm:GetParameter als kms:Decrypt op de key nodig. Het vergeten van de KMS-permissie is een van de meest voorkomende misconfiguraties — de IAM policy lijkt correct, maar de API-call mislukt bij het ontsleutelen.

Op EC2, ECS, EKS en Lambda moet de code een IAM-rol aannemen en GetSecretValue of GetParameter aanroepen; geen langlevende credentials op schijf. Het direct insluiten van IAM user access keys in applicatiecode — zelfs versleuteld — schendt het ’least privilege’-principe en bemoeilijkt rotatie.

Audit- en Forensische Tools

CloudTrail registreert elke AWS API-call: wie, wat, wanneer, van waar. Een organization trail die vanuit het management account is ingeschakeld, legt events van alle accounts vast in één enkele S3-bucket, idealiter in een streng beveiligd security-account met S3 Object Lock en MFA Delete. Dit levert een onveranderlijke forensische tijdlijn op — welke principal een volume heeft verwijderd, welke rol een security group heeft gewijzigd, welke access key ec2:RunInstances heeft aangeroepen om 03:17 UTC. Vul dit aan met CloudWatch Logs en alarms (root-login, wijzigingen in IAM-policies), en AWS Config voor de status van resources op een bepaald tijdstip en conformance packs. Voorkom manipulatie met een SCP die cloudtrail:StopLogging en cloudtrail:DeleteTrail weigert.

MFA Delete op een S3-bucket dwingt de root-gebruiker om een MFA-token te presenteren om een objectversie permanent te verwijderen of versioning uit te schakelen. Het kan alleen door root via de CLI worden ingeschakeld en biedt sterke bescherming tegen ransomware en verwijdering door insiders.

Amazon Macie gebruikt beheerde ML om PII, PHI, credentials en financiële gegevens in S3 te ontdekken, en produceert bevindingen gerangschikt naar ernst. Het is een discovery-tool, geen encryptie-tool.

Threat Detection: GuardDuty, Security Hub, Detective

Amazon GuardDuty analyseert continu VPC Flow Logs, DNS-logs en CloudTrail management- en data-events, met speciale beschermingsplannen voor EKS audit logs, S3 data events, EBS-malwarescans, Lambda-netwerkactiviteit en RDS login events. GuardDuty RDS Protection brengt afwijkende of brute-force authenticatiepogingen tegen Aurora en RDS aan het licht — gedrag dat een security group niet kan detecteren omdat de verbinding op L4 legitiem is. Bevindingen stromen naar de dashboards van EventBridge, Security Hub en Detective.

Security groups werken alleen op L3–L4. Een groep die 0.0.0.0/0 op poort 443 toestaat, doet zijn werk wanneer het een SQL-injectie-payload doorstuurt — dat is precies waarvoor WAF bestaat om te stoppen. Defense in depth betekent security groups plus WAF plus Shield plus GuardDuty, waarbij elke dienst een laag dekt die de andere niet kunnen zien.

DDoS: Shield Standard en Advanced

AWS Shield Standard is automatisch en gratis, en verdedigt elk account tegen veelvoorkomende L3/L4-aanvallen (SYN-floods, reflection attacks). Het draait stil op de achtergrond zonder zichtbaarheid, zonder aangepaste mitigatie en zonder de mogelijkheid voor menselijke tussenkomst.

AWS Shield Advanced ($3.000/maand per organisatie plus datatransferkosten) is vereist wanneer het scenario spreekt over proactieve betrokkenheid, toegewijde respons, kostenbescherming tegen schalen als gevolg van DDoS, of bijna-realtime inzicht in aanvallen. Het dekt CloudFront, Global Accelerator, ALB, CLB, Route 53 en Elastic IP’s, en biedt 24/7 toegang tot het Shield Response Team (SRT) — vooraf geautoriseerd via een IAM-rol — om namens u WAF-regels te schrijven tijdens een actieve aanval. Wanneer een ontwerp achter een ALB en Route 53 beheerde detectie en een menselijke respons vereist, is Shield Standard alleen onvoldoende; dat is de terugkerende valkuil. Advanced biedt ook kostenbescherming voor schalen dat door aanvallen wordt veroorzaakt. Wanneer “MINSTE implementatie-inspanning” wordt genoemd en de architectuur al een Global Accelerator of een ALB bevat, is het antwoord doorgaans Shield Advanced inschakelen en de door AWS beheerde WAF-regelgroepen koppelen, en niet het bouwen van aangepaste Lambda@Edge-functies of het migreren van een CDN.

Applicatielaagbescherming: AWS WAF

AWS WAF kan worden gekoppeld aan CloudFront, Application Load Balancers, API Gateway, AppSync, App Runner en Cognito user pools. Het beschermt niet rechtstreeks Network Load Balancers (plaats er een CloudFront voor). Het inspecteert L7-verkeer en past regels toe voor SQL-injectie, XSS, groottelimieten, geo-blocking, IP-reputatie en rate limiting. AWS Managed Rules bieden samengestelde groepen zoals AWSManagedRulesCommonRuleSet en AWSManagedRulesSQLiRuleSet zonder dat u zelf regex hoeft te schrijven.

Rate-based rules zijn de primaire verdediging tegen HTTP-floods en credential stuffing — ze tellen het aantal verzoeken per venster van vijf minuten per bron-IP (of per doorgestuurde header) en blokkeren overtreders automatisch:

Rules:
  - Name: RateLimitPerIP
    Priority: 1
    Statement:
      RateBasedStatement:
        Limit: 2000        # per 5-min window per IP
        AggregateKeyType: IP
    Action: { Block: {} }
    VisibilityConfig:
      CloudWatchMetricsEnabled: true
      MetricName: RateLimitPerIP
      SampledRequestsEnabled: true

WAF is geen DDoS-dienst — dat is de rol van Shield. WAF vult resource policies (S3 bucket policies die non-TLS weigeren, VPC endpoint policies die bereikbare buckets beperken) en netwerkcontroles (security groups, NACL’s) aan — een misconfiguratie op één enkele laag mag geen data blootstellen.

Netwerkisolatie: Security Groups, NACL’s, Network Firewall

Binnen een VPC is de verdediging gelaagd:

• Security groups zijn stateful, worden toegepast op ENI’s, zijn ‘allow-only’ en evalueren alle regels tegelijk. Retourverkeer wordt automatisch toegestaan, dus efemere poorten hoeven niet expliciet te worden geopend.
• Network ACLs zijn stateless, worden toegepast op subnets, ondersteunen zowel ‘allow’ als ‘deny’, en evalueren in numerieke volgorde. Omdat ze stateless zijn, moet u, als u inkomend verkeer op poort 443 toestaat, ook uitgaand verkeer op de efemere poorten 1024–65535 toestaan voor de antwoorden. Als u dit vergeet, worden alle antwoorden op subtiele wijze gedropt. Security groups hebben dit probleem niet.
• AWS Network Firewall biedt deep packet inspection, Suricata-compatibele IPS-regels en domeingebaseerde egress filtering, en wordt geplaatst tussen subnets en IGW’s/TGW’s voor gecentraliseerde inspectie.

Ervan uitgaan dat alleen security groups volstaan, negeert bedreigingen op subnetniveau en ‘blast radius’-controles; ervan uitgaan dat alleen NACL’s volstaan, negeert hun stateless karakter en grofmazigheid.

Valkuilen

Trust policy vergeten. Een permissions policy van een rol verleent rechten; alleen de trust policy verleent de mogelijkheid om de rol aan te nemen (‘assumability’). Beide moeten openstaan om cross-account of service-to-service toegang te laten werken — de aanroeper ontvangt AccessDenied op sts:AssumeRole, ongeacht hoe permissief de identity policy is.

IAM policy zonder overeenkomstige key policy. kms:Decrypt in IAM is noodzakelijk maar niet voldoende. De key policy moet ofwel de principal benoemen of delegeren aan IAM met Principal: {"AWS": "arn:aws:iam::ACCOUNT:root"}. Het delen van versleutelde AMI’s/snapshots mislukt wanneer alleen de AMI wordt gedeeld en de key policy niet wordt bijgewerkt.

SCP’s behandeld als rechtenverlening. SCP’s beperken, maar verlenen nooit rechten. Een Allow s3:* SCP doet niets zonder een overeenkomstige identity policy. Omgekeerd wordt een permissieve identity policy begrensd door elke SCP Deny in het pad van het account.

Uitgaan van automatische KMS-rotatie. Door de klant beheerde CMK’s roteren niet totdat dit is ingeschakeld; geïmporteerd sleutelmateriaal roteert nooit automatisch.

SSE-S3 gekozen voor data die onderhevig is aan compliance. SSE-S3 heeft geen key policy, geen zichtbaarheid in CloudTrail en geen intrekkingspad — het voldoet niet aan enige vereiste die “beheren”, “controleren”, “auditen” of “intrekken” van de sleutel vermeldt.

Versleuteling ‘at rest’ als voldoende beschouwen. ‘At rest’ en ‘in transit’ zijn onafhankelijk van elkaar. RDS met KMS vereist nog steeds require_secure_transport=ON en validatie van de client-CA.

Bucket policy die accounts individueel benoemt. Schaalt niet en gaat stuk bij organisatieveranderingen. Gebruik aws:PrincipalOrgID.

Hardcoded access keys, waar dan ook. In user data, .env-bestanden, CloudFormation-parameters, Git — altijd fout. Gebruik instance profiles, task roles, execution roles, IRSA/Pod Identity of Roles Anywhere.

Root user voor dagelijks werk of gekoppelde policies. De root user kan niet worden beperkt door IAM of SCP’s; een policy toevoegen aan root is zinloos. Elk antwoord dat dit doet, is op het eerste gezicht al fout.

IAM users voor cross-account toegang. IAM users kunnen niet cross-account worden ‘assumed’; creëer een rol in het doelaccount en laat de principal uit het bronaccount deze aannemen.

NLB achter WAF. WAF kan niet worden gekoppeld aan NLB’s. Plaats een CloudFront voor de NLB als L7-filtering nodig is.

NACL mist efemeer uitgaand verkeer. Stateless NACL’s hebben expliciete regels voor het retourpad nodig. Het ontbreken van uitgaand verkeer op poorten 1024-65535 breekt stilzwijgend alle inkomende reacties op poort 443.

Shield Standard voor beheerde betrokkenheid. Standard is passief zonder toegang tot het SRT; alleen Advanced voldoet aan “proactieve beheerde betrokkenheid” of “kostenbescherming.”

← Applicatie-integratie · Alle domeinen · Beheer →

Oefen deze vragen → · Getimede oefening op ExamRoll.io →

Blader door Amazon →