ZFS-Verschlüsselung

N

nukim

gefährlich Halbwissender
Hiho@all, ich bin momentan am aufsetzen eines FreeBSD-13-Server (HP DL360gen9, 64GB RAM, 2x PM987, 6x SAS-HDD, 1x PM893 im Optical-Drive-Caddy für OS).
Die PM987 werden als mirror-Pool, die SAS-HDD als raidz2-Pool verwendet. Auf dem mirror-Pool soll mittels bhyve ein Windows 2019 virtualisiert werden. Der raidz2-Pool soll den Speichernplatz für Samba-Jails bereitstellen.

Da wir aufgrund gesetzlicher Vorgaben gezwungen sind, eine Verschlüsselung einzusetzen (BGB, DSGVO - Stand der Technik) möchte ich den mirror-Pool, sowie den raidz2-Pool, mittels nativer-ZFS-Verschlüsselung aufbauen.

Unser Backup-Server (XigmaNAS, HP ML110gen9, 4x 4TB HDD) macht die Verschlüsselung der Festplatten mittels geli.

Was ich bisher herausgefunden habe, ist das die native-ZFS-Verschlüsselung nur auf Dataset anwendbar ist.
ZFS lädt ja beim Start des Rechners automatisch die Pools. Bei einer Verschlüsselung per Passphrase ist dies jedoch nicht möglich.
Beim Neustart des Backup-Server muss ich immer die einzelnen HDD entschlüsseln, attachen und dann den Pool neueinlesen.

Wie gehe ich vor beim FreeBSD-13-Server? Die Datasets auf dem raidz2-Pool werden wahrscheinlich beim mounten per Passphrase eingebunden. Beim mirror-Pool habe ich ein zvol angelegt (Bsp aus FreeBSD-Handbuch: # zfs create -V16G -o volmode=dev zroot/linuxdisk0), wie wird das geladen/eingehängt?
 
Ich weiß nicht genau was jetzt deine Frage ist, wenn du ein dataset verschlüsselst, lädst und mountest du es nach einem neustart mit:

zfs load-key DATASET
zfs mount -a oder zfs mount DATASET
 
@Andy_m4: Beim Backup-Server wird alles per XigmaNAS-Web-Gui erledigt. kein Problem :-)

@medV2: mein Problem ist, wenn ich das zvol laut Handbuch anlege, ist es in /dev/zvol/vm-disk (laut zfs list ohne Mountpoint ("-")), beim Neustart werde ich nicht nach der Passphrase gefragt, wie bekomme ich es hin, das nach einem Neustart, das zvol in /dev/zvol/.. angelegt ist um darauf zuzugreifen?
 
hi

was mich interessieren wuerde , wo steht geschrieben das man auf einem Server , der im zweifel
permanent laeuft , platten verschluesseln muss ?

Bitte Gesetz und paragraph angeben , zum nachlesen.

Holger
 
mark05 schrieb:
hi

was mich interessieren wuerde , wo steht geschrieben das man auf einem Server , der im zweifel
permanent laeuft , platten verschluesseln muss ?

Bitte Gesetz und paragraph angeben , zum nachlesen.

Holger
Zum Vergrößern anklicken....

Hallo Mark,

ich denke der Satz

nukim schrieb:
Da wir aufgrund gesetzlicher Vorgaben gezwungen sind, eine Verschlüsselung einzusetzen (BGB, DSGVO - Stand der Technik) möchte ich den mirror-Pool, sowie den raidz2-Pool, mittels nativer-ZFS-Verschlüsselung aufbauen.
Zum Vergrößern anklicken....

"Stand der Technik" ist hier der Punkt. Was "Stand der Technik" ist, ist natürlich immer auslegungssache der Gerichte - und auch frage der eigenen Argumentation.
Letztlich wird als absolutes Minimum oft das herangezogen was relativ offensichtlich und relativ einfach ist. In Zeiten von Bitlocker den man auch als enduser mit 2 klicks aktivieren kann, kann das schon eine lokale Festplattenverschlüsselung sein.

