Amazon SCS-C02: Encryptie, KMS en Secrets — 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.

Typen AWS KMS-sleutels, beleidsregels en toegangscontrole

AWS KMS ondersteunt drie brede categorieën sleutels, en de juiste keuze bepaalt wie het sleutelmateriaal beheert, waar het zich bevindt en hoe het geroteerd kan worden. AWS-owned keys zijn onzichtbaar voor jou, kosten niets en worden gebruikt door services zoals S3 wanneer je SSE-S3 inschakelt. AWS-managed keys (met alias aws/<service>) laten een service namens jou versleutelen, maar je kunt hun key policy niet aanpassen, waardoor ze ongeschikt zijn voor cross-account toegang of fijnmazig beheer. Customer-managed keys (CMK’s) zijn het werkpaard: jij beheert de key policy, rotatie (jaarlijks automatisch of on-demand), grants, aliassen en de verwijderingsperiode.

Twee gespecialiseerde varianten zijn van belang. Geïmporteerd sleutelmateriaal wordt gebruikt wanneer regelgeving of BYOK-eisen je dwingen om sleutelmateriaal buiten AWS te genereren en het in een KMS-sleutel te importeren. Geïmporteerd materiaal is de enige manier om een expliciete vervaldatum voor sleutelmateriaal te configureren—door AWS gegenereerde CMK’s vervallen nooit. Je kunt geen automatische jaarlijkse rotatie van AWS inschakelen voor geïmporteerde sleutels; je moet het materiaal zelf opnieuw importeren. Multi-Region keys delen dezelfde key ID en hetzelfde materiaal over meerdere Regions via replica-sleutels, zodat een ciphertext die in us-east-1 is geproduceerd, in us-west-1 kan worden ontsleuteld zonder herversleuteling. Elke replica heeft zijn eigen onafhankelijke key policy en aliassen, maar het cryptografische materiaal wordt gesynchroniseerd.

De meest onbegrepen controlemaatregel is de KMS key policy. In tegenstelling tot de meeste AWS-resources waar IAM-beleidsregels alleen toegang verlenen, gebruiken KMS-sleutels hun key policy als de root-autorisatie. Een IAM-beleid dat kms:Decrypt op een sleutel toestaat, is krachteloos tenzij de key policy ook toegang delegeert aan IAM (via een Principal van de account-root plus een passende statement, of door de principal direct te benoemen). Daarom kan een engineer met AdministratorAccess nog steeds een AccessDenied-fout krijgen bij het aanroepen van Decrypt op een CMK waarvan de policy het account niet vertrouwt. De canonieke delegatie-statement ziet er als volgt uit:

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

Grants en ViaService-condities voegen gelaagde beperkingen toe—bijvoorbeeld door af te dwingen dat een sleutel alleen via S3 in een specifieke Region wordt gebruikt met kms:ViaService: s3.us-east-1.amazonaws.com.

Server-Side en Client-Side Encryptie

Voor S3 verschillen de twee gangbare server-side opties voornamelijk in beheer en auditeerbaarheid:

• SSE-S3 (AES-256): S3 beheert de sleutels volledig; er is geen voor de klant zichtbare key policy, geen per-sleutel CloudTrail decrypt-events en geen cross-account beheer. Voldoende voor basisversleuteling-at-rest, maar ontoereikend wanneer compliance vereist dat wordt bewezen wie de data heeft ontsleuteld.
• SSE-KMS: Gebruikt een CMK die jij beheert; elke decrypt-aanroep wordt gelogd, de key policy dwingt toegang af en je kunt beperken op basis van de encryptiecontext. Het kost meer per request en verbruikt KMS TPS-quota, dus bucket keys (BucketKeyEnabled: true) moeten worden ingeschakeld om het aantal KMS-aanroepen drastisch te verminderen.

Client-side encryptie met de AWS Encryption SDK is geschikt wanneer data versleuteld moet worden voordat het de applicatie verlaat, of wanneer de opslagservice nooit de plaintext mag zien. Workloads met een hoge doorvoersnelheid zouden de SDK moeten wrappen met de caching cryptographic materials manager (CachingCryptoMaterialsManager), die datasleutels hergebruikt voor meerdere berichten binnen configureerbare limieten voor bytes, berichten en TTL. Zonder caching activeert elke encrypt-aanroep een GenerateDataKey-request, wat de KMS-requestquota snel verzadigt en de kosten opdrijft.

