Sophos Firewall mit Sophos Fusion verbinden

Eine Sophos Firewall muss nicht zwingend mit Sophos Fusion (ehemals Sophos Central) verbunden werden. Eine einzelne Firewall kann vollständig lokal über die WebAdmin-Konsole verwaltet werden. Trotzdem lohnt sich die Verbindung mit Sophos Fusion in vielen Umgebungen, weil dadurch zusätzliche Management-, Backup-, Reporting- und Sicherheitsfunktionen verfügbar werden.

Dieser Artikel hilft bei der Entscheidung, wann Sophos Fusion sinnvoll ist und wann eine lokale Verwaltung ausreicht.

Die Plattform heisst heute Sophos Fusion, früher Sophos Central. Menüs, Schaltflächen und der Registrierungs-Alert auf der Firewall können weiterhin Sophos Central verwenden; beim beschriebenen Ablauf orientiert man sich an diesen sichtbaren UI-Bezeichnungen. Eine zentral verwaltete Firewall kann auch als ZTNA-Gateway für den Zugriff auf interne Ressourcen integriert werden. Die Registrierung allein konfiguriert dieses Gateway nicht und gewährt keinen Zugriff auf diese Ressourcen. ZTNA-Bereitstellung und Zugriffsrichtlinien müssen separat geplant werden.

Kurzantwort

Wenn man nur eine einzelne Sophos Firewall lokal betreibt und keine Central-Funktionen nutzen möchte, ist Sophos Fusion nicht zwingend nötig.

Wenn man mehrere Firewalls verwaltet, Logdaten zentral auswerten möchte, Konfigurationsbackups in der Cloud speichern will oder weitere Sophos-Produkte wie Sophos Endpoint einsetzt, bringt Sophos Fusion deutliche Vorteile.

Die Entscheidung sollte aber nicht nur lauten: verbinden oder nicht verbinden. Wichtiger ist, welche Central-Funktionen wirklich aktiviert werden sollen. Eine Firewall kann in Sophos Fusion registriert sein, ohne dass jede Management-, Reporting- oder Backup-Funktion produktiv genutzt wird.

Zero Touch: Bereitstellung mit einer Konfigurationsdatei

Sophos Fusion bietet neben der Verwaltung vorhandener Firewalls auch Zero Touch: Neue Firewalls können mit einer Zero-Touch-Konfigurationsdatei installiert werden. Dafür wird ein Sophos-Fusion-Konto benötigt; die Oberfläche kann weiterhin Sophos Central heissen. Diese Möglichkeit ist für die Planung neuer Standortinstallationen relevant, wenn die Bereitstellung über Central vorbereitet werden soll. Sie ist nicht dasselbe wie der spätere Fernzugriff auf WebAdmin oder das Verteilen einer Gruppenrichtlinie.

Vor der Wahl des Bereitstellungswegs klären Sie den vorgesehenen Tenant, die zuständigen Administratoren und deren Berechtigungen, Gerät und Seriennummer, Lizenzbedarf sowie die Internetanbindung. Für die anschliessende Central-Verwaltung bleibt eine funktionierende IPv4-Verbindung erforderlich; die in diesem Artikel beschriebenen Lizenzanforderungen gelten weiterhin. Zero Touch ist keine Voraussetzung für den lokalen Betrieb und keine Reparaturmethode für eine bereits produktive Firewall.

Unterscheiden Sie die Aufgaben bewusst:

• Neue Installation mit Zero Touch: Die Konfigurationsdatei dient der Bereitstellung einer neuen Firewall. Dieser Überblick beschreibt die Fähigkeit, aber keine vollständige Anleitung zum Erstellen oder Anwenden der Datei. Planen Sie diesen Weg vor der Installation; leiten Sie aus den folgenden OTP-Schritten keine Zero-Touch-Prozedur ab.
• Lokale Einrichtung, Claim und Lizenzen: Sophos Firewall einrichten, claimen und Lizenzen aktivieren beschreibt die lokale Grundeinrichtung, die Zuordnung zum Tenant durch den Claim und die getrennte Aktivierung beziehungsweise Synchronisierung von Lizenzen. Diese Aufgaben dürfen nicht mit der Management-Registrierung gleichgesetzt werden.
• Vorhandene Firewall verbinden: Der weiter unten beschriebene OTP-Weg setzt eine eingerichtete und im richtigen Tenant geclaimte Firewall voraus. OTP registriert sie für Central Management, ersetzt aber weder den Claim noch die Aktivierung von Abonnements. Eine Partner-Kundenzuordnung ersetzt den Claim ebenfalls nicht.
• Mehrere Firewalls gemeinsam verwalten: Sophos Fusion Firewall Groups sicher nutzen erklärt gemeinsame Richtlinien und die Auswirkungen von Full Sync. Gruppenverwaltung ist eine eigene Betriebsaufgabe, nicht der Zero-Touch-Installationsweg.

Vorteile der Verbindung mit Sophos Fusion

Zentrale Übersicht

In Sophos Fusion sieht man registrierte Firewalls zentral an einem Ort. Das ist besonders hilfreich, wenn mehrere Standorte oder Appliances derselben Organisation verwaltet werden.

Typische Vorteile:

• Statusübersicht der Firewalls
• Seriennummern und Lizenzinformationen
• Firmware- und Sicherheitsstatus
• zentrale Reports
• schneller Wechsel zwischen mehreren Firewalls

Management über Sophos Fusion

Mit Manage from Sophos Central kann man über Sophos Fusion auf die Firewall-Verwaltung zugreifen. Das ist oft sicherer, als die WebAdmin Console direkt aus dem Internet zu veröffentlichen.

Der Management-Zugriff ersetzt aber keine saubere Admin-Strategie. Admin-Konten, MFA, Rollen, Device Access und ACL-Regeln müssen weiterhin bewusst konfiguriert werden. Ausserdem braucht Central Firewall Management laut Sophos eine aktive bezahlte Subscription ausser Base Firewall oder eine dafür berechtigende aktive Sophos-Supportlizenz, zum Beispiel Enhanced Support. Die Base-Firewall-Lizenz allein reicht nicht; ein beliebiger Supportvertrag ist nicht automatisch eine solche Berechtigung.

Ein technischer Punkt wird gerne übersehen: Sophos Fusion kann Firewalls nur verwalten, wenn die Firewall über IPv4 ins Internet kommt. In IPv6-only- oder sehr streng getrennten Umgebungen muss dieser Pfad vor der Aktivierung geprüft werden.

Wenn Änderungen über Central nicht wie erwartet auf der Firewall ankommen, sollte man zusätzlich die Sophos Fusion Firewall Management Task Queue prüfen. Dort sieht man, ob Gruppenrichtlinien oder API-basierte Firewall-Tasks noch ausstehen, fehlgeschlagen sind oder übersprungen wurden.

