Sophos NDR auf AWS bereitstellen

Sophos NDR läuft in AWS als EC2-basierte Integrations-Appliance. Sie empfängt eine Kopie des ausgewählten VPC-Verkehrs über VPC Traffic Mirroring, analysiert diesen passiv und übermittelt NDR-Daten an den Sophos Data Lake. Die Appliance liegt nicht inline und ersetzt weder Security Groups noch eine Firewall.

Der belastbare Kurzablauf lautet: Lizenz und Verantwortlichkeiten klären, AWS-Netzwerte festhalten, die Appliance in Sophos Fusion anlegen, das generierte CloudFormation-Template herunterladen, das Marketplace-Angebot abonnieren, den Stack erstellen, genau eine kontrollierte Mirror Session hinzufügen, den Managementzugang einschränken und jede Schicht einzeln abnehmen.

⚠️ Dieses Runbook enthält bewusst keinen vollständigen Rückbau. Die sichere Reihenfolge und die Folgen beim Löschen von Stack, Appliance, EC2-, EBS-, ENI-, Security-Group-, Elastic-IP-, Mirror- und Marketplace-Ressourcen sind nicht vollständig verifiziert. Ein fehlgeschlagenes Deployment darf deshalb nicht mit einer improvisierten Löschreihenfolge „bereinigt“ werden.

Architektur und Entscheidungen vor dem Start

CloudFormation erstellt zwei logisch getrennte Netzwerkpfade:

Die Management Interface liegt in einem Public Subnet und verwendet eine zugewiesene Elastic IP Address. Darüber erfolgen SSH und der Zugriff auf Sophos Appliance Manager.
Die SPAN interface empfängt gespiegelten Verkehr. Als Mirror Target dient der vom Template erstellte NDR SPAN Target.
Eine Traffic mirror session verbindet eine ausgewählte Quell-ENI mit diesem Target. Der ebenfalls erstellte NDR Traffic Mirror Filter bestimmt, welche Pakete gespiegelt werden.
Die Appliance verarbeitet die Kopien und sendet NDR-Daten an Sophos. Die ursprünglichen Flows bleiben auf ihrem normalen AWS-Datenpfad.

Damit ist die wichtigste Designentscheidung nicht „welche ganze VPC überwachen wir?“, sondern welche ENI ist eine sinnvolle Mirror Source. Beginne mit einer einzelnen, dokumentierten ENI eines Testsystems. Das hält Datenvolumen, Kosten und Fehlerbereich klein. Weitere Quellen werden erst nach der technischen Abnahme ergänzt.

Vor dem Deployment gehört mindestens Folgendes in einen Bauplan:

AWS-Konto, Region, VPC, Availability Zone und Owner-Tags;
VPC-ID sowie Management- und SPAN-Subnet-ID;
mindestens eine im AWS-Konto zugewiesene Elastic IP für die Management Interface; sie ist eine Kontovoraussetzung, aber in der dokumentierten Parameterliste kein vorab wählbarer Template-Input;
aktuell von Sophos unterstützte EC2-Typen: c5n.2xlarge, c6i.4xlarge oder c7i.16xlarge mit Nitro-Virtualisierung; welcher Typ tatsächlich verwendet wird, ist am aktuellen Tenant-Template und nach dem Deployment an der Instanz zu prüfen;
Name des vorhandenen SSH Key Pair und sicherer Aufbewahrungsort des Private Key;
Security Group für SSH und feste Admin-Quellnetze;
erste Mirror-Source-ENI und das dafür verantwortliche Workload-Team;
erwarteter normaler Testverkehr dieser ENI;
Kostenstelle, Budgetalarm und Freigabe für AWS-Infrastrukturkosten sowie die für dieses Konto angezeigten Marketplace-Bedingungen.

VPC, Subnets und Elastic IP

Eine vorhandene VPC und vorhandene Subnets können verwendet werden. Die Auswahl darf sich aber nicht nur am Namen orientieren:

Das Management-Subnet muss als Public Subnet geplant sein. Vor der Auswahl werden dessen Route Table und der vorgesehene Internetpfad geprüft.
Das SPAN-Subnet wird für die NDR SPAN interface angegeben. Halte Subnet und Availability Zone gemeinsam mit der Mirror Source fest, statt die Werte später aus Ressourcennamen zu erraten.
Die Elastic IP gehört an die Management Interface, nicht an die SPAN-Seite. Stelle vorab sicher, dass im Konto mindestens eine Elastic IP zugewiesen ist. Behaupte nicht, dass der Stack eine bestimmte vorhandene Adresse verwendet: Ermittle und protokolliere nach CREATE_COMPLETE die tatsächlich erzeugte beziehungsweise verwendete Adresse und ihre ENI-Zuordnung.
Das Template wählt AMI und Region automatisch anhand der AWS-Region, in welcher das Template hochgeladen wird. Erzwinge keine andere AMI durch eine manuelle Templateänderung.

Security Groups und SSH Key Pair

Verwende ein vorhandenes AWS Key Pair, dessen Private Key bereits sicher gespeichert ist. CloudFormation benötigt den Namen des Key Pair; der Private Key wird nicht in Sophos Fusion oder im Template hinterlegt. Ohne den Private Key ist der von Sophos dokumentierte SSH-Zugang für die AWS-Appliance später nicht verfügbar.

Bereite eine Security Group vor, die SSH nur aus dem administrativen Zugangsnetz zulässt, beispielsweise aus einer festen Firmen-Egress-IP als /32 oder über einen kontrollierten Jump Host. Öffne weder SSH noch TCP 8443 für 0.0.0.0/0.

Das Template erstellt zusätzlich InternalMgmtSG. Nach dem Deployment wird dort TCP 8443 nur für die tatsächlichen Admin-Quellen freigegeben. Falls dieselbe Appliance zusätzlich einen Log Collector hostet, wird Syslog ausschliesslich mit dem vom jeweiligen Connector verlangten Protokoll und Port aus den internen Quellnetzen erlaubt. VPC Traffic Mirroring selbst benötigt keine pauschale Syslog-Freigabe aus dem Internet.

Outbound-Verbindung vorab prüfen

Ein Public Subnet und eine Elastic IP belegen noch keinen funktionierenden ausgehenden Pfad. Vor Submit muss das verantwortliche Netzwerkteam bestätigen, dass die Management Interface über die vorgesehene Route und ein Internet Gateway oder das genehmigte zentrale Egress-Design ausgehend kommunizieren kann. Prüfe dazu DNS-Auflösung, Route Table, Network ACL, Security-Group-Egress sowie Proxy- und Upstream-Firewall-Regeln.

Die benötigten Ziele und Ports werden nicht in dieses Runbook kopiert. Gleiche stattdessen zum Change-Zeitpunkt die aktuellen Port- und Domain-Ausnahmen für Sophos-Appliances mit dem Egress-Regelwerk ab. Diese Freigaben sind für Boot, Updates, Registrierung und Datenupload relevant; ein Verbindungsnachweis zu einem einzelnen Ziel ersetzt den vollständigen Abgleich nicht.

Voraussetzungen, Rollen, Lizenz und Kosten

Für die Einrichtung werden benötigt:

ein AWS-Konto mit vorhandener VPC, Subnets und Availability Zones;
ein Sophos-Fusion-Konto;
im Regelfall das Sophos Network Detection and Response integration license pack;
mindestens eine geeignete EC2-Quellinstanz beziehungsweise deren ENI;
mindestens eine im AWS-Konto zugewiesene Elastic IP Address;
ein gespeichertes AWS SSH Key Pair;
eine aktuelle Change-Freigabe für Netzwerkspiegelung und die dabei verarbeiteten Daten.

Teile die Arbeit nach Möglichkeit auf, ohne unbestätigte IAM-Policy-Namen zu erfinden:

Ein Sophos-Fusion-Administrator erstellt die NDR-Konfiguration und lädt das Template herunter.
Eine für Beschaffung autorisierte Person akzeptiert die Bedingungen von Sophos Integration Appliance im AWS Marketplace.
Ein AWS-Administrator mit den für den Stack und die referenzierten Netzwerkressourcen nötigen Rechten erstellt CloudFormation-, EC2-, VPC-Traffic-Mirroring-, Security-Group- und Elastic-IP-Ressourcen.
Das zuständige Netzwerk- oder Workload-Team bestätigt Mirror Source, Filterwirkung, Testfenster und erwarteten Traffic.

Sophos nennt keine separate minimale NDR-spezifische Fusion-Rolle für diesen Ablauf. Wenn Add Configuration, Download image oder Open Appliance Manager nicht sichtbar ist, darf deshalb nicht geraten werden: Ein Super Admin soll die effektiven Tenant-Rechte und die Lizenz prüfen.

Die einzige hier berücksichtigte Ausnahme ist eng begrenzt: Für MSP-Flex-Kunden mit einer XDR-Lizenz dokumentiert Sophos, dass Sophos NDR ohne zusätzliches Integration License Pack integriert werden kann. Daraus folgt weder, dass jede XDR- oder MDR-Subscription NDR umfasst, noch dass die Ausnahme für Term-Lizenzen gilt. Bestätige deshalb die konkrete Tenant-/SKU-Berechtigung in Fusion und bei Unklarheit mit Sophos beziehungsweise dem beschaffenden Partner anhand der aktuellen Sophos-Integrationslizenzregeln.

CloudFormation erzeugt kostenpflichtige AWS-Ressourcen. Die virtuelle Appliance ist im anwendbaren Sophos-NDR-Entitlement enthalten; daraus wird hier weder ein öffentlicher Listenpreis noch eine Aussage über das konkrete Marketplace-Angebot des Kontos abgeleitet. Prüfe vor Submit die aktuell angezeigten Marketplace-Bedingungen. Schätze separat die AWS-Kategorien EC2, Speicher, öffentliche IPv4-Adresse/Elastic IP, Datenübertragung und VPC Traffic Mirroring. Dieses Runbook nennt absichtlich keine festen Beträge: Region, Laufzeit, Datenvolumen und AWS-Preismodell verändern die Rechnung. Tags und ein Budgetalarm gehören vor der produktiven Spiegelung in den Change.

1. Appliance und CloudFormation-Template in Sophos Fusion erstellen

Öffne in Sophos Fusion Threat Analysis Center > Integrations > Marketplace.
Öffne Sophos Network Detection and Response (NDR).
Klicke unter Data Ingest (Security Alerts) auf Add Configuration.
Trage in Step 1 einen eindeutigen Namen und eine Beschreibung ein, zum Beispiel ndr-aws-prod-eu1 und NDR Sensor für AWS Produktions-VPC eu1.
Wähle in Step 2 unter Virtual platform den Wert AWS.
Klicke auf Save. Sophos erzeugt die CloudFormation-Datei aws_ndr_cf_latest.json.
Öffne Threat Analysis Center > Integrations > Configured und danach den Tab Integration Appliances.
Suche die gerade erstellte Appliance. Öffne in der rechten Spalte das Drei-Punkte-Menü, wähle Download image und speichere aws_ndr_cf_latest.json im geschützten Change-Ordner.

Das JSON stammt aus dem eigenen Fusion-Tenant und der gerade angelegten Appliance. Verwende nicht eine alte Datei aus einem anderen Tenant oder Change. Ändere das Template nicht manuell, um nicht unterstützte Instanztypen, AMIs oder Netzvarianten zu erzwingen.

2. Marketplace-Angebot abonnieren

Suche in AWS Marketplace nach Sophos Integration Appliance.
Klicke auf der Seite Product Overview auf Continue to Subscribe.
Prüfe auf Subscribe to this software die Bedingungen und akzeptiere sie nur mit der vorgesehenen Beschaffungsfreigabe. Klicke danach auf Continue to Configuration.
Prüfe auf Configure this software Version und Region. Sie müssen zum Bauplan passen. Klicke auf Continue to Launch.
Öffne auf Launch this software zuerst Usage instructions und dokumentiere die angezeigten Zugangshinweise.
Klicke auf Launch. AWS öffnet Create stack.

