Amazon DOP-C02: Beveiliging, Compliance en Governance — Studiegids

By Laurynas Brazys · 4 August 2026 · #amazon #dop-c02 #certification #exam-prep #study-guide

Onderdeel van de AWS DevOps Engineer Professional DOP-C02 — Studiegids. Oefen met geverifieerde antwoorden in het Amazon-examencentrum, of doe getimede oefentests op ExamRoll.io.

Overzicht

Beveiliging, compliance en governance op AWS zijn afhankelijk van deterministische controles die schalen over accounts en Regions zonder de levering te vertragen. Een robuust ontwerp combineert verschillende lagen van identiteitscontroles (IAM, permission boundaries en service control policies), multi-account governance (AWS Organizations en Control Tower), continue beoordeling en herstel (AWS Config), dreigingsdetectie (Security Hub, GuardDuty, Inspector), hygiëne van secrets, encryptie met AWS KMS, en netwerkisolatie (VPC security groups, NACL’s, endpoints en PrivateLink). Het doel is om de ‘blast radius’ (schade-impact) te minimaliseren, continu compliance aan te tonen, en preventie en herstel te automatiseren met behoud van ’least privilege’ en de autonomie van ontwikkelaars.

Identiteit, Beleid en Multi-Account Governance

IAM-rollen, policies, permission boundaries en SCP’s werken samen om de effectieve permissieset te vormen. Identity-based policies van een IAM-rol definiëren de toegestane acties; de trust policy van de rol definieert wie deze mag aannemen (assumen). Permission boundaries beperken wat een principal kan doen, ongeacht wat de identity policies zeggen. SCP’s in AWS Organizations stellen het absolute maximum in voor elke principal in een member-account (inclusief de root user). Resource-based policies (voor S3, KMS, Secrets Manager, etc.) kunnen cross-account toegang toestaan, maar ook zij kunnen de grenzen die door SCP’s of permission boundaries zijn opgelegd niet overschrijden. De effectieve permissie is de doorsnede van: identity policies ∩ permission boundary ∩ session policies (indien aanwezig) ∩ resource policy (indien van toepassing) ∩ SCP’s, waarbij een expliciete ‘Deny’ altijd voorrang heeft.

Gebruik permission boundaries om veilige selfservice binnen één account mogelijk te maken. Bijvoorbeeld, een ‘developer vending pipeline’ kan alleen rollen aanmaken als deze een boundary koppelt die iam:PassRole weigert, behalve voor specifieke patronen, kms:Decrypt op gevoelige sleutels weigert, en EC2-instance types beperkt. Boundaries kunnen alleen worden gekoppeld door principals die al iam:PutRolePermissionsBoundary hebben; bewaak dit recht zeer zorgvuldig.

SCP’s zijn ‘guardrails’ (vangrails) voor de hele organisatie. Veelvoorkomende guardrails zijn onder meer het verbieden van het uitschakelen van AWS Config of CloudTrail, het voorkomen van uitnodigingen van buiten de Organization, het weigeren van wijzigingen aan de gedelegeerde beheerder van IAM Identity Center, en het beperken van Regions. Geef de voorkeur aan expliciete ‘allow-by-exception’-patronen met condities (bijvoorbeeld het toestaan van wijzigingen door een centrale beheerdersrol) om frictie te minimaliseren. Sta altijd de aanmaak en het gebruik van benodigde service-linked roles toe (bv. voor GuardDuty, Inspector, Config), anders blokkeren je SCP’s onbedoeld de configuratie van services.

AWS Organizations biedt hiërarchische OU’s om omgevingen (bv. Sandbox, Dev, Prod), workload-types en uitzonderingspaden te scheiden. Neem SCP’s over van bovenliggende OU’s om ‘policy drift’ te voorkomen. Gebruik ‘account vending’ om de setup van accounts te standaardiseren: AWS Control Tower’s Account Factory (console) of Account Factory for Terraform (AFT) om te integreren in CI/CD. AFT voegt GitOps-workflows, ‘drift detection’ en ‘feature flags’ toe (bv. het provisioneren van Enterprise Support), en schaalt naar honderden accounts met consistente basis-guardrails.

