Welche Backup-Ebene sollte die Verschlüsselungsschlüssel verwalten: Client, Repository oder externes Ziel?

Eva Wong

IceWhale author

Eva Wong ist die Technische Redakteurin und und leidenschaftliche Tüftlerin bei ZimaSpace. Eine lebenslange Geek mit einer Leidenschaft für Homelabs und Open-Source-Software, sie spezialisiert sich darauf, komplexe technische Konzepte in zugängliche, praktische Anleitungenzu übersetzen. Eva ist der Meinung, dass Self-Hosting Spaß machen und nicht einschüchternd sein sollte. Durch ihre Tutorials befähigt sie die Community, Hardware-Setups zu entmystifizieren, vom Bau ihres ersten NAS bis hin zur Beherrschung von Docker-Containern.

Which Backup Layer Should Own Encryption Keys: Client, Repository, or Off-Site Target?

Bei den meisten Backups von Heimservern sollte die Backup-Anwendung oder der Client die für das Lesen des Backups erforderliche Verschlüsselung kontrollieren, während die Verschlüsselung des externen Speicheranbieters als zusätzliche Ebene betrachtet werden sollte. So wird verhindert, dass ein Angriff auf den Cloud- oder Remotespeicher automatisch die Backup-Inhalte offenlegt, während ein Backup-Format erhalten bleibt, das Daten weiterhin effizient deduplizieren, überprüfen und wiederherstellen kann.

Der wichtige Unterschied ist nicht einfach „clientseitige gegenüber serverseitiger Verschlüsselung“. Sie müssen entscheiden, welche Fehlerdomäne das Entschlüsselungsgeheimnis besitzt. Wenn der einzige Schlüssel auf dem Quellserver vorhanden ist, kann ein ausgefallener oder durch Ransomware verschlüsselter Quellserver die Wiederherstellbarkeit zunichtemachen. Wenn das externe Ziel den einzigen maßgeblichen Schlüssel besitzt, kann der Zielbetreiber oder ein kompromittiertes Zielkonto weiterhin innerhalb der Vertrauensgrenze liegen. Das beste Design trennt Backup-Daten, Repository-Zugangsdaten und Wiederherstellungsschlüssel.

Es gibt drei verschiedene Stellen, an denen Verschlüsselung stattfinden kann

Der Ausdruck „verschlüsseltes Backup“ kann mehrere Architekturen verbergen. Die Quelldateien können verschlüsselt werden, bevor das Backup-Tool sie sieht. Das Backup-Tool kann sein Repository-Format verschlüsseln, bevor es Objekte an lokalen oder entfernten Speicher sendet. Oder das Zielspeichersystem kann Daten empfangen und sie im Ruhezustand mithilfe seiner eigenen Schlüsselverwaltung verschlüsseln.

Ebene	Wer führt die Verschlüsselung durch?	Wer muss ein Wiederherstellungsgeheimnis aufbewahren?	Hauptstärke	Hauptschwäche
Clientseitige Vorverschlüsselung	Quellanwendung oder Verschlüsselungstool	Besitzer des Client-/Benutzerschlüssels	Starke Trennung vom Backup-Repository und Anbieter	Kann die backupbewusste Deduplizierung, die Sichtbarkeit von Metadaten und den Komfort granularer Wiederherstellungen einschränken
Verschlüsselung des Backup-Repositorys	Backup-Software vor der Speicherung	Inhaber des Repository-Schlüssels/der Passphrase	Das beste Gleichgewicht zwischen Vertraulichkeit und Backup-Funktionen	Ein verlorener Schlüssel oder eine vergessene Passphrase kann das gesamte Repository unlesbar machen
Verschlüsselung des externen Ziels	Cloud-/NAS-/Speicherdienst	Anbieter-, KMS- oder kundenseitig verwalteter Zielschlüssel	Einfacher Schutz für ruhende Daten	Das Ziel bleibt Teil der Vertrauensgrenze für die Entschlüsselung

Repositoryverschlüsselung ist in der Regel die beste Standardeinstellung