Das Marketplace-Abonnement ist eine Voraussetzung dafür, dass AWS die im Template referenzierte Software akzeptiert. Beginne die Fehlersuche bei einer nicht verfügbaren AMI oder einem Entitlement-Fehler deshalb beim Abonnement, bei Region und Version, nicht mit Änderungen am JSON.

3. CloudFormation-Stack erstellen

Öffne vor dem Ausfüllen die Parameter des aktuell aus diesem Tenant generierten Templates. Falls es einen dokumentierten Parameter für den EC2-Instanztyp anbietet, wähle dort ausschliesslich einen aktuell von Sophos unterstützten Typ und protokolliere Parametername und Wert. Bietet es keinen solchen Parameter an, wählt das Template den Typ; editiere das JSON nicht manuell. In beiden Fällen wird der tatsächlich gestartete EC2-Typ nach der Erstellung verifiziert.

Lasse unter Create stack die Option Template is ready ausgewählt.
Wähle unter Specify template die Option Upload a template file.
Klicke auf Choose file, wähle die soeben erzeugte aws_ndr_cf_latest.json und danach Next.
Vergib unter Specify stack details einen eindeutigen Stack name, beispielsweise sophos-ndr-prod-eu1.
Trage unter Network Configuration ein:
- die geplante vorhandene VPC;
- das Public Subnet für die NDR Management Interface;
- das Subnet für die NDR SPAN interface;
- die vorbereitete Security Group für den administrativen SSH-Zugang.
Wähle unter EC2 Instance Configuration das vorhandene SSH Key Pair. Prüfe nochmals, dass der Private Key auffindbar und geschützt ist.
Klicke auf Next. Prüfe unter Configure stack options Tags und die übrigen AWS-Optionen. Übernimm Defaults nicht blind, sondern vergleiche sie mit dem Change.
Prüfe die Zusammenfassung und klicke auf Submit.
Warte auf CREATE_COMPLETE. Sophos nennt dafür typischerweise fünf bis sechs Minuten; die CloudFormation-Events sind massgebend, nicht diese Zeitangabe.

Vor der Mirror Session müssen im Stack beziehungsweise in den zugehörigen AWS-Ressourcen mindestens die erwartete Sophos-Appliance, ihr tatsächlicher EC2-Typ, Management- und SPAN-ENI, NDR SPAN Target, NDR Traffic Mirror Filter, InternalMgmtSG sowie die tatsächlich verwendete Elastic IP und deren Zuordnung auffindbar sein. Fehlt ein Element oder endet der Stack nicht mit CREATE_COMPLETE, wird keine Mirror Session angelegt.

4. Eine Traffic Mirror Session erstellen

Nicht jede EC2-ENI oder Topologie ist automatisch als Mirror Source geeignet. Prüfe vor dem Anlegen anhand der aktuellen AWS-Dokumentation die unterstützten Quell-Instanztypen sowie die Voraussetzungen und Einschränkungen für das Mirror Target und die konkrete Source/Target-, Region- und Availability-Zone-Topologie. Prüfe ausserdem in Service Quotas und anhand der AWS-Quoten für Traffic Mirroring, ob für Source, Sessions, Targets und Filter ausreichend Kontingent vorhanden ist. Diese AWS-Prüfung ist ein eigener Freigabepunkt; die Sophos-Liste unterstützter Appliance-Typen bestätigt nicht die Mirror-Fähigkeit einer beliebigen Workload-ENI.

Öffne VPC > Traffic mirror sessions > Create traffic mirror session und fülle die Felder bewusst aus:

