🏢Active DirectoryGPOComputersConfig

BitLocker AD Wiederherstellungspruefung: Richtlinie, Status und Hinterlegung

Prüfen Sie BitLocker-Richtlinie, Volume-Schutz und aktuelle AD-DS-Hinterlegung getrennt. Gleichen Sie Einträge mit aktuellen Schutzkennungen ab.

Younes AZABARVon Younes AZABAR10 Min. Lesezeit
BitLocker AD Wiederherstellungspruefung: Richtlinie, Status und Hinterlegung

Was ist die BitLocker AD Wiederherstellungspruefung?

Die BitLocker AD Wiederherstellungspruefung verbindet drei voneinander unabhängige Nachweise: die für einen Computer geltende Richtlinie, den tatsächlich auf jedem Volume vorhandenen Schutz und die in Active Directory Domain Services (AD DS) gespeicherten Wiederherstellungsinformationen für dessen aktuellen Wiederherstellungsschutz. Ein Richtlinienbefund eröffnet diese Untersuchung; er kann nicht alle drei Fragen beantworten.

Die sinnvolle Prüfeinheit ist ein benannter Computer mit einem benannten Volume zu einem dokumentierten Zeitpunkt. Eine domänenweite Einstellung, ein lokal verschlüsseltes Laufwerk und ein altes Wiederherstellungsobjekt im Verzeichnis können gleichzeitig vorhanden sein, während der vorgesehene Wiederherstellungsweg weiterhin ungeprüft bleibt. Dokumentieren Sie diese Beobachtungen getrennt, bevor Sie über die erforderlichen Maßnahmen entscheiden.

Unser Artikel zur Hygiene von Computerobjekten einschließlich BitLocker und der Hinterlegung von Wiederherstellungsinformationen ordnet diese Arbeit in die umfassendere Prüfung des Computerlebenszyklus ein. Hier ist die Aufgabe enger gefasst: Stellen Sie fest, ob der Wiederherstellungsdatensatz dem aktuell auf dem Volume vorhandenen Schutz entspricht. Leiten Sie den Verschlüsselungszustand nicht aus dem Vorhandensein oder Fehlen eines Verzeichnisobjekts ab.

Funktionsweise: Richtlinie, Volumestatus und Hinterlegung

Verwaltungsweg und Volume-Umfang bestimmen

Halten Sie fest, welche Betriebssystem-, Festdaten- und Wechseldatenträger-Volumes zum Prüfumfang gehören, welchen Computern sie zugeordnet sind und ob ihre Konfiguration aus GPO oder CSP stammt. Benennen Sie ausgeschlossene Volumes ausdrücklich; allein die Prüfung des Betriebssystemlaufwerks kann eine Anforderung für Datenlaufwerke nicht abschließen.

Microsofts Referenz zur BitLocker-Konfiguration bezeichnet ./Device/Vendor/MSFT/BitLocker/RequireDeviceEncryption als CSP-Richtlinie und kennzeichnet ihre GPO-Entsprechung mit Not available. Das bedeutet nicht, dass BitLocker keine GPO-Einstellungen besitzt. Wiederherstellungseinstellungen für Betriebssystem- und Festdatenlaufwerke bieten die Sicherung in AD DS sowie eine Option, die eine Aktivierung verhindert, bis diese Sicherung erfolgreich abgeschlossen ist. Windows Server verwendet für die BitLocker-Konfiguration GPO statt CSP.

Erfassen Sie für ein per GPO verwaltetes Ziel computerbezogene Nachweise des Richtlinienergebnissatzes mit der von Microsoft dokumentierten gpresult-Syntax:

gpresult /scope computer /z