Moderne Backup-Tools sind darauf ausgelegt, Daten als Teil des Repository-Formats zu verschlüsseln. Die Verschlüsselungsdokumentation von restic behandelt Verschlüsselung als grundlegende Repository-Funktion und unterstützt mehrere Zugriffsschlüssel und Passwörter. Kopia beschreibt seine Repositorys ähnlich als Speicherorte, die auf Speicher-Backends wie Dateisystemen, S3 und Cloud-Objektspeichern Verschlüsselung und Deduplizierung hinzufügen.

Borg macht das Vertrauensmodell besonders deutlich. Seine Sicherheitsdokumentation geht davon aus, dass die Client-Umgebung vertrauenswürdig und das Repository potenziell feindselig ist. Borg verschlüsselt lokal, sodass ein entferntes Repository weder die Dateien im Klartext noch den unverschlüsselten Backup-Schlüssel erhält.

Dieses Muster ist für ein Heim-NAS attraktiv, da die Backup-Anwendung beim Erstellen des Backups weiterhin die Originaldateien sehen kann. Sie kann Chunking, Deduplizierung, Komprimierung, die Verarbeitung von Snapshot-Metadaten, Überprüfungen und selektive Wiederherstellungen vor oder zusammen mit der Verschlüsselung durchführen. Das Speicherziel erhält verschlüsselte Repository-Objekte statt gewöhnlicher lesbarer Dateien.

Verwechseln Sie den Repository-Schlüssel nicht mit den Speicherzugangsdaten

Ein Cloud-Bucket-Zugriffsschlüssel, ein privater SFTP-Schlüssel, ein Passwort für ein entferntes NAS und ein Backup-Entschlüsselungsschlüssel sind unterschiedliche Geheimnisse, selbst wenn ein Automatisierungsskript alle davon benötigt. Die Speicherzugangsdaten beantworten die Frage: „Darf dieser Client Repository-Objekte lesen oder schreiben?“ Der Repository-Schlüssel beantwortet: „Können diese Objekte in entschlüsselte Backup-Daten umgewandelt werden?“

Die Trennung dieser beiden Aspekte ist während eines Sicherheitsvorfalls wichtig. Ein Angreifer, der ein Bucket-Zugangstoken mit Schreibberechtigung stiehlt, sollte dadurch nicht automatisch das Entschlüsselungsgeheimnis des Repositorys erhalten. Umgekehrt sollte der Besitz der Backup-Passphrase nicht unbedingt administrativen Zugriff auf das externe Speicherkonto gewähren.

Der ZimaSpace-Leitfaden zum Überprüfen jedes für eine verschlüsselte Wiederherstellung erforderlichen Schlüssels ist eine nützliche Ergänzung, da er den Zugriff auf das Repository, die Backup-Verschlüsselung, den Zielspeicher, Container-Geheimnisse und Geheimnisse auf Anwendungsebene als separate Wiederherstellungsabhängigkeiten abbildet.

-15% OFF

ZimaBoard 2 – Mini-Heimserver für Ihre große Idee

Single board computer zimaboard2

Clientseitige Verschlüsselung ist für kleine Datenmengen mit hoher Sensibilität am besten

Dateien zu verschlüsseln, bevor die Sicherungsanwendung sie liest, kann sinnvoll sein, wenn ein bestimmter Datensatz selbst für die üblichen Sicherungstools oder Administratoren undurchsichtig bleiben muss. Beispiele hierfür sind ein kleines Rechtsarchiv, eine exportierte Passwortdatenbank, ein Paket privater Schlüssel oder ein vom Kunden kontrollierter verschlüsselter Container.

Der Nachteil besteht darin, dass eine zu früh durchgeführte Verschlüsselung Strukturen verbergen kann, die das Sicherungssystem ansonsten nutzen würde. Wenn jede geänderte Datei zu einer vollständig anderen verschlüsselten Ausgabe wird, können Komprimierung und Deduplizierung weniger effektiv werden. Auch das gezielte Durchsuchen einzelner Dateien kann zu einer Wiederherstellung in zwei Schritten werden: Zuerst wird das verschlüsselte Objekt wiederhergestellt, anschließend wird es mit einem anderen Tool entsperrt.

Aus diesem Grund ist die Vorabverschlüsselung des gesamten Datensatzes als standardmäßige Architektur für Heimsicherungen meist schwächer als der Einsatz eines Sicherungstools mit nativer, authentifizierter Repository-Verschlüsselung. Verwenden Sie sie, wenn Sie gezielt eine zweite Vertrauensgrenze um einen Teil der Daten benötigen.

