BitLocker-Wiederherstellungsschlüssel sicher verwalten

BitLocker schützt Daten nur, solange der Wiederherstellungsschlüssel den richtigen Personen zur Verfügung steht und allen anderen nicht zugänglich ist. Organisationen bekommen meist nur eine Hälfte richtig hin: Die Schlüssel sind hinterlegt, aber für Hunderte Administratoren lesbar, oder der Zugriff ist streng, aber ein Viertel der Flotte hat überhaupt keinen hinterlegten Schlüssel, und das erste fehlgeschlagene Firmwareupdate wird zum Datenverlust.

Der Leitfaden zur BitLocker-Härtung behandelt die Verschlüsselungsrichtlinie selbst, einschließlich der GPO-Einstellung, die die Verschlüsselung blockiert, bis der Schlüssel gesichert ist. Dieser Leitfaden behandelt das Leben des Schlüssels danach: wo er liegt, wie Sie nachweisen, dass jedes Gerät einen hat, wer ihn lesen kann, wie Lesezugriffe überwacht und wie Schlüssel rotiert werden. Das Thema BitLocker & Startsicherheit listet den Rest der Reihe auf.

Wo die Schlüssel liegen

Microsoft BitLocker Administration and Monitoring (MBAM), Teil von MDOP, hat das Ende des erweiterten Supports erreicht; wenn Sie es noch betreiben, migrieren Sie zur BitLocker-Verwaltung von Configuration Manager oder zu Intune, statt es weiter zu betreiben.

Jedes Volume kann im Lauf der Zeit mehrere Schutzvorrichtungen für Wiederherstellungskennwörter haben. Die auf dem Wiederherstellungsbildschirm angezeigte Schlüsselschutz-ID („Recovery key ID“, die ersten 8 Zeichen reichen für die Suche) gibt an, welche der Benutzer braucht.

Schritt 1: nachweisen, dass jedes Gerät einen hinterlegten Schlüssel hat

Die Einstellung „Do not enable BitLocker until recovery information is stored“ aus dem Härtungsleitfaden schützt neue Verschlüsselungen. Sie deckt keine früher verschlüsselten Geräte ab, keine Geräte, die sich vor Anwendung der Richtlinie automatisch verschlüsselt haben, und keine Schlüssel, die beim Neuanlegen eines Computerobjekts verloren gingen. Messen Sie die Abdeckung.

Vergleichen Sie auf dem Gerät die lokalen Schutzvorrichtungen mit dem, was das Verzeichnis enthält:

(Get-BitLockerVolume -MountPoint C:).KeyProtector |
  Where-Object KeyProtectorType -eq 'RecoveryPassword' |
  Select-Object KeyProtectorId

Listen Sie in Active Directory auf, welche Computer mindestens ein Wiederherstellungsobjekt haben:

$withKeys = Get-ADObject -LDAPFilter '(objectClass=msFVE-RecoveryInformation)' -SearchBase 'OU=Workstations,DC=corp,DC=example,DC=com' |
  ForEach-Object { ($_.DistinguishedName -split ',',2)[1] } | Sort-Object -Unique
Get-ADComputer -Filter * -SearchBase 'OU=Workstations,DC=corp,DC=example,DC=com' |
  Where-Object { $_.DistinguishedName -notin $withKeys } |
  Select-Object Name

Führen Sie das mit einem Konto aus, das die Wiederherstellungsobjekte lesen darf, sonst erscheint jeder Computer ungeschützt. Für Entra ID listen Sie die Schlüsselmetadaten (nicht die Schlüssel) mit Microsoft Graph PowerShell auf und vergleichen die DeviceId-Werte mit Ihrem Intune-Geräteinventar:

Connect-MgGraph -Scopes 'BitLockerKey.ReadBasic.All'
Get-MgInformationProtectionBitlockerRecoveryKey -All |
  Select-Object Id, DeviceId, CreatedDateTime, VolumeType

Der Verschlüsselungsbericht von Intune zeigt ebenfalls den Verschlüsselungsstatus pro Gerät. Für Lücken sichern Sie die vorhandene Schutzvorrichtung per Wartungsskript mit Backup-BitLockerKeyProtector (AD) oder BackupToAAD-BitLockerKeyProtector (Entra ID), wie im Härtungsleitfaden gezeigt. Das Ereignisprotokoll Microsoft > Windows > BitLocker-API > Management auf dem Gerät zeichnet jeden Sicherungsversuch und dessen Ergebnis auf; alarmieren Sie bei fehlgeschlagenen Sicherungen.

Schritt 2: Lesezugriff auf Schlüssel in Active Directory beschränken

msFVE-RecoveryPassword ist ein vertrauliches Attribut: Zum Lesen braucht man zusätzlich zur normalen Leseberechtigung das Recht Control Access auf das Attribut. Standardmäßig heißt das: Domain Admins und jeder mit Vollzugriff auf die Computerobjekte, was in vielen Domänen Dienstkonten und überdelegierte Helpdesk-Gruppen einschließt.

1. Legen Sie eine Gruppe wie BitLocker-Recovery-Readers für die Personen an, die tatsächlich Wiederherstellungen durchführen.
2. Delegieren Sie dieser Gruppe Lesezugriff auf die Wiederherstellungsobjekte in den Arbeitsplatz-OUs:

dsacls "OU=Workstations,DC=corp,DC=example,DC=com" /I:S /G "CORP\BitLocker-Recovery-Readers:RP;;msFVE-RecoveryInformation"
dsacls "OU=Workstations,DC=corp,DC=example,DC=com" /I:S /G "CORP\BitLocker-Recovery-Readers:CA;msFVE-RecoveryPassword;msFVE-RecoveryInformation"

3. Prüfen Sie, wer sonst noch Vollzugriff oder All extended rights auf diese OUs und Computerobjekte hat, und entfernen Sie das, wo es nicht nötig ist. Dieselbe Prüfung, die Sie für die Leser von Windows-LAPS-Kennwörtern durchgeführt haben, gilt hier, und oft handelt es sich um dieselben Personen.

Testen Sie die Delegierung zuerst im Labor. Installieren Sie auf den Admin-Arbeitsplätzen des Helpdesks das RSAT-Feature BitLocker Recovery Password Viewer; es ergänzt Computerobjekte um eine Registerkarte BitLocker Recovery und eine Suche nach Schlüssel-ID.

Schritt 3: Lesezugriff auf Schlüssel in Entra ID beschränken

In Entra ID erfordert das Lesen des Schlüssels selbst die Berechtigung microsoft.directory/bitlockerKeys/key/read. Mehrere integrierte Rollen enthalten sie, darunter Cloud Device Administrator, Helpdesk Administrator, Intune Administrator und Security Administrator; prüfen Sie vor der Zuweisung die aktuelle Rollenreferenz. Empfehlungen:

• Weisen Sie dem Wiederherstellungsteam eine dieser Rollen oder eine benutzerdefinierte Rolle nur mit der BitLocker-Schlüsselberechtigung zu, und zwar berechtigt über Privileged Identity Management statt dauerhaft.
• Begrenzen Sie den Helpdesk-Zugriff mit Verwaltungseinheiten, sofern Ihre Lizenzierung das erlaubt.
• Entscheiden Sie über den Self-Service für Benutzer. Standardmäßig kann der registrierte Besitzer eines Geräts dessen Wiederherstellungsschlüssel im Kontoportal sehen. Für firmeneigene Geräte können Sie das unter Entra admin center > Devices > Device settings mit der Einstellung abschalten, die Nicht-Administratoren daran hindert, BitLocker-Schlüssel ihrer eigenen Geräte abzurufen.
• Verwenden Sie für Automatisierung nach Möglichkeit BitLockerKey.ReadBasic.All (nur Metadaten); gewähren Sie BitLockerKey.Read.All nur dem Werkzeug, das Schlüssel tatsächlich lesen muss.

Schritt 4: jeden Schlüsselzugriff überwachen

Active Directory. Aktivieren Sie auf Domänencontrollern Audit Directory Service Access (Success) unter Advanced Audit Policy Configuration > Audit Policies > DS Access und fügen Sie dann eine SACL auf den Arbeitsplatz-OUs hinzu: Prinzipal Everyone, Erfolg, Read msFVE-RecoveryPassword, angewendet auf untergeordnete msFVE-RecoveryInformation-Objekte. Jeder Lesezugriff erzeugt dann Ereignis 4662 auf dem DC, der ihn bedient hat, mit dem Subjektkonto und der Schema-GUID des Attributs im Feld Properties. Ermitteln Sie die GUID, nach der Sie filtern:

Get-ADObject -SearchBase (Get-ADRootDSE).schemaNamingContext `
  -LDAPFilter '(lDAPDisplayName=msFVE-RecoveryPassword)' -Properties schemaIDGUID |
  ForEach-Object { [guid]$_.schemaIDGUID }

Entra ID. Jeder Schlüsselzugriff wird im Überwachungsprotokoll von Entra in der Kategorie KeyManagement als Read BitLocker key mit Akteur und Gerät festgehalten. Streamen Sie die Überwachungsprotokolle in Ihr SIEM und alarmieren Sie bei Zugriffen außerhalb des Wiederherstellungsteams, bei Massenabrufen und bei Zugriffen durch Anwendungen.

Korrelieren Sie Zugriffe mit Tickets. Ein Schlüsselzugriff ohne passendes Wiederherstellungsticket verdient eine Nachfrage.

Schritt 5: Schlüssel nach Verwendung rotieren

Intune (Entra-gebunden und hybrid eingebunden). Setzen Sie in Ihrer BitLocker-Richtlinie (Endpoint security > Disk encryption oder Einstellungskatalog) Configure Recovery Password Rotation auf Aktualisierung für Entra-gebundene oder für Entra-gebundene und hybrid eingebundene Geräte (BitLocker-CSP ConfigureRecoveryPasswordRotation, Werte 1 und 2). Wird ein Wiederherstellungskennwort zum Entsperren des Betriebssystemlaufwerks verwendet, erzeugt das Gerät ein neues und hinterlegt es. Für einen offengelegten, aber nicht verwendeten Schlüssel, etwa einen, der am Telefon der falschen Person vorgelesen wurde, führen Sie auf der Geräteseite in Intune die Geräteaktion BitLocker key rotation aus.

Active Directory. Es gibt keine integrierte, clientgesteuerte Rotation. Führen Sie (über Ihr Managementwerkzeug oder eine geplante Wartungsaufgabe) ein Skript aus, das ein neues Wiederherstellungskennwort hinzufügt, es hinterlegt und erst dann die alte Schutzvorrichtung entfernt:

$old = (Get-BitLockerVolume -MountPoint C:).KeyProtector | Where-Object KeyProtectorType -eq 'RecoveryPassword'
$new = Add-BitLockerKeyProtector -MountPoint C: -RecoveryPasswordProtector -WarningAction SilentlyContinue
$newId = ($new.KeyProtector | Where-Object { $_.KeyProtectorType -eq 'RecoveryPassword' -and $_.KeyProtectorId -notin $old.KeyProtectorId }).KeyProtectorId
Backup-BitLockerKeyProtector -MountPoint C: -KeyProtectorId $newId
foreach ($p in $old) { Remove-BitLockerKeyProtector -MountPoint C: -KeyProtectorId $p.KeyProtectorId }

Prüfen Sie, dass die Sicherung erfolgreich war (das Cmdlet wirft bei einem Fehler eine Ausnahme), bevor Sie etwas entfernen. Alte Wiederherstellungsobjekte bleiben in AD; das ist harmlos, weil die zugehörige Schutzvorrichtung auf dem Laufwerk nicht mehr existiert.

Was kaputtgeht

• Zu enge Delegierung lässt den Helpdesk um 7 Uhr morgens ohne Möglichkeit zurück, ein Gerät wiederherzustellen. Halten Sie einen dokumentierten Notfallweg über Tier-0-Administratoren bereit.
• Bereinigungsskripte, die veraltete Computer- oder Entra-Geräteobjekte löschen, löschen auch die Schlüssel für Laufwerke, die womöglich noch in einer Schublade liegen. Prüfen Sie zuerst das Datum des letzten Wiederherstellungsschlüssels und den Verschlüsselungsstatus und lassen Sie den AD-Papierkorb aktiviert.
• Neu installierte Geräte verwenden denselben Namen, erzeugen aber neue Schlüssel; Benutzer, die die falsche Schlüssel-ID ablesen, verlieren Zeit. Schulen Sie den Helpdesk, immer die Schlüssel-ID abzugleichen.
• Das Abschalten des Self-Service in Entra ID erhöht die Zahl der Helpdesk-Anrufe; planen Sie die Besetzung entsprechend.

Überprüfen

• Abdeckungsbericht: null verschlüsselte Geräte ohne hinterlegten Schlüssel, in AD wie in Entra ID.
• dsacls oder die Ansicht Advanced Security auf den Arbeitsplatz-OUs zeigt nur die vorgesehenen Gruppen mit Control Access auf msFVE-RecoveryPassword.
• Ein Testzugriff mit einem Helpdesk-Konto erzeugt innerhalb von Minuten ein 4662-Ereignis oder einen Entra-Überwachungseintrag Read BitLocker key im SIEM.
• Nach einer Testwiederherstellung auf einem Intune-Gerät ändert sich die Schlüssel-ID in Entra ID, und das alte Kennwort entsperrt das Laufwerk nicht mehr.

Checkliste

• Jedes verschlüsselte Gerät hat einen in AD DS oder Entra ID hinterlegten Schlüssel; Lücken behoben
• AD-Lesezugriff auf msFVE-RecoveryPassword nur an eine dedizierte Gruppe delegiert
• Entra-Rollen zum Lesen von Schlüsseln über PIM zugewiesen; Self-Service bewusst entschieden
• AD-Schlüsselzugriffe mit 4662 überwacht; Entra-Schlüsselzugriffe aus dem Überwachungsprotokoll gestreamt
• Zugriffe mit Wiederherstellungstickets korreliert
• Rotation des Wiederherstellungskennworts in Intune aktiviert; skriptbasierte Rotation für reine AD-Geräte
• Bereinigungsprozesse schützen hinterlegte Schlüssel

Wiederherstellungsschlüssel werden am häufigsten nach Änderungen an der Startkette benötigt. Der Leitfaden zu Secure Boot und UEFI erklärt, welche Updates eine Wiederherstellung auslösen können und wie man sich vorbereitet, und der Glossareintrag zum TPM erklärt, warum das TPM den Schlüssel nur freigibt, wenn die Messwerte übereinstimmen.