Sophos Managed Risk kontrolliert ausser Betrieb nehmen

Beim Offboarding von Sophos Managed Risk sind zwei Bereiche zu trennen: die dokumentierten Kontrollen in Sophos Fusion und die Beendigung des Dienstes, für welche die verfügbaren Unterlagen keinen Ablauf beschreiben. Administratoren können aktuell verfügbare Reports sichern und Managed-Risk-Cases dokumentieren. Das Stoppen externer wie interner Scans erfordert eine Managed Risk service request und eine für die eigene Umgebung bestätigte Reihenfolge; von einer nicht dokumentierten Selbstbedienungsfunktion zur Deaktivierung darf nicht ausgegangen werden.

⚠️ Verbindliche Stoppgrenze: Die folgende Checkliste kündigt weder einen Vertrag noch belegt sie eine Datenlöschung. Appliance oder VM nicht löschen, nicht zurücksetzen und nicht «zur Sicherheit» vom Netzwerk trennen. Auch keine Firewall-Freigaben, DNS-, Proxy-, Hypervisor- oder Service-Einstellungen entfernen, bevor das Managed-Risk-Team die Abhängigkeiten auf Dienst- und Appliance-Seite sowie die Reihenfolge bestätigt hat.

Kontrollierter Kurzablauf

Tenant, Scanner, Scans, Zeitpläne, Ziele, Ausschlüsse, Credentials, Kontakte und offene Managed-Risk-Cases inventarisieren.
Alle benötigten Reports herunterladen, die unter My Products > Managed Risk > Report History aktuell angeboten werden, und relevante Cases dokumentieren, bevor der Zugriff auf das Managed-Risk-Interface endet.
Unter Threat Analysis Center > Cases eine Managed Risk service request eröffnen, das Stoppen oder Deaktivieren aller externen und internen Scans verlangen und die unterstützte Reihenfolge schriftlich bestätigen lassen.
Die Antwort gegen inventarisierte Scan-Umfänge und Zeitfenster prüfen; bei fehlender oder unklarer Bestätigung weder Appliance, VM, Netzwerk noch Scan-Konfiguration ändern.
Erst nachdem der Dienst schriftlich bestätigt hat, dass alle Scans gestoppt sind und kein Scan mehr von dem betreffenden Credential abhängt, jedes freigegebene Credential löschen, das nicht mehr benötigt wird.
Appliance, VM und zugehörige Infrastruktur unverändert lassen, bis Sophos die nächsten Schritte für genau diese Umgebung schriftlich bestätigt.
Case ID, Freigaben, Zeitstempel und Prüfergebnisse im Change festhalten.

1. Ausgangszustand und Freigabe erfassen

Vor der ersten Änderung eine Bestandsaufnahme mit Zeitstempel und Zeitzone erstellen. Sie muss mindestens enthalten:

Sophos-Fusion-Tenant und verantwortliche Personen;
autorisierte primäre, sekundäre und tertiäre Kontakte, soweit vorhanden;
jeden internen Scanner mit Name, Beschreibung, virtueller Plattform, Management-IP und sichtbarem Status;
jeden Discovery- und Vulnerability-Scan mit Scan-Typ, Scanner, Zeitplan, Zeitzone, Zielen und Ausschlüssen;
bei authentifizierten Scans die zugeordneten Credentials;
die gespeicherten externen Domains, IP-Adressen oder CIDR-Bereiche und den wöchentlichen Scanzeitpunkt;
offene Managed-Risk-Cases mit Case ID, Zweck und zuständiger Person;
den genehmigten Zielzustand: nur Scanpause, technische Übergabe oder geplante Beendigung des Dienstes.

Keine Kennwörter, privaten Schlüssel, Hashes oder vollständigen Secrets in Screenshots, Tickets oder Übergabeprotokolle kopieren. Die Inventur dokumentiert Abhängigkeiten und Nachweise; sie ist kein Export der Managed-Risk-Konfiguration und keine Aussage über deren spätere Verfügbarkeit.

