Amazon SCS-C02: Gegevensbescherming en S3 — Studiegids
Onderdeel van de AWS Security Specialty SCS-C02 — Studiegids. Oefen met geverifieerde antwoorden in het Amazon-examencentrum, of doe getimede oefentests op ExamRoll.io.
S3 Bucket Policies, Resource ARN’s en Expliciete Denies
Een S3 bucket policy is een resource-gebaseerd JSON-document dat wordt geëvalueerd naast identity-based policies. Twee regels domineren het gedrag ervan. Ten eerste wint een expliciete Deny altijd: ongeacht hoeveel Allow-statements er zijn, een overeenkomstige Deny blokkeert het verzoek. Ten tweede moet het Resource-element exact overeenkomen met het ARN-patroon van de actie. Acties op bucket-niveau zoals s3:ListBucket werken op arn:aws:s3:::my-bucket, terwijl acties op object-niveau zoals s3:GetObject en s3:PutObject werken op arn:aws:s3:::my-bucket/*. Een veelvoorkomende misconfiguratie is het toekennen van s3:GetObject op arn:aws:s3:::my-bucket zonder het /*-achtervoegsel — de API-call richt zich op een object-ARN, geen enkel statement komt overeen, en het verzoek wordt standaard geweigerd.
De volgende policy weigert alle niet-TLS-toegang en verleent leestoegang voor een specifieke rol, waarbij beide ARN-vormen correct worden gebruikt.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyInsecureTransport",
"Effect": "Deny",
"Principal": "*",
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::reports",
"arn:aws:s3:::reports/*"
],
"Condition": { "Bool": { "aws:SecureTransport": "false" } }
},
{
"Sid": "AllowAnalyticsRead",
"Effect": "Allow",
"Principal": { "AWS": "arn:aws:iam::111122223333:role/Analytics" },
"Action": ["s3:GetObject"],
"Resource": "arn:aws:s3:::reports/*"
}
]
}
Een veelvoorkomende valkuil is proberen een uitzondering te maken door een Allow toe te voegen na een brede Deny. Policy-statements zijn niet volgordegevoelig, en de IAM-evaluatielogica retourneert Deny zodra er een overeenkomstige deny wordt gevonden. De juiste oplossing is om de Deny te verfijnen — bijvoorbeeld via een NotPrincipal of een Condition — in plaats van er een permissief statement onder toe te voegen.
Lifecycle Rules, Object Expiry en Vault Lock
S3 Lifecycle rules automatiseren transities tussen storage-classes en de vervaldatum van objecten. Om te voldoen aan retentievereisten — zoals het verwijderen van PII 30 dagen na opname — voeg je een regel toe die de huidige objectversies na 30 dagen laat verlopen en niet-huidige versies kort daarna permanent verwijdert. Voor gerelateerde metadata die naar DynamoDB wordt geschreven, activeer je het DynamoDB TTL-attribuut zodat items zichzelf volgens hetzelfde schema verwijderen; het combineren van deze twee mechanismen is operationeel efficiënt omdat er geen Lambda, scheduler of op maat gemaakte opschooncode nodig is.
LifecycleConfiguration:
Rules:
- Id: ExpirePIIAfter30Days
Status: Enabled
Filter: { Prefix: "ingest/" }
Expiration: { Days: 30 }
NoncurrentVersionExpiration: { NoncurrentDays: 1 }
Voor gearchiveerde data met wettelijke retentievereisten biedt S3 Glacier Vault Lock een afzonderlijke WORM-controle op vault-niveau. Zodra de Vault Lock-policy is vastgelegd (een proces van twee stappen: initiëren/voltooien binnen 24 uur), kan deze niet meer worden gewijzigd, zelfs niet door de account-root. Dit staat los van Object Lock, dat op het niveau van S3-objecten werkt.
Block Public Access en CloudFront OAC
S3 Block Public Access (BPA) is een set van vier schakelaars op account- en bucket-niveau die elke ACL of policy die anders openbare toegang zou verlenen, overschrijven. Activeer alle vier op accountniveau en dwing dit af met een SCP, bijvoorbeeld door s3:PutBucketPublicAccessBlock te weigeren wanneer dit de instellingen zou versoepelen. Deze ‘defense-in-depth’-aanpak voorkomt dat een engineer per ongeluk een bucket opnieuw openbaar maakt via een permissieve ACL.
Voor publiek toegankelijke content die via CloudFront wordt geserveerd, is het juiste patroon Origin Access Control (OAC). OAC ondertekent verzoeken van CloudFront naar S3 met SigV4; de bucket policy staat vervolgens alleen de service principal van de CloudFront-distributie toe. Alleen vertrouwen op CloudFront zonder OAC (of de verouderde OAI) laat de S3-URL direct toegankelijk, wat de toegangscontroles en WAF van de CDN tenietdoet. De bucket moet privé blijven, BPA moet ingeschakeld zijn en de policy moet gespecificeerd zijn voor de ARN van de distributie:
{
"Effect": "Allow",
"Principal": { "Service": "cloudfront.amazonaws.com" },
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::site-assets/*",
"Condition": {
"StringEquals": {
"AWS:SourceArn": "arn:aws:cloudfront::111122223333:distribution/E1ABCXYZ"
}
}
}
S3 Object Lock en Cross-Region Replication
Object Lock dwingt WORM-semantiek af op individuele objecten en vereist dat versioning is ingeschakeld en Object Lock is aangezet bij het aanmaken van de bucket (het kan niet later worden toegevoegd aan een bestaande bucket zonder contact op te nemen met AWS). Er bestaan twee retentiemodi:
Governance mode: gemachtigde principals met
s3:BypassGovernanceRetentionkunnen de retentie inkorten of verwijderen.Compliance mode: geen enkele gebruiker — inclusief de AWS account-root — kan het object verwijderen, overschrijven of de retentieperiode verkorten totdat deze is verlopen. Een ’legal hold’ kan bovendien onafhankelijk worden toegepast en verwijderd door gebruikers met
s3:PutObjectLegalHold.
Compliance mode is de juiste keuze wanneer de vereiste absolute onveranderlijkheid tegenover alle identiteiten is. Om die garantie uit te breiden over meerdere Regions, koppel je Object Lock aan S3 Replication. Gerepliceerde objecten behouden hun lock-configuratie in de doel-bucket (waar Object Lock ook ingeschakeld moet zijn), zodat een gebeurtenis die een hele Regio treft of een kwaadwillige verwijderpoging de bewaarde kopie niet kan compromitteren.
Macie en Athena voor Detectie en Onderzoek
Amazon Macie gebruikt beheerde en aangepaste data-identifiers om S3-objecten te scannen op PII, PHI, credentials en andere gevoelige patronen. Het rapporteert bevindingen aan Security Hub en EventBridge, wat geautomatiseerde herstelacties mogelijk maakt, zoals het in quarantaine plaatsen van objecten met een restrictieve, op tags gebaseerde bucket policy. Activeer Macie in elke Regio waar klantgegevens worden opgeslagen, en delegeer het beheer via AWS Organizations voor gecentraliseerde bevindingen.
Amazon Athena biedt serverless SQL voor data in S3 en is de standaardtool voor het bevragen van CloudTrail data-events op objectniveau. Om te onderzoeken wie een specifiek S3-object heeft benaderd, schakel je CloudTrail data-events in voor de bucket, lever je de logs af in een centrale S3-bucket en voer je een query uit met Athena:
SELECT eventTime, userIdentity.arn, sourceIPAddress, requestParameters
FROM cloudtrail_logs
WHERE eventName IN ('GetObject','DeleteObject')
AND requestParameters LIKE '%reports/q3-financials.pdf%'
AND eventTime > '2024-01-01T00:00:00Z';
Veelvoorkomende Valkuilen en Hun Oorzaken
/*ontbreekt op object-ARN’s: API-calls op objectniveau worden geëvalueerd op basis vanbucket/key, niet de bucket-ARN. Zonder/*matcht geen enkele statement en retourneert IAM een impliciete ‘deny’ — wat zich manifesteert als onverwachte 403-fouten bijGetObject, zelfs wanneer de “bucket” toegestaan lijkt.Een ‘Allow’ toevoegen na een expliciete ‘Deny’: De evaluatie van IAM is niet afhankelijk van de volgorde; elke matchende
Denyleidt direct tot een weigering. De oplossing is om de scope van de ‘deny’ te verkleinen (viaCondition,NotPrincipalofNotResource), niet om permissieve statements toe te voegen.CloudFront zonder OAC of een restrictief bucket-beleid: De S3 origin-URL blijft rechtstreeks bereikbaar, waardoor signed URL’s, WAF-regels en geo-restricties worden omzeild. Schakel altijd BPA in op de origin-bucket en beperk
s3:GetObjecttot de CloudFront service principal viaAWS:SourceArn.Ervan uitgaan dat Object Lock kan worden ingeschakeld op een bestaande bucket: Object Lock moet worden geconfigureerd bij het aanmaken van de bucket. Achteraf aanpassen vereist het aanmaken van een nieuwe bucket waarop Object Lock is ingeschakeld en het migreren van de data.
Governance- en compliance-modus door elkaar halen: Governance-modus weerhoudt een gebruiker met hoge rechten er niet van om de retentie te verwijderen; alleen de compliance-modus blokkeert zelfs het root-account.
Praktijkprobleem: Gebruiksscenario
Scenario: Meridian Financial slaat klantafschriften, transactielogboeken en lange-termijn compliance-archieven op in meerdere S3-buckets verspreid over twee AWS-regio’s. Hun omgeving gebruikt CloudFront voor klantenportalen, cross-account logging en geautomatiseerde lifecycle-transities naar archiveringsopslagklassen voor wettelijke retentie.
Uitdaging: Een recente interne audit bracht aan het licht dat verschillende buckets inconsistente policies hadden die PII blootstelden, er geen onveranderlijke retentie was voor gearchiveerde gegevens, en er geen gecentraliseerde manier was om te ontdekken waar gevoelige objecten zich bevinden over accounts en regio’s heen.
Aanbevolen Aanpak:
- Schakel S3 Block Public Access in op account- en bucketniveau en implementeer CloudFront Origin Access Control (OAC); scherp het bucket-beleid aan om GetObject alleen toe te staan vanaf de CloudFront OAC principal met behulp van precieze resource-ARN’s en voeg expliciete ‘denies’ toe voor elk verzoek dat niet via de OAC komt.
- Dwing server-side encryptie met AWS KMS af door
kms:Encrypt/kms:GenerateDataKeyte vereisen in een bucket-beleid en voeg expliciete ‘denies’ toe voor PutObject-verzoeken die nietx-amz-server-side-encryptionen de vereistekms:contextbevatten om niet-versleutelde uploads te voorkomen. - Configureer S3 Object Lock in compliance-modus voor buckets die onveranderlijk moeten zijn en schakel Cross-Region Replication (CRR) in met replicatieregels die de metadata van object lock behouden, zodat gerepliceerde objecten onveranderlijk blijven in de DR-regio.
- Maak S3 Lifecycle Rules aan om verouderde objecten over te zetten naar S3 Glacier-opslagklassen en stel objectverloop in voor toegestane retentieperiodes; voor archieven die juridisch onveranderlijk moeten zijn, plaats ze in Amazon S3 Glacier-vaults en pas Glacier Vault Lock-beleidsregels toe om write-once retentie af te dwingen.
- Rol Amazon Macie uit over accounts heen om PII te ontdekken en te classificeren, schakel S3 Inventory in en bevraag de bevindingen met Amazon Athena voor onderzoeksvragen, en trigger geautomatiseerde herstelacties (Lambda/Step Functions) om gevoelige objecten te taggen, in quarantaine te plaatsen of te verplaatsen naar vergrendelde, versleutelde buckets.
Rationale: Deze gelaagde aanpak dwingt ’least privilege’ en encryptie af, biedt onveranderlijke retentie en cross-region duurzaamheid voor compliance, en gebruikt Macie/Athena voor gecentraliseerde detectie en geautomatiseerd herstel — in lijn met de best practices van AWS voor databescherming en lifecycle management.
Amazon Macie: Geautomatiseerde Detectie, Classificatie-taken en Toestemmingslijsten
Amazon Macie is een beheerde databeveiligingsdienst die machine learning en patroonherkenning gebruikt om gevoelige data te ontdekken — persoonlijk identificeerbare informatie (PII), betaalkaartnummers (PAN’s), credentials en aangepaste, met regex gedefinieerde datatypen — die is opgeslagen in Amazon S3. Macie werkt in twee complementaire modi die vaak door elkaar worden gehaald.
Geautomatiseerde detectie van gevoelige data is een goedkoop, continu lopend proces dat steekproeven neemt van objecten in elke bucket binnen het account (of binnen een organisatie wanneer Macie is gedelegeerd aan een Security-account). Het bouwt een gevoeligheidsscore en inventaris per bucket op. Dit is het juiste startpunt wanneer u duizenden buckets heeft en nog niet weet waar gevoelige data zich bevindt, omdat het de kosten en administratieve overhead minimaliseert door steekproeven te nemen in plaats van elk object te scannen.
Classificatie-taken (sensitive data discovery jobs) zijn eenmalige of geplande diepe scans gericht op specifieke buckets. Zodra geautomatiseerde detectie een bucket markeert als houder van gevoelige data, maakt u een classificatie-taak aan die gericht is op die bucket voor een uitputtende analyse. Het canonieke patroon is dus: schakel geautomatiseerde detectie in voor de hele organisatie en voer vervolgens alleen classificatie-taken uit op de gemarkeerde buckets.
Toestemmingslijsten zijn het mechanisme om bekende, goedaardige matches te onderdrukken. Als een data lake synthetische test-PAN’s bevat (bijvoorbeeld de bekende 4111 1111 1111 1111 testkaartreeks), zal Macie elke keer dat dit voorkomt een markering plaatsen. De data herschrijven of verplaatsen is duur en verstorend; de juiste aanpak is om een Macie-toestemmingslijst te definiëren — ofwel een platte-tekstlijst met exacte waarden of een regex — en deze te koppelen aan uw classificatie-taken en de configuratie voor geautomatiseerde detectie. Matches met de toestemmingslijst worden uitgesloten van de bevindingen, terwijl echte PAN’s alerts blijven triggeren.
Praktijkprobleem: Gebruiksscenario
Scenario: Meridian Financial beheert een AWS-omgeving met meerdere accounts en honderden S3-buckets waarin transactielogs, klantendocumenten en langetermijnarchieven die naar S3 Glacier zijn verplaatst, worden opgeslagen. Hun beveiligingsteam heeft basisversleuteling en logging geïmplementeerd, maar er is geen gecentraliseerde detectie van gevoelige gegevens of consistente retentiecontroles over de verschillende accounts.
Uitdaging: Een recent ontdekte publiek toegankelijke bucket bevatte gearchiveerde klantgegevens met PII na een foutieve bucket policy en een lifecycle-transitie naar S3 Glacier. Meridian moet nu alle gevoelige gegevens opsporen, de blootstellingen herstellen en in de toekomst een compliant retentiebeleid voor archivering afdwingen.
Aanbevolen Aanpak:
- Activeer Amazon Macie voor de gehele AWS Organization en schakel geautomatiseerde S3-detectie in, zodat Macie continu buckets en objecten evalueert op gevoelige gegevens en risicovolle configuraties.
- Maak Macie-classificatietaken aan die gericht zijn op alle S3-buckets; configureer aangepaste identifiers voor gevoelige gegevens zoals BSN’s en rekeningnummers, en stel ‘allow lists’ (toestemmingslijsten) in om bekende testdata, bestanden van leveranciers en service-accounts uit te sluiten.
- Gebruik S3 Inventory om objecten in S3 Glacier te inventariseren en voer vervolgens S3 Batch Operations uit om tijdelijk alleen de objecten te herstellen die door de inventarisatie zijn gemarkeerd voor Macie-scanning, zodat classificatietaken de inhoud die in Glacier is gearchiveerd kunnen inspecteren.
- Automatiseer het herstel door Macie-bevindingen naar Amazon EventBridge en Security Hub te sturen; trigger Lambda-functies om veilige S3-bucket policies toe te passen, S3 Block Public Access in te schakelen, publieke ACL’s te verwijderen en buckets te taggen voor beoordeling.
- Implementeer duurzame retentie en preventie: schakel S3 Versioning en S3 Object Lock (governance/compliance modes) in op kritieke buckets, dwing SSE-KMS met CMK’s af via bucket policies, en implementeer AWS Organizations SCP’s om publieke ACL’s te blokkeren en versleuteling en Object Lock waar nodig te vereisen.
- Activeer CloudTrail data events voor S3 en stuur de bevindingen naar een SIEM voor alarmering en het periodiek inplannen van Macie-classificatietaken om continue dekking te garanderen.
Rationale: Deze aanpak gebruikt Macie voor geautomatiseerde detectie en gerichte classificatie (met ‘allow lists’), herstelt Glacier-objecten alleen wanneer nodig voor inspectie, automatiseert herstel via EventBridge/Lambda en dwingt onveranderlijke retentie en versleuteling af met Object Lock en KMS. Dit is in lijn met de best practices van AWS voor detectie, herstel en preventieve controles.
# Example allow list (regex form) matching common test PANs
Type: Regex
Regex: '^4111[- ]?1111[- ]?1111[- ]?1111$|^5555[- ]?5555[- ]?5555[- ]?4444$'
Name: synthetic-test-pans
Het behandelen van onbewerkte Macie-bevindingen als de absolute waarheid zonder ‘allow lists’ of onderdrukkingslijsten te configureren, leidt tot ‘alert fatigue’ (waarschuwingsmoeheid) en kan echte incidenten verbergen in de ruis van synthetische data. Daarom is simpelweg ‘de bevindingen vertrouwen’ de verkeerde aanpak in omgevingen met veel false positives.
Integratie van Macie-bevindingen met EventBridge
Macie publiceert elke bevinding naar Amazon EventBridge op de aws.macie source. Hierdoor kunt u bevindingen doorsturen zonder de Macie API te hoeven pollen. Een typische regel stuurt Policy-bevindingen door naar SNS voor on-call paging en stuurt SensitiveData-bevindingen naar AWS Security Hub voor aggregatie.
{
"source": ["aws.macie"],
"detail-type": ["Macie Finding"],
"detail": { "severity": { "description": ["High"] } }
}
De ’targets’ van de regel zijn SNS-topics, Security Hub of een Lambda-functie voor aangepast herstel (bijvoorbeeld het automatisch toepassen van een restrictieve bucket policy op de betreffende bucket).
Bucket Policy Conditions voor Organisatiegrenzen
S3 Block Public Access (BPA) blokkeert alleen toegang die afkomstig is van het openbare internet of anonieme principals. Het voorkomt niet dat een geauthenticeerde principal in een ander AWS-account of een andere AWS Organization toegang krijgt tot de bucket als een bucket policy of ACL dergelijke toegang verleent. Alleen vertrouwen op BPA is daarom onjuist wanneer de eis is om toegang van buiten de organisatie te voorkomen. U moet bucket policies combineren met Service Control Policies (SCPs) op het niveau van Organizations.
Twee IAM condition keys maken de handhaving van organisatiegrenzen nauwkeurig:
aws:ResourceOrgID: de Organization ID die eigenaar is van de resource waartoe toegang wordt gevraagd. Wordt gebruikt in identity policies/SCPs om te voorkomen dat principals resources buiten uw Org aanraken.aws:PrincipalOrgID: de Org ID van de aanroepende principal. Wordt gebruikt in bucket policies om toegang van principals buiten uw Org te weigeren.aws:SourceOrgPaths: het OU-pad van de bron-principal, waardoor scoping naar een specifieke OU mogelijk is (bijvoorbeeld, alleen de “Production” OU mag naar een compliance-bucket schrijven).
{
"Version": "2012-10-17",
"Statement": [{
"Sid": "DenyOutsideOrg",
"Effect": "Deny",
"Principal": "*",
"Action": ["s3:GetObject", "s3:DeleteObject"],
"Resource": "arn:aws:s3:::acme-compliance/*",
"Condition": {
"StringNotEqualsIfExists": {
"aws:PrincipalOrgID": "o-abcd1234",
"aws:SourceOrgPaths": "o-abcd1234/r-root/ou-prod-xyz/"
}
}
}]
}
Combineer dit met een SCP die s3:DeleteObject* weigert op resources waar aws:ResourceOrgID niet overeenkomt met uw Org, en exfiltratie of verwijdering van data over de Org-grens heen wordt onmogelijk, zelfs als een bucket policy per ongeluk wordt versoepeld.
S3 Object Lock: Compliance Mode en Versioning
Object Lock dwingt write-once-read-many (WORM) semantiek af op individuele objectversies. Het vereist dat S3 Versioning is ingeschakeld op de bucket (Object Lock zonder versioning is niet mogelijk — de lock beschermt een specifieke versie-ID, niet de key).
Governance mode: gebruikers met de
s3:BypassGovernanceRetention-permissie kunnen de retentieperiode verkorten of verwijderen. Geschikt voor de handhaving van intern beleid.Compliance mode: geen enkele principal, inclusief de root van het AWS-account, kan de objectversie verkorten, verwijderen of de lock opheffen totdat de retentieperiode is verstreken. Dit is de juiste keuze voor wettelijke onveranderlijkheidsvereisten (SEC 17a-4, FINRA, HIPAA-archivering).
Retentie kan per object worden ingesteld (Retain-Until-datum) of via een standaard retentieconfiguratie op bucketniveau. Legal Holds zijn afzonderlijke, onbeperkte locks die blijven bestaan totdat ze expliciet worden verwijderd door een principal met de s3:PutObjectLegalHold-permissie.
aws s3api put-object-retention \
--bucket acme-audit-logs \
--key 2024/transactions.parquet \
--retention '{"Mode":"COMPLIANCE","RetainUntilDate":"2031-01-01T00:00:00Z"}'
S3 Glacier Vault Lock: Fouten in het beleid corrigeren voordat de vergrendeling is voltooid
Vault Lock op S3 Glacier dwingt onveranderlijk kluistoegangsbeleid af. Het proces bestaat uit twee aanroepen: initiate-vault-lock plaatst het beleid in een in-progress-status met een venster van 24 uur, en complete-vault-lock maakt het permanent. Als er binnen het venster van 24 uur een typefout wordt ontdekt — bijvoorbeeld een te permissieve Principal — is de juiste en goedkoopste oplossing:
aws glacier abort-vault-lock --account-id - --vault-name compliance-archive
aws glacier initiate-vault-lock --account-id - --vault-name compliance-archive \
--policy file://corrected-policy.json
abort-vault-lock annuleert de in-progress-vergrendeling zonder kosten, zodat u opnieuw kunt initiëren met het gecorrigeerde beleid. Alternatieve “oplossingen” — zoals het verwijderen en opnieuw aanmaken van de kluis (wat vereist dat alle 10 TB aan archieven worden verwijderd en opnieuw geüpload, met ophaal- en overdrachtskosten tot gevolg), of wachten tot de vergrendeling is voltooid en er vervolgens omheen werken — zijn verspillend of onmogelijk. Zodra complete-vault-lock is uitgevoerd, is het beleid voor altijd onveranderlijk; afbreken is alleen geldig tijdens het in-progress-venster.
Gerelateerde valkuil: DNSSEC-vertrouwensketen
Een veelvoorkomende domeinoverstijgende valkuil betreft Route 53 DNSSEC. Het inschakelen van DNSSEC-ondertekening op een hosted zone voor een subdomein genereert een Key Signing Key (KSK) en een bijbehorend DS-record. Dat DS-record moet worden gepubliceerd in de parent-zone; zonder dit kunnen resolvers de vertrouwensketen niet valideren en zullen ze ofwel de antwoorden als ongeldig (bogus) behandelen, ofwel terugvallen op onbeveiligde resolutie, waardoor DNS voor validerende clients niet meer werkt. Het inschakelen van ondertekening zonder het DS-record te exporteren en in te voegen bij de registrar of de parent-zone is een onvolledige configuratiestatus, geen werkende DNSSEC-implementatie.
← Encryptie · Alle domeinen · Netwerken en VPC-beveiliging →
Oefen deze vragen → · Getimede oefening op ExamRoll.io →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
Slaag voor je examen →