Ob wirklich notwendig hängt sicherlich von weiteren Faktoren ab, steht das Gerät in einem 24/7 zb durch einen Sicherheitsdienst überwachten Gebäude oder in einem umbewachten Gebäude in einem Industriegebiet am Stadtrand mit einfacher Alarmanlage.

Aus meiner Praxis als ich noch kleine Betriebe als Dienstleister betreut habe, in den 2000ern, war Datenverlust durch Diebstahl der Server (Inkl. der oft daneben liegenden Backups :( ) noch vor defekten Festplatten (!) und vor weiteren Elementarschäden der mit dtl. Abstand häufigste Grund für Datenverlust. (Entsprechend oft bete ich Matraartig "Raid ist kein Backup, HA ist kein Backup ... die nehmen idr erstmal pauschal alles mit was nach "könnte Geld bringen" aussieht)

Entsprechend halte ich es schon für zumutbar bis "Stand der Technik" das man in vielen Situationen Festplatten verschlüsselt auf denen Personenbezogene Daten gespeichert werden. Bei uns zb auch die SSDs von Notebooks die das Gelände verlassen.
 
mark05 schrieb:
der im zweifel
permanent laeuft , platten verschluesseln muss ?
Zum Vergrößern anklicken....
Von Verschlüsselung von Platten steht ohnehin nichts im Gesetz. Gegenstand ist, das personenbezogene Daten nicht in unbefugte Hände gelangen dürfen. WIE Du das umsetzt ist erst mal nebensächlich.

Unbeachtet dessen ist Festplattenverschlüsselung natürlich ein Weg, den man gehen kann. Und es ist auch nicht die schlechteste Idee das zum Default zu machen, auch wenn es für ein Szenario augenscheinlich erst mal wenig bringt.
Denn Festplattenverschlüsselung kostet quasi nix, weil die modernen Prozessoren Befehlssätze dafür haben (Stichwort AES-NI). Zweitens kann selbst ein Server ja mal Diebstahl und ähnlichem zum Opfer fallen. Und spätestens nach Lebensende der Platte gehen ja die Probleme los. Die müssen dann fachgerecht entsorgt werden usw.

Ich würde es daher eher umgekehrt sehen. Wenn Du es nicht machst und es passiert irgendwas, was Du vorher gar nicht bedacht hast, wirst Du immer dem Vorwurf ausgesetzt sein, warum Do sowas einfaches wie Plattenverschlüsselung nicht eingeschaltet hast. Insofern schließe ich mich meinem Vorredner an.
 
geklaut bei "https://dsgvo-gesetz.de"

"Auch der Datenschutz verkennt das Risiko bei der Verarbeitung personenbezogener Daten nicht und legt dem Verantwortlichen und dem Auftragsverarbeiter gemäß Art. 32 Abs. 1 Datenschutz-Grundverordnung deshalb auf, geeignete technische und organisatorische Maßnahmen zur Sicherung der personenbezogenen Daten zu treffen. Dabei sind der Stand der Technik, die Implementierungskosten, sowie die Art, der Umfang, die Umstände und der Zweck der Verarbeitung zu berücksichtigen. Neben diesen Kriterien sind auch die unterschiedlichen Eintrittswahrscheinlichkeiten und die Schwere des Risikos für die Rechte und Freiheiten der Betroffenen mit einzubeziehen. Dementsprechend sollte der Grad der getroffenen Sicherheitsmaßnahmen angepasst werden. Die Verschlüsselung wird dabei explizit als eine solche Maßnahme im nicht abschließenden Katalog des Art. 32 Abs. 1 EU-DSGVO angeführt."

Das irrwitzige ist ja, das eigentlich die Entschlüsselung manuell erfolgen muss. Eine automatische Entschlüsselung per irgendwo im Intranet gespeicherten Key würde ja eine "Security by obscurity" bedeuten, was sinnlos wäre.

@medV2 thx, das ZFS-Volume wird jetzt als /dev/zvol/vm-pool/vm-disk angezeigt.
 
nukim schrieb:
geklaut bei "https://dsgvo-gesetz.de"

"Auch der Datenschutz verkennt das Risiko bei der Verarbeitung personenbezogener Daten nicht und legt dem Verantwortlichen und dem Auftragsverarbeiter gemäß Art. 32 Abs. 1 Datenschutz-Grundverordnung deshalb auf, geeignete technische und organisatorische Maßnahmen zur Sicherung der personenbezogenen Daten zu treffen. Dabei sind der Stand der Technik, die Implementierungskosten, sowie die Art, der Umfang, die Umstände und der Zweck der Verarbeitung zu berücksichtigen. Neben diesen Kriterien sind auch die unterschiedlichen Eintrittswahrscheinlichkeiten und die Schwere des Risikos für die Rechte und Freiheiten der Betroffenen mit einzubeziehen. Dementsprechend sollte der Grad der getroffenen Sicherheitsmaßnahmen angepasst werden. Die Verschlüsselung wird dabei explizit als eine solche Maßnahme im nicht abschließenden Katalog des Art. 32 Abs. 1 EU-DSGVO angeführt."

Das irrwitzige ist ja, das eigentlich die Entschlüsselung manuell erfolgen muss. Eine automatische Entschlüsselung per irgendwo im Intranet gespeicherten Key würde ja eine "Security by obscurity" bedeuten, was sinnlos wäre.

@medV2 thx, das ZFS-Volume wird jetzt als /dev/zvol/vm-pool/vm-disk angezeigt.
Zum Vergrößern anklicken....


Stand der Technik darf man sich hier nicht als das vorstellen, was "wir" als SdT bezeichnen würden, sondern was sich ein alter Beamter in seinem Kämmerchen vorstellt.

Bei uns wurde mal eingebrochen und u.a. Notebooks gestohlen von denen eins leider auch unverschlüsselt war. Zur Vorsicht haben wir uns dann von einer Anwaltskanzlei beraten lassen: Das verschließen der Datenträger in den Geschäftsräumen ist fast immer ausreichend. Zudem dürfen nur die MA Zugang haben, für denen der Zugang auch erforderlich ist, sofern es mit vertretbarem Aufwand umsetzbar ist. Also Serverraum versperren, Rechnungsdaten von Kunden z.b. im verschlossenen Büro des Chefs/der Buchhaltung.
Verschlüsselt werden müssen z.b. Notebooks die Mitarbeiter mitnehmen und die Geschäftsräume verlassen.

Nach dem Einbruch hatten wir auch bezüglich einer Videoüberwachung überlegt, da habe ich mich mit den zuständigen Behörden rumgeschlagen: Denen war eine security by obscurity Lösung von einem Drittanbieter (der Verschlüsselungskey war da im Binary einkompiliert, könnte man also mit etwas Debugging da auch rausholen) lieber, als meine selbsterdachte Bastellösung die wirklich sicher wäre. Zitat war hier Sinngemäß: "System von Hersteller X ist tausend mal im Einsatz, da sind Sie auf der sicheren Seite. Ihre Lösung klingt sicher, im Zweifel muss das bei einem Vorfall aber genau untersucht, und dann entschieden werden."
Wir habens dann aber ohnehin bleiben lassen.

Achtung, das war vor einigen Jahren und in Österreich. Das ist keine Rechtsberatung ;)

Aber ich persönlich verschlüssle natürlich auch gerne, wie schon erwähnt kostet es nichts und hilfts nichts, dann schadet es auch nicht.
 
medV2 schrieb:
Bei uns wurde mal eingebrochen und u.a. Notebooks gestohlen von denen eins leider auch unverschlüsselt war. Zur Vorsicht haben wir uns dann von einer Anwaltskanzlei beraten lassen: Das verschließen der Datenträger in den Geschäftsräumen ist fast immer ausreichend. Zudem dürfen nur die MA Zugang haben, für denen der Zugang auch erforderlich ist, sofern es mit vertretbarem Aufwand umsetzbar ist. Also Serverraum versperren, Rechnungsdaten von Kunden z.b. im verschlossenen Büro des Chefs/der Buchhaltung.
Verschlüsselt werden müssen z.b. Notebooks die Mitarbeiter mitnehmen und die Geschäftsräume verlassen.
Zum Vergrößern anklicken....

Unsere Firmenanwälte sowie die spezialisierten Anwälte für Datenschutz sagen etwas komplett anderes.

Und nochmal: Heutzutage ist "Festplattenverschlüsselung" halt mit 2 Klicks in Windows aktiviert - klar man kann ewig über die Qualität von Bitlocker streiten aber ich denke für mehr als 99,9% der Einbrecher die das Zeugs nur weiterverkaufen wirds locker reichen.

Aber durchaus möglich das man das in Österreich rechtlich anders sieht ;)
 
