FDE bei Server

[Physikbuddha]

Wir möchten uns gerne einen kleinen Server hinstellen, der Sachen wie NAS, Webserver für Entwicklungszwecke, Geodatenbank für GIS und vielleicht noch ein paar andere Dinge in Zukunft abfrühstückt.

Aufgrund der Daten möchten wir den Server gerne vollverschlüsseln, wie es auch unsere Arbeitsgeräte sind.
Könnt ihr ein paar Richtungen geben, was da Best Practice ist?
Ich sehe ja die größten Probleme einen Headless-Server nach einem Neustart zu entsperren.

Unsere Clients nutzen alle Veracrypt. Wenn sich das auf nem Core-Server installieren lässt, wäre der Plan gewesen einen Hyper-V-Server aufzusetzen, und dort dann für alle Rollen VMs drauf.
Zum Entsperren sollte dann ein Board mit Management-Chip zur Fernwartung verwendet werden.

Alternativ gäbe es auch noch die Option Dropbear zum Entsperren zu verwenden, und dann alle VMs auf dem Linux rennen zu lassen.

Ist so ein vollverschlüsseltes Serversystem überhaupt eine gute Idee?
Würdet ihr ganz anders drangehen?
Vielleicht alle VMs einzeln verschlüsseln? Dann müsste man die alle einzeln entsperren ...

 

[Coca_Cola]

Würde mich ja an ein Systemhaus wenden wenn du was im Betrieblichen Umfeld aufbaust.

 

[xexex]

Vielleicht alle VMs einzeln verschlüsseln? Dann müsste man die alle einzeln entsperren ...

Hier wird dir geholfen.
https://docs.microsoft.com/de-de/wi...c-shielded-vm/guarded-fabric-and-shielded-vms

Lese dich da erst einmal ein, Stichwort für weitere Informationen wäre "Shielded VMs".

 

[Physikbuddha]

Hm, ja gut, aber so wie ich das verstehe wird Bitlocker verwendet (wollen wir nicht), und Passworteingabe gibts auch nicht. Nur der Host wird überprüft. Hilft halt nicht so wirklich, wenn jemand den Server losschneidet und mitnimmt.
Oder sehe ich das falsch?

 

[xexex]

Hm, ja gut, aber so wie ich das verstehe wird Bitlocker verwendet (wollen wir nicht),

Weil?

Verstehe mich nicht falsch, aber bei Serversystemen würde ich definitiv nicht auf Frickelsoftware zurückgreifen und Verschlüsselung soll vor unerlaubten Zugriff bei Diebstahl schützen. Diesen Punkt erfüllt Bitlocker in vollem Umfang.

Soll jetzt aber auch letztlich nur ein Anregung sein, falls dich das nicht überzeugt, habe zumindest ich keine weiteren Tipps wie man das sonst lösen könnte.

 

[Physikbuddha]

Naja, der Grund ist einfach: bei Bitlocker weiß ich einfach nicht, was es für Hintertüren gibt. Veracrypt wurde ja diesbezüglich geprüft und ist Open Source. Empfindest du VC wirklich als "Frickelsoftware"?

Und auf Linux-Guests gibts ja kein Bitlocker.

Ergänzung (20. November 2019)

Ergänzung: Nochmal kurz laut gedacht.

Wenn wir Bitlocker verwenden, und alle VMs shielden, dann ist die Passworteingabe zum Booten der VMs nicht erforderlich, da das vTPM-System verwendet wird.

Wenn ein Angreifer den Server wirklich klauen sollte, dann kommt er nicht an die Daten heran, da der Netzwerkzugriff passwortgeschützt ist, die VHDX verschlüsselt sind, und direkt auf die Serveroberfläche kommt man auch nicht, da dort natürlich auch ein Passwort zum einloggen gebraucht wird.

Übersehe ich irgendwelche Angriffsvektoren?

Wie ist das mit den Linux-Clients? (Eigentlich wollen wir fast nur Linuxclients verwenden. Eigentlich wollten wir möglichst wenig Microsoft-Software verwenden, um sich nicht so abhängig zu machen.) Unterstützt die Ubuntu-Systemverschlüsselung denn TPM? Bin da nicht so fit. Kriegen wir diese Systeme auch richtig dicht?

 