AWS Control Tower automatiseert een ’landing zone’ met prescriptieve guardrails. Preventieve guardrails zijn SCP’s die Control Tower beheert; detectieve guardrails zijn AWS Config-regels die het uitrolt. Control Tower integreert IAM Identity Center voor SSO en permission sets. Gebruik op ABAC gebaseerde permission sets met attributen voor toegangscontrole om acties te scopen op basis van aws:PrincipalTag of identiteitsattributen. Breid de baseline uit met Customizations for AWS Control Tower (CfCT) om CloudFormation, SCP’s en Config-packs automatisch per OU/account uit te rollen. Houd uitzonderings-OU’s aan voor workloads die maatwerkbeleid vereisen, zonder de globale guardrails te verzwakken.

Continue Compliance en Geautomatiseerd Herstel

Activeer AWS Config voor de hele organisatie vanuit een ‘delegated administrator’-account. Schakel recording in voor alle resources in alle Regions en aggregeer de configuratie over de hele Organization met een ‘organization aggregator’. Gebruik beheerde regels (managed rules) voor veelvoorkomende controles (bv. ebs-encryption-by-default, restricted-ssh, s3-bucket-level-public-access-prohibited) en schrijf custom, door Lambda ondersteunde regels voor maatwerklogica (bv. het verifiëren van de rotatiefrequentie van KMS tegen een 90-dagenbeleid of het afdwingen van standaard tags en waarden). Conformance packs groeperen regels, parameters en herstelacties (remediation) in versiebeheerde, uitrolbare bundels per OU; onderhoud deze in versiebeheer en rol ze uit via StackSets of CfCT voor consistentie en auditeerbaarheid.

Geautomatiseerde remediation sluit de cirkel. Koppel de ’noncompliant’-evaluatie van elke regel aan een SSM Automation runbook dat de baseline afdwingt: koppel een standaard instance profile, pas een tag met een standaardwaarde toe, schakel S3 Block Public Access in, of herstart een EC2-instance voor onderhoud. Gebruik geparametriseerde documenten en dynamische input (bv. uit de Config-bevinding) om runbooks generiek te houden. Configureer voor risicovolle resources de remediation zo dat deze automatisch wordt uitgevoerd; voor gevoelige acties, vereis een goedkeuring (change approval) of handmatige aanroep via EventBridge en ChatOps. Bescherm Config zelf met SCP’s die het stoppen van de recorder of het verwijderen van delivery channels weigeren, behalve door een centrale beheerder.

Firewall Manager vult deze laag aan voor ‘policy-as-a-service’ over accounts heen, met behulp van Organizations. Delegeer een centrale beheerder en stel beleid op voor WAF web ACL-associaties op internetgerichte ALB’s/API Gateway, auditing en opschoning van VPC security groups, of de propagatie van DNS Firewall-regels. Dit verschuift de toekomstige handhaving van detectie/herstel naar preventie.

Bedreigingsdetectie, Secrets Hygiëne en Kwetsbaarhedenbeheer

Security Hub dient als de centrale overzichtspagina (central pane of glass) voor bevindingen over accounts en Regions heen. Activeer het met een gedelegeerde beheerder (delegated admin), aggregeer bevindingen en activeer relevante standaarden (AWS Foundational Security Best Practices, CIS, PCI DSS waar van toepassing). Bevindingen worden vastgelegd in het AWS Security Finding Format (ASFF), waarbij de input van GuardDuty, Inspector, IAM Access Analyzer, Config, Macie en partnertools wordt genormaliseerd. Koppel EventBridge-patronen om kritieke bevindingen door te sturen naar geautomatiseerde herstelacties (SSM Automation, Lambda) en notificaties (SNS, chat).