Eine Sache, die auch noch interessant wäre: Die native ZFS-Verschlüsselung erlaubt es, per zfs send + receive Daten verschlüsselt zu versenden und zu speichern, z.B. zu einem Backup-Server. Selbst im laufenden Betrieb müssen sie dazu nirgends entschlüsselt werden. Jemand der sich durch irgendeinen remote exploit Zugriff auf den Backup-Server verschafft, kann die dort gespeicherten Daten trotzdem nicht lesen.

Deshalb richte ich meine neue Laptop-SSD gerade mit GELI und ZFS-Verschlüsselung ein. Eigentlich wollte ich das Basissystem in einer GELI-verschlüsselten Partition ablegen und alles unter /usr/home/<ich> als verschlüsselte ZFS-Datasets in einer anderen Partition. Leider habe ich nicht herausgefunden, wie ich das installieren müsste. Daher habe ich doch die gesamte Festplatte GELI verschlüsselt und zusätzlich die besagten Datasets ZFS-verschlüsselt, damit ich sie so sicher backup'pen kann.

Die Schlüssel für die ZFS-Datasets liegen bei mir unter /keys, so dass mein verschlüsseltes Home-Verzeichnis ohne Passphrase automatisch gemounted werden kann. Solange ich dieses Verzeichnis nicht ins Backup schreibe, sind meine Daten dort sicher. So habe ich es auch schon mit einem Verzeichnis auf dem Server gemacht, wo die MariaDB-Dumps liegen. Das verschlüsselte Dataset wird alle 2h auf einen externen Server kopiert, per zfs send + receive. Klappt tadellos.
 
