Verifica recupero BitLocker AD: criteri, volumi e deposito

Che cos’è la verifica recupero BitLocker AD?

La verifica recupero BitLocker AD collega tre prove indipendenti: il criterio applicabile a un computer, la protezione effettivamente presente su ciascun volume e le informazioni di ripristino archiviate in Active Directory Domain Services (AD DS) per il suo attuale dispositivo di protezione del ripristino. Un rilievo sul criterio avvia questa indagine; non può rispondere a tutte e tre le domande.

L’unità utile di revisione è un computer identificato e un volume identificato, a un’ora registrata. Un’impostazione a livello di dominio, un’unità crittografata localmente e un vecchio oggetto di ripristino nella directory possono esistere contemporaneamente mentre il percorso di ripristino previsto resta non verificato. Registrare queste osservazioni separatamente prima di decidere che cosa correggere.

Il nostro articolo sull’igiene degli oggetti computer, inclusi BitLocker e il deposito delle informazioni di ripristino colloca questo lavoro nella revisione più ampia del ciclo di vita dei computer. Qui il compito è più circoscritto: stabilire se il record di ripristino corrisponde al dispositivo di protezione attualmente presente sul volume. Non dedurre lo stato della crittografia dalla presenza o dall’assenza di un oggetto nella directory.

Come funziona: criteri, stato dei volumi e deposito delle informazioni di ripristino

Stabilire il percorso di gestione e l’ambito dei volumi

Annotare quali volumi del sistema operativo, di dati fissi e rimovibili rientrano nell’ambito, a quali computer appartengono e se la loro configurazione proviene da GPO o CSP. Indicare esplicitamente i volumi esclusi; controllare soltanto l’unità del sistema operativo non consente di soddisfare un requisito che comprende le unità dati.

La documentazione sulla configurazione di BitLocker di Microsoft identifica ./Device/Vendor/MSFT/BitLocker/RequireDeviceEncryption come criterio CSP e indica Not available per il suo equivalente GPO. Questo non significa che BitLocker non disponga di impostazioni GPO. Le impostazioni di ripristino per le unità del sistema operativo e di dati fissi offrono il backup in AD DS e un’opzione che impedisce l’attivazione finché il backup non riesce. Windows Server utilizza GPO anziché CSP per la configurazione di BitLocker.

Per una destinazione gestita tramite GPO, raccogliere le prove del gruppo di criteri risultante nell’ambito computer usando la sintassi di gpresult documentata da Microsoft:

gpresult /scope computer /z

Esaminare le impostazioni di ripristino pertinenti e i criteri prevalenti. Per i client gestiti tramite CSP, ottenere l’assegnazione corrispondente e i risultati dei criteri del dispositivo dal sistema di gestione. Un report GPO non dimostra l’applicazione di CSP. Risolvere le discrepanze della gestione mista prima di descrivere il criterio previsto come effettivo. La stessa distinzione tra un valore raccolto e la protezione della destinazione compare nei nostri quattro controlli di sicurezza GPO e nella loro verifica sulla destinazione.

Considerare la cronologia del volume

Le domande frequenti su BitLocker di Microsoft spiegano che le informazioni di ripristino di un’unità crittografata prima dell’applicazione del criterio di backup non vengono caricate automaticamente in AD DS quando il computer entra nel dominio o riceve successivamente quel criterio. AD DS conserva inoltre le vecchie voci delle password di ripristino. Un evento passato di backup riuscito può persistere più a lungo del record nella directory o del dispositivo di protezione che lo rendeva utile.

Chiedere quando è iniziata la crittografia, quando sono iniziati l’appartenenza al dominio e il criterio di ripristino, e se i dispositivi di protezione sono cambiati. Queste risposte determinano dove cercare una lacuna. Né una distribuzione recente dei criteri né il timestamp più recente nella directory sostituiscono la corrispondenza con il dispositivo di protezione attuale. Quando la cronologia non è disponibile, registrarla come sconosciuta ed eseguire i controlli diretti seguenti.

Rilevamento: raccogliere tre prove indipendenti

Passaggio 1: misurare crittografia e protezione su ciascun volume

Eseguire localmente il comando di stato manage-bde documentato per l’unità selezionata:

manage-bde -status C:

Registrare lo stato di conversione, la percentuale di crittografia, il metodo di crittografia, lo stato di protezione e lo stato di blocco. L’avanzamento della crittografia e la protezione attiva sono campi distinti; un volume crittografato con la protezione disattivata richiede un intervento diverso da quello necessario per un volume completamente decrittografato. Un comando che non riesce non può fornire nessuna delle due osservazioni.

PowerShell offre il cmdlet documentato Get-BitLockerVolume. Questo esempio limita le proprietà visualizzate tramite Select-Object:

Get-BitLockerVolume -MountPoint "C:" -ErrorAction Stop |
    Select-Object MountPoint,VolumeType,VolumeStatus,EncryptionPercentage,EncryptionMethod,ProtectionStatus,LockStatus

