Amazon SCS-C02: Protokollierung, Audit und Forensik — Lernleitfaden

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

Teil des AWS Security Specialty SCS-C02 — Lernleitfaden. Üben Sie mit verifizierten Antworten im Amazon-Prüfungscenter, oder absolvieren Sie zeitlich begrenzte Übungstests auf ExamRoll.io.

Amazon GuardDuty-Ergebnisse und Behebung

GuardDuty ist ein verwalteter Dienst zur Bedrohungserkennung, der im Hintergrund kontinuierlich drei Telemetrie-Streams aufnimmt: CloudTrail-Verwaltungsereignisse (und optional S3-Datenereignisse), VPC Flow Logs und Route 53 DNS-Abfrageprotokolle. Sie müssen diese Protokollquellen nicht separat aktivieren, bereitstellen oder bezahlen, damit GuardDuty sie nutzen kann – der Dienst liest einen doppelten Stream direkt. Aus diesem Grund kann GuardDuty mit einem einzigen API-Aufruf eingeschaltet werden und innerhalb von Minuten Ergebnisse (Findings) generieren, ohne dass ein Engineering der Protokoll-Pipeline erforderlich ist.

Ergebnisse haben einen Schweregrad zwischen 0,1 und 8,9, der den Stufen Niedrig (0,1–3,9), Mittel (4,0–6,9) und Hoch (7,0–8,9) zugeordnet ist. Typische handlungsrelevante Ergebnisse sind UnauthorizedAccess:EC2/SSHBruteForce, Backdoor:EC2/C&CActivity.B!DNS, CryptoCurrency:EC2/BitcoinTool.B und Recon:IAMUser/MaliciousIPCaller. Die Muster zur Behebung variieren je nach Ergebnis: Eine Kompromittierung auf EC2-Basis rechtfertigt in der Regel die Isolierung der Instanz mit einer Quarantäne-Sicherheitsgruppe, das Erstellen von Snapshots der Volumes für die Forensik und die anschließende Terminierung; ein IAM-basiertes Ergebnis erfordert die Rotation der Zugriffsschlüssel und die Überprüfung der jüngsten CloudTrail-Aktivitäten des Prinzipals.

Für Umgebungen mit mehreren Konten aktivieren Sie GuardDuty über AWS Organizations und benennen Sie ein delegated administrator-Konto (üblicherweise das Security-Tooling-Konto). Der delegierte Administrator kann GuardDuty automatisch in jedem bestehenden und neuen Mitgliedskonto in jeder Region aktivieren, in der der Dienst eingeschaltet ist. Ohne die Konfiguration des delegierten Administrators bleiben die GuardDuty-Ergebnisse jedes Kontos im jeweiligen Mitgliedskonto isoliert – die individuelle Aktivierung der Detektoren führt nicht zu einer zentralen Aggregation.

AWS Security Hub und kontoübergreifende Aggregation

Security Hub ist die Normalisierungs- und Aggregationsschicht. Er nimmt Ergebnisse von GuardDuty, Inspector, Macie, IAM Access Analyzer, Firewall Manager, Config und Dutzenden von Partnerprodukten auf und konvertiert sie in das AWS Security Finding Format (ASFF). Zudem führt er eigene Kontrollen anhand von Standards wie CIS AWS Foundations, AWS Foundational Security Best Practices, PCI DSS und NIST 800-53 durch.

Die konto- und regionsübergreifende Aggregation funktioniert genauso wie bei GuardDuty: Registrieren Sie Security Hub beim delegierten Administrator von Organizations und legen Sie dann eine aggregation Region fest, sodass Ergebnisse aus anderen Regionen in diese zentrale Ansicht repliziert werden. Ein häufiger Fehler besteht darin, Security Hub in jedem Konto zu aktivieren und eine konsolidierte Ansicht zu erwarten – ohne den delegierten Administrator und die Aggregationsregion sieht jedes Konto weiterhin nur seine eigenen Ergebnisse.

