Amazon SCS-C02: Logging, Audit en Forensics — 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.

Amazon GuardDuty-bevindingen en herstel

GuardDuty is een beheerde service voor dreigingsdetectie die achter de schermen continu drie telemetriestromen verwerkt: CloudTrail management-events (en optioneel S3 data-events), VPC Flow Logs en Route 53 DNS-querylogs. U hoeft die logbronnen niet afzonderlijk in te schakelen, aan te leveren of ervoor te betalen zodat GuardDuty ze kan gebruiken — de service leest rechtstreeks een gedupliceerde stream. Daarom kan GuardDuty met een enkele API-call worden aangezet en binnen enkele minuten bevindingen genereren, zonder enige engineering van log-pipelines.

Bevindingen hebben een ernstgraad tussen 0.1 en 8.9, die wordt gemapt naar Low (0.1–3.9), Medium (4.0–6.9) en High (7.0–8.9). Typische bevindingen die actie vereisen, zijn bijvoorbeeld UnauthorizedAccess:EC2/SSHBruteForce, Backdoor:EC2/C&CActivity.B!DNS, CryptoCurrency:EC2/BitcoinTool.B en Recon:IAMUser/MaliciousIPCaller. Herstelpatronen verschillen per bevinding: een compromittering op EC2-niveau rechtvaardigt over het algemeen het isoleren van de instance met een ‘quarantine security group’, het maken van snapshots van volumes voor forensisch onderzoek, en het beëindigen van de instance; een IAM-gebaseerde bevinding vereist het rouleren van access keys en het controleren van de recente CloudTrail-activiteit van de principal.

Voor omgevingen met meerdere accounts, schakel GuardDuty in via AWS Organizations en wijs een delegated administrator-account aan (meestal het Security Tooling-account). De delegated admin kan GuardDuty automatisch inschakelen in elk bestaand en nieuw member-account, in elke regio waar de service is aangezet. Zonder de delegated admin-configuratie blijven de GuardDuty-bevindingen per account geïsoleerd in elke member — het individueel inschakelen van detectors aggregeert ze niet centraal.

AWS Security Hub en cross-account aggregatie

Security Hub is de normalisatie- en aggregatielaag. Het verwerkt bevindingen van GuardDuty, Inspector, Macie, IAM Access Analyzer, Firewall Manager, Config en tientallen partnerproducten, en converteert ze naar het AWS Security Finding Format (ASFF). Het voert ook zijn eigen controles uit ten opzichte van standaarden zoals CIS AWS Foundations, AWS Foundational Security Best Practices, PCI DSS en NIST 800-53.

Cross-account, cross-region aggregatie werkt op dezelfde manier als bij GuardDuty: registreer Security Hub bij de Organizations delegated administrator en wijs vervolgens een aggregation Region aan, zodat bevindingen uit andere regio’s naar dat ene centrale overzicht worden gerepliceerd. Een veelgemaakte fout is om Security Hub in elk account in te schakelen en een geconsolideerd overzicht te verwachten — zonder de delegated admin plus de aggregation Region ziet elk account nog steeds alleen zijn eigen bevindingen.

Security Hub verstuurt zelf geen e-mails. Notificaties en automatiseringen worden gebouwd door Security Hub-bevindingsevents op de standaard EventBridge-bus te matchen en door te sturen naar SNS, Lambda, Step Functions of Systems Manager Automation-documenten.

CloudTrail: Management Events vs. Data Events

CloudTrail legt twee categorieën van activiteit vast, en het door elkaar halen hiervan is de meest voorkomende leemte in de dekkingsgraad van detectie.

• Management events: control-plane-operaties — RunInstances, CreateBucket, AttachRolePolicy, PutBucketAcl. Standaard ingeschakeld op elke nieuwe trail.

• Data events: operaties op resourceniveau met een hoog volume — S3-object-level calls (GetObject, PutObject, DeleteObject, PutObjectAcl), Lambda Invoke, DynamoDB API-calls op itemniveau. Standaard uitgeschakeld en afzonderlijk gefactureerd.

