Sophos Central Endpoint-Richtlinien richtig aufbauen
Sophos Central kombiniert die Einstellungen verschiedener Policy-Typen nicht beliebig miteinander. Für jeden Typ, etwa Threat Protection, Web Control oder Update Management, sucht Central von oben nach unten und verwendet die erste aktive Policy, deren Zielgruppe zum Benutzer oder Gerät passt.
Diese einfache Regel erklärt viele vermeintliche Agent-Probleme: Die gewünschte Policy ist vorhanden, wird aber durch eine allgemeinere Policy weiter oben übergangen.
Das Policy-Modell
Für jede Funktion gibt es eine Base Policy. Sie steht immer am Ende, lässt sich nicht löschen oder deaktivieren und greift, wenn keine spezifischere Policy passt.
Zusätzliche Policies lassen sich dagegen löschen, aber nicht aus Sophos Central wiederherstellen. Vor dem Löschen werden Einstellungen, Zielgruppe, Reihenfolge und Ausnahmebegründung deshalb exportiert oder nachvollziehbar dokumentiert.
Zusätzliche Policies überschreiben die Base Policy für ihre Zielgruppe vollständig innerhalb dieses Policy-Typs. Einstellungen werden nicht aus mehreren Threat-Protection-Policies zusammengesetzt. Es gilt immer genau die erste passende Threat-Protection-Policy, die erste passende Web-Control-Policy und so weiter.
Merksatz: Spezifische Policies nach oben, allgemeine Policies nach unten.
Benutzer- oder Computer-Policy?
Eine Benutzer-Policy folgt dem Benutzer auf seine verwalteten Geräte. Eine Computer-Policy gilt für das Gerät, unabhängig davon, wer angemeldet ist. Nicht jeder Policy-Typ unterstützt beide Zielarten.
| Anforderung | Meist passende Zielart |
|---|---|
| gleicher Schutz für einen Kiosk oder Produktions-PC | Computer oder Computergruppe |
| Web-Regeln folgen einer Person auf mehrere Geräte | Benutzer oder Benutzergruppe |
| gestaffelte Softwareupdates | Computergruppe |
| kritischer Sonderfall auf einem Gerät | einzelner Computer, zeitlich begrenzt |
Wenn Benutzer- und Computer-Policy desselben Typs auf ein Gerät passen, entscheidet ebenfalls die Reihenfolge in der Liste. Die Zielart allein hat keinen automatischen Vorrang.
Eine wartbare Baseline
Ein gutes Modell braucht nur so viele Abweichungen wie betrieblich begründet sind:
- Base Policy: sichere Standardwerte für alle Geräte.
- Pilot: kleine, betreute Gruppe für neue Einstellungen und Softwarestufen.
- Production: nur wenn die Base Policy nicht bereits den Produktionsstandard bildet.
- Critical systems: klar dokumentierte Ausnahme für inkompatible oder besonders sensible Systeme.
- Temporary exception: befristete Problembehebung mit Besitzer und Ablaufdatum.
Eine eigene Policy pro Abteilung oder Einzelgerät erzeugt schnell Überschneidungen. Besser ist eine kleine Anzahl verständlicher Zielgruppen und ein dokumentierter Grund für jede Abweichung.
Neue Policy sicher einführen
Unter My Products > Endpoint > Policies wird der gewünschte Policy-Typ gewählt. Danach folgt ein kontrollierter Ablauf:
- Zweck und messbares Ziel festlegen.
- Bestehende Base Policy und höhere Policies vergleichen.
- Neue Policy mit sprechendem Namen erstellen.
- Nur die Pilotgruppe zuweisen.
- Policy aktivieren und an die richtige Position verschieben.
- Auf einem Pilotgerät die Registerkarte Policies prüfen.
- Events, Alerts, Benutzerwirkung und Performance beobachten.
- Erst danach die Zielgruppe erweitern.
Ein Name wie TP-Pilot-HTTPS-Decrypt-2026Q3 ist nützlicher als Neue Policy 2. Er zeigt Funktion, Zweck und Gültigkeitskontext.
Reihenfolge mit einem Beispiel
Angenommen, drei Threat-Protection-Policies sind aktiv:
| Position | Policy | Zielgruppe |
|---|---|---|
| 1 | TP-Finance-Exception | Finance-Gruppe |
| 2 | TP-All-Workstations | alle Arbeitsplatzgeräte |
| 3 | Base Policy | alle übrigen |
Ein Finance-Notebook erhält Position 1. Ein anderes Arbeitsplatzgerät erhält Position 2. Die Base Policy greift nur für Geräte, die von beiden Policies nicht erfasst werden.
Würde TP-All-Workstations an Position 1 stehen, käme die Finance-Ausnahme nie zum Zug.
Effektive Policy am Gerät kontrollieren
Die Konfiguration wird nicht nur in der Policy-Liste geprüft:
- My Environment > Computers & Servers öffnen.
- Gerät auswählen.
- Registerkarte Policies öffnen.
- Pro Policy-Typ den angewendeten Namen kontrollieren.
- Zeitpunkt der letzten Aktivität beachten.
Ein Offline-Gerät übernimmt eine neue Zuweisung erst beim nächsten Kontakt. Bei Benutzer-Policies muss zusätzlich der zuletzt angemeldete Benutzer stimmen.
Policy-Empfang statt nur Zuweisung prüfen
Die Zuweisung in Central beschreibt den Sollzustand. Damit eine Policy wirksam wird, muss das Management Communication System, kurz MCS, auf dem Endpoint installiert und funktionsfähig sein. Last Active ist dafür ein nützlicher Indikator, wird laut Sophos aber höchstens einmal pro Stunde aktualisiert.
Neue Policies und Kommandos wie Update, Scan oder Cleanup werden normalerweise innerhalb weniger Sekunden bis Minuten abgeholt. In seltenen Fällen kann es länger als 15 Minuten dauern. Eine Benutzer-Policy wird zudem erst nach der korrekten Zuordnung des interaktiv angemeldeten Kontos aktualisiert. Bis dahin kann noch die Policy des vorherigen Benutzers gelten.
Bei einer Benutzer-Policy werden deshalb drei Identitäten verglichen:
- das lokal angemeldete Konto, etwa
domain1\user1, - die Zuordnung dieses Kontos zum richtigen Central-Benutzer,
- der Benutzer, den der MCS Client als interaktiv angemeldet erkannt hat.
Endpoint Self Help zeigt unter Policy, ob die einzelnen Komponenten ihre Policy erhalten haben. Für Windows ordnen McsClient.log und McsAgent.log Kommunikations- beziehungsweise Verarbeitungsfehler zeitlich zu. Die Logpfade beschreibt Sophos Endpoint Windows-Logs und Dienste richtig auswerten.
Policy non-compliance ist komponentenspezifisch
Ein Alert zu Policy non-compliance bedeutet nicht automatisch, dass die gesamte Endpoint-Policy fehlt. Der Alert nennt die Komponente, die ihren Sollzustand nicht erreicht hat. Genau diese Komponente wird in Endpoint Self Help, im lokalen Status und im passenden Komponentenlog untersucht. Erst danach wird das Gerät neu gestartet und erneut geprüft. Kehrt der Alert zurück, folgt die komponentenspezifische Reparatur statt wiederholter Neustarts oder einer pauschalen Neuinstallation.
Je nach Notification-Konfiguration erhalten Administratoren dasselbe Ereignis zusätzlich per E-Mail. Mehrere Meldungen zum gleichen Gerät werden deshalb anhand von Zeit, Policy-Typ und Komponente zusammengeführt, bevor daraus mehrere unabhängige Störungen abgeleitet werden.
Base Policy und Sophos-Empfehlungen
Sophos liefert insbesondere für Threat Protection empfohlene Grundeinstellungen. Der Account Health Check vergleicht Policies und Gerätezustände mit diesen Empfehlungen.
Fix automatically kann empfohlene Werte anwenden. Diese Funktion sollte wie jede Massenänderung behandelt werden: betroffene Policies prüfen, Änderung im Audit Log nachvollziehen und geschäftskritische Ausnahmen vorher dokumentieren. Ein grüner Score ist nützlich, aber nicht wichtiger als eine bewusst begründete und kompensierte Ausnahme.
Zeitlich begrenzte Ausnahmen
Jede Ausnahme braucht mindestens eine verantwortliche Person, die betroffenen Geräte, einen technischen Grund, die Sicherheitsauswirkung, eine kompensierende Massnahme und ein Ablaufdatum.
Wo möglich, wird eine Ausnahme direkt in einer spezifischen Policy statt global umgesetzt. Für Scan-Ausnahmen beschreibt Sophos Central Endpoint-Ausnahmen sicher konfigurieren die Unterschiede.
Einstellungen einer Policy im Bypass Mode prüfen
Im Policy bypass mode blendet Sophos Central die Policy-Einstellungen aus. Das ist erwartetes Verhalten. Für eine reine Prüfung wird zuerst sichergestellt, dass der Policy keine Geräte oder Benutzer zugewiesen sind. Danach aktiviert man Policy is Active, ohne die Änderung zu speichern. Die Felder werden dadurch sichtbar, während der gespeicherte Bypass-Zustand bestehen bleibt.
Die Seite wird anschliessend ohne Speichern verlassen. Eine zugewiesene Bypass-Policy wird für diese Sichtprüfung nicht temporär aktiviert, weil ein versehentliches Speichern die Einstellungen wieder erzwingen könnte.
Typische Fehler
Richtige Policy existiert, wird aber nicht angewendet
Reihenfolge, Zielgruppe, Aktivstatus und Ablaufdatum werden geprüft. Danach folgt die effektive Policy im Gerätedatensatz. Ein manuelles Agent-Update ändert keine falsche Policy-Priorität.
Ein einzelner Schalter scheint ignoriert zu werden
Eine Policy wird als Ganzes gewählt. Der Schalter kann aus einer anderen, höher priorisierten Policy stammen als erwartet. Zusätzlich können Partner- oder Enterprise-Vorgaben Einstellungen sperren.
Benutzer erhalten auf demselben Computer unterschiedliche Regeln
Das kann bei Benutzer-Policies beabsichtigt sein. Für gemeinsam genutzte oder unbeaufsichtigte Systeme ist eine Computer-Policy meist leichter vorhersehbar.
Nach einer Änderung entstehen viele Alerts
Rollout stoppen, Pilotumfang wiederherstellen und Alert-Typ sowie betroffene Plattform prüfen. Die Policy wird nicht global abgeschwächt, bevor die tatsächliche Inkompatibilität bekannt ist.