Security Hub selbst versendet keine E-Mails. Benachrichtigungen und Automatisierungen werden erstellt, indem Security-Hub-Ergebnisereignisse auf dem Standard-EventBridge-Bus abgeglichen und an SNS, Lambda, Step Functions oder Systems Manager Automation-Dokumente weitergeleitet werden.

CloudTrail: Verwaltungs- vs. Datenereignisse

CloudTrail zeichnet zwei Kategorien von Aktivitäten auf, und deren Verwechslung ist die häufigste Lücke bei der Abdeckung von Erkennungsmechanismen.

• Verwaltungsereignisse (Management Events): Operationen auf der Steuerungsebene – RunInstances, CreateBucket, AttachRolePolicy, PutBucketAcl. Bei jedem neuen Trail standardmäßig aktiviert.

• Datenereignisse (Data Events): hochvolumige Operationen auf Ressourcenebene – S3-Aufrufe auf Objektebene (GetObject, PutObject, DeleteObject, PutObjectAcl), Lambda Invoke, API-Aufrufe auf Elementebene in DynamoDB. Standardmäßig deaktiviert und separat abgerechnet.

Wenn eine Sicherheitsanforderung lautet, „erkennen, wenn jemand ein S3-Objekt über PutObjectAcl öffentlich macht“, wird ein einfacher Trail für Verwaltungsereignisse dies nicht erfassen, da ACL-Änderungen an einzelnen Objekten Datenereignisse sind. Ebenso ist der Abfluss von Daten durch GetObject aus einem sensiblen Bucket ohne Datenereignisse nicht sichtbar. PutBucketAcl (auf Bucket-Ebene) ist ein Verwaltungsereignis und würde protokolliert; PutObjectAcl (auf Objektebene) ist es nicht.

Verwenden Sie einen organization trail, der im Verwaltungskonto oder im Konto des delegierten Administrators erstellt wird, damit die Ereignisse jedes Mitgliedskontos in einem einzigen S3-Bucket erfasst und nicht von Prinzipalen der Mitgliedskonten deaktiviert werden können. Schützen Sie den Trail mit:

• SSE-KMS-Verschlüsselung für den Ziel-Bucket, mit einer KMS-Schlüsselrichtlinie, die unbefugte Entschlüsselung verweigert.

• Einer Bucket-Richtlinie, die s3:PutObject ohne den CloudTrail-Service-Prinzipal verweigert und das Löschen untersagt.

• Log file integrity validation aktiviert, wodurch stündlich Digest-Dateien erstellt werden, die mit SHA-256 signiert sind, sodass Manipulationen nachgewiesen werden können.

Beispiel für die Erstellung:

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 und SNS-Benachrichtigungen

EventBridge ist die Routing-Struktur, die Ergebnisse mit menschlichen und automatisierten Bearbeitern (Respondern) verbindet. Jedes GuardDuty-Ergebnis, jede Aktualisierung eines Security-Hub-Ergebnisses und jedes von CloudTrail abgeleitete Ereignis landet auf dem Standard-Event-Bus. Regeln verwenden JSON-Ereignismuster zum Filtern und leiten die Ereignisse dann an ein oder mehrere Ziele weiter (Fan-Out) (SNS, Lambda, SQS, Kinesis Data Firehose, Step Functions, Systems Manager).

Ein kanonisches Muster für GuardDuty-Ergebnisse mit hohem Schweregrad, die sowohl an ein SNS-Thema für E-Mails als auch an einen Firehose-Bereitstellungsstream zur Speisung von OpenSearch für Analysen weitergeleitet werden:

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

Für Security-Hub-Ergebnisse mit dem Schweregrad CRITICAL, die per E-Mail weitergeleitet werden:

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

Der E-Mail-Endpunkt ist eine einfache SNS-Subscription; der Abonnent muss die Zustellung über den per E-Mail zugesandten Link bestätigen, bevor sie beginnt. Eine einzelne Regel kann bis zu fünf Ziele haben, sodass für Benachrichtigungen und nachgelagerte Analysen keine doppelten Regeln erforderlich sind.