Name Tag: sprechender Name, beispielsweise ndr-prod-app01;
Description: Zweck und Change-Referenz, beispielsweise Mirror app01 ENI to Sophos NDR - CHG-1234;
Mirror Source: die ENI des freigegebenen Testsystems, nicht lediglich eine EC2-Instanz mit ähnlichem Namen;
Mirror Target: der durch den Stack erstellte NDR SPAN Target;
Session number: eine für diese Source passende Nummer. AWS verwendet sie zur Reihenfolge, wenn dieselbe Source mehrere Sessions hat. Inventarisiere vorhandene Sessions vor der Wahl;
VNI: 1;
Filter: der durch den Stack erstellte NDR Traffic Mirror Filter.

Klicke erst nach dem Vier-Augen-Vergleich von Source, Target, Session number, VNI und Filter auf Create. VNI = 1 und die Wahl des generierten Filters sind Produktvorgaben. Source, Name, Beschreibung und Session number müssen dagegen zur eigenen AWS-Umgebung passen.

Lege beim ersten Test keine weiteren Quellen „vorsorglich“ an. Eine zusätzliche Mirror Session vergrössert Datenmenge, Kosten und Untersuchungsbereich und benötigt deshalb eine eigene fachliche Freigabe.

5. Managementzugang und Credentials einrichten

Suche in der AWS Console nach dem Namen der Appliance, wähle den Tab EC2 und öffne die Instanz Sophos Appliance.
Öffne auf Instance Summary den Tab Security und danach InternalMgmtSG.
Ergänze unter Inbound rules TCP 8443 nur für die freigegebenen Admin-CIDRs. Dokumentiere Rule-ID, Quelle und Change-Referenz.
Öffne in Sophos Fusion Threat Analysis Center > Integrations > Configured > Integration Appliances.
Öffne bei der Appliance das Drei-Punkte-Menü und wähle Open Appliance Manager.
Klicke im Bestätigungsdialog auf reset it, um das Passwort festzulegen.
Melde dich mit dem festen Benutzernamen zadmin und dem gesetzten Passwort an.

Behandle das zadmin-Passwort wie ein privilegiertes Secret. Lege es im freigegebenen Passwort-Tresor ab, nicht im CloudFormation-Template, Ticket oder Screenshot. Alle Administratoren verwenden dasselbe Appliance-Manager-Passwort. Geht es verloren, wird es über Open Appliance Manager > reset it neu gesetzt.

Abnahme von Deployment und Erstregistrierung

Ein laufender EC2-Status allein beweist weder den Mirror-Pfad noch die Registrierung. Prüfe in dieser Reihenfolge:

CloudFormation: Der Stack zeigt CREATE_COMPLETE; die erwarteten Ressourcen und keine übersprungenen oder fehlgeschlagenen Events sind vorhanden.
Netzzuordnung: VPC, Management-Subnet, SPAN-Subnet, Elastic IP, beide ENIs und SSH Key Pair entsprechen dem Bauplan.
Exposition: SSH und TCP 8443 sind nur aus den genehmigten Admin-Netzen erreichbar. Es existiert keine neue Managementregel mit 0.0.0.0/0.
Mirror-Konfiguration: Die Session verweist auf exakt die freigegebene Source-ENI, den NDR SPAN Target, VNI 1 und den NDR Traffic Mirror Filter. Session number und vorhandene parallele Sessions sind dokumentiert.
Sophos-Verbindung: Die Appliance ist unter Integration Appliances auffindbar; ihr NDR-Status in Sophos Fusion ist grün, Open Appliance Manager öffnet das erwartete Ziel und die Anmeldung als zadmin funktioniert.
Vorläufiger Datenpfad: Erzeuge im freigegebenen Testfenster normalen, ungefährlichen Verkehr auf der Mirror-Source-ENI. Prüfe im Tab NDR des Appliance Manager den Upload-Prozentsatz, den Capture-Prozentsatz des konfigurierten SPAN-Ports und den Graphen Total flows. Halte Messzeit und Werte fest. Eine Detection ist für diesen Infrastrukturtest nicht erforderlich.
Negativkontrolle: Eine nicht freigegebene Admin-Quelle darf TCP 8443 nicht erreichen. Diese Kontrolle belegt die Managementbegrenzung, nicht die NDR-Erkennung.

