Amazon SCS-C02: Vorfallsreaktion 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.

Isolierung kompromittierter EC2-Instanzen

Das erste operative Ziel bei Verdacht auf eine kompromittierte EC2-Instanz ist die Eindämmung ohne Zerstörung von Beweismitteln. Die Eindämmung auf AWS ist eine mehrschichtige Aktivität, die die Netzwerkexposition der Instanz, ihre Lebenszyklus-Bindungen und ihre Zugänglichkeit für die Einsatzkräfte (Responder) betrifft.

Die kanonische Isolationssequenz beginnt mit der Verschärfung der Security Group der Instanz. Da idealerweise jede Instanz ihre eigene dedizierte Security Group hat, können Sie die Ingress- und Egress-Regeln durch einen minimalen Satz ersetzen, der nur dem Forensik-Team (oder einer dedizierten Diagnose-Security-Group) den Zugriff erlaubt. Wenn die Instanz hinter einem Application Load Balancer oder in einer Target Group sitzt, deregistrieren Sie sie zuerst; wenn sie Mitglied einer Auto Scaling Group ist, trennen Sie sie mit dem Flag --should-decrement-desired-capacity, damit die ASG nicht sofort einen Ersatz startet oder, schlimmer noch, die „fehlerhafte“ Instanz mitten in der Untersuchung beendet.

aws autoscaling detach-instances \
  --instance-ids i-0abc123 \
  --auto-scaling-group-name web-asg \
  --should-decrement-desired-capacity

aws elbv2 deregister-targets \
  --target-group-arn arn:aws:elasticloadbalancing:...:targetgroup/web/abc \
  --targets Id=i-0abc123

aws ec2 modify-instance-attribute \
  --instance-id i-0abc123 \
  --disable-api-termination

Die Aktivierung des Beendigungsschutzes (Termination Protection) ist unerlässlich, da ein wohlmeinender Operator, ein Automatisierungsskript oder ein ASG-Scale-In-Ereignis andernfalls genau die Volumes zerstören kann, die Sie zu sichern versuchen. Der Beendigungsschutz ist kein Ersatz für das Trennen von der ASG – eine ASG kann geschützte Instanzen während eines Scale-In-Vorgangs immer noch beenden, es sei denn, Sie entfernen die Instanz auch aus dem Geltungsbereich der Gruppe.

Für eine Eindämmung auf Subnetz-Ebene, wenn Sie eine sofortige Unterbrechung des ausgehenden Datenverkehrs benötigen (z. B. wenn eine Instanz Signale an bekannte bösartige IPs sendet), können Sie eine explizite „Deny-All“-Regel für ausgehenden Verkehr als Regel mit der niedrigsten Nummer zur Netzwerk-ACL des Subnetzes hinzufügen. Diese ist zustandslos und wirkt sich sofort auf alle Datenflüsse aus, im Gegensatz zu Änderungen an Security Groups, die sich nur auf neue Datenflüsse auswirken. Sobald Ihr forensischer Zugriffspfad über eine Diagnose-SG eingerichtet ist, kann die NACL-Deny-Regel entfernt werden, damit das Responder-Subnetz das Ziel über die SG-Allow-List erreichen kann.

Sicherung von flüchtigen und nichtflüchtigen Beweismitteln

Flüchtige Beweismittel – Prozesslisten, offene Netzwerk-Sockets, geladene Kernel-Module, Speicherinhalte, tmpfs-Inhalte – werden in dem Moment zerstört, in dem die Instanz angehalten wird. Nichtflüchtige Beweismittel befinden sich auf EBS und überstehen ein Anhalten/Starten, können aber dennoch verloren gehen, wenn Volumes getrennt oder die Instanz ohne Snapshots beendet wird. Die Reihenfolge lautet: Sammeln Sie zuerst flüchtige Artefakte, während die Instanz noch läuft, und erstellen Sie dann einen Snapshot von EBS.

Die Sammlung flüchtiger Daten sollte per Skript erfolgen und über SSM Run Command ausgeführt werden, anstatt durch einen Menschen, der in einer interaktiven Shell tippt. Run Command zeichnet den Aufruf, die Parameter, den ausführenden Principal und die Ausgabe in CloudWatch Logs oder S3 auf, was selbst Teil der Nachweiskette (Chain of Custody) wird.

