FileVault mit Sophos Fusion verwalten

Sophos Fusion Device Encryption verwaltet Apples FileVault und den persönlichen Recovery Key. Die Verschlüsselung, die Benutzerberechtigung am Pre-Boot und das Entsperren des Startvolumes bleiben Funktionen von macOS. Ein Mac ist deshalb erst fertig ausgerollt, wenn Policy, lokaler FileVault-Zustand, berechtigte Benutzer und ein tatsächlich verfügbarer Recovery Key zusammenpassen.

Schnellablauf

1. Unterstützte macOS- und Sophos-Version, APFS-Volumes sowie den bestehenden FileVault- und Managementzustand prüfen.
2. Sicherstellen, dass der aktivierende lokale Benutzer einen Secure Token besitzt. Auf einem Mac mit Apple-Chip muss er zusätzlich Volume Owner sein.
3. Sophos Endpoint und den Device Encryption Agent installieren.
4. Unter My Products > Encryption > Policies eine Device-Encryption-Policy erstellen, Device Encryption is on aktivieren und sie allen vorgesehenen Benutzern des Macs zuweisen.
5. Den Benutzer lokal anmelden lassen. Im Sophos-Dialog startet Encrypt eine neue Verschlüsselung; bei bereits aktivem FileVault erzeugt Create key einen neuen, von Sophos verwalteten persönlichen Recovery Key.
6. Lokal und unter My Products > Encryption > Computers prüfen: erwartete Volumes verschlüsselt, vorgesehene Konten am Pre-Boot berechtigt, Synchronisation aktuell und Recovery Key in Sophos Fusion verfügbar.

Eine zugewiesene Policy oder ein lokal angezeigtes «FileVault: On» genügt nicht als Abnahme. Ein verschlüsseltes Volume ohne belastbaren Recovery-Weg bleibt ein offener Sicherheits- und Betriebsfall.

Voraussetzungen vor der ersten Zuweisung

Unterstützte Plattform und Agenten

Unterstützte macOS- und Sophos-Versionen ändern sich. Vor Pilot und breitem Rollout wird deshalb der aktuelle Stand gemäss Sophos Endpoint Systemanforderungen und Lifecycle planen geprüft. Auf dem Mac müssen Sophos Endpoint und der separate Device Encryption Agent installiert sein.

Sophos verwaltet das APFS-Startvolume und – sofern die Policy dies vorsieht – feste interne Datenvolumes. Wechselmedien und mit Boot Camp erstellte Windows-Partitionen werden nicht unterstützt. Vor der Zuweisung werden daher mit Disk Utility oder diskutil apfs list alle internen Volumes inventarisiert. So ist klar, welche Volumes geschützt werden sollen und ob ein zusätzliches Volume bereits ein eigenes Datenträgerkennwort besitzt.

Secure Token und Volume Owner verstehen

Ein FileVault-Benutzer benötigt die passende Apple-Berechtigung, nicht nur ein lokales Konto:

• Der Benutzer, der FileVault aktiviert oder ein Startvolume am Pre-Boot entsperrt, braucht einen Secure Token.
• Auf Macs mit Apple-Chip muss ein Benutzer zusätzlich Volume Owner sein, um das Startvolume zu entsperren und sicherheitsrelevante Startvorgänge zu autorisieren.
• Ein Administratorname oder eine Policy-Zuweisung erteilt diese Apple-Berechtigungen nicht automatisch.

Die Zusammenhänge beschreibt Apple in Manage FileVault with device management. Für einen lokalen, lesenden Vorabcheck können folgende Befehle im Terminal verwendet werden:

sysadminctl -secureTokenStatus <KURZNAME>
diskutil apfs listUsers /

<KURZNAME> wird durch den lokalen Accountnamen ersetzt. Der erste Befehl muss für den aktivierenden Benutzer einen aktivierten Secure Token melden. Die APFS-Benutzerliste wird mit den lokal vorgesehenen FileVault-Benutzern abgeglichen; auf Apple-Chip-Macs wird die Volume-Owner-Berechtigung zusätzlich über den in der Organisation freigegebenen Apple- beziehungsweise MDM-Prüfweg bestätigt. Fehlt eine Berechtigung, wird sie vor dem Rollout mit dem bestehenden Apple-Administrationsprozess korrigiert – nicht durch wiederholtes Ein- und Ausschalten der Sophos-Policy.

