Datenverschlüsselung ist kein Nice-to-have mehr — sie ist regulatorische Pflicht und Grundlage eines ernsthaften Sicherheitskonzepts. Wer TrueNAS als Speicherlösung betreibt, hat mit ZFS native Encryption ein leistungsfähiges Werkzeug direkt an Bord. Dieser Artikel zeigt, wie Encryption at Rest mit TrueNAS richtig eingerichtet und langfristig sicher betrieben wird.

Warum Encryption at Rest unverzichtbar ist

Physischer Diebstahl passiert. Eine ausgebaute Festplatte, ein entwendeter Server, ein vergessenes Backup-Medium — ohne Verschlüsselung ist der Zugriff auf alle Daten trivial. Keine Authentifizierung, kein Passwort schützt vor jemandem, der das Speichermedium direkt in der Hand hält.

Darüber hinaus schreiben regulatorische Rahmenbedingungen Verschlüsselung vor oder empfehlen sie ausdrücklich:

DSGVO (Art. 32): Technische Maßnahmen zum Schutz personenbezogener Daten — Verschlüsselung wird explizit als Beispiel genannt.
ISO 27001: Kontrolle A.10.1.1 fordert eine Richtlinie zur Verwendung kryptografischer Maßnahmen.
KRITIS-Anforderungen: Kritische Infrastrukturen sind verpflichtet, Daten gegen unbefugten Zugriff zu schützen — Encryption at Rest ist ein Standardbaustein.

Im Schadensfall macht Verschlüsselung den Unterschied: Ein Unternehmen, das nachweisen kann, dass gestohlene Medien verschlüsselt waren, muss unter der DSGVO unter Umständen keine Datenpannenmeldung erstatten. Das ist nicht nur ein rechtlicher Vorteil, sondern schützt auch die Reputation.

ZFS native Encryption vs. LUKS vs. VeraCrypt

TrueNAS-Anwender haben grundsätzlich drei Optionen zur Verschlüsselung:

Kriterium	ZFS native Encryption	LUKS (Linux)	VeraCrypt
Integration	Tief in ZFS integriert	Auf Block-Ebene	Auf Datei-/Container-Ebene
Granularität	Per Dataset oder Pool	Pro Partition/Zvol	Pro Container
Snapshots	Vollständig kompatibel	Funktioniert	Eingeschränkt
Replikation	Verschlüsselte ZFS-Sends	Nicht direkt	Nicht direkt
Key-Management	In ZFS integriert	Externes Tool nötig	Eigenes System
TrueNAS-Support	Nativ, GUI-gestützt	Kein GUI-Support	Kein GUI-Support

Für TrueNAS ist ZFS native Encryption die richtige Wahl: Sie ist tief in das Dateisystem integriert, unterstützt verschlüsselte Replikation und lässt sich vollständig über die TrueNAS-GUI verwalten. LUKS eignet sich für Linux-Systeme ohne ZFS, VeraCrypt für portable Container — beides ist für TrueNAS-Deployments kein sinnvoller Ansatz.

Dataset-Verschlüsselung vs. Pool-Verschlüsselung

ZFS Encryption kann auf zwei Ebenen eingesetzt werden:

Pool-Verschlüsselung bedeutet, dass der gesamte Pool verschlüsselt ist. Das klingt nach maximaler Sicherheit, hat aber einen entscheidenden Nachteil: TrueNAS selbst speichert Betriebsdaten (Konfiguration, Logs) im System-Dataset des Pools. Ist der gesamte Pool gesperrt, kann TrueNAS nicht mehr booten.

Dataset-Verschlüsselung ist die empfohlene Vorgehensweise: Das Root-Dataset des Pools bleibt unverschlüsselt, die tatsächlichen Nutzdaten-Datasets werden verschlüsselt. So bootet das System normal, und die sensiblen Daten bleiben gesperrt bis zur expliziten Entsperrung.

Praktische Empfehlung für die meisten Umgebungen:

Root-Dataset des Pools: unverschlüsselt
Datasets für Nutzerdaten, VMs, Backups: einzeln verschlüsselt
Separate Verschlüsselungs-Keys pro Datenkategorie ermöglichen granulares Zugriffsmanagement

Verschlüsseltes Dataset in TrueNAS einrichten

Die Einrichtung erfolgt direkt in der TrueNAS-GUI unter Storage > Datasets.

Dataset anlegen und Verschlüsselung aktivieren

Storage > Datasets > Add Dataset
  Name:               confidential-data
  Encryption:         Aktiviert (Checkbox)
  Encryption Type:    Passphrase  (oder Key)
  Passphrase:         [starkes Passwort]
  Confirm Passphrase: [Wiederholung]
  Algorithm:          AES-256-GCM  (Standard, empfohlen)

Alternativ über die CLI mit zfs create:

zfs create -o encryption=aes-256-gcm \
           -o keyformat=passphrase \
           -o keylocation=prompt \
           tank/confidential-data

Der Befehl fordert anschließend interaktiv zur Eingabe der Passphrase auf. Das Dataset ist ab diesem Moment verschlüsselt — alle Daten, die geschrieben werden, werden on-the-fly mit AES-256-GCM verschlüsselt.

Passphrase vs. Key-File: Was ist besser?

Passphrase ist intuitiv und für die meisten Umgebungen ausreichend. Der Nachteil: Sie muss bei jedem Unlock manuell eingegeben werden, was automatisches Entsperren beim Boot ohne zusätzliche Maßnahmen verhindert.

Key-File (Hex-Key) ist ein maschinenlesbarer 256-Bit-Zufallsschlüssel, der in einer Datei gespeichert wird. Vorteile:

Kann für automatisches Entsperren hinterlegt werden
Kein menschlicher Faktor bei der Schlüsselqualität
Einfacher in automatisierte Abläufe integrierbar

# Key-File generieren und Dataset damit verschlüsseln
openssl rand -hex 32 > /mnt/secure/tank-confidential.key
chmod 400 /mnt/secure/tank-confidential.key

zfs create -o encryption=aes-256-gcm \
           -o keyformat=hex \
           -o keylocation=file:///mnt/secure/tank-confidential.key \
           tank/confidential-data

Das Key-File selbst muss sicher aufbewahrt werden — idealerweise auf einem verschlüsselten, separaten Medium oder in einem Hardware Security Module (HSM).

Key-Management und Escrow

Der häufigste Fehler bei Encryption at Rest: Der Schlüssel geht verloren. Ohne Schlüssel sind die Daten unwiederbringlich verloren — das ist ja der Sinn der Verschlüsselung, aber es ist auch das größte Risiko.

Key Escrow bezeichnet die gesicherte Hinterlegung von Schlüsseln bei einem vertrauenswürdigen Dritten oder an einem separaten, sicheren Ort. Empfohlene Vorgehensweise:

Passphrase-Dokumentation: Passphrasen in einem Passwort-Manager wie Bitwarden oder 1Password speichern — mit Zugriffsrechten für mindestens zwei Administratoren.
Key-File-Backup: Copies der Key-Files auf einem verschlüsselten USB-Stick, der in einem Safe oder Bankschließfach aufbewahrt wird.
Recovery-Test: Mindestens einmal jährlich den Restore-Prozess testen — ein ungetesteter Schlüssel ist kein zuverlässiger Schlüssel.

In TrueNAS lassen sich Encryption Keys direkt exportieren:

Storage > Datasets > [Dataset] > Export Key

Der Export gibt den Raw-Key als Download — sofort sicher verwahren und nicht auf dem TrueNAS-System lassen.

Datasets entsperren: Manuell vs. Automatisch

Manuelles Entsperren

Nach einem Neustart von TrueNAS sind verschlüsselte Datasets standardmäßig gesperrt. Das Entsperren erfolgt in der GUI:

Storage > Datasets > [Dataset] > Unlock
  Passphrase oder Key-File angeben

Oder per CLI:

zfs load-key tank/confidential-data
zfs mount tank/confidential-data

Automatisches Entsperren beim Boot

Für Datasets mit Key-Files kann TrueNAS so konfiguriert werden, dass beim Start automatisch entsperrt wird:

Storage > Datasets > [Dataset] > Edit > Encryption Options
  Unlock at Boot: Aktiviert

Voraussetzung ist, dass das Key-File an einem für TrueNAS beim Boot erreichbaren Speicherort liegt. Achtung: Liegt das Key-File auf dem TrueNAS-System selbst, bietet automatisches Entsperren nur Schutz vor physischem Diebstahl einzelner Festplatten — nicht vor Diebstahl des gesamten Systems mit dem Key-File.

Für maximale Sicherheit ist manuelles Entsperren die richtige Wahl: Das System bootet, die Daten bleiben gesperrt, ein Administrator entsperrt explizit. Sinnvoll für hochsensible Umgebungen, wo Verfügbarkeit zugunsten von Sicherheit zurücksteht.

Pools exportieren und importieren

Verschlüsselte Pools können auf andere Hardware migriert werden — der Key muss dabei nicht mit den Daten reisen.

# Pool exportieren
zpool export tank

# Pool auf neuem System importieren (ohne Key — Datasets bleiben gesperrt)
zpool import tank

# Key laden und Dataset entsperren
zfs load-key tank/confidential-data
zfs mount tank/confidential-data

Das ist ein wichtiges Konzept: Die Verschlüsselung bleibt beim Export/Import vollständig erhalten. Wer die Festplatten ohne Key in die Hand bekommt, sieht nur chiffrierten Datenstrom.

