Zum Hauptinhalt springen

Datenbankverschlüsselung

Libre WebUI enthält einen Verschlüsselungsdienst auf Anwendungsebene für sensible Werte, bevor sie gespeichert werden.

Verschlüsselungsverfahren​

Das Backend verwendet AES-256-GCM über das Kryptografiemodul von Node.js. Der Schlüssel muss 32 Byte lang und als 64-stellige Hexadezimalzeichenfolge dargestellt sein:

ENCRYPTION_KEY=0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef

Schlüssel erzeugen:

openssl rand -hex 32

Schlüsselspeicherung​

Libre WebUI lädt den Schlüssel in dieser Reihenfolge:

  1. ENCRYPTION_KEY aus der Umgebung.
  2. Eine persistente Datei .encryption_key im gewählten DATA_DIR.
  3. Nur bei einem neuen Speicher einen neu erzeugten Schlüssel, der vor dem Datenbankstart dauerhaft nach DATA_DIR/.encryption_key geschrieben wird.

Liefern Umgebung und Datei jeweils einen Schlüssel, müssen sie übereinstimmen, sonst schlägt der Start fehl. Ein bestehender verschlüsselter Zustand ohne Originalschlüssel wird ebenfalls sicher abgewiesen; Libre erzeugt keinen Ersatz für einen vorhandenen Speicher.

Wichtige Schlüsselregeln​

  • Sichere ENCRYPTION_KEY zusammen mit der Datenbank.
  • Rotiere den Schlüssel nur mit einem Migrationsplan für verschlüsselte Werte.
  • Ohne Schlüssel können verschlüsselte Werte nicht wiederhergestellt werden.
  • Ein Schlüsselwechsel ohne Neuverschlüsselung macht vorhandene Werte unlesbar.

Was geschützt wird​

Die Verschlüsselung wird von Codepfaden angewendet, die den Dienst oder verschlüsselte Speicherhilfen verwenden. Sie ist für sensible Anwendungswerte wie Zugangsdaten und private Benutzerdaten gedacht, die von diesen Hilfen verarbeitet werden.

Sie ist keine vollständige Datenträger-, SQLite-Seiten- oder Ende-zu-Ende-Verschlüsselung zwischen Benutzer und Browser. Verwende Datenträgerverschlüsselung und HTTPS für diese Ebenen.

Work-Daten​

Die Anwendungsverschlüsselung verschlüsselt nicht eine gesamte Work-Aufgabe. Quelldateien und Abhängigkeiten sind normale Dateien in aufgabenspezifischen benannten Docker-Volumes. Work-Unterhaltungen, Werkzeugergebnisse, Befehlsausgaben und Metadaten liegen in SQLite und werden nicht automatisch verschlüsselt, nur weil einige Zugangsdatenpfade den Dienst nutzen.

Schütze Docker-Datenstamm und DATA_DIR bei Bedarf mit Zugriffskontrollen und Datenträgerverschlüsselung. Sichere Datenbank, ENCRYPTION_KEY und verwaltete Work-Volumes gemeinsam. Ein Remote-Work-Lauf kann dem Anbieter Kontext sowie angeforderte Datei- oder Befehlsausgaben offenlegen; Speicherverschlüsselung ändert diese Netzwerkgrenze nicht.

Docker und Kubernetes​

Setze für die Produktion einen stabilen Schlüssel:

ENCRYPTION_KEY=replace-with-64-hex-characters
DATA_DIR=/data

Binde DATA_DIR auf persistentem Speicher ein. Speichere den Schlüssel in Kubernetes in einem Secret und die Daten auf einem PersistentVolume.

Fehlerbehebung​

Ungültige Schlüssellänge

Der Schlüssel muss genau 64 Hexadezimalzeichen enthalten. Erzeuge einen neuen mit:

openssl rand -hex 32

Daten lassen sich nach erneuter Bereitstellung nicht entschlüsseln

Prüfe, ob derselbe ENCRYPTION_KEY und dasselbe DATA_DIR-Volume verwendet werden.

Die Entwicklung hat einen neuen Schlüssel erzeugt

Bewahre DATA_DIR/.encryption_key mit der Datenbank auf. Du kannst denselben Wert auch als ENCRYPTION_KEY setzen; beide Quellen müssen übereinstimmen.

Verwandte Dokumentation​