BitLocker mit Sophos Fusion verwalten
Sophos Device Encryption aktiviert und verwaltet Microsoft BitLocker. Die eigentliche Laufwerksverschlüsselung und Pre-Boot-Authentifizierung stammen weiterhin von Windows. Deshalb müssen Windows-Hardware, Firmware, BitLocker-Gruppenrichtlinien und die Sophos-Policy zusammenpassen.
Kurzweg: Unter My Products > Encryption > Policies eine Device Encryption-Policy erstellen, Benutzer oder Gruppen zuweisen, die Windows-Einstellungen festlegen und die Policy einschalten. Danach meldet sich ein zugewiesener Benutzer lokal am Pilotgerät an, erledigt die Sophos-Dialoge und Neustarts und führt den Pre-Boot-Test aus. Fertig ist der Rollout erst, wenn lokaler BitLocker-Status, Sophos-Fusion-Status und ein passender Recovery Key bestätigt sind.
Voraussetzungen und Kompatibilität prüfen
Vor der Aktivierung werden mindestens diese Punkte freigegeben:
- Windows-Edition, Build, Patchstand und Lebenszyklusstatus gemäss Systemanforderungen und Lebenszyklen für Sophos Endpoint. Die weiter unten stehende historische Protector-Matrix ist keine Freigabe alter Windows-Versionen.
- Installierter und kommunizierender Sophos Core Agent mit der von der Lizenz abgedeckten Device-Encryption-Komponente.
- BitLocker-Unterstützung der Windows-Edition und ein zum Gerät passender Authentifizierungsmodus.
- Aktiviertes, bereites TPM; bei TPM 2.0 ein GPT-formatierter Systemdatenträger und UEFI-Modus.
- Ausreichend Platz für System- und Recovery-Partition. Volumes mit 64 MB oder weniger werden von Sophos ignoriert.
- Keine zweite Instanz, die gleichzeitig BitLocker-Protectoren, Verschlüsselungsmethode oder Recovery Keys verwaltet.
- Festgelegter Recovery-Prozess und berechtigte Personen, bevor der erste Protector ersetzt wird.
Dynamic Disks werden für das Systemvolume nicht unterstützt; Datenvolumes auf Dynamic Disks werden ignoriert. Windows-Partitionen, die mit Boot Camp auf einem Mac erstellt wurden, sind ebenfalls nicht unterstützt. Wechselmedien kann Windows mit BitLocker To Go verschlüsseln, Sophos Fusion verwaltet dafür aber weder Status noch Recovery Keys.
Sophos Device Encryption unterstützt vorab bereitgestelltes BitLocker und bereits verschlüsselte Laufwerke. Neue Volumes verschlüsselt es softwarebasiert. Eine vorhandene Hardwareverschlüsselung stellt es nicht automatisch um. Bereits verwaltetes BitLocker darf nur in einem kontrollierten Änderungsfenster und ohne parallele Protector-Verwaltung übernommen werden. Dabei ersetzt Sophos die bisherigen Recovery Keys; diese sind danach ungültig und ausdrücklich kein Rückweg. Das vollständige, geordnete Vorgehen steht unter Vorhandenes BitLocker übernehmen.
Ein TPM-Fehler wird nicht durch wiederholtes Ein- und Ausschalten der Policy behoben. TPM-Bereitschaft, Windows-Ereignisse und der lokale BitLocker-Status werden zuerst geprüft.
Device-Encryption-Policy konfigurieren
- My Products > Encryption > Policies öffnen, Add Policy wählen und eine Device Encryption-Policy erstellen.
- Benutzer oder Benutzergruppen zuweisen. Unter Windows löst die lokale Anmeldung eines zugewiesenen Benutzers die Einrichtung aus. Das Laufwerk bleibt danach auch verschlüsselt, wenn sich ein Benutzer ohne diese Policy anmeldet.
- Im Tab Settings die Option Device Encryption is on aktivieren.
- Encrypt boot volume only bewusst wählen. Ist die Option ausgeschaltet, werden nach dem Systemvolume auch unterstützte feste Datenvolumes verschlüsselt.
- Unter Advanced Windows settings festlegen, ob Require startup authentication nötig ist. Die Option ist standardmässig aktiv. Ist sie ausgeschaltet, verwendet Sophos auf kompatiblen Geräten
TPM only. - Encrypt used space only ausschliesslich für neu bereitgestellte Geräte verwenden. Die Erstverschlüsselung geht schneller, zuvor gelöschte Daten in vermeintlich freien Bereichen können aber unverschlüsselt bleiben.
- Falls verlangt, mit Require new authentication password/PIN from users das Änderungsintervall für PIN oder Passphrase definieren. Diese Funktion ist unter Windows ab Device Encryption 2.0 verfügbar und standardmässig ausgeschaltet.
- Policy speichern, einschalten und zuerst einer repräsentativen Pilotgruppe zuweisen.
Ist eine Einstellung gesperrt, kann sie aus einer globalen Vorgabe des Sophos-Partners oder Enterprise-Administrators stammen. Das wird geklärt, bevor die lokale Policy als fehlerhaft behandelt wird.
Authentifizierungsmodus wählen
Welche Protector-Art installiert wird, hängt von Gerät, BitLocker-GPO und Require startup authentication ab. 1 bezeichnet in der folgenden Matrix die erste Wahl von Sophos. 1* gilt nur, wenn Require startup authentication ausgeschaltet ist. Ist die Option aktiv, steht TPM only nicht zur Wahl und TPM + PIN wird auf einem kompatiblen Gerät bevorzugt.
| Windows und TPM | TPM only | TPM + PIN | Passphrase | USB Key |
|---|---|---|---|---|
| Windows 7, ohne TPM | — | — | — | 1 |
| Windows 7, mit TPM | 1* | 2 | — | 3 |
| Windows 8.1, ohne TPM | — | — | 1 | — |
| Windows 8.1, mit TPM | 1* | 2 | 3 | — |
| Windows 10, ohne TPM | — | — | 1 | — |
| Windows 10, mit TPM | 1* | 2 | 3 | — |
| Windows 11, ohne TPM | — | — | 1 | — |
| Windows 11, mit TPM | 1* | 2 | 3 | — |
Windows 7 und 8.1 stehen hier nur, damit die von Sophos dokumentierte Protector-Zuordnung vollständig bleibt. Sie sind keine aktuelle Bereitstellungsempfehlung und werden separat gegen den verlinkten Lebenszyklus geprüft. Der USB Key ist entsprechend nur eine historische Windows-7-Matrixoption, keine Empfehlung für einen neuen Rollout. Im Windows-FIPS-Modus dokumentiert Sophos diese BitLocker-Verwaltung für Windows 8.1, 10 und 11; daraus folgt ebenfalls keine aktuelle Betriebssystemfreigabe. Unter Windows 7 lässt sich kein FIPS-konformes BitLocker-Recovery-Passwort in Active Directory Domain Services speichern.
- TPM only setzt ein vorbereitetes TPM und eine GPO voraus, die diesen Schutz erlaubt; ausserdem muss Require startup authentication ausgeschaltet sein. Der Modus verursacht keinen zusätzlichen Pre-Boot-Schritt. Das ist betriebsfreundlich, schützt aber weniger gegen einen Angreifer, der das Gerät und eine entsperrbare Windows-Umgebung kontrolliert.
- TPM + PIN setzt ein vorbereitetes TPM und eine GPO voraus, die diesen Schutz erlaubt. Die PIN umfasst 4 bis 20 Zeichen und besteht nur aus Ziffern, sofern die GPO Allow enhanced PINs for startup nicht auch Buchstaben und Sonderzeichen erlaubt. Alle Benutzer desselben Computers teilen diese PIN; danach melden sie sich mit ihren persönlichen Windows-Zugangsdaten an. Windows Single Sign-on wird dabei nicht unterstützt. Der Modus erhöht den Pre-Boot-Schutz, aber auch Einführungs-, Helpdesk- und Recovery-Aufwand.
- Passphrase erfordert Windows 8 oder neuer sowie eine GPO, die den Passphrase-Modus erlaubt, und umfasst 8 bis 100 Zeichen. Sie ist die Sophos-Option für die aufgeführten Systeme ohne TPM. Für Passphrase und PIN gilt in der Pre-Boot-Umgebung ausschliesslich das US-englische Tastaturlayout. Sonderzeichen werden deshalb auf der realen Hardware getestet.
- USB Key muss bei jedem Start angeschlossen, beschreibbar und mit NTFS, FAT oder FAT32 formatiert sein; exFAT wird nicht unterstützt. Diese Legacy-Option wird nicht als Ausweg für ein nicht unterstütztes aktuelles Gerät eingesetzt.
Die Auswahl folgt dem Bedrohungsmodell, der Hardware und dem Supportprozess, nicht einer pauschalen Maximalhärtung. Weicht der angewendete Protector von der erwarteten Zeile ab, werden zuerst Require startup authentication, TPM-Bereitschaft und BitLocker-GPOs geprüft.
BitLocker-Gruppenrichtlinien bereinigen
Windows-GPOs können Authentifizierung, Algorithmen, Recovery-Ablage und Hardwareverschlüsselung vorgeben. Stehen die relevanten Authentifizierungseinstellungen auf Not configured, kann Sophos die GPO-Werte so setzen, dass die vorgesehenen Modi erlaubt sind. Eine manuell konfigurierte Vorgabe unter Computer Configuration > Administrative Templates > Windows Components > BitLocker Drive Encryption > Operating System Drives wird dagegen nicht überschrieben. Von Sophos gesetzte Werte erscheinen zudem nicht zwingend im Local Group Policy Editor; sie liegen unter HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\FVE.
Vor dem Pilot werden effektive Domain- und lokale Richtlinien mit ihrer Herkunft dokumentiert. Besonders geprüft werden:
- erlaubte Startup-Protectoren und TPM-Anforderungen,
- Recovery-Passwort und dessen zusätzliche Ablage, beispielsweise in Active Directory,
- Verschlüsselungsmethode und Software- beziehungsweise Hardwarevorgaben,
- Smartcard-Pflichten sowie andere Einstellungen, die Sophos nicht unterstützt.
Sophos verschlüsselt neue Volumes standardmässig softwarebasiert mit AES-256; per Gruppenrichtlinie ist AES-128 möglich. Eine vorhandene GPO, die Hardwareverschlüsselung verlangt, wird nicht überschrieben. Eine Smartcard-Pflicht für BitLocker unterstützt Sophos Device Encryption nicht und meldet ein Fehlerereignis. Widersprechen sich GPO und Sophos-Policy, bleibt die Verschlüsselung typischerweise ausstehend oder endet mit einem Fehler. Dann wird der Konflikt behoben, statt die Policy wiederholt neu zuzuweisen.
Network Unlock lässt sich mit Sophos Fusion weder konfigurieren noch verwalten. Eine separat korrekt eingerichtete BitLocker-Network-Unlock-Infrastruktur kann parallel verwendet werden.
Rollout und Benutzer-Prompts begleiten
Die erstmalige Durchsetzung und die Pre-Boot-Prüfung finden an der lokalen Konsole statt. Über Remote Desktop werden die erforderlichen Dialoge nicht angezeigt und die Device-Encryption-Policy wird nicht durchgesetzt. Die Pre-Boot-Authentifizierung lässt sich über Remote Desktop ebenfalls nicht ausführen.
Der Ablauf auf dem Gerät ist:
- Der zugewiesene Benutzer meldet sich lokal an; der Agent verbindet und synchronisiert sich mit Sophos Fusion.
- Ist das TPM noch nicht aktiviert, fordert der Ablauf eine Firmware-/BIOS-Aktion und einen Neustart an. Ein aktives, aber noch nicht initialisiertes TPM sowie fehlende Endorsement Keys versucht der Agent vorzubereiten.
- Fehlt die BitLocker-Systempartition, startet Sophos
BdeHdCfg.exe, bereitet das Laufwerk vor und verlangt einen echten Neustart. Ohne erfolgreichen Neustart beginnt keine Verschlüsselung. - Bei aktiver Startup-Authentifizierung setzt der Benutzer PIN, Passphrase oder USB Key im Sophos Device Encryption-Dialog. Mit Do this later lässt sich der Dialog verschieben; damit bleibt aber auch die Verschlüsselung ausstehend.
- Restart and Encrypt startet den Pre-Boot-Hardwaretest. Schlägt die Eingabe vor der ersten Verschlüsselung fehl, kann der Benutzer mit
Escnormal starten und wird bei der nächsten Anmeldung erneut aufgefordert. - Nach erfolgreichem Test verschlüsselt Sophos zuerst das Systemvolume und danach – sofern in der Policy vorgesehen – feste Datenvolumes im Hintergrund. Deren automatische Entsperrung ist an das Systemvolume gebunden.
Die Diagnoseprotokolle CDE.log und CDE_trace.xml liegen unter %ProgramData%\Sophos\Sophos Data Protection\Logs. Sie dienen der Ursachenanalyse, sind aber kein Ersatz für den lokalen BitLocker-Status.
Status und Reporting abnehmen
Unter My Products > Encryption > Computers lässt sich die Geräteliste nach Verschlüsselungsstatus und -methode filtern. Die Detailseite des Computers zeigt pro Volume Verschlüsselungsmethode und Algorithmus; unter Windows zusätzlich Encrypted since. Bei übernommenen oder aktualisierten Geräten kann dieses Datum den Installations- beziehungsweise Upgradezeitpunkt anzeigen und ist deshalb nicht immer das ursprüngliche Verschlüsselungsdatum.
Für die lokale, nur lesende Kontrolle eignen sich eine administrative Eingabeaufforderung und PowerShell:
manage-bde -status
Get-BitLockerVolume
Dabei werden für alle vorgesehenen Volumes mindestens Conversion-/Volume-Status, Schutzstatus, Sperrstatus, Verschlüsselungsmethode und vorhandene Key Protectoren geprüft. Die Abnahme umfasst:
- Das Systemvolume und alle von der Policy erfassten festen Datenvolumes sind vollständig verschlüsselt; der Schutz ist aktiv.
- Der tatsächlich installierte Protector entspricht Policy, GPO und Risikofreigabe.
- Sophos Fusion zeigt das Gerät unter My Products > Encryption > Computers im erwarteten Zustand und mit plausibler Methode.
- Der zu diesem Volume gehörende Recovery Key ist in Sophos Fusion hinterlegt. Die Regeln für Show Key und Bereitschaftstests stehen unter Wiederherstellungsschlüssel sicher abrufen.
- Neustart und vorgesehene Pre-Boot-Authentifizierung funktionieren auf der echten Hardware.
- Ein separates Testgerät hat den vereinbarten Recovery-Ablauf und eine typische Firmware-/TPM-Änderung durchlaufen.
Ein Fortschrittswert von 100 Prozent allein genügt nicht: Ohne aktiven Schutz und belegte Recovery-Bereitschaft ist das Gerät nicht abgenommen. Verschlüsselungsereignisse können zusätzlich unter Reports > General Logs > Events ausgewertet werden; Filter-, Export- und Aufbewahrungsmechanik beschreibt Sophos Endpoint Events und Reports auswerten.
PIN oder Passphrase erneuern
Ein Änderungsintervall wird in der Device-Encryption-Policy mit Require new authentication password/PIN from users gesetzt. Schliesst der Benutzer den Dialog, erscheint er nach jedem Neustart erneut; nach fünf geschlossenen Aufforderungen erzeugt Sophos einen Alert.
Für ein einzelnes Gerät öffnet der Admin die Computerdetailseite und verwendet im Tab Summary unter Device Encryption die Aktion Trigger change of password/PIN. Der Prompt erscheint auf dem Endpoint erneut, bis der Benutzer ein neues Geheimnis setzt; auch hier führt fünfmaliges Schliessen zu einem Alert. Eine erzwungene Änderung wird pilotiert, und Helpdesk sowie Benutzer wissen, dass das neue Geheimnis ab dem nächsten Pre-Boot gilt.
Windows nach Key-Abruf wiederherstellen
Den autorisierten Abruf und die Zuordnung übernimmt Wiederherstellungsschlüssel sicher abrufen. Dieser Abschnitt beginnt am Windows-BitLocker-Bildschirm mit dem bereits zugeordneten Schlüssel und beschreibt ausschliesslich dessen Verwendung.
Für die eigentliche Windows-Wiederherstellung:
- Computer neu starten und am BitLocker-Prompt
Escdrücken. - Die am Bildschirm angezeigte Recovery Key ID vollständig erfassen und gegen den abgerufenen Key abgleichen.
- Den Recovery Key direkt am Gerät eingeben.
- Den Bildschirmanweisungen folgen und bei PIN- oder Passphrase-Betrieb ein neues Geheimnis setzen.
- Normal anmelden, synchronisieren und prüfen, dass Sophos einen neuen Recovery Key hinterlegt hat.
Bleibt danach ein Datenvolume gesperrt, wird der Vorgang mit dessen eigener Recovery Key ID wiederholt. Ein Key des Systemvolumes ist nicht automatisch der Key eines Datenvolumes.
Bei einem Hardwaredefekt kann das BitLocker-Laufwerk an ein anderes BitLocker-fähiges Windows-System angeschlossen werden. Dort Unlock Drive > More options > Enter recovery key wählen und die angezeigte Key ID verwenden. Vor TPM-Löschen, Protector-Manipulation oder anderen zustandsändernden Workarounds wird zuerst sichergestellt, dass ein passender Recovery Key tatsächlich verfügbar ist.
Nach jedem Recovery wird die Ursache geklärt. Eine vergessene PIN, ein BIOS-Update, ein deaktiviertes oder gelöschtes TPM, Secure-Boot-Änderungen, ein Mainboard-Tausch und Manipulationsverdacht verlangen unterschiedliche Folgeaktionen.
Vorhandenes BitLocker übernehmen
Die Übernahme erfolgt in dieser Reihenfolge:
- Pro Volume Verschlüsselungsmethode, Schutzstatus, Protectoren, Recovery-Key-ID und bisherige Verwaltung dokumentieren. Den aktuell nutzbaren Wiederherstellungsweg prüfen und ein kontrolliertes Änderungsfenster öffnen.
- Protector-Änderungen der bisherigen Verwaltung deaktivieren, bevor Sophos die Verwaltung übernimmt. Zwei Verwaltungen dürfen nie gleichzeitig Protectoren ändern.
- Die Sophos-Komponente installieren, eine wirksame Device-Encryption-Policy zuweisen und die lokale Aufforderung abschliessen.
- Festhalten, sobald Sophos die vorhandenen BitLocker-Protectoren und Recovery Keys ersetzt hat. Ab diesem Moment sind die bisherigen Schlüssel ungültig und dürfen nicht als Rückweg behandelt werden; auch das Aufbewahren alter Daten macht sie nicht wieder nutzbar.
- Das Änderungsfenster offen und die alte Verwaltungsinfrastruktur inaktiv, aber verfügbar halten. In Sophos Fusion prüfen, dass das Gerät korrekt erscheint und der neue Fusion-Key zum getesteten Volume passt. Lokal aktiven Schutz sowie einen erfolgreichen Neustart mit Pre-Boot-Eingabe nachweisen.
- Erst nach diesen Nachweisen die alte Instanz ausser Betrieb nehmen.
Auch ein späterer Wechsel zu einer Drittverwaltung erfolgt ohne parallele Protector-Verwaltung im unten beschriebenen Änderungsfenster.
SafeGuard-Migration nach Ausgangszustand trennen
Vor jeder SafeGuard-Migration werden Version, installierte Module und tatsächliche Laufwerksverschlüsselung inventarisiert. Eine unbekannte oder gemischte Installation ist ein Abbruchkriterium. Historische SafeGuard-Dokumentation beweist keine heutige Produktunterstützung.
Lebenszyklusgrenze: Es gibt derzeit keine belastbare aktuelle Freigabe, um SafeGuard Enterprise oder SafeGuard-File-Encryption-Module nach der Migration weiterzubetreiben oder neu zu installieren. Dieser Artikel empfiehlt beides nicht. Sind noch dateibasierte SafeGuard-Module oder damit verschlüsselte Dateien vorhanden, wird die Migration angehalten, bis Sophos Support die konkrete Version und das Modul schriftlich bestätigt und ein geprüfter Zugriffspfad für diese Dateien feststeht.
SafeGuard Enterprise BitLocker 6.x oder 7.x
Dieser Zweig erlaubt keine direkte Übernahme. Das Systemlaufwerk muss zuerst nach dem für die vorhandene SafeGuard-Version freigegebenen Verfahren entschlüsselt werden. Vorher werden Wiederherstellbarkeit, Stromversorgung und freier Speicher geprüft. Erst nach vollständig bestätigter Entschlüsselung und kontrollierter Entfernung der alten Laufwerksverwaltung werden Sophos Device Encryption installiert, die Policy zugewiesen und BitLocker neu verschlüsselt. Der neue Fusion-Key und die Pre-Boot-Anmeldung werden abgenommen, bevor die alte Wiederherstellungsinfrastruktur wegfällt.
SafeGuard Enterprise BitLocker 8.0 oder neuer
Bei diesem Zweig kann das SafeGuard-BitLocker-Modul entfernt werden, ohne die BitLocker-Volumes zu entschlüsseln:
- Unter Control Panel > Uninstall a program den Sophos SafeGuard Client mit der rechten Maustaste wählen und Change öffnen.
- Im SafeGuard-Installationsassistenten ausschliesslich die BitLocker-Komponente entfernen. Danach lokal bestätigen, dass das Volume weiterhin verschlüsselt und zugänglich ist.
- Sophos Device Encryption installieren und eine aktivierte Policy zuweisen.
- Synchronisierung, neuen Protector, passenden Fusion-Recovery-Key, Schutzstatus und Neustart abnehmen.
Der Schritt gilt nur für den eindeutig identifizierten BitLocker-Zweig ab 8.0. Er erlaubt keine Aussage über den Weiterbetrieb anderer SafeGuard-Module; bei solchen Modulen greift die Lebenszyklusgrenze oben.
SafeGuard Enterprise Full Disk Encryption
Full Disk Encryption ist technisch ein anderer Zweig und darf nicht wie SafeGuard-BitLocker 8+ behandelt werden. Beim unterstützten Entfernen des SafeGuard Clients werden die damit verschlüsselten Volumes entschlüsselt; dateibasiert verschlüsselte Dateien können verschlüsselt bleiben. Gerade deshalb werden installierte Module und Datenzugriff vor der Entfernung geklärt. Sind dateibasierte Module beteiligt, gilt das oben genannte Abbruchkriterium bis zur schriftlichen Lebenszyklus- und Migrationsfreigabe.
Alle Voraussetzungen für Sophos Device Encryption und BitLocker werden vor Beginn der Entschlüsselung vorbereitet. Das Klartextfenster beginnt mit der bestätigten vollständigen SafeGuard-Entschlüsselung und endet erst, wenn BitLocker-Schutz und der zum Volume passende Fusion-Recovery-Key abgenommen sind. Dieses Fenster wird im Änderungsplan zeitlich begrenzt und so kurz wie möglich gehalten.
Während des Klartextfensters bleibt das Gerät im kontrollierten Wartungsbetrieb: Es wird nicht produktiv verwendet, nur die für den Wechsel berechtigten Personen erhalten Zugriff, und Netzwerkzugang sowie Datentransfers werden auf das für Installation und Abnahme erforderliche Mass beschränkt. Nach dem freigegebenen Rückbau werden Sophos Device Encryption installiert, die Policy zugewiesen und das Volume unverzüglich mit BitLocker neu verschlüsselt. Das Änderungsfenster bleibt offen, bis der lokale BitLocker-Schutz aktiv ist, der passende Fusion-Recovery-Key nachgewiesen wurde und Neustart sowie vorgesehene Pre-Boot-Authentifizierung erfolgreich waren. Der gesamte Wechsel besteht aus Entschlüsseln und erneutem Verschlüsseln; er ist keine direkte Protector-Übernahme.
Kontrolliert entschlüsseln und ausser Betrieb nehmen
Zuerst wird der Zielzustand festgelegt: Soll das Gerät vollständig entschlüsselt werden, oder soll BitLocker unter einer Nachfolgeverwaltung aktiv bleiben? Agent-Deinstallation, Löschen des Gerätedatensatzes und Entschlüsselung sind drei verschiedene Vorgänge.
Für eine geplante Entschlüsselung gilt diese Reihenfolge:
- Je nach Art der Richtlinie alle Benutzer oder den Computer aus der wirksamen Device-Encryption-Policy entfernen und die Synchronisierung bestätigen.
- Mit lokalem Windows-Administratorkonto im Windows Explorer beim Volume Manage BitLocker > Turn off BitLocker wählen.
- Stromversorgung und Wartungsfenster sicherstellen und die Entschlüsselung bis zum Abschluss überwachen.
- Mit
manage-bde -statusoderGet-BitLockerVolumebestätigen, dass jedes vorgesehene Volume vollständig entschlüsselt und der Schutz aus ist. - Erst nach belegter vollständiger Entschlüsselung wird die lokale Agent-Entfernung an Sophos Endpoint unter Windows deinstallieren übergeben. Eine spätere Löschung oder Wiederherstellung des Fusion-Gerätedatensatzes wird davon getrennt über Sophos Central Gerät ersetzen oder stilllegen ausgeführt.
Versucht ein lokaler Administrator die Entschlüsselung bei weiterhin aktiver Device-Encryption-Policy, hebt Sophos Fusion den lokalen Befehl auf und das Laufwerk bleibt verschlüsselt. Das reine Entfernen einer Policy oder des Agents beweist umgekehrt weder deaktiviertes BitLocker noch eine abgeschlossene Entschlüsselung.
Soll BitLocker bestehen bleiben, erfolgt die Übergabe in dieser Reihenfolge:
- Ein nicht überlappendes Änderungsfenster öffnen. Den aktuellen lokalen BitLocker-Schutz und einen zum Volume passenden aktuellen Sophos-Recovery-Key nachweisen; BitLocker bleibt eingeschaltet.
- Die lokale Sophos-Verwaltung ausschliesslich nach Sophos Endpoint unter Windows deinstallieren entfernen beziehungsweise deaktivieren.
- Erst danach das Gerät unmittelbar in die Nachfolgeverwaltung aufnehmen. Zwei Verwaltungen dürfen zu keinem Zeitpunkt gleichzeitig Protectoren ändern.
- In der Nachfolgeverwaltung einen neuen passenden Recovery Key erzeugen und sicher verwahren.
- Den lokalen Schutzstatus und einen Neustart prüfen. Erst nach diesen Nachweisen die Sophos-Verwahrung des Wiederherstellungsschlüssels aufgeben und das Änderungsfenster schliessen.
Das spätere Löschen oder Wiederherstellen des Datensatzes in Sophos Fusion bleibt ein separater Verwaltungsakt nach Sophos Central Gerät ersetzen oder stilllegen, keine lokale Deinstallation.
Wenn die Abnahme scheitert
Nicht mit wiederholtem Ein- und Ausschalten der Policy, TPM-Löschen oder Protector-Änderungen experimentieren. Zuerst Symptom und Ebene eingrenzen:
- Kein Prompt: Benutzer-/Policy-Zuweisung, lokale statt RDP-Anmeldung, Agent-Synchronisierung und installierte Device-Encryption-Komponente prüfen.
- Prompt verschoben: Benutzer schliesst den Dialog und echten Neustart an der lokalen Konsole ab.
- Pre-Boot-Test fehlgeschlagen: TPM/Firmware, Tastaturlayout, effektive GPO und Windows-Ereignis prüfen; es wird noch nicht verschlüsselt.
- Lokal verschlüsselt, in Fusion nicht abgenommen: Gerätesynchronisierung, Eingang des Recovery Keys und Zuordnung des Volumes prüfen; für die sichere Abrufprüfung gilt der zentrale Recovery-Ablauf.
- Unerwarteter Protector oder Algorithmus: wirksame Domänen- und lokale Gruppenrichtlinien sowie vorhandene Hardwareverschlüsselung mit der Sophos-Policy vergleichen.
- Recovery nach Firmwareänderung: zuerst passenden Key sichern und Ursache bestätigen; erst danach eine zustandsändernde Reparatur erwägen.
Konkrete Alerts, TPM-, WMI- und Servicefehler sowie die sichere Logsammlung behandelt Sophos Device Encryption Fehler systematisch beheben.
Häufige Fragen
Warum startet BitLocker trotz zugewiesener Sophos-Policy nicht?
Ist TPM only immer die beste Einstellung?
TPM only ist komfortabel, besitzt aber ein anderes Risikoprofil als TPM + PIN. Die Wahl hängt von Bedrohungsmodell, Hardware, Benutzerprozess und belastbarem Helpdesk-/Recovery-Ablauf ab.