Hyper-V und NICs Server 2019

  • Ersteller Ersteller Bob.Dig
  • Erstellt am Erstellt am
Bitlocker nutzt keine Hardware-Verschlüsselung mehr seit 'nem guten Jahr weil es die Hersteller einfach reihenweise verkacken. Man kann es zwar wieder explizit aktivieren aber wenn man einfach nur Bitlocker aktiviert dann erfolgt die Verschlüsselung rein software-seitig. Wenn du ja Server 2019 verwenden willst würde ich der VM einen vTPM geben und dann wie gewohnt. Geht aber "nur" mit Gen2 VMs, bei Gen1 VMs müsste man nen virtuelles Diskettenlaufwerk dran pappen oder so. Fand da zur Erklärung den Artikel recht gut: https://www.itpromentor.com/bitlocker-hyperv-guest/

Der Zusammenhang warum bei Bitlocker der ganze Controller durchgereicht werden muss entzieht sich bei mir jetzt etwas, hast da ggf. einen Link für mich?

Afaik kennen HyperV VMs als Storagecontroller zum booten nur IDE (Gen1) und SCSI (Gen1 & Gen2). Vielleicht kannst deshalb nicht von einem PCIe Device in der VM booten? Auf die Schnelle nur das hier dazu gefunden: https://www.reddit.com/r/HyperV/comments/cu9rmc/dda_for_nmve_as_guest_os_volume/
 
  • Gefällt mir
Reaktionen: Bob.Dig
@snaxilian Was das nvme betrifft, ja den Link hatte ich auch schon gelesen. Denke auch, dass es einfach nicht geht und eine Limitierung von Hyper-V ist. Müsste mal gucken, ob ich mit einer kleinen vhdx nur für die Bootfiles und dann Windows direkt auf ein nvme-Laufwerk installiert bekomme?

Über BitLocker eDrive habe ich eine Abhandlung in meiner Signatur. 😉
 
Naja wenn ich die Wahl habe zwischen einer schlampig umgesetzten und umgehbaren Verschlüsselung oder einer bis heute als sicher geltenden Variante und dafür weniger Performance dann nehme ich letzteres zumal man ja bald gemäß deiner Abhandlung bald keine Wahl hat. Von daher sehe ich für das Thema erst reicht keine Notwendigkeit, ein komplettes Laufwerk durchzureichen. vTPM und dann die VHD bzw. VHDX so verschlüsseln, zumindest würde ich das so machen.
 
@snaxilian Verständlich, aber man kann auch anders dazu stehen, denn erstens war die Verschlüsselung lt. Audit nicht bei jedem Drive zu umgehen und zweitens, MS kontrolliert BitLocker, ich vertraue MS nicht wirklich, ich bevorzuge da Diversität. Und drittens mag ich einfach, wenn sich das Drive drum kümmert. 😉

Ich kann aber jede andere Meinung zum Thema, insbesondere nach der damaligen einseitigen Berichterstattung, auch akzeptieren.
 
Samsung Magician kann das nvme-Drive nicht finden, trotz DDA. Aber eDrive funktioniert jetzt 😄, nachdem es erst so aussah, als würde es nicht, was wiederum daran lag, dass Windows meint, bei dem NVMe-Laufwerk handele es sich um einen Wechseldatenträger...

Natürlich nur als Zweitlaufwerk, booten muss ich leider von einer vhdx mit Windows drauf. Müssen halt ein paar Sachen "manuell" umgebogen werde.
 
Zuletzt bearbeitet von einem Moderator:
Wenn es verschiedene Hersteller nicht fähig sind, die Verschlüsselung vernünftig zu implementieren dann hätte MS 2 Optionen gehabt: Das jeweilige Laufwerk inkl. FW-Version zu prüfen ob eine Lücke bekannt ist und falls nein dann die HW-Verschlüsselung zu verwenden. Ist bei der Einrichtung ein Problem bekannt, dann eben in Software.
Okay, cool und wer soll den Quatsch pflegen und die Kosten dafür tragen? Bei jedem Hersteller und jedem neuen Modell mit jeder Firmware? Was machst wenn dann bei einer Firmware eine neue Lücke auftaucht? Dann das Laufwerk entschlüsseln und neu mit der SW-Verschlüsselung wieder verschlüsseln bis der Anwender oder Admin, sofern vorhanden, die Firmware aktualisiert hat um dann wieder von SW- auf HW-Verschlüsselung zurück zu gehen? Oder soll Microsoft sagen: Lieber Kunde tja schade, dass du dich auf die Verschlüsselung verlässt, die der Hersteller angeblich bietet und zur Verwaltung Bitlocker nutzt aber leider ist diese nutzlos. Mimimi bitte in Richtung Hersteller. Not gonna happen weil der Eindruck entsteht, dass Bitlocker nicht richtig verschlüsseln würde. Auf der anderen Seite: Hersteller hatten ihre Chance und MS hat auf den Streß und Aufwand keine Lust, zumal die meisten Prozessoren AES-NI mitbringen. Somit war das die mMn logischere Wahl. Aber vielleicht hast du ja einen Lösungsweg der deutlich einfacher und trotzdem allgemeingültig ist der bessere wäre?

Zum DDA: Ich meine gelesen zu haben, dass man sich per PowerShell alle DDA-fähigen Geräte anzeigen lassen kann inkl. Status der Unterstützung. Das vBios/vUEFI der VMs muss dann natürlich auch mit allen möglichen Firmwares klar kommen und diese unterstützen und das ist nicht bei allen Geräten der Fall afaik. Wie schon gesagt: Es gibt viele alternative Möglichkeiten zum Ziel zu kommen aber wenn du eine für dich zufriedenstellende Lösung gefunden hast ist doch super.
 
snaxilian schrieb:
Aber vielleicht hast du ja einen Lösungsweg der deutlich einfacher und trotzdem allgemeingültig ist der bessere wäre?
Ich hätte kein Problem mit MS, wenn sie die hardwarebasierte Verschlüsselung einfach nicht mehr zum Standard gemacht hätten, also so, wie sie zuletzt bis 1909 verfahren sind. Es jetzt kommentarlos gar nicht mehr zu unterstützen, lässt bei mir Zweifel aufkommen, was die Motive betrifft.

Bin jetzt mit DDA soweit zufrieden, Magician zu benutzen war auch nie mein Ziel. Die Herumfragerei im Vorfeld war für mich übrigens sehr nützlich, weil ich zwar haufenweise Arbeit habe, aber mir haufenweise andere Arbeit ersparen konnte, was nämlich esxi betrifft, denn diesen konnte ich im Vorfeld für mich als Plattform ausschließen. Gründe dafür waren vor allem der Storage bzw. der Umgang mit dem internen SATA-Controller meines Boards.

Bin tatsächlich happy stand jetzt, so wie es läuft. Mal sehen was pfSense davon hält. Das wird nämlich so gut wie gar nicht auf MS-Sachen validiert.
 
Zurück
Oben