Vor dem Weiterarbeiten müssen Service Owner, Security Operations, Netzwerk- und Plattformverantwortliche den Umfang kennen. Bei einer geplanten Vertragsbeendigung gehört auch die dafür zuständige kaufmännische Stelle in die Freigabe. Aus dieser Freigabe folgt jedoch noch keine dokumentierte technische oder vertragliche Wirkung.

2. Aktuell verfügbare Reports sichern

Unter My Products > Managed Risk > Report History die Registerkarten External, Internal und Account einzeln prüfen. Nur die dort aktuell sichtbaren Reports und angebotenen Formate herunterladen:

Vulnerability Reports: CSV, PDF oder HTML;
Attack-Surface-Management-Reports: CSV;
Discovery Reports: CSV.

Pro Datei Reportname, Registerkarte, Downloadzeitpunkt, Format und verantwortliche Person im Change festhalten. Die Dateien gemäss den eigenen Zugriffs- und Aufbewahrungsvorgaben ablegen und die Lesbarkeit stichprobenartig prüfen. Bei HTML-Reports lässt sich zusätzlich kontrollieren, ob aktive und behobene Schwachstellen sowie die Filter nach Risikostufe, Gerätetyp und IP-Adresse sichtbar sind.

Wichtig: Report History ist der dokumentierte Downloadweg, aber keine Vollständigkeitsgarantie. Nicht behaupten, dass alle historischen Scans, Cases oder Rohdaten exportiert wurden. Fehlt ein erwarteter Report oder ein gewünschtes Format, nicht durch einen anderen Central-Report ersetzen. Die Lücke mit Reportname, Scan, erwartetem Zeitraum und Screenshot in die Managed Risk service request aufnehmen.

3. Daten- und Zugriffsgrenzen einplanen

Das aktuelle Privacy Data Sheet dokumentiert für Managed Risk folgende Grenzen:

Die Daten werden in der Sophos-Central-Region verarbeitet, in welcher das Kundenkonto bereitgestellt wurde. Diese Region wird beim Onboarding zu Sophos Fusion (ehemals Sophos Central) gewählt.
Das Hosting erfolgt in AWS-Rechenzentren in der beziehungsweise den Regionen, die der Kunde beim Erstellen des Sophos-Central-Kontos gewählt hat. Weitere Informationen zu von Sophos eingesetzten Unterauftragsverarbeitern enthält die jeweils aktuelle Sophos-Liste; daraus keine abweichende Region oder vertragliche Zusage ableiten.
Reporting- und Case-Daten werden zwei Jahre aufbewahrt.
Nach der Beendigung des Managed-Risk-Dienstes wird der Zugriff auf das Managed-Risk-Interface in Sophos Fusion nach einer 30-tägigen Übergangsfrist deaktiviert.

Die zweijährige Aufbewahrung bedeutet nicht, dass Administratoren zwei Jahre lang auf das Interface zugreifen können. Deshalb alle aktuell benötigten und sichtbaren Reports herunterladen und relevante offene oder abgeschlossene Cases vor dem Ende des Interface-Zugriffs im eigenen Change- oder Ticketsystem festhalten. Dazu gehören mindestens Case ID, Zweck, aktueller Stand, vereinbarte nächste Schritte, verantwortliche Person und Zeitstempel; Secrets bleiben ausgeschlossen. Ein solches Protokoll ist kein vollständiger Case-Export und keine Zusage, dass sämtliche Inhalte lokal vorliegen.

Diese Angaben beschreiben Verarbeitung, Hosting, Aufbewahrung und den Interface-Zugriff. Sie erklären weder, wie eine Kündigung auszulösen ist, noch wann Daten im Einzelfall endgültig gelöscht werden. Ebenso belegen sie keine Wirkung der Dienstbeendigung auf Scans, Appliance, VM oder Netzwerk. Für diese Punkte bleibt die bestätigte umgebungsspezifische Reihenfolge erforderlich.

4. Vor Infrastrukturänderungen einen Service-Case eröffnen

Die verfügbaren Unterlagen belegen keine Selbstbedienungsfunktion zum Stoppen von Scans. Über den Managed-Risk-Service-Case muss das Stoppen oder Deaktivieren aller externen und internen Scans angefordert werden. Dieser Schritt erfolgt vor dem Löschen von Credentials, dem Entfernen von Firewall-Freigaben oder Änderungen an Appliance, VM, Netzwerk oder Scan-Konfiguration.