GuardDuty biedt beheerde bedreigingsdetectie (managed threat detection) zonder dat u log-pipelines voor het datavlak (data-plane) hoeft te beheren. Het analyseert CloudTrail management- en data-events, VPC Flow Logs, DNS-querylogs van Route 53 Resolver en EKS-auditlogs om afwijkend gedrag, exfiltratie van credentials, crypto-mining, DNS-exfiltratie en meer te detecteren. Activeer Malware Protection voor het scannen van S3 en EC2/EBS bij verdachte activiteit. Gebruik automatische activering voor de hele organisatie en archiveer bevindingen met een laag signaal (low-signal findings) systematisch met onderdrukkingsregels (suppression rules) om de focus op uitvoerbare acties te houden.

Amazon Inspector beoordeelt continu EC2 (via de SSM-agent) op CVE’s in packages, ECR-container-images op kwetsbaarheden vóór de implementatie (pre-deploy), en Lambda-functies op CVE’s in code-packages. Voor Inspector is vereist dat EC2-instances de SSM Agent geïnstalleerd hebben, het instance profile SSM-permissies toestaat, en er uitgaand verkeer (egress) naar SSM/KMS-eindpunten is (via VPC-eindpunten als internettoegang beperkt is). Configureer Inspector om bevindingen naar Security Hub te sturen en patch-workflows te activeren met Systems Manager Patch Manager of herstelacties via runbooks. Gebruik tags om te bepalen welke resources binnen het bereik (scope) van de scans vallen en om sandbox-workloads te scheiden van gereguleerde workloads.

Secrets Manager centraliseert de opslag, rotatie en cross-account toegang van secrets met sterke auditeerbaarheid. Geef de voorkeur aan Secrets Manager boven parameter stores voor credentials die rotatie vereisen; maak hierbij gebruik van de ingebouwde rotatie voor RDS/Aurora of op Lambda gebaseerde rotatie voor externe systemen. Staging labels (AWSCURRENT, AWSPREVIOUS) maken rotatie zonder downtime mogelijk. Voer rotatie-Lambda’s uit in VPC’s met de benodigde eindpunten (Secrets Manager, RDS, KMS) en beperk uitgaand verkeer (egress). Voor gebruik vanuit een ander account (cross-account), voeg een resource-based policy toe die principals in andere accounts de GetSecretValue-permissie geeft; zorg ervoor dat de KMS key policy voor de CMK van het secret de principals van de consumer toestaat om te ontsleutelen (decrypt) en, indien nodig, om grants aan te maken. Voor disaster recovery of voor het beheren van lokaliteit, repliceer secrets over meerdere Regions en stem de rotatievensters op elkaar af.

Gegevensbescherming en Netwerkbeveiliging

Ontwerp versleuteling met KMS met expliciete key policies. Key policies, en niet alleen IAM policies, autoriseren uiteindelijk principals voor cryptografische operaties op een CMK. Hanteer een key policy-model gebaseerd op least-privilege en rollen: delegeer administratie aan een centrale KMS admin-rol; ken gebruiksrechten beperkt toe aan workload-rollen; sta de wildcard kms:* niet toe om onbedoelde escalatie te voorkomen. Gebruik condition keys (kms:EncryptionContext:*) om decryptie te koppelen aan verwachte contexten. Multi-Region keys maken actief-actieve encryptie mogelijk waarbij data cross-region wordt gerepliceerd.

Grants zijn het juiste middel voor het delegeren van tijdelijk of strikt afgebakend sleutelgebruik zonder de key policy aan te passen, en ze zijn vereist voor sommige service-flows (bijv. EC2 Auto Scaling dat versleutelde launch templates gebruikt, cross-account AMI-gebruik). Om een ander account toe te staan grants aan te maken, moet de key policy kms:CreateGrant toestaan voor de principals van dat account; de grantee moet een grant token aanleveren voor onmiddellijk gebruik in hetzelfde call path. Voor cross-account versleutelde AMI’s: kopieer en versleutel de AMI met een CMK, deel de AMI, sta het doelaccount toe om grants aan te maken op de CMK, en laat de service-linked role van het doel een grant ontvangen.