Praktisches Problem: Anwendungsszenario

Szenario: Meridian Financial betreibt seine kundenorientierten Webanwendungen in einem einzigen AWS-Konto über mehrere VPCs hinweg. Dabei werden Auto Scaling Groups hinter Application Load Balancern, EBS-gestützte EC2-Instanzen, zentralisierte Protokollierung mit CloudTrail und CloudWatch, GuardDuty und ein S3-basiertes Log-Archiv, das mit KMS verschlüsselt ist, verwendet. Das Security-Operations-Team nutzt AWS Systems Manager für die Fernverwaltung und speichert Backups und Snapshots in einem dedizierten Wiederherstellungskonto.

Herausforderung: Eine EC2-Produktionsinstanz zeigt Anzeichen einer Kompromittierung mit verdächtigem ausgehendem Datenverkehr und unerwarteter Prozessaktivität. Das Team muss die Instanz isolieren und sowohl flüchtige Speicher- als auch nichtflüchtige Festplattenbeweise für die forensische Analyse sichern, ohne Audit-Trails zu zerstören.

Empfohlener Ansatz:

Verwenden Sie die Auto Scaling- und ELB-APIs, um die Instanz von den Target Groups zu trennen und Auto-Scaling-Prozesse auszusetzen. Wenden Sie dann eine restriktive Security Group an (deny all inbound/outbound) und aktualisieren Sie die Network-ACL-Regeln der Instanz, um den Netzwerkzugriff zu isolieren, während die Verwaltung über AWS Systems Manager Session Manager erhalten bleibt.
Verwenden Sie AWS Systems Manager Run Command, um eine In-Guest-Speichererfassung (z. B. mit LiME) auszuführen, die den RAM-Dump auf ein angehängtes, verschlüsseltes EBS-Volume oder direkt in einen S3-Bucket schreibt, der mit SSE-KMS verschlüsselt ist und bei dem S3 Object Lock für die Aufbewahrung aktiviert ist.
Verwenden Sie EC2 CreateSnapshot (oder CreateImage), um Point-in-Time-EBS-Snapshots aller angehängten Volumes zu erfassen. Kopieren Sie diese Snapshots anschließend in ein separates AWS-Konto oder eine andere Region, um die Nachweiskette zu wahren und Manipulationen zu verhindern.
Aktivieren oder rufen Sie VPC Traffic Mirroring für das ENI der Instanz ab, um Paketmitschnitte an eine dedizierte Überwachungs-EC2 zu senden. Exportieren Sie gleichzeitig VPC Flow Logs, ELB Access Logs, CloudTrail, CloudWatch Logs und GuardDuty-Ergebnisse in das sichere S3-Archiv.
Versehen Sie alle gesammelten Artefakte in AWS Security Hub oder einem Ticketsystem mit Tags und inventarisieren Sie sie. Stellen Sie sicher, dass S3-Objekte verschlüsselt sind und Object Lock gesetzt ist, und beschränken Sie den IAM-Zugriff auf ein kleines Forensik-Team, während alle Zugriffe über CloudTrail protokolliert werden.

Begründung: Die Isolierung des Netzwerkzugriffs vor der Erstellung von Images verhindert eine weitere Kontamination, während die Verwendung von SSM das Öffnen neuer Netzwerkvektoren vermeidet. Die vorherige Erfassung des flüchtigen Speichers und die Erstellung unveränderlicher EBS-Snapshots sowie sicherer S3-Archive wahren die Integrität der Beweismittel und die Nachweiskette im Einklang mit den Best Practices für Incident Response von AWS.

# ssm-document: capture-volatile.yml
schemaVersion: '2.2'
description: Collect volatile artifacts from a suspect Linux host
mainSteps:
  - action: aws:runShellScript
    name: volatileCapture
    inputs:
      runCommand:
        - TS=$(date +%s)
        - mkdir -p /var/ir/$TS && cd /var/ir/$TS
        - ps auxfww > processes.txt
        - ss -tanp > sockets.txt
        - lsof -n > openfiles.txt
        - cat /proc/mounts > mounts.txt
        - lsmod > modules.txt
        - dd if=/dev/mem of=mem.raw bs=1M 2>/dev/null || true
        - aws s3 cp . s3://ir-evidence-bucket/$INSTANCE_ID/$TS/ --recursive