from aws_encryption_sdk import CachingCryptoMaterialsManager, LocalCryptoMaterialsCache
cache = LocalCryptoMaterialsCache(capacity=100)
ccmm = CachingCryptoMaterialsManager(
    master_key_provider=mkp, cache=cache,
    max_age=600.0, max_messages_encrypted=10000)

Secrets Manager en Parameter Store

Secrets Manager slaat credentials op, versleuteld met een KMS CMK, en ondersteunt automatische rotatie via een Lambda-functie—AWS levert templates voor RDS, Redshift en DocumentDB, en custom Lambda’s kunnen al het andere afhandelen. Rotatie doorloopt een vierstaps state machine (createSecret, setSecret, testSecret, finishSecret) die nieuwe credentials onder het AWSPENDING-label plaatst voordat ze worden gepromoveerd naar AWSCURRENT. Applicaties zouden authenticatiefouten moeten opvangen, het secret vernieuwen en opnieuw proberen—dit patroon elimineert downtime omdat de vorige credential via AWSPREVIOUS kortstondig geldig blijft.

Wanneer de rotatie-Lambda binnen een VPC draait (typisch om een private RDS-instance te bereiken), heeft deze uitgaande netwerktoegang nodig tot het Secrets Manager service-eindpunt. In een private VPC zonder NAT moet je een interface VPC endpoint (com.amazonaws.<region>.secretsmanager) implementeren en de security group van de Lambda toestaan het eindpunt te bereiken op poort 443. Dit vergeten is een klassieke fout: de rotatie lijkt geconfigureerd, maar elke aanroep resulteert in een time-out.

Voor cross-Region veerkracht, gebruik een multi-Region KMS key en de replica-secret-functie van Secrets Manager. Het primaire secret in us-east-1 is versleuteld met de primaire CMK; de replica in us-west-1 ontsleutelt met behulp van de replica-CMK. Aliassen zoals alias/prod-db kunnen on-demand naar een nieuwe key ID worden verwezen voor snelle sleutelrotatie zonder de applicatiecode te wijzigen.

Het SecureString-type van Parameter Store is een lichtgewicht alternatief wanneer je geen rotatie nodig hebt. Beide services bieden dynamische referenties in CloudFormation ({{resolve:secretsmanager:MySecret:SecretString:password}}), zodat stack-templates nooit plaintext bevatten.

EBS, RDS, Aurora en Snapshot-encryptie

Encryptie-at-rest wordt per volume of per instance ingeschakeld op het moment van aanmaken en kan niet ter plekke worden omgezet. Het herstelpatroon voor een niet-conforme, onversleutelde resource is een snapshot-kopie met encryptie:

aws ec2 copy-snapshot --source-snapshot-id snap-abc \
  --source-region us-east-1 --encrypted \
  --kms-key-id alias/prod-ebs
aws ec2 create-volume --snapshot-id snap-newEncrypted ...

Voor RDS en Aurora, herstel de versleutelde snapshot naar een nieuwe instance en schakel over. Voor cross-account herstel moet je de snapshot delen en het doelaccount kms:CreateGrant en kms:Decrypt op de CMK toekennen via de key policy—alleen de snapshot delen zal mislukken omdat de bestemming de datasleutel niet kan ontsleutelen. Standaard EBS-encryptie op accountniveau moet worden ingeschakeld, zodat nieuw aangemaakte volumes altijd versleuteld zijn, ongeacht het gedrag van de aanroeper.

TLS: ACM en ALB Policies