Als een beveiligingseis is ‘detecteer wanneer iemand een S3-object openbaar maakt via PutObjectAcl,’ dan zal een standaard trail met alleen management events dit niet vastleggen, omdat ACL-wijzigingen op individuele objecten data events zijn. Op dezelfde manier is GetObject-egress uit een gevoelige bucket onzichtbaar zonder data events. PutBucketAcl (op bucketniveau) is een management event en zou wel gelogd worden; PutObjectAcl (op objectniveau) niet.

Gebruik een organization trail die is aangemaakt in het management- of delegated admin-account, zodat de events van elk member-account worden vastgelegd in één enkele S3-bucket en niet kunnen worden uitgeschakeld door principals in de member-accounts. Beveilig de trail met:

• SSE-KMS-encryptie op de doelbucket, met een KMS key policy die ongeautoriseerde decryptie weigert.

• Een bucket policy die s3:PutObject weigert zonder de CloudTrail service principal en die verwijdering weigert.

• Validatie van logbestandsintegriteit ingeschakeld, wat elk uur digest-bestanden produceert die zijn ondertekend met SHA-256, zodat manipulatie kan worden bewezen.

Voorbeeld van aanmaken:

aws cloudtrail create-trail \
  --name org-trail \
  --s3-bucket-name central-ct-logs \
  --is-organization-trail \
  --is-multi-region-trail \
  --enable-log-file-validation \
  --kms-key-id arn:aws:kms:us-east-1:111122223333:key/abcd-...

aws cloudtrail put-event-selectors \
  --trail-name org-trail \
  --event-selectors '[{"ReadWriteType":"All","IncludeManagementEvents":true,
                       "DataResources":[{"Type":"AWS::S3::Object",
                                         "Values":["arn:aws:s3:::sensitive-bucket/"]}]}]'

EventBridge en SNS-alarmering

EventBridge is de ‘routing fabric’ die bevindingen verbindt met menselijke en geautomatiseerde responders. Elke GuardDuty-bevinding, elke update van een Security Hub-bevinding en elk van CloudTrail afgeleid event komt terecht op de standaard event bus. Rules gebruiken JSON event patterns om te filteren en sturen de events vervolgens door naar een of meer targets (SNS, Lambda, SQS, Kinesis Data Firehose, Step Functions, Systems Manager).

Een canoniek patroon voor GuardDuty-bevindingen met een hoge ernstgraad, doorgestuurd naar zowel een SNS-topic voor e-mail als een Firehose delivery stream die OpenSearch voedt voor analyses:

{
  "source": ["aws.guardduty"],
  "detail-type": ["GuardDuty Finding"],
  "detail": { "severity": [ { "numeric": [ ">=", 7 ] } ] }
}

Voor Security Hub CRITICAL-bevindingen die naar e-mail worden gerouteerd:

{
  "source": ["aws.securityhub"],
  "detail-type": ["Security Hub Findings - Imported"],
  "detail": {
    "findings": {
      "Severity": { "Label": ["CRITICAL"] },
      "Workflow": { "Status": ["NEW"] }
    }
  }
}

Het e-mail-endpoint is een eenvoudige SNS-subscription; de abonnee moet de aanmelding bevestigen via de link in de e-mail voordat de bezorging start. Een enkele rule kan tot vijf targets bevatten, dus voor alarmering en downstream-analyses zijn geen dubbele rules nodig.

Onthoud bij het schrijven van patterns dat CloudTrail management events binnenkomen met "detail-type": "AWS API Call via CloudTrail", terwijl data events niet op de standaard bus verschijnen, tenzij u een trail configureert die naar CloudWatch Logs publiceert en een metric filter gebruikt of zich abonneert via de CloudTrail data-event-integratie van EventBridge. Het schrijven van een EventBridge-rule die matcht op "eventName": "PutObjectAcl" op de standaard bus zonder data events in te schakelen, levert nul matches op.

CloudWatch Logs, Insights, Metric Filters en Alarms

Het versturen van CloudTrail (en VPC Flow Logs, en applicatielogs) naar CloudWatch Logs maakt bijna-realtime detectie mogelijk. Metric filters scannen elke binnenkomende loggebeurtenis op basis van een patroon en verhogen een custom CloudWatch-metric; een CloudWatch-alarm op die metric activeert SNS.