Envelope-encryptie is het standaardpatroon: genereer een data key met KMS, versleutel de data lokaal met de plaintext data key, en sla vervolgens alleen de ciphertext en de versleutelde data key op. Roep bij het lezen KMS Decrypt aan om de plaintext data key in het geheugen te herstellen. Dit minimaliseert KMS-aanroepen voor grote payloads en beperkt de blootstelling van de plaintext key. Waar ondersteund, gebruik door de service beheerde SSE-KMS (S3, EBS, RDS) voor operationele eenvoud, maar stem de key policies nog steeds af op cross-account producers/consumers.

VPC-beveiliging begint met security groups die het least-privilege-principe volgen. Security groups zijn stateful; terugkerend verkeer is impliciet toegestaan. Geef de voorkeur aan security group-referenties boven op CIDR gebaseerde regels om kwetsbare IP-allow-lists te vermijden en de intentie te behouden in de infrastructure-as-code. Standaard uitgaande regels die alles toestaan zijn riskant; beperk egress expliciet tot de vereiste bestemmingen en gebruik VPC endpoints voor toegang tot AWS-services. NACL’s zijn stateless en worden als eerste geëvalueerd; houd ze als grove controles op subnetniveau met expliciete return-regels voor ephemeral ports, alleen wanneer u een extra grens moet implementeren of aan regelgeving moet voldoen; geef anders de voorkeur aan security groups voor de beheerbaarheid.

Elimineer afhankelijkheden van het internet door VPC endpoints te gebruiken. Gateway endpoints (S3, DynamoDB) routeren privé over het AWS-netwerk; koppel een endpoint policy om de toegankelijke buckets of tabellen te beperken. Interface endpoints (AWS PrivateLink) stellen AWS-services (Secrets Manager, KMS, SSM, ECR, CloudWatch) beschikbaar via privé-IP’s; implementeer ze in subnets met de juiste security groups en activeer Private DNS zodat standaard servicenamen naar privé-adressen resolven. Voor producer-consumer microservices over accounts/VPC’s heen, publiceer een endpoint service ondersteund door een NLB en laat consumers er interface endpoints naar aanmaken via PrivateLink, waarmee peering of transit gateways worden vermeden en het verkeer van het publieke internet wordt gehouden. Combineer deze controles met subnets zonder NAT en zonder IGW, en gecentraliseerde egress-inspectie waar internettoegang vereist is.

Praktijkscenario

Expedia Group breidt uit naar honderden AWS-accounts in meerdere Regio’s en moet een strikte security baseline afdwingen: geen internet-egress voor workloads, geautomatiseerd herstel van misconfiguraties, gecentraliseerde dreigingsdetectie, rotatie van secrets en gecontroleerd cross-account delen van versleutelde AMI’s voor gestandaardiseerde golden images.

Zet multi-account governance op met AWS Organizations en AWS Control Tower

Actie: Maak OU’s aan voor Sandbox, Dev, Prod en Security. Implementeer Control Tower om de landing zone op te zetten, verplichte guardrails te activeren en IAM Identity Center te integreren. Gebruik Account Factory for Terraform (AFT) om accounts op te leveren via GitOps.
Waarom: Control Tower biedt kant-en-klare, continu afgedwongen guardrails (SCP’s en Config-regels). AFT standaardiseert het provisionen van accounts op schaal en legt baselines vast in versiebeheer.

Stel SCP’s op om globale guardrails met uitzonderingen af te dwingen

Actie: Koppel SCP’s die het uitschakelen van CloudTrail en AWS Config verbieden, Regio’s beperken en publieke S3 ACL’s voorkomen. Voeg op condities gebaseerde uitzonderingen toe voor een security-admin-rol in de Security OU. Sta het aanmaken/gebruiken van vereiste service-linked roles toe.
Waarom: SCP’s beperken de privileges van alle principals, inclusief root, en voorkomen zo drift, terwijl gecontroleerde uitzonderingen voor centrale operaties worden toegestaan.

Implementeer Config conformance packs met geautomatiseerd herstel