Management- und Recovery-Verantwortung klären

Vor der Umstellung werden der aktuelle FileVault-Status, vorhandene persönliche Recovery Keys, berechtigte Pre-Boot-Benutzer und die bisherige Verwaltung dokumentiert. Zwei Systeme dürfen nicht gleichzeitig widersprüchliche FileVault-Vorgaben erzwingen. Wenn ein MDM oder ein älteres Verschlüsselungsprodukt beteiligt ist, müssen Zielzustand und Key-Verantwortung vor der Änderung feststehen.

Der gemeinsame Helpdesk-Prozess für Abruf, Ausgabe und Dokumentation steht unter Wiederherstellungsschlüssel sicher abrufen. Eine Sicherung des FileVault-Recovery-Keys im iCloud-Schlüsselbund wird von Sophos nicht empfohlen.

Eine repräsentative Pilotgruppe umfasst mindestens Intel- und Apple-Chip-Varianten, die tatsächlich eingesetzten Registrierungsarten, einen neuen Mac, einen Mac mit bereits aktivem FileVault und – falls vorhanden – einen Mac mit zusätzlichen internen APFS-Volumes.

Policy erstellen und zuweisen

Der dokumentierte Central-Pfad lautet My Products > Encryption > Policies:

1. Add Policy wählen und eine Device-Encryption-Policy erstellen.
2. Auf der Registerkarte Settings die Option Device Encryption is on aktivieren.
3. Entscheiden, ob Encrypt boot volume only verwendet wird. Ist die Option aktiv, ignoriert die Policy feste interne Datenvolumes. Andernfalls kann Sophos diese Volumes nach dem Startvolume ebenfalls verwalten.
4. Die Policy einschalten und den vorgesehenen Benutzern zuweisen.

Die Zuweisung ist benutzerbasiert. Sophos empfiehlt, die Policy allen Benutzern eines bestimmten Macs zuzuweisen. Das verhindert, dass ein gemeinsam verwendeter Mac nur wegen einer unvollständigen Zuweisung ausserhalb des gewünschten Schutzumfangs bleibt. Die tatsächliche Pre-Boot-Berechtigung wird trotzdem separat geprüft; Policy-Zuweisung und FileVault-Benutzerstatus sind nicht dasselbe.

Wird die Policy ausgeschaltet oder entfernt, führt Sophos keine neue Ver- oder Entschlüsselungsaktion aus. Ein bereits aktiviertes FileVault bleibt aktiv. Ein früher erfolgreich an Sophos Fusion übertragener Recovery Key kann weiterhin abrufbar sein; daraus darf man aber weder aktuelle Key-Escrow-Fähigkeit noch die Übernahme späterer Key-Änderungen ableiten. «Policy aus, FileVault an» ist daher kein sauber nachgewiesener, zentral verwalteter Zielzustand.

Einen neuen Mac verschlüsseln

Nach lokaler Anmeldung und erfolgreicher Synchronisation zeigt Sophos den Aktivierungsdialog:

1. Der Benutzer gibt sein macOS-Anmeldekennwort ein. Damit autorisiert er Sophos Device Encryption im Kontext seines lokalen Accounts.
2. Mit Encrypt startet er die Verschlüsselung. Postpone verschiebt den Start nur; der Mac ist damit noch nicht abgenommen.
3. Der Agent speichert den persönlichen Recovery Key im lokalen Schlüsselbund und überträgt ihn an Sophos Fusion.

Beim ersten Rollout fügt Sophos die bereits vorhandenen berechtigten Benutzer des Endpoints zu FileVault hinzu. Wenn Encrypt boot volume only nicht aktiviert ist, folgen nach dem Startvolume die unverschlüsselten festen internen Datenvolumes. Statusmeldungen zeigen den Fortschritt pro Volume.

