Sophos Device Encryption: Åtgärda BitLocker- och FileVault-fel

Sophos Fusion (tidigare Sophos Central) styr Device Encryption, men utför inte krypteringen själv: BitLocker används i Windows och FileVault i macOS. Ett fel kan därför finnas på fyra olika nivåer: policy och användartilldelning, Sophos-agent och synkronisering, operativsystem eller hantering av Recovery Keys.

Säker snabbväg: Anteckna statusen i Central och alertens exakta ordalydelse, kontrollera den lokala BitLocker- eller FileVault-statusen utan att ändra något och bekräfta att det finns en giltig återställningsväg. Felsök först därefter den berörda grenen. Att upprepade gånger stänga av och slå på policyn är ingen diagnostisk åtgärd och kan påverka status, nyckelhantering eller en pågående kryptering eller dekryptering.

Hänvisa vanliga återställningsfall rätt

Den här runbooken diagnostiserar avvikelser men hämtar eller avslöjar inte någon Recovery Key. En vanlig återställningsbegäran går till Sophos Device Encryption: Hämta Recovery Key säkert.

Efter den behöriga överlämningen av den unikt tilldelade nyckeln sker upplåsning på respektive plattform: på Windows i artikeln Hantera BitLocker med Sophos Fusion, på macOS i FileVault-hanteringsflödet. Stegen för hämtning, avslöjande och upplåsning dupliceras inte här.

Blanda inte ihop status i Central och alerts

Krypteringsstatus beskriver det enhetstillstånd som senast rapporterades till Central. En Alert avser däremot en specifik avvikelse. Om statusen i Central är gammal men den lokala visningen är aktuell tyder det i första hand på ett kommunikations- eller synkroniseringsproblem, inte automatiskt på fel i krypteringen.

De sju statusvärdena

Pending betyder inte “policyn väntar i princip på att tillämpas”, och Suspended betyder inte “volymen är dekrypterad”. Encrypted enbart är inte tillräckligt för godkännande: Recovery Key måste vara tillgänglig för den ansvariga återställningsprocessen.

De tre Device Encryption-alerts

Device is not encrypted betyder att en volym inte är krypterad trots att policyn kräver det. En möjlig orsak är att användaren har skjutit upp krypteringen efter policytilldelningen. Därefter kontrolleras den berörda volymen, en väntande användarprompt och det lokala krypteringsförloppet.

Recovery key is missing betyder att Central inte kan hitta en Recovery Key för en krypterad volym i sin databas. Detta är en återställningsrisk, inte ett bevis för en okrypterad enhet. Kontrollera kommunikationen, den senaste synkroniseringen och den ansvariga förvaringen av Recovery Keys utan att anteckna nyckeln i ärendet.

Device Encryption is suspended rapporterar att BitLocker-skyddet är pausat. Om detta inte gjordes avsiktligt anger Sophos tre typiska orsaker:

• Recovery Key har ännu inte sparats i Central. Slutpunkten kräver en fungerande internetanslutning.
• Förkonfigurerad BitLocker är ännu inte aktiverad. Användaren måste ange PIN, lösenfras eller USB Key beroende på avsett läge.
• Windows-uppdateringar är installerade. BitLocker tar automatiskt bort pausen efter nästa omstart.

Först när dessa tre fall har uteslutits undersöks ett oplanerat administrativt ingripande eller ett djupare Windows-fel.

Ett flöde för varje felbild

1. Dokumentera tillståndet och säkra återställningen

Före den första ändringen, notera:

• Enhetsnamn och central enhets-ID;
• Operativsystem, build och tidpunkt för problem;
• tilldelad policy och berörda användare;
• Exakt status, alertstext, felkod och tidsstämpel;
• Berörd volym och om den för närvarande krypteras eller dekrypteras;
• om den som ansvarar för återställning har bekräftat en lämplig, aktuell nyckel.

Arbetsloggen säger bara Nyckel finns, Nyckel saknas eller fortfarande oklart. Själva nyckeln och fullständiga nyckel-ID:n används inte.

2. Jämför central och lokalt tillstånd

Fyra resultat leder i olika riktningar:

1. Båda sidor rapporterar samma tillstånd: Felsök det lokala felet.
2. Lokalt rätt, Central inaktuellt: Kontrollera agentkommunikation, policytidsstämpel och senaste synkronisering.
3. Centralt rätt, lokalt inkonsekvent: Kontrollera den specifika volymen och den inbyggda operativsystemsskärmen; dra inte slutsatser om alla volymer från en övergripande status.
4. Båda sidor okända eller motstridiga: Utför ingen tillståndsförändrande åtgärd. Skapa ett diagnostikpaket och eskalera ärendet.

3. Kontrollera policytillämpningen

En installerad komponent bevisar inte att en policy tillämpas. Kontrollera följande:

• Policyn är aktiverad och tilldelad till den avsedda användaren eller användarens grupp;
• användaren som är inloggad på enheten är kopplad till rätt enhet i Central;
• ingen högre prioritet eller global standard förklarar den synliga inställningen;
• Tidpunkten för den senaste policytillämpningen ligger efter den senaste ändringen;
• ingen GPO, MDM-policy eller tidigare krypteringshantering upprätthåller ett annat tillstånd.

En felaktig inställning korrigeras i det system som ansvarar för den. Att generellt sätta lokala principer till Not configured eller växla en Central-policy flera gånger döljer bara vilket hanteringssystem som faktiskt styr inställningen.

Windows: BitLocker startar inte eller förblir vilande

Kontrollera först lokalt och skrivskyddat

I en administrativ kommandotolk visar Windows statusen för alla BitLocker-volymer:

manage-bde -status

Det som är viktigt för varje volym är Conversion Status, Percentage Encrypted, Protection Status, Lock Status och de befintliga Key Protectors. Utdata kan anonymiseras innan de skickas till supporten; återställningslösenord och andra hemligheter ska tas bort.

Det viktigaste Sophos-protokollet finns här:

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

Dessutom granskas den relevanta tidsperioden i Windows Event Viewer, TPM-tillståndet och de BitLocker-gruppolicyer som faktiskt tillämpas. Det är inte antalet alerts, utan det första reproducerbara felet efter att policyn har tillämpats eller en omstart har gjorts som avgör nästa steg.

Användaren ser inte en aktiveringsdialog

Om den förväntade dialogrutan saknas, dokumenteras endast sessionstyp, inloggad användare, exakt loggtext, tid och väntande omstarter. Varken en specifik sessionsorsak eller ett tjänstfel härleds från en enda loggpost. En ändring av sessionstyp eller omstart sker endast enligt de aktuella Sophos-instruktionerna som gäller för den installerade versionen; sedan jämförs manage-bde -status, den nya tidsstämpeln CDE.log och Central igen.

Policy och GPO motsäger varandra

Typiska konfliktområden är Startup Authentication, tillåtna Protectors, TPM-krav, FIPS, krypteringsmetod och Recovery-Key-Backup. Dokumentera gällande GPO och jämför den med policyn i Central. Korrigera därefter det ansvariga hanteringssystemet; felsökningsfallet är inte platsen att kringgå säkerhetskonceptet med en lokal lösning.

Normal konfiguration, skyddsval och GPO-inställning förklaras Hantera BitLocker med Sophos Fusion.

BitLocker är Suspended

Suspended betyder inte att en volym är dekrypterad, utan att skyddet är pausat på minst en volym. Först kontrolleras en körande Windows- eller firmwareuppdatering, väntande omstarter, Pre-Provisioning och den centrala lagringen av Recovery Key.

• Om en dokumenterad uppdateringsprocess ännu inte har slutförts avslutas dess avsedda omstartssekvens och kontrolleras sedan igen.
• Om en administratör medvetet har pausat BitLocker-skyddet, bestämmer den person som ansvarar för ändringen om skyddet ska återupptas.
• Om en förklaring saknas betraktas pausen som en säkerhetsavvikelse. Tvinga inte fram ett återupptagande i blindo, utan dokumentera tidpunkt, event och Protector-status inför eskaleringen.

Aktiveringsfel med TPM, firmware eller DMA-kontext