Ripetere per ciascun volume selezionato. Conservare insieme al risultato l’identità del computer, il punto di montaggio, il timestamp e l’esito della raccolta, affinché un revisore successivo possa riprodurre l’ambito. Nel report, non trasformare un endpoint irraggiungibile in un endpoint non crittografato.

Passaggio 2: identificare i dispositivi di protezione del ripristino attuali senza mostrare segreti

La documentazione di Backup-BitLockerKeyProtector descrive l’array KeyProtector, KeyProtectorId e KeyProtectorType. Usare queste proprietà per identificare i dispositivi di protezione di tipo password di ripristino, anziché presumere una posizione fissa nell’array:

(Get-BitLockerVolume -MountPoint "C:" -ErrorAction Stop).KeyProtector |
    Select-Object KeyProtectorType,KeyProtectorId

Questa proiezione mostra identificatori e tipi, non la password di ripristino. Registrare ogni dispositivo di protezione attuale di tipo password di ripristino per il volume selezionato; può essercene più di uno. Un dispositivo di protezione TPM non è l’identificatore della password di ripristino da confrontare con AD DS. Se il dispositivo di protezione di tipo password di ripristino previsto è assente, classificare esplicitamente questa osservazione anziché scegliere un altro tipo per far apparire completa la tabella.

Passaggio 3: leggere i metadati di ripristino AD DS del computer corretto

Microsoft documenta la classe msFVE-RecoveryInformation come informazioni di ripristino associate a un computer e msFVE-RecoveryGuid come GUID associato a una password di ripristino. L’ObjectGUID dell’oggetto della directory stesso è un identificatore diverso.

Usare il modulo ActiveDirectory da una workstation di amministrazione autorizzata. La seguente query circoscritta utilizza i parametri di Get-ADObject di Microsoft. Sostituire il DN del computer e il DC con i valori verificati. Richiede metadati di ripristino senza richiedere msFVE-RecoveryPassword o tutte le proprietà:

Get-ADObject -LDAPFilter '(objectClass=msFVE-RecoveryInformation)' -SearchBase 'CN=PC01,OU=Workstations,DC=contoso,DC=com' -SearchScope OneLevel -Server 'dc01.contoso.com' -Properties whenCreated,msFVE-RecoveryGuid,msFVE-VolumeGuid -ErrorAction Stop |
    Select-Object DistinguishedName,whenCreated,'msFVE-RecoveryGuid','msFVE-VolumeGuid'

Gli attributi GUID restituiti possono essere array di byte. Per un oggetto di ripristino restituito, il costruttore .NET Guid da un array di byte documentato fornisce un valore leggibile per il confronto. Assegnare un oggetto restituito a $recoveryObject prima di valutare questa espressione:

[guid]::new([byte[]]$recoveryObject.'msFVE-RecoveryGuid')

Confrontare il GUID completo con l’ID del dispositivo di protezione attuale di tipo password di ripristino, ignorando le parentesi graffe di formattazione e le differenze tra maiuscole e minuscole. Usare l’associazione con computer e volume come contesto aggiuntivo; non basare la corrispondenza soltanto sulla data di creazione. Trattare gli attributi mancanti o non validi come prove incomplete. Lo schema rende msFVE-VolumeGuid facoltativo, quindi l’assenza di quel solo attributo non dimostra il fallimento del backup della password di ripristino.

L’accesso alla directory fa parte della misurazione. Una query riuscita ma vuota eseguita con un account che non può vedere gli oggetti pertinenti non è un risultato affidabile di assenza. Verificare DN, autorizzazioni e DC scelto, e indagare le incertezze di replica o visibilità prima di concludere che non esiste una voce corrispondente. La corrispondenza dei metadati non dimostra ancora che l’operatore di ripristino autorizzato possa recuperare e usare il segreto.

Passaggio 4: conservare le incognite nella matrice delle prove

Usare quanto segue come modello di report, non come risultati misurati:

Distinguere la mancata osservazione, la raccolta fallita e un test non eseguito. Una riga può risultare osservata mentre un’altra resta irrisolta. Segnalare ogni discrepanza con le prove necessarie per chiuderla, anziché ridurre le righe a un unico indicatore di conformità.

Correzione: allineare criteri, dispositivi di protezione attuali e ripristino (Remediation)

Passaggio 1: correggere il criterio previsto per le nuove attivazioni

Confermare prima il percorso di gestione e ogni classe di unità. Per i criteri di ripristino AD DS applicabili, selezionare il backup delle informazioni di ripristino richieste e l’opzione che blocca l’attivazione finché l’archiviazione in AD DS non riesce. Esaminare separatamente le impostazioni del sistema operativo e dei dati fissi. Queste opzioni sono documentate nella documentazione di configurazione citata sopra; non sono una versione GPO sostitutiva di RequireDeviceEncryption.