Wie mehrere Firewalls eine gemeinsame Policy erhalten und was Full Sync beziehungsweise Skip full sync wirklich bewirken, erklärt Sophos Fusion Firewall Groups sicher verwenden.

Für mehrere Standorte kann Central ausserdem route-based VPN-Verbindungen, XFRM-Interfaces, Routen und Regeln orchestrieren. Planung, Konfliktauflösung und lokale Abnahme erklärt Sophos Fusion SD-WAN Connection Group einrichten und prüfen.

Grenzen von Central Firewall Management

Central Firewall Management ist ein zusätzlicher Verwaltungsweg, aber kein vollständiger Ersatz für lokale Firewall-Bedienung, lokale Logs und einen getesteten Notfallzugriff. Gerade bei mehreren Admins, Firewall-Gruppen und HA-Clustern sollte man die wichtigsten Grenzen kennen, damit normale Plattformeffekte nicht fälschlich als Konfigurationsfehler eingeordnet werden.

Typische Beobachtungen aus dem Betrieb:

• Zwei Admins öffnen dieselbe Firewall über Sophos Fusion: Es kann nur eine Central-Manager-Sitzung pro Firewall aktiv sein. Wenn ein zweiter Admin übernimmt, kann der erste eine Lade- oder Verbindungsfehlermeldung sehen.
• Read-only- oder Helpdesk-Rolle sieht gruppierte Firewalls nicht: Bei Firewalls in Central-Gruppen können Leserechte anders wirken als erwartet. Für Betriebsrollen sollte man den Zugriff mit einem Testkonto prüfen.
• HA-Paare erscheinen in Central unerwartet doppelt oder auf mehreren Seiten: Das kann ein Darstellungs- oder Pagination-Thema sein. Für Entscheidungen zählt zusätzlich der lokale HA-Status auf der Firewall.
• Firewall-Regeln lassen sich auf Gruppenebene nicht wie lokal verschieben: Nicht jede lokale WebAdmin-Aktion ist in Central-Gruppen gleich abgebildet. Regelreihenfolge und Wirkung müssen nach Gruppenänderungen lokal validiert werden.
• Importierte Gruppen oder WAF-Regeln verhalten sich in Central unerwartet: Nach Config-Import, Full Sync oder WAF-Regelimport sollte man nicht nur die Central-Ansicht prüfen, sondern auch die Ziel-Firewall und die Task Queue.

Für produktive Umgebungen ist deshalb wichtig: Sophos Fusion ist der Koordinationspunkt, die Firewall bleibt aber die Stelle, an der man kritische Wirkung validiert. Nach Gruppenänderungen, Firmware-Tasks, WAF-Anpassungen oder HA-Arbeiten sollte man zusätzlich lokal prüfen, ob Regeln, Dienste, HA-Status, Logs und betroffene Verbindungen wirklich passen.

Konfigurationsbackups in Sophos Fusion

Die Firewall kann Konfigurationsbackups an Sophos Fusion senden. Das ist nützlich, wenn eine Appliance ersetzt oder wiederhergestellt werden muss und lokale Backups nicht verfügbar sind.

In Sophos Fusion kann man geplante Backups für registrierte Firewalls einrichten. Als Intervall stehen Daily, Weekly und Monthly zur Verfügung. Damit lässt sich zum Beispiel definieren, dass ausgewählte Firewalls täglich, wöchentlich oder monatlich ein Konfigurationsbackup nach Sophos Fusion senden.

Die aktuelle Sophos-Backup-Dokumentation nennt Global Settings > Products and Services > Firewall > Schedule Backup als Zugang zur Planung. Falls der im Screenshot gezeigte Pfad Firewall Management > Backup in deiner Oberfläche fehlt, verwende diesen Zugang.

Sophos Fusion bewahrt nicht unbegrenzt alle automatischen Backups auf. Standardmässig bleiben die fünf neuesten Backups erhalten; ältere werden verworfen. Ein Backup kann zusätzlich dauerhaft markiert werden. Bei HA-Clustern werden Primary und Auxiliary im Backup-Zeitplan angezeigt, erzeugt wird laut Sophos aber nur das Backup vom Primary-Gerät.

Für den Betrieb sind zwei Details wichtig: Sophos Fusion versucht ein Backup bis zu fünfmal und erzeugt bei dauerhaftem Fehlschlag einen Alert sowie eine E-Mail an den Central-Admin. Wird eine Firewall aus Sophos Fusion Management entfernt, löscht Sophos Fusion die zugehörigen Backup-Dateien. Cloud-Backups sind deshalb hilfreich, aber kein Ersatz für eine eigene Backup- und Restore-Strategie.

Trotzdem sollte man nicht nur auf eine einzige Backup-Methode setzen. Für produktive Systeme sind regelmässige lokale oder externe Backups weiterhin sinnvoll. Wichtig sind auch Backup-Passwort und Secure Storage Master Key.

Central Firewall Reporting

Mit Central Firewall Reporting sendet die Firewall Log- und Reportdaten an Sophos Fusion. Dadurch können Reports über längere Zeiträume ausgewertet und zentral gesucht werden.

In Sophos Fusion stehen dafür Dashboards, der Report Hub, der Report Generator, gespeicherte Templates und geplante Exporte zur Verfügung. Man kann Reports für einzelne Firewalls oder mehrere Firewalls erstellen, Zeiträume filtern, nach bestimmten Ereignissen suchen und Ergebnisse als PDF, CSV oder HTML exportieren. Für regelmässige Auswertungen können Reports zusätzlich geplant und automatisch bereitgestellt werden.

Gespeicherte Vorlagen, geplante Exporte und Downloads erfordern laut Sophos eine Central Firewall Reporting Advanced-Lizenz. Für Berichte über mehrere Firewalls müssen alle ausgewählten Firewalls entsprechend lizenziert sein.

Typische Report-Templates sind:

• Antivirus
• Bandwidth usage
• Cloud app risks and usage
• Firewall
• IPS
• Log viewer and search
• SD-WAN
• SD-WAN SLA trend
• SD-WAN bandwidth usage
• Security posture assessment
• Synchronize app
• Threat geo activity
• Threats and events blocked
• VPN usage
• Web usage
• Web user risks
• X-Ops
• Zero-day protection

Die Aufbewahrungsdauer hängt von der Lizenz ab. Typische Werte:

• Aktive Firewall Subscription: Bis zu 7 Tage für grundlegende Reports und kurze Rückblicke.
• Xstream Protection / Central Orchestration: Bis zu 30 Tage, abhängig von Bundle und Berechtigung.
• Central Firewall Reporting Advanced: Bis zu 365 Tage und 100 GB zusätzlicher Speicher pro Lizenz.

