Sophos Fusion Endpoint-Geräte und Gruppen verwalten

Computergruppen geben Endpoint-Policies ein stabiles Ziel. Sie beantworten aber nicht jede Inventar- oder Identitätsfrage: Tags und allgemeine Geräteaktionen gehören zur gemeinsamen Central-Plattform, Benutzergruppen zu einem eigenen Identitätsmodell.

Schnellablauf: Gruppenmodell festlegen, unter My Products > Endpoint > Computers > Computer Groups eine Gruppe erstellen, Computer zuweisen und danach am Gruppen- sowie Computerobjekt die tatsächlich angewendeten Policies prüfen. Vor dem Löschen, Bereinigen oder Migrieren wird der Lifecycle separat geklärt.

Wichtig: Ein Computer kann nur einer Computergruppe angehören. Tags ergänzen mehrere flexible Merkmale; Agent Mode beschreibt den Softwareumfang. Diese Ebenen dürfen nicht als austauschbar behandelt werden.

Endpoint-Gruppen von Plattformfunktionen abgrenzen

Die gemeinsame Ansicht My Environment > Computers & Servers ist die richtige Grundlage für Filter, Spalten, Tags, Tamper Protection, Softwareumfang, Health Reset und allgemeines Löschen. Der Ablauf steht im Plattformartikel Sophos Fusion Geräteinventar verwalten; hier werden diese Funktionen nicht doppelt beschrieben.

Sophos ersetzt die ältere Seite My Products > Endpoint > Computers durch diese gemeinsame Ansicht. Während der Umstellung kann im Tenant weiterhin die ältere Seite erscheinen; sie bleibt außerdem der Weg zu Computer Groups. Die folgenden Gruppenabläufe verwenden deshalb diesen Pfad.

Benutzer, Logins und Benutzergruppen sind ebenfalls eigenständige Objekte. Ob eine Policy einer Person oder einem Gerät folgen soll und wie die Reihenfolge bei mehreren passenden Policies wirkt, erklärt Sophos Fusion Endpoint Benutzer und Gruppen richtig zuordnen. Dieser Artikel konzentriert sich auf Computergruppen und ihren Endpoint-Lifecycle.

Gruppenmodell vor dem Rollout festlegen

Computergruppen eignen sich für stabile organisatorische Grenzen. Ein praxistaugliches Modell richtet sich nach tatsächlich unterschiedlichen Schutzanforderungen, beispielsweise:

• Pilotgeräte
• Standard-Arbeitsplätze
• besonders kritische Arbeitsplätze
• Kiosk- oder Produktionssysteme
• virtuelle, nicht persistente Desktops

Abteilungen sind nur dann gute Gruppen, wenn sie wirklich andere Policies benötigen. Eine tiefe Nachbildung des Organigramms macht Zuweisungen oft unübersichtlich, ohne die Sicherheit zu verbessern.

So wird eine Gruppe erstellt:

1. My Products > Endpoint > Computers öffnen und Computer Groups wählen.
2. Add Computer Group anklicken.
3. Einen eindeutigen Namen und eine kurze Beschreibung eintragen.
4. Unter den verfügbaren Computern nur die vorgesehenen Geräte zuweisen und speichern.

Ein bereits gruppierter Computer wird bei einer neuen Zuweisung aus seiner bisherigen Gruppe entfernt. Für eine bestehende Gruppe öffnet man deren Namen, wählt im linken Bereich Edit, passt Assigned Computers an und speichert. Delete entfernt nur die Gruppe, nicht ihre Computer. Vor einer Massenänderung werden deshalb alte und neue Mitgliedschaft dokumentiert und zuerst wenige Pilotgeräte verschoben.

Tags für flexible Merkmale nutzen

Tags ergänzen die feste Gruppe um mehrere frei kombinierbare Eigenschaften, etwa owner=finance, site=zuerich, criticality=high oder lifecycle=pilot. Ein Gerät kann höchstens 15 Tags besitzen; bis zu fünf Tags lassen sich in der gemeinsamen Geräteliste anpinnen.

Tags helfen bei Filtern und Arbeitslisten, steuern aber keine Gruppenmitgliedschaft. Wenn dieselbe Information gleichzeitig in Gerätenamen, Gruppen und mehreren Tags steckt, entstehen widersprüchliche Daten. Erstellung, Prüfung und Entfernung von Tags beschreibt das verlinkte Central-Geräteinventar.

