Sophos Device Encryption: rozwiązywanie problemów z BitLockerem i FileVaultem

Sophos Fusion (wcześniej Sophos Central) steruje Device Encryption, ale samo nie szyfruje: w Windows działa BitLocker, a w macOS FileVault. Błąd może więc występować na czterech różnych poziomach: polityki i przypisania użytkownika, agenta Sophos i synchronizacji, systemu operacyjnego albo zarządzania Recovery Key.

Bezpieczna ścieżka: zapisz stan Central i dokładną treść alertu, sprawdź lokalny stan BitLockera lub FileVaulta wyłącznie do odczytu i potwierdź istnienie ważnej drogi odzyskiwania. Dopiero wtedy zajmij się dokładnie tą gałęzią, której dotyczy problem. Wielokrotne wyłączanie i włączanie polityki nie jest diagnostyką i może zmienić stan, zarządzanie kluczami albo trwające szyfrowanie bądź odszyfrowywanie.

Przekazanie zwykłego przypadku odzyskiwania

Ten runbook diagnozuje odchylenia, ale nie pobiera ani nie ujawnia Recovery Key. Zwykłe żądanie odzyskiwania należy skierować do procedury Sophos Device Encryption: bezpieczne pobieranie klucza odzyskiwania.

Po autoryzowanym przekazaniu jednoznacznie przypisanego klucza odblokowanie odbywa się na właściwej platformie: w Windows według artykułu Zarządzanie BitLockerem za pomocą Sophos Fusion, a w macOS według procedury zarządzania FileVaultem. Kroki pobrania, ujawniania i odblokowywania nie są tutaj powtarzane.

Nie myl stanu Central z alertem

Stan szyfrowania opisuje ostatni stan urządzenia zgłoszony do Central. Alert informuje natomiast o konkretnym odchyleniu. Nieaktualny stan Central przy jednocześnie aktualnym lokalnym wskazaniu sugeruje więc w pierwszej kolejności problem z komunikacją lub synchronizacją, a nie automatycznie awarię szyfrowania.

Siedem wartości stanu

Pending nie oznacza zatem ogólnie, że „polityka czeka na zastosowanie”, a Suspended nie oznacza, że dysk jest odszyfrowany. Sam stan Encrypted również nie wystarcza do odbioru: Recovery Key musi być dostępny w odpowiedzialnym procesie odzyskiwania.

Trzy alerty Device Encryption

Device is not encrypted oznacza, że wolumin nie jest zaszyfrowany, mimo że zgodnie z polityką powinien być. Możliwą przyczyną jest odroczenie szyfrowania przez użytkownika po przypisaniu polityki. Następnie sprawdza się objęty problemem wolumin, otwarty monit użytkownika i lokalny postęp szyfrowania.

Recovery key is missing oznacza, że Central nie znajduje w swojej bazie Recovery Key dla zaszyfrowanego woluminu. Jest to ryzyko dla odzyskiwania, a nie dowód, że dysk nie jest zaszyfrowany. Należy sprawdzić komunikację, ostatnią synchronizację i właściwy magazyn Recovery Key, bez zapisywania klucza w notatkach sprawy.

Device Encryption is suspended zgłasza wstrzymanie szyfrowania BitLockerem. Jeśli nie było ono zamierzone, Sophos wskazuje trzy typowe przyczyny:

• Recovery Key nie został jeszcze zapisany w Central. Endpoint potrzebuje działającego połączenia z Internetem.
• Wstępnie przygotowany BitLocker nie został jeszcze aktywowany. Użytkownik musi określić PIN, hasło lub USB Key zależnie od przewidzianego trybu.
• Instalowane są aktualizacje Windows. BitLocker automatycznie zniesie wstrzymanie po następnym restarcie.

Dopiero po wykluczeniu tych trzech przypadków szuka się nieplanowanej ingerencji administratora lub głębszego błędu Windows.

Jedna procedura dla każdego objawu

1. Zamrożenie stanu i zabezpieczenie odzyskiwania

Przed pierwszą zmianą należy zapisać:

• nazwę urządzenia i Central Device ID;
• system operacyjny, kompilację i czas wystąpienia problemu;
• przypisaną politykę i użytkownika, którego dotyczy problem;
• dokładny stan, tekst alertu, kod błędu i znacznik czasu;
• objęty problemem wolumin oraz informację, czy trwa jego szyfrowanie lub odszyfrowywanie;
• informację, czy osoba odpowiedzialna za odzyskiwanie potwierdziła pasujący, aktualny klucz.

W protokole roboczym zapisuje się wyłącznie klucz dostępny, brak klucza albo jeszcze nieustalone. Nie wolno przenosić do niego samego klucza ani pełnych Key IDs.

2. Porównanie Central ze stanem lokalnym

