Sophos Server Protection auf AWS EC2 und Azure VMs ausrollen

Eine EC2-Instanz oder Azure VM wird im Gastbetriebssystem mit Sophos Server Protection geschützt. Für Windows Server verwendet man den Windows Server Installer, für unterstützte Linux-Server Sophos Protection for Linux (SPL). Der Ort der VM ändert nicht die Wahl des Server-Agenten. Sophos Firewall als virtuelle Appliance in AWS oder Azure schützt und routet Netzwerkverkehr; sie ersetzt keinen Agenten im Gast. Sophos Cloud Optix ist ein separates Cloud-Posture-/Inventarprodukt, keine Voraussetzung für die Server-Installation: Laut Sophos-Lifecycle-Mitteilung enden Support und Zugang am 30. September 2026. Es ist daher keine Grundlage für einen neuen oder dauerhaften Cloud-Inventar- und Bereinigungsprozess. Ob Server Protection und seine Funktionen im eigenen Tenant verfügbar und vertraglich abgedeckt sind, muss separat geprüft werden.

Schnellweg: Eine repräsentative VM wählen, Betriebssystem und Schutzmodus freigeben, die Verbindung zu Sophos Fusion aus ihrem tatsächlichen Cloud-Netz testen, den tenantgebundenen Server-Installer installieren und danach My Products > Server > Servers sowie die Serverdetails prüfen. Erst wenn Registrierung, Gruppe, Richtlinien, Agent Health und Anwendung funktionieren, wird die nächste Welle freigegeben. Für kurzlebige Instanzen muss zusätzlich ein eigener Abgleich mit dem Cloud-Inventar geplant werden.

Vor dem Pilot: Schutz und Netzweg klären

1. VM und Vertrag: AWS-Konto beziehungsweise Azure-Subscription, Region, VM-Rolle, Betriebssystem-Build oder Linux-Distribution, Architektur und Lifecycle erfassen. Die aktuelle Unterstützung für genau dieses Gastbetriebssystem und die benötigten Komponenten prüfen. Die Lizenz des konkreten Tenants und den bestellten Server-SKU samt Vertragsbedingungen für diese VMs bestätigen; eine sichtbare Download-Schaltfläche ist kein Entitlement-Nachweis.
2. Schutzmodus: Vollständigen Sophos Malware-Schutz oder XDR Sensor festlegen. Der reine XDR Sensor bietet keinen Malware-Schutz und braucht einen aktiven Drittanbieter-Schutz. Vor der Umstellung Konflikte mit bestehender Security-Software und einen Rückweg für die betroffene VM klären.
3. Ausgehende Verbindung: Aus dem vorgesehenen Subnetz prüfen, ob DNS, HTTPS, die für den Tenant erforderlichen Sophos-Ziele und gegebenenfalls Proxy oder Message Relay während Installation und Betrieb erreichbar sind. Security Groups, Network Security Groups, Cloud-Routen, NAT, Firewalls und TLS-Inspection können den Pfad beeinflussen. Die aktuelle Allowlist und Proxy-Diagnose stehen unter Netzwerk- und Proxy-Anforderungen. Keine feste Liste von Cloud-IP-Adressen als Ersatz für die Sophos-Ziele annehmen.
4. Pilot und Abnahme: Eine kleine VM-Gruppe mit repräsentativer Serverrolle, OS-Version, Netzwerksegment und gegebenenfalls Proxyweg wählen. Namen, erwartete Servergruppe, Zielrichtlinien, Neustartfenster, Workload-Test und Stop-Kriterien festhalten. Bei mehreren Subnetzen oder Images mindestens einen passenden Test pro abweichendem Pfad einplanen.

Beispiel: Eine Windows-Anwendungs-VM und eine Linux-Worker-VM in getrennten privaten Subnetzen sind zwei Pilotfälle, nicht ein gemeinsamer Netzwerktest. Ein erfolgreicher Installer auf der ersten VM beweist nicht, dass die zweite ihr Update-Ziel über ihren NAT- oder Proxyweg erreicht.

Installer im Gast ausführen und Images richtig behandeln

Unter My Environment > Installers > Server Protection den zum freigegebenen Schutzmodus passenden Windows Server Installer beziehungsweise Linux Server Installer aus dem richtigen Sophos-Fusion-Tenant auswählen. Auf einer einzelnen Windows-VM SophosSetup.exe geschützt übertragen, mit lokalen Administratorrechten starten, angezeigte Vorprüfungen beachten und Installation samt angefordertem Neustart abschliessen. Auf einer Linux-VM SophosSetup.sh geschützt übertragen, ausführbar machen und zuerst sudo ./SophosSetup.sh --test, nach erfolgreichem Test sudo ./SophosSetup.sh ausführen. Danach die Registrierung im Tenant und die lokale Agent Health prüfen; ein beendeter Installer allein genügt nicht. Schutzmodus, erweiterte CLI, Logs und Fehlerbehebung stehen in Windows Server Protection installieren und ausrollen und SPL installieren und ausrollen. Den tenantgebundenen Installer und seine Downloadadresse nur in einer geschützten Paketablage verwenden, nicht in einem öffentlichen VM-Image oder Repository ablegen.

Nicht die bereits registrierte Master-VM unverändert vervielfältigen. Bei SPL im Linux-Gold-Image muss die Master-VM nach der Installation mit registerCentral --deregister gemäss dem Linux-Gold-Image-Verfahren deregistriert, sofort heruntergefahren und im ausgeschalteten Zustand als Image gespeichert werden. Nachträgliches Starten der Master-VM kann sie erneut registrieren; in diesem Fall vor dem Speichern nochmals deregistrieren. Zwei Klone starten und getrennte Identitäten prüfen.

