Nutzung von Bitlocker in virtuellen Maschinen

derwowusste
Goto Top
Vorbetrachtung: Wen sollte das interessieren?

Wer virtuelle Maschinen zum Test auf seiner lokalen Festplatte speichert, wird diese nur selten auch noch verschlüsseln wollen, es sei denn, er möchte in den Maschinen Aspekte der Verschlüsselung testen. Hat man sein Storage eh selbst gebitlockt, ist es nur dann sinnvoll, die Maschine auch noch zu bitlocken, wenn man diesen Extraschutz gegen andere Benutzer des Host-Rechners benötigt.
Ein Anwendungsfall ist viel häufiger, dass man einen VM-Host hat, der vielleicht gar kein Bitlocker unterstützt (zum Beispiel Vmware ESXI) und tatsächlich gegen Einbrüche in den Serverraum vorbeugen möchte, indem man die Gastsysteme selbst die Verschlüsselung machen lässt.

Nehmen wir also an, wir haben z.B. ESXI und entscheiden uns ebenso dagegen, das VMStorage zu verschlüsseln (auch möglich!), sondern wollen stattdessen einzelne Gastsysteme verschlüsseln.
Das Vorgehen ist bei Systemlaufwerken einfach:

1 man erlaubt per GPO* im Gastsystem, dass Bitlocker auch ohne TPM Chip genutzt werden darf (denn ESXI bietet noch keine virtuellen TPMs)
2 Man erstellt in ESXI entweder eine virtuelle Floppy oder eine virtuelle Festplatte, die man auf der Freigabe eines anderen, physikalisch besser gesicherten Servers als Datei speichert
3 Über ESXI mountet man fortan diese Festplatte/Floppy in der VM, formatiert sie und erstellt einen Startupkey, welchen man auf diese virtuelle Festplatte/Floppy speichert, z.B. so:
bzw.
(wobei a: der Laufwersbuchstabe der Floppy und x: der der Festplatte ist)
Schon fertig. Die virtuelle Festplatte/Floppy bleibt danach einfach gemountet und beim Start der VM wird automatisch der Schlüssel von ihr eingelesen.
[Wer nicht möchte, dass eine Schlüsseldatei ständig zugänglich in Laufwerk a: schlummert, muss eben per GPO den Zugriff auf Wechselmedien verbieten, die Floppy zusätzlich mit NTFS formatieren (mit 3rd party tools) und mit ACLs arbeiten, oder diese per Skript nur zum Start der Maschine einlegen.]
Die virtuelle Festplatte ist die bessere Wahl, da man diese im diskmgmt.msc einfach nach der Schlüsselablage auf "offline" setzen kann und das OS sie nicht einmal mehr sieht. Keine Nebeneffekte und zudem kompatibel mit allen Hypervisorgenerationen, während Floppies bei z.B. Hyper-V Gen2 gar nicht mehr angeboten werden - an dieser Stelle noch einmal Danke an @C.R.S. für den Tipp.

Ist dieses Vorgehen sicher?
Wer Zugriff auf die Schlüsseldatei UND auf die virtuelle Festplatte hat, hat die VM „im Sack“. Somit sollte man sichergehen, dass die Datei der virtuellen Floppy/Festplatte wirklich sicher verwahrt ist, also die Freigabe- und ggf. NTFS-Rechte ebenso wie den physikalischen Zugriff auf den Server absichern.

Ist dieses Vorgehen von Microsoft supported?
Nein! Dennoch sehe ich keine Gefahr, es einzusetzen und habe das schon vor 10 Jahren so gemacht. Offiziell supported ist es nur mit vTPM, also Hyper-V und Gen2 Maschinen.

Wie verhält es sich mit Datenlaufwerken?
Diese können entweder per Autounlock automatisch nach dem Start eingebunden werden, oder man benutzt für sie einen eigenen Startupkey und einen geplanten Task, um sie zu mounten. Beispiel für die Aktion des geplanten Tasks:

Wie würde das Ganze mit Oracle Virtualbox VMs oder VMWare workstation laufen?
Exakt gleich.

Und wie würde es mit Hyper-V der aktuellen Generation auf einer VM Gen2 laufen?
Hier würde man einfach einen virtuellen TPM („vTPM“) nehmen und verschlüsseln wie mit einem physikalischen TPM auch. Dokumentationen zum Shielding von VMs mittels TPM gibt es im Netz viele, Suchbegriffe: shielding zusammen mit vTPM.

Auf „alten“ Hyper-V Hosts und/oder „alten“ Gastsystemen (Gen1) müsste man ohne vTPM auskommen und ebenso das geschilderte Vorgehen benutzen.

* gpedit.msc öffnen, dort zu „Computerkonfiguration/Administrative Vorlagen/Windows-Komponenten/Bitlocker-Laufwerksverschlüsselung/Betriebssystemlaufwerke“, gehen und „Zusätzliche Authentifizierung beim Start anfordern“ öffnen ->aktivieren und Haken setzen bei „Bitlocker ohne kompatibles TPM zulassen …“

Dies ist ein Zusatz zum Hauptartikel Meine Wissenssammlung zu Bitlocker

Content-Key: 392173

Url: https://administrator.de/contentid/392173

Ausgedruckt am: 07.08.2022 um 04:08 Uhr

Mitglied: C.R.S.
C.R.S. 09.11.2018 um 19:46:06 Uhr
Goto Top
[Wer nicht möchte, dass eine Schlüsseldatei ständig zugänglich in Laufwerk a: schlummert, muss eben per GPO den Zugriff auf Wechselmedien verbieten, die Floppy zusätzlich mit NTFS formatieren (mit 3rd party tools) und mit ACLs arbeiten, oder diese per Skript nur zum Start der Maschine einlegen.]

Das geht einfacher und vor allem auch in VMs der zweiten Generation, indem man anstelle der Floppy eine VHD nimmt und sie offline setzt (Admin-Rechte für den Zugang erforderlich).

Grüße
Richard
Mitglied: UweGri
UweGri 09.11.2018 um 22:50:29 Uhr
Goto Top
Guten Abend!

Ich nutze BL seit Jahren "verschachtelt". Also LW Bitlockern und darin eine VM ebenfalls. Das LW C lässt sich zumindest bei Virtualbox ohne TPM (lehne ich eh ab (*)) chiffrieren, mittels PW Abfrage beim Start. Weitere LW ebenso.

(*) Es gab vor Tagen einen Artikel, das hardwarebasierte SSD Chiffrierung den Overkill hat. Weltweit ohne Firmwareupdate ab sofort als unsicher gilt. War ein Artikel bei DrWindows. Bei einem TPM ist diese Unsicherheit auch gegeben.

Mir ist klar, dass für eine gute Administration vieles automatisiert sein muss, aber genau das verträgt sich nicht mit dem Konzept Chiffrierung.

Danke für den Beitrag!

Uwe
Mitglied: DerWoWusste
DerWoWusste 10.11.2018 um 11:55:27 Uhr
Goto Top
Hi Richard.

Danke für den Hinweis - ja, das klappt auch und mag einfacher erscheinen als die GPO, zumal es keine Nebeneffekte hat. Nehme ich gleich mit auf.