Cztery możliwe wyniki prowadzą w różnych kierunkach:

1. Obie strony zgłaszają ten sam stan: zajmij się lokalnym objawem błędu.
2. Lokalnie jest poprawnie, Central jest nieaktualne: sprawdź komunikację agenta, znacznik czasu polityki i ostatnią synchronizację.
3. Central jest poprawne, lokalny stan jest sprzeczny: sprawdź konkretny wolumin i natywny widok systemu operacyjnego; nie przenoś ogólnego stanu na wszystkie woluminy.
4. Obie strony są nieznane lub sprzeczne: nie wykonuj naprawy zmieniającej stan. Utwórz pakiet diagnostyczny i eskaluj.

3. Sprawdzenie zastosowania polityki

Zainstalowany komponent nie dowodzi, że polityka jest stosowana. Należy sprawdzić, czy:

• polityka jest włączona i przypisana przewidzianemu użytkownikowi lub jego grupie;
• użytkownik zalogowany na urządzeniu jest przypisany w Central do właściwego urządzenia;
• ustawienie o wyższym priorytecie lub ustawienie globalne nie wyjaśnia widocznej wartości;
• czas ostatniego zastosowania polityki jest późniejszy niż ostatnia zmiana;
• żadna GPO, polityka MDM ani poprzedni system zarządzania szyfrowaniem nie wymusza innego stanu.

Przypisanie poprawia się w jego źródle. Ogólne ustawianie lokalnych zasad na Not configured albo wielokrotne przełączanie polityki Central jedynie zaciera informację, który system zarządzania faktycznie wygrał.

Windows: BitLocker nie uruchamia się lub pozostaje oczekujący

Najpierw kontrola lokalna tylko do odczytu

Stan wszystkich woluminów BitLockera pokazuje w Windows administracyjny wiersz poleceń:

manage-bde -status

Dla każdego woluminu istotne są Conversion Status, Percentage Encrypted, Protection Status, Lock Status i istniejące Key Protectors. Dane wyjściowe można oczyścić przed przekazaniem do pomocy technicznej; Recovery Passwords i inne sekrety muszą zostać usunięte.

Najważniejszy log Sophos znajduje się tutaj:

C:\ProgramData\Sophos\Sophos Data Protection\Logs\CDE.log

Dodatkowo analizuje się odpowiedni okres w Windows Event Viewer, stan TPM i rzeczywiście skuteczne zasady grupy BitLockera. Następny krok wyznacza nie liczba ostrzeżeń, lecz pierwszy powtarzalny błąd po zastosowaniu polityki lub restarcie.

Użytkownik nie widzi okna aktywacji

Jeśli oczekiwany dialog się nie pojawia, należy jedynie udokumentować rodzaj sesji, zalogowanego użytkownika, dokładny tekst logu, czas i oczekujące restarty. Z pojedynczego wpisu logu nie wolno wnioskować ani o konkretnej przyczynie związanej z sesją, ani o awarii usługi. Rodzaj sesji można zmienić lub wykonać restart wyłącznie według aktualnej instrukcji Sophos dotyczącej zainstalowanej wersji; następnie ponownie porównuje się manage-bde -status, nowy znacznik czasu CDE.log i Central.

Polityka i GPO są sprzeczne

Typowe obszary konfliktu to Startup Authentication, dozwolone Protectors, wymagania TPM, FIPS, metoda szyfrowania i kopia zapasowa Recovery Key. Należy udokumentować skuteczną GPO i porównać ją z polityką Central. Następnie poprawia się system zarządzania odpowiedzialny merytorycznie; przypadek diagnostyczny nie służy do obchodzenia modelu bezpieczeństwa za pomocą lokalnego obejścia.

Standardową konfigurację, wybór protectora i uzgadnianie GPO opisuje artykuł Zarządzanie BitLockerem za pomocą Sophos Fusion.

BitLocker ma stan Suspended

Suspended nie oznacza odszyfrowania, lecz wstrzymanie ochrony na co najmniej jednym woluminie. Najpierw sprawdza się trwającą aktualizację Windows lub firmware, oczekujące restarty, Pre-Provisioning i zapis Recovery Key w Central.

• Jeśli udokumentowana aktualizacja jeszcze się nie zakończyła, należy dokończyć przewidzianą sekwencję restartów i ponownie sprawdzić stan.
• Jeśli administrator świadomie wstrzymał BitLockera, o wznowieniu decyduje właściciel zmiany.
• Jeśli brakuje wyjaśnienia, wstrzymanie traktuje się jako odchylenie bezpieczeństwa. Nie należy wymuszać wznowienia w ciemno, lecz zabezpieczyć czas, zdarzenie i stan protectorów do eskalacji.

Błąd aktywacji związany z TPM, firmware lub DMA