Denken Sie beim Erstellen von Mustern daran, dass CloudTrail-Verwaltungsereignisse mit "detail-type": "AWS API Call via CloudTrail" ankommen, während Datenereignisse nicht auf dem Standard-Bus erscheinen, es sei denn, Sie konfigurieren einen Trail, der in CloudWatch Logs veröffentlicht, und verwenden einen Metrikfilter oder abonnieren sie über die Integration von CloudTrail-Datenereignissen in EventBridge. Das Schreiben einer EventBridge-Regel, die auf dem Standard-Bus auf "eventName": "PutObjectAcl" prüft, ohne Datenereignisse zu aktivieren, führt zu null Treffern.

CloudWatch Logs, Insights, Metrikfilter und Alarme

Das Senden von CloudTrail (sowie VPC Flow Logs und Anwendungs-Logs) an CloudWatch Logs ermöglicht eine Erkennung nahezu in Echtzeit. Metrikfilter scannen jedes eingehende Log-Ereignis anhand eines Musters und erhöhen eine benutzerdefinierte CloudWatch-Metrik; ein CloudWatch-Alarm für diese Metrik löst SNS aus.

Beispiel: Alarm bei wiederholten fehlgeschlagenen Anmeldungen an der Konsole.

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 bietet Ad-hoc-Abfragen mit einer speziell dafür entwickelten Abfragesprache, was für die Reaktion auf Vorfälle (Incident Response) nach dem Auslösen eines Alarms nützlich ist:

fields @timestamp, userIdentity.arn, sourceIPAddress, eventName

Häufige Fallstricke

• Fehlende S3-Aktivität auf Objektebene: PutObjectAcl, GetObject und DeleteObject sind Datenereignisse. Ein Standard-Trail erfasst nur Verwaltungsereignisse; Sie müssen Selektoren für Datenereignisse hinzufügen, andernfalls wird der Finding, der Alarm oder die EventBridge-Regel, die auf diese API-Namen abzielt, stillschweigend niemals ausgelöst.

• Zentrale Sichtbarkeit ohne delegierten Administrator: Die Aktivierung von GuardDuty oder Security Hub in jedem Konto führt nicht zu einer Aggregation der Ergebnisse. Findings werden nur dann zentral gesammelt, wenn ein delegierter Administrator in AWS Organizations registriert und für Security Hub eine Aggregationsregion ausgewählt wird. Kontoübergreifende Einladungen funktionieren für kleine Umgebungen, sind aber nicht skalierbar und erfordern eine Bestätigung pro Konto.

• Verwechslung von Verwaltungs- und Datenereignissen in Filtern: PutBucketAcl (Bucket) ist ein Verwaltungsereignis und funktioniert in jedem Standard-EventBridge- oder Metrikfilter; PutObjectAcl (Objekt) hingegen nicht, egal wie gut das Muster formuliert ist, es sei denn, Datenereignisse sind aktiviert und werden an dieselbe Pipeline geliefert.

Praktisches Problem: Anwendungsfallszenario

Szenario: Meridian Financial betreibt eine AWS Organization mit mehreren Konten, einem dedizierten Sicherheitskonto und einem zentralen Protokollierungskonto. Ihre Umgebung umfasst personenbezogene Kundendaten (PII) in S3, transaktionale APIs auf EC2/Lambda, und CloudTrail schreibt bereits Verwaltungsereignisse in einen zentralen S3-Bucket. Die Teams wünschen sich eine schnellere Erkennung und eine koordinierte Reaktion über alle Konten hinweg.

Herausforderung: Sicherheitsingenieure stellten einen plötzlichen Anstieg von S3-GET-Anfragen und damit verbundene GuardDuty-Findings fest, die auf eine mögliche Datenexfiltration hindeuten. Die Alarme sind jedoch unübersichtlich (noisy) und es fehlt ihnen an korreliertem CloudTrail-Kontext und automatisierter Eindämmung (Containment) über die Konten hinweg.