Prüfen Sie die relevanten Wiederherstellungseinstellungen und die jeweils maßgeblichen Richtlinien. Beschaffen Sie für per CSP verwaltete Clients die entsprechenden Zuweisungs- und Geräterichtlinienergebnisse aus dem Verwaltungssystem. Ein GPO-Bericht belegt keine CSP-Anwendung. Klären Sie Widersprüche bei gemischter Verwaltung, bevor Sie die vorgesehene Richtlinie als wirksam beschreiben. Dieselbe Unterscheidung zwischen einem erfassten Wert und dem Schutz am Ziel erläutert unser Artikel zu vier GPO-Sicherheitsprüfungen und ihrer Verifikation am Zielsystem.

Die Vorgeschichte des Volumes berücksichtigen

Microsofts BitLocker-FAQ erläutert, dass Wiederherstellungsinformationen eines vor Anwendung der Sicherungsrichtlinie verschlüsselten Laufwerks nicht automatisch in AD DS hochgeladen werden, wenn der Computer der Domäne beitritt oder diese Richtlinie später erhält. AD DS bewahrt außerdem alte Einträge für Wiederherstellungskennwörter auf. Ein früheres Ereignis über eine erfolgreiche Sicherung kann den Verzeichnisdatensatz oder den Schutz überdauern, der es nutzbar machte.

Ermitteln Sie, wann die Verschlüsselung begann, wann Domänenmitgliedschaft und Wiederherstellungsrichtlinie wirksam wurden und ob sich die Schutzmechanismen geändert haben. Diese Antworten bestimmen, wo nach einer Lücke zu suchen ist. Weder eine kürzlich ausgerollte Richtlinie noch der neueste Verzeichniszeitstempel ersetzt den Abgleich mit dem aktuellen Schutz. Ist die Vorgeschichte nicht verfügbar, dokumentieren Sie sie als unbekannt und führen Sie die folgenden direkten Prüfungen durch.

Erkennung: Drei unabhängige Nachweise erfassen

Schritt 1: Verschlüsselung und Schutz auf jedem Volume messen

Führen Sie den dokumentierten manage-bde-Statusbefehl lokal für das ausgewählte Laufwerk aus:

manage-bde -status C:

Dokumentieren Sie Konvertierungsstatus, Verschlüsselungsprozentsatz, Verschlüsselungsmethode, Schutzstatus und Sperrstatus. Verschlüsselungsfortschritt und aktiver Schutz sind getrennte Felder; ein verschlüsseltes Volume mit deaktiviertem Schutz erfordert andere Folgemaßnahmen als ein vollständig entschlüsseltes Volume. Ein fehlgeschlagener Befehl liefert keine der beiden Beobachtungen.

PowerShell bietet das dokumentierte Cmdlet Get-BitLockerVolume. Dieses Beispiel begrenzt die angezeigten Eigenschaften mithilfe von Select-Object:

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

Wiederholen Sie die Prüfung für jedes ausgewählte Volume. Speichern Sie Computeridentität, Bereitstellungspunkt, Zeitstempel und Erfassungsergebnis zusammen mit dem Resultat, damit spätere Prüfer den Umfang nachvollziehen können. Machen Sie im Bericht aus einem unerreichbaren Endpunkt keinen unverschlüsselten Endpunkt.

Schritt 2: Aktuelle Wiederherstellungsschutzmechanismen ohne Ausgabe von Geheimnissen identifizieren

Die Referenz zu Backup-BitLockerKeyProtector dokumentiert das Array KeyProtector sowie KeyProtectorId und KeyProtectorType. Identifizieren Sie mit diesen Eigenschaften Schutzmechanismen vom Typ Wiederherstellungskennwort, statt eine feste Arrayposition anzunehmen:

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

Diese Projektion zeigt Kennungen und Typen, nicht das Wiederherstellungskennwort. Erfassen Sie jeden aktuellen Wiederherstellungskennwort-Schutzmechanismus des ausgewählten Volumes; es kann mehrere geben. Ein TPM-Schutzmechanismus ist nicht die Wiederherstellungskennwort-Kennung, die mit AD DS abzugleichen ist. Fehlt der erwartete Wiederherstellungskennwort-Schutzmechanismus, klassifizieren Sie diese Beobachtung ausdrücklich, statt einen anderen Schutztyp auszuwählen, um die Tabelle vollständig erscheinen zu lassen.