Die genaue Aktivierung und die Log-Auswahl sind im ausführlichen Artikel Central Firewall Reporting aktivieren beschrieben.

Synchronized Security und Security Heartbeat

Wenn Sophos Endpoint und Sophos Firewall gemeinsam über Sophos Fusion betrieben werden, kann Synchronized Security genutzt werden. Dabei tauschen Firewall und Endpoint Sicherheitsinformationen aus.

Beispiele:

• Die Firewall sieht den Security Heartbeat von Endpoints.
• Geräte mit rotem Heartbeat können automatisch eingeschränkt werden.
• Netzwerk- und Endpoint-Sicht werden besser miteinander verbunden.
• Bei Incidents ist schneller sichtbar, welcher Benutzer oder welches Gerät betroffen ist.

Das ist einer der grössten Mehrwerte, wenn neben der Firewall auch Sophos Endpoint, MDR oder XDR eingesetzt wird.

Security Heartbeat kann zusätzlich die Windows-Domänenidentität eines verwalteten Endpoints an die Firewall übermitteln. Der sichere Pilot-, Regel- und HA-Ablauf steht unter Synchronized User ID Authentication einrichten.

Security Heartbeat nach der Registrierung abnehmen

Eine sichtbare Firewall in Sophos Fusion bestätigt noch nicht, dass Security Heartbeat für die Endpoints funktioniert. Dafür braucht es ein Sophos-Central-Konto, mindestens einen von Sophos Fusion verwalteten Endpoint mit Trial oder Vollizenz und eine gültige Network Protection-Subscription auf der Firewall. Bei der Registrierung aktiviert SFOS Security Heartbeat und Synchronized Application Control automatisch.

Für eine kontrollierte Erstabnahme eignet sich ein einzelner verwalteter Pilotendpoint:

1. Unter System > Sophos Central prüfen, ob die Firewall registriert und Security Heartbeat aktiv ist.

2. In Sophos Fusion unter My Products > Firewall Management > Firewalls den Alert A new firewall has been successfully registered to Sophos Central bestätigen. Dieser Alert belegt die Registrierung, aber noch keine Regelwirkung.

3. Beim Pilotendpoint in Sophos Fusion den Tenant, den aktuellen Gesundheitsstatus und zeitgleiche Events prüfen.

4. Unter Control Center > User & device insights > Security Heartbeat prüfen, ob der Zähler Connected den erwarteten Pilotstatus plausibel berücksichtigt. Bei einem rein grünen Bestand bleibt die Detailansicht laut Sophos leer; sie listet nur rote und gelbe Endpoints einzeln auf.

5. Die tatsächlich getroffene Firewall-Regel prüfen. Ohne konfigurierte Heartbeat-Bedingung bleibt der Status nur sichtbar; eine Zugriffswirkung entsteht erst durch die Einstellungen unter Configure Synchronized Security Heartbeat. Dabei die Mindestanforderungen für Source heartbeat und Destination heartbeat getrennt prüfen. Auch Block clients with no heartbeat garantiert nicht, dass jeder Webzugriff blockiert wird: Sophos dokumentiert, dass Webanfragen bei einer Ausnahme für Policy-Prüfungen unter Web > Exceptions nicht blockiert werden. Deshalb die zutreffenden Ausnahmen und das tatsächliche Zugriffsergebnis mitprüfen.

6. Erst nach dieser Baseline eine Heartbeat-Bedingung in einer eng begrenzten Pilotregel aktivieren, Logging einschalten und erlaubten Traffic mit einem gesunden Endpoint testen.

Widerspruch in der Sophos-Dokumentation: Die Security-Heartbeat-Übersicht für SFOS 22 und 23 sagt im VPN-Abschnitt pauschal, dass bei Missing sämtlicher Traffic dieses Endpoints durch die Firewall blockiert wird. Die detaillierte Heartbeat-Beschreibung macht die Zugriffswirkung dagegen von den Regeln abhängig und nennt ausdrücklich die Ausnahme für Policy-Prüfungen unter Web > Exceptions: Webanfragen werden trotz Block clients with no heartbeat nicht blockiert. Diese Aussagen sind nicht als allgemeine Isolationsgarantie miteinander vereinbar. Für eine sichere Abnahme prüft man deshalb die tatsächlich getroffene Regel, die getrennten Mindestanforderungen für Source heartbeat und Destination heartbeat, die zutreffenden Ausnahmen und das reale Zugriffsergebnis. Die Anzeige Missing allein ist kein Nachweis vollständiger Isolation; diese Einordnung ist dokumentarisch begründet, nicht auf einer hier durchgeführten Appliance- oder Tenant-Prüfung gestützt.

Ein roter Status sollte für diesen Test nicht durch Abschalten oder Manipulieren des Endpoint-Schutzes erzeugt werden. Stimmen Central, Control Center und Regelwirkung nicht überein oder erscheint Missing, führt Missing Heartbeat Alerts systematisch prüfen durch Zonen, Pfad, Rule ID und Logs.

Die umfassendere Ansicht unter Control Center > User & device insights erklärt User & Device Insights sicher auswerten. Der Artikel behandelt Heartbeat- und Anwendungszähler, Zero-Day-Funde, UTQ, SSL/TLS-Fehler und Firewall-Sitzungen, einschliesslich der unterschiedlichen Zeitfenster und des Unterschieds zwischen dem Ausblenden eines Fehlers und dem Ändern einer Entschlüsselungsrichtlinie. Diese lokalen Signale sind nicht mit Central Reporting gleichzusetzen und belegen nicht, dass jeder Endpoint oder jede Verbindung geschützt ist.

Heartbeat-Überwachungsumfang festlegen und den Pfad prüfen

Unter System > Sophos Central > Optional configurations > Missing heartbeat zones wählt man nur Zonen aus, in denen verwaltete Sophos Endpoints erwartet werden. Fehlende Heartbeats werden nur in den ausgewählten Zonen erkannt. Drucker, Gäste, IoT-Geräte und Clients mit einem anderen EDR erhalten durch die Registrierung keinen Sophos Heartbeat. Die Zonenliste und die Heartbeat-Bedingungen der zutreffenden Firewall-Regeln müssen zusammenpassen. Sophos dokumentiert einen Sonderfall: Wenn eine Heartbeat-Richtlinie eine Zone blockiert, in diesem Feld aber keine Zone hinzugefügt ist, kann das Widget im Control Center trotzdem Missing anzeigen. Eine leere Liste belegt deshalb nicht, dass keine Richtlinie den Traffic beeinflusst.