Windows Server hat einen anderen Image-Prozess: Vor dem Backen prüfen, ob Tamper Protection für die Image-Konfiguration deaktiviert ist und ob Server Lockdown oder Update Cache aktiv sind; von solchen Servern kein Gold Image erstellen. BitLocker-verschlüsselte Master oder solche mit Sophos-Encryption-Komponenten sind ebenfalls ausgeschlossen. Mit dem tenantgebundenen Windows Server Installer als Administrator SophosSetup.exe --goldimage nach dem Windows-Gold-Image-Verfahren (auch für Server) ausführen, Installation und Health kontrollieren, Tamper Protection wieder aktivieren und den Master vor dem Image-Snapshot herunterfahren. Beim ersten Start muss jeder Klon rechtzeitig vor der Sophos-Erkennung einen vom Master verschiedenen, endgültigen Computernamen erhalten: Sophos erkennt Klone anhand der Namensänderung, nicht anhand der Cloud-Instanz-ID. Bei verzögerter Namensvergabe den im Guide beschriebenen Timeout-Modus prüfen; der Notification Mode ist dort für VMware Horizon Instant Clone beschrieben und nicht pauschal für EC2/Azure anzuwenden. Keine gewöhnliche Windows-Installation als bereits klonfertig behandeln. Auch hier zwei Klone getrennt in Fusion abnehmen.

Cloud-Welle prüfen und bei Fehlern anhalten

Nach Installation oder Start eines Pilot-Klons unter My Products > Server > Servers die erwarteten Server einzeln öffnen. Für zwei gleichzeitig laufende Klone müssen zwei unterscheidbare Serverobjekte sichtbar sein. Bei der Abnahme eine externe Zuordnung von AWS-Konto/Azure-Subscription, Region, EC2-Instanz-ID/Azure-VM-Ressourcen-ID, Fusion-Server-ID, Owner und Erstellungszeitpunkt erfassen; die Serverliste zeigt Cloud-IDs nicht automatisch an. In den Details Summary, Status und Policies sowie letzte Aktivität, Health, installierte Komponenten und wirksame Server-Richtlinien prüfen. Die erste automatische Default Policy ist nicht zwingend die geplante Produktionsrichtlinie. Anschliessend Dienst, Anwendungszugriff, Backup und einen repräsentativen Workload-Test vor und nach einem nötigen Neustart vergleichen.

Fehlt eine VM in Fusion, zuerst Tenant und Filter, danach DNS, Proxy, ausgehenden Netzwerkpfad und Installationslogs gemäss dem passenden Windows- oder Linux-Runbook prüfen. Sind Klone nicht unterscheidbar, den Image-Rollout stoppen und den Identitätsschritt des Gold-Image-Verfahrens kontrollieren. Bei falschen Komponenten, schlechter Health oder gestörtem Workload keine weitere Welle freigeben; die betroffene Welle isoliert untersuchen, statt Installer und Richtlinien wiederholt blind anzuwenden.

Terminierte Instanzen und inaktive Geräte getrennt behandeln

Kurzlebige VMs können beendet sein, während ihr Eintrag in Sophos Fusion noch sichtbar ist. Ein alter Last Active-Zeitpunkt ist weder ein Beweis für eine terminierte Cloud-Instanz noch eine universelle automatische Bereinigungsfrist. Die externe Zuordnung von Konto/Subscription, Region, Cloud-Instanz-/Ressourcen-ID und Fusion-Server-ID regelmässig mit dem AWS-/Azure-Bestand und dem Fusion-Geräteinventar abgleichen; Owner, Lifecycle-Zeitpunkte und den Nachweis des EC2-Terminate- beziehungsweise Azure-VM-Delete-Ereignisses festhalten. Ein wiederverwendeter Hostname oder eine gestoppte Azure VM ist kein Nachweis, dass das zugeordnete Serverobjekt ausgemustert ist.

Manueller Abgleich und gezieltes Delete bleiben die Basis: Erst nach positivem Cloud-Terminierungsnachweis und eindeutiger ID-Zuordnung benötigte Alerts und Untersuchungsdaten sichern, mögliche Duplikate prüfen und den Rückbau beziehungsweise Ersatzschutz dokumentieren. Delete in Fusion ersetzt weder die Deinstallation auf einer noch laufenden VM noch den Cloud-Lifecycle-Prozess.

Separat dokumentiert Sophos unter Removal of inactive devices eine konfigurierbare Server-Regel für inaktive Geräte: zielgerichtet nach Gruppen oder global mit Gruppenausnahmen (Ausnahmen gelten nicht für zielgerichtete Regeln). Sie reagiert auf Inaktivität, nicht auf einen bestätigten EC2-Terminate- oder Azure-Delete-Event und deinstalliert keinen Agenten. Vor einer Aktivierung im eigenen Tenant Gruppen, Frist, Ausnahmen, Datenaufbewahrung und Folgen für angehaltene oder vorübergehend nicht erreichbare produktive VMs an einem Testbestand prüfen; keine pauschale Frist oder Lizenzwirkung annehmen. Die frühere Cloud-Optix-Integration bot für bestehende, im selben Tenant verknüpfte AWS-/Azure-Umgebungen mit Server-Agenten eine separate, standardmässig deaktivierte, nur durch Super Admin aktivierbare Termination-Bereinigung, nicht rückwirkend für zuvor beendete Instanzen. Wegen des Endes von Support und Zugang am 30. September 2026 ist dies nur historischer Kontext, keine Empfehlung für neue Einrichtung oder dauerhafte Automation. Für Autoscaling-Löschhooks, API-Automation oder Lizenzzählung wird kein unbestätigter Ablauf versprochen.