Schritt 3: AD-DS-Wiederherstellungsmetadaten für den richtigen Computer lesen

Microsoft dokumentiert die Klasse msFVE-RecoveryInformation als einem Computer zugeordnete Wiederherstellungsinformationen und msFVE-RecoveryGuid als die einem Wiederherstellungskennwort zugeordnete GUID. Die eigene ObjectGUID des Verzeichnisobjekts ist eine andere Kennung.

Verwenden Sie das Modul ActiveDirectory von einer autorisierten Administrationsstation aus. Die folgende begrenzte Abfrage setzt Microsofts Get-ADObject-Parameter konkret ein. Ersetzen Sie Computer-DN und DC durch die geprüften Werte. Sie fordert Wiederherstellungsmetadaten an, ohne msFVE-RecoveryPassword oder sämtliche Eigenschaften anzufordern:

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'

Die zurückgegebenen GUID-Attribute können Bytearrays sein. Für ein zurückgegebenes Wiederherstellungsobjekt liefert der dokumentierte .NET-Guid-Konstruktor für Bytearrays einen lesbaren Vergleichswert. Weisen Sie ein zurückgegebenes Objekt $recoveryObject zu, bevor Sie diesen Ausdruck auswerten:

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

Vergleichen Sie diese vollständige GUID mit der aktuellen ID des Wiederherstellungskennwort-Schutzmechanismus und ignorieren Sie dabei formatierende geschweifte Klammern sowie Groß- und Kleinschreibung. Berücksichtigen Sie die Computer- und Volume-Zuordnung als zusätzlichen Kontext; gleichen Sie nicht allein anhand des Erstellungsdatums ab. Behandeln Sie fehlende oder fehlerhafte Attribute als unvollständige Nachweise. Das Schema macht msFVE-VolumeGuid optional; allein das Fehlen dieses Attributs belegt daher kein Scheitern der Sicherung des Wiederherstellungskennworts.

Der Verzeichniszugriff ist Teil der Messung. Eine erfolgreiche, aber leere Abfrage unter einem Konto, das die relevanten Objekte nicht sehen kann, ist kein zuverlässiger Abwesenheitsnachweis. Prüfen Sie DN, Berechtigungen und gewählten DC und untersuchen Sie Unsicherheiten bei Replikation oder Sichtbarkeit, bevor Sie schließen, dass kein entsprechender Eintrag existiert. Die Übereinstimmung der Metadaten belegt weiterhin nicht, dass der autorisierte Wiederherstellungsoperator das Geheimnis abrufen und verwenden kann.

Schritt 4: Unbekanntes in der Nachweismatrix erhalten

Verwenden Sie die folgende Tabelle als Berichtsvorlage, nicht als gemessene Ergebnisse:

NachweisBeobachtetNach gültiger Prüfung nicht beobachtetErfassung fehlgeschlagen oder unvollständig
Geltende RichtlinieRichtlinienergebnis am Ziel identifiziert Einstellungen, Verwaltungsweg und UmfangErwartete Einstellung fehlt in einer abgeschlossenen ZielprüfungRichtlinienbericht nicht verfügbar, Zuweisung ungeklärt oder Umfang unsicher
Volume-SchutzLokaler Zustand dokumentiert Verschlüsselung und Schutz des benannten VolumesErwarteter verschlüsselter/geschützter Zustand fehltEndpunkt unerreichbar, Zugriff verweigert oder Befehl fehlgeschlagen
Aktueller WiederherstellungsschutzWiederherstellungskennwort-Typ und vollständige ID erfasstErwarteter Schutz fehlt nach abgeschlossener AufzählungAufzählung der Schutzmechanismen fehlgeschlagen
Entsprechender AD-DS-EintragWiederherstellungs-GUID entspricht dem aktuellen Schutz unter dem richtigen ComputerKein passender Eintrag in einer Abfrage mit geprüfter SichtbarkeitAbfrage fehlgeschlagen, Sichtbarkeit ungeprüft oder Attribute unlesbar
WiederherstellungsübungGenehmigte Übung nutzte den vorgesehenen Wiederherstellungsweg erfolgreichÜbung abgeschlossen, aber vorgesehener Weg gescheitertÜbung nicht durchgeführt oder unterbrochen