Empfohlener Ansatz:

1. Aktivieren Sie Amazon GuardDuty in jedem Mitgliedskonto und benennen Sie das Sicherheitskonto als delegierten Administrator für GuardDuty. Aktivieren Sie den Schutz für S3-Datenereignisse, damit Findings Anomalien beim Zugriff auf Objektebene beinhalten.
2. Konfigurieren Sie CloudTrail pro Konto so, dass Verwaltungsereignisse zur Aufbewahrung an den zentralen S3-Bucket geliefert und ausgewählte, hochwertige Datenereignisse (S3 GetObject/PutObject/DeleteObject und Lambda Invoke) zur Überprüfung mit geringer Latenz an CloudWatch Logs im Sicherheitskonto weitergeleitet werden.
3. Aktivieren Sie AWS Security Hub im Sicherheitskonto und schalten Sie die kontoübergreifende Aggregation mit den Mitgliedskonten ein, damit GuardDuty-Findings, von CloudTrail abgeleitete Findings und Ergebnisse von Config/Inspector zentralisiert und normalisiert werden.
4. Erstellen Sie EventBridge-Regeln, die auf GuardDuty- und Security-Hub-Findings mit hohem Schweregrad passen und diese für Pager-Benachrichtigungen an SNS sowie an eine Lambda-Funktion zur Problembehebung (Remediation) weiterleiten, die den CloudTrail-Kontext nutzt, um Eindämmungsmaßnahmen zu ergreifen (API-Schlüssel widerrufen, IAM-Sitzung entfernen, EC2-ENI isolieren).
5. Fügen Sie CloudWatch-Logs-Metrikfilter für anormale s3:GetObject-Raten hinzu, die nach IAM-Prinzipalen eingegrenzt sind, sowie einen Alarm, der dieselbe EventBridge/SNS/Lambda-Pipeline auslöst. Verwenden Sie CloudWatch-Logs-Insights-Abfragen im Sicherheitskonto, um Alarme für die Triage von Vorfällen mit korrelierten CloudTrail-Ereignissen anzureichern.

Begründung: Die Zentralisierung von Findings (GuardDuty + Security Hub) und das Senden gezielter CloudTrail-Datenereignisse an CloudWatch ermöglichen eine Korrelation mit geringer Latenz, Alarmierung und automatisierte Eindämmung über EventBridge/SNS/Lambda. Dies entspricht den AWS Best Practices für Erkennung, kontoübergreifende Aggregation und automatisierte Reaktion.

Zentralisierter CloudTrail und Log-Integrität

CloudTrail ist die maßgebliche Aufzeichnung der AWS-API-Aktivität. Die Grundlage jeder Audit-Architektur ist ein einziger Multi-Region-Trail, der in einen zentralen S3-Bucket liefert, idealerweise in einem dedizierten Log-Archiv-Konto innerhalb von AWS Organizations. Ein Multi-Region-Trail erfasst automatisch Verwaltungsereignisse in jeder aktuellen Region und in jeder Region, die AWS später einführt. Ein Single-Region-Trail erzeugt blinde Flecken, sobald eine Workload an anderer Stelle gestartet wird, was der klassische Fehler bei der Vollständigkeit während Audits ist. Wenn der Trail auf Organisationsebene angewendet wird, erfasst er auch die Ereignisse jedes Mitgliedskontos, sodass ein neues Konto, das der Organisation beitritt, ohne jegliche Konfiguration pro Konto abgedeckt ist.

Aktivieren Sie die Log-Datei-Validierung für den Trail. CloudTrail liefert dann stündlich eine signierte Digest-Datei in denselben S3-Bucket, die die SHA-256-Hashes der gelieferten Log-Dateien enthält. Der Befehl aws cloudtrail validate-logs durchläuft die Digest-Kette und erkennt Manipulationen, Löschungen oder Lücken. Ohne Validierung kann ein Verteidiger nicht beweisen, dass die Protokolle nach einem Vorfall nicht verändert wurden, was sie als forensische Beweismittel ungültig macht.

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