Der Benutzer muss für Aktivierung und Migration lokal am Mac angemeldet sein. Eine reine Remote-Anmeldung reicht nicht. Wird kein Dialog angezeigt, werden zuerst lokale Sitzung, Policy-Zuweisung, letzte Synchronisation, Secure Token und auf Apple-Chip-Macs der Volume-Owner-Status geprüft.

Bestehendes FileVault oder SafeGuard übernehmen

Bereits aktives FileVault

Ein bereits verschlüsselter Mac muss für die Übernahme durch Sophos nicht zuerst entschlüsselt werden:

1. Ausgangszustand, vorhandenen Recovery-Weg und Pre-Boot-Benutzer dokumentieren.
2. Device Encryption Agent installieren und die aktive Policy zuweisen.
3. Einen berechtigten Benutzer lokal anmelden lassen.
4. Im Sophos-Dialog das macOS-Anmeldekennwort eingeben und Create key wählen.
5. Warten, bis Sophos einen neuen persönlichen Recovery Key erzeugt und an Fusion übertragen hat.
6. Erst nachdem lokaler Status und Central-Nachweis stimmen, den bisherigen Recovery-Weg gemäss dem eigenen Aufbewahrungsprozess ausser Betrieb nehmen.

Ein bereits verschlüsseltes internes Datenvolume mit eigenem Datenträgerkennwort verlangt dieses Kennwort einmalig. Danach kann Sophos das Volume verwalten und beim Start automatisch entsperren. Ist das Kennwort unbekannt, wird die Übernahme dieses Volumes gestoppt; eine funktionierende Anmeldung am Startvolume beweist nicht, dass auch das Datenvolume wiederherstellbar ist.

SafeGuard-Ausgangszustand

Bei einem SafeGuard-Mac werden zuerst Produkt, Version, installierte Module, FileVault-Zustand und vorhandener Recovery-Weg eindeutig erfasst. Die Sophos-Migrationsanleitung verlangt, die SafeGuard-Device-Encryption-Software vor der Übernahme zu entfernen; für SafeGuard Enterprise 8 oder neuer beschreibt sie eine Übernahme, bei der FileVault verschlüsselt bleiben kann.

Historische SafeGuard-Release-Notes sind jedoch kein Nachweis für den heutigen Support eines weiterbetriebenen oder neu installierten SafeGuard-Moduls. Bei unbekannter Version, gemischten Modulen oder dem Plan, ein SafeGuard-Dateiverschlüsselungsmodul weiterzuverwenden, wird die Migration gestoppt und die konkrete Kombination mit einer aktuellen Sophos-Support-Aussage geklärt. Der sichere Grundsatz bleibt: nie zwei Manager gleichzeitig FileVault oder dessen Recovery Key steuern lassen, und den alten Recovery-Weg erst nach bestätigtem neuem Key aufgeben.

Weitere FileVault-Benutzer autorisieren

Wer den Mac am Pre-Boot entsperren soll, muss als FileVault-Benutzer autorisiert sein. Werden neue Benutzer nicht automatisch hinzugefügt, beschreibt Sophos folgenden Ablauf:

1. Der neue Benutzer meldet sich lokal an, gibt im Sophos-Dialog sein macOS-Anmeldekennwort ein und wählt Proceed.
2. Ist noch kein Recovery Key in Fusion gespeichert, wählt er zusätzlich einen bereits autorisierten FileVault-Benutzer aus.
3. Dieser vorhandene Benutzer gibt sein eigenes macOS-Anmeldekennwort ein und wählt Proceed.
4. Nach einem Neustart wird geprüft, ob sich der neue Benutzer am FileVault-Pre-Boot anmelden kann.

Ein fehlender Secure Token oder – auf Apple-Chip-Macs – fehlender Volume-Owner-Status lässt sich nicht durch die Anmeldedaten eines beliebigen Administrators ersetzen. In diesem Fall wird zuerst die Apple-Berechtigung korrigiert und danach der Sophos-Ablauf wiederholt.

Das Entfernen eines Benutzers aus der Central-Policy entfernt ihn laut Sophos nicht automatisch aus FileVault. Auf gemeinsam verwendeten Macs werden Policy-Zuweisung, lokale Konten und tatsächliche Pre-Boot-Berechtigung deshalb getrennt gepflegt. Die lokal aktivierten FileVault-Benutzer zeigt:

sudo fdesetup list

Status und Recovery-Bereitschaft abnehmen

Central-Status richtig lesen

Unter My Products > Encryption > Computers wird der Mac mit seiner letzten Kommunikation und seinem Verschlüsselungsstatus geprüft. Für macOS sind insbesondere diese Zustände relevant:

• Encrypted: Die Verschlüsselung ist abgeschlossen. Der Recovery-Nachweis wird trotzdem separat kontrolliert.
• Pending: Die Policy ist zugewiesen, aber Verschlüsselung oder Benutzeraktion ist noch nicht abgeschlossen.
• Plain: Mindestens ein erwartetes Volume ist unverschlüsselt oder die Verschlüsselung wurde noch nicht gestartet.
• Unmanaged: Der Agent ist vorhanden, aber keine Device-Encryption-Policy ist wirksam.
• Not supported: Plattform oder Betriebsmodus wird nicht unterstützt.
• Not available: Fusion kennt den Zustand nicht, beispielsweise weil die Komponente fehlt oder noch keine verwertbare Meldung vorliegt.

Suspended ist ein BitLocker-Zustand und kein FileVault-Abnahme- oder Diagnosewert. Bei einem Mac werden stattdessen Policy, Benutzerautorisierung, Volume-Zustand, Synchronisation und Recovery Key zusammen bewertet.

Für Rollout- und Betriebsnachweise werden Statuswechsel und Key-Ereignisse zusätzlich unter Reports > General Logs > Events für den betroffenen Mac und Zeitraum ausgewertet. Ereignisse wie Device Encryption status changed, Received recovery keys, Key creation failed oder Recovery key missing zeigen den Verlauf, ersetzen aber nicht die aktuelle Prüfung am Gerät und unter Encryption > Computers. Filter, Export und Aufbewahrung des Reports erklärt Sophos Endpoint Events und Reports auswerten.

Lokal prüfen

Die App Sophos Device Encryption liegt im Programme-Ordner und zeigt Policy-, Benutzer-, Volume- und Recovery-Status. Die Volume-Symbole bedeuten:

• Grün: vollständig verschlüsselt und Recovery Key in Fusion gespeichert.
• Gelb: vollständig verschlüsselt, aber kein Key in Fusion gespeichert; bei einem lokal und ohne Fusion verschlüsselten Volume kann noch kein verwalteter Key existieren.
• Gelb mit Ausrufezeichen: von der Policy verlangtes, vollständig verschlüsseltes Volume ohne verfügbaren Recovery Key.
• Rot: nicht verschlüsselt, obwohl die Policy Verschlüsselung verlangt.
• Grau: nicht verschlüsselt und von der Policy nicht verlangt oder keine Policy vorhanden.
• Fortschrittsbalken: Das Volume wird gerade ver- oder entschlüsselt.

Zusätzlich stellt Sophos das Tool /usr/local/bin/seadmin bereit:

/usr/local/bin/seadmin help
/usr/local/bin/seadmin status
/usr/local/bin/seadmin --device-encryption

status zeigt letzte Synchronisation und Synchronisationsintervall. --device-encryption zeigt die aktuelle Policy sowie Verschlüsselungs- und Recovery-Status der internen Volumes. Für die Betriebsfreigabe müssen vier Nachweise zusammen vorliegen:

1. Die vorgesehenen Volumes sind vollständig verschlüsselt und lokal grün.
2. fdesetup status meldet, dass FileVault aktiv ist; sudo fdesetup list enthält die vorgesehenen Pre-Boot-Benutzer.
3. Der Mac hat aktuell mit Fusion synchronisiert und meldet Encrypted.
4. Der freigegebene Abrufweg kann den Recovery Key für den richtigen Mac beziehungsweise die dort angezeigte Recovery-Key-ID liefern; die lokale FileVault-Abnahme bleibt davon getrennt.

Einen Mac wiederherstellen

Wiederherstellungsschlüssel sicher abrufen liefert den bereits korrekt zugeordneten Key. Dieser Artikel beginnt mit dessen Einsatz in FileVault.