Halte Stack-ID, Appliance-Name, Instanz-ID und -Typ, Management- und SPAN-ENI, tatsächliche EIP-Zuordnung, Mirror-Session-ID, Source-ENI, Target, Filter, VNI, Security-Group-Rule-IDs, NDR-Messwerte und das Abnahmezeitfenster fest. Secrets gehören nicht in dieses Protokoll. Diese Abnahme bestätigt nur Bereitstellung und Erstregistrierung. Prüfe danach den gespiegelten Datenpfad vollständig mit Traffic Mirroring für Sophos NDR konfigurieren und validieren und führe anschliessend einen sicheren End-to-End-Detection-Test aus. Weder Login noch gewöhnlicher Testverkehr beweisen allein eine funktionierende Erkennungskette.

Troubleshooting nach Symptom

Stack endet nicht mit `CREATE_COMPLETE`

Öffne zuerst den Stack-Tab Events und arbeite vom ersten fehlgeschlagenen Event aus, nicht von der letzten Folgefehlermeldung rückwärts.

Bei Marketplace- oder AMI-Entitlement-Fehlern: Abonnement, akzeptierte Bedingungen, Version und Region prüfen.
Bei Berechtigungsfehlern: Den AWS-Administrator die im konkreten Event genannte Aktion und Ressource prüfen lassen. Keine pauschale Administrator-Policy als Schnelllösung vergeben.
Bei Netzwerkparametern: VPC- und Subnet-IDs, zugewiesene Elastic IP beziehungsweise verfügbares EIP-Kontingent, Security Group und SSH Key Pair mit dem Bauplan vergleichen.
Bei Kapazitäts- oder Quotenfehlern: den gewählten unterstützten Instanztyp und die konkrete AWS-Fehlermeldung prüfen. Nicht auf einen vom Template nicht angebotenen Typ ausweichen.

Solange der Stack unvollständig ist, werden weder Mirror Session noch zusätzliche Inbound Rules erstellt.

Appliance läuft, aber es kommt kein gespiegelter Verkehr an

Prüfe die Kette in dieser Reihenfolge:

Ist Mirror Source wirklich die ENI, über welche der Testverkehr läuft?
Ist Mirror Target der NDR SPAN Target dieses Stacks und nicht ein ähnlich benanntes Target einer anderen Umgebung?
Steht VNI auf 1?
Ist der NDR Traffic Mirror Filter ausgewählt?
Kollidiert die Session number mit der beabsichtigten Auswertungsreihenfolge anderer Sessions derselben Source?
Wurde während des dokumentierten Fensters tatsächlich Verkehr über diese ENI erzeugt?

Ändere immer nur eine dieser Variablen und wiederhole danach denselben Test. Eine breitere Filter- oder Source-Auswahl ist kein Ersatz für die Ursachenanalyse.

Mirror Session lässt sich nicht erstellen

Lies zuerst die konkrete AWS-API-/Konsolenfehlermeldung und ändere nicht gleichzeitig Source, Target und Filter.
Prüfe die Source-ENI und ihren EC2-Instanztyp erneut gegen die aktuellen AWS-Voraussetzungen und -Einschränkungen für Traffic Mirroring.
Vergleiche Source/Target-Topologie und Region-/Availability-Zone-Auswahl mit der aktuellen AWS-Dokumentation.
Prüfe die betroffenen Traffic-Mirroring-Kontingente in Service Quotas. Beantrage eine Erhöhung oder ändere das Design über den regulären AWS-Change, statt bestehende Sessions ungeprüft zu löschen.

Registrierung oder NDR-Upload schlägt fehl