Zustellungsfehler sind fast immer nachgelagerte Berechtigungsprobleme, keine Fehler in CloudTrail. Der S3-Bucket muss existieren, bevor der Trail erstellt wird. Seine Bucket Policy muss s3:PutObject für cloudtrail.amazonaws.com mit einer aws:SourceArn-Bedingung gewähren, die mit dem Trail übereinstimmt, und der Objekteigentümer muss der Bucket-Eigentümer sein (bucket-owner-full-control). Wenn der Trail SSE-KMS verwendet, muss die CMK-Richtlinie kms:GenerateDataKey* für den CloudTrail-Service-Prinzipal erlauben, und jeder Konsument (Athena, Sicherheitsingenieure, Lambda-Parser) muss kms:Decrypt für diesen Schlüssel haben. Ein häufiger Ausfallmodus: Die Protokolle werden problemlos zugestellt, aber Athena-Abfragen geben „AccessDenied“ zurück, weil der Abfragerolle die Berechtigung Decrypt für den CMK zur Protokollverschlüsselung fehlt. Beheben Sie dies in der Schlüsselrichtlinie, nicht durch Deaktivieren der Verschlüsselung.

CloudWatch Logs, Metrikfilter und Echtzeit-Alarmierung

CloudTrail liefert in 5- bis 15-minütigen Batches an S3 – ausreichend für retrospektive Audits, aber zu langsam für die Echtzeiterkennung. Um bei sensiblen Ereignissen Alarme auszulösen, streamen Sie den Trail zu CloudWatch Logs (eine Trail-Option) oder leiten Sie bestimmte Ereignisse über EventBridge weiter. Der Ansatz mit CloudWatch Logs verwendet Metrikfilter (metric filters), die JSON-Ereignisse per Musterabgleich erkennen und eine CloudWatch-Metrik erhöhen. Diese wiederum steuert einen CloudWatch Alarm und eine SNS-Benachrichtigung. Das Standardbeispiel ist die Anmeldung an der Konsole als Root-Benutzer:

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

EventBridge ist oft besser für eng definierte, bekannte Ereignisse (Deaktivierung von KMS-Schlüsseln, Änderungen an IAM-Richtlinien), da Regeln Lambda oder Step Functions direkt und ohne Logs-Kosten auslösen können. Verwenden Sie Metrikfilter, wenn Sie aggregierte Zählungen oder Dashboarding benötigen.

Die Aufbewahrung (Retention) in CloudWatch Logs ist standardmäßig auf Nie ablaufen (Never Expire) eingestellt, was teuer und selten die richtige Wahl ist. Legen Sie eine explizite Aufbewahrungsfrist pro Log-Gruppe fest (aws logs put-retention-policy), die auf die Compliance-Vorgaben abgestimmt ist – üblicherweise 90 Tage „heiß“ in CloudWatch mit Langzeitarchivierung in S3 über einen Abonnementfilter oder Kinesis Data Firehose.

Für die Hygiene sensibler Daten wenden Sie CloudWatch Logs-Datenschutzrichtlinien (data protection policies) auf Kontoebene an. Diese verwenden verwaltete Datenkennungen (Kreditkartennummern, AWS Secret Keys, Sozialversicherungsnummern), um übereinstimmende Zeichenfolgen bei der Erfassung (Ingestion) zu maskieren. Entscheidend ist, dass für die Demaskierung die Berechtigung logs:Unmask erforderlich ist; gewähren Sie diese nur einer Break-Glass-Rolle. Benutzer, die die Log-Gruppe lesen können, aber nicht über Unmask verfügen, sehen nur Sternchen. Eine kontenweite Richtlinie gilt für alle aktuellen und zukünftigen Log-Gruppen, was die richtige Steuerung ist – Richtlinien pro Gruppe driften auseinander, wenn neue Services neue Gruppen erstellen.