Voorbeeld: alarm bij herhaalde mislukte aanmeldingen bij de console.

aws logs put-metric-filter \
  --log-group-name /aws/cloudtrail/org \
  --filter-name ConsoleSignInFailures \
  --filter-pattern '{ ($.eventName = "ConsoleLogin") && ($.errorMessage = "Failed authentication") }' \
  --metric-transformations metricName=ConsoleLoginFailures,metricNamespace=Security,metricValue=1

CloudWatch Logs Insights biedt de mogelijkheid voor ad-hocquery’s met behulp van een speciaal daarvoor ontwikkelde querytaal, nuttig voor incidentrespons nadat een alarm is afgegaan:

fields @timestamp, userIdentity.arn, sourceIPAddress, eventName

Veelvoorkomende Valkuilen

• Ontbrekende S3-activiteit op objectniveau: PutObjectAcl, GetObject en DeleteObject zijn data events. Een standaard trail legt alleen management events vast; u moet data-event selectors toevoegen, anders zal de finding, het alarm of de EventBridge-regel die op die API-namen gericht is, stilzwijgend nooit worden geactiveerd.

• Centraal overzicht zonder delegated admin: het inschakelen van GuardDuty of Security Hub in elk account aggregeert de resultaten niet. Findings worden alleen centraal verzameld na het registreren van een delegated administrator in AWS Organizations en, voor Security Hub, het kiezen van een aggregation Region. Uitnodigingen voor meerdere accounts werken voor kleine omgevingen, maar schalen niet en vereisen acceptatie per account.

• Verwarring tussen management en data in filters: PutBucketAcl (bucket) is een management event en werkt in elke standaard EventBridge- of metric filter; PutObjectAcl (object) niet, ongeacht hoe goed het patroon is opgesteld, tenzij data events zijn ingeschakeld en aan dezelfde pipeline worden geleverd.

Praktijkprobleem: Gebruikersscenario

Scenario: Meridian Financial beheert een multi-account AWS Organization met een speciaal security-account en een gecentraliseerd logging-account. Hun omgeving bevat PII van klanten in S3, transactionele API’s op EC2/Lambda, en CloudTrail schrijft al management events naar een centrale S3-bucket; teams willen snellere detectie en een gecoördineerde respons over de verschillende accounts.

Uitdaging: Security engineers hebben een plotselinge piek in S3 GETs gedetecteerd en gerelateerde GuardDuty-findings die wijzen op mogelijke data-exfiltratie, maar de meldingen zijn ’noisy’ en missen gecorreleerde CloudTrail-context en geautomatiseerde indamming (containment) over de accounts heen.

Aanbevolen Aanpak:

1. Schakel Amazon GuardDuty in voor elk member-account en wijs het security-account aan als de GuardDuty delegated administrator; schakel S3 data-event protection in zodat findings afwijkingen in toegang op objectniveau bevatten.
2. Configureer CloudTrail per account om management events te leveren aan de centrale S3-bucket voor retentie en om geselecteerde waardevolle data events (S3 GetObject/PutObject/DeleteObject en Lambda Invoke) door te sturen naar CloudWatch Logs in het security-account voor inspectie met lage latentie.
3. Activeer AWS Security Hub in het security-account en schakel cross-account aggregatie met member-accounts in, zodat GuardDuty-findings, van CloudTrail afgeleide bevindingen en Config/Inspector-resultaten worden gecentraliseerd en genormaliseerd.
4. Maak EventBridge-regels die overeenkomen met GuardDuty- en Security Hub-findings met een hoge ernstgraad en routeer ze naar SNS voor pagermeldingen en naar een remediation Lambda die CloudTrail-context gebruikt om indammingsacties te ondernemen (API-sleutels intrekken, IAM-sessie verwijderen, EC2 ENI isoleren).
5. Voeg CloudWatch Logs metric filters toe voor abnormale s3:GetObject-rates, gespecificeerd per IAM-principal, en een alarm dat dezelfde EventBridge/SNS/Lambda-pipeline activeert; gebruik CloudWatch Logs Insights-query’s in het security-account om meldingen te verrijken met gecorreleerde CloudTrail-events voor incident triage.

