sbruder hat geschrieben:Ah OK danke, jetzt hab ichs verstanden! IPMI-Zeug ist da sicher auch so ein Kandidat.
IPMI ist sideband - das hat ein paar hooks ins BIOS, konsolenumleitung und "powermanagement" (power/reset); aber läuft nicht "unterhalb" des OS wie das BIOS/EFI.
Jede Verschlüsselung, die vom Server selbst zur Laufzeit umgekehrt werden muss, ist sinnlos wenn jemand physischen Zugriff auf das System oder auf den Kommunikationskanal hat, über den die Daten (bereits entschlüsselt) übertragen werden. Zudem muss das Token entweder bereits am Server sein, z.B. als USB-Key, dann muss der "Dieb" aber so blöd sein und den USB-Key ausstecken und zurücklassen, oder man muss bei jedem Bootvorgang per Konsole (SoL, IPMI, serial über anderes system...) erst das Token übermitteln. Für nen Server ist sowas also völlig unbrauchbar.
Wirkungsvoll ist in diesen Fällen nur (dateisystembasierte) Verschlüsselung, die erst am Client umgekehrt wird.
Unter Linux ist mir bisher nichts derartiges bekannt. An meinem Storageserver (FreeBSD) Zuhause ist mein home-dataset mit PEFS[1] verschlüsselt, wird auch verschlüsselt per SSHFS oder NFS an den Clients (FreeBSD oder TrueOS) gemounted und dann lokal entschlüsselt. Pefs "mounted" dabei nochmals über den selben mountpunkt und liegt dann praktisch als ver/entschlüsselungsschicht dazwischen. Das alles erfolgt erst am Client - Daten im Transit und am Server sind immer verschlüsselt (Transit zusätzlich durch die SSH-Verbindung) und da es sich um ein Dateisystem und keinen container (dm-crypt o.ä.) handelt, kann auch problemlos konkurrierend von mehreren Clients gemounted werden, da alle lockingmechanismen des Dateisystems am Server erhalten bleiben. Auch inkrementelle, dateisystembasierte backups wie tarsnap sind (fast) ohne Einschränkung möglich - bei containern muss immer der gesamte (ggf fast komplett leere) container gesichert werden.
Auch mein home-dataset am Notebook ist so verschlüsselt - das System kann dadurch ganz normal gebootet werden (nach BIOS-bootpasswort), mein user könnte mit dem normalen Userpasswort einloggen (das nicht dem PEFS-Passwort entspricht), im home-Verzeichnis liegt dann aber nur vermeintlicher Datenmüll - durch die 'gescrambelten' Dateinamen sieht das ähnlich wie ein zerschossenes Dateisystem aus und durch die "fehlenden" configdateien verhalten sich Desktopoberfläche und alle Programme wie bei einer frischen Installation bzw einem neuen User.
Nur wenn ich mich mit dem PEFS-Passwort einlogge, wird gleichzeitig auch das home-dataset entschlüsselt. Dank PAM-modul lässt sich das völlig transparent und trivial in den normalen Login einbauen.
Der enorme Vorteil von PEFS ist, dass auch auf Systemen mit mehreren hundert usern jeder user sein home-Verzeichnis effektiv verschlüsseln kann. Das Betriebssystem (das ohnehin generisch ist), bleibt unverschlüsselt und immer lauffähig (wichtig für Fehlerbehebung, recovery etc), die sensiblen Daten der user sind nur von diesen entschlüsselbar - somit kann auch kein Admin gezwungen werden (nicht vorhandene) keys herauszugeben und da die Entschlüsselung erst am Client erfolgt, werden auch keine unverschlüsselten Daten am Server in RAM/SWAP/Caches geleaked.
Durch unterschiedliche user- und PEFS-Passwörter können auch andere Betriebssyteme ein PEFS-verschlüsseltes Dateisystem per SSH mounten. Ist das PAM-modul für PEFS in der chain, wird beim Login einfach das PEFS-Kennwort angegeben und das PEFS-modul erledigt den overlay-mount und Entschlüsselung am Server. Die Vorteile sind zwar damit deutlich reduziert, man kann so aber auch von Linux- und OS X-Clients zugreifen. (KA ob es für Windows ne Lösung für SSHFS gibt... Ansonsten kann samba IIRC auch PAM für logins nutzen)
[1]
http://pefs.io/