ACM geeft kosteloos openbare certificaten uit en vernieuwt deze automatisch wanneer ze gekoppeld zijn aan geïntegreerde services (ALB, CloudFront, API Gateway). Certificaten kunnen niet worden geëxporteerd, dus voor TLS die op EC2 wordt beëindigd, is ofwel ACM Private CA (voor privé-certificaten die je kunt exporteren) of een geïmporteerd certificaat vereist. Een pragmatisch patroon: beëindig openbare TLS op de ALB met een ACM-certificaat en gebruik een self-signed of private-CA-certificaat voor de hop van ALB naar EC2 als end-to-end-encryptie vereist is. Dwing clients om moderne ciphers te gebruiken met een security policy zoals ELBSecurityPolicy-TLS13-1-2-2021-06, die TLS 1.0/1.1 en zwakke suites uitschakelt.

Veelvoorkomende Valkuilen

IAM zonder key policy. Het toekennen van kms:Decrypt in een IAM policy terwijl de key policy van de CMK de account principal weglaat, resulteert in AccessDenied. KMS beschouwt de key policy als de autoritatieve bron; IAM-permissies kunnen alleen verder beperken wat de key policy toestaat.

Rotatie-Lambda zonder VPC-endpoint. Als de Lambda in private subnets draait en de VPC geen NAT en geen secretsmanager interface-endpoint heeft, kan de rotatie-aanroep naar secretsmanager.<region>.amazonaws.com niet worden omgezet of kan er geen verbinding worden gemaakt. De security group op het endpoint moet ook poort 443 toestaan vanaf de SG van de Lambda.

SSE-S3 gelijkgesteld aan SSE-KMS. SSE-S3 gebruikt een door AWS beheerde sleutel zonder door de klant aanpasbare policy, geen decrypt-logging per object in CloudTrail en geen mogelijkheid om de sleutel cross-account te delen. Het voldoet aan de ’encrypt at rest’-vereisten, maar kan niet afdwingen welke principals specifieke objecten ontsleutelen—alleen SSE-KMS met een CMK biedt die governance.

Praktijkprobleem: Gebruiksscenario

Scenario: Meridian Financial beheert een multi-account AWS Organization met een Security-account, aparte Prod/NonProd-accounts, microservices achter een ALB in ECS/EKS, RDS/Aurora-clusters, EC2-instances met EBS en S3-data lakes. Ontwikkelaars en automatisering gebruiken momenteel een mix van door AWS beheerde sleutels, plaintext SSM-parameters en incidenteel handmatig delen van snapshots tussen accounts.

Uitdaging: Een engineer heeft per ongeluk een niet-versleutelde RDS-snapshot gedeeld met een extern account en er werden diverse API-credentials ontdekt die als plaintext SecureString-parameters waren opgeslagen, wat een risico op data-exfiltratie en ongeautoriseerde restore-toegang creëert.

Aanbevolen Aanpak:

1. Creëer een customer-managed, symmetrische AWS KMS CMK met organisatie-scope in het Security-account met een key policy die gebruik toestaat via aws:PrincipalOrgID aan member-accounts en schakel automatische rotatie in; gebruik grants voor kortstondige cross-account operaties.
2. Herstel bestaande artefacten door de niet-versleutelde RDS-snapshot en eventuele EBS-snapshots te kopiëren en daarbij de nieuwe CMK te selecteren om versleutelde kopieën te maken, en verwijder vervolgens de originele niet-versleutelde snapshots; stel account-defaults in zodat nieuwe RDS en EBS standaard versleutelde resources aanmaken.
3. Migreer secrets naar AWS Secrets Manager (of SSM Parameter Store SecureString) versleuteld met de CMK, schakel automatische rotatie in Secrets Manager in voor DB-credentials via Lambda, en beperk de toegang met resource-based policies en IAM-rollen volgens het least-privilege-principe.
4. Dwing encryptie in transit af door via ACM beheerde TLS-certificaten te provisioneren en deze te koppelen aan ALBs met een modern TLS-beleid (TLS 1.2/1.3), en configureer databases en clients om TLS-verbindingen te vereisen.
5. Voorkom herhaling met guardrails: pas Service Control Policies toe om het aanmaken/delen van niet-versleutelde snapshots en niet-versleutelde S3-puts te weigeren, schakel AWS Config-regels in voor versleutelde resources, en monitor het gebruik van KMS en Secrets Manager via CloudTrail en CloudWatch Alarms.