Threat Analysis Center > Cases öffnen.
Create case wählen.
Als Typ Managed Risk service request auswählen.
Einen eindeutigen Namen und eine Beschreibung erfassen.
Create wählen und die erzeugte Case ID im Change notieren.

Die Beschreibung sollte den Tenant, den gewünschten Zielzustand und Termin, externe und interne Scan-Umfänge, Scannernamen, offene Reports sowie die bereits genehmigten Änderungen nennen. Ausserdem konkret bestätigen lassen:

ab wann keine externen und internen Scans mehr ausgelöst werden;
ob aufseiten des Dienstes weitere Scan- oder Scannerabhängigkeiten bestehen;
in welcher Reihenfolge Credentials, Appliance, VM, Firewall-Freigaben und übrige Infrastruktur behandelt werden dürfen;
welche Abnahme Sophos nach den einzelnen Phasen erwartet;
wer Fragen zum Kündigungsweg, zu Vertragswirkungen, zur konkreten Datenlöschung und zu abweichenden vertraglichen Datenschutzanforderungen verbindlich beantwortet.

In den Case gehören keine Passwörter, privaten Schlüssel oder sonstigen Secrets. Solange die unterstützte Reihenfolge fehlt, bleibt die Infrastruktur in Betrieb und unverändert.

5. Scan-Stopp bestätigen lassen und sicher prüfen

Über die Managed Risk service request für jeden inventarisierten externen und internen Scan, einschliesslich Discovery- und Vulnerability-Umfang, das Stoppen oder Deaktivieren anfordern. Jeden Scan mit Name, Typ, Scanner, Zielen, Zeitplan und Zeitzone bezeichnen; der Scannername allein genügt nicht.

Eine schriftliche Bestätigung zu abgedeckten Scans, Wirksamkeitszeitpunkt, allfälligem letztem oder laufendem Durchlauf, verbleibenden dienstseitigen Abhängigkeiten und der von Sophos erwarteten Prüfung verlangen. Die Antwort mit der Inventur vergleichen und fehlende, unklare oder abweichende Scans im selben Case festhalten.

Nach jedem ursprünglich geplanten Zeitfenster verfügbare Status- und Reportangaben auf unerwartete Aktivität prüfen und die Nachweise dem Case hinzufügen. Ein fehlender Report allein beweist keinen Stopp. Fehlt die Bestätigung, ist der Umfang unvollständig oder widersprechen sich Status, Reports und Laufzeitverhalten, gilt Stopp: VM nicht herunterfahren, Datenverkehr nicht blockieren, Ziele nicht improvisiert ändern, keine Credentials löschen und keine Infrastruktur ändern oder entfernen. Alles bleibt betriebsbereit und unverändert, bis das Managed-Risk-Team die Abweichung schriftlich geklärt hat.

6. Credentials für authentifizierte Scans bereinigen

Das Löschen eines Managed-Risk-Credentials ist dauerhaft und entfernt es aus allen Scan-Konfigurationen, in denen es verwendet wurde. Deshalb darf ein Credential nicht allein wegen seines Namens gelöscht werden.

Vor jeder Löschung:

Credential-Name und -Typ eindeutig identifizieren.
Alle Discovery- und Vulnerability-Scans prüfen, die dieses Credential verwenden.
Schriftlich vom Dienst bestätigen lassen, dass die Scans gestoppt sind und kein externer oder interner Scan das Credential noch benötigt.
Die für das Credential und die Zielsysteme zuständigen Personen einbeziehen.
Freigabe, betroffene Scans und erwartete Wirkung im Change erfassen.

Danach unter Managed Risk > Settings > Credentials das Credential suchen, in der Spalte Actions das Drei-Punkte-Menü öffnen, Delete wählen und im Bestätigungsdialog mit Confirm dauerhaft löschen. Anschliessend die Credentials-Liste aktualisieren und prüfen, dass genau der freigegebene Eintrag nicht mehr erscheint. Die betroffenen Scan-Konfigurationen nochmals kontrollieren, weil die Löschung das Credential aus jeder zugeordneten Konfiguration entfernt.