Die serverseitige Verschlüsselung bei externem Speicher schützt den Speicher, nicht das gesamte Vertrauensmodell der Sicherung

Cloud-Objektspeicher verschlüsseln Daten üblicherweise im Ruhezustand. Amazon S3 verwendet beispielsweise standardmäßig eine serverseitige Verschlüsselung und unterstützt von AWS verwaltete oder vom Kunden verwaltete KMS-Schlüssel. Die SSE-KMS-Dokumentation beschreibt, wie S3 die Verschlüsselung am Ziel durchführt, während AWS KMS die Schlüssel und Berechtigungen kontrolliert.

Backblaze B2 unterstützt ebenfalls die vom Anbieter verwaltete SSE-B2- und die vom Kunden verwaltete SSE-C-Verschlüsselung. Die Dokumentation zur serverseitigen Verschlüsselung weist darauf hin, dass SSE die Dateidaten im Ruhezustand schützt und der Verlust eines vom Kunden verwalteten SSE-C-Schlüssels die Daten unwiederbringlich macht.

Die serverseitige Verschlüsselung ist wertvoll. Sie trägt zum Schutz physischer Medien und der Speicherinfrastruktur bei, und vom Kunden verwaltete KMS-Richtlinien können starke organisatorische Kontrollen schaffen. Wenn der Zieldienst Daten jedoch entschlüsseln kann, sobald eine autorisierte Speicheranforderung eingeht, befindet sich das Ziel weiterhin innerhalb der Vertraulichkeitsgrenze. Das unterscheidet sich vom Hochladen eines Borg-, restic- oder Kopia-Repositorys, das bereits vor dem Erreichen des Anbieters verschlüsselt wurde.

Offsite-Verschlüsselung als zusätzliche Schutzschicht verwenden

Die praktische Antwort lautet oft „beides“. Lass die Backup-Anwendung den Inhalt des Repositorys vor dem Upload verschlüsseln, und lass anschließend die normale Verschlüsselung des Ziels im Ruhezustand als weitere Schutzmaßnahme aktiviert. Die beiden Ebenen schützen vor unterschiedlichen Ereignissen.

Ausfall oder Bedrohung	Repository-Verschlüsselung	Serverseitige Verschlüsselung des Ziels
Offenlegung von Cloud-Festplatte bzw. -Medien	Schützt die Inhalte	Schützt die Inhalte
Der Speicheranbieter kann autorisierte Objekte lesen	Kann den Anbieter außerhalb der Vertrauensgrenze für Klartext halten	In der Regel nicht allein
Gestohlene Bucket-Anmeldedaten	Daten können ohne den Repository-Schlüssel unlesbar bleiben	Autorisierte Lesevorgänge können weiterhin eine Entschlüsselung auslösen
Verlust der Backup-Passphrase bzw. des -Schlüssels	Kann das Repository unwiederherstellbar machen	Stellt den Repository-Schlüssel nicht wieder her
Verlust des vom Anbieter verwalteten Speicherschlüssels	Die Repository-Ebene kann nicht verfügbare Zieldaten wiederherstellen	Die Wiederherstellungsrichtlinie des Anbieters/KMS gilt

Der Schlüssel muss die von ihm geschützte Maschine überleben

Die wichtigste Regel für die Schlüsselablage ist einfach: Bewahre die einzige Wiederherstellungskopie des Verschlüsselungsgeheimnisses nicht auf dem Server auf, der gesichert wird. Der aktuelle Leitfaden zur Repository-Initialisierung von Borg empfiehlt ausdrücklich, eine Sicherung des Borg-Schlüssels sowohl außerhalb des Repositorys als auch außerhalb des Systems aufzubewahren, das die Backups erstellt.

Dieselbe Logik gilt für restic-Passwörter, Kopia-Repository-Passwörter, age-Schlüssel, LUKS-Wiederherstellungsmaterial, die Verwaltung von Cloud-KMS und Master-Schlüssel von Anwendungen. Ein perfekt verschlüsseltes Repository ist nutzlos, wenn das einzige Entschlüsselungsgeheimnis mit dem ausgefallenen Boot-Laufwerk verloren geht.