Rationale: Centrale CMK’s met policies op organisatieniveau, geautomatiseerde her-encryptie, Secrets Manager voor de levenscyclus van secrets, het afdwingen van TLS en preventieve guardrails volgen de AWS best practices voor least privilege en defense-in-depth om plaintext secrets en ongeautoriseerde toegang tot snapshots te elimineren.

Door de klant beheerde CMK’s: Multi-Region, geïmporteerd sleutelmateriaal en sleutelbeleid

Een door de klant beheerde CMK (Customer Managed CMK) is het beheervlak voor elke cryptografische operatie op data die u bezit in AWS. De drie eigenschappen die het vaakst bepalen of een ontwerp slaagt of een storing veroorzaakt, zijn de regio-topologie van de sleutel, de herkomst van het sleutelmateriaal en het beleid dat eraan gekoppeld is.

Multi-region sleutels zijn een set KMS-sleutels in verschillende regio’s die dezelfde key-ID en, cruciaal, hetzelfde onderliggende sleutelmateriaal delen. Ze worden niet automatisch gerepliceerd zoals DynamoDB global tables dat wel doen — u maakt expliciet replica’s aan vanuit een primaire sleutel met ReplicateKey. Omdat het sleutelmateriaal identiek is voor alle replica’s, kan ciphertext die in us-east-1 is geproduceerd, worden gedecodeerd in us-west-1 zonder cross-region KMS-aanroepen. Dit is precies de eigenschap die vereist is bij het repliceren van een Secrets Manager-secret over meerdere regio’s: het replica-secret in de failover-regio moet lokaal decodeerbaar zijn, zowel om cross-region latency bij elke GetSecretValue te elimineren als om een regionale storing van de primaire regio te overleven. Een single-region CMK kan geen Secrets Manager-replica in een andere regio ondersteunen, dus het correcte patroon is om het primaire secret te versleutelen met een multi-region CMK, de sleutel te repliceren naar de doelregio en vervolgens het secret te repliceren terwijl u naar de replica-CMK verwijst.

aws kms create-key --multi-region --region us-east-1
aws kms replicate-key --key-id mrk-abc123 \
  --replica-region us-west-1
aws secretsmanager replicate-secret-to-regions \
  --secret-id prod/db \
  --add-replica-regions Region=us-west-1,KmsKeyId=mrk-abc123

Geïmporteerd sleutelmateriaal (externe herkomst, Origin=EXTERNAL) bestaat wanneer u het ruwe AES-256-materiaal buiten AWS genereert en het importeert in een KMS-sleutelhuls. AWS heeft nooit een kopie van dat materiaal buiten het beschermde geheugen van de HSM, en er is geen back-up. Als u het geïmporteerde materiaal verwijdert — hetzij via DeleteImportedKeyMaterial of omdat de vervaldatum is verstreken — krijgt de sleutel de status PendingImport en is alle ciphertext die met die sleutel is geproduceerd onherstelbaar, tenzij u exact dezelfde bytes opnieuw importeert. Dit is het herstelpad wanneer bijvoorbeeld een EBS-volume niet kan worden gekoppeld omdat de versleutelde datasleutel niet kan worden gedecodeerd: importeer het identieke sleutelmateriaal opnieuw vanuit uw offline escrow, en het volume wordt weer bruikbaar. Er is geen hersteloptie aan de kant van AWS, geen rotatietruc en geen supportticket dat verwijderd geïmporteerd materiaal kan herstellen. Behandel de offline kopie als tier-zero infrastructuur.

Sleutelbeleid (Key policies) is de ‘root of trust’ voor elke KMS-sleutel. In tegenstelling tot alleen IAM, vereist KMS een expliciete ‘allow’ in het sleutelbeleid zelf; een IAM-beleid dat kms:Decrypt toestaat, is niet effectief tenzij het sleutelbeleid delegeert aan IAM ("Principal": {"AWS": "arn:aws:iam::111122223333:root"} gecombineerd met een voorwaarde). Voor cross-account gebruik moet het beleid van de sleutel expliciet het externe account of de principal benoemen, en het externe account moet vervolgens via IAM toestemming verlenen aan zijn eigen gebruikers. Het vergeten van de kant van het sleutelbeleid is de meest voorkomende oorzaak van cross-account Secrets Manager-fouten — het resourcebeleid van Secrets Manager staat de externe principal toe om GetSecretValue aan te roepen, maar de onderliggende Decrypt-operatie mislukt omdat de CMK de aanroeper nog steeds weigert.