Achtung gefährliches Halbwissen: Du bräuchtest doch nur dem verschlüsselten Dataset als Mountpoint "usr/home/<ich>" mit geben, oder?

Bei meinem Backupserver (Xigmanas) war die native ZFS-Verschlüsselung noch nicht so "ausgereift". Deshalb griff ich zu geli-Verschlüsselung. Geli verschlüsselt die komplette Festplatte. Bei ZFS-Verschlüsselung werden ja momentan nur Datasets verschlüsselt, die Metadaten sollen ja unverschlüsselt vorliegen (kA was alles Metadaten umfasst, die Dataset-Struktur ist glaub ich irrelevent für Spione, da die eigentlichen Daten ja verschlüsselt vorliegen).

Bei Verwendung von ZFS wird ja von Hardware-Raid-Controller abgeraten, wegen des fehlenden vollen Zugriffs auf die Datenträger. Sollte es beim Einsatz von geli nicht ähnlich sein?
 
nukim schrieb:
Du bräuchtest doch nur dem verschlüsselten Dataset als Mountpoint "usr/home/<ich>" mit geben, oder?
Zum Vergrößern anklicken....
Naja. Nicht ganz. Es können sich auch außerhalb des Home-Verzeichnisses "problematische" Daten ansammeln. Typische Beispiele sind hier die temporären Verzeichnisse, Swapspace und dergleichen.
 
nukim schrieb:
Achtung gefährliches Halbwissen: Du bräuchtest doch nur dem verschlüsselten Dataset als Mountpoint "usr/home/<ich>" mit geben, oder?
Zum Vergrößern anklicken....

Im Prinzip ja. Dies waren die Schritte, die ich gemacht habe. Damit wird das Dataset beim Booten automatisch entschlüsselt und gemounted.

Code: 
# ZFS-Key für Home-Verzeichnis generieren (hier in hex Format)
openssl rand -hex 32 > /keys/usr_home_<ich>.key