Kennwort am normalen Startbildschirm zurücksetzen

1. Im Kennwortfeld auf das Fragezeichen klicken und mit dem Pfeil zum Recovery-Key-Feld wechseln.
2. Den für diesen Mac ausgegebenen Recovery Key eingeben.
3. Dem macOS-Dialog zum Erstellen eines neuen Anmeldekennworts folgen.
4. Wird Create New Keychain angeboten, einen neuen Schlüsselbund erstellen. Der alte Schlüsselbund wird durch einen FileVault-Recovery-Key nicht automatisch entsperrt.
5. Nach der Anmeldung FileVault-Benutzer, Sophos-Synchronisation und Recovery-Status erneut prüfen.

Die Recovery-Key-ID wird beim Start nur kurz angezeigt. Für eine erneute Anzeige muss der Mac neu gestartet werden. Bei aus Active Directory importierten Benutzern wird zuerst das Kennwort in AD zurückgesetzt und ein vorläufiges Kennwort vergeben. Im macOS-Dialog wählt der Benutzer Cancel und gibt anschliessend dieses vorläufige Kennwort ein.

APFS-Volume ausserhalb des normalen Starts entsperren

Dieser Fallback gilt für ein verschlüsseltes APFS-Volume, wenn der normale Startbildschirm nicht nutzbar ist. Er ersetzt weder die Identitätsprüfung noch die eindeutige Zuordnung des Recovery Keys. Je nach Mac-Modell und macOS-Version stehen macOS Recovery, ein unterstütztes externes Startvolume oder die von Apple vorgesehene Verbindung beziehungsweise Datenträgerfreigabe zu einem zweiten Mac zur Verfügung.

1. In der gewählten Recovery-Umgebung Utilities > Terminal öffnen.

2. Die APFS-Struktur nur lesend anzeigen:

   diskutil apfs list
   

3. Das verschlüsselte Zielvolume anhand Name, Rolle und APFS-Volume-ID eindeutig bestimmen. Bei unklarer Zuordnung abbrechen; System-, Data-, Preboot- und Recovery-Volumes dürfen nicht verwechselt werden.

4. Das Zielvolume interaktiv entsperren:

   diskutil apfs unlockVolume <VOLUME-ID>
   

   <VOLUME-ID> wird durch den ermittelten Identifier ersetzt. Den Recovery Key erst an der interaktiven Kennwortabfrage eingeben, nie als Befehlsargument oder in ein Skript schreiben.

5. Mit diskutil apfs list und im Finder prüfen, ob das richtige Volume eingebunden ist und die erwarteten Daten lesbar sind.

Das erfolgreiche Entsperren beweist nur, dass dieser Key zu diesem APFS-Volume passt. Es repariert weder den Sophos-Agenten noch die Key-Übertragung und berechtigt nicht zu weiteren Änderungen am Volume. Danach werden Daten gesichert oder die eigentliche Störung kontrolliert bearbeitet.

Wenn der Recovery Key nicht gespeichert wird

Kann der Agent den neuen Recovery Key weder im macOS-Schlüsselbund noch in Sophos Fusion speichern, zeigt Sophos ihn dem Benutzer an und fordert ihn auf, eine Kopie zu sichern. Zusätzlich legt Sophos eine nur für root zugängliche Notfallsicherung an:

/Library/Application Support/Sophos Encryption/.RecoverykeyEmergencybackup

Der Agent versucht die Übertragung wiederholt. Sobald sie erfolgreich ist, informiert er den Benutzer, dass Fusion einen neuen Key verwaltet und die manuelle Kopie vernichtet werden kann. Bis dahin wird der Key wie ein Geheimnis aufbewahrt und ein gelber Status nicht als erfolgreicher Rollout verbucht.

Bleibt der Status nach lokaler Anmeldung, Netzwerkverbindung und erneuter Synchronisation gelb oder widersprechen sich App, seadmin und Fusion, werden Zeitpunkt, macOS- und Agentversion, Policy, betroffene Volume-ID und Statusanzeigen ohne Recovery Key festgehalten. Weitere Diagnose und Eskalation behandelt Sophos Device Encryption Fehler systematisch beheben.