Patronen voor Secrets Manager en Parameter Store SecureString

Secrets Manager en SSM Parameter Store SecureStrings delegeren beide de versleuteling aan KMS, maar ze verschillen in kosten, rotatiesemantiek en cross-region gedrag. Secrets Manager ondersteunt native multi-region replicatie, versiebeheer met staging labels (AWSCURRENT, AWSPENDING) en rotatie ondersteund door Lambda. Parameter Store SecureString is goedkoper, integreert met hiërarchische paden en werkt goed voor configuratie-achtige secrets die niet vaak roteren.

Voor cross-account toegang moet u zowel het resourcebeleid van het secret (of het IAM-beleid in het consumer-account van Parameter Store) als het KMS-sleutelbeleid van de versleutelende CMK bijwerken. Aannemen dat alleen de permissies van Secrets Manager voldoende zijn, is onjuist, omdat de ophaalworkflow altijd een impliciete kms:Decrypt uitvoert op de CMK; zonder een ‘allow’ in het sleutelbeleid voor het externe account, ontvangt de aanroeper een AccessDeniedException bij de Decrypt-stap, ook al is aan het beleid van het secret zelf voldaan.

• Secrets Manager: beheerde rotatie, JSON-structuur, ~$0,40/secret/maand, ingebouwde multi-region replicatie
• Parameter Store SecureString (Advanced): goedkoper voor veel waarden, 8 KB per parameter, geen ingebouwde cross-region replicatie
• Parameter Store SecureString (Standard): gratis niveau voor met KMS versleutelde parameters tot 4 KB, geen rotatieframework

Envelope-encryptie, Bucket Keys en Grant Tokens

Envelope-encryptie betekent dat KMS nooit uw bulkdata aanraakt. U roept GenerateDataKey aan, wat zowel een plaintext datasleutel (lokaal gebruikt om uw payload te versleutelen met AES-GCM) als een versleutelde kopie van die datasleutel (opgeslagen naast de ciphertext) retourneert. Om te ontsleutelen, roept u Decrypt aan op de ingepakte datasleutel en leidt u de plaintext sleutel lokaal opnieuw af. Dit patroon is essentieel omdat KMS request quota’s heeft (per regio, per sleutel) en prijzen per API-aanroep. Als u elk record van 4 KB versleutelt met een directe Encrypt-aanroep, zult u tegen throttling en hoge kosten aanlopen; als u één datasleutel per batch of per bestand genereert, schaalt de doorvoer lineair met uw lokale crypto-bibliotheek.

S3 Bucket Keys passen hetzelfde principe toe binnen S3 voor SSE-KMS. Zonder een bucket key genereert elke PUT en GET van een SSE-KMS-object een GenerateDataKey- of Decrypt-aanroep. Op een bucket die duizenden objecten per seconde ontvangt, leidt dit zowel tot KMS-throttling als tot een verrassend hoge KMS-rekening. Het inschakelen van een bucket key zorgt ervoor dat S3 één kortlevende sleutel op bucket-niveau genereert en deze hergebruikt voor veel objecten, waardoor het volume van KMS-requests met ordes van grootte wordt verminderd:

aws s3api put-bucket-encryption --bucket app-data \
  --server-side-encryption-configuration '{
    "Rules":[{
      "ApplyServerSideEncryptionByDefault":{
        "SSEAlgorithm":"aws:kms","KMSMasterKeyID":"alias/app"},
      "BucketKeyEnabled":true}]}'

