Systematyczne rozwiązywanie błędów Sophos Device Encryption
Sophos Central koordynuje BitLocker i FileVault, ale za samo szyfrowanie nadal odpowiada system operacyjny. Dlatego poprawnie przypisana Policy może zakończyć się niepowodzeniem z powodu TPM, Firmware, Windows WMI, Group Policies, sesji użytkownika albo zarządzania Recovery Key. Wielokrotne włączanie i wyłączanie Policy raczej ukrywa stan, niż go naprawia.
Diagnostyka rozpoczyna się od Central Alert i kończy na lokalnym kodzie błędu. W systemie Windows najważniejszym logiem Sophos jest:
C:\ProgramData\Sophos\Sophos Data Protection\Logs\CDE.log
Dodatkowo należy sprawdzić manage-bde -status, Windows Application Event Log, stan TPM i efektywne BitLocker GPOs. W macOS wspólnie analizuje się stan FileVault, użytkownika, Secure Token i Recovery Key.
Najpierw rozróżnić stan
| Wskazanie lub błąd | Rzeczywiste znaczenie | Następny punkt kontroli |
|---|---|---|
Pending | Policy jest aktywna, szyfrowanie oczekuje lub trwa | User Prompt, sesja lokalna, GPO, TPM |
Suspended | Volume jest zaszyfrowany, ale Protector czasowo wstrzymany | Update, restarty, lokalny administrator, manage-bde |
Recovery key is missing | Central nie ma prawidłowego Key | komunikacja, lokalne zarządzanie Key, zmiana użytkownika |
Device is not encrypted | co najmniej jeden oczekiwany Volume nie jest zaszyfrowany | Policy, wspierane Volumes, lokalny kod błędu |
| Usługa nie uruchamia się | komponent agenta jest uszkodzony lub niezgodny | Event Log i log komponentu |
Przed naprawą należy udokumentować urządzenie, użytkownika, Policy, czas, Volume, kod błędu i aktualną metodę Recovery. Systemu produkcyjnego nie odszyfrowuje się, dopóki stan istniejącego Recovery Key nie jest wyjaśniony.
Używanie Endpoint Self Help we właściwej kolejności
W About > Endpoint Self Help > Device Encryption najpierw usuń ostrzeżenia w Services i Management Communication. Bez działającej usługi Device Encryption i aktualnej komunikacji MCS dalsze wyniki nie są wiarygodne; restart nie naprawia brakującej usługi ani ścieżki.
Następnie sprawdź instalację, BitLocker Error, czas polityki i woluminy. ESH pokazuje postęp, blokadę, protector i błędy; porównaj je z efektywną polityką i Last Active w Central.
Częste konflikty pochodzą z GPO dla typu szyfrowania, protectorów, TPM, FIPS lub backupu Recovery Key do Active Directory. Ustal źródło każdej opcji przed zmianą Sophos lub Windows.
BitLocker ma stan Suspended
Suspended nie oznacza odszyfrowania. Dysk pozostaje zaszyfrowany, ale podczas uruchamiania czasowo nie wymaga TPM PIN ani hasła. Windows lub Firmware Updates mogą automatycznie wstrzymać BitLocker na określoną liczbę restartów, a następnie ponownie go aktywować. Sophos Central zgłasza ten stan, ale zasadniczo nie cofa samodzielnie celowo ustawionego Suspension.
Lokalny stan pokazuje, czy pozostały niezabezpieczone restarty:
manage-bde -status
Jeżeli Update jest zakończony albo BitLocker został wstrzymany przez administratora, Protector należy ponownie aktywować w kontrolowany sposób:
manage-bde -protectors -enable C:
Następnie wykonuje się restart, synchronizację z Central i ponowną kontrolę stanu. Suspension bez możliwego do wyjaśnienia Change należy zbadać jako zdarzenie bezpieczeństwa.
TPM-only kończy się błędem 0x80310048
Błąd FVE_E_FIRMWARE_TYPE_NOT_SUPPORTED oznacza, że Windows nie obsługuje TPM-only Protector z powodu Firmware lub BIOS. Sophos Policy nie jest wtedy przyczyną. Najpierw należy zaktualizować BIOS lub UEFI oraz TPM Firmware zgodnie z instrukcją producenta.
Jeżeli sprzęt nie umożliwia odpowiedniej pracy TPM, świadomie wybrana Policy bez TPM Protector może korzystać z trybu hasła. Jest to decyzja dotycząca bezpieczeństwa, a nie cichy Workaround. Przed zmianami należy sprawdzić istniejące Recovery Keys.
Inny przypadek TPM-only wymaga tylko właściwego restartu: gdy CDE przygotował hardware test, szyfrowanie rusza po Restart now w Sophos. Wyłączenie i późniejszy zimny start nie zawsze kończą ten sam proces.
Urządzenie DMA blokuje BitLocker
Jeśli Windows zgłasza urządzenie DMA bez ochrony przed dostępem zewnętrznym, blokada pochodzi z Windows DMA Security, nie z Sophos. Zidentyfikuj urządzenie lub magistralę w Event Viewer i potwierdź cel u producenta.
W Windows 10 i Windows 11 do 24H1 potwierdzoną magistralę można dodać w HKLM\SYSTEM\CurrentControlSet\Control\DmaSecurity\AllowedBuses. Windows 11 24H2 i nowszy ignoruje allowlist: popraw firmware, sterownik lub zgodność. Nie zezwalaj szeroko na nieznane magistrale.
InvalidNamespace 0x8004100E
Jeżeli CDE.log zgłasza brak informacji o Volume z powodu ManagementStatus.InvalidNamespace, a manage-bde -status również zwraca błąd 0x80041002, klasa WMI Win32_EncryptableVolume jest często nieprawidłowo zarejestrowana.
W wierszu polecenia administratora należy ponownie zarejestrować Microsoft MOF:
mofcomp.exe C:\Windows\System32\wbem\win32_encryptablevolume.mof
manage-bde.exe -status
Dopiero gdy drugie polecenie ponownie zwraca prawidłowe dane Volume, należy zrestartować urządzenie i jeszcze raz uruchomić PIN Prompt.
Tablet lub Slate nie przyjmuje Pre-Boot Protector
Windows blokuje Protector wymagający klawiatury na urządzeniach rozpoznanych jako Slate, jeżeli brakuje odpowiedniej BitLocker Policy. Typowy jest błąd 0x803100B6 podczas tworzenia Recovery Protector.
W Computer Configuration > Administrative Templates > Windows Components > BitLocker Drive Encryption > Operating System Drives należy włączyć Enable use of BitLocker authentication requiring preboot keyboard input on slates. Następnie wykonać gpupdate /force albo normalną aktualizację GPO.
Brak UI Prompt przez RDP lub Hyper-V Enhanced Session
Wiersz No UI user session available w CDE.log często nie oznacza błędu usługi. Sophos celowo wyświetla okno BitLocker tylko w lokalnej interaktywnej sesji Windows. Logowanie typu Network przez RDP lub Hyper-V Enhanced Session nie może uruchomić szyfrowania, aby następnie nie pozostawić niemożliwego do obsługi stanu Pre-Boot.
Użytkownik powinien więc zalogować się przy lokalnej konsoli i tam zakończyć konfigurację PIN, hasła lub Protector. Dopiero potem można ponownie korzystać ze zdalnego dostępu.
Nośnik rozruchowy blokuje start
Włożona bootowalna płyta CD/DVD lub zamontowany w VM bootowalny ISO może zablokować hardware test BitLocker. Jeśli po restarcie test wraca do początku, usuń nośnik, sprawdź kolejność bootowania i powtórz prompt Sophos na lokalnej konsoli.
Device Encryption Service z BadImageFormatException
Jeżeli według Application Event Log proces Sophos.Encryption.BitLockerService.exe kończy się z System.BadImageFormatException, plik log4net.dll w katalogu Sophos Data Protection może być uszkodzony. Oficjalny Sophos KBA wykorzystuje nienaruszoną kopię z AutoUpdate Cache.
Po zabezpieczeniu logów i potwierdzeniu dokładnie zgodnego obrazu błędu uszkodzony plik w
C:\Program Files (x86)\Sophos\Sophos Data Protection\
należy zastąpić plikiem log4net.dll z
C:\ProgramData\Sophos\AutoUpdate\Cache\decoded\enc\ProgramFilesFolder\Sophos\Sophos Data Protection\
Po ponownym uruchomieniu Sophos Device Encryption Service musi znów działać. Jeżeli brakuje pliku w Cache albo błąd jest inny, nie należy improwizować tej naprawy, tylko użyć SDU i Sophos Support.
Brak lub niedziałający FileVault Recovery Key
Na już zarządzanym komputerze Mac użytkownik może lokalnie utworzyć nowy Personal FileVault Key. Jeżeli Sophos Agent nie może go zweryfikować, Central usuwa z bazy nieaktualny już Key. Nowy klucz trzeba wtedy uzyskać od użytkownika albo z systemu zarządzania, który rzeczywiście go przejął.
Także późniejsze powiązanie lokalnego użytkownika z Apple ID lub iCloud może zmienić zarządzanie FileVault Key. Lokalnie działający FileVault nie dowodzi więc, że Central ma aktualny Recovery Key. Należy wspólnie sprawdzić użytkownika, Secure Token, Volume Owner, MDM Escrow i czas Central Key.
Jeśli Mac powiązany z AD używa tylko konta sieciowego, nie może ono bezpośrednio uruchomić szyfrowania. Zaloguj się raz, aby utworzyć lokalne konto mobilne, a następnie autoryzuj je administratorem z Secure Token. Potem użytkownik włącza FileVault, a agent Sophos deponuje klucz.
BitLocker nie startuje po konwersji MBR do GPT
Po konwersji Windows 10 z TPM 2.0 z MBR/Legacy BIOS do GPT/UEFI odwołania odzyskiwania w Boot Configuration Data mogą nie pasować. Device Encryption pozostaje pending mimo gotowego dysku i TPM.
Zabezpiecz Recovery Key, BCD i reagentc /info. Uruchom reagentc /disable i reagentc /enable, sprawdź nową lokalizację i zrestartuj. Nie kontynuuj bez aktywnego Windows RE i zabezpieczonego klucza. Po restarcie ponownie sprawdź CDE.log i reagentc /info, zanim szyfrowanie będzie kontynuowane.
Zwiększenie logowania Device Encryption
CDE.log i trace ustawia się od FATAL do TRACE przez udokumentowane 32- lub 64-bitowe klucze rejestru. Ścieżka musi pasować do architektury agenta; potem restartuje się usługę.
Włącz DEBUG lub TRACE tylko na krótki odtwarzalny okres: logi zawierają użytkownika, wolumin i politykę i szybko rosną. Przywróć poziom i przesyłaj pliki jako dane wrażliwe.
Kiedy eskalować?
Zgłoszenie do Support należy otworzyć, gdy dostępność Recovery Key jest niejasna, naprawa nie odpowiada dokładnie obrazowi błędu Sophos albo stan usługi i szyfrowania pozostają sprzeczne po restarcie. Pakiet zawiera CDE.log, SDU, manage-bde -status, efektywne BitLocker GPOs, Central Event, dokładny czas i wykonane już kroki.
Podstawy platform opisują Zarządzanie BitLocker za pomocą Sophos Central i Zarządzanie FileVault za pomocą Sophos Central.