Kontrollierter Zielzustand und Offboarding

Für macOS gibt es keine belegte allgemeine Sophos-Sequenz nach dem Muster «Policy entfernen, Benutzer entfernen, automatisch entschlüsseln». Ebenso überträgt die Deinstallation des Endpoint-Agenten keinen FileVault-Key an ein neues Management. Vor Übergabe, Tenant-Wechsel oder Agent-Deinstallation wird deshalb ein kontrollierter Zielzustand hergestellt:

1. Festlegen, ob FileVault aktiv bleiben oder durch einen lokalen autorisierten Administrator bewusst deaktiviert werden soll.
2. Den letzten lokalen Zustand mit fdesetup status, die Pre-Boot-Benutzer mit sudo fdesetup list und die betroffenen internen Volumes dokumentieren.
3. Wenn FileVault aktiv bleibt, Recovery-Verantwortung und einen zum Gerät passenden, freigegebenen Recovery-Weg beim künftigen Eigentümer nachweisen. Ein alter Fusion-Eintrag allein ist keine Übergabe.
4. Wenn FileVault lokal deaktiviert werden soll, zuerst sicherstellen, dass die Device-Encryption-Policy für den Mac nicht mehr wirksam ist. Das Entfernen oder Deaktivieren der Policy entschlüsselt FileVault nicht; es verhindert, dass Sophos die Aktivierung erneut anfordert. Danach Recovery und Wartungsfenster sichern, die Entschlüsselung unter macOS ausführen und ihren vollständigen Abschluss lokal prüfen.
5. Erst wenn Zielzustand, lokale Nachweise und Recovery-Verantwortung stimmen, die lokale Agent-Entfernung nach Sophos Endpoint unter macOS deinstallieren ausführen.
6. Die Bereinigung des Geräteobjekts in Fusion bleibt ein separater Verwaltungsschritt und ist weder Entschlüsselung noch Key-Transfer.

Bei einem Wechsel zu einem anderen Managementsystem wird dessen FileVault- und Escrow-Funktion zuerst auf einer Pilotgruppe geprüft. Die alte Recovery-Möglichkeit bleibt erhalten, bis das neue System den vorgesehenen Zielzustand und einen getesteten Recovery-Weg nachweislich übernommen hat.

Typische Abweichungen eingrenzen

Kein Sophos-Dialog nach der Anmeldung

Zuerst lokale statt Remote-Anmeldung, installierten Device Encryption Agent, Benutzer- und Policy-Zuweisung sowie letzte Synchronisation prüfen. Danach folgen Secure Token und bei Apple-Chip-Macs Volume Owner. Ohne diese Voraussetzungen ist wiederholtes Umschalten der Policy kein sinnvoller Test.

Benutzer kann macOS starten, aber nicht am FileVault-Pre-Boot anmelden

Das lokale Konto ist nicht automatisch ein FileVault-Benutzer. sudo fdesetup list mit der erwarteten Benutzerliste abgleichen, Apple-Berechtigungen prüfen und den dokumentierten Ablauf zum Hinzufügen eines Benutzers durchführen. Danach mit einem Neustart testen; Ab- und Anmelden innerhalb der laufenden Sitzung genügt nicht.

Fusion zeigt Encrypted, lokal ist ein Volume gelb

Encrypted allein beweist keinen vollständigen Recovery-Zustand. In der Sophos Device Encryption App und mit seadmin --device-encryption das konkrete Volume und seinen Key-Status bestimmen. Bis ein passender Recovery Key nachgewiesen ist, bleibt der Mac ausserhalb der Abnahme.

FileVault ist aktiv, Fusion zeigt Pending oder Not available

Letzte Synchronisation, Komponente, lokale Benutzeraktion und Policy prüfen. Bei bereits aktivem FileVault kontrollieren, ob der Benutzer Create key abgeschlossen hat. Bleiben lokaler und zentraler Zustand nach erneuter Synchronisation widersprüchlich, keine Key-Rotation oder Policy-Experimente starten, sondern Belege sichern und zum Troubleshooting übergeben.

Häufige Fragen