Grants zijn een alternatief voor key policies voor tijdelijke, fijnmazige delegatie. Ze zijn operationeel belangrijk vanwege eventual consistency: nadat CreateGrant een resultaat teruggeeft, is de grant niet onmiddellijk zichtbaar voor elk KMS-eindpunt in de regio. Als een client een paar milliseconden later een Encrypt-operatie probeert, kan deze een AccessDeniedException ontvangen. De response body van CreateGrant bevat een GrantToken-string die, wanneer meegegeven bij volgende KMS-aanroepen via de --grant-tokens-parameter, KMS dwingt de grant onmiddellijk te honoreren, ongeacht de propagatiestatus.

TOKEN=$(aws kms create-grant --key-id $KEY \
  --grantee-principal arn:aws:iam::111122223333:role/worker \
  --operations Encrypt Decrypt --query GrantToken --output text)
aws kms encrypt --key-id $KEY --plaintext fileb://payload \
  --grant-tokens "$TOKEN"

Vertrouwen op een ‘retry-with-backoff’-mechanisme in plaats van de grant token is een geldige maar inferieure oplossing — het verspilt latency en faalt nog steeds onder hoge belasting. Het canonieke antwoord is altijd: retourneer de grant token vanuit de service die de grant aanmaakt, en vereis dat aanroepers deze presenteren bij hun eerste operatie.

Praktijkprobleem: Gebruikersscenario

Scenario: Meridian Financial beheert een multi-account AWS-omgeving waarin PII van klanten wordt gehost in S3, transactionele databases in RDS, en serverless verwerking via Lambda. Ze gebruiken Customer Managed CMK’s met geïmporteerd sleutelmateriaal om te voldoen aan regionale regels voor sleutelbeheer (‘key custody’) en repliceren sleutels naar een tweede regio voor disaster recovery.

Uitdaging: Een recente audit heeft een verkeerd geconfigureerde KMS key policy gevonden die cross-account ontsleuteling toestond. Een externe auditor heeft tijdelijk toegang nodig om een subset van S3-objecten te ontsleutelen. Meridian heeft ook veilige rotatie van secrets en efficiënte encryptie voor grote objecten nodig om de kosten van KMS-requests te beheersen.

Aanbevolen Aanpak:

1. Vervang de verkeerd geconfigureerde CMK-policy in AWS KMS door een ’least-privilege’-policy die expliciet alleen de benodigde IAM principals en rollen toestaat, en maak een multi-Region replica CMK voor DR met behulp van KMS multi-Region keys.
2. Herimporteer of plan lifecycle management voor geïmporteerd sleutelmateriaal volgens de compliance-vensters en schakel automatische meldingen voor het verlopen/roteren van sleutelmateriaal in met AWS Config en EventBridge.
3. Maak voor de auditor een KMS grant aan met een korte TTL en gebruik de grant token onmiddellijk in de assume-role-sessie van de auditor om tijdelijke ontsleutelingsoperaties toe te staan zonder de key policy te wijzigen.
4. Verplaats langlevende credentials naar AWS Secrets Manager met op Lambda gebaseerde rotatie die gekoppeld is aan de onderliggende service (RDS of API-sleutels). Sla infrastructuurparameters op als Systems Manager Parameter Store SecureString voor niet-roterende items, waarbij encryptie met de CMK en strikte resource-based policies worden afgedwongen.
5. Implementeer envelope-encryptie voor grote S3-objecten door KMS GenerateDataKey (Encrypt/Decrypt) aan te roepen in de applicatiecode of via de AWS SDK, en schakel S3 Bucket Keys in om KMS-requests en -kosten te verminderen voor server-side encryptie van grote objecten.
6. Schakel CloudTrail-logging en KMS key usage-logging in, en maak CloudWatch Alarms/GuardDuty-regels aan om te waarschuwen bij onverwachte ontsleutelingsoperaties of het aanmaken van grants.

Rationale: Deze aanpak dwingt ’least-privilege’ toegang tot sleutels af, waarborgt de compliance voor geïmporteerd materiaal en multi-regio continuïteit, gebruikt tijdelijke grants voor veilige toegang door derden, centraliseert secrets met rotatie, en optimaliseert het KMS-gebruik en de kosten volgens de best practices van AWS.

← Logging · Alle domeinen · Gegevensbescherming en S3 →

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

Blader door Amazon →