Richtlinienzuweisung prüfen

Eine Gruppe ist erst dann fachlich fertig, wenn ihre Policy-Wirkung kontrolliert wurde:

1. Unter My Products > Endpoint > Computers > Computer Groups den Gruppennamen öffnen.
2. Policies wählen und die aktivierten, angewendeten Policies prüfen.
3. Bei Bedarf einen Policy-Namen öffnen. Eine Änderung wirkt auf alle Benutzer und Gruppen, denen diese Policy zugewiesen ist; deshalb Zielumfang und Policy-Reihenfolge vor dem Speichern kontrollieren.
4. Ein Pilotgerät unter My Environment > Computers & Servers öffnen und auf Policies die effektiv angewendete Policy jedes Typs vergleichen.
5. Abweichungen über Zielzuweisung und Reihenfolge korrigieren und nach dem nächsten Central-Kontakt erneut prüfen.

Die Zielart besitzt keinen automatischen Vorrang: Treffen Benutzer- und Computer-Policies desselben Typs zu, entscheidet ihre Reihenfolge. Das vollständige Prioritätsmodell erklärt Sophos Fusion Endpoint-Richtlinien richtig aufbauen.

Agent Mode und Gerätezustand einordnen

Endpoint, XDR und XDR Sensor beschreiben unterschiedliche Softwareumfänge; XDR Sensor enthält keinen Sophos Malware-Schutz. Im Computerobjekt zeigen Summary den zugewiesenen Umfang und die Gruppe, Status die einzelnen Health-Bewertungen und Policies die effektiven Policies. Welche Spalten, Filter und Softwareaktionen in der gemeinsamen Geräteansicht verfügbar sind, steht im Central-Geräteinventar.

Inaktive Geräte untersuchen

Ein inaktiver Datensatz ist zunächst ein Signal, kein Löschauftrag. Vor dem Entfernen wird geklärt, warum der Kontakt fehlt:

• Gerät ist ausser Betrieb oder ersetzt.
• Benutzer ist länger abwesend.
• Agent, Proxy oder Netzwerkverbindung ist gestört.
• Computer wurde aus einem alten Image geklont.
• Gerät gehört zu einem Lab, einer VDI-Umgebung oder einem Update Cache.

Die neue gemeinsame Geräteansicht zeigt auch Geräte, die länger als 30 Tage inaktiv sind. In älteren Endpoint-Listen muss dafür gegebenenfalls der Filter Not online recently gesetzt werden.

Last Active wird im Mittel nur einmal pro Stunde aktualisiert. Ein Event kann deshalb einen neueren Zeitstempel besitzen als der sichtbare Last-Active-Wert. Das ist nicht automatisch ein Datenfehler.

Dasselbe verzögerte Aktualisierungsmodell gilt für Online und Last Activity. Nach einer neuen Benutzeranmeldung kann Sophos Fusion (ehemals Sophos Central) das Gerät deshalb bereits dem neuen Benutzer zuordnen, während die Zeitstempel noch bis zu ungefähr einer Stunde den alten Stand zeigen. Ist das Gerät danach offline, dauert die Korrektur entsprechend länger.

Im Computer Report bedeuten Online und Last User zudem nicht dasselbe: Online basiert auf der zuletzt verarbeiteten Statusmeldung. Last User ändert sich erst, wenn sich ein anderes eindeutiges Benutzerkonto erstmals am Gerät anmeldet. Ein sehr alter Last-User-Wert beweist deshalb nicht, dass der Endpoint seit diesem Datum offline ist.

Automatische Bereinigung

Unter Global Settings > Products and Services > Endpoint and Server > Removal of Inactive Devices lassen sich Regeln getrennt für Endpoints und Server erstellen.

Sophos unterscheidet Targeted rules für ausgewählte Gruppen und eine Global rule für alle übrigen Geräte. Die globale Frist muss länger sein als die Fristen gezielter Regeln. Geräte wie Update Caches, Message Relays oder selten gestartete Spezialcomputer gehören in ausdrücklich ausgenommene Gruppen.

Es können zwei gezielte Regeln erstellt werden. Von der globalen Regel lassen sich höchstens vier Gruppen ausnehmen; Untergruppen zählen separat und werden nicht automatisch mitausgenommen. Sophos prüft die Regeln täglich um Mitternacht der Tenant-Datenregion.