Vid ett hårdvarurelaterat aktiveringsfel dokumenteras den exakta felkoden, aktuellt TPM/UEFI-tillstånd, avsett autentiseringsläge samt firmware- och drivrutinsversioner. Varken orsak eller åtgärd fastställs utan aktuella instruktioner för den specifika modellen samt Windows- och Sophos-versionen. Äldre signaturer klassificeras därför endast i det supportstyrda historiska avsnittet.

Om en oskyddad DMA-kompatibel enhet rapporteras måste enhetstillverkaren bekräfta om bussen och enheten är interna och säkra. En registerpost under AllowedBuses, ändringar av ACL:er eller ett generellt tillåtande av okända bussar är ingen allmän lösning. Beteendet skiljer sig också mellan Windows-versioner. Registret ändras inte utan aktuella, modell- och versionsspecifika instruktioner från OEM-tillverkaren eller Sophos.

macOS: FileVault väntar på användar- eller Recovery Key

Begränsa användarbehörighet

FileVault kräver en lokalt behörig användare. På en Mac med Apple-chip krävs dessutom Volume Owner; korrekt Secure Token-status är också relevant för administrationen. Kontrollera därför följande:

• Omfattas den för närvarande lokalt inloggade användaren av Device Encryption-policyn?
• Kan den här användaren verkligen låsa upp FileVault vid start?
• Är den förväntade användaren synlig i Sophos Device Encryption-appen?
• Finns Secure Token- respektive Volume Owner-behörighet?
• Väntar en Sophos-dialogruta på macOS-inloggningslösenordet eller för Encrypt, Create key eller Proceed?

Skapa inte ett nytt lokalt eller mobilt konto för säkerhets skull och ändra inte användarbehörigheter förrän den saknade förutsättningen har fastställts entydigt. Den process som stöds för att ge ytterligare användare behörighet finns i FileVault-hanteringsflödet.

FileVault är aktivt, men Central har ingen nyckel

“FileVault active” och “Recovery Key managed in Central” är två olika uttalanden. För varje volym som krävs av policyn jämförs lokal krypteringsstatus, återställningsindikation i Sophos Device Encryption-appen och sista centrala tidsstämpeln.

De dokumenterade Sophos-frågorna lyder:

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

status hjälper till att jämföra den senaste synkroniseringen. --device-encryption visar policy samt kryptering och återställningsstatus för de interna volymerna. En krypterad volym utan bekräftad central lagring godkänns inte som en framgångsrik utrullning.

Om Sophos visar en personlig Recovery Key efter en misslyckad lagring ansvarar den FileVault-ansvariga personen för en säker tillfällig förvaring. Nyckeln kopieras inte till diagnospaketet. Den stödda hanteringen av denna enda nyckel och den efterföljande centrala verifieringen beskrivs i den länkade FileVault-artikeln; denna runbook ersätter inte återställningsprocessen.

Kryptering eller dekryptering stoppas

Ett oförändrat procentuellt värde är ännu inte en anledning att starta om krypteringshanteringen. Först jämförs följande över en tillräckligt lång tidsperiod:

• det lokala förloppet för den berörda volymen;
• strömförsörjning, ledigt lagringsutrymme och väntande omstart;
• senaste tidsstämpel för policy och agent;
• OS-events samtidigt;
• konkurrerande krypteringshantering;
• förväntat måltillstånd: kryptera, adoptera eller dekryptera.

Vid en planerad dekryptering bekräftar ändringsansvarig måltillstånd, ansvar för Recovery Key och plattformsflöde. Windows-versionen hör hemma i BitLocker-artikeln, macOS-versionen i FileVault-artikeln. Vid en oväntad dekryptering åsidosätts inte processen av hektiska policyändringar; enhet, policyändring och events undersöks som en säkerhetsavvikelse.

Unmanaged, befintlig kryptering och migrering

Unmanaged betyder bara: Device Encryption-komponenten är installerad, men ingen Device Encryption-policy tillämpas. Databäraren kan vara krypterad eller okrypterad. Detta är inte en begäran om att tilldela en policy omedelbart.

Före adoption eller migrering inventeras källtillståndet:

1. Plattform, volymer och lokal krypteringsstatus.
2. Aktiva Protectorer eller behöriga FileVault-användare.
3. Tidigare hanteringssystem och gällande GPO-/MDM-inställningar.
4. Verifierad återställningsväg under tidigare hantering.
5. Avsett måltillstånd och ett enda ansvarigt målsystem.

Därefter väljs exakt en plattformsgren. Genomförandet sker enligt BitLocker- eller FileVault-flödet. Så länge den nya Recovery Key inte har bekräftats i målsystemet får den tidigare återställningsvägen inte kasseras och den gamla hanteringen inte tas ur drift.

Listorna i Central har också olika betydelser: Computers without Device Encryption installed visar hanterade enheter utan krypteringskomponenten. Unmanaged computers kan däremot innehålla datorer som har synkroniserats från katalogen men saknar Sophos-skydd. Före en installation eller policyåtgärd ska det därför klarläggas i vilken lista enheten förekommer och varför.

Historiska signaturer: identifiera, men reparera inte på egen hand

Följande signaturer bygger på äldre operativa erfarenheter från Avanet. De hjälper till att klassificera ett supportärende, men utgör inget aktuellt godkännande för en åtgärd:

• ManagementStatus.InvalidNamespace, 0x8004100E eller 0x80041002 relaterade till Win32_EncryptableVolume;
• 0x803100B6 på enheter som identifierats som Slate-enheter;
• System.BadImageFormatException vid Sophos.Encryption.BitLockerService.exe;
• BitLocker-fel efter MBR till GPT eller äldre BIOS till UEFI-konvertering;
• Aktiveringsfel när startbar ISO eller disk är monterad;
• No UI user session available;
• 0x80310048 eller FVE_E_FIRMWARE_TYPE_NOT_SUPPORTED;
• äldre DMA/AllowedBuses-felbilder;
• behov av utökad DEBUG- eller TRACE-loggning.

Microsoft-klassen Win32_EncryptableVolume förklarar WMI-sammanhanget men godkänner varken en MOF-omregistrering eller en WMI-reparation. Inte heller får DLL-filer kopieras från cacheminnen, registerbehörigheter övertas, BCD-/återställningspartitioner ändras eller odokumenterade loggningsnycklar anges. Sophos Support måste tillhandahålla aktuella instruktioner för den installerade versionen, exakt build och fullständig signatur.

Diagnostikpaket och eskaleringspunkt

Windows

• export eller skärmbild av en alert i Central, utan hemliga uppgifter;
• Enhets-, policy- och användarkartläggning med tidsstämplar;
• rensad utdata av manage-bde -status;
• relevant utdrag från CDE.log;
• Matchande Windows-events och faktiska gällande BitLocker GPOs;
• Status för TPM, UEFI och firmware samt senaste riktiga omstart;
• Endpoint Self Help eller Sophos Diagnostic Utility (SDU), om tillgängligt i den agent som används;
• kort lista över tillståndsbevarande kontroller som redan har utförts.

macOS

• Enhets-, policy- och användarkartläggning med tidsstämplar;
• macOS och Sophos komponentversion;
• rensad utdata av seadmin status och seadmin --device-encryption;
• Status för berörda volymer i Sophos Device Encryption-appen;
• Information om huruvida användaren har Secure Token/Volume Owner och behörighet före start;
• Tidpunkt för den senaste framgångsrika centrala kommunikationen;
• SDU-paket och reproducerbar process utan Recovery Key.

Innan delning reduceras användardata till vad som är nödvändigt och Recovery Keys, lösenord, fullständiga nyckel-ID och andra hemligheter tas bort.

Ärendet eskaleras till Sophos Support om ansvaret för eller tillgången till Recovery Key förblir oklar, Central och operativsystemet rapporterar motstridiga tillstånd efter en lyckad synkronisering, agenttjänsten misslyckas upprepade gånger, en historisk signatur förekommer eller nästa steg skulle ändra WMI, registret, programfiler, BCD eller partitioner. Ärendet ska ange den första observerade avvikelsen, inte bara det senaste följdfelet.

Vanliga frågor