Vor einer Änderung des Überwachungsumfangs oder einer Pilotregel dokumentiert man die bisherige Zonenliste, Rule ID, Heartbeat-Optionen sowie IP, MAC und aktuellen Status des Pilotendpoints. Anschliessend nimmt man nur die vorgesehene, eng begrenzte Änderung vor. Danach vergleicht man denselben Endpoint in Central und im Control Center, erzeugt einen freigegebenen Testverkehr mit dem gesunden Endpoint und prüft im Log Viewer die zutreffende Rule ID und das Zugriffsergebnis. Ändert sich der Zugriff unerwartet, stellt man die dokumentierte Zonenliste und die Regeloptionen wieder her, wiederholt denselben Testverkehr und untersucht den Pfad, statt die Heartbeat-Anforderungen global abzuschwächen.

Der dokumentierte Heartbeat-Kanal verwendet verschlüsseltes TLS zu 52.5.76.173 über TCP 8347. Central stellt Zertifikate bereit, mit denen die Firewall Endpoints der richtigen Organisation zuordnen kann. Ein offener Port allein stellt dieses Vertrauen nicht her. Vor der Diagnose eines fehlenden Status sollte man diese Topologiegrenzen prüfen:

• Ein VPN, das vor der Heartbeat-Verbindung aufgebaut wird, kann den Heartbeat-Traffic an der lokalen Firewall vorbeileiten. Bei Sophos Connect IPsec prüft man Remote access VPN > IPsec > Advanced settings > Send Security Heartbeat through tunnel anhand der vorgesehenen Verbindungsrichtlinie.
• Hinter einem zwischengeschalteten Router ohne NAT kann ein Endpoint seinen Gesundheitsstatus weiterhin übermitteln, die Firewall kann aber keinen fehlenden Heartbeat erkennen. Ein sichtbarer Gesundheitsstatus belegt nicht, dass die Missing-Überwachung auf diesem Pfad funktioniert.
• Hinter einem NAT-Gateway können Endpoints ihren Gesundheitsstatus nicht mit der Firewall austauschen. Das ist eine andere Einschränkung als beim gerouteten Pfad ohne NAT.
• Im TAP-Modus muss mindestens ein dauerhaft verbundenes Interface in der LAN-Zone für die Endpoints erreichbar sein. Gespiegelter Traffic allein reicht nicht: Die Endpoints erhalten die Adressen der LAN-Interfaces über Central und versuchen, ihren Heartbeat an eine dieser Adressen zu senden.

Gesundheitsstatus einordnen, ohne automatische Isolation anzunehmen

Connected (green) ist der vom Endpoint gemeldete gesunde Status, aber keine Garantie, dass jede Bedrohung ausgeschlossen ist. Warning (yellow) kann auf eine PUA, inaktive oder bereits bereinigte Malware oder seit 24 Stunden nicht aktualisierte Signaturen hinweisen. At risk (red) muss untersucht werden, beispielsweise wegen aktiver Malware, die nicht entfernt werden konnte, schädlichen Netzwerkverkehrs oder nicht korrekt funktionierenden Schutzes. Missing (red) bedeutet etwas anderes: Die Firewall sieht Traffic, erhält aber keinen zugehörigen Gesundheitsstatus. Man sollte die Endpoint-Events vergleichen, bevor man beide roten Anzeigen als denselben Incident behandelt.

Die Detailansicht für rote und gelbe Endpoints zeigt Hostname, IP, Benutzer und die Zeit seit der Statusänderung. Ein Missing-Eintrag kann im Control Center und in Reports bestehen bleiben, nachdem der Endpoint das Netzwerk verlassen hat; er ändert sich, wenn sich der Endpoint erneut verbindet. Ein solcher Eintrag sollte nicht nur gelöscht werden, damit das Dashboard grün erscheint. Der verlinkte Leitfaden zu Missing Heartbeat erklärt die Beweissicherung, die Abwägung bei Timern, das unterstützte Modern-Standby-Verhalten und eine eng begrenzte Bereinigung. Endpoints senden ihren Heartbeat alle 15 Sekunden. Die Verteilung der Listen roter und gelber Endpoints alle 30 Sekunden und das standardmässige Timeout von 60 Sekunden für die Missing-Erkennung sind separate Mechanismen. Längere Erkennungs- oder Meldeverzögerungen können auch echte Alerts verzögern.

Der Schutz vor lateraler Bewegung ist eine weitere, separate Kontrolle: Andere Endpoints stellen die Kommunikation mit einem roten Endpoint nur ein, wenn die entsprechende Central-Endpoint-Richtlinie greift. Die Firewall verteilt MAC-Adressen und Gesundheitsstatus als Layer-2-Proxy innerhalb derselben Broadcast-Domäne. Man darf nicht annehmen, dass dies Endpoints über geroutete Netzwerke hinweg isoliert oder Heartbeat-Bedingungen für Traffic ersetzt, der durch die Firewall läuft.

Die SFOS-22-Übersicht beschreibt die synchronisierte Benutzeridentität mit Domänenname, Benutzername und Active Directory. Die SFOS-23-Übersicht dokumentiert zusätzlich User Principal Name (UPN) und die Kontoprüfung gegen Active Directory or Microsoft Entra ID. Diese SFOS-23-Beschreibung darf nicht auf eine SFOS-22-Umgebung übertragen werden. Ebenso wenig konfiguriert die Registrierung allein die Identitätsauthentifizierung. Vor dem Einsatz identitätsbasierter Regeln prüft man die tatsächliche Firmware und die Konfiguration der Authentifizierungsserver.

Was Sophos Fusion nicht ersetzt

Sophos Fusion ist hilfreich, ersetzt aber nicht die saubere Firewall-Konfiguration.

Central ersetzt nicht:

• saubere Zonen- und Interface-Planung
• restriktive Firewall-Regeln
• Device Access Hardening
• MFA für Admins und Portale
• lokales Troubleshooting mit Log Viewer und Packet Capture
• dokumentierte Backups und Wiederherstellungstests
• ein externes Syslog-System, wenn Compliance oder lange Aufbewahrung gefordert ist

Sophos Fusion ist also ein zusätzlicher Management- und Reporting-Layer, aber keine Abkürzung für eine sichere Grundkonfiguration.

Vor der Registrierung prüfen

Vor der Verbindung mit Sophos Fusion sollte man kurz klären, was mit der Registrierung erreicht werden soll. Das verhindert später unklare Zuständigkeiten, doppelte Tenants oder unnötig aktivierte Dienste.

Wichtige Vorabfragen:

• In welchem Sophos-Fusion-Tenant soll die Firewall registriert werden?
• Wer hat im Tenant die nötigen Rechte für Firewall Management, Reporting, Backup und Lizenzthemen?
• Ist die Firewall bereits in einem anderen Central-Konto registriert?
• Hat die Firewall eine aktive bezahlte Subscription ausser Base Firewall oder eine für Central Firewall Management berechtigende aktive Sophos-Supportlizenz, zum Beispiel Enhanced Support? Die konkrete Lizenz prüfen, nicht nur das Vorhandensein eines Supportvertrags.
• Hat die Firewall eine funktionierende IPv4-Verbindung ins Internet?
• Soll Central nur für Lizenzübersicht und Inventar genutzt werden oder auch für Management, Reporting und Backups?
• Werden Firewall-Gruppen genutzt, und sind die Rollen für Admin, Helpdesk und Read-only praktisch getestet?
• Dürfen Firewall-Logs aus Datenschutz- oder Compliance-Sicht an Sophos Fusion gesendet werden?
• Gibt es ein aktuelles lokales Backup und einen dokumentierten Secure Storage Master Key?
• Ist klar, wer nach der Registrierung Alerts, Reports und fehlgeschlagene Tasks prüft?

Wenn die Firewall bereits im falschen Konto liegt, sollte zuerst Sophos Firewall in ein anderes Sophos-Fusion-Konto übertragen geprüft werden. Für die Einordnung der verschiedenen Konten und Portale hilft Sophos-Portale: SophosID, Central, Support und Firewall-Zugänge.

Wann man die Firewall nicht verbinden muss

Eine Verbindung mit Sophos Fusion ist nicht zwingend nötig, wenn:

• nur eine einzelne Firewall lokal verwaltet wird
• keine Central Reports benötigt werden
• keine Sophos-Endpoint-Integration geplant ist
• Cloud-Management aus organisatorischen Gründen nicht gewünscht ist
• Logs bereits an ein eigenes SIEM oder einen Syslog-Server gesendet werden

In solchen Fällen kann man die Firewall lokal betreiben. Wichtig ist dann aber, Backups, Firmware-Updates, Monitoring und Logging anderweitig sauber zu organisieren.

Wann Sophos Fusion empfehlenswert ist

Sophos Fusion ist besonders empfehlenswert, wenn:

• mehrere Firewalls verwaltet werden
• Admins von unterschiedlichen Standorten arbeiten
• Firewalls nicht direkt per WebAdmin aus dem Internet erreichbar sein sollen
• Konfigurationsbackups zentral gespeichert werden sollen
• Firewall Reporting benötigt wird
• Sophos Endpoint, MDR, XDR oder weitere Sophos-Fusion-Produkte im Einsatz sind
• Security Heartbeat und Synchronized Security genutzt werden sollen

Verbindung aktivieren

Die Verbindung wird auf der Firewall unter System > Sophos Central eingerichtet.

Die folgenden Abläufe verwenden die englischen UI-Bezeichnungen, die für SFOS 22 und SFOS 23 dokumentiert sind; die lokale Oberfläche kann weiterhin Sophos Central anzeigen. Ein lokaler Firewall-Administrator benötigt Zugriff auf dieses Menü. Central Firewall Management erfordert weiterhin eine aktive bezahlte Subscription ausser Base Firewall oder eine aktive Sophos-Supportlizenz, die diese Berechtigung einschliesst, zum Beispiel Enhanced Support. Base Firewall allein reicht nicht aus, und der Managementpfad über das Internet funktioniert nur über IPv4.

Vor dem Erzeugen eines OTP: Die Firewall muss bereits eingerichtet und im vorgesehenen Sophos-Fusion-Tenant geclaimt sein. Falls Setup oder Claim noch fehlen, zuerst Sophos Firewall einrichten, claimen und Lizenzen aktivieren durchgehen und die Geräte- und Lizenzzuordnung prüfen. Die anschliessende OTP-Registrierung bindet die bestehende Firewall für Central Management an; sie ersetzt den Eigentums-Claim nicht und aktiviert keine Subscriptions. Auch die Partnerzuweisung zum Kunden ersetzt den Claim nicht.

Es gibt zwei typische Registrierungswege:

• OTP aus Sophos Fusion: Sinnvoll, wenn ein Partner, ein Projektteam oder ein Firewall-Admin nicht mit Super-Admin-Zugangsdaten des Central-Tenants auf der Firewall arbeiten soll. In Sophos Fusion wird unter My Products > Firewall Management > Firewalls > Add Firewall die vorhandene Firewall per Seriennummer hinzugefügt und ein OTP erzeugt.
• Sophos-Fusion-Zugangsdaten: Sinnvoll, wenn man mit einem passenden Sophos-Central-Admin-Konto direkt auf der Firewall registriert. Sophos nennt dafür einen Central Super Admin.

Bei HA-Paaren sollte man besonders sauber arbeiten. Bei der OTP-Registrierung werden beide Seriennummern in Sophos Fusion eingetragen; bei neuen HA-Paaren wird das OTP auf dem Primary-Gerät verwendet.

OTP im richtigen Tenant erzeugen

Für eine bereits eingerichtete und geclaimte Firewall erzeugt man das OTP zuerst in Central, bevor man mit den lokalen Registrierungsschritten fortfährt:

1. Im vorgesehenen Tenant anmelden. Ein Partner weist die Firewall zuerst im Partner Dashboard dem richtigen Kunden zu und öffnet dessen Central-Admin-Konsole. Die Kundenzuweisung ersetzt den Claim nicht.
2. My Products > Firewall Management > Firewalls > Add Firewall öffnen und Join a firewall that is configured or deployed auswählen.
3. Unter Enter Device Serial Number die vorgesehene Seriennummer eingeben und auf Next klicken. Bei HA beide Seriennummern durch ein Komma getrennt eingeben und mit dem geplanten Paar abgleichen.
4. Register using OTP ausgewählt lassen und Copy OTP and Finish wählen. Das OTP ist 14 Tage gültig. Man gibt es nur über den freigegebenen Kanal zur sicheren Übermittlung von Geheimnissen an den berechtigten Firewall-Administrator weiter. OTP, Passwörter oder ungeschwärzte Screenshots von Zugangsdaten gehören nicht in eine Support-Dokumentation.
5. Auf der Firewall Register > Use OTP wählen, das OTP unter Enter OTP einfügen und auf Register klicken. Bei einem neuen HA-Paar gibt man das OTP nur auf dem Primary-Gerät ein. Anschliessend aktiviert man die vorgesehenen Central-Dienste und lässt sie wie unten beschrieben freigeben.

Ist das OTP abgelaufen oder schlägt die Registrierung fehl, prüft man zuerst den vorgesehenen Tenant, den Claim, die Seriennummern und die IPv4-Konnektivität. Bei Bedarf erzeugt man ein neues OTP im richtigen Tenant. Man sollte nicht wiederholt abmelden oder die Eigentumszuordnung ändern, um den Fehler zu umgehen. Die Registrierung gilt erst als abgenommen, wenn Seriennummern und Dienststatus in beiden Ansichten übereinstimmen.

Der alternative Ablauf mit Zugangsdaten erfordert einen Central Super Admin. Ein Administratorkonto aus einem Central Enterprise sub-estate kann für diese Registrierung nicht verwendet werden. Das Tenant-Konto und die lokale Firewall-Administratorrolle bleiben getrennt: Mit OTP kann der lokale Administrator die Firewall registrieren, ohne das Super-Admin-Passwort des Tenants zu erhalten.

Typischer Ablauf auf der Firewall:

1. Auf der Firewall anmelden.
2. System > Sophos Central öffnen.
3. Register auswählen.
4. Use OTP oder Use email address auswählen.
5. OTP oder Sophos-Central-Zugangsdaten eintragen.
6. Registrierung abschliessen.
7. Sophos Central services aktivieren.
8. Gewünschte Services auswählen.

Je nach Bedarf können diese Optionen aktiviert werden:

• Use Sophos Central reporting / Send reports and logs to Sophos Central: sendet Log- und Reportdaten an Sophos Fusion.
• Use Sophos Central management / Manage from Sophos Central: erlaubt Management-Zugriff über Sophos Fusion.
• Send configuration backup to Sophos Central: speichert Konfigurationsbackups in Sophos Fusion. Diese Option hängt praktisch am Central-Management-Setup und muss in Sophos Fusion bestätigt werden.

Es sollten nur die Funktionen aktiviert werden, die wirklich genutzt werden. In Umgebungen mit Datenschutz- oder Compliance-Vorgaben sollte vorher geklärt werden, welche Logdaten an Sophos Fusion gesendet werden dürfen.

Nach dem Aktivieren der Services muss ein Konto mit der Rolle Super admin im betroffenen Sophos-Fusion-Mandanten in Sophos Fusion die Services akzeptieren:

1. In Sophos Fusion anmelden.
2. My Products > Firewall Management > Firewalls öffnen.
3. Firewall mit Approval Pending suchen.
4. accept-services auswählen.
5. Auf der Firewall prüfen, ob der Status von Waiting for approval from Sophos Central auf Managed beziehungsweise verbunden wechselt.

Der Statuswechsel kann einige Minuten dauern. Wenn die Anzeige nicht sofort springt, sollte man nicht mehrfach registrieren, sondern zuerst Central-Status, Internetverbindung, DNS und Uhrzeit prüfen.

Steht vor der Firewall ein Egress-Filter, müssen zusätzlich die passenden ausgehenden Sophos-Dienste und Ports für Central, Reporting und Backups erreichbar sein.

Ein HA-Paar unter Central Management bringen

Vor jeder Änderung unterscheidet man zwei Ausgangslagen. Man dokumentiert beide Seriennummern, Firmware-Versionen, Primary-/Auxiliary-Rollen, den lokalen HA-Status und die Zustände der Central-Dienste. Aktuelle Konfigurationsbackups, die zugehörigen Passwörter, der Secure Storage Master Key und ein funktionierender lokaler Administrationszugang müssen verfügbar sein. Die Bildung eines HA-Paars ist eine separate Wartungsänderung und keine Abkürzung zur Behebung von Registrierungsproblemen. Sophos Firewall HA-Varianten planen und betreiben erklärt die massgebliche Konfiguration, die Synchronisierung und den Wiederherstellungsplan.

• Zwei eigenständige Firewalls werden bereits zentral verwaltet: Man bereitet HA lokal mit der vorgesehenen Primary-Konfiguration vor. Beide Geräte müssen dieselbe Firmware-Version verwenden. Sophos dokumentiert sowohl Active-Active als auch Active-Passive. Nach der Paarbildung sollte Central ein HA-Paar anzeigen, nicht zwei unabhängige Verwaltungsziele. Bevor die Synchronisierung die Auxiliary-Konfiguration ersetzen darf, folgt man dem Ablauf zur HA-Vorbereitung.
• Ein HA-Paar besteht bereits, wird aber nicht zentral verwaltet: Man arbeitet auf dem Primary. Die HA-spezifische Dokumentation bezeichnet die Registrierungsansicht als Central synchronization und die Aktion als Register both HA devices. Nach der Registrierung aktiviert man Central Management und wählt in Central neben der Primary-Firewall mit dem berechtigten Super Admin Approval Pending > accept-services. Beim OTP-Verfahren verwendet man beide Seriennummern und gibt das OTP wie oben beschrieben nur auf dem Primary ein, statt jeden Knoten einzeln zu registrieren.

Nach einigen Minuten prüft man, ob Central ein einzelnes Paar mit einem HA-Symbol und den vorgesehenen Seriennummern anzeigt. Primary-/Auxiliary-Rollen und Synchronisierung werden lokal geprüft, ebenso der Management-Zugriff und ein freigegebener Test mit Produktivverkehr. Konfigurationsänderungen über Central gelten für beide Firewalls. Ein einzelnes angezeigtes Objekt belegt nicht, dass nur der Primary betroffen ist.

Bleibt die Anzeige getrennt oder doppelt, vergleicht man den lokalen HA-Zustand, beide Seriennummern, Tenant, Servicefreigabe und Task Queue, bevor man die Registrierung ändert. Soll nur die Management-Änderung zurückgenommen werden, stellt man die dokumentierten Zustände der Central-Dienste wieder her und prüft lokalen Zugriff und HA-Zustand. Man löst das HA-Paar nicht auf, führt den Setup-Assistenten nicht erneut aus und erzwingt keine Abmeldung per CLI, um eine Darstellungsabweichung zu beheben. Die Rücknahme der HA-Paarbildung erfordert den separat freigegebenen HA-Wiederherstellungsplan. Bei ungelösten Registrierungsproblemen oder unklarem Umfang der betroffenen Knoten übergibt man die gesicherten Zustandsdaten an Sophos Support.

Blockierte Registrierung sicher eingrenzen

Bei Approval Pending oder Waiting for approval from Sophos Central wird nicht erneut registriert und nicht vorschnell abgemeldet. Zuerst prüft man den richtigen Tenant und die Seriennummer, die Freigabe durch einen Super admin des betroffenen Mandanten unter My Products > Firewall Management > Firewalls, IPv4-Internetzugang, DNS, Uhrzeit und die benötigten ausgehenden Dienste. Bei HA müssen beide Seriennummern in Central hinterlegt sein; das OTP wird auf dem Primary eingegeben. Bleibt der Status trotz korrigierter Voraussetzungen hängen, werden Screenshots der Statusanzeigen, Zeitpunkt, Seriennummern und HA-Rollen für Sophos Support gesichert.

Synchronized-Security-Konfiguration löschen: nur als freigegebene Support-Massnahme. Die Device-Console-Dokumentation für SFOS 22 und 23 beschreibt system synchronized-security central_registration deregister, um die Synchronized-Security-Konfiguration aus Sophos Fusion beziehungsweise Sophos Central zu entfernen, wenn diese die Registrierung oder Abmeldung blockiert. Der hier gemeinte Einsatzfall ist eine bestehende Firewall, deren Registrierung nach den obigen Vorprüfungen weiterhin durch Synchronized Security blockiert wird und für die Sophos Support diese Ursache bestätigt. Das ist weder die vollständige Geräteabmeldung über Deregister im folgenden Abschnitt noch eine interne Datenbankbereinigung per SQL. Der Befehl ist zustandsverändernd, kein lesender Diagnosetest und kein allgemeiner Fix für Approval Pending.

Vor jeder Ausführung dokumentiert man im Supportfall den vorgesehenen und den aktuellen Tenant, Gerät und Seriennummer, die genaue SFOS-Version einschliesslich Build, Registrierungsstatus, aktive Central-Dienste, Security Heartbeat und Synchronized Application Control sowie betroffene Regeln und deren bisherige Wirkung. Bei HA gehören beide Seriennummern, Primary-/Auxiliary-Rollen, Synchronisierungszustand und der ausdrücklich bestätigte Umfang der betroffenen Knoten dazu. Ein berechtigter lokaler WebAdmin- und Konsolenzugang muss unabhängig vom Central-Managementpfad geprüft und verfügbar sein; ein aktuelles lokales Backup, dessen Passwort und der Secure Storage Master Key werden bereitgehalten.

Ohne build-spezifische Freigabe nicht ausführen. Sophos Support muss vorab bestätigen, ob die Konfigurationslöschung im konkreten Fall geeignet ist, welche Auswirkungen auf Registrierung, Dienste, Heartbeat-abhängigen Traffic und HA zu erwarten sind und wie die Wiederherstellung einschliesslich nötiger Registrierung und Servicefreigaben erfolgt. Die dokumentierte Syntax allein garantiert weder unveränderte Dienste noch eine reversible Wiederherstellung des bisherigen Zustands; ein Backup allein belegt diesen Rückweg ebenfalls nicht. Bleiben Auswirkung, Knotenumfang oder Wiederherstellungsablauf unklar, bleibt die Ausführung ausgesetzt und der Fall beim Support. Keine SQL-Eingriffe oder erzwungene vollständige Abmeldung als Ersatz versuchen.

Nach einer ausdrücklich freigegebenen Massnahme prüft man gemäss Supportplan die Registrierung im richtigen Tenant und beide Statusansichten, die vorgesehenen Dienste und den unabhängigen lokalen Zugriff. Zusätzlich kontrolliert man Security Heartbeat mit dem verwalteten Pilotendpoint, gegebenenfalls die Anwendungserkennung, betroffene Regelwirkung, Produktivverkehr, Logs und bei HA Rollen und Synchronisierung. Eine wieder sichtbare Firewall allein reicht nicht als Erfolgsnachweis. Bei Abweichungen sichert man den Zustand und folgt dem freigegebenen Wiederherstellungsplan mit Sophos Support, statt den Befehl erneut auszuführen.

Central-Dienste ändern oder die Registrierung aufheben

Wenn man Security Heartbeat, Synchronized Application Control oder Sophos Central management ausschaltet, bleibt die Firewall in Central registriert. Die Dienste sind jedoch nicht unabhängig: Security Heartbeat auszuschalten deaktiviert auch Synchronized Application Control; Endpoints und Firewall tauschen dann keine Gesundheitsstatusinformationen mehr aus. Eine Heartbeat-Pause betrifft deshalb mehr als einen einzelnen Dienst.

Vor der Änderung hält man unter System > Sophos Central die bisherigen Ein-/Aus-Zustände von Security Heartbeat und Synchronized Application Control sowie den Zustand des betroffenen Dienstes fest. Anschliessend deaktiviert man den vorgesehenen Dienst, speichert, prüft die betroffenen Dienstzustände und kontrolliert, dass die Firewall weiterhin registriert ist.

Für den Rückweg stellt man den betroffenen Dienst und beide dokumentierten Zustände wieder her und lässt eine eventuell neue Servicefreigabe in Central durch einen Super admin des betroffenen Mandanten akzeptieren. Man prüft Security Heartbeat und Synchronized Application Control jeweils ausdrücklich, statt anzunehmen, dass die Heartbeat-Aktivierung allein beide korrekt wiederherstellt. War Heartbeat vorher aktiv, kontrolliert man mit einem verwalteten Pilot-Endpoint den aktuellen Gesundheitsstatus und den zugehörigen Connected-Zähler im Control Center wie oben beschrieben. War Synchronized Application Control vorher aktiv, prüft man zusätzlich die Anwendungserkennung unter Applications > Synchronized Application Control mit dem Pilot-Endpoint; den passenden Prüfablauf erklärt Application Control gezielt einsetzen.

Eine vollständige Abmeldung ist ein eigener, geplanter Schritt im Lebenszyklus:

1. Ein aktuelles lokales Konfigurationsbackup erstellen und Backup-Passwort sowie Secure Storage Master Key verfügbar halten. Tenant, Seriennummern, aktive Dienste, Firewall-Gruppen, offene Tasks, Reporting und Central-Backups dokumentieren. Bei HA beide Knoten und ihre Rollen erfassen.
2. Lokalen WebAdmin-Zugang mit einem berechtigten Konto testen. Offene Central-Tasks abschliessen oder ihren Zustand dokumentieren und ein Wartungsfenster wählen. Central-Backup-Dateien nicht als einzigen Rückweg verwenden, weil sie beim Entfernen aus Central Management gelöscht werden.
3. Auf der Firewall System > Sophos Central öffnen und Deregister wählen. Keine nicht dokumentierten Device-Console- oder Advanced-Shell-Befehle als Abkürzung verwenden.
4. Lokal prüfen, dass die Firewall nicht mehr als Central-verwaltet angezeigt wird. Unter My Products > Firewall Management > Firewalls den Zustand des Geräteobjekts kontrollieren; ein verbleibendes Objekt nicht mit einer funktionierenden Registrierung verwechseln. Danach den lokalen Zugriff, den Produktivverkehr, das Logging und bei HA den Clusterstatus prüfen.

Soll die Änderung zurückgenommen werden, registriert man die Firewall über den normalen OTP- oder Super-Admin-Ablauf erneut, lässt die benötigten Services in Central durch einen Super admin des betroffenen Mandanten akzeptieren und führt die dienstspezifischen Abnahmetests aus. Ist Deregister nicht verfügbar, bleibt die Abmeldung hängen oder ist bei HA der betroffene Umfang unklar, wird sie nicht per CLI erzwungen. Dann übergibt man die gesicherten Zustandsdaten an Sophos Support.

