Fix #42: Serverseitige Verschlüsselung optional machen #49

2026-09-01T14:08:54Z

florian.wilde commented

2026-09-01 14:08:54 +00:00

Closes #42

Was war

Der S3-Treiber setzte fest ServerSideEncryption: 'AES256'. Das mitgelieferte MinIO läuft ohne KMS und lehnt das mit NotImplemented ab — es ließ sich kein einziges Dokument ablegen.

Was jetzt gilt

S3_SSE steuert es. Leer bedeutet aus, auch eine Zeile mit Leerzeichen.

Gebraucht wird der Kopf ohnehin nicht mehr: Seit v1.11.0 verschlüsselt die Anwendung jede Datei selbst, bevor sie den Server verlässt. Eine zweite Lage durch den Anbieter schützt vor nichts, was der eigene Umschlag nicht schon abdeckt.

Warum es niemand gemerkt hat

In der Entwicklung läuft der Dateitreiber. Der S3-Pfad wurde von keinem Test ausgeführt — auch nicht von den 95 E2E-Tests. Die neuen Tests fangen den Befehl deshalb ab, bevor er das Netz sieht, und schauen hinein. Was an den Objektspeicher geht, ist jetzt belegt statt angenommen.

Nebenbei prüfen sie mit, dass der Inhalt verschlüsselt hinausgeht (BCD1-Kopf, Klartext nicht auffindbar) und als application/octet-stream ausgezeichnet wird.

Geprüft

731 Unit-Tests, tsc und Lint sauber. Gegen drei Mutationen: SSE wieder fest verdrahtet · leere Angabe nicht abgefangen · Inhalt unverschlüsselt — jede wird rot.

Für das Livesystem

Nach dem Ausrollen kann die Notlösung weg:

MINIO_KMS_SECRET_KEY aus der docker-compose.override.yml und der .env entfernen
docker compose up -d
Ein Dokument ablegen — muss funktionieren

Damit verschwindet ein Schlüssel, dessen Verlust die Objekte unlesbar gemacht hätte. Vorher aber prüfen, ob bereits mit SSE abgelegte Objekte noch lesbar sind: MinIO braucht den Schlüssel, um sie herauszugeben. Am einfachsten ist es, die vorhandenen Dokumente vorher einmal herunterzuladen — bei einem Dokument ist das ein Klick.

Closes #42 ## Was war Der S3-Treiber setzte fest `ServerSideEncryption: 'AES256'`. Das mitgelieferte MinIO läuft ohne KMS und lehnt das mit `NotImplemented` ab — es ließ sich **kein einziges Dokument ablegen**. ## Was jetzt gilt `S3_SSE` steuert es. Leer bedeutet aus, auch eine Zeile mit Leerzeichen. Gebraucht wird der Kopf ohnehin nicht mehr: Seit v1.11.0 verschlüsselt die Anwendung jede Datei selbst, bevor sie den Server verlässt. Eine zweite Lage durch den Anbieter schützt vor nichts, was der eigene Umschlag nicht schon abdeckt. ## Warum es niemand gemerkt hat In der Entwicklung läuft der Dateitreiber. Der S3-Pfad wurde von keinem Test ausgeführt — auch nicht von den 95 E2E-Tests. Die neuen Tests fangen den Befehl deshalb ab, **bevor er das Netz sieht**, und schauen hinein. Was an den Objektspeicher geht, ist jetzt belegt statt angenommen. Nebenbei prüfen sie mit, dass der Inhalt verschlüsselt hinausgeht (`BCD1`-Kopf, Klartext nicht auffindbar) und als `application/octet-stream` ausgezeichnet wird. ## Geprüft **731 Unit-Tests**, `tsc` und Lint sauber. Gegen drei Mutationen: SSE wieder fest verdrahtet · leere Angabe nicht abgefangen · Inhalt unverschlüsselt — jede wird rot. ## Für das Livesystem Nach dem Ausrollen kann die Notlösung weg: 1. `MINIO_KMS_SECRET_KEY` aus der `docker-compose.override.yml` und der `.env` entfernen 2. `docker compose up -d` 3. Ein Dokument ablegen — muss funktionieren Damit verschwindet ein Schlüssel, dessen Verlust die Objekte unlesbar gemacht hätte. **Vorher** aber prüfen, ob bereits mit SSE abgelegte Objekte noch lesbar sind: MinIO braucht den Schlüssel, um sie herauszugeben. Am einfachsten ist es, die vorhandenen Dokumente vorher einmal herunterzuladen — bei einem Dokument ist das ein Klick.

florian.wilde added 1 commit 2026-09-01 14:08:54 +00:00

Serverseitige Verschluesselung optional machen c0cb29bf53

Der S3-Treiber setzte bei jedem PutObject fest
ServerSideEncryption: 'AES256'. Das mitgelieferte MinIO laeuft ohne KMS
und lehnt das mit "NotImplemented" ab - es liess sich kein einziges
Dokument ablegen. Wer der INSTALLATION.md folgte, landete zwangslaeufig
dort; es war kein Konfigurationsfehler des Betreibers, sondern der
Auslieferungszustand.

Gebraucht wird die Zeile ohnehin nicht mehr. Seit v1.11.0 verschluesselt
die Anwendung jede Datei selbst, bevor sie den Server verlaesst. Eine
zweite Lage durch den Anbieter schuetzt vor nichts, was der eigene
Umschlag nicht schon abdeckt.

Jetzt steuert S3_SSE, ob der Kopf mitgeht. Leer bedeutet aus - auch eine
Zeile mit Leerzeichen, sonst schickte eine leergelassene .env-Zeile einen
leeren Kopf und der Anbieter antwortete mit einem Fehler, den niemand
versteht.

Im Kommentar von v1.11.0 stand, die serverseitige Verschluesselung
"kostet nichts". Das war falsch: Auf MinIO ohne KMS kostete sie die
gesamte Funktion. Der Satz ist korrigiert.

Aufgefallen ist das erst im Betrieb, und der Grund ist derselbe wie beim
Ausloeser: In der Entwicklung laeuft der Dateitreiber, der S3-Pfad wurde
von keinem Test ausgefuehrt. Deshalb pruefen die neuen Tests den Befehl
ab, bevor er das Netz sieht - was hineingeschrieben wird, ist jetzt
belegt, nicht angenommen.

Gegen drei Mutationen geprueft: SSE wieder fest verdrahtet, leere Angabe
nicht abgefangen, Inhalt unverschluesselt - jede wird rot.

Refs #42

florian.wilde merged commit 88e9202c2f into main

2026-09-01 14:09:01 +00:00

florian.wilde deleted branch fix/42-sse-optional

2026-09-01 14:09:02 +00:00

florian.wilde referenced this pull request

2026-09-01 14:09:21 +00:00

Der mitgelieferte Objektspeicher kann keine Dokumente aufnehmen #42

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: florian.wilde/betreuungs-cockpit#49