[snaxilian]

@Physikbuddha Welchen "Grund" habt ihr gegen Bitlocker? Lass mich raten: Bauchgefühl weil bestimmt mit NSA Backdoor? Tja dann solltet ihr nicht Windows nutzen. Entweder ihr vertraut dem Laden oder nicht. Ist wie "ein bisschen schwanger", geht ebenso wenig...

Entweder ihr müsst beim Reboot einer VM einen Key eingeben oder den zugänglich ablegen, siehe Dropbear Methode. Aber dann liegt der Key halt woanders im Klartext außer das System hat ebenfalls eine FDE und abgesicherten SSH Zugang. Dürfen Key-Host und VMs halt nie gleichzeitig neu starten...
Alternativ den Key auf eine virtuelle Diskette packen und an jede VM hängen. Aber wie gesagt: Wird der Host kompromittiert > Key kompromittiert da eben dauerhaft dort.

Die shielded VM Lösung ist btw nix anderes nur technisch etwas anders umgesetzt. Dort wird ein vTPM verwendet in dem der Key liegt. Kommt die VM nicht an den vTPM heran beim Start > Keine Entschlüsselung. Vorteil ist dabei, dass auch du als Admin oder ein Angreifer nicht an den vTPM kommt. Selbst wenn er den ganzen Cluster mit nimmt kommt er nicht an die VMs solange er keine gültigen Credentials hat.

So oder so musst du deine Fragestellung verfeinern: Vor welchen Szenarien wollt ihr euch schützen? Je nach Szenario gibt es andere mögliche Lösungen.

edit: Ist heute schon wieder Google kaputt oder stellst du dich absichtlich faul an? Shielded VMs mit HyperV als Hypervisor kann auch Linux Gäste. Wenn ihr kein MS nutzen wollt: VMware kann dies ebenso ab vSphere 6.5 aber auch wenn dort vieles auf Linux basiert ist es Closed Source und damit nicht sicherer oder unsicherer als MS.
Generell: Diese Funktionalität soll vor "rogue admins" schützen, sprich du als Admin sollst keine Möglichkeit haben auf den Server von HR zuzugreifen. Sei es durch Kopie der VMDK und Auswertung zuhause o.ä. oder wenn ihr eure VMs auf einem Cluster hostet, der nicht euch gehört, Stichwort "Cloud" oder Hosting wie es seit gefühlt über 20 Jahren heißt.

Sicherheit und Bequemlichkeit müssen immer gegeneinander abgewogen werden. Ein sich selbst beim Start entschlüsselndes System wird sich auch selbst entschlüsseln wenn der Angreifer es komplett mit nimmt. Bei der Dropbear Lösung könnte man z.B. den Zugriff per iptables einschränken und dieses System an anderer Stelle aufbewahren oder der Key wird abends in einen Safe geschlossen. Dann klappt zwar auch kein Reboot nachts aber ein Einbrecher kann nix damit anfangen wenn er die physischen Systeme klaut. Der "rogue admin" hingegen schon.
Das ist aber wieder ein anderer Angriffsvektor und dagegen hilft nur: Loginrechte für den Admin verbieten. Config ausschließlich aus einem Config-Mgmt-Tool heraus wie puppet oder ansible und die Config dafür in ein git mit append only, sprich komplette Nachvollziehbarkeit wer wann was gemacht hat.

 

[xexex]

Naja, der Grund ist einfach: bei Bitlocker weiß ich einfach nicht, was es für Hintertüren gibt.

Ein oft hervorgebrachter "Argument", aber kommt die NSA bei dir ins Haus und klaut dir die Server?

 

[PHuV]

Zudem ist Bitlocker doch viel besser in Windows integriert und macht auch alle Updates der Server und Desktops mit, was VC eben nicht so mal kann. Wiederherstellungsschlüssel werden ebenso im AD gesichert, so daß auch jederzeit wieder ein Entschlüsseln möglich ist.

 

[Physikbuddha]

Die Vor- und Nachteile müssen natürlich individuell abgewägt werden.

Das war alles sehr aufschlussreich, und wir haben jetzt einen klaren Plan für die Umsetzung.
Danke für das konstruktive Feedback.