# Kompromittierte Automation kontrolliert zurückführen
Typ: Checkliste
Herkunft: virtualization-private-cloud / virtualization-expert-capstone / virt-capstone-automation-containment
Version: virt-capstone-automation-containment-2026-07-30
Geprüft: 2026-07-30

ACHTUNG: Dieses Dokument ist ein Lernartefakt aus einer Schulungssequenz. Es ist kein produktives Runbook. Vor jeder Anwendung in einer realen Umgebung müssen die Schritte gegen lokale Dokumentation, Runbooks und Freigabestatus geprüft werden.

## Szenario
Ein Automatisierungsservice mit vCenter-API-Zugriff zeigt verdächtige VM- und Netzwerkänderungen. Ein getesteter Recoverypunkt, ein isolierter Runner und ein Plattformowner stehen bereit.

## Schritte
1. Token und Servicekonto gezielt sperren, API-Aktivität sichern und weitere Automationsläufe stoppen.
2. Betroffene VMs, Overlay-Policies, Management-Änderungen und Dienstwirkung gegen die Zeitlinie abgrenzen.
3. Runner aus vertrauenswürdigem Zustand wiederherstellen, Credentials rotieren und Minimalrechte sowie Netzscope neu setzen.
4. Management Plane, Overlay-Pfad und repräsentativen Guest-Workload im isolierten bzw. Pilot-Scope testen.
5. Nach Owner-Freigabe schrittweise verbinden, Monitoring erhöhen und Erkenntnisse in Rollen-, Runbook- und Change-Review übergeben.

## Begründung
Warum: Bei kompromittierter Automation werden Zugang und Wirkung zuerst begrenzt; Wiederherstellung ist erst nach neuen Minimalrechten und Tests über Management, Netz und Workload freigabefähig.
Folgen: **+** Erhält Evidenz und verhindert erneute unkontrollierte API-Änderungen. **−** Plattform- und Serviceowner müssen unter Zeitdruck koordiniert handeln.

## Quellen
1. https://docs.vmware.com/en/VMware-vSphere/8.0/vsphere-security/GUID-0D3D564F-8C91-4D5D-81A4-4A3A8CEB0D3A.html
2. https://www.cisa.gov/stopransomware/ransomware-guide