Halten Sie Nichtbeobachtung, fehlgeschlagene Erfassung und einen nicht durchgeführten Test auseinander. Eine Zeile kann bestätigt sein, während eine andere ungeklärt bleibt. Berichten Sie jede Abweichung mit den Nachweisen, die zu ihrer Klärung erforderlich sind, statt die Zeilen zu einem einzigen Compliance-Kennzeichen zusammenzufassen.

Behebung: Richtlinie, aktuelle Schutzmechanismen und Wiederherstellung abstimmen (Remediation)

Schritt 1: Die vorgesehene Richtlinie für neue Aktivierungen korrigieren

Bestätigen Sie zunächst den Verwaltungsweg und jede Laufwerksklasse. Wählen Sie für die anwendbaren AD-DS-Wiederherstellungsrichtlinien die Sicherung der erforderlichen Wiederherstellungsinformationen und die Option, die eine Aktivierung bis zur erfolgreichen Speicherung in AD DS blockiert. Prüfen Sie Betriebssystem- und Festdateneinstellungen getrennt. Diese Optionen sind in der obigen Konfigurationsreferenz dokumentiert; sie sind keine GPO-Ersatzversion von RequireDeviceEncryption.

Erproben Sie die Konfiguration im Pilotbetrieb, prüfen Sie die Richtlinienergebnisse am Ziel und dokumentieren Sie sämtliche Bereitstellungsfehler. Microsoft weist darauf hin, dass viele BitLocker-Richtlinien bei der Erstaktivierung durchgesetzt werden und Richtlinienänderungen die Verschlüsselung nicht neu starten. Bereits verschlüsselte Volumes benötigen deshalb den folgenden direkten Abgleich.

Schritt 2: Einen vorhandenen aktuellen Wiederherstellungsschutz sichern

Identifizieren Sie auf einem bereits verschlüsselten Volume zunächst den Wiederherstellungskennwort-Schutzmechanismus anhand von Typ und ID. Klären Sie Domänenkonnektivität und Sicherungsberechtigungen und verwenden Sie anschließend den dokumentierten manage-bde-Vorgang zur Sicherung der Schutzinformationen in AD DS:

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

Die geschweiften Klammern enthalten einen Platzhalter für die tatsächliche vollständige Schutz-GUID, kein Kennwort. Der Parameter -id ist erforderlich. Dieser Vorgang sichert die ausgewählten Wiederherstellungsinformationen; er verschlüsselt weder ein unverschlüsseltes Laufwerk noch erstellt er einen fehlenden Schutzmechanismus. Ist kein geeigneter Schutz vorhanden, verwenden Sie vor dem Sicherungsversuch das genehmigte Bereitstellungsverfahren der Organisation.

Wiederholen Sie nach der Sicherung die begrenzte AD-DS-Abfrage und gleichen Sie die ID erneut ab. Bewahren Sie ältere Einträge gemäß der Wiederherstellungsdatenrichtlinie der Organisation auf; löschen Sie sie nicht allein wegen ihres Alters. Auf eine erfolgreiche Befehlsantwort sollte eine unabhängig beobachtete Übereinstimmung im Verzeichnis folgen. Fehlt sie weiterhin, lassen Sie den Hinterlegungspunkt ungeklärt und untersuchen Sie den konkreten Fehler.

Schritt 3: Wiederherstellung unter kontrollierten Bedingungen erproben

Verwenden Sie Microsofts BitLocker-Wiederherstellungsprozess, um Operatorzugriff und Abruf festzulegen. Das AD-DS-Verfahren nutzt den RSAT BitLocker Recovery Password Viewer in Active Directory Users and Computers; standardmäßig haben Domain Administrators Wiederherstellungszugriff, der delegiert werden kann. Der Viewer kann anhand der angezeigten Kennwort-ID suchen.

Planen Sie ein repräsentatives Testgerät oder ein genehmigtes Wartungsfenster, einen verantwortlichen Operator, einen Wiederherstellungsweg und einen Rücksetzplan. Bestätigen Sie Computer, Volume und angezeigte Wiederherstellungs-ID, bevor Sie das passende Geheimnis abrufen. Übertragen Sie es ausschließlich über den genehmigten Wiederherstellungskanal. Erzwingen Sie keine Wiederherstellung auf Produktionssystemen, nur um ein Audit-Feld auszufüllen.

Dokumentieren Sie, ob der vorgesehene Operator die passenden Informationen abrufen konnte und ob sie das vorgesehene Volume entsperrten. Halten Sie das Kennwort aus dem Nachweisdokument heraus. Folgen Sie nach der Verwendung dem Verfahren der Organisation zur Rotation von Wiederherstellungskennwörtern, prüfen Sie jeden Ersatzschutz und dessen neue Entsprechung in der Hinterlegung und kontrollieren Sie den Schutzstatus erneut. Eine Übung, die nur den Abruf prüft, sollte als Abruf verifiziert bezeichnet werden; sie ist kein Entsperrtest.

Wie EtcSec dies erkennt

Die geprüfte etc-collector-Implementierung meldet BITLOCKER_NOT_REQUIRED als Befund mit Schweregrad Low. Ihre Methode Detect() liest BitLockerRequired über FindRegistrySettingInt: Ein fehlender Wert oder jeder andere Wert als 1 ergibt Count 1; der Wert 1 ergibt Count 0. Dieser Zähler ist ein Prüfergebnis, keine Anzahl unverschlüsselter Computer.

Die Hilfsfunktion liefert den ersten verfügbaren Wert aus der Default Domain Controllers Policy, dann aus der Default Domain Policy und schließlich aus einer anderen erfassten Richtlinie. Sie berechnet keine wirksame Richtlinie pro Computer einschließlich Verknüpfungsrangfolge, Filterung und Vererbung. Ein aus einer Richtlinie akzeptierter Wert kann die Abdeckung des gesamten Bestands nicht belegen.

Der SMB-Provider liest GptTmpl.inf und Machine/Registry.pol. Der Registry.pol-Parser ordnet BitLockerRequired nur dann zu, wenn der Schlüssel fve enthält und der Wert ein DWORD namens requiredeviceencryption ist. Die oben erläuterte CSP/GPO-Unterscheidung von Microsoft bedeutet, dass diese Zuordnung keine allgemeine GPO-Verschlüsselungsanforderung belegen kann. Auch fehlende oder ungelesene Dateien beweisen nicht, dass keine Richtlinie angewendet wird.

Diese Methode Detect() erfasst weder den Verschlüsselungszustand eines Volumes noch den aktuellen Wiederherstellungsschutz, einen entsprechenden AD-DS-Wiederherstellungsdatensatz oder das Ergebnis eines Wiederherstellungstests. Ordnen Sie sowohl positive Ergebnisse als auch Ergebnisse mit Zähler null anhand der getrennten Nachweismatrix ein. Schließen Sie die Prüfung erst ab, wenn die benannten Volumes, aktuellen Schutzmechanismen und vorgesehenen Wiederherstellungswege berücksichtigt sind und für verbleibende Unbekannte ausdrücklich Verantwortliche feststehen.

Entdecken Sie die Identity-Security-Seiten zu diesem Thema