Actie: Activeer vanuit het gedelegeerde admin-account voor Security AWS Config voor de hele organisatie en maak een aggregator aan. Rol een conformance pack uit dat standaard versleuteling van EBS afdwingt, beperkte SSH, verplichte tags met standaardwaarden en een vereiste WAF op publieke entry points. Koppel elke regel aan SSM Automation-documenten voor automatische fixes (bijv. koppel het standaard instance profile, stel ontbrekende tags in op ‘weekly’).
Waarom: Conformance packs leveren consistente, auditeerbare policy-as-code met auto-remediation die omgevingen compliant houdt zonder een stroom aan tickets.

Centraliseer detectie met Security Hub, GuardDuty en Inspector

Actie: Activeer GuardDuty en Inspector voor de hele organisatie met een gedelegeerde admin. Activeer Security Hub-standaarden (AWS FSBP en CIS) en aggregeer bevindingen. Maak EventBridge-regels om bevindingen met een hoge prioriteit door te sturen naar SSM Automation runbooks en een SNS-topic voor de on-call.
Waarom: Beheerde detectie en kwetsbaarheidsanalyse bieden continue dekking met minimale operationele overhead, en Security Hub consolideert signalen voor snellere triage en respons.

Dwing least privilege IAM af met permission boundaries en ABAC

Actie: Vereis in accounts die met AFT zijn geprovisioneerd dat door ontwikkelaars gemaakte rollen een permission boundary koppelen die iam:PassRole weigert, behalve voor gecureerde rollen, en API’s met een hoge impact beperkt. Gebruik IAM Identity Center permission sets met ABAC om acties af te bakenen op basis van team-tags.
Waarom: Permission boundaries maken veilige self-service mogelijk en voorkomen privilege-escalatie; ABAC vermindert de wildgroei van policies en blijft afgestemd op identiteitsattributen.

Verhard netwerkpaden met VPC endpoints en PrivateLink

Actie: Verwijder IGW’s/NAT’s uit applicatie-subnets. Maak interface endpoints voor KMS, Secrets Manager, SSM, ECR, CloudWatch, en gateway endpoints voor S3/DynamoDB met restrictieve endpoint policies. Publiceer interne platformservices via NLB’s met PrivateLink voor cross-account gebruik.
Waarom: Privéconnectiviteit elimineert blootstelling aan het internet en zorgt ervoor dat services bereikbaar blijven in afgesloten omgevingen.

Implementeer een KMS-sleutelstrategie met grants voor cross-account AMI’s

Actie: Maak CMK’s per omgeving met op rollen afgestemde key policies. Versleutel in het image-building account de golden AMI’s en deel ze. Werk de CMK-policy bij om de doelaccounts toe te staan grants aan te maken, en maak vervolgens grants aan voor service-linked roles in die doelaccounts.
Waarom: Grants bieden afgebakende, auditeerbare delegatie zonder voor elke consumer de key policies te hoeven aanpassen, waardoor Auto Scaling kan opstarten vanaf versleutelde AMI’s over accounts heen.

Standaardiseer de rotatie van secrets en cross-account toegang

Actie: Sla database- en API-credentials op in Secrets Manager. Implementeer Lambda-rotatie voor niet-RDS-doelen en activeer de ingebouwde rotatie voor RDS. Voor gedeelde platform-secrets, koppel resource-based policies die GetSecretValue toekennen aan consumer-rollen in andere accounts en zorg ervoor dat CMK-policies decryptie toestaan. Plaats de rotatie-Lambda’s in VPC’s met de benodigde endpoints.
Waarom: Geautomatiseerde rotatie vermindert het risico van credentials; resource-policies met KMS-afstemming maken veilig cross-account gebruik mogelijk met behoud van least privilege en audittrails.

Deze architectuur geeft Expedia Group afdwingbare guardrails, aantoonbare compliance, geautomatiseerde fixes en strikt gecontroleerde paden voor gegevenstoegang, en dat alles met behoud van de snelheid van ontwikkelaars door veilige self-service en privéconnectiviteit.

← Monitoring · Alle domeinen · Containers en Serverless-operaties →

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