Diese Aktion löscht den in Fusion gespeicherten Eintrag für authentifizierte Scans. Daraus folgt weder, dass ein zugrunde liegendes Konto auf Windows, Linux, macOS, SNMP oder VMware deaktiviert wurde, noch dass andere Kopien eines Secrets entfernt sind. Solche Konten werden ausschliesslich nach dem freigegebenen Prozess des jeweiligen Zielsystems behandelt.

Die beim Erstellen einer Scanning Appliance einmalig angezeigten administrativen Appliance-Credentials sind davon getrennt. Für sie ist in den verfügbaren Managed-Risk-Unterlagen kein Widerrufs- oder Löschverfahren dokumentiert. Ihre Behandlung deshalb im Service-Case bestätigen lassen und nicht aus der Löschung eines Scan-Credentials ableiten.

7. Infrastruktur unverändert übergeben

Nach Report-Sicherung, schriftlicher Bestätigung des Scan-Stopps und der genehmigten Credential-Bereinigung endet der selbst ausführbare Teil dieser Checkliste. Bis eine umgebungsspezifische Antwort im Managed-Risk-Case vorliegt:

Scanner-Appliance und VM nicht löschen, herunterfahren, zurücksetzen oder neu bereitstellen;
virtuelle Datenträger, Images und Hypervisor-Objekte nicht entfernen;
Management-IP, DHCP-Reservation, DNS, Proxy und Routing nicht verändern;
Firewall-Freigaben und ausgehende Verbindungen nicht entfernen;
keine Shell-Befehle, Service-Neustarts oder manuelle Datei- und Datenbereinigung ausführen;
die einmaligen Appliance-Credentials nicht als durch eine andere Löschaktion widerrufen behandeln.

Die Dienstbestätigung des Scan-Stopps und das Löschen eines Scan-Credentials belegen nicht, dass ein Abonnement gekündigt oder gespeicherte Daten gelöscht wurden.

8. Abschluss und klare Stoppgrenzen

Der kontrollierte Übergabestand ist erreicht, wenn:

Bestand und freigegebener Zielzustand dokumentiert sind;
alle aktuell benötigten und verfügbaren Reports lesbar gesichert wurden;
relevante Cases vor dem Ende des Interface-Zugriffs mit Case ID, Stand und nächsten Schritten im eigenen System dokumentiert wurden;
der Stopp aller externen und internen Scans unter einer Case ID schriftlich bestätigt und nach ihren nächsten vorgesehenen Zeitfenstern kontrolliert wurde;
Scan-Abweichungen und die weitere Reihenfolge im Case geklärt oder ausdrücklich offen dokumentiert sind und keine weiteren Änderungen erfolgten;
nur freigegebene Credentials für authentifizierte Scans gelöscht und ihre Scan-Abhängigkeiten nachgeprüft wurden;
Appliance, VM und Netzwerkinfrastruktur bis zur Sophos-Bestätigung unverändert geblieben sind;
Abnahmen, Abweichungen, Screenshots und Zeitstempel im Change hinterlegt sind.

Hier stoppen: Das Privacy Data Sheet belegt die regionale Verarbeitung und das AWS-Hosting, verweist auf die Sophos-Liste der Unterauftragsverarbeiter, nennt zwei Jahre Aufbewahrung für Reporting- und Case-Daten und eine 30-tägige Übergangsfrist bis zur Deaktivierung des Interface-Zugriffs. Es beschreibt jedoch weder einen Kündigungsablauf oder Vertragsfolgen noch die konkrete Löschung oder sichere Vernichtung und auch nicht, wie Appliance oder VM zu entfernen sind. Aus den dokumentierten Fristen keine Wirkung auf Scans oder Infrastruktur ableiten. Die zuständige Managed-Risk-, Vertrags- oder Datenschutzstelle muss offene Punkte für den konkreten Tenant schriftlich beantworten, bevor weitere Änderungen erfolgen.