Datenschutz · Wer sieht die Akten?
Stand: 2026-11-05 · Zur Übersicht
Verschlüsselung schützt den ruhenden Dateibestand und das Borg-Archiv. Im laufenden Betrieb verarbeitet Samba Klartext. Im normalen Samba-Betrieb gibt es außerhalb des Containers keinen dauerhaften Klartext-Mount. Nur der getrennte Backup-Lauf öffnet vorübergehend eine schreibgeschützte Klartextansicht auf dem Host. Die folgende Tabelle trennt Speicherort, Zeitpunkt und Zugriff. Sie beschreibt den verifizierten OMNISRV-Stand, keine absolute Sicherheitsgarantie.
| Ebene | Form und Zeitpunkt | Zugriff und Kontrolle | Ende des Klartextzugriffs |
|---|---|---|---|
| Ruhender Btrfs-Datenträger | gocryptfs-Cipherdir: Dateiinhalte und Namen verschlüsselt; Struktur, Größen, Zeiten und andere Metadaten können sichtbar oder ableitbar sein. | Zugriff auf Cipherdir und Schlüssel wird durch Hostrechte und geschützte Secret-Ablage begrenzt. Privilegierte Hostprozesse bleiben eine Grenze. | Dort liegt kein regulärer Klartext. |
| Laufender Samba-Betrieb | Samba sieht die Dateien über einen gocryptfs-Mount innerhalb seines Containers entschlüsselt. Auf dem Host bleibt der dauerhafte Btrfs-Bestand verschlüsselt; ein dauerhafter Host-Klartext-Mount ist nicht aktiv. | Samba verarbeitet Inhalte. Anmeldung, Freigaberechte, POSIX-Gruppen und ACLs begrenzen normale Benutzer. Host-root mit Schlüssel- und Docker-Zugriff bleibt eine Sicherheitsgrenze. | Beim Containerstopp endet dessen interne Mount-Ansicht. Ein kontrollierter Stopp und Neustart sowie ein gezielter Samba-Prozessabbruch wurden am 5. November geprüft; ein kompletter Hostreboot bleibt offen. |
| Stündliche Sicherung | Btrfs-Snapshot des Cipherdir ist schreibgeschützt. Ein zweiter gocryptfs-Mount zeigt ihn dem Backup-Prozess vorübergehend im Klartext. | Backup-Prozess mit nötigen Rechten liest Inhalte und Metadaten. Der temporäre Mount ist auf diesen Prozess begrenzt; Fehlerpfade sollen ihn ebenfalls entfernen. | Nach Backup-Lauf: Mount aushängen, Snapshot entfernen. Automatische Folgeläufe zeigten keinen Restmount. |
| Übertragung und Repository | Borg verschlüsselt die Archivnutzdaten clientseitig; deduplizierte Daten liegen im entfernten Repository verschlüsselt. Der aktuelle Transportweg ist SSH. | Borg-Schlüssel und Repository-Zugang sind getrennt zu schützen. SSH schützt zusätzlich den Transportkanal; Borgs Archivverschlüsselung hängt nicht von diesem Zusatzschutz ab. | Klartext existiert nur am Backup-Client während des Lesens, nicht als reguläre Repository-Datei. |
| Wiederherstellung | Autorisierter Restore entschlüsselt benötigte Archivdaten in einem gesonderten Ziel. | Zielordner und Prozessrechte begrenzen den Zugriff. Nach dem Restore gelten Eigentümer, Modus und ACLs zu prüfen. | Temporäres Restore-Ziel nach Prüfung kontrolliert entfernen; dauerhafte Wiederherstellung bleibt bewusst verfügbar. |
Schutzgrenzen
Dateiverschlüsselung ersetzt weder Samba-Rechte noch Hostschutz. Der temporäre Backup-Mount, Host-root mit Schlüssel- und Docker-Zugriff, Schlüsselverlust, sichtbare Metadaten und ungeschützte Restore-Ziele bleiben reale Risiken. Die Schlüssel selbst gehören nicht in Wiki, Git oder Protokolle.
Die Container-Mounts, das Fehlen des dauerhaften Host-Mounts, ein kontrollierter Dienststopp und -start sowie ein gezielter Samba-Prozessabbruch wurden beim produktiven Umbau am 5. November 2026 geprüft. Ein vollständiger OMNISRV-Neustart ist noch nicht empirisch abgenommen.
Quellen: OMNISRV-SAMBA-CONTAINER-FUSE-001-Abschlussbericht vom 5. November 2026; Betriebs- und Recovery-Nachweise; gocryptfs 2.5.1; Borg 1.4, Verschlüsselungsmodi.