Sophos Fusion Endpoint-Richtlinien richtig aufbauen
Sophos Fusion (ehemals Sophos Central) wendet für jede Funktion genau eine passende Policy an. Sophos Fusion prüft die Liste von oben nach unten; die erste Policy, die aktiv ist und zum Benutzer oder Computer passt, gewinnt. Die Base Policy steht immer unten und fängt alle Ziele auf, die keine Policy darüber erfasst.
Damit ist auch die wichtigste Abgrenzung klar: Policies desselben Typs werden nicht zu einer wirksamen Konfiguration zusammengeführt. Dieser Grundlagenartikel erklärt deshalb Zuweisung, Scope und Reihenfolge. Die Einstellungen einzelner Policy-Typen behandeln die verlinkten Detailartikel.
Der vollständige Weg von der Planung bis zur Betriebsübergabe ist im Endpoint-Onboarding-Pfad beschrieben.
Das Modell in vier Regeln
- Eine Policy gehört zu genau einer lizenzierten Funktion, beispielsweise Threat Protection, Application Control oder Web Control.
- Eine Policy enthält alle Einstellungen dieser Funktion. Ein Endpoint bezieht nicht einzelne Schalter aus mehreren Policies desselben Typs.
- Der Scope entsteht durch die zugewiesenen Benutzer, Benutzergruppen, Computer oder Computergruppen. Welche Zielarten verfügbar sind, hängt vom Policy-Typ ab.
- Treffen mehrere aktive Policies desselben Typs zu, entscheidet ausschliesslich ihre Position: Die erste passende Policy wird angewendet.
Merksatz: Spezifische Policies nach oben, allgemeine Policies nach unten.
Das Wort «Vererbung» ist hier leicht missverständlich. Eine zusätzliche Policy übernimmt zur Laufzeit nicht einige Werte aus der Base Policy und ergänzt andere. Sie kann Einstellungen der Base Policy für ihren Scope überschreiben, wirksam ist für diesen Policy-Typ aber die vollständige erste passende Policy.
Base Policy und zusätzliche Policies
Sophos stellt für jede Funktion eine Base Policy bereit. Sie ist immer verfügbar, kann weder deaktiviert noch gelöscht werden und bleibt am Ende der Liste. Anfangs gilt sie für alle Benutzer und Geräte beziehungsweise – bei Server-Policies – für alle Server.
Bei Funktionen wie Threat Protection liefert Sophos die Base Policy mit Best-Practice-Einstellungen aus. Bei netzwerkspezifischen Funktionen wie Application Control oder Peripheral Control muss man die Funktion dagegen passend zur eigenen Umgebung konfigurieren.
Zusätzliche Policies sind nur nötig, wenn eine Zielgruppe andere Einstellungen erhalten soll. Für eine einheitliche Konfiguration kann die Base Policy allein ausreichen. Jede zusätzliche Policy erhöht jedoch die Zahl möglicher Überschneidungen; ihr Zweck und ihr Scope sollten daher eindeutig benannt sein.
Benutzer- oder Computer-Scope wählen
Eine Benutzer-Policy gilt auf allen verwalteten Geräten dieses Benutzers. Eine Computer-Policy gilt für bestimmte Computer oder Computergruppen, unabhängig davon, wer sich anmeldet. Einige Funktionen unterstützen beide Varianten, andere nur eine. Update Management kann Sophos zufolge beispielsweise für Computer, nicht aber für Benutzer konfiguriert werden.
| Anforderung | Passender Scope |
|---|---|
| gleiche Einstellung für einen Kiosk- oder Produktions-PC | Computer oder Computergruppe |
| Einstellung soll einer Person auf mehreren Geräten folgen | Benutzer oder Benutzergruppe |
| gestaffelte Endpoint-Updates | Computergruppe |
| eng begrenzter Sonderfall auf einem Gerät | einzelner Computer |
Passen eine Benutzer- und eine Computer-Policy derselben Funktion gleichzeitig, besitzt keine Zielart automatisch Vorrang. Auch dann entscheidet die Reihenfolge in der Policy-Liste.
Gruppen sind eine Zuweisungshilfe, keine zusätzliche Policy-Ebene. Auf der Registerkarte Policies einer Computergruppe sieht man die aktivierten und auf die Gruppe angewendeten Policies. Wird eine dort verlinkte Policy bearbeitet, betrifft die Änderung auch alle anderen Gruppen, denen dieselbe Policy zugewiesen ist.
Reihenfolge und Überschneidungen planen
Eine wartbare Reihenfolge beginnt mit dem kleinsten Scope und endet mit dem grössten. Ein einfaches Beispiel für drei aktive Threat-Protection-Policies:
| Position | Policy | Scope |
|---|---|---|
| 1 | TP-Finance-Exception | Finance-Computergruppe |
| 2 | TP-All-Workstations | alle Arbeitsplatzgeräte |
| 3 | Base Policy | alle übrigen Ziele |
Ein Finance-Notebook erhält Position 1. Ein anderes Arbeitsplatzgerät erhält Position 2. Würde TP-All-Workstations oben stehen, würde diese allgemeine Policy bereits passen und die Finance-Policy käme nicht zum Zug.
Avanet-Empfehlung: Die Base Policy bildet nach Möglichkeit den Produktionsstandard. Darüber liegen nur begründete Abweichungen, beispielsweise eine kleine Pilotgruppe oder eine eng begrenzte technische Ausnahme. Eine eigene Policy pro Abteilung ist nur sinnvoll, wenn sich die Einstellungen tatsächlich unterscheiden.
Policy erstellen und zuweisen
Unter fusion.sophos.com anmelden. Der offizielle Ablauf beginnt auf der Produktseite:
- My Products öffnen und Endpoint wählen.
- Policies öffnen und Add Policy wählen.
- Funktion und – falls angeboten – den Endpoint-Policy-Typ auswählen.
- Auf der Detailseite den vorgesehenen Benutzern oder Geräten zuweisen.
- Die Einstellungen des gewählten Policy-Typs konfigurieren.
- Die Policy aktivieren und speichern.
- In der Policy-Liste an die gewünschte Position ziehen.
Vor dem breiten Rollout wird eine neue Policy nur einer kleinen Pilotgruppe zugewiesen. Ein Name wie TP-Pilot-2026Q3 macht Funktion, Zweck und zeitlichen Kontext sichtbar. Die fachlichen Einstellungen selbst gehören in den jeweiligen Detailartikel, etwa zu Threat Protection, Application Control, Peripheral Control oder Web Control.
Die Data Collection and Investigation Policy zeigt das Scope-Prinzip besonders klar: Ihre Base Policy gilt standardmässig für alle Geräte. Sollen bestimmte Geräte abweichen, werden sie in einer Computergruppe gesammelt und einer zusätzlichen Policy zugewiesen. Die Einstellungen für Live Response, Data-Lake-Uploads oder Ausschlüsse werden hier bewusst nicht wiederholt.
Tatsächlich angewendete Policy kontrollieren
Zuordnung, Empfang und Wirkung sind drei verschiedene Nachweise. Die Registerkarte Policies zeigt die dem Gerät zugeordneten Richtlinien. Sie beweist allein noch nicht, wann eine einzelne Komponente ihre Konfiguration zuletzt erhalten hat. Für Windows-Endpoints und Windows-Server lässt sich dieser Empfang mit Endpoint Self Help (ESH) prüfen:
- My Environment > Computers & Servers öffnen. Alternativ My Products > Endpoint > Computers verwenden und den Computer öffnen.
- Unter Policies pro Funktion den zugeordneten Policy-Namen mit Scope und Priorität vergleichen.
- Auf dem Windows-Gerät Endpoint Self Help öffnen und die Ansicht Policy wählen. Dort den letzten Empfang je Komponente prüfen und mit der tatsächlich freigegebenen Änderung vergleichen.
- Nur wenn eine bereits genehmigte Änderung kontrolliert werden soll: diese in Sophos Fusion speichern (Save) und die ESH-Anzeige mit Refresh aktualisieren. Je nach Region kann die Übermittlung bis zu fünf Minuten dauern. Für den Nachweis keine zusätzliche Schutzausnahme anlegen.
- Danach die betreffende Schutzfunktion mit dem vorgesehenen, freigegebenen Funktionstest prüfen. Empfangene Konfiguration ist noch kein Beleg ihrer Wirkung.
Last Active ist ein MCS-Kommunikationsindikator und wird höchstens stündlich aktualisiert. Der Wert ist kein Zeitstempel für eine angewendete Policy. Ebenso ist Not since in ESH allein kein Fehler: Unveränderte Komponenten können ihre vorhandene Konfiguration und den bisherigen Zeitstempel behalten. Entscheidend ist, ob die konkret geänderte Komponente die erwartete Konfiguration erhalten hat. Eine unveränderte Policy muss nicht bei jedem Kontakt einen neuen Zeitstempel bekommen.
Mit einem Klick auf den Policy-Namen öffnet man ihre Details. Änderungen dort wirken auf alle zugewiesenen Benutzer oder Geräte. Daher erst Scope und Überschneidungen prüfen. Die Gruppensicht unter My Products > Endpoint > Computers > Computer Groups > Policies hilft bei der Zuordnung, ersetzt aber keinen Empfangsnachweis auf dem einzelnen Gerät.
Der ESH-Prüfweg gilt für Windows-Endpoints und Windows-Server. Für macOS wird ein eigener plattformspezifischer Nachweis benötigt. Die Policies-Registerkarte zeigt die Zuordnung; für den Empfang ist die betroffene Komponente in ESH massgeblich. Für die Abnahme werden Gerät, Policy-Typ und -Name, freigegebene Änderung mit Zeitpunkt, betroffene Komponente, ESH-Empfangsstand und Ergebnis des Funktionstests getrennt dokumentiert. Fehlt ein eindeutiger Empfangsnachweis, bleibt die Abnahme offen.
Wenn die erwartete Policy nicht erscheint
In dieser Reihenfolge prüfen:
- Policy-Typ: Gehören die verglichenen Policies zur selben Funktion?
- Aktivstatus: Ist die erwartete Policy aktiviert und noch nicht abgelaufen?
- Scope: Ist der Benutzer, Computer oder die richtige Gruppe tatsächlich zugewiesen?
- Reihenfolge: Passt eine allgemeinere Policy weiter oben bereits?
- Zuordnung: Welcher Policy-Name steht auf der Registerkarte Policies des Computers?
- Empfang: Zeigt ESH auf dem Windows-Gerät für die tatsächlich geänderte Komponente den erwarteten Empfang? Last Active oder ein unveränderter Policy-Name genügen nicht. Ohne eindeutigen Nachweis bleibt die Abnahme offen.
Ein Agent-Update korrigiert keine falsche Reihenfolge oder Zuweisung. Sind Zuordnung und Übernahme nachvollziehbar, aber der freigegebene Funktionstest schlägt fehl, gehört die weitere Untersuchung in die komponentenspezifische Endpoint-Diagnose. Fehlt der erwartete Empfang der geänderten Komponente, werden zuerst Gerätekontakt und Kommunikation geprüft, bevor man die Schutzkonfiguration ändert.