CrowdStrike zeigt, wo BitLocker-Wiederherstellungsschlüssel fehlen

Den 19. Juli 2024 werden viele von uns so schnell nicht vergessen. Ein fehlerhaftes Update für den CrowdStrike Falcon Sensor hat weltweit Millionen Windows-Geräte lahmgelegt. In zahlreichen Kundenumgebungen, die ich betreue oder kenne, genügte ein einfacher Neustart, und schon erschien der berüchtigte Blue Screen of Death, gefolgt von endlosen Bootschleifen. Wer BitLocker aktiviert hatte, kam noch schwerer weiter, denn ohne den BitLocker-Wiederherstellungsschlüssel ließ sich das Gerät weder über WinRE noch im abgesicherten Modus reparieren. Aus der eher theoretischen Frage „Wo liegen eigentlich unsere BitLocker-Schlüssel?“ wurde plötzlich eine handfeste Notfallaufgabe.

Intune, Entra ID und Active Directory speichern die Wiederherstellungsschlüssel an unterschiedlichen Stellen

Fast alle modernen Microsoft-365-Umgebungen werden heute aus der Cloud verwaltet, ob mit Intune, mit Microsoft Entra ID (vormals Azure AD) oder hybrid zusammen mit Active Directory. Im Idealfall landen die BitLocker-Wiederherstellungsschlüssel dabei automatisch in der jeweiligen Plattform („escrowed“). Nach meiner Erfahrung sieht die Wirklichkeit allerdings oft weniger erfreulich aus. In Intune-verwalteten Umgebungen stehen die Schlüssel im Intune Admin Center unter Devices → device → Recovery keys. Im Microsoft Entra Admin Center (https://learn.microsoft.com/en-us/entra/identity/devices/manage-device-identities) führt der Weg über Devices → All devices → Gerät → BitLocker keys. In hybriden Umgebungen lassen sich die Schlüssel auch im lokalen Active Directory ablegen, und zwar im Attribut „msFVE-RecoveryInformation“.

Dass im Ernstfall tatsächlich jeder Schlüssel vorhanden ist, kann man aber nur dann sicher sagen, wenn Geräte- und Verschlüsselungsrichtlinien sauber greifen und die Nutzer nicht tricksen. Sehr hilfreich sind dabei die Verschlüsselungsberichte in Intune. Sie zeigen auf einen Blick, für welche Geräte der Schlüssel wirklich zentral hinterlegt ist; zu finden sind sie in der Regel unter Intune Admin Center → Devices → Monitor → Encryption report. Vor allem in organisch gewachsenen Tenants entdeckt man dort regelmäßig Lücken.

Der Lesezugriff auf die Schlüssel gehört in wenige Hände

Mit einem BitLocker-Wiederherstellungsschlüssel lässt sich das Gerät vollständig aufschließen. Wer ihn besitzt, kann die Festplatte lesen, egal welche Schutzmaßnahmen sonst greifen. Die Rollenvergabe verdient deshalb besondere Sorgfalt. Im Microsoft Entra Admin Center dürfen etwa die Rollen Cloud Device Administrator und Helpdesk Administrator die Schlüssel standardmäßig abrufen; es lohnt sich immer, die Rollenbeschreibung genau zu lesen. In Intune reicht häufig schon die Berechtigung „Read BitLocker keys“, die in vielen Helpdesk-Rollen steckt.

Praxis-Tipp: Vor allem in größeren Organisationen sollte man regelmäßig kontrollieren, wer tatsächlich Zugriff hat und ob diese Personen noch im Unternehmen bzw. in der jeweiligen Rolle sind. Meist genügen dafür eine gut gepflegte dynamische Sicherheitsgruppe und ein automatisiertes Review alle paar Monate.

Im lokalen AD sollten nur eigens dafür vorgesehene Helpdesk- und Recovery-Admins Rechte auf die betreffenden Attribute bekommen. Zu einem guten Sicherheitskonzept gehört außerdem, dass Schlüsselabfragen überwacht werden.

Längst nicht jedes Gerät hat seinen Schlüssel hinterlegt

Der CrowdStrike-Vorfall hat deutlich gemacht, wie weit Richtlinie und Wirklichkeit auseinanderliegen können. In vielen Tenants, die ich mir ansehe, findet sich eine beträchtliche Zahl von Geräten, auf denen BitLocker nie aktiviert wurde oder die ihren Schlüssel nie hochgeladen haben. Bei anderen ist eine Migration zwischen Verwaltungssystemen schiefgegangen. Besonders oft rutschen Geräte durchs Raster, die schon länger im Einsatz sind oder bei denen „Bring Your Own Device“ im Spiel ist.

Problemfälle erkennt man im Intune Admin Center schnell am Verschlüsselungsbericht, der anzeigt, ob der Schlüssel im Tenant liegt oder nicht. Wer es genauer wissen will, ruft den Status per PowerShell über die Graph-API ab. Dafür braucht es eine App-Registrierung und die passenden Graph-Berechtigungen:

# Voraussetzung: Microsoft.Graph.DeviceManagement Module, App-Registrierung mit DeviceManagementManagedDevices.Read.All
Connect-MgGraph -Scopes "DeviceManagementManagedDevices.Read.All"
Get-MgDeviceManagementManagedDevice -Filter "encryptionState ne 'encrypted'"

Im Notfall kann auch eine Dokumentation direkt am Gerät weiterhelfen. Bei Flotten mit Hunderten oder Tausenden Clients taugt das selbstverständlich nicht als Lösung.

Microsofts Recovery-Tool ersetzt weder den Schlüssel noch saubere Prozesse

Microsoft hat schnell ein USB-basiertes Recovery-Tool bereitgestellt, das Betroffenen bei Blue Screen oder Bootschleife unkompliziert helfen soll. Bei verschlüsselten Geräten führt aber kein Weg am BitLocker-Wiederherstellungsschlüssel vorbei, denn das Tool kann und darf ihn nicht umgehen. Wer den Schlüssel im Notfall nicht parat hat, muss auf eine aufwendige manuelle Wiederherstellung ausweichen und riskiert unter Umständen sogar Datenverlust. Die Dokumentation zur BitLocker-Wiederherstellung dürfte in den vergangenen Tagen in IT-Teams weltweit zu den meistgeklickten Links gehört haben.

Wichtiger als jedes Tool sind allerdings Prozesse und Resilienz. Vielen Organisationen fehlte schlicht eine offline verfügbare Liste der Wiederherstellungsschlüssel für die wichtigsten Systeme, also etwa Domain-Controller, zentrale Fileserver oder kritische Admin-Workstations. Auch bei der Frage, welche Geräte zuerst wiederhergestellt werden müssen, zeigte sich vielerorts eine große Schwäche. Abhilfe schafft eine regelmäßig aktualisierte Liste mit Systembezeichnungen, Gerätenamen und, wo zulässig, den zugehörigen Recovery-IDs.

Das folgende Diagramm zeigt, wie der Zugriff auf einen BitLocker-Wiederherstellungsschlüssel in der Regel abläuft:

flowchart TD
  User["Nutzer startet Wiederherstellung"] --> IT["IT erhält Anfrage"]
  IT --> Portal["BitLocker-Schlüsselportal (Entra/Intune/AD)"]
  Portal --> Key["Wiederherstellungsschlüssel abfragen"]
  Key --> User["Nutzer gibt Schlüssel ein"]

Abbildung: Typischer Ablauf einer BitLocker-Wiederherstellung aus Sicht von Support und IT.

Regelmäßige Kontrolle schützt besser als bloße Annahmen

Der CrowdStrike-Ausfall hat gezeigt, dass es nicht genügt, BitLocker zentral „zu verwalten“ und darauf zu hoffen, dass schon alles klappt. Man muss regelmäßig prüfen, ob wirklich alle (!) Geräte ihre BitLocker-Wiederherstellungsschlüssel wie vorgesehen im Tenant hinterlegt haben. Ebenso wichtig ist, dass der Zugriff im Notfall schnell klappt und dabei sicher und nachvollziehbar bleibt. Das gilt für den Helpdesk ebenso wie für die Abläufe rund um besonders kritische Systeme.

In den kommenden Wochen wird sich zeigen, wie viele Unternehmen ihre Prozesse anpassen und Recovery-Schlüssel endlich als das behandeln, was sie sind, nämlich als einen der wichtigsten Hebel für echte Resilienz. Wer jetzt nicht prüft, erlebt beim nächsten Vorfall womöglich wieder eine böse Überraschung. Deshalb gehört das Thema weit nach oben auf die Tagesordnung, im IT-Team ebenso wie im Krisenmanagement.