Erstellen Sie unmittelbar nach der Erfassung der flüchtigen Daten einen Snapshot von jedem angehängten EBS-Volume. Versehen Sie die Snapshots mit der Incident-ID, damit sie eindeutig dem Fall zugeordnet sind.

aws ec2 create-snapshot \
  --volume-id vol-0def456 \
  --description "IR-2024-0917 root volume i-0abc123" \
  --tag-specifications 'ResourceType=snapshot,Tags=[
     {Key=IncidentId,Value=IR-2024-0917},
     {Key=SourceInstance,Value=i-0abc123},
     {Key=Handler,Value=jdoe}]'

Versehen Sie die Instanz selbst mit demselben Incident-Ticket, dem Namen des Ermittlers und einem Status-Label wie Quarantine. Ein konsistentes Tagging mit Metadaten ist der AWS-native Mechanismus für die Nachweiskette (Chain of Custody) – es ist abfragbar, über IAM Condition Keys unveränderlich und erscheint in jedem CloudTrail-Ereignis, das die Ressource betrifft.

Live-Response mit Session Manager und Run Command

Ein subtiler, aber prüfungsrelevanter Punkt: Bestehende SSH-Sitzungen überleben das Entfernen von Sicherheitsgruppenregeln. Sicherheitsgruppen sind zustandsbehaftet und werten Regeln beim Verbindungsaufbau aus; eine bereits etablierte TCP-Sitzung läuft weiter, auch nachdem die Eingangsregel, die sie erlaubt hat, gelöscht wurde. Wenn ein Responder eine Instanz isoliert, indem er SG-Regeln entfernt, während er für den Zugriff auf seine eigene SSH-Sitzung angewiesen ist, funktioniert diese Sitzung – bis sie abbricht. An diesem Punkt ist er ausgesperrt und jeder Wiedereintritt über einen Bastion-Host oder schlüsselbasiert ist nun unmöglich.

Das korrekte Vorgehen besteht darin, dem Forensik-Team Zugriff über den SSM Session Manager zu gewähren, der keinen offenen eingehenden Port erfordert. Der Session Manager arbeitet über die ausgehende Verbindung des SSM Agents zu den SSM-, EC2-Messages- und SSM-Messages-Endpunkten (idealerweise über VPC-Interface-Endpunkte, sodass die isolierte Instanz keine Internet-Route benötigt). Hängen Sie ein Instanzprofil an, das ssm:UpdateInstanceInformation und die Messages-APIs erlaubt, und gewähren Sie den Respondern ssm:StartSession, dessen Geltungsbereich per Tag auf die unter Quarantäne gestellte Instanz beschränkt ist.

Da Session-Manager-Sitzungen über die SSM-Steuerungsebene vermittelt werden, stört eine Verschärfung oder vollständige Leerung der Eingangsregeln der Sicherheitsgruppe sie nicht. Jeder Tastenanschlag kann in S3 oder CloudWatch Logs protokolliert werden – eine auditierbare interaktive Sitzung, keine Blackbox.

Kontoübergreifende Wiederherstellung von verschlüsselten Snapshots

In reifen Umgebungen werden forensische Snapshots in ein dediziertes Forensik-Konto geleitet, das vom kompromittierten Workload-Konto isoliert ist. Die Freigabe von Snapshots über Konten hinweg erfordert zwei Dinge: Der Snapshot muss für das Zielkonto freigegeben werden (modify-snapshot-attribute --create-volume-permission), und wenn der Snapshot mit einem kundenverwalteten KMS-Schlüssel verschlüsselt ist, muss die KMS-Schlüsselrichtlinie den Prinzipalen des Forensik-Kontos kms:Decrypt, kms:CreateGrant und kms:DescribeKey gewähren. Snapshots, die mit dem von AWS verwalteten aws/ebs-Schlüssel verschlüsselt sind, können nicht kontoübergreifend freigegeben werden – Sie müssen sie zuerst über einen Kopiervorgang mit einem CMK neu verschlüsseln. Kopieren Sie im Forensik-Konto den freigegebenen Snapshot und verschlüsseln Sie ihn unter einem lokalen forensischen CMK neu, damit die nachfolgende Volume-Erstellung nicht vom Quellkonto abhängt.

Playbook-Design und Minimierung des Overheads

Kodifizieren Sie die Eindämmungsschritte als SSM-Automation-Dokument oder Step-Functions-Workflow, der durch GuardDuty- oder Security-Hub-Erkenntnisse über EventBridge ausgelöst wird. Eine einzelne Automatisierung sollte: (1) flüchtige Daten über Run Command erfassen, (2) Snapshots von Volumes mit Incident-Tags erstellen, (3) den Terminierungsschutz aktivieren, (4) die Instanz von der ASG trennen und von den ELB-Zielen abmelden, (5) die SG durch die Quarantäne-SG ersetzen und (6) die Instanz mit der Ticket-ID taggen. Die Instanz am Laufen zu halten, bewahrt Live-Beweise und ermöglicht eine interaktive Untersuchung über den Session Manager – das Ausschalten sollte ein bewusster späterer Schritt sein, nicht Teil der automatischen Eindämmung, da das Herunterfahren flüchtige Beweise löscht und in Malware eingebettete Bereinigungslogik auslösen kann.

Die Fallen, die man verinnerlichen muss: Das Entfernen von SG-Regeln im Vertrauen auf eine bestehende SSH-Sitzung macht den Responder blind und vermittelt ein falsches Gefühl der Isolation; die Durchführung einer In-Place-Sanierung vor der Erstellung von Snapshots zerstört die Artefakte, die die Frage beantworten, wie der Einbruch geschah; und das Belassen der Instanz in ihrer ASG oder Zielgruppe lädt zur automatisierten Terminierung oder, schlimmer noch, zum stillschweigenden Austausch ein, was den Umfang des Vorfalls verschleiert.

Sofortige Eindämmung

Wenn ein Workload unter Kompromittierungsverdacht steht, ist die erste Entscheidung, ob er an Ort und Stelle isoliert oder außer Betrieb genommen werden soll. Das Außerbetriebnehmen – Anhalten oder Terminieren – zerstört flüchtige Beweismittel wie RAM-Inhalte, laufende Prozesse, offene Sockets und jegliche Malware, die nur im Arbeitsspeicher existiert. Die Eindämmung vor Ort ist fast immer der richtige erste Schritt, und sie muss schnell genug erfolgen, damit ein Angreifer keine weiteren Daten exfiltrieren oder sich seitlich bewegen kann, bevor die Kontrollen greifen.

Zwei AWS-native Kontrollen arbeiten auf unterschiedlichen Ebenen, und der Unterschied ist wichtig. Sicherheitsgruppen sind zustandsbehaftet und an Elastic Network Interfaces (ENIs) angehängt; Netzwerk-ACLs (NACLs) sind zustandslos und an Subnetze angehängt. Das Ersetzen der Sicherheitsgruppen einer Instanz durch eine abgeriegelte „Quarantäne“-SG ist der chirurgische Ansatz – er isoliert ein ENI, ohne andere Workloads im selben Subnetz zu stören, und bewahrt den Laufzeitzustand der Instanz. Änderungen an Sicherheitsgruppen wirken sich jedoch nur auf neue Datenflüsse aus, die auf das ENI treffen. Wenn die kompromittierte Instanz bereits langlebige ausgehende Verbindungen unterhält, kann der bestehende Zustand fortbestehen. NACL-Deny-Regeln werden an der Subnetzgrenze sofort wirksam und können den Datenverkehr noch schneller unterbinden, wenn Geschwindigkeit wichtiger ist als chirurgische Präzision – zum Beispiel, wenn mehrere Instanzen im selben Subnetz betroffen sind oder wenn die aktive Sitzung eines Angreifers sofort unterbrochen werden muss. NACLs sind auch nützlich, wenn eine Richtlinie die direkte Änderung einer Instanz verhindert.

Die kanonische Quarantäne-SG erlaubt keinen eingehenden Datenverkehr und ausgehenden Datenverkehr nur zu VPC-Interface-Endpunkten für com.amazonaws.<region>.ssm, com.amazonaws.<region>.ssmmessages und com.amazonaws.<region>.ec2messages. Das erhält den Zugriff über den Systems Manager Session Manager, während C2-Kanäle, Datenexfiltration und Lateral Movement blockiert werden.

QuarantineSG:
  Type: AWS::EC2::SecurityGroup
  Properties:
    GroupDescription: Forensic quarantine - SSM only
    VpcId: !Ref VpcId
    SecurityGroupEgress:
      - IpProtocol: tcp
        FromPort: 443
        ToPort: 443
        DestinationPrefixListId: !Ref SsmEndpointPrefixList
    SecurityGroupIngress: []

Reihenfolge der Beweissicherung

Der forensische Wert von Daten nimmt mit ihrer Flüchtigkeit ab, daher ist die Reihenfolge der Operationen fest und nicht verhandelbar:

Aktivieren Sie zuerst den Terminate-Schutz. Das Setzen von DisableApiTermination=true verhindert, dass ein Auto-Scaling-Ereignis, ein Fehler eines Operators oder eine geplante Aktion die Instanz mitten in der Untersuchung zerstört. Trennen Sie die Instanz auch von ihrer Auto-Scaling-Gruppe, damit Health-Checks der ASG sie nicht ersetzen können.
Von Auto Scaling trennen oder davor schützen. Verwenden Sie EnterStandby oder trennen Sie die Instanz, damit die ASG sie nicht als fehlerhaft beendet.
Erstellen Sie einen Snapshot von jedem angehängten EBS-Volume. CreateSnapshot (oder CreateSnapshots für die atomare Erfassung mehrerer Volumes) erzeugt ein unveränderliches, verschlüsseltes forensisches Artefakt. Verschlagworten Sie Snapshots mit der Incident-ID, der ID der Quellinstanz, dem Zeitstempel und dem Analysten. Kopieren Sie Snapshots in ein dediziertes Forensik-Konto des Sicherheitsteams, damit sie eine Kompromittierung des Kontos überstehen.
Arbeitsspeicher erfassen. Verwenden Sie ein SSM RunCommand-Dokument, um ein Tool zur Speicherakquise (LiME, AVML unter Linux; WinPMEM unter Windows) aufzurufen und das Abbild in einen S3-Forensik-Bucket mit Object Lock im Compliance-Modus zu streamen. Der Arbeitsspeicher muss erfasst werden, während die Instanz noch läuft – eine gestoppte Instanz hat keinen RAM, der erfasst werden könnte.
Metadaten sammeln. Erfassen Sie Instanz-ID, AMI, IAM-Instanzprofil, VPC/Subnetz, ENI-IDs, Tags, die Liste der laufenden Prozesse, die netstat-Ausgabe und IMDS-Inhalte. Versehen Sie die Instanz mit den Tags Status=Quarantined und IncidentId=<id>, damit nachgelagerte Automatisierungen und menschliche Bediener ihren Zustand erkennen.
Stoppen Sie die Instanz erst dann, wenn die Untersuchung eine Offline-Analyse der Festplatte erfordert. Das Stoppen löscht den Arbeitsspeicher, daher ist dies immer der letzte Schritt.

aws ec2 modify-instance-attribute --instance-id i-0abc --disable-api-termination
aws autoscaling enter-standby --instance-ids i-0abc \
    --auto-scaling-group-name app-asg --should-decrement-desired-capacity
aws ec2 create-snapshots --instance-specification InstanceId=i-0abc \
    --description "IR-2024-071 forensic" --copy-tags-from-source volume
aws ssm send-command --instance-ids i-0abc \
    --document-name "AWS-RunShellScript" \
    --parameters 'commands=["avml /tmp/mem.lime && aws s3 cp /tmp/mem.lime s3://forensics-bucket/"]'

Automatisierte IR-Workflows

GuardDuty-Ergebnisse sollten die Eindämmung innerhalb von Sekunden, nicht Stunden, auslösen. Die kanonische Pipeline ist EventBridge → Lambda → SSM Automation, mit SNS für Benachrichtigungen.

Eine EventBridge-Regel reagiert auf source: aws.guardduty mit dem Detail-Typ GuardDuty Finding und einem Muster, das auf EC2-relevante Ergebnistypen wie UnauthorizedAccess:EC2/*, Backdoor:EC2/*, Trojan:EC2/* und CryptoCurrency:EC2/* filtert.

{
  "source": ["aws.guardduty"],
  "detail-type": ["GuardDuty Finding"],
  "detail": {
    "type": [{"prefix": "UnauthorizedAccess:EC2/"},
             {"prefix": "Backdoor:EC2/"},
             {"prefix": "Trojan:EC2/"}]
  }
}

Das Lambda-Ziel extrahiert die Instanz-ID aus detail.resource.instanceDetails.instanceId und ruft dann ein SSM-Automation-Dokument auf (oder ruft direkt das SDK auf), um: den Terminate-Schutz zu aktivieren, die Sicherheitsgruppen des ENI über ModifyNetworkInterfaceAttribute durch die Quarantäne-SG zu ersetzen, Snapshots von allen angehängten Volumes zu erstellen, die Instanz zu taggen und eine SNS-Nachricht an den SOC-Kanal zu veröffentlichen. Die Verwendung von SSM Automation anstelle von reinen SDK-Aufrufen bietet schrittweise Audit-Trails im Ausführungsverlauf von Automation.

Protokollierung für Exfiltration und C2-Analyse

Eindämmung ohne Telemetrie ist nur Rätselraten. VPC Flow Logs müssen auf VPC- oder Subnetz-Ebene aktiviert sein, wobei der Verkehrstyp auf ALL (sowohl ACCEPT als auch REJECT) eingestellt ist. REJECT-Einträge decken Scans, blockierte Exfiltrationsversuche und C2-Beacons auf, die versuchen, bekannte schädliche IPs zu erreichen; ACCEPT-Einträge zeigen, welche Flows erfolgreich waren. Leiten Sie Flow Logs an CloudWatch Logs für Echtzeitabfragen und an S3 zur Langzeitaufbewahrung mit Object Lock weiter. CloudTrail mit Datenereignissen für den Forensik-S3-Bucket und KMS liefert die Audit-Kette für den Umgang mit Beweismitteln. Kombinieren Sie dies mit der Protokollierung von DNS-Abfragen (Route 53 Resolver), um DGA und DNS-Tunneling zu erkennen, die Flow Logs allein übersehen würden.

Kontrollierter forensischer Zugriff über Session Manager

Session Manager macht SSH-Schlüssel, Bastion-Hosts oder offene Ports 22/3389 überflüssig, und genau aus diesem Grund kann die Quarantäne-SG jeden traditionellen Zugriff blockieren. Aktivieren Sie die Sitzungsprotokollierung in einen S3-Bucket mit SSE-KMS und in CloudWatch Logs; erzwingen Sie EnforceEncryption=true in den Sitzungseinstellungen, damit keine Sitzung ohne TLS und Protokollverschlüsselung ausgeführt wird. IAM-Richtlinien für ssm:StartSession sollten auf Instanzen mit dem Tag tag:Status=Quarantined beschränkt und nur der Incident-Response-Rolle zugewiesen sein.

Typische Fallstricke und ihre Tücken

Zuerst stoppen oder beenden. Das Stoppen gibt den Arbeitsspeicher frei, beendet aktive Verbindungen und verhindert die Erfassung flüchtiger Artefakte. Das Beenden gibt zusätzlich das Root-Volume frei, es sei denn, DeleteOnTermination=false ist gesetzt, und selbst dann gehen Laufzeitzustände verloren. Führen Sie die Eindämmung immer vor Ort durch, bevor Sie den Energiezustand ändern.
Sich ausschließlich auf Security Groups verlassen, obwohl NACLs schneller sind. Änderungen an SGs sind präzise, wirken sich aber nur auf das ENI aus, an das sie angehängt sind, und steuern nur neue Datenflüsse. Wenn mehrere Instanzen in einem Subnetz betroffen sind oder wenn eine bestehende ausgehende Sitzung eines Angreifers sofort unterbrochen werden muss, schließt eine NACL-Deny-Regel auf Subnetz-Ebene die Tür schneller, da NACLs zustandslos sind und jedes Paket unabhängig vom vorherigen Zustand blockieren.
Problembehebung vor der Erstellung von Snapshots. Das Neu-Aufsetzen (Reimaging), Patchen oder Ersetzen der Instanz vor der Erstellung von EBS-Snapshots zerstört die auf der Festplatte befindlichen Beweismittel – Malware-Binärdateien, Persistenzmechanismen, Protokolle, Zeitstempel. Snapshots sind kostengünstig und unveränderlich; erstellen Sie sie vor jeder Maßnahme zur Problembehebung und kopieren Sie sie in ein dediziertes Forensik-Konto, damit ein kompromittiertes Produktionskonto sie nicht löschen kann.

Praktisches Problem: Anwendungsfallszenario

Szenario: Meridian Financial betreibt eine AWS-Umgebung mit mehreren Konten, wobei die Produktions-Workloads in einem dedizierten Konto laufen: EC2- und EKS-Services, die Kundendaten hosten, S3-Buckets für Archive, zentralisierte Protokollierung in einem Sicherheitskonto mit aktiviertem CloudTrail, GuardDuty, Security Hub und Config sowie eine CI/CD-Pipeline für Deployments. Ihr Betriebsteam verwendet Systems Manager für Patching und Wartung sowie Route 53/ALBs für öffentliche Endpunkte.

Herausforderung: Ein GuardDuty-Finding und unerwartete Spitzen im ausgehenden Datenverkehr deuten auf eine wahrscheinlich kompromittierte EC2-Instanz hin, die Daten exfiltriert und verdächtige IAM-API-Aufrufe tätigt. Dies erfordert eine sofortige Eindämmung bei gleichzeitigem Erhalt forensischer Beweismittel und der Gewährleistung eines auditierbaren Zugriffs für Ermittler.

Empfohlener Ansatz:

Sofortige Eindämmung über EventBridge auf Basis des GuardDuty-Findings auslösen, um einen Step Functions-Workflow aufzurufen. Dieser verwendet eine Lambda/SSM-Automatisierung, um eine Quarantäne-Security-Group anzuhängen, öffentliche IPs zu entfernen oder das ENI zu trennen und die betroffenen IAM-Anmeldeinformationen über IAM zu widerrufen/rotieren.
Flüchtige und persistente Beweismittel sichern, indem ein SSM-Automatisierungsdokument ausgeführt wird, um einen EBS-Snapshot und ein AMI der Instanz zu erstellen, die Snapshots in ein dediziertes AWS-Forensik-Konto zu kopieren und exportierte Artefakte in einem S3-Bucket mit S3 Object Lock (Compliance-Modus) und KMS-Verschlüsselung zu speichern.
Protokollierung für die Analyse von Exfiltration und C2 erfassen, indem sichergestellt wird, dass CloudTrail-Management- und Datenereignisse (S3, Lambda) aktiviert sind. VPC Flow Logs, ALB/NGINX-Zugriffsprotokolle und Route 53-Abfrageprotokolle werden an das zentrale Sicherheitskonto weitergeleitet und das Finding zur Korrelation der Zeitachse an Amazon Detective übergeben.
Orchestrierung und Benachrichtigungen mithilfe von EventBridge -> Step Functions -> Lambda automatisieren, um die Eindämmung, das Kopieren von Beweismitteln, SNS-Benachrichtigungen an die Verantwortlichen für den Vorfall und die Ticketerstellung im bestehenden ITSM-System zu koordinieren.
Kontrollierten forensischen Zugriff bereitstellen, indem AWS Systems Manager Session Manager für Live-Untersuchungssitzungen mit Sitzungsprotokollierung in CloudWatch Logs und dem forensischen S3-Bucket vorgeschrieben wird. Der Zugriff ist nur einer designierten forensischen IAM-Rolle mit MFA und temporären Anmeldeinformationen gestattet.

Begründung: Dieser Ansatz isoliert die Bedrohung schnell, bewahrt unveränderliche Artefakte und zentralisierte Protokolle für die Analyse, automatisiert wiederholbare Reaktionsschritte, um die Zeit bis zur Eindämmung zu verkürzen, und erzwingt einen auditierbaren forensischen Zugriff mit den geringsten Rechten über den Session Manager gemäß den AWS Best Practices.

← Container- und Serverless-Sicherheit · Alle Domänen

Diese Fragen üben → · Zeitlich begrenzte Übung auf 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.

Bestehe deine Prüfung →

Amazon durchsuchen →