Rationale: Het centraliseren van findings (GuardDuty + Security Hub) en het sturen van gerichte CloudTrail data events naar CloudWatch maakt correlatie met lage latentie, alarmering en geautomatiseerde indamming mogelijk via EventBridge/SNS/Lambda—wat in lijn is met de best practices van AWS voor detectie, cross-account aggregatie en geautomatiseerde respons.

Gecentraliseerde CloudTrail en Log-integriteit

CloudTrail is de gezaghebbende registratie van AWS API-activiteit, en de basis van elke auditarchitectuur is één enkele multi-Region trail die levert aan één gecentraliseerde S3-bucket, idealiter in een speciaal log-archive-account binnen AWS Organizations. Een multi-Region trail legt automatisch management events vast in elke huidige regio en in elke regio die AWS later lanceert — een single-Region trail creëert blinde vlekken op het moment dat een workload elders wordt opgestart, wat de klassieke fout is met betrekking tot volledigheid tijdens audits. Wanneer toegepast op organisatieniveau, legt de trail ook de events van elk member-account vast, zodat een nieuw account dat lid wordt van de organisatie gedekt is zonder enige configuratie per account.

Schakel log file validation in op de trail. CloudTrail levert dan elk uur een ondertekend digest-bestand aan dezelfde S3-bucket, dat de SHA-256-hashes van de geleverde logbestanden bevat. Het aws cloudtrail validate-logs-commando doorloopt de digest-keten en detecteert manipulatie, verwijdering of hiaten. Zonder validatie kan een verdediger niet bewijzen dat logs na een incident niet zijn gewijzigd, wat ze ongeldig maakt als forensisch bewijs.

aws cloudtrail create-trail \
  --name org-trail \
  --s3-bucket-name corp-audit-logs \
  --is-multi-region-trail \
  --is-organization-trail \
  --enable-log-file-validation \
  --kms-key-id arn:aws:kms:us-east-1:111122223333:key/abcd-...
aws cloudtrail start-logging --name org-trail

Leveringsfouten zijn bijna altijd problemen met permissies downstream, geen bugs in CloudTrail. De S3-bucket moet bestaan voordat de trail wordt aangemaakt, de bucket policy moet s3:PutObject toekennen aan cloudtrail.amazonaws.com met een aws:SourceArn-conditie die overeenkomt met de trail, en de eigenaar van het object moet de eigenaar van de bucket zijn (bucket-owner-full-control). Als de trail SSE-KMS gebruikt, moet de CMK-policy kms:GenerateDataKey* toestaan voor de CloudTrail service principal, en elke consumer (Athena, security engineers, Lambda-parsers) moet kms:Decrypt hebben op die sleutel. Een veelvoorkomende storing: logs worden correct geleverd, maar Athena-query’s geven “AccessDenied” terug omdat de query-rol geen Decrypt-permissie heeft op de CMK voor log-encryptie. Los dit op in de key policy, niet door encryptie uit te schakelen.

CloudWatch Logs, Metric Filters en Real-Time Alarmering

CloudTrail levert data in batches van 5 tot 15 minuten aan S3 — voldoende voor retrospectieve audits, maar te traag voor real-time detectie. Om te alarmeren op gevoelige gebeurtenissen, stream de trail naar CloudWatch Logs (een optie voor een trail) of routeer specifieke gebeurtenissen via EventBridge. De aanpak met CloudWatch Logs gebruikt metric filters die JSON-gebeurtenissen op basis van patronen matchen en een CloudWatch-metric verhogen, die vervolgens een CloudWatch Alarm en een SNS-notificatie aanstuurt. Het klassieke voorbeeld is een aanmelding op de root-console:

{ $.eventName = "ConsoleLogin" && $.userIdentity.type = "Root" }

EventBridge is vaak beter voor specifieke, bekende gebeurtenissen (het uitschakelen van een KMS-sleutel, wijzigingen in IAM-beleid) omdat regels direct Lambda of Step Functions kunnen triggeren zonder kosten voor Logs. Gebruik metric filters wanneer je geaggregeerde tellingen of dashboarding nodig hebt.

