Sophos Central Firewall Groups und Full Sync sicher verwenden

Eine Firewall Group in Sophos Central ist eine gemeinsame Konfigurationsvorlage für mehrere Firewalls. Das spart Arbeit, verändert aber auch die Verantwortung: Sobald eine Firewall der Gruppe vollständig folgt, werden unterstützte Regeln, Objekte und Einstellungen zentral verwaltet.

Der kritische Entscheid fällt beim Hinzufügen der Firewall. Mit Full Sync übernimmt sie die vollständige unterstützte Gruppenkonfiguration. Mit Skip full sync bleibt der aktuelle Bestand zunächst erhalten, spätere Gruppenänderungen werden aber trotzdem verteilt. Skip full sync ist deshalb keine dauerhafte Trennung von der Gruppe.

⚠️ Vor dem ersten Full Sync ein aktuelles Firewall-Backup erstellen, eine lokale Admin-Sitzung offenhalten und den Rückweg testen. Ein erfolgreicher Central-Task beweist noch nicht, dass Routing, NAT, Authentifizierung und produktiver Traffic korrekt funktionieren.

Schnellweg für eine sichere Einführung

Eine repräsentative Pilotfirewall auswählen und ihre lokale Konfiguration, Regelreihenfolge und Abhängigkeiten inventarisieren.
Unter My Products > Firewall Management > Firewalls > Create New Group eine leere Gruppe erstellen.
Use Sophos default oder Import existing configuration bewusst wählen und die erzeugte Gruppenpolicy vor der Zuweisung prüfen.
Die Pilotfirewall zunächst nur dann mit Skip full sync hinzufügen, wenn ihr aktueller Bestand erhalten bleiben muss.
Eine kleine, eindeutig erkennbare Gruppenänderung ausrollen und die Task Queue prüfen.
Die Änderung lokal auf der Firewall und mit echtem Testtraffic abnehmen.
Erst danach weitere Firewalls, Untergruppen oder einen vollständigen Sync planen.

Was eine Firewall Group verwaltet

Die Gruppenpolicy wird über Manage Policy geöffnet. Sie ähnelt dem lokalen WebAdmin, gilt aber für alle zugewiesenen Firewalls. Unterstützte Objekte und Einstellungen werden von Central verteilt; rein lokale oder interfacebezogene Konfigurationen sind nicht automatisch Bestandteil der Vorlage.

Das ist besonders wichtig bei unterschiedlichen Standorten. Eine gemeinsame Regel kann nur funktionieren, wenn ihre Zonen, dynamischen Interfaces, Netze, Dienste und Abhängigkeiten auf jedem Zielsystem sinnvoll aufgelöst werden. Für individuelle Standortwerte eignen sich bewusst geplante Untergruppen oder Dynamic Objects besser als nachträgliche lokale Korrekturen.

Objekte, Einstellungen und Untergruppen

Objekte wie Firewall-Regeln, NAT-Regeln, FQDN Hosts und IP Hosts können in einer Gruppenpolicy erstellt und gelöscht werden. Untergruppen erben Objekte des übergeordneten Parents schreibgeschützt, können sie aber als Grundlage für eigene Regeln verwenden. Wird ein Parent-Objekt in einer Untergruppe verwendet, verhindert Central seine Löschung und zeigt die Abhängigkeit an.

Einstellungen mit einer Apply-Schaltfläche werden nur im obersten Parent konfiguriert und an alle Untergruppen vererbt. Eine Untergruppe kann diese Settings nicht separat überschreiben. Vor dem Aufbau einer Hierarchie sollte deshalb klar sein, welche Werte wirklich für alle Standorte gleich sein müssen.

Gruppe erstellen und Ausgangskonfiguration wählen

Unter My Products > Firewall Management > Firewalls > Create New Group stehen zwei Ausgangspunkte zur Verfügung:

Use Sophos default: erstellt eine neue Gruppenpolicy aus den Sophos-Standardwerten. Das ist für ein neues, bewusst zentral aufgebautes Design gut nachvollziehbar.
Import existing configuration: übernimmt die von Central unterstützte Konfiguration einer bestehenden Firewall als Vorlage. Interface- und andere lokale Konfigurationen werden nicht vollständig importiert.

Beim Import kann die Gruppenerstellung scheitern, wenn Firewall-Regeln nicht unterstützte Benutzertypen referenzieren. Sophos nennt AD-, Sophos-Live-, L2TP- und PPTP-Benutzer. Vor dem Import werden deshalb die betroffenen Regeln, Benutzerobjekte und die Task Queue geprüft; ein fehlgeschlagener Import wird nicht durch spontanes Löschen produktiver Regeln erzwungen.

Eine leere Gruppe ist oft der sicherste Start. Die Policy kann zuerst geprüft und vorbereitet werden, bevor eine Firewall zugewiesen wird. Die Verbindung der Firewall mit Central selbst erklärt Sophos Firewall mit Sophos Central verbinden.

Full Sync und Skip full sync richtig wählen

Full Sync

Full Sync übernimmt die vollständige unterstützte Gruppenkonfiguration auf die Firewall. Dieser Weg passt, wenn die Gruppenpolicy der vorgesehene Sollzustand ist und lokale Abweichungen bewusst ersetzt werden dürfen.

Vor der Ausführung werden mindestens Firewall- und NAT-Regeln, Hosts, Services, Authentifizierungsabhängigkeiten, Zertifikate, VPNs, Web- und TLS-Policies sowie lokale Service-ACLs verglichen. Ein aktuelles Backup, Managementzugang und ein Wartungsfenster gehören zur Änderung.

Skip full sync

Mit Skip full sync wird die bestehende Konfiguration beim Zuweisen nicht vollständig durch die Gruppenpolicy ersetzt. Die Firewall kann deshalb zunächst von den anderen Gruppenmitgliedern abweichen. Neue oder später geänderte Gruppenobjekte und Settings werden jedoch weiterhin an sie verteilt.

Der Modus passt für eine kontrollierte Übernahme einzelner zukünftiger Central-Änderungen. Er ist ungeeignet, wenn lokale und zentrale Administratoren dasselbe Objekt unabhängig pflegen sollen. Vor jeder Gruppenänderung muss klar sein, ob ein gleichnamiges oder bereits vorhandenes Objekt auf der Pilotfirewall überschrieben oder ergänzt wird.

Ein späterer Force sync übernimmt die vollständige Gruppenkonfiguration. Bei einem HA-Paar ist diese Aktion nur auf der aktiven Firewall verfügbar. Sie wird erst ausgelöst, wenn der Unterschied zwischen lokalem Bestand und Gruppenpolicy dokumentiert und technisch abgenommen ist.

Gruppenpolicy ändern und verteilen

In My Products > Firewall Management > Firewalls beim Gruppenmenü Manage Policy öffnen.
Nur die geplante Regel, das Objekt oder Setting ändern.
Zurück in Central unter My Products > Firewall Management > Tasks Queue den Auftrag aufklappen.
Status, betroffene Firewalls, Entity, Zeitpunkt und Fehlermeldung dokumentieren.
Erst nach Successful oder sauber geklärtem Teilstatus lokal prüfen.

Bei Firewall- und NAT-Regeln gelten Top und Bottom nur innerhalb der Central-Policy. Central-Regeln werden auf der Firewall oberhalb lokaler Regeln eingefügt. Eine gemischte Pflege kann dadurch andere Matches erzeugen als erwartet. Für zentral verwaltete Firewalls sollten zusammenhängende Regeln deshalb konsequent über Central gepflegt und anhand der tatsächlichen Firewall Rule ID beziehungsweise NAT Rule ID geprüft werden.

Wirkung lokal abnehmen

Ein erfolgreicher Task zeigt, dass Central den Auftrag verarbeitet hat. Die fachliche Abnahme erfolgt auf jeder betroffenen Firewall:

Ist das erwartete Objekt oder Setting sichtbar und vollständig?
Stimmt die effektive Regelreihenfolge?
Trifft ein definierter Testflow die erwartete Firewall- und NAT-Regel?
Funktionieren Hin- und Rückweg, DNS, Authentifizierung und abhängige Dienste?
Bleibt ein absichtlich nicht erlaubter Test blockiert?
Zeigt der Audit Trail den erwarteten Administrator, Zeitpunkt und Change?

Bei mehreren Standorten werden Erfolg und Fehler pro Firewall dokumentiert. Ein teilweise erfolgreicher Rollout wird nicht als Gruppenerfolg zusammengefasst. Für Rules, Policy Test, Log Viewer und Packet Capture hilft Sophos Firewall-Regeln testen.

Fehler sicher eingrenzen

Firewall bleibt unsynchronisiert

Zuerst Gruppenmitgliedschaft, Central-Verbindung, Lizenz, Task-Status und die konkrete Fehlermeldung prüfen. Retry wird erst nach behobener Ursache verwendet. Skip räumt nur den Task aus der Verarbeitung; die ausgelassene Konfiguration bleibt fachlich offen.

Lokale Regel verhält sich nach einem Push anders

Dann effektive Regelreihenfolge, Rule ID, Objektauflösung und NAT prüfen. Central-Regeln stehen oberhalb lokaler Regeln. Die Lösung ist nicht, weitere breite Allow-Regeln einzufügen, sondern Ownership und Reihenfolge des betroffenen Regelblocks eindeutig zu machen.

Import einer bestehenden Firewall scheitert

Die Fehlermeldung und referenzierten Entities sichern. Danach nicht unterstützte Benutzerreferenzen, lokale Interfaces und andere nicht importierbare Abhängigkeiten prüfen. Bleibt die Ursache unklar, mit Task-Daten und Firewall-Backup an Sophos Support eskalieren, statt produktive Objekte versuchsweise zu löschen.

Rollback und Betrieb

Eine Firewall kann aus der Gruppe entfernt werden; bereits aus Central verteilte Policies bleiben dabei auf der Firewall erhalten. Das Entfernen ist deshalb kein automatischer Rollback. Die zuvor dokumentierten Objekte werden lokal kontrolliert, bevor eine Regel oder ein Objekt gelöscht oder ersetzt wird.

Für einen sauberen Betrieb braucht jede Gruppenänderung einen Owner, eine Task-Referenz, einen lokalen Test und eine Rückfallentscheidung. Umfangreiche Änderungen werden zuerst auf einer Pilotfirewall oder Untergruppe geprüft. Audit Trail Logs und ein aktuelles Backup bleiben auch bei Central-Verwaltung notwendig.

Checkliste

Pilotfirewall und Management-Rückweg sind getestet.
Backup und Ausgangskonfiguration sind gesichert.
Use Sophos default oder Import existing configuration wurde bewusst gewählt.
Full Sync oder Skip full sync passt zum vorgesehenen Ownership-Modell.
Gruppenobjekte, Settings, Untergruppen und Abhängigkeiten sind geprüft.
Task Queue zeigt den erwarteten Status je Firewall.
Regelreihenfolge, Rule IDs und realer Traffic sind lokal abgenommen.
Rollback berücksichtigt, dass Central-Policies beim Entfernen aus der Gruppe erhalten bleiben.

FAQ

Ist Skip full sync eine dauerhafte Ausnahme von Gruppenänderungen?

Nein. Beim Zuweisen bleibt die bestehende Konfiguration zunächst erhalten, spätere Änderungen der Gruppenpolicy werden aber an die Firewall verteilt.

Setzt das Entfernen einer Firewall aus der Gruppe die Central-Änderungen zurück?

Nein. Bereits verteilte Policies bleiben auf der Firewall. Ein Rollback muss die betroffenen Regeln, Objekte und Settings ausdrücklich prüfen und kontrolliert zurückführen.