Sperimentare la configurazione su un gruppo pilota, controllare i risultati dei criteri sulla destinazione e conservare qualsiasi errore di distribuzione. Microsoft osserva che molti criteri BitLocker vengono applicati all’attivazione iniziale e che le modifiche ai criteri non riavviano la crittografia. I volumi già crittografati richiedono quindi la riconciliazione diretta seguente.

Passaggio 2: eseguire il backup di un dispositivo di protezione del ripristino attuale esistente

Su un volume già crittografato, identificare prima il dispositivo di protezione di tipo password di ripristino tramite tipo e ID. Risolvere la connettività con il dominio e le autorizzazioni di backup, quindi usare l’operazione manage-bde di backup dei dispositivi di protezione in AD DS documentata:

manage-bde -protectors -adbackup C: -id "{CURRENT-RECOVERY-PROTECTOR-GUID}"

Le parentesi graffe contengono un segnaposto per il GUID completo effettivo del dispositivo di protezione, non una password. Il parametro -id è obbligatorio. Questa operazione esegue il backup delle informazioni di ripristino selezionate; non crittografa un’unità non crittografata e non crea un dispositivo di protezione mancante. Se non esiste un dispositivo di protezione idoneo, usare la procedura di provisioning approvata dall’organizzazione prima di tentare il backup.

Dopo il backup, ripetere la query circoscritta ad AD DS e confrontare di nuovo l’ID. Conservare le voci meno recenti secondo il criterio dell’organizzazione sui dati di ripristino; non eliminarle soltanto perché sono più vecchie. Una risposta di comando riuscita deve essere seguita da una corrispondenza nella directory osservata indipendentemente. Se continua a mancare, lasciare irrisolto il punto relativo al deposito delle informazioni di ripristino e indagare il guasto preciso.

Passaggio 3: esercitare il ripristino in condizioni controllate

Usare il processo di ripristino BitLocker di Microsoft per definire l’accesso dell’operatore e il recupero delle informazioni. La sua procedura AD DS usa RSAT BitLocker Recovery Password Viewer in Active Directory Users and Computers; l’accesso al ripristino è assegnato per impostazione predefinita a Domain Administrators e può essere delegato. Il visualizzatore può cercare in base all’ID della password mostrato.

Pianificare un dispositivo di test rappresentativo o una finestra di manutenzione approvata, un operatore responsabile, una via di ripristino e un piano di rollback. Confermare computer, volume e ID di ripristino mostrato prima di recuperare il segreto corrispondente. Trasferirlo soltanto tramite il canale di ripristino approvato. Non provocare il ripristino sui sistemi di produzione soltanto per compilare un campo di audit.

Registrare se l’operatore previsto ha recuperato le informazioni corrispondenti e se queste hanno sbloccato il volume previsto. Escludere la password dalla registrazione delle prove. Dopo l’uso, seguire la procedura dell’organizzazione per la rotazione della password di ripristino, verificare qualsiasi dispositivo di protezione sostitutivo e la sua nuova corrispondenza nel deposito, e ricontrollare lo stato di protezione. Un’esercitazione limitata al recupero delle informazioni deve essere etichettata come recupero delle informazioni verificato; non è un test di sblocco.

Come EtcSec rileva questa situazione

L’implementazione esaminata di etc-collector espone BITLOCKER_NOT_REQUIRED come un rilievo di severità Low. Il suo Detect() legge BitLockerRequired tramite FindRegistrySettingInt: un valore assente o qualsiasi valore diverso da 1 produce Count 1; un valore di 1 produce Count 0. Il conteggio è il risultato di un controllo, non il numero di computer non crittografati.

La funzione ausiliaria restituisce il primo valore disponibile dalla Default Domain Controllers Policy, poi dalla Default Domain Policy, poi da un altro criterio raccolto. Non calcola il criterio effettivo per computer, comprese precedenza dei collegamenti, filtri ed ereditarietà. Un valore accettato da un criterio non può dimostrare la copertura del parco.

Il provider SMB legge GptTmpl.inf e Machine/Registry.pol. Il parser Registry.pol associa BitLockerRequired soltanto quando la chiave contiene fve e il valore è un DWORD denominato requiredeviceencryption. La distinzione CSP/GPO di Microsoft descritta sopra significa che questa associazione non può dimostrare un requisito generale di crittografia tramite GPO. Anche i file mancanti o non letti non provano l’assenza di un criterio applicato.

Questo Detect() non raccoglie alcuno stato di crittografia dei volumi, dispositivo di protezione del ripristino attuale, record di ripristino AD DS corrispondente o esito di test di ripristino. Qualificare sia i risultati positivi sia quelli con conteggio zero mediante la matrice delle prove separata. Chiudere il compito di verifica soltanto quando sono stati considerati i volumi identificati, i dispositivi di protezione attuali e la via di ripristino prevista, con responsabili esplicitamente assegnati alle incognite rimanenti.