Log-Abfragen im großen Maßstab: Insights und Athena

Zwei Abfrage-Engines adressieren unterschiedliche Datenebenen.

• CloudWatch Logs Insights fragt Daten ab, die sich bereits in CloudWatch Logs befinden, und verwendet dafür eine speziell entwickelte Abfragesprache. Ideal für aktuelle Betriebsdaten (Lambda-Logs, VPC Flow Logs in Logs, Anwendungs-Logs). Schnell, keine Schema-Einrichtung erforderlich, aber durch die CloudWatch-Aufbewahrungsdauer und die Kosten pro gescanntem GB eingeschränkt.

• Amazon Athena führt Presto/Trino-SQL für Daten in S3 aus. Ideal für forensische Abfragen im großen Maßstab über CloudTrail, ALB-Zugriffsprotokolle, in S3 gespeicherte VPC Flow Logs und CloudFront-Logs. Kosten: 5 $ pro gescanntem TB; verwenden Sie Partition Projection oder Glue-Partitionen nach Datum/Region, um die Scankosten drastisch zu senken.

Ein typischer forensischer Anwendungsfall: Identifizieren, wer einen KMS-Schlüssel deaktiviert hat. Da das CloudTrail-JSON verschachtelt ist, stellt die von CloudTrail erstellte Athena-Tabelle userIdentity als Struct bereit:

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';

Für die Analyse von Bots auf einem ALB aktivieren Sie die ALB-Zugriffsprotokolle nach S3, definieren Sie eine Athena-Tabelle über dem Log-Präfix, führen Sie dann einen Join mit einer Tabelle bekannter bösartiger IPs durch und visualisieren Sie die Aggregation in QuickSight. QuickSight liest von Athena, die Pipeline lautet also: ALB → S3 → Athena → QuickSight. Das Senden von ALB-Protokollen an CloudWatch Logs Insights ist kein unterstützter nativer Pfad – ALB-Protokolle gehen nur nach S3.

VPC Flow Logs können an beide Ziele gesendet werden: Wählen Sie Logs für taktische Untersuchungen wie filter dstPort=3389 and action="REJECT" und S3 (Parquet, partitioniert) für Trendabfragen über mehrere Monate.

Sammlung von Nachweisen mit Audit Manager

AWS Audit Manager automatisiert die kontinuierliche Sammlung von Nachweisen, die auf Frameworks wie PCI DSS, HIPAA, SOC 2 und CIS abgebildet sind. Er sammelt Nachweise aus Config-Regeln, Security Hub-Ergebnissen (Findings), CloudTrail-Ereignissen und dem Ressourceninventar und bündelt sie in Kontrollbewertungen (Control Assessments). Wenn er im Verwaltungskonto von Organizations oder im Konto eines delegierten Administrators aktiviert ist, sammelt er Daten aus allen Mitgliedskonten und erstellt einen Bewertungsbericht (Assessment Report) – ein gezipptes Bündel von Nachweisen mit einem Manifest –, den Auditoren anstelle von manuellen Screenshots akzeptieren. Dies ist die richtige Antwort, wenn ein Szenario nach kontinuierlichen, kontenübergreifenden, auf ein Framework ausgerichteten Nachweisen fragt: Config allein bietet Ressourcen-Compliance, aber keine Zuordnung zu einem Framework; Security Hub liefert Ergebnisse, aber keine Bündelung für eine Bewertung; ein selbst erstellter Athena-Bericht ist nicht kontinuierlich.

Zusammenfassung der Fallstricke

• CloudTrail die Schuld für fehlende Protokolle zu geben, ist normalerweise falsch: Der Bucket existiert möglicherweise nicht, die Bucket-Richtlinie lehnt den CloudTrail-Principal möglicherweise ab oder die Objekt-Eigentümerschaft ist falsch konfiguriert. Überprüfen Sie zuerst S3.

• Ein Trail für eine einzelne Region scheint günstiger zu sein, erzeugt aber einen unvollständigen Audit-Verlauf; Multi-Region ist die standardmäßig korrekte Antwort für eine organisationsweite Abdeckung.

