Layout Server Festplatten

Du kannst die Schlüssel für die weiteren Platten auf der root-Partition ablegen. Sobald die entschlüsselt ist, können damit die weiteren RAID/Daten-Platten entsperrt werden.

Die Reihenfolge macht cryptsetup&co automatisch, einfach in der crypt-tab in der "<key file>"-Spalte eine Schlüsseldatei angeben.

Würde empfehlen, auf der Datenplatte zusätzlich zum Key-File auch ein Passwort einzurichten (Luks kann ja mehrere Key-Slots), dann ist bei Ausfall der Root-Platte nicht alles verloren.

Εrnst B. schrieb:

Die Reihenfolge macht cryptsetup&co automatisch, einfach in der crypt-tab in der "<key file>"-Spalte eine Schlüsseldatei angeben.

Danke das habe ich gesucht. Dann macht es eigentlich auch keinen Sinn diese Datenplatte in die Volume Group aufzunehmen.

Εrnst B. schrieb:

Würde empfehlen, auf der Datenplatte zusätzlich zum Key-File auch ein Passwort einzurichten (Luks kann ja mehrere Key-Slots), dann ist bei Ausfall der Root-Platte nicht alles verloren.

Das mache ich bei allen Platten und Backups werden nochmal separat auf einem anderen Gerät verwahrt, das woanders ist.

Ist das ein gangbarer Weg eine Datenpartition zu haben oder machen das die "echten Profis" ganz anders? Ich möchte zum Beispiel die Daten der Docker Container oder SMB Shares darauf Lagern, da die Betriebssystem Partition klein ist.

Gustav G. schrieb:

Bei der Einrichtung meines Server bin ich mir bei einer Idee zur Partitionierung unsicher.

Überleg dir zuerst Mal welches Dateisystem du nutzen willst. Im Endeffekt hast du eigentlich nur die Wahl zwischen ZFS und BRTFS.

Zumindest bei ZFS kannst du LVM und LUKS streichen... Das macht das Dateisystem selbst.

Datengrab ohne scrubbing würde ich nicht machen.

73

Hans W. schrieb:

Überleg dir zuerst Mal welches Dateisystem du nutzen willst. Im Endeffekt hast du eigentlich nur die Wahl zwischen ZFS und BRTFS.

Für das Root Dateisystem ext4 und für das Datensystem dachte ich an BTRFS innerhalb der LUKS Verschlüsselung.

Hans W. schrieb:

Datengrab ohne scrubbing würde ich nicht machen.

Dafür ja das Hardware RAID.

Moderne Festplatten unterstützen auch eine Hardwareverschlüsselung auf der Platte, das ist evt. für die Performance interessant wenn der Server Stromsparend ist.

Rüdiger B. schrieb:

Moderne Festplatten unterstützen auch eine Hardwareverschlüsselung auf der Platte, das ist evt. für die Performance interessant wenn der Server Stromsparend ist.

Der Server ist ein HPE DL380 Gen10. Der wird im Leerlauf schon mindestens seine 70W ziehen.

Gustav G. schrieb:

... oder machen das die "echten Profis" ganz anders?

Die bauen einfach dicke Mauern und Zaeune um ihre Server. An "Verschluesseln" verschwendet da keiner einen Gedanken. Ein "Austausch" findet bei Gewaehrleistungsfaellen natuerlich auch nicht statt.

Motopick schrieb:

Die bauen einfach dicke Mauern und Zaeune um ihre Server. An "Verschluesseln" verschwendet da keiner einen Gedanken. Ein "Austausch" findet bei Gewaehrleistungsfaellen natuerlich auch nicht statt.

Dicke Mauern und Zäune gehen bei mir nicht.

Gustav G. schrieb:

oder machen das die "echten Profis" ganz anders?

Die verwenden, wenn selbst gehostet, meist keine physischen Server mehr, sondern virtualisierte. Da ist dann Verschlüsselung keine Eigenschaft des in einer VM installierten Systems, sondern der Virtualisierung oder des verwendeten Speichersystems.

(prx) A. K. schrieb:

Die verwenden, wenn selbst gehostet, meist keine physischen Server mehr

Einen physischen Server muss es ja geben um die VMs zu hosten. Der Schlüssel muss dann auch auf dem Root Dateisystem liegen oder für jede VM einmal eingegeben werden?

Monk schrieb:

Unter dem Root Filesystem verstehe ich das Linux System selbst. Da man dieses sowieso frei downloaden kann, sehe ich keinen Bedarf, es zu verschlüsseln.

Bei Verschlüsselung des Betriebssystems geht es in diesem Zusammenhang nicht darum, Leute davon abzuhalten, das Kernel-Image zu klauen. Eher schon um rumlungernde Passwörter. Aber auch um Manipulation zu verhindern.

Bedenke, dass verschlüsselte Dateisysteme weniger effizient sind.

So ziemlich alle nicht steinalte Prozessoren haben Hardware-Support für Verschlüsselung.

Monk schrieb:

Unter dem Root Filesystem verstehe ich das Linux System selbst.

Auf dem Root Dateisystem sind dann allerdings die Schlüssel für die verschlüsselten partitionen.

(prx) A. K. schrieb:

Bei Verschlüsselung des Betriebssystems geht es in diesem Zusammenhang nicht darum, Leute davon abzuhalten, das Kernel-Image zu klauen. Eher schon um rumlungernde Passwörter. Aber auch um Manipulation zu verhindern.

Komplette Verschlüsselung verhindert weder Manupulation noch Datenklau über das Netzwerk. Es geht bei meiner Anwendung darum, dass beim Hardwareklau die Daten für den Dieb niemals sichtbar sind. Der Server ist dann weg aber dann gibt es das Backup.

Thomas W. schrieb:

Wir wissen ja nicht, welche Anforderungen der TO hat: Nur Spielerei oder will er einen Server fuer einen Verarbeiter von Artikel 9-Daten aufbauen?

Der Server wird hauptsächlich als Dateiserver und für Webdienste benutzt und einige Simulationen (keine GPU). Die Anforderung von Kunden ist teilweise sich gegen Hardware Diebstahl zu schützen.

Thomas W. schrieb:

Auch ist das Budget die Frage, sowohl bei der Anschaffung der Platten (wieviele?) und bei dem Betrieb.

Es handelt sich um einen gebrauchten HPE DL380 Gen10 mit festplatten für <2000€. ich wollte etwas erweiterbares, damit man bei mehr Anforderungen nach oben etwas offen ist.

Monk schrieb:

War dafür nicht der TPM Chip? Wobei ich dem auch nicht so richtig traue. Wer Zugang zur Hardware hat, kann den auch auslesen.

Darüber habe ich auch nachgedacht aber was bringt es wenn die Hardware gestohlen wird und das System dann trotzdem bootet weil die Schlüssel auf dem TPM Chip liegen.

Es ist natürlich umständlicher das rootfs erstmal per SSH entsperren zu müssen aber eben die sicherste Lösung denke ich. Es gibt ja dropbear-initramfs.

Es wird sich doch machen lassen, dass die Hardware nicht gestohlen wird ... Wir haetten da einen WW2 Bunker in der Naehe. Kostet nicht die Welt.