Przy sprzętowym błędzie aktywacji należy udokumentować dokładny kod błędu, aktualny stan TPM/UEFI, przewidziany tryb uwierzytelniania oraz wersje firmware i sterowników. Bez aktualnej instrukcji właściwej dla modelu, wersji Windows i Sophos nie wolno wywodzić z tych danych przyczyny ani sposobu naprawy. Starsze sygnatury są dlatego ujęte wyłącznie w historycznej sekcji przeznaczonej do pracy pod kierunkiem pomocy technicznej.

Przy komunikacie o niechronionym urządzeniu obsługującym DMA producent musi potwierdzić, czy magistrala i urządzenie są wewnętrzne oraz bezpieczne. Wpis w rejestrze pod AllowedBuses, zmiana ACL ani ogólne dopuszczenie nieznanych magistral nie są uniwersalną naprawą. Zachowanie różni się również między wersjami Windows. Bez aktualnej instrukcji OEM lub Sophos właściwej dla modelu i wersji nie wolno zmieniać rejestru.

macOS: FileVault czeka na użytkownika lub Recovery Key

Zawężanie problemu z autoryzacją użytkownika

FileVault wymaga lokalnie autoryzowanego użytkownika. Na komputerach Apple Silicon musi on być Volume Owner; dla zarządzania istotny jest ponadto właściwy stan Secure Token. Dlatego sprawdza się:

• czy aktualnie lokalnie zalogowany użytkownik jest objęty polityką Device Encryption;
• czy ten użytkownik rzeczywiście może odblokować FileVault przy uruchomieniu;
• czy oczekiwany użytkownik jest widoczny w aplikacji Sophos Device Encryption;
• czy istnieją uprawnienia Secure Token lub Volume Owner;
• czy okno Sophos czeka na hasło logowania macOS albo na Encrypt, Create key lub Proceed.

Nie należy zapobiegawczo tworzyć nowego konta lokalnego lub mobilnego ani zmieniać uprawnień użytkownika, dopóki brakujące wymaganie nie zostanie jednoznacznie ustalone. Obsługiwana autoryzacja kolejnych użytkowników pozostaje częścią procedury zarządzania FileVaultem.

FileVault jest aktywny, ale Central nie ma klucza

„FileVault aktywny” i „Recovery Key zarządzany w Central” to dwa różne stwierdzenia. Dla każdego woluminu wymaganego przez politykę porównuje się lokalny stan szyfrowania, wskazanie odzyskiwania w aplikacji Sophos Device Encryption i ostatni znacznik czasu Central.

Udokumentowane zapytania Sophos służą tylko do odczytu:

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

status pomaga porównać ostatnią synchronizację. --device-encryption pokazuje politykę oraz stan szyfrowania i odzyskiwania wewnętrznych woluminów. Zaszyfrowany wolumin bez potwierdzonego zapisu w Central nie przechodzi odbioru jako udane wdrożenie.

Jeśli po nieudanej próbie zapisu Sophos wyświetla osobisty Recovery Key, za jego bezpieczne przejściowe przechowywanie nadal odpowiada właściciel FileVaulta. Klucza nie wolno kopiować do pakietu diagnostycznego. Obsługiwane postępowanie z tym jedynym kluczem i późniejsze potwierdzenie w Central opisuje powiązany artykuł o FileVaulcie; ten runbook nie zastępuje procesu odzyskiwania.

Szyfrowanie lub odszyfrowywanie zatrzymało się

Niezmienny procent nie jest jeszcze powodem do restartowania systemu zarządzania szyfrowaniem. Najpierw należy przez dostatecznie długi okres porównywać:

• lokalny postęp konkretnego woluminu;
• zasilanie, wolne miejsce i oczekujący restart;
• ostatni znacznik czasu polityki i agenta;
• zdarzenia systemu operacyjnego z tego samego czasu;
• konkurencyjny system zarządzania szyfrowaniem;
• oczekiwany stan docelowy: szyfrowanie, przejęcie lub odszyfrowywanie.

Przy planowanym odszyfrowywaniu właściciel zmiany potwierdza stan docelowy, odpowiedzialność za Recovery Key i procedurę dla platformy. Wykonanie w Windows należy do artykułu o BitLockerze, a w macOS — do artykułu o FileVaulcie. Nieoczekiwanego odszyfrowywania nie należy przykrywać gorączkowymi zmianami polityki; urządzenie, zmianę polityki i zdarzenia bada się jako odchylenie bezpieczeństwa.

Unmanaged, istniejące szyfrowanie i migracja

Unmanaged oznacza tylko, że komponent Device Encryption jest zainstalowany, ale nie jest stosowana żadna polityka Device Encryption. Dysk może być zaszyfrowany lub niezaszyfrowany. Stan ten nie jest poleceniem natychmiastowego przypisania polityki.

