Will man einen RAID verschlüsseln, steht man vor verschiedenen Problemen. Zuallererst muss man sich klar werden, dass eine Verschlüsselung die Datensicherheit (Redundanz) gefährden kann. Tausend Backups nützen nichts wenn der Schlüssel bzw. das Schlüsselfile verloren gegangen ist. Das klingt banal, schießt einen aber ins Knie, wenn der RAID bei einem Systemausfall die wichtigen Daten am Leben hält, das Schlüsselfile aber mit ins Nirwana gegangen ist.

Umgekehrt torpediert dein RAID meist mit der schieren Masse an  Daten die Datensicherheit im Sinne des Zugriffsschutzes. Je mehr Daten man mit dem gleichen Schlüssel verschlüsselt, desto „leichter“ lässt sich der Schlüssel aus dieser Menge extrahieren. Ab 2 GByte sollte man sich intensiv damit beschäftigen, welchen Verschlüsselungsalgorithmus (Cipher) man verwenden kann und mit welcher Schlüssellänge man arbeiten sollte.

Neben solchen theoretischen Vorüberlegungen muss man sich aber auch klar werden wie man Verschlüsseln will. Welche Features will man nutzen, worauf kann man verzichten. Ich für meinen Teil hatte klare Vorstellungen von meinem Setup:

• FullDiskEncryption (FDE): Das RAID Array soll im ganzen verschlüsselt werden.
• Dynamische RAID-Vergrößerung: Ab gewissen Speichergrößen ist eine Verdopplung des Speichers nicht mehr praktikabel oder schlicht bezahlbar.

Beide Punkte zusammen haben jedoch ihren Knackpunkt. Nicht alle Verschlüsselungstechnologien sind bei FDE (oder überhaupt) in der Lage einmal verschlüsselte Container/Volumes in der Größe zu verändern. TrueCrypt kann dies nur bei Containern und dann mit einem Performance-Overhead, der inakzeptabel ist. Bei den OpenSource-Technologien bleibt dann nur noch dm-crypt über. Dieses hat jedoch die „Schwäche“, dass der Verschlüsselungheader (welcher Cipher, Start, Ende, etc) selber unverschlüsselt auf der Platte liegt. Sicherheitstechnisch ist das kein Problem. Auch wenn der Angreifer den Cipher kennt, beißt er sich bei den richtigen Algorithmen und Schlüssellängen die Zähne aus. Nur kann ein dm-crypt Benutzer nicht glaubhaft abstreiten, dass er eben dm-crypt nicht benutzt.

Mir war die juristische Debatte erstmal egal, ich wollte ein verschlüsseltes dynamisches RAID-Device. Das hat mich ein ganzes Wochenende gekostet (500GB auf 750GB zu migrieren dauert immer ungefähr 4 Stunden). Es hat sich mir ein zentrales Problem in den weg gestellt. Es gibt für die Konsole kein Tool, dass eine Partition vergrößern kann, dessen Dateisystem es nicht erkennt. Man kann mittels fdisk die Partitionstabelle löschen und neu schreiben. So sadomasochistisch bin ich aber nicht veranlagt. Man riskiert immer vollen Datenverlust!

Man kann den Umweg über Logical Volume Manager (LVM) gehen. Dazu wird bei einem vergrößerten Device nicht die Partition vergrößert, sondern im neuen freien Bereich einfach eine weitere Partition erstellt. Diese wird dann dem Logischen Device hinzugefügt. Arbeitet man nur mit einem Fake- oder Software-RAID, mag das akzeptabel sein. Kommt es bei diesen zu einem Stromausfall darf man eh beten. Hardware-RAIDs nutzen jedoch BBUs um Datenverlust im Fehlerfall zu unterbinden. Was mit der LVM Zwischenschicht wieder ausgehebelt währe.

Möglichkeit drei ist einfach: man nutzt keine Partitionierung. Dazu muss man einfach wie folgt sein Device „beschreiben“

sudo parted /dev/sdX
mklabel msdos
quit

Nach dieser Aktion hat man eine MSDOS – Partitionierung, aber nicht erschrecken, die verschwindet gleich wieder ;).
Jetzt kann man die Festplatte direkt verschlüsseln, was z.B. bei einer GPT – Partitionstabelle nicht geht.

sudo cryptsetup luksFormat --cipher aes-xts-plain:sha256 -s 256 -q /dev/sdX #Verschlüsselung anlegen
sudo cryptsetup luksOpen /dev/sdX someCryptDev #Verschlüsseltes Device öffnen
mkfs.ext3 /dev/mapper/someCryptDev #verschlüsseltes Device formatieren
mount /dev/mapper/someCryptDev /mnt/someCryptDevUncrypted

Beim Wiedereinhängen einfach luksFormat und mkfs weglassen, sonst blöd 😉
Interessant wird jetzt die Vergrößerung. Dazu im unter lagerten RAID erstmal das Device vergrößern. Um die neue Festplattengröße dem System bekannt zu machen muss man entweder mittels des RAID-Treibers ein rescann auslösen, man entlädt einfach den ganzen Treiber und hängt ihn wieder ein oder startet einfach neu.

sudo lsmod #alle Treiber anzeigen lassen und den RAID-Treiber raus suchen.
sudo modprobe -r
 #RAID-Treiber entladen
sudo modprobe
 #RAID-Treiber laden

Letztes geht nicht ohne das aushängen der gemountet Partition. Besser gesagt, es geht schon, bloß muss man dann mit Datenverlust rechnen. Ein Rescan sollte zu keinem Datenverlust führen, das ist jedoch Treiber-abhängig, in jedem Fall das Manual oder den Maintainer konsultieren. Für 3Ware (jetzt LSI) Raids müssen die Devices z.B. ausgehängt sein.

Ist die neue Festplattengröße im System bekannt, muss man sie nutzbar machen. Dazu gibt es zwei Möglichkeiten:

• Online – ohne Downtime des Dateisystems: Dies benötigt ein Dateisystem, was das Vergrößern/Verkleinern „on-the-Fly“ unterstützt. Das können z.b. EXT3 oder XFS.

  sudo fdisk -lu /dev/sdX #Sektoren raus schreiben
  sudo cryptsetup status  #Offset raus schreiben
  sudo cryptsetup resize -o  -b ;
  sudo resize2fs /dev/mapper/sdX #resize des FileSystems am Beispiel EXT3

• Offline – mit Downtime des Dateisystems: Die kann mit allen Dateisystemen durchgeführt werden, die vergrößert/verkleinert werden können. Es ist auch ein Stück komfortabler.

  sudo umount /dev/mapper/; #aushängen des verschlüsselten Devices (wenn nicht schon vor dem Scann passiert)
  sudo cryptsetup luksClose  #schließen des verschlüsselten Devices (wenn nicht schon vor dem Scann passiert)
  sudo cryptsetup luksOpen /dev/sdX  #damit ist auch schon die Vergrößerung des verschlüsselten Devise erledigt...
  sudo resize2fs /dev/mapper/ #resize des FileSystems am Beispiel EXT3/EXT2

  Beim öffnen des Device nutzt selbiges scheinbar automatisch allen verfügbaren Platz, wenn man nichts anderes (mittels resize) einstellt.

So kann kann in jedem Fall ohne viel Stress seine RAID-Device stückchenweise nach seinen Bedürfnissen erweitern. Dennoch sollte man von allen wichtigen Daten immer ein Backup haben! Zudem sollte man dieses Vorgehen ein, zwei mal geübt haben, bevor man es mit wichtigen Daten durchführt;)