# ZFS-verschlüsseltes Dataset anlegen
zfs create -o encryption=aes-256-gcm -o keyformat=hex -o keylocation=file:///keys/usr_home_<ich>.key -o mountpoint= /usr/home/<ich> zroot/usr/home/<ich>


# ZFSKeys beim Booten laden
sysrc zfskeys_enable="YES"

Zu den anderen Punkten kann ich nicht viel sagen.

Die Meta-Daten, die noch sichtbar sein könnten, machen wir keine Sorgen. Ein Punkt war da immer, dass man nicht mehr glaubhaft abstreiten könne, dass da doch überhaupt gar keine nützlichen Daten seien und man daher von z.B. einem Geheimdienst dazu gezwungen werden könnte, die Daten zu entschlüsseln.

Aber das sehe ich für mich nicht als relevantes Angriffs-Szenario. Ich will in allererste Linie verhindern, dass personen-bezogene oder sonstwie sensitive Informationen von irgendwelchen Bösewichten abgezogen und missbraucht werden. Selbst wenn ein Hacker aus den Metadaten herausfinden könnte, dass da ein Verzeichnis mit Naktfotos von mir existiert, ist mir das herzlich egal, solange er oder sie die Fotos selbst nicht lesen kann.
 
Andy_m4 schrieb:
Naja. Nicht ganz. Es können sich auch außerhalb des Home-Verzeichnisses "problematische" Daten ansammeln. Typische Beispiele sind hier die temporären Verzeichnisse, Swapspace und dergleichen.
Zum Vergrößern anklicken....
Das ist richtig. Da muss man sich gut überlegen, was man ins Backup schiebt und daher vielleicht verschlüsselt haben möchte: Swap würde vermutlich niemand sichern wollen, aber natürlich gibt es noch diverse Stellen in einem System, an dem sensitive Daten liegen können (die etc-Verzeichnisse, Log-Dateien,...).
 
wird nicht deshalb auch bei Verwendung DSGVO-relevanter Daten empfohlen das swap zu verschlüssen?
 
Generell ist es empfehlenswert alles wo potentiell sensible Daten auftauchen können zu verschlüsseln. Also selbst wenn Dinge nicht im Backup landen, so hast Du ja noch die Problematik das die dann unverschlüsselt im Originalsystem liegen. Man darf ja auch nicht vergessen, das man die im Zweifel nicht mehr gelöscht kriegt. Gerade in Zeiten von SSDs, wo ja auch viel mit Reserveblöcken gearbeitet wird und Du unter Umständen gar keinen Zugriff mehr drauf hast, ist das halt nicht unproblematisch (und allein auf Secure Erase verlassen ... naja).
Das kriegt man sicher alles irgendwie gemanagt. Aber wie gesagt. Man weiß ja nie, was passiert. Und Verschlüsselung tut einfach zu wenig weh als das man es nicht im Zweifel lieber anschaltet, anstatt sich erst mal ewig darüber Gedanken zu machen, ob man es wirklich braucht (und dann am Ende doch ein Szenario nicht im Blick hat).
 
Drollig sind immer solche Formulierungen wie: "Und zwar mit einem bisher als sicher geltenden Verfahren." Es ist halt ein Hase-Igel-Spiel :-)
 
Naja. Irgendwo muss man halt anfangen. Niemand kann in die Zukunft gucken. Wenn es darum geht, jegliches Risiko zu vermeiden, dann dürfte man ja gar nichts machen.
Aber selbst dem Aspekt wird ja Rechnung getragen durch Prinzipien wie Datensparsamkeit.
 
nukim schrieb:
Bei Verwendung von ZFS wird ja von Hardware-Raid-Controller abgeraten, wegen des fehlenden vollen Zugriffs auf die Datenträger. Sollte es beim Einsatz von geli nicht ähnlich sein?
Zum Vergrößern anklicken....

Bei geli sollte das ziemlich egal sein, das ist ja transparent für alle beteiligten. Auch für ZFS halte ich das so pauschal für groben Unfug, man kann durchaus seinen Raidcontroller so konfigurieren, dass er z.b. die Platten einzeln ohne große Magie ans System und ZFS durchreicht, man aber dennoch vom Cache des Controllers profitiert.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben