Amazon SCS-C02: Bedrohungserkennung und Alarmierung — 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.

Zentralisierung von GuardDuty über eine gesamte Organisation

Amazon GuardDuty ist ein Dienst zur kontinuierlichen Bedrohungserkennung, der CloudTrail Management- und Datenereignisse, VPC Flow Logs, DNS-Abfrageprotokolle, EKS-Audit-Protokolle, RDS-Anmeldeaktivitäten und Laufzeit-Telemetrie analysiert. Er erzeugt Erkenntnisse (Findings), die nach Bedrohungszweck (Backdoor, CryptoCurrency, Recon, UnauthorizedAccess, PenTest, Policy, Stealth, Trojan, Impact) und Ressourcentyp (EC2, IAMUser, S3, Kubernetes, RDS, Lambda, Runtime) klassifiziert sind.

Der Betrieb von GuardDuty auf Konto-für-Konto-Basis ist nicht skalierbar. Die korrekte Architektur in einer AWS Organizations-Umgebung besteht darin, einen delegierten Administrator – typischerweise das dedizierte Sicherheits- oder Audit-Konto – über das Verwaltungskonto der Organisation zu benennen. Vom delegierten Administrator aus aktivieren Sie GuardDuty organisationsweit und schalten die automatische Aktivierung (Auto-Enable) ein, sodass neue Mitgliedskonten und neue Regionen automatisch geschützt werden, sobald sie erstellt werden. Ohne die automatische Aktivierung bleibt ein neu bereitgestelltes Konto blind, bis ein Operator die Erkennung manuell aktiviert, was genau die Lücke ist, die Angreifer während des Onboardings ausnutzen.

Praktisches Problem: Anwendungsfallszenario

Szenario: Meridian Financial betreibt eine AWS-Umgebung mit mehreren Konten, die sich auf 28 Konten für Produktion, Entwicklung und gemeinsam genutzte Dienste verteilt. Ihr Verwaltungskonto steuert die Konten über AWS Organizations, mit zentralisierter CloudTrail- und S3-Protokollierung, aber Sicherheitswarnungen und Untersuchungsdaten sind über die Mitgliedskonten verstreut, was die Triage von Vorfällen langsam und inkonsistent macht.

Herausforderung: Eine kürzlich in einem Konto entdeckte laterale Bewegung erzeugte GuardDuty-Erkenntnisse, die für die zentralen SOC-Tools nicht schnell genug sichtbar waren, was die Eindämmung und die forensische Untersuchung verzögerte.

Empfohlener Ansatz:

Benennen Sie einen delegierten GuardDuty-Administrator im Verwaltungskonto und aktivieren Sie GuardDuty über AWS Organizations für die gesamte Organisation, sodass alle Mitgliedskonten ihre Erkenntnisse an einen zentralen Detektor weiterleiten.
Schalten Sie das zentralisierte AWS Security Hub im Verwaltungskonto als Aggregator ein und aktivieren Sie Security Hub für alle Konten und Regionen, um GuardDuty-Erkenntnisse zusammen mit anderen Sicherheitsstandards zu normalisieren.
Konfigurieren Sie Amazon EventBridge-Regeln im Verwaltungskonto, um GuardDuty- und Security Hub-Erkenntnisse zu erfassen und sie an zentrale Ziele wie Amazon SNS für Paging, Amazon Kinesis Data Firehose zu S3 zur Archivierung oder zur direkten Zustellung an Ihr SIEM weiterzuleiten.
Stellen Sie Lambda-Responder bereit, die von EventBridge ausgelöst werden, um automatisierte Eindämmungsmaßnahmen durchzuführen (z. B. eine EC2-Instanz über die EC2-API isolieren und einen AWS Systems Manager-Vorfall erstellen) und Erkenntnisse zur Untersuchung zu markieren.
Integrieren Sie Amazon Detective für die zentrale Untersuchung und leiten Sie archivierte Erkenntnisse in S3 zur langfristigen Korrelation und Berichterstattung an Ihre Analyse-/SIEM-Lösung weiter.

Begründung: Die Verwendung eines delegierten GuardDuty-Administrators mit Security Hub und EventBridge zentralisiert die Erkennung, normalisiert Warnungen und ermöglicht automatisierte, auditierbare Reaktionen gemäß den AWS Best Practices für organisationsweite Bedrohungserkennung und zeitnahe Reaktion auf Vorfälle.

# From the Organizations management account
aws organizations enable-aws-service-access \
  --service-principal guardduty.amazonaws.com

aws guardduty enable-organization-admin-account \
  --admin-account-id 111122223333

# From the delegated admin
aws guardduty update-organization-configuration \
  --detector-id abc123 \
  --auto-enable-organization-members ALL \
  --features '[{"Name":"RDS_LOGIN_EVENTS","AutoEnable":"NEW"},
               {"Name":"EKS_AUDIT_LOGS","AutoEnable":"NEW"},
               {"Name":"RUNTIME_MONITORING","AutoEnable":"NEW"}]'

GuardDuty ist regional, daher müssen die Beziehung zum delegierten Administrator und die Einstellungen für die automatische Aktivierung in jeder Region, in der Sie tätig sind, eingerichtet werden. Dies ist eine häufige Ursache für blinde Flecken – ein Team aktiviert GuardDuty in us-east-1 und geht von einer globalen Abdeckung aus.

Dienstspezifische Schutzmechanismen

Das Basis-GuardDuty deckt grundlegende Datenquellen ab, aber mehrere Schutzpläne müssen explizit aktiviert werden, da sie zusätzliche Kosten und die Erfassung weiterer Telemetriedaten verursachen:

RDS Protection: Profiliert die Anmeldeaktivitäten für Aurora MySQL/PostgreSQL- und RDS-Engines und generiert Erkenntnisse wie CredentialAccess:RDS/AnomalousBehavior.SuccessfulLogin, wenn sich unbekannte Benutzer an einem DB-Endpunkt authentifizieren. Dies ist die richtige Quelle zur Erkennung verdächtiger Datenbankanmeldungen – erstellen Sie keine benutzerdefinierten CloudWatch-Metrikfilter für DB-Audit-Protokolle, wenn RDS Protection die Erkenntnis bereits nativ ausgibt.
EKS Protection: Erfasst Kubernetes-Audit-Protokolle, um anomalen API-Zugriff, die Erstellung privilegierter Pods und die Nutzung exponierter Dashboards zu erkennen.
Runtime Monitoring: Stellt einen leichtgewichtigen, eBPF-basierten Agenten auf EC2, ECS/Fargate oder EKS bereit, um Prozess-, Datei- und Netzwerkereignisse aufzudecken – erforderlich zur Erkennung von dateiloser Malware oder Reverse Shells zur Laufzeit.
Malware Protection: Scannt EBS-Volumes per Snapshot, die an Instanzen angehängt sind, die durch andere Erkenntnisse markiert wurden, oder führt On-Demand-Scans von S3-Objekten beim Hochladen durch.
Lambda Protection und S3 Protection: Decken Aufrufmuster von Funktionen bzw. den Zugriff auf die S3-Datenebene ab.

Nur den Basisdienst zu aktivieren und zu erwarten, dass Anomalien bei DB-Anmeldungen erscheinen, ist eine häufige Fehlkonfiguration – die entsprechenden Arten von Erkenntnissen werden einfach nicht generiert, bis die zugehörige Funktion aktiviert ist.

Security Hub als Aggregationsebene

Security Hub erfasst Befunde von GuardDuty, Inspector, Macie, IAM Access Analyzer, Firewall Manager, Config, Health und ISV-Produkten von Drittanbietern und normalisiert sie in das AWS Security Finding Format (ASFF). Es führt auch eigene Compliance-Standards aus (AWS Foundational Security Best Practices, CIS, PCI DSS, NIST 800-53).

Zur Zentralisierung über eine gesamte Organisation hinweg:

Aktivieren Sie Security Hub als Service in Organizations und benennen Sie einen delegierten Administrator (in der Regel dasselbe Sicherheitskonto wie für GuardDuty).
Schalten Sie die automatische Aktivierung für neue Konten ein, damit Mitgliedskonten automatisch registriert werden.
Konfigurieren Sie eine Befundaggregations-Region (auch Heimatregion genannt) und verknüpfen Sie alle anderen Regionen mit ihr. Ohne regionsübergreifende Aggregation unterhält jede Region eine unabhängige Security-Hub-Instanz, und Analysten müssen zwischen den Konsolen wechseln.

Das Muster für einen globalen, organisationsweiten Rollout erfordert daher zwei koordinierte Einstellungen: die Verknüpfung der Aggregations-Region und den organisationsweiten Schalter zur automatischen Aktivierung. Wird nur eine der beiden Einstellungen aktiviert, bleiben entweder neue Konten unberücksichtigt oder neue Regionen isoliert.

Eine wichtige Einschränkung: Security Hub aggregiert und priorisiert, aber er führt keine Behebungsmaßnahmen durch. Ihn als Behebungsplattform zu behandeln, ist ein Kategorienfehler – die Behebung erfolgt nachgelagert über EventBridge.

EventBridge als Automatisierungs-Fabric

Sowohl GuardDuty als auch Security Hub veröffentlichen Befunde im Standard-Event-Bus. aws.guardduty emittiert GuardDuty Finding-Ereignisse, und aws.securityhub emittiert Security Hub Findings - Imported (vom Hub erstellt/aktualisiert) und Security Hub Findings - Custom Action (vom Bediener ausgelöst).

Zu weit gefasste Regeln wie {"source": ["aws.securityhub"]} rufen bei jeder Aktualisierung eines Befunds von jedem Anbieter Ziele auf, was schnell SNS-Themen überflutet und Bereitschaftsingenieure mit informativem Rauschen alarmiert. Der korrekte Ansatz ist, nach severity.Label, ProductArn, Types oder spezifischen Title-Werten zu filtern:

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

Für ein Security-Hub-zentrisches Muster, das nur bei GuardDuty-Befunden mit hohem Schweregrad ausgelöst wird und gleichzeitig gesprächige ISV-Produkte von Drittanbietern ignoriert:

{
  "source": ["aws.securityhub"],
  "detail-type": ["Security Hub Findings - Imported"],
  "detail": {
    "findings": {
      "Severity": { "Label": ["HIGH", "CRITICAL"] },
      "ProductArn": [
        { "wildcard": "arn:aws:securityhub:*::product/aws/guardduty" }
      ],
      "Workflow": { "Status": ["NEW"] }
    }
  }
}

Gängige Ziele sind ein SNS-Thema für Benachrichtigungen per E-Mail/SMS/Slack, eine Lambda-Funktion, die eine Instanz durch Austausch ihrer Sicherheitsgruppe isoliert, ein SSM-Automation-Runbook oder eine Step-Functions-Zustandsmaschine, die eine mehrstufige Reaktion orchestriert. Für den Anwendungsfall der Aurora-Anmeldeanomalie ist der Weg mit dem geringsten Aufwand: GuardDuty RDS Protection → EventBridge-Regel, die nach dem RDS-Befundtyp filtert → SNS-Thema mit E-Mail-Abonnement. Kein benutzerdefiniertes Polling, keine Lambda-Funktion und kein Drittanbieter-SIEM erforderlich.

Benutzerdefinierte Aktionen in Security Hub

Benutzerdefinierte Aktionen sind vom Bediener gesteuerte Auslöser. In der Security-Hub-Konsole wählt ein Analyst einen oder mehrere Befunde aus und entscheidet sich für eine benutzerdefinierte Aktion (z. B. „Quarantine EC2“). Security Hub emittiert ein Security Hub Findings - Custom Action-Ereignis, das die ARNs der ausgewählten Befunde enthält. Eine EventBridge-Regel passt auf den ARN der benutzerdefinierten Aktion und ruft eine Lambda-Funktion auf, die die Reaktion durchführt. Dies gibt Ihnen eine Human-in-the-Loop-Schaltfläche, ohne eine maßgeschneiderte Benutzeroberfläche erstellen zu müssen:

aws securityhub create-action-target \
  --name "Quarantine EC2" \
  --description "Attach isolation SG and snapshot volumes" \
  --id QuarantineEC2

Der resultierende ARN (arn:aws:securityhub:us-east-1:111122223333:action/custom/QuarantineEC2) wird zum Abgleichswert im resources-Feld der EventBridge-Regel.

Unterdrückung und Signal-Management

Rauschmanagement ist eine Disziplin, keine einmalige Filterung. Verwenden Sie Automatisierungsregeln in Security Hub oder Unterdrückungsregeln in GuardDuty, um Befunde automatisch zu archivieren, die als unbedenklich bekannt sind (z. B. ein erwarteter Recon:EC2/Portscan-Befund eines Penetrationstest-Tools). Filtern Sie EventBridge-Regeln nach ProductArn, um eine gesprächige Drittanbieter-Integration stummzuschalten, ohne sie vollständig zu deaktivieren. Kombinieren Sie Severity.Label mit Workflow.Status = NEW, damit wiedereröffnete oder bereits gemeldete Befunde keine erneute Alarmierung auslösen. Das Ziel ist, dass jede Benachrichtigung, die einen Menschen erreicht, ein handhabbares, hochgradig vertrauenswürdiges Ereignis darstellt – alles andere untergräbt die Reaktionsbereitschaft.

Dreh- und Angelpunkt für Untersuchungen

Wenn ein Befund mit hohem Schweregrad ausgelöst wird – zum Beispiel Backdoor:EC2/C&CActivity.B!DNS – ist der schnellste Untersuchungsweg nicht, von Hand Athena-Abfragen für CloudTrail und Flow Logs zu schreiben. Wenn Amazon Detective zusammen mit GuardDuty aktiviert ist, erstellt es vorab Entitätsgraphen aus CloudTrail, VPC Flow Logs und GuardDuty-Befunden. Der direkte Wechsel vom Befund zur IAM-Rolle oder zum EC2-Instanzprofil in Detective macht API-Aktivitäten, Netzwerk-Peers und die Anzahl erfolgreicher im Vergleich zu fehlgeschlagenen Verbindungen über den relevanten Zeitraum sichtbar, ohne dass dafür benutzerdefinierte Abfragen erforderlich sind.

← Identitäts- und Zugriffsverwaltung · Alle Domänen · Protokollierung →

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