Bewahre in einem Haushalt oder kleinen Labor mindestens eine Wiederherstellungskopie offline oder in einem separaten Anmeldedatensystem auf, das nicht davon abhängt, dass das NAS verfügbar ist. Teste anschließend eine Wiederherstellung auf einem sauberen System. Ein notiertes Passwort, das nie zum Öffnen des Repositorys verwendet wurde, belegt die Dokumentation, nicht die Wiederherstellbarkeit.

Welche Ebene sollte in gängigen Heimserver-Designs den Schlüssel verwalten?

Sicherung eines Heim-NAS in den Objektspeicher

Verwende die integrierte Repository-Verschlüsselung in restic, Borg, Kopia oder einem vergleichbaren Backup-Tool, bevor die Daten das NAS verlassen. Bewahre den Repository-Schlüssel bzw. die Passphrase außerhalb des NAS auf. Lass die Bucket-Verschlüsselung als zusätzliche Schutzschicht aktiviert. So bleibt das Cloud-Ziel nicht die einzige Vertraulichkeitskontrolle.

Sicherung eines Heim-NAS auf dem entfernten Server eines Freundes

Bevorzugen Sie eine client- bzw. repositoryseitige Verschlüsselung, deren Klartextschlüssel nicht auf dem Server des Freundes gespeichert ist. Der Remote-Host kann undurchsichtige Repository-Objekte speichern und eingeschränkte Schreibberechtigungen erzwingen. Das ist besonders wertvoll, weil die physische und administrative Kontrolle über den Remote-Rechner zu einer anderen Fehlerdomäne gehört.

Lokale Backup-Festplatte im selben Haus aufbewahrt

Die Verschlüsselung des Repositorys schützt die Vertraulichkeit weiterhin, wenn die Festplatte verloren geht oder gestohlen wird. Eine vollständige Festplattenverschlüsselung auf dem Backup-Laufwerk kann eine sinnvolle zweite Schutzschicht sein. Lassen Sie jedoch nicht zu, dass der Entsperrschlüssel des Laufwerks zum einzigen Zugriff auf das Backup-Repository wird.

Verwaltetes Cloud-Backup mit Wiederherstellungsfunktionen des Anbieters

Eine vom Anbieter verwaltete Verschlüsselung kann sinnvoll sein, wenn Einfachheit und eine vom Anbieter unterstützte Wiederherstellung wichtiger sind, als den Anbieter von der Vertrauensgrenze für Klartextdaten auszuschließen. Beachten Sie, dass dies eine andere Sicherheitsentscheidung ist als eine clientseitige Verschlüsselung nach dem Zero-Knowledge-Prinzip.

Legen Sie nicht alle Backup-Geheimnisse in einer Automatisierungsdatei ab

Ein unbeaufsichtigter Backup-Auftrag benötigt Zugangsdaten, doch Bequemlichkeit kann Ihre Sicherheitsgrenzen auflösen. Die Anleitung zur Automatisierung von Restic warnt davor, dass die Art der Passwortübergabe Zugangsdaten offenlegen kann, und empfiehlt, Passwortdateien sorgfältig zu schützen.

Für einen Heimserver sollten Sie, soweit praktikabel, mindestens diese Rollen trennen:

Eine eng begrenzte Zugangsdatenkombination, die den Backup-Zielspeicher erreichen kann.
Das Entschlüsselungspasswort bzw. der Entschlüsselungsschlüssel des Repositorys.
Eine offline gespeicherte Wiederherstellungskopie dieses Passworts bzw. Schlüssels.
Administratoren-Zugangsdaten, mit denen Aufbewahrungsrichtlinien, Buckets oder Remote-Konten gelöscht werden können.

Diese Trennung ist wichtiger als die Entscheidung, ob ein bestimmtes Geheimnis in einer Datei, einer Umgebungsvariablen, einem Passwortmanager, einem Hardware-Token oder einem KMS gespeichert wird. Die Architektur sollte verhindern, dass ein gestohlenes Automatisierungs-Tokengen gleichzeitig Klartext lesen, das Repository löschen und den einzigen Wiederherstellungsschlüssel zerstören kann.

Verschlüsselung ersetzt weder Unveränderlichkeit noch Wiederherstellungstests