Nach der Verbindung kontrollieren

Nach der Registrierung sollte man nicht nur prüfen, ob die Firewall in Sophos Fusion sichtbar ist. Entscheidend ist, ob die aktivierten Dienste wirklich funktionieren und ob die Verantwortlichkeiten klar sind.

Sinnvolle Nachkontrolle:

1. In Sophos Fusion prüfen, ob Modell, Seriennummer und Lizenzstatus korrekt angezeigt werden.
2. Auf der Firewall unter System > Sophos Central prüfen, ob die gewünschten Services aktiv und verbunden sind.
3. Wenn Manage from Sophos Central genutzt wird, öffnet man in Central My Products > Firewall Management > Firewalls und klickt auf den Namen der Firewall, um ihre WebAdmin-Konsole zu öffnen. Man wartet einige Sekunden und prüft den Zugriff mit der vorgesehenen Administratorrolle; der funktionierende lokale Administrationszugang bleibt während des Tests verfügbar.
4. Wenn Reporting aktiv ist, im Log Viewer und in Sophos Fusion prüfen, ob aktuelle Ereignisse ankommen.
5. Wenn Cloud-Backups aktiv sind, ein geplantes Backup konfigurieren und den letzten erfolgreichen Backup-Zeitpunkt dokumentieren.
6. Alerts, Rollen und Zuständigkeiten in Sophos Fusion prüfen.
7. Wenn Änderungen über Central verteilt werden, die Central Firewall Management Task Queue kontrollieren.

Gerade bei mehreren Firewalls sollte die Registrierung in der internen Dokumentation landen: Tenant, Seriennummer, Standort, aktiver Central-Service, Reporting-Aufbewahrung, Backup-Intervall und zuständige Person.

Central-Dienste getrennt abnehmen

Nach der Registrierung sollte nicht nur der globale Central-Status geprüft werden. Die einzelnen Dienste haben unterschiedliche Fehlerbilder und brauchen deshalb eigene Abnahmetests.

• Registrierung und Inventar: Firewall erscheint im richtigen Tenant, Seriennummer, Modell, Lizenz und Standort stimmen.
• Manage from Sophos Central: Zugriff über Central funktioniert mit der vorgesehenen Admin-Rolle, ohne dass WebAdmin unnötig aus dem WAN offen bleibt.
• Central Reporting: Ein bewusst ausgelöstes Ereignis erscheint im Report Hub mit richtiger Firewall, Zeit, Rule ID oder Logtyp.
• Central Backups: Ein geplantes oder manuelles Backup läuft erfolgreich durch, und Backup-Intervall, Passwort und Secure Storage Master Key sind dokumentiert.
• Backup-Aufbewahrung: Die fünf neuesten Central-Backups und ein eventuell dauerhaft gespeichertes Backup sind bekannt. Bei HA ist klar, dass der Primary das Backup erzeugt.
• Backup-Alarmierung: Fehlgeschlagene Central-Backups erzeugen Alerts und E-Mail-Hinweise, die von einer verantwortlichen Person geprüft werden.
• Central Tasks: Nach einer Central-Änderung wird die Task Queue geprüft, bis der Task erfolgreich abgeschlossen oder sauber eskaliert ist.
• Security Heartbeat: Sophos Fusion zeigt den erwarteten Pilotstatus, und der passende Zähler im Control Center ist plausibel. Regelbasierte Einschränkungen werden erst nach dieser Baseline schrittweise getestet.
• Alerts und Zuständigkeit: Es ist klar, wer fehlgeschlagene Tasks, Backup-Probleme, Reporting-Lücken und Lizenzwarnungen regelmässig prüft.

Diese Trennung verhindert einen typischen Betriebsfehler: Eine Firewall kann in Sophos Fusion sichtbar sein, während Reporting, Backups oder Central Tasks trotzdem nicht korrekt funktionieren.

Typische Fehler

Firewall ist im falschen Central-Konto registriert

Das passiert häufig bei Dienstleisterwechseln, Testaccounts oder mehreren historischen SophosID-Konten. In diesem Fall sollte nicht einfach eine zweite Registrierung versucht werden. Zuerst klären, wo die Firewall aktuell liegt, wer Zugriff auf den Tenant hat und ob ein Account-Transfer nötig ist.

Central Management wird mit lokalem WebAdmin verwechselt

Manage from Sophos Central ist ein zusätzlicher Zugriffsweg. Die lokale WebAdmin Console, lokale Admin-Benutzer, MFA, Device Access und SSH bleiben weiterhin eigenständige Sicherheitskontrollen. Besonders wichtig ist, dass WebAdmin nicht nur deshalb aus dem WAN erreichbar bleibt, weil Central Management noch nicht getestet wurde.

Central-Ansicht wird nicht lokal validiert

Bei Gruppenrichtlinien, HA-Clustern, WAF-Regeln und Firmware-Tasks sollte man Central nicht als einzige Wahrheit behandeln. Central kann anzeigen, dass eine Änderung geplant, angewendet oder sichtbar ist. Entscheidend ist aber, ob die betroffene Firewall die Änderung verarbeitet hat und ob der reale Traffic oder Dienst danach funktioniert.

Praktisch heisst das: Nach Central-Änderungen Task Queue, lokale WebAdmin-Ansicht, Log Viewer und bei Bedarf Audit Trail prüfen. Wenn die Central-Oberfläche nur lädt, ein HA-Paar doppelt wirkt oder eine Gruppenregel nicht verschoben werden kann, ist das nicht automatisch ein Firewall-Regelproblem.

Reporting ist aktiviert, aber es kommen keine verwertbaren Daten an

Dann sollte man zuerst prüfen, ob Send reports and logs to Sophos Central aktiv ist, ob die passenden Logtypen eingeschaltet sind und ob die Firewall Central erreichen kann. Danach im Artikel Central Firewall Reporting aktivieren die Detailpunkte zu Logauswahl, Aufbewahrung und Reports prüfen.

Cloud-Backup wird als einziges Backup verstanden

Central-Backups sind praktisch, aber sie ersetzen keine vollständige Recovery-Planung. Für kritische Standorte sollte zusätzlich klar sein, wo lokale Backups liegen, wer das Backup-Passwort kennt, ob der Secure Storage Master Key dokumentiert ist und wie ein Restore oder Reimage ablaufen würde.

Niemand prüft Central Tasks und Alerts

Central hilft nur, wenn Meldungen und fehlgeschlagene Tasks auch bearbeitet werden. Besonders bei Gruppenrichtlinien, Firmware-Tasks, Reporting und Backups sollte klar sein, wer Warnungen prüft und wie Fehler intern eskaliert werden.

Häufige Fragen