De retentie voor CloudWatch Logs staat standaard op Never Expire (Nooit Verlopen), wat duur is en zelden de juiste instelling. Stel een expliciete retentie in per log group (aws logs put-retention-policy) die in lijn is met het compliance-regime — doorgaans 90 dagen ‘hot’ in CloudWatch met een langetermijnarchief in S3 via een subscription filter of Kinesis Data Firehose.

Voor de hygiëne van gevoelige data, pas CloudWatch Logs data protection policies toe op accountniveau. Deze gebruiken beheerde data-identifiers (creditcardnummers, AWS secret keys, BSN’s) om overeenkomende strings te maskeren bij opname (ingestion). Cruciaal is dat voor het demaskeren logs:Unmask vereist is; ken dit recht alleen toe aan een break-glass role. Gebruikers die de log group kunnen lezen maar Unmask missen, zien alleen sterretjes. Een beleid voor het hele account is van toepassing op alle huidige en toekomstige log groups, wat de juiste controlemaatregel is — beleid per groep kan gaan afwijken naarmate nieuwe services nieuwe groepen aanmaken.

Log Query op Schaal: Insights en Athena

Twee query-engines richten zich op verschillende datalagen.

• CloudWatch Logs Insights doorzoekt data die al in CloudWatch Logs staat met een speciaal daarvoor ontwikkelde querytaal. Ideaal voor recente operationele data (Lambda-logs, VPC Flow Logs in Logs, applicatielogs). Snel, geen schema-setup nodig, maar beperkt door de retentie van CloudWatch en de kosten per gescande GB.

• Amazon Athena voert Presto/Trino SQL uit op data in S3. Ideaal voor grootschalige forensische queries op CloudTrail, ALB access logs, VPC Flow Logs opgeslagen in S3, en CloudFront-logs. Kost $5 per TB die wordt gescand; gebruik partition projection of Glue-partities op datum/regio om de scankosten drastisch te verlagen.

Een typisch forensisch gebruiksscenario: identificeren wie een KMS-sleutel heeft uitgeschakeld. Omdat de JSON van CloudTrail genest is, stelt de door CloudTrail aangemaakte Athena-tabel userIdentity beschikbaar als een struct:

SELECT eventTime,
       userIdentity.arn                                         AS principal,
       userIdentity.sessionContext.sessionIssuer.arn            AS assumed_role,
       userIdentity.sessionContext.attributes.mfaAuthenticated  AS mfa,
       sourceIPAddress,
       requestParameters
FROM   cloudtrail_logs
WHERE  eventName = 'DisableKey'
  AND  eventTime BETWEEN '2024-05-01T03:00:00Z' AND '2024-05-01T03:30:00Z';

Voor de analyse van bots op een ALB, schakel ALB access logs naar S3 in, definieer een Athena-tabel over de log-prefix, voer vervolgens een join uit met een tabel van bekende kwaadaardige IP-adressen en visualiseer de aggregatie in QuickSight. QuickSight leest data uit Athena, dus de pipeline is: ALB → S3 → Athena → QuickSight. Het sturen van ALB-logs naar CloudWatch Logs Insights is geen ondersteund native pad — ALB-logs gaan alleen naar S3.

VPC Flow Logs kunnen naar beide bestemmingen gaan: kies Logs voor tactische onderzoeken van het type filter dstPort=3389 and action="REJECT", en S3 (Parquet, gepartitioneerd) voor trend-queries over meerdere maanden.

Verzamelen van Bewijsmateriaal met Audit Manager

AWS Audit Manager automatiseert het continu verzamelen van bewijsmateriaal (evidence) dat is gekoppeld aan raamwerken zoals PCI DSS, HIPAA, SOC 2 en CIS. Het haalt bewijsmateriaal op uit Config-regels, Security Hub-bevindingen, CloudTrail-gebeurtenissen en de resource-inventaris, en verpakt dit in ‘control assessments’. Wanneer ingeschakeld in het management- of gedelegeerde administrator-account van Organizations, verzamelt het data over alle member-accounts en produceert het een ‘assessment report’ — een gezipte bundel bewijsmateriaal met een manifest — dat auditors accepteren in plaats van handmatige screenshots. Dit is het juiste antwoord wanneer een scenario vraagt om continu, multi-account, op een raamwerk afgestemd bewijsmateriaal: Config alleen geeft je resource-compliance maar geen koppeling met een raamwerk; Security Hub levert bevindingen maar geen verpakking in een assessment; een zelfgemaakt Athena-rapport is niet continu.

Valkuilen Samengevat

• CloudTrail de schuld geven van ontbrekende logs is meestal onjuist: de bucket bestaat mogelijk niet, het bucketbeleid kan de CloudTrail-principal weigeren, of het eigendom van objecten is mogelijk verkeerd geconfigureerd. Controleer eerst S3.

• Een trail voor één regio lijkt goedkoper, maar levert een onvolledige auditgeschiedenis op; multi-Region is het standaard juiste antwoord voor dekking over de hele organisatie.

• Met SSE-KMS versleutelde logs zijn onzichtbaar voor Athena, Lambda-parsers of engineers, tenzij het CMK-beleid kms:Decrypt toekent aan die principals — versleuteling uitschakelen is niet de oplossing; het corrigeren van het sleutelbeleid wel.

Praktijkprobleem: Use-Case Scenario

Scenario: Meridian Financial beheert een AWS Organization met meerdere accounts, waaronder productie, staging en een speciaal logging-account. Hun omgeving host API’s voor klanten, analytics en door IAM beheerde secrets, en ze hebben gecentraliseerde, fraudebestendige logging en snelle onderzoekstools nodig om incidentrespons en compliance-verzoeken te ondersteunen.

Uitdaging: Een recente verdachte reeks console-aanmeldingen en wijzigingen in IAM-beleid bleef urenlang onopgemerkt en er bestaat bezorgdheid dat de integriteit van de logs en tijdige alarmering onvoldoende zijn voor forensische reconstructie en het verzamelen van bewijs voor Audit Manager.

Aanbevolen Aanpak:

1. Activeer een AWS Organizations CloudTrail (organization trail) in alle regio’s, schakel CloudTrail log file integrity validation in, lever logs en digest-bestanden af in een gecentraliseerde S3-bucket die is versleuteld met een KMS CMK waarvan het sleutelbeleid de ontsleuteling beperkt tot een klein beveiligingsteam, en schakel S3 access logging en versioning in.
2. Configureer CloudTrail om management- en geselecteerde data-events te streamen naar CloudWatch Logs, maak vervolgens CloudWatch Logs metric filters voor risicovolle patronen (mislukte console-aanmeldingen vanaf nieuwe IP’s, CreateUser, PutRolePolicy) en koppel CloudWatch Alarms aan SNS-topics voor paging en een geautomatiseerd Lambda-playbook.
3. Implementeer CloudWatch Logs Insights-dashboards voor interactief onderzoek van recente gebeurtenissen en stel bewaar- en lifecycle-regels in het logging-account in om bewijsmateriaal te bewaren volgens het beleid.
4. Catalogueer CloudTrail S3-objecten met AWS Glue en voer Athena-query’s uit (gepartitioneerd op regio/datum/service) voor grootschalige retrospectieve analyse en om CSV-bewijsexports voor onderzoekers te produceren.
5. Maak een AWS Audit Manager-assessment dat automatisch bewijsmateriaal van CloudTrail, AWS Config en IAM verzamelt in een evidence folder en periodieke exports plant voor compliance-reviewers.

Rationale: Het centraliseren en valideren van CloudTrail, het streamen naar CloudWatch voor real-time metric filters en alarmen, en het gebruik van Athena/Logs Insights voor schaalbare query’s volgen de best practices van AWS voor detectie, onveranderlijke logging en forensische paraatheid, terwijl Audit Manager het verzamelen van bewijs voor audits automatiseert.

← Bedreigingsdetectie en Alarmering · Alle domeinen · Encryptie →

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

Blader door Amazon →