• Mit SSE-KMS verschlüsselte Protokolle sind für Athena, Lambda-Parser oder Ingenieure unsichtbar, es sei denn, die CMK-Richtlinie gewährt diesen Principals kms:Decrypt – die Deaktivierung der Verschlüsselung ist nicht die Lösung; die Korrektur der Schlüsselrichtlinie ist es.

Praktisches Problem: Anwendungsfallszenario

Szenario: Meridian Financial betreibt eine AWS Organization mit mehreren Konten, darunter Produktions-, Staging- und ein dediziertes Protokollierungskonto. Ihre Umgebung hostet kundenorientierte APIs, Analysefunktionen und von IAM verwaltete Secrets. Sie benötigen eine zentralisierte, manipulationssichere Protokollierung sowie schnelle Untersuchungswerkzeuge, um auf Vorfälle reagieren und Compliance-Anfragen bearbeiten zu können.

Herausforderung: Eine kürzlich aufgetretene verdächtige Abfolge von Konsolenanmeldungen und Änderungen an IAM-Richtlinien blieb stundenlang unbemerkt. Es besteht die Sorge, dass die Protokollintegrität und die rechtzeitige Alarmierung für eine forensische Rekonstruktion und die Sammlung von Nachweisen durch Audit Manager unzureichend sind.

Empfohlener Ansatz:

1. Aktivieren Sie einen AWS Organizations CloudTrail (Organization Trail) in allen Regionen, schalten Sie die Integritätsprüfung für CloudTrail-Protokolldateien ein, liefern Sie Protokolle und Digest-Dateien an einen zentralen S3-Bucket, der mit einem KMS CMK verschlüsselt ist, dessen Schlüsselrichtlinie die Entschlüsselung auf ein kleines Sicherheitsteam beschränkt, und aktivieren Sie die S3-Zugriffsprotokollierung und -Versionierung.
2. Konfigurieren Sie CloudTrail so, dass Verwaltungs- und ausgewählte Datenereignisse an CloudWatch Logs gestreamt werden. Erstellen Sie dann CloudWatch Logs Metrikfilter für risikoreiche Muster (fehlerhafte Konsolenanmeldungen von neuen IPs, CreateUser, PutRolePolicy) und verknüpfen Sie CloudWatch Alarms mit SNS-Themen für Paging und ein automatisiertes Lambda-Playbook.
3. Stellen Sie CloudWatch Logs Insights-Dashboards für die interaktive Untersuchung aktueller Ereignisse bereit und legen Sie Aufbewahrungs- und Lebenszyklusregeln im Protokollierungskonto fest, um Nachweise gemäß den Richtlinien aufzubewahren.
4. Katalogisieren Sie CloudTrail-S3-Objekte mit AWS Glue und führen Sie Athena-Abfragen (partitioniert nach Region/Datum/Service) für groß angelegte retrospektive Analysen durch, um CSV-Nachweisexporte für Ermittler zu erstellen.
5. Erstellen Sie eine AWS Audit Manager-Bewertung (Assessment), die automatisch Nachweise von CloudTrail, AWS Config und IAM in einem Nachweisordner (Evidence Folder) sammelt und regelmäßige Exporte für Compliance-Prüfer plant.

Begründung: Die Zentralisierung und Validierung von CloudTrail, das Streaming zu CloudWatch für Echtzeit-Metrikfilter und -Alarme sowie die Nutzung von Athena/Logs Insights für skalierbare Abfragen folgen den AWS Best Practices für Erkennung, unveränderliche Protokollierung und forensische Bereitschaft (Forensic Readiness), während Audit Manager die Sammlung von Nachweisen für Audits automatisiert.

← Bedrohungserkennung und Alarmierung · Alle Domänen · Verschlüsselung →

Diese Fragen üben → · Zeitlich begrenzte Übung auf ExamRoll.io →

Amazon durchsuchen →