Vertraulichkeit, Integrität, Löschresistenz und Wiederherstellbarkeit sind voneinander unabhängige Ziele. Ein verschlüsseltes Repository kann trotzdem gelöscht werden. Ein unveränderlicher Bucket kann weiterhin Backups enthalten, deren Entschlüsselungsschlüssel verloren gegangen ist. Ein erfolgreich abgeschlossener Backup-Auftrag kann bei der Wiederherstellung trotzdem fehlschlagen.

Der Vergleich von Remote-Sicherungsservern und Cloud-Objektspeicher für VM-Sicherungen von ZimaSpace kommt zum gleichen betrieblichen Ergebnis: Die Bezeichnung des Ziels ist weniger wichtig als die Frage, ob eine echte Wiederherstellung getestet wurde.

Entscheidungsmatrix

Priorität	Bevorzugte Schlüsselverwaltung
Cloud-/Remote-Administratoren von Klartextdaten fernhalten	Client oder verschlüsseltes Sicherungs-Repository
Deduplizierung und sicherungsbewusste Wiederherstellungen beibehalten	Native Repository-Verschlüsselung
Geringster betrieblicher Aufwand	Vom Anbieter verwaltete Zielverschlüsselung bei Akzeptanz einer umfassenderen Vertrauensstellung
Starke mehrschichtige Absicherung	Repository-Verschlüsselung + serverseitige Verschlüsselung des Ziels
Eine winzige, besonders sensible Teilmenge separat schützen	Clientseitige Vorverschlüsselung + normale Repository-Sicherung
Notfallwiederherstellung nach Verlust der Quelle	Jedes Modell mit einer unabhängigen, getesteten Wiederherstellungskopie des Schlüssels

Abschließendes Urteil

Bei den meisten selbst gehosteten Sicherungssystemen sollte der Sicherungsclient oder das Repository-Format die Grenze für die Inhaltsverschlüsselung festlegen, während das externe Ziel zusätzlich eine Verschlüsselung im Ruhezustand vornimmt. Dadurch bleiben Sicherungsfunktionen wie Deduplizierung und Verifizierung erhalten, während Sie dem entfernten Speichersystem weniger Vertrauen in Bezug auf Klartextdaten entgegenbringen müssen.

Der Schlüsselverwaltungsplan ist erst dann vollständig, wenn das Entschlüsselungsgeheimnis den Verlust des Quellservers, des Speicherziels und des normalen Administratorarbeitsplatzes übersteht. Testen Sie diese Annahme auf einem sauberen Rechner, bevor Sie die Sicherung als wiederherstellbar betrachten.

Häufig gestellte Fragen

Reicht die serverseitige Verschlüsselung eines Cloud-Dienstes für Heimsicherungen aus?

Sie schützt Daten im Ruhezustand, belässt den Speicherdienst jedoch normalerweise innerhalb der Entschlüsselungs-Vertrauensgrenze. Verwenden Sie zusätzlich eine native Sicherungsverschlüsselung, wenn Sie nicht möchten, dass der Anbieter oder ein gestohlenes Speicherkonto allein ausreicht, um auf Klartextdaten zuzugreifen.

Sollte der Repository-Schlüssel im Repository gespeichert werden?

Einige Sicherungsformate speichern ein verschlüsseltes Schlüsselobjekt im Repository. Die Wiederherstellung hängt jedoch weiterhin von einem weiteren Geheimnis ab, beispielsweise einer starken Passphrase. Bewahren Sie unabhängiges Wiederherstellungsmaterial außerhalb des Repositorys und des Quellsystems auf.

Erhöht die Verschlüsselung von Dateien vor der Sicherung die Sicherheit?

Dies kann eine zusätzliche Vertrauensgrenze für sensible Teilmengen schaffen. Wenn jedoch alles verschlüsselt wird, bevor das Sicherungstool darauf zugreift, können Deduplizierung, Komprimierung, Metadatensichtbarkeit und der Komfort bei der Wiederherstellung beeinträchtigt werden.

Was ist der wichtigste Test für die Schlüsselverwaltung?

Stellen Sie die Sicherung auf einem sauberen Rechner wieder her, nachdem Sie so getan haben, als sei das ursprüngliche NAS vollständig nicht verfügbar. Wenn Sie nicht jede Anmeldeinformation finden und repräsentative Daten entschlüsseln können, ist der Schlüsselplan unvollständig.