Przed przejęciem lub migracją należy zinwentaryzować stan źródłowy:

1. Platformę, woluminy i lokalny stan szyfrowania.
2. Aktywne Protectors lub uprawnionych użytkowników FileVaulta.
3. Dotychczasowy system zarządzania i skuteczne ustawienia GPO/MDM.
4. Zweryfikowaną drogę odzyskiwania w dotychczasowym systemie zarządzania.
5. Przewidziany stan docelowy i dokładnie jeden odpowiedzialny system docelowy.

Następnie wybiera się dokładnie jedną gałąź platformy. Wykonanie pozostaje w procedurze BitLockera albo FileVaulta. Dopóki nowy Recovery Key nie zostanie potwierdzony w systemie docelowym, nie wolno porzucać dotychczasowej drogi odzyskiwania ani wycofywać starego systemu zarządzania.

Także listy w Central mają różne znaczenie: Computers without Device Encryption installed pokazuje zarządzane urządzenia bez komponentu Encryption. Unmanaged computers może natomiast zawierać komputery zsynchronizowane z katalogu, ale bez ochrony Sophos. Przed instalacją lub zastosowaniem polityki należy więc najpierw ustalić, na której liście i z jakiego powodu pojawia się urządzenie.

Historyczne sygnatury: rozpoznawaj, nie naprawiaj samodzielnie

Poniższe sygnatury pochodzą ze starszych doświadczeń operacyjnych Avanet. Pomagają sklasyfikować przypadek dla pomocy technicznej, ale nie są aktualnym zatwierdzeniem naprawy:

• ManagementStatus.InvalidNamespace, 0x8004100E lub 0x80041002 w związku z Win32_EncryptableVolume;
• 0x803100B6 na urządzeniach rozpoznanych jako Slate;
• System.BadImageFormatException w Sophos.Encryption.BitLockerService.exe;
• błędy BitLockera po zmianie MBR na GPT lub Legacy BIOS na UEFI;
• błędy aktywacji przy zamontowanym rozruchowym ISO lub nośniku;
• No UI user session available;
• 0x80310048 lub FVE_E_FIRMWARE_TYPE_NOT_SUPPORTED;
• starsze problemy DMA/AllowedBuses;
• potrzeba rozszerzonego logowania DEBUG lub TRACE.

Klasa Microsoft Win32_EncryptableVolume wyjaśnia kontekst WMI, ale nie zezwala ani na ponowną rejestrację MOF, ani na naprawę WMI. Nie wolno też kopiować bibliotek DLL z pamięci podręcznej, przejmować uprawnień rejestru, zmieniać BCD lub partycji Recovery ani ustawiać nieudokumentowanych kluczy logowania. Sophos Support musi przekazać aktualną instrukcję dla zainstalowanej wersji, dokładnej kompilacji i pełnej sygnatury.

Pakiet diagnostyczny i punkt eskalacji

Windows

• eksport lub zrzut ekranu alertu Central bez sekretów;
• przypisanie urządzenia, polityki i użytkownika ze znacznikami czasu;
• oczyszczone dane wyjściowe manage-bde -status;
• właściwy fragment CDE.log;
• odpowiednie zdarzenia Windows i rzeczywiście skuteczne GPO BitLockera;
• stan TPM, UEFI i firmware oraz ostatni rzeczywisty restart;
• Endpoint Self Help lub Sophos Diagnostic Utility (SDU), jeśli są dostępne w używanym agencie;
• krótka lista już wykonanych kontroli zachowujących stan.

macOS

• przypisanie urządzenia, polityki i użytkownika ze znacznikami czasu;
• wersje macOS i komponentów Sophos;
• oczyszczone dane wyjściowe seadmin status i seadmin --device-encryption;
• stan objętych problemem woluminów w aplikacji Sophos Device Encryption;
• informacja, czy użytkownik ma Secure Token, uprawnienia Volume Owner i Pre-Boot;
• czas ostatniej pomyślnej komunikacji z Central;
• pakiet SDU i powtarzalna procedura bez Recovery Key.

Przed przekazaniem dane użytkownika ogranicza się do niezbędnego minimum, a Recovery Keys, hasła, pełne Key IDs i inne sekrety usuwa.

Przypadek eskaluje się do Sophos Support, gdy odpowiedzialność za Recovery Key lub jego dostępność pozostaje niejasna, Central i system operacyjny po udanej synchronizacji zgłaszają sprzeczne stany, usługa agenta wielokrotnie przestaje działać, występuje historyczna sygnatura albo następny krok zmieniłby WMI, rejestr, pliki programu, BCD lub partycje. W zgłoszeniu należy podać pierwsze zaobserwowane odchylenie, a nie tylko ostatni błąd następczy.

Często zadawane pytania