Relution Signet Customer Hub

Serverseitige Verschlüsselung (SSE-C)

Relution kann die Objekte, die es in einem S3-kompatiblen Bucket speichert, mit Server-Side Encryption und einem kundenseitig bereitgestellten Schlüssel (SSE-C) verschlüsseln. Bei SSE-C sendet Relution den Schlüssel mit jeder Anfrage mit, und das Speicher-Backend verwendet ihn, um Objekte beim Schreiben zu verschlüsseln und beim Lesen zu entschlüsseln. Das Backend speichert den Schlüssel niemals selbst - die sichere Aufbewahrung liegt ausschließlich in der eigenen Verantwortung.

Vor dem Aktivieren lesen: SSE-C wird beim Start sofort wirksam, und Relution verschlüsselt bereits im Bucket vorhandene Objekte nicht. Nur auf einer frischen Instanz mit leerem Bucket aktivieren, oder zuvor alle bestehenden Objekte verschlüsseln. Geht der Schlüssel verloren, sind alle verschlüsselten Daten unwiederbringlich verloren. Details dazu unter Wichtige Hinweise weiter unten.
SSE-C vs. KMS-Verschlüsselung: SSE-C ist nicht dasselbe wie clientseitige Verschlüsselung über AWS KMS. Bei KMS wird ein vom Kunden verwalteter Schlüssel (CMK) von AWS KMS gehalten und verwaltet. Bei SSE-C wird der Schlüssel von Relution bei jeder Anfrage an S3 weitergeleitet und muss eigenständig gespeichert werden. Diese beiden Mechanismen schließen sich gegenseitig aus - aktivierbar ist SSE-C oder KMS oder keines von beiden, aber niemals beide gleichzeitig.

Voraussetzungen

  • Eine funktionierende S3-kompatible Objektspeicher-Einrichtung - siehe Objektspeicher verbinden →.
  • Ein Objektspeicher-Backend, das SSE-C unterstützt. Die Unterstützung wurde mit SeaweedFS und Hetzner Object Storage getestet. Andere S3-kompatible Backends können funktionieren, wurden aber nicht getestet.
  • Ein 256-Bit-Schlüssel (siehe unten).

Schlüssel generieren

SSE-C benötigt einen 256-Bit-Schlüssel (32 Byte), der als Base64-codierte Zeichenkette bereitgestellt wird. Ein Schlüssel lässt sich mit openssl generieren:

openssl rand -base64 32

Den resultierenden Wert sicher aufbewahren. Geht dieser Schlüssel verloren, können alle verschlüsselten Objekte im S3-Bucket nicht mehr entschlüsselt werden und sind unwiederbringlich verloren.

Konfiguration

SSE-C wird aktiviert, sobald ein Schlüssel konfiguriert ist. Der Schlüssel kann entweder direkt über die Konfiguration relution.storage.s3.serverSideEncryption.key angegeben (Option A und B) oder als Datei über relution.storage.s3.serverSideEncryption.keyFile bereitgestellt werden (Option C). Sind beide gesetzt, hat die Schlüsseldatei Vorrang.

Option A: Verwendung von application.yml

Den serverSideEncryption-Block zur application.yml hinzufügen:

relution:
  storage:
    resourceStorageType: S3
    s3:
      customEndpoint: http://seaweedfs:8333
      accessKey: %IHR-ACCESS-KEY%
      secretKey: %IHR-SECRET-KEY%
      bucketName: relution
      serverSideEncryption:
        key: %IHR-BASE64-SCHLÜSSEL%

Option B: Verwendung von Umgebungsvariablen

Die folgende Umgebungsvariable zum relution Service in der compose.yaml hinzufügen:

services:
  relution:
    environment:
      - RELUTION_STORAGE_S3_SERVERSIDEENCRYPTION_KEY=%IHR-BASE64-SCHLÜSSEL%

Option C: Schlüssel als Datei

Alternativ zur direkten Angabe kann der Schlüssel aus einer Datei gelesen werden. Das ist vor allem dann sinnvoll, wenn der Schlüssel als Docker- oder Kubernetes-Secret in den Container eingehängt wird. Der Pfad zur Schlüsseldatei wird über relution.storage.s3.serverSideEncryption.keyFile konfiguriert:

relution:
  storage:
    s3:
      serverSideEncryption:
        keyFile: /pfad/zu/ssec.key

Oder über die entsprechende Umgebungsvariable:

services:
  relution:
    environment:
      - RELUTION_STORAGE_S3_SERVERSIDEENCRYPTION_KEYFILE=/pfad/zu/ssec.key

Die Datei muss denselben Base64-codierten 256-Bit-Schlüssel enthalten wie bei der direkten Angabe (z. B. erzeugt mit openssl rand -base64 32). Ein abschließender Zeilenumbruch ist unkritisch, da der Wert automatisch bereinigt wird; binär oder hexadezimal codierte Schlüssel werden abgelehnt.

Beim Start protokolliert Relution das Einlesen mit Reading SSE-C key from file <Pfad>. Fehlt die Datei oder enthält sie keinen 32-Byte-Schlüssel, bricht der Start mit einer entsprechenden Fehlermeldung ab.

Aktivierung prüfen

Beim Start protokolliert Relution die aktive Verschlüsselung, bei SSE-C mit S3 storage encryption: SSE-C (server-side). Auch ein direkt angegebener Schlüssel (Option A und B) wird beim Start geprüft: Ist der Wert kein gültiges Base64 oder ergibt er keinen 32-Byte-Schlüssel, bricht der Start ab, bei falscher Länge mit SSE-C key must be 32 bytes (AES-256).

Wichtige Hinweise

Keine Migration bestehender Dateien: SSE-C wird sofort wirksam, sobald Relution mit konfiguriertem Schlüssel startet. Relution verschlüsselt keine Objekte, die bereits im Bucket vorhanden sind. SSE-C nur auf einer frischen Instanz mit leerem Bucket verwenden, oder alle bestehenden S3-Objekte verschlüsseln, bevor Relution mit dem Schlüssel gestartet wird. Andernfalls bleiben zuvor gespeicherte Objekte unverschlüsselt und können unzugänglich werden.
Schlüsselverlust bedeutet Datenverlust: Das Speicher-Backend speichert den Schlüssel nicht - die sichere Aufbewahrung liegt ausschließlich in der eigenen Verantwortung. Geht der Schlüssel verloren, werden alle verschlüsselten Objekte im Bucket unwiederbringlich verloren, und Relution kann keine Apps oder Ressourcen mehr aus dem Objektspeicher ausliefern. Den Schlüssel an einem sicheren Ort aufbewahren.
Schlüsselrotation erfordert Neuverschlüsselung: Die Rotation des Schlüssels liegt in der eigenen Verantwortung. Relution verschlüsselt Objekte bei einem Schlüsselwechsel nicht neu. Zum Rotieren des Schlüssels müssen alle bestehenden Objekte im Bucket mit dem neuen Schlüssel neu verschlüsselt werden (z.B. durch Kopieren mit dem neuen Schlüssel), bevor Relution mit der aktualisierten Konfiguration gestartet wird. Wird Relution mit einem neuen Schlüssel gestartet, während Objekte noch mit dem alten verschlüsselt sind, werden diese Objekte unzugänglich.
Gegenseitiger Ausschluss mit KMS: Serverseitige (SSE-C) und clientseitige (KMS) Verschlüsselung können nicht gleichzeitig aktiv sein. Sind beide konfiguriert, bricht der Start mit Conflicting encryption configuration: client and server side encryption active ab.

Wie hilfreich war dieser Artikel?