MSP- und Marketplace-Kunden müssen für eine Regel mindestens 31 inaktive Tage wählen. Für mit --nonpersistent erzeugte VDI-Klone kann Permanently remove VDI desktops aktiviert werden; diese Geräte lassen sich anschliessend nicht wiederherstellen. Der Gold-Image-Master selbst wird nicht durch solche Regeln entfernt.

Entfernte Geräte bleiben 120 Tage im Recovery-Report. Während der ersten 30 Tage können sie wiederhergestellt werden. Update Cache und Message Relay werden dabei nicht wiederhergestellt.

Entfernen ist keine lokale Deinstallation: Eine automatische Bereinigung entfernt den Datensatz aus Central, nicht die lokal verbliebene Sophos-Software. Vor dem Aktivieren einer Regel muss deshalb feststehen, wie diese Geräte vollständig zurückgebaut werden.

Bereinigung und allgemeines Löschen unterscheiden

Eine automatische Removal-Regel entfernt inaktive Geräte aus der Verwaltung, deinstalliert die lokal verbliebene Sophos-Software aber nicht. Delete und Lizenzablauf lösen auf unterstützten aktuellen Windows-Systemen ab Core Agent 2023.2 dagegen einen dokumentierten Back-off aus: Tamper Protection und Schutzkomponenten werden entfernt, der Sophos Endpoint Agent bleibt für einen vollständigen lokalen Rückbau dennoch zu deinstallieren. Diese Abläufe werden nicht vermischt.

Recovery Report und Tamper-Protection-Passwort bleiben 120 Tage verfügbar; wiederherstellen lässt sich ein entferntes Gerät während der ersten 30 Tage. Update Cache und Message Relay werden dabei nicht wiederhergestellt. Den kontrollierten Windows-Rückbau erklärt Sophos Fusion Endpoint unter Windows deinstallieren. Allgemeine Delete- und Health-Reset-Schritte stehen im Central-Geräteinventar.

Geräte nicht mit Gruppenwechseln verwechseln

Change group verschiebt ein Computerobjekt innerhalb desselben Tenants. Ein Wechsel in einen anderen Central-Tenant ist dagegen eine API-basierte Device Migration mit eigenem Empfangs- und Sendeauftrag. Geräte können bis zu 14 Tage in der Warteschlange bleiben; dauerhaft offline Geräte müssen danach erneut eingereiht werden. Der vollständige, pilotierte Ablauf steht in Sophos Endpoint Geräte zwischen Central-Tenants migrieren.

Doppelte Geräte richtig behandeln

Jede Sophos-Installation erhält bei der Registrierung eine eindeutige Geräte-ID. Wird ein bereits registriertes System unbereinigt geklont, können mehrere Endpoints dieselbe ID verwenden. In Sophos Fusion ist dann zunächst nur ein gemeinsam überschriebenes Geräteobjekt sichtbar. Die automatische Duplicate Detection erkennt dieses Muster unter Windows, macOS und Linux, registriert die betroffenen Geräte neu und erzeugt dadurch zusätzliche Objekte.

Das neu registrierte Gerät übernimmt Gruppe, Policies und Produktzuweisung des ursprünglichen Objekts. Diese Werte werden nach der Deduplication trotzdem kontrolliert, denn die geerbte Zuordnung muss nicht für jeden Klon fachlich richtig sein.

Central meldet das Muster an drei Stellen: Im Dashboard erscheint der Alert Duplicate device detection, im Tab Events des Geräts stehen Device has been detected as a duplicate device und nach der Neuregistrierung Device has been de-duplicated from: <DEVICENAME>. Administratoren erhalten zusätzlich eine E-Mail mit dem Betreff [Medium] Alert for Sophos Central: We’ve detected a cloned device.

Ein Alert wie Device has been detected as a duplicate device ist deshalb kein Auftrag, sofort den markierten Datensatz zu löschen. Das ursprüngliche Objekt kann noch von weiteren Klonen mit derselben ID benötigt werden. Wird es zu früh entfernt, können diese Geräte nicht mehr mit Sophos Fusion kommunizieren und müssen neu installiert werden. Sophos empfiehlt, das markierte Ursprungsobjekt mindestens zwei Wochen stehen zu lassen, sofern nicht zweifelsfrei alle betroffenen Systeme ermittelt wurden.