Performance-Impact: AES-NI macht den Unterschied

Verschlüsselung kostet CPU-Zeit — ohne Hardware-Beschleunigung. Alle modernen Prozessoren (Intel seit 2010, AMD seit 2011) unterstützen AES-NI, den hardwarebasierten AES-Befehlssatz. Mit AES-NI ist der Performance-Overhead von ZFS Encryption praktisch vernachlässigbar:

Szenario	Durchsatz ohne Verschlüsselung	Durchsatz mit AES-256-GCM + AES-NI
Sequentielles Lesen	~3 GB/s	~2,9 GB/s (-3%)
Sequentielles Schreiben	~2 GB/s	~1,9 GB/s (-5%)
Random IOPS	Latenzabhängig	Praktisch identisch

Ob AES-NI auf Ihrem System aktiv ist:

grep -m1 aes /proc/cpuinfo
# Ausgabe sollte "aes" in der flags-Zeile enthalten

In TrueNAS unter System > Advanced > AES-NI lässt sich der Status einsehen. Ohne AES-NI kann die CPU unter hoher Last zum Engpass werden — ein Grund mehr, auf aktuelle Hardware zu setzen.

AES-256-GCM ist der empfohlene Algorithmus: GCM (Galois/Counter Mode) ist ein authentifizierender Verschlüsselungsmodus, der Integrität und Vertraulichkeit gleichzeitig sichert. Er ist schneller als CBC und bietet durch die Authentifizierung zusätzlichen Schutz vor Manipulation.

Backup mit verschlüsselter Replikation

Backups verschlüsselter Datasets haben eine wichtige Eigenschaft: ZFS unterstützt verschlüsselte Replikation, bei der die Daten verschlüsselt übertragen werden — ohne dass das Zielsystem den Key kennen muss.

# Verschlüsselten Snapshot replizieren (Key bleibt auf Quellsystem)
zfs snapshot tank/confidential-data@backup-2026-04-01
zfs send -Rw tank/confidential-data@backup-2026-04-01 | \
  ssh backup-server zfs receive backup-tank/confidential-data

Der Parameter -w (raw) überträgt die verschlüsselten Blöcke direkt — das Zielsystem empfängt chiffrierten Datenstrom und kann ihn ohne den Key nicht entschlüsseln. Das ist ideal für Offsite-Backups zu externen Dienstleistern: Der Backup-Provider sieht nur verschlüsselte Daten.

In TrueNAS lässt sich das über Data Protection > Replication Tasks konfigurieren — die Option Include Dataset Properties sorgt dafür, dass Encryption-Metadaten mit übertragen werden.

Audit-Trail mit DATAZONE Control

Verschlüsselung ist ein technischer Schutz — aber ohne Monitoring wissen Sie nicht, wann Datasets entsperrt wurden, wer Zugriff hatte oder ob Schlüssel exportiert wurden. DATAZONE Control schließt diese Lücke:

Unlock-Events überwachen: Jedes manuelle oder automatische Entsperren eines Datasets wird protokolliert.
Key-Export-Alarme: Wird ein Encryption Key exportiert, löst das eine sofortige Benachrichtigung aus.
Dataset-Status-Monitoring: Offene Frage “Welche Datasets sind gerade entsperrt?” — jederzeit einsehbar im Dashboard.
Compliance-Reports: Automatisierte Nachweise für DSGVO-Audits und ISO-27001-Zertifizierungen, die dokumentieren, welche Daten wann durch welche Verschlüsselungsmaßnahmen geschützt waren.

Encryption ohne Logging ist wie ein Tresor ohne Zugriffsprotokoll — technisch sicher, aber audit-untauglich.

Fazit

ZFS native Encryption in TrueNAS ist ausgereifte, performante Verschlüsselung, die direkt in das Dateisystem integriert ist. Mit AES-256-GCM und AES-NI-Beschleunigung ist der Performance-Overhead minimal. Der eigentliche Aufwand liegt im Key-Management: Schlüssel müssen sicher hinterlegt, regelmäßig getestet und nachvollziehbar dokumentiert werden.

Dataset-Verschlüsselung statt Pool-Verschlüsselung, sorgfältige Key-Escrow-Strategie, verschlüsselte Replikation für Offsite-Backups und lückenloses Monitoring durch DATAZONE Control — das sind die Bausteine einer Encryption-Strategie, die Compliance-Anforderungen erfüllt und im Ernstfall wirklich schützt.

Sie möchten Verschlüsselung at Rest für Ihre TrueNAS-Umgebung einrichten und dabei Compliance-Anforderungen sauber abdecken? Kontaktieren Sie uns — wir konzipieren und implementieren Ihre Encryption-Strategie inklusive Key-Management und Audit-Trail.

TrueNAS Dataset-Verschlüsselung: ZFS Encryption im Einsatz