Amazon SCS-C02: Governance, Configuratie en Automatisering — Studiegids

By Laurynas Brazys · 24 July 2026 · #amazon #scs-c02 #certification #exam-prep #study-guide

Onderdeel van de AWS Security Specialty SCS-C02 — Studiegids. Oefen met geverifieerde antwoorden in het Amazon-examencentrum, of doe getimede oefentests op ExamRoll.io.

Service Control Policies en Guardrails op Organisatorisch Niveau

Service Control Policies (SCP’s) vormen de buitenste grens van wat een principal in een AWS Organization kan doen. Een SCP is geen IAM-policy — het verleent geen rechten, het definieert alleen de maximale permissies die beschikbaar zijn voor accounts binnen een OU of de gehele organisatie. Een Allow in een IAM-policy, resource-policy of permissions boundary is volledig krachteloos als een SCP de actie weigert. Deze asymmetrie is precies waarom SCP’s het juiste instrument zijn voor organisatiebrede guardrails: Regio-restricties, verboden services, bescherming van centraal beheerde IAM-rollen en het afdwingen van encryptie bij het aanmaken van resources.

Een canoniek SCP dat het aanmaken van niet-versleutelde DynamoDB-tabellen en S3-buckets weigert, ziet er als volgt uit:

Version: "2012-10-17"
Statement:
  - Sid: DenyUnencryptedS3
    Effect: Deny
    Action: s3:CreateBucket
    Resource: "*"
    Condition:
      StringNotEquals:
        s3:x-amz-server-side-encryption-aws-kms-key-id: !Ref CmkArn
  - Sid: DenyUnencryptedDdb
    Effect: Deny
    Action: dynamodb:CreateTable
    Resource: "*"
    Condition:
      "Null":
        dynamodb:SSESpecificationEnabled: "true"

Een veelvoorkomende valkuil is proberen af te dwingen dat “niemand in de organisatie us-east-2 mag gebruiken” of “niemand CloudTrail mag uitschakelen” via IAM-policies die in elk account zijn gekoppeld. Zelfs met een afstemming van permissions boundary en identity policy kan een lokale beheerder zichzelf een ontsnappingsroute verschaffen. Alleen een SCP die op de root of OU wordt toegepast, is betrouwbaar, omdat deze zelfs de root-gebruiker van member-accounts beperkt (met de kleine uitzondering van een handvol niet-beperkbare acties).

SCP’s moeten ook break-glass- en gedelegeerde beheerdersrollen beschermen: voeg een expliciete Deny toe voor elke actie die gericht is op een rol zoals OrganizationAccountAccessRole of SecurityAudit, tenzij de aws:PrincipalArn van de aanroeper overeenkomt met een goedgekeurde lijst.

AWS Config, Conformance Packs en Multi-Account Handhaving

AWS Config biedt de continue evaluatielaag die een aanvulling is op SCP’s (die voorkomen) met detectie (die afwijkingen observeert en rapporteert). Een conformance pack is een bundel van Config-regels — zowel beheerde regels zoals s3-bucket-server-side-encryption-enabled als custom regels ondersteund door Lambda of Guard — verpakt als een enkel, implementeerbaar YAML-artefact met optionele herstelacties.

Om een standaard baseline organisatiebreed uit te rollen, worden twee mechanismen gecombineerd:

• CloudFormation StackSets vanuit het management-account met service-managed permissies en AutoDeployment: Enabled, zodat elk nieuw account dat lid wordt van de organisatie automatisch een stack ontvangt die de Config recorder en delivery channel inschakelt. Dit lost het bootstrap-probleem op: een conformance pack kan een account niet evalueren waar Config niet is ingeschakeld.

• Conformance packs geïmplementeerd vanuit het delegated administrator-account (bijvoorbeeld security-01) met behulp van PutOrganizationConformancePack. Dit verspreidt een consistente set regels naar elk huidig en toekomstig account zonder elk account handmatig te hoeven aanpassen.

Het delegated-administrator + aggregator-patroon is belangrijk: het stelt het securityteam in staat om de compliance van alle accounts op één plek te zien, terwijl applicatieteams nog steeds lokaal hun eigen regels kunnen toevoegen. Het rechtstreeks implementeren van dezelfde regels vanuit het management-account zou werken, maar schendt het principe van ’least privilege’ en blokkeert audits op scheiding van taken (separation of duties).

CloudFormation Guard, StackSets en Service Catalog

Preventie moet ‘shift left’ plaatsvinden. CloudFormation Guard (cfn-guard) is een policy-as-code engine die CloudFormation-templates (of elke JSON/YAML) parseert en deze evalueert aan de hand van declaratieve regels vóór de implementatie. Een Guard-regel ziet er als volgt uit:

rule s3_encrypted {
  Resources.*[ Type == "AWS::S3::Bucket" ] {
    Properties.BucketEncryption exists
    Properties.BucketEncryption.ServerSideEncryptionConfiguration[*] {
      ServerSideEncryptionByDefault.SSEAlgorithm == "aws:kms"
    }
  }
}

Dit integreren in een CI/CD-stap — meestal als een Docker-containerstap die cfn-guard validate -r rules.guard -d template.yaml uitvoert — laat de pipeline falen voordat een niet-compliant resource wordt aangemaakt. Bij een overtreding publiceert de pipeline naar een SNS-topic waarop het securityteam is geabonneerd, waardoor ze zichtbaarheid krijgen zonder een handmatige goedkeuringsbottleneck te worden. Alleen vertrouwen op StackSets of CloudFormation change-set reviews om het securityteam te informeren is een valkuil: geen van beide services geeft per-resource compliance-bevindingen uit, en tegen de tijd dat een stack is aangemaakt, bestaat de resource al in het account.

Service Catalog vult Guard aan voor de ’last mile’. In plaats van ontwikkelaars willekeurige CloudFormation te laten schrijven, publiceert het platformteam goedgekeurde producten (VPC-baselines, RDS-patronen, EKS-clusters) als Service Catalog-portfolio’s die via AWS RAM met andere accounts worden gedeeld. Ontwikkelaars starten deze met beperkte parameters, en een ’launch constraint’ IAM-rol provisioneert resources met verhoogde permissies die de ontwikkelaar zelf niet heeft. Dit levert een auditeerbaar, self-service implementatiemodel op waarbij het onderliggende template de Guard-controles al heeft doorstaan.

StackSets zelf vereisen de juiste inrichting: gebruik het SERVICE_MANAGED permissiemodel bij implementatie vanuit het org management-account, schakel trusted access voor CloudFormation in Organizations in en configureer execution-rollen zorgvuldig. Het AdministrationRoleARN/ExecutionRoleName-paar (in self-managed modus) of de service-linked roles (in service-managed modus) moeten iam:PassRole toestaan voor de CloudFormation service-rol die daadwerkelijk de resources aanmaakt. Het vergeten van een CloudFormation service-rol en in plaats daarvan vertrouwen op de credentials van de implementerende gebruiker leidt tot periodieke AccessDenied-fouten op iam:PassRole — een veelvoorkomende oorzaak van mislukte StackSet-operaties. Het juiste patroon is één toegewijde service-rol per stack met alleen de permissies die nodig zijn om de gedeclareerde resourcetypes aan te maken.

Geautomatiseerde Remediatie-Pipelines

Wanneer Config non-compliance detecteert, moet het herstel automatisch zijn voor alles wat veilig zelf kan worden hersteld. De event-flow is als volgt:

• Config publiceert een Compliance Change-event naar de standaard event bus.

• Een EventBridge-regel filtert op NON_COMPLIANT-bevindingen voor specifieke regels en stuurt deze door naar een Systems Manager Automation-document (voor eenvoudige, idempotente fixes zoals het inschakelen van S3-encryptie), een Lambda-functie (voor fixes op API-niveau), of een Step Functions state machine (voor workflows met meerdere stappen die goedkeuringen, retries of cross-service orkestratie vereisen).

Als bijvoorbeeld s3-bucket-public-read-prohibited wordt geactiveerd, herstelt een SSM Automation runbook AWS-DisableS3BucketPublicReadWrite dit. Voor complexere flows — bijvoorbeeld, een KMS key policy die afwijkt en moet worden gesynchroniseerd terwijl het eigenaarsteam wordt geïnformeerd — coördineert Step Functions: lees de huidige policy, vergelijk deze met de ‘golden version’, roep kms:PutKeyPolicy aan, en post vervolgens naar SNS. Het opslaan van de remediatielogica in Step Functions in plaats van in een enkele Lambda-functie biedt inzicht (observability) in elke stap en duidelijke retry-semantiek.

IAM Access Analyzer en Policy Validatie

IAM Access Analyzer beantwoordt twee verschillende vragen. Ten eerste identificeren ’external access analyzers’ resources (S3, KMS, IAM-rollen, Lambda, SQS, Secrets Manager) waarvan de policies toegang verlenen aan principals buiten een gedefinieerde ‘zone of trust’ — hetzij het account, hetzij de organisatie. Activeer de analyzer op organisatieniveau vanuit het ‘delegated administrator’-account, zodat bevindingen centraal worden geaggregeerd.

Ten tweede worden Access Analyzer policy validation en policy generation uitgevoerd tijdens het schrijven van de policy (‘authoring’). aws accessanalyzer validate-policy retourneert beveiligingswaarschuwingen, fouten en suggesties (bijvoorbeeld het signaleren van een te ruime Resource: "*" in combinatie met gevoelige acties). Integreer dit in dezelfde CI/CD-fase als cfn-guard, zodat IAM-policies die zijn ingebed in CloudFormation worden gecontroleerd vóór de deployment. Access Analyzer kan ook een ’least-privilege’ policy genereren op basis van de CloudTrail-geschiedenis, waarbij een wildcard-policy wordt vervangen door de exacte acties die een rol daadwerkelijk heeft gebruikt. Dit is het mechanische antwoord op “dwing least privilege af voor datatoegang”, naast een afgebakende KMS key policy die kms:Decrypt alleen toestaat wanneer de aanroepende service S3, DynamoDB, Lambda of EKS is via kms:ViaService-condities.

Praktijkprobleem: Use-Case Scenario

Scenario: Meridian Financial beheert een multi-account AWS Organization met productie-, staging-, sandbox- en een gecentraliseerd security-account. Ze deployen workloads met een mix van CloudFormation-templates en door ontwikkelaars gemaakte templates in de sandbox; het eigenaarschap is gefedereerd over teams, en ze moeten voldoen aan interne governance voor data-encryptie en ’least-privilege’ toegang.

Uitdaging: Ontwikkelaars in de sandbox hebben per ongeluk openbare S3-buckets en te ruime IAM-policies gemaakt die naar andere accounts zijn gepropageerd. Het security-team mist consistente, geautomatiseerde handhaving en template-validatie binnen de hele Organisatie.

Aanbevolen Aanpak:

1. Maak Service Control Policies (SCPs) op organisatieniveau om openbare S3-toegang te weigeren, bucket-encryptie af te dwingen en geprivilegieerde IAM-acties te beperken op de ‘Organization root’ om preventieve ‘guardrails’ te bieden.
2. Deploy vanuit het centrale security-account een AWS Config aggregator en Conformance Packs met behulp van CloudFormation StackSets naar elk account en elke regio om continu de openbare toegang tot S3, patronen voor het koppelen van IAM-policies en encryptie-compliance te evalueren.
3. Integreer CloudFormation Guard (cfn-guard) regels in de CI/CD-pipeline (CodePipeline/CodeBuild) en vereis het gebruik van Service Catalog-producten voor goedgekeurde infrastructuur, zodat templates worden gevalideerd en alleen compliant stacks kunnen worden geprovisioneerd.
4. Activeer geautomatiseerde remediatie met AWS Config via SSM Automation-documenten of Lambda-runbooks voor bevindingen met hoge prioriteit (automatisch blokkeren van openbare S3, herstellen van te ruime IAM-policies) en trigger aanvullende workflows via EventBridge.
5. Voer IAM Access Analyzer en policy-validatie centraal uit, neem de bevindingen op in Security Hub (‘ingest’), en automatiseer het aanmaken van tickets of het uitvoeren van ‘remediation playbooks’ voor ontdekte cross-account of te ruime policies.

Rationale: Deze aanpak combineert preventieve, organisatiebrede ‘guardrails’ (SCPs), continue detectie (Config/Conformance Packs), ‘shift-left’ template-validatie (cfn-guard/Service Catalog), en geautomatiseerde remediatie met IAM Access Analyzer om ’least privilege’ af te dwingen en consistente multi-account governance te bereiken volgens de best practices van AWS.

AWS Config: Organization Rules, Aggregators en Gedelegeerd Beheer

AWS Config is de basis van detectieve compliance op AWS. Het legt continu de configuraties van resources vast en evalueert deze aan de hand van regels — ofwel door AWS beheerd (bijvoorbeeld restricted-ssh, vpc-flow-logs-enabled, encrypted-volumes) ofwel aangepast (ondersteund door Lambda of Guard). Op enterpriseschaal zijn drie architectonische beslissingen belangrijker dan de regels zelf: hoe regels worden uitgerold, hoe bevindingen worden geaggregeerd en wie eigenaar is van de tooling.

Voor implementaties over meerdere accounts en meerdere regio’s onder AWS Organizations is het juiste patroon om een gedelegeerd beheerdersaccount aan te wijzen (meestal het security- of auditaccount, niet het managementaccount) via aws organizations register-delegated-administrator --service-principal=config-multiaccountsetup.amazonaws.com. Gebruik vanuit dat account PutOrganizationConfigRule of PutOrganizationConformancePack om regels uit te rollen naar elk lidaccount en elke regio. Als u gedelegeerd beheer overslaat, moet u Config handmatig in elk account inschakelen of alles vanuit het managementaccount uitvoeren — dit laatste schendt de scheiding van verantwoordelijkheden en het eerste schaalt niet verder dan een handvol accounts.

Organisatieregels pushen één enkele regeldefinitie; aggregators verzamelen de resulterende evaluaties. Maak een aggregator aan in het gedelegeerde beheerdersaccount met een OrganizationAggregationSource die alle accounts en regio’s omvat. Het dashboard van de aggregator beantwoordt dan vragen als “welke VPC’s in 200 accounts hebben geen Flow Logs?” zonder te hoeven jongleren met cross-account rollen. Merk op dat aggregators read-only zijn: ze maken de compliancestatus zichtbaar, maar voeren zelf geen herstelacties uit.

Conformance Packs voor Basislijn Handhaving

Een conformance pack bundelt Config-regels en hun herstelacties in één enkel YAML-sjabloon. AWS levert packs die zijn afgestemd op frameworks zoals PCI DSS, HIPAA, NIST 800-53 en CIS. Het implementeren van een organization conformance pack vanuit het gedelegeerde beheerdersaccount richt zich op specifieke OU’s — bijvoorbeeld door een strenger pack toe te passen op de Prod OU dan op Sandbox. Dit is de meest efficiënte manier om een consistente basislijn af te dwingen over honderden accounts, omdat één enkele API-aanroep de regelset en de bijbehorende herstelkoppelingen overal tegelijk propageert.

Resources:
  EncryptedVolumesRule:
    Type: AWS::Config::ConfigRule
    Properties:
      ConfigRuleName: encrypted-volumes
      Source:
        Owner: AWS
        SourceIdentifier: ENCRYPTED_VOLUMES
  EncryptedVolumesRemediation:
    Type: AWS::Config::RemediationConfiguration
    Properties:
      ConfigRuleName: encrypted-volumes
      TargetType: SSM_DOCUMENT
      TargetId: AWSConfigRemediation-EncryptS3BucketVolume
      Automatic: true
      MaximumAutomaticAttempts: 3
      RetryAttemptSeconds: 60

Automatische Herstelpatronen

Er zijn twee canonieke herstelpaden, en de keuze daartussen hangt af van de vereisten voor latentie en complexiteit.

Het Config-native herstelpad gebruikt AWS::Config::RemediationConfiguration om een SSM Automation-runbook aan te roepen telkens wanneer een regel NON_COMPLIANT rapporteert. AWS biedt vooraf gebouwde runbooks zoals AWS-EnableVPCFlowLogs, AWSConfigRemediation-RemoveUnrestrictedSourceIngressRules en AWSConfigRemediation-EncryptSNSTopic. Dit pad is declaratief, integreert naadloos met conformance packs en is ideaal wanneer een vertraging van enkele minuten acceptabel is.

Het EventBridge-gestuurde pad is vereist wanneer latentie van belang is of wanneer aangepaste orkestratie nodig is. Config zendt een Config Rules Compliance Change-event uit bij elke statusovergang. Een EventBridge-regel filtert op detail.newEvaluationResult.complianceType = NON_COMPLIANT en stuurt dit door naar een Lambda-functie (of Step Function, of rechtstreeks naar een SSM-runbook). Omdat EventBridge binnen enkele seconden na de evaluatie wordt geactiveerd, worden herstelvensters van minder dan een minuut haalbaar.

{
  "source": ["aws.config"],
  "detail-type": ["Config Rules Compliance Change"],
  "detail": {
    "configRuleName": ["restricted-ssh"],
    "newEvaluationResult": { "complianceType": ["NON_COMPLIANT"] }
  }
}

De Lambda-handler roept vervolgens RevokeSecurityGroupIngress aan op de foutieve SG. Welk pad u ook kiest, de automatisering moet een IAM-rol aannemen met de minimale permissies om de doelresource te wijzigen. Een veelvoorkomende foutmodus is een Config-regel waarvan de compliancestatus eindeloos heen en weer springt tussen NON_COMPLIANT en COMPLIANT, omdat het herstel-runbook een AccessDenied-fout krijgt — Config registreert de aanroep maar gaat stilzwijgend door. Inspecteer altijd de uitvoeringsgeschiedenis van SSM Automation en geef de runbook-rol de specifieke wijzigingspermissies die het nodig heeft (bijvoorbeeld ec2:CreateFlowLogs, iam:PassRole voor de flow-log delivery-rol, en logs:CreateLogGroup).

Systems Manager Automation en Patch Manager

SSM Automation-runbooks zijn het werkpaard voor imperatief herstel. Het zijn geversioneerde YAML/JSON-documenten die stappen beschrijven — API-aanroepen, goedkeuringen, vertakkingen — die worden uitgevoerd door een door u gespecificeerde IAM-rol. Naast door Config getriggerd herstel, voeren ze geplande hygiënetaken uit: het rouleren van access keys, het taggen van niet-gekoppelde EBS-volumes, of het beëindigen van gestopte instances na 30 dagen.

Patch Manager is een subsysteem van SSM dat besturingssystemen compliant houdt met een patch-basislijn (een set van goedgekeurde patches, classificaties en ernstfilters). Instances worden gegroepeerd in patchgroepen via de Patch Group-tag; een onderhoudsvenster plant het AWS-RunPatchBaseline-document in om op hen te worden uitgevoerd. De compliancestatus vloeit terug naar Config en Security Hub, waarmee de cirkel tussen de status op OS-niveau en de organisatorische rapportage wordt gesloten.

Service Catalog, CloudFormation StackSets en Preventive Guardrails

Detectie en herstel zijn reactief. Om non-compliance te voorkomen, gebruik je preventieve controles:

• Service Catalog publiceert gecureerde, geparametriseerde CloudFormation-templates als producten. Ontwikkelaars lanceren goedgekeurde patronen (een ‘hardened’ VPC, een versleuteld RDS-cluster) zonder dat ze IAM-permissies nodig hebben voor de onderliggende services, wat een scheiding van taken afdwingt tussen het platformteam en de consumenten.

• CloudFormation StackSets implementeert identieke stacks over accounts en Regions heen. Met service-managed permissies en OU-targeting, landt een enkele operatie Config-recorders, IAM-rollen of GuardDuty-detectoren in elk account in de organization, inclusief nieuw aangemaakte accounts via automatische implementatie.

• Service Control Policies (SCPs) zijn het enige mechanisme dat een API-call direct kan weigeren op de grens van de organization. Config en SSM kunnen een RunInstances-call die versleuteling mist niet voorkomen — ze kunnen deze alleen achteraf detecteren en herstellen. Pogingen om harde verboden af te dwingen (“nooit openbare S3-buckets”) puur met Config-regels, laten een tijdsvenster open tussen het aanmaken van de resource en het herstel. Koppel een detectieve Config-regel aan een SCP zoals een s3:PutBucketPublicAccessBlock-weigering om dit gat te dichten.

Disaster Recovery: Back-up, Templates en Broncodebeheer

Om aan RPO/RTO-doelstellingen te voldoen, moeten zowel data als infrastructuurdefinities herstelbaar zijn. AWS Backup centraliseert back-upbeleid voor EBS, RDS, DynamoDB, EFS en FSx; back-upbeleid op organization-niveau dwingt plannen af over de member-accounts, en cross-Region, cross-account kopieën beschermen tegen het verlies van een Region en accountcompromittering. De RPO wordt bepaald door de back-upfrequentie; de RTO hangt af van de herstelmechanismen (een DynamoDB PITR-restore duurt minuten; een RDS-snapshot-restore over Regions kan een uur duren).

Infrastructuurherstel is afhankelijk van CloudFormation-templates die zijn opgeslagen in CodeCommit (of een andere Git-provider) als de enige ‘source of truth’. Het opnieuw implementeren van een StackSet vanuit versiebeheerde templates herbouwt VPC’s, IAM en applicatie-stacks in een herstel-Region binnen enkele minuten. Templates alleen in de console bewaren — zonder een repo — maakt de RTO onvoorspelbaar omdat er geen reproduceerbaar artefact is.

Analyse van Valkuilen

Drie misvattingen leiden consequent tot foute antwoorden. Ten eerste, Config behandelen als een preventieve controle: het evalueert nadat CloudTrail de wijziging heeft vastgelegd, dus echte verboden vereisen SCP’s. Ten tweede, het configureren van herstel zonder een IAM-rol met de juiste scope — het SSM-document bestaat en de Config-regel wordt geactiveerd, maar het runbook faalt stilzwijgend door permissiefouten. Ten derde, services voor de hele organization uitvoeren vanuit het management-account in plaats van een ‘delegated administrator’ te registreren, wat handmatige activering per account afdwingt en de correcte werking van aggregators voor de hele organization blokkeert.

Praktijkprobleem: Use-Case Scenario

Scenario: Meridian Financial beheert een multi-account AWS-omgeving met afzonderlijke productie-, ontwikkelings- en security-accounts onder AWS Organizations. Het securityteam moet continue compliance met interne controles en regelgevers aantonen, terwijl het honderden EC2-instances, S3-buckets en Lambda-functies over verschillende regions beheert.

Uitdaging: Een recente audit bracht niet-gepatchte EC2-instances, openbare S3-buckets en inconsistente handhaving van de baseline over accounts aan het licht; herstel is handmatig en traag, en preventieve controles worden niet uniform toegepast.

Aanbevolen Aanpak:

1. Wijs het Security-account aan als de AWS Config ‘delegated administrator’ en implementeer een AWS Config Aggregator via CloudFormation StackSets om configuratie- en compliancegegevens van alle accounts en regions te verzamelen.
2. Implementeer AWS Config Conformance Packs op organization-niveau vanuit het security-account (met behulp van StackSets) om baseline-controles te codificeren (S3 publieke toegang, versleuteling, tagging), zodat dezelfde regels consistent worden toegepast.
3. Koppel automatische herstelacties van AWS Config aan regels met een hoog risico die AWS Systems Manager Automation-documenten aanroepen (geregistreerd als herstel-runbooks), zodat overtredingen automatisch SSM Automation- of Run Command-herstel activeren.
4. Gebruik AWS Systems Manager Patch Manager met SSM Patch Baselines en State Manager om patchgroepen te definiëren en OS-patching over accounts heen te automatiseren; voer de resultaten van patch-compliance in de Config Aggregator in.
5. Publiceer goedgekeurde CloudFormation-templates in AWS Service Catalog en gebruik CloudFormation StackSets om compliant stacks te implementeren of bij te werken; dwing preventieve ‘guardrails’ af met AWS Organizations Service Control Policies om het aanmaken van niet-toegestane resources te blokkeren (bijvoorbeeld het uitschakelen van het aanmaken van publieke S3-buckets).
6. Configureer Amazon EventBridge (CloudWatch Events) en SNS om het securityteam te informeren bij non-compliance en om aanvullende SSM Automation-workflows te activeren voor complexe incidenten.

Rationale: Het centraliseren van detectie met Config Aggregator en conformance packs, het automatiseren van herstel via SSM, en het afdwingen van preventieve ‘guardrails’ via Service Catalog/StackSets en SCP’s zorgt voor consistente, auditeerbare controles en snel herstel in lijn met de AWS best practices voor security, compliance en ’least privilege’.

← Edge en Applicatiebeveiliging · Alle domeinen · Kwetsbaarheden →

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

Blader door Amazon →