Central zeigt beim Löschen dieses Ursprungsdatensatzes deshalb eine zusätzliche Bestätigungs-Checkbox. Sie wird erst gewählt und die Löschung erst fortgesetzt, wenn kein weiteres Gerät mehr mit der zur Deduplication markierten ID zu kommunizieren versucht.

Ein sicherer Ablauf sieht so aus:

1. Alert und Events des betroffenen Geräts prüfen.
2. Nach dem Gerätenamen suchen und aktive sowie ältere Datensätze anhand von Last Active vergleichen.
3. Beim neu registrierten Objekt Gruppe, Policies und Produktzuweisung kontrollieren.
4. Ursache im Deployment, Gold Image oder Snapshot beseitigen.
5. Erst löschen, wenn alle Systeme mit der alten ID bekannt sind und keines mehr darüber kommuniziert.

Bei nicht persistenten VDI-Umgebungen kann jeder neue Klon oder jede Rückkehr auf einen Snapshot eine erneute Registrierung auslösen. Zusätzliche Objekte sind dann nicht zwingend ein neuer Deduplication-Fehler. Das Gold Image muss mit dem unterstützten Verfahren vorbereitet werden, das im Artikel Sophos Fusion Endpoint für VDI und Gold Images bereitstellen beschrieben ist.

Auch bei einem korrekt vorbereiteten Image erzeugt jede neu erstellte VM erwartungsgemäss ein neues Central-Geräteobjekt; das Zurücksetzen einer bestehenden VM auf einen Snapshot sollte nach der unterstützten Vorbereitung dagegen keine Deduplication auslösen. Diese Vorbereitung ist vor jedem neuen oder aktualisierten Gold Image auszuführen. Andernfalls kann sich das Image erneut registrieren, eine ID erhalten und diese gemeinsame ID an alle nachfolgenden Klone weitergeben.

Auch AWS-Instanzen und Azure-VMs durchlaufen diese Erkennung. Ihr Instanz- beziehungsweise VM-Datensatz kann vorübergehend noch nicht mit dem Serverdatensatz verknüpft sein; Central behandelt das Gerät in dieser Zeit als normalen Server. Die Registrierung verknüpft es später mit einem neuen Serverdatensatz. Windows Server mit aktivem Server Lockdown sind von der Deduplication ausgeschlossen. Geräte mit derselben ID, aber unterschiedlichen Betriebssystemen werden zwar als Duplikate erkannt, jedoch nicht automatisch neu registriert. Wiederkehrende Alerts werden deshalb nicht durch fortlaufendes Löschen kaschiert, sondern über die Image- und Registrierungsursache behoben.

Wichtig: Eine versehentliche Löschung des gemeinsam verwendeten Ursprungsobjekts lässt sich für nicht mehr kommunizierende Klone nicht über Central reparieren. In diesem Fall bleibt nur die Neuinstallation des Sophos Agents.

Neustarts richtig interpretieren

Eine Erstinstallation oder die Entfernung eines Konkurrenzprodukts kann einen Neustart verlangen. Produktupdates benötigen ihn häufig nicht sofort. Wurde ein Gerät jedoch monatelang nicht neu gestartet, können zwei Updatezustände nacheinander je einen Neustart erfordern. Sophos empfiehlt in diesem Fall etwa 20 Minuten zwischen den beiden Neustartzyklen, damit das erste Update vollständig abgeschlossen wird.

Alte Windows- und macOS-Alerts werden nach 90 Tagen aus der Detailansicht entfernt. Ein roter Health State kann trotzdem verbleiben, bis die Ursache behoben und der Zustand zurückgesetzt wird. Der fehlende alte Alert allein beweist keine Reparatur.

Monatliche Betriebskontrolle

Ein kurzer monatlicher Check verhindert, dass sich blinde Flecken ansammeln:

1. Geräte ohne aktuelle Aktivität filtern und Besitzer klären.
2. Health-Probleme nach Ursache statt nur nach Farbe bearbeiten.
3. Product unassigned, Upgrade available und nicht unterstützte Geräte prüfen.
4. Tamper Protection mit Status Off begründen und korrigieren.
5. Computer ohne Gruppe oder mit falschen Tags bereinigen.
6. Update Caches, Message Relays und VDI-Gold-Images von Löschregeln ausnehmen.
7. Nicht mehr benötigte Geräte kontrolliert deinstallieren und danach löschen.

Häufige Fragen