Prüfe zuerst den in Outbound-Verbindung vorab prüfen festgelegten Pfad. Insbesondere müssen DNS, Route Table, Internet Gateway beziehungsweise genehmigtes Egress-Design, Network ACL, Security-Group-Egress sowie Proxy und Upstream-Firewall zusammenpassen. Gleiche die Regeln erneut mit den aktuellen Sophos-Port- und Domain-Ausnahmen ab. Ein Fehler beim Upload über eine vorsignierte S3-URL deutet laut Sophos häufig auf blockierten ausgehenden Internetverkehr am Proxy oder an der Firewall hin. Erweitere Egress nicht pauschal; dokumentiere das konkret blockierte Ziel und lasse nur die aktuell von Sophos verlangte Ausnahme freigeben.

Appliance Manager ist über TCP 8443 nicht erreichbar

Prüfe, ob InternalMgmtSG die aktuelle öffentliche Admin-Quelladresse erlaubt.
Prüfe die Elastic-IP-Zuordnung zur Management Interface und das gewählte Public Subnet.
Stelle sicher, dass Open Appliance Manager die erwartete Appliance öffnet.
Wenn eine Regel kurzfristig auf 0.0.0.0/0 erweitert wurde, schliesse sie sofort wieder; eine breite Freigabe ist kein Diagnoseschritt.

Erst wenn der Netzwerkpfad funktioniert, wird ein Passwortproblem untersucht.

`zadmin`-Anmeldung schlägt fehl oder Appliance Manager ist gesperrt

Bei einem unbekannten Passwort verwende in Sophos Fusion Open Appliance Manager > reset it. Zeigt die Appliance ausdrücklich eine Sperrmeldung, dokumentiert Sophos für AWS folgenden Eingriff über SSH:

redis-cli --no-auth-warning -h redis-master.default.svc.cluster.local -p 6379 -a $(jq -r .RedisPassword /etc/dragonfly/sensorapi_config.json) SET userlockout '{"attempt":0,"locked":false}'

Der Befehl wird ausschliesslich in der SSH-Sitzung der betroffenen Sophos-NDR-EC2-Instanz mit dem beim Deployment gewählten Private Key ausgeführt. Dieses Runbook nennt bewusst keinen Betriebssystem-Benutzernamen und keine vollständige SSH-Syntax, weil die geprüfte Sophos-Seite sie nicht dokumentiert. Entnimm die aktuelle Verbindungsidentität den Usage instructions des abonnierten Marketplace-Angebots oder kläre sie mit Sophos Support; rate sie nicht. Vergleiche vor dem Verbindungsaufbau Zieladresse, Instanz-ID und Host-Fingerprint mit dem AWS-Inventar. Der Befehl verändert den Lockout-Zustand, setzt aber kein neues Passwort. Verwende ihn nur bei der ausdrücklich sichtbaren Sperre, nicht als allgemeinen Login-Fix. Prüfe danach die Anmeldung mit dem bestehenden Passwort; funktioniert dieses nicht, setze es anschliessend in Sophos Fusion zurück. Befehl und Ergebnis gehören ohne Passwort oder Private Key ins Change-Protokoll.

Begrenzter Rückweg statt unbestätigtem Teardown

Vor jeder manuellen Security-Group-Änderung wird der Ausgangszustand exportiert oder mit Rule-IDs dokumentiert. Verursacht die neue TCP-8443- oder Syslog-Regel ein Problem, kann genau diese manuell hinzugefügte Regel entfernt und der dokumentierte Ausgangszustand geprüft werden. Das ist ein enger Rückweg für die eigene Inbound-Änderung, kein Rückbau der NDR-Appliance.

Für Stack, Marketplace-Abonnement, Appliance-Objekt, EC2/EBS, ENIs, Elastic IP, Traffic Mirror Session, Target, Filter und Security Groups wird hier absichtlich keine vollständige Löschreihenfolge angegeben. Ebenso wird nicht behauptet, dass das Löschen des CloudFormation-Stacks alle zugehörigen Ressourcen, Kosten, Sophos-Objekte oder Datenfolgen erledigt. Bis diese Abhängigkeiten mit aktueller Herstellerdokumentation und einem Test verifiziert sind, werden Ressourcen nur über einen separat geprüften Retirement-Change entfernt.