Der Notfallkoffer — warum ein Wiederherstellungsplan im Backup keiner ist

Zwei Sicherungen liefen, beide vollständig, beide überwacht. Aus Teil 1 war die Erkenntnis geblieben, dass ausgerechnet die Zugangsschlüssel gefehlt hatten — also wurden sie aufgenommen. Damit lagen nun im Backup: die Konfiguration für den Zugang zum Cloud-Speicher und die Passwortdatei des Repositories selbst.

Also der Zugang zum Lagerort und das Passwort des Tresors — beide im Tresor.

Solange der Rechner lebt, ist das vollkommen egal. Nach einem Totalverlust ist es ein geschlossener Kreis: Man bräuchte das Backup, um an die Mittel zu kommen, mit denen man das Backup öffnet.

Der Kreis hat einen Namen

Das ist kein exotischer Sonderfall, sondern ein benannter Standardfehler. Der BSI-Grundschutz führt ihn im Baustein zum Datensicherungskonzept als eigene Gefährdung und beschreibt ihn fast wörtlich so, wie er hier auftrat:

„Wird diese beispielsweise verschlüsselt, und ist bei einem Datenverlust auch der Schlüssel zum Entschlüsseln der Datensicherung betroffen, können die Daten nicht wiederhergestellt werden. Das könnte dann der Fall sein, wenn nicht daran gedacht wurde, den Schlüssel getrennt aufzubewahren."

Dieselbe Quelle behandelt den zweiten Teil des Problems getrennt — die Anleitung selbst: Liegt die Information zur Wiederherstellung nur digital vor, geht sie bei einem Großschaden mit unter, und die Wiederherstellung ist gefährdet.

Auch die internationale Seite ist eindeutig. Die NIST-Empfehlung zum Schlüsselmanagement verlangt, dass archiviertes Schlüsselmaterial getrennt von den operativen Daten gespeichert wird — mit einem verbindlichen „shall", nicht als Empfehlung — und dass mehrere Kopien an physisch getrennten Orten vorgehalten werden. Die Leitlinie zur Notfallplanung fordert entsprechend, dass eine Kopie des Wiederherstellungsplans am Ausweichstandort und bei den Sicherungsmedien liegt, damit sie verfügbar ist, wenn die örtlichen Kopien es nicht mehr sind.

Der Anspruch ist damit klar formuliert. Die Frage ist nur, wo der Einstieg praktisch liegen soll.

Der Einstieg muss außerhalb liegen

Die Lösung, die wir gewählt haben, ist unspektakulär und genau deshalb belastbar. Der gesamte Zugang hängt an einer einzigen verschlüsselten Passwortdatenbank. Diese Datei selbst darf ruhig überall liegen — sie ist verschlüsselt, sie liegt in jedem Backup, es gibt zusätzliche Sicherungsstände daneben.

Entscheidend ist das Master-Passwort dieser Datenbank. Und das liegt nicht im Backup, sondern in einer Datei mit strengen Rechten auf zwei voneinander unabhängigen Servern, die bei verschiedenen Anbietern stehen. Wer im Ernstfall an einen der beiden herankommt, kommt an alles Weitere.

Damit ist der Kreis aufgebrochen. Die Kette lautet jetzt:

1. Master-Passwort von einem der beiden Server holen
2. Passwortdatenbank öffnen
3. Repo-Passwort entnehmen
4. vom schnellsten verfügbaren Ziel wiederherstellen

Kein Schritt dieser Kette setzt ein funktionierendes Backup voraus. Das ist die einzige Eigenschaft, auf die es ankommt.

Eine Schwachstelle bleibt und gehört benannt: Ohne Zugriff auf einen der beiden Server und ohne die Datenbank ist keine Wiederherstellung möglich. Das ist der Kern der Kette, und er ist bewusst so gebaut — zwei Wege sind besser als einer, aber es sind eben nur zwei.

Ein Koffer, der kein Geheimnis enthält

Aus dieser Überlegung entstand das, was wir Notfallkoffer nennen — ein Verzeichnis mit sechs Bereichen:

Bereich	Inhalt
Einstieg	Wie komme ich an die Passwortdatenbank?
Anleitung	Wiederherstellung Schritt für Schritt
Inventar	Welche Schlüssel es gibt — ohne deren Werte
Schlüssel	verschlüsselte Archive
Datenbanken	die Passwortdatenbanken, verschlüsselt
Skripte	Sicherung und Wiederherstellung

Die entscheidende Entwurfsregel: Der Koffer enthält kein einziges Geheimnis im Klartext. Nur verschlüsselte Behälter, Anleitungen und Inventare, die beschreiben, welche Schlüssel existieren und wofür — nie ihren Wert.

Das klingt nach einer Selbstverständlichkeit, ist aber der Punkt, an dem sich Nützlichkeit entscheidet. Ein Koffer mit Klartext-Geheimnissen muss geschützt gelagert werden, und geschützte Lagerung bedeutet in der Praxis: schwer erreichbar. Ein Koffer ohne Klartext darf auf einen USB-Stick, in eine Schublade, zu einer Vertrauensperson. Er darf in jedem Backup liegen. Genau diese Freizügigkeit macht ihn im Ernstfall verfügbar — und Verfügbarkeit ist die Eigenschaft, an der Notfallpläne scheitern.

Die Anleitung liegt zusätzlich als Eintrag in der Passwortdatenbank selbst. Denn eine Wiederherstellungsanleitung, die nur in dem Backup liegt, das man wiederherstellen will, ist keine.

Die Werkzeugfrage: Was öffne ich in zwei Jahren?

Für die verschlüsselten Archive stand die Wahl zwischen einem modernen, schlanken Verschlüsselungswerkzeug und dem alten 7z. Technisch ist die Sache eindeutig — das moderne Werkzeug ist sauberer entworfen und lässt weniger Fehlbedienung zu.

Die Prüfung ergab trotzdem etwas anderes, weil die richtige Frage nicht lautet „was ist eleganter", sondern: Womit öffne ich das in zwei Jahren auf einem fremden Rechner?

Werkzeug	Rechner A	Rechner B
modernes Werkzeug	vorhanden	fehlt
7z	vorhanden	vorhanden

Das modernere Werkzeug fehlte bereits auf einem der beiden eigenen Rechner. 7z liegt auf beiden, ist auf jedem Linux in Sekunden nachinstalliert und lässt sich auch unter Windows öffnen. Für ein Notfallarchiv schlägt Verbreitung die Eleganz.

Dateinamen sind Daten

Dazu kommt ein Vorteil, der oft übersehen wird. Ein verschlüsseltes Archiv schützt standardmäßig nur die Dateiinhalte — nicht die Namen. Ohne Passwort lässt sich das komplette Inhaltsverzeichnis auflisten, samt Größen und Zeitstempeln.

Bei 7z gibt es dafür eine eigene Option, die auch die Namensliste verschlüsselt. Sie ist standardmäßig aus. Der Unterschied in der Praxis:

Archiv	Inhaltsverzeichnis ohne Passwort
7z, nur Inhalte verschlüsselt	vollständig lesbar, mit Größen und Zeitstempeln
7z mit Header-Verschlüsselung	verweigert das Auflisten vollständig
ZIP, auch mit starker Verschlüsselung	vollständig lesbar

Beim ZIP-Format ist das kein Versehen, sondern dokumentierte Eigenschaft. Die Formatspezifikation nennt das Problem selbst beim Namen — information leakage — und beschreibt präzise, was offenliegt: Name, ursprüngliche Größe, Zeitstempel und Prüfsumme jeder Datei, obwohl deren Inhalt verschlüsselt ist. Es gibt eine optionale Erweiterung, die auch das Verzeichnis verschlüsselt; sie ist ausdrücklich nicht der Normalfall und in gängigen Werkzeugen nicht umgesetzt.

Für ein Schlüsselarchiv ist das entscheidend. Ein lesbares Inhaltsverzeichnis verrät, welche Dienste man nutzt, wie die Ablage strukturiert ist und wo eine Notfallkarte liegt — Informationen, die einen Angreifer zielgenau machen, auch ohne dass er eine einzige Datei entschlüsselt.

Eine Feinheit zur Sorgfalt: Sucht man in einem 7z-Archiv ohne diese Option nach Klartext-Namen in den Rohdaten, findet man nichts. Das ist kein Schutz, sondern nur die Kompression des Verzeichnisses. Aufgelistet wird trotzdem alles.

Der Test, der bestand, weil er nicht lief

Ein Wiederherstellungsskript, das nie erprobt wurde, ist wertlos. Also baute ich einen Test mit Wegwerfdaten: packen, Inhaltsverzeichnis ohne Passwort prüfen, mit falschem Passwort prüfen, entpacken, Inhalt vergleichen.

Der Test lief durch. Schritt 2 und 3 meldeten „bestanden". Schritt 4 schlug fehl, und weil derselbe Befehl im echten Wiederherstellungsskript stand, sah ich mir den Fehler genauer an.

Die Ursache war banal: Ich hatte die Aufrufe mit einem Zeitbegrenzungs-Befehl umschlossen, damit sie nicht hängen bleiben. Diesen Befehl gibt es auf macOS nicht.

Damit war nicht nur Schritt 4 kaputt. Auch das „bestanden" von Schritt 2 und 3 war wertlos — es kam zustande, weil der Befehl gar nicht ausgeführt wurde und die nachgelagerte Textsuche deshalb nichts fand. Ein Nicht-Ausführen sieht in der Auswertung genauso aus wie ein erfolgreiches Ausführen ohne Treffer.

Das war die zweite Scheinbestätigung dieses Tages — die erste, ein Vergleich zweier versehentlich leerer Listen, steht in Teil 3. Beide Male sah das Ergebnis plausibel aus. Beide Male hätte es eine Entscheidung getragen.

Der saubere Durchlauf ergab dann echte Ergebnisse — unter anderem den Befund, dass bei aktiver Header-Verschlüsselung schon das bloße Auflisten ein Passwort verlangt und ohne Angabe interaktiv nachfragt. Ein Detail, das ein Skript zum Hängen bringt, wenn man es nicht kennt.

Warum die Rechte über den Erfolg entscheiden

Der Teil, den man beim Sichern von Schlüsseln am leichtesten übersieht, sind die Dateirechte. Ein zurückgespielter privater SSH-Schlüssel, der für andere lesbar ist, wird von OpenSSH schlicht ignoriert — die Handbuchseite sagt das ausdrücklich, und im Quellcode steht die Prüfung, die alle Gruppen- und Andere-Bits auf null verlangt. Zulässig sind damit die Rechte 0600 oder 0400; alles ab 0640 fällt durch. Die Wiederherstellung wäre technisch erfolgreich und praktisch nutzlos.

Für das 7z-Archiv haben wir das gelöst, indem das Sicherungsskript ein Manifest mit den Original-Rechten mit ins Archiv legt, das beim Zurückspielen wieder angewandt wird. Das ist kein Beiwerk — 7z überträgt die Unix-Rechte unter macOS nicht zuverlässig, das Manifest ist also der Grund, warum die Wiederherstellung überhaupt funktioniert.

Bei Restic liegt der Fall anders, und das ist eine Präzisierung, die ich der Recherche für diesen Artikel verdanke. Restic sichert Rechte, Eigentümer und erweiterte Attribute und setzt den Zugriffsmodus beim Zurückspielen korrekt. Was scheitert, ist die Eigentümerschaft: Läuft die Wiederherstellung nicht als Systemverwalter, schlägt das Setzen fremder Besitzverhältnisse fehl — und dieser Fehler wird im Quellcode ausdrücklich verschluckt, weil er bei gewöhnlichen Verzeichnissen normal ist. Die Dateien gehören danach dem wiederherstellenden Nutzer. Und OpenSSH prüft zuerst, ob der Aufrufer auch Eigentümer ist, bevor es überhaupt die Rechte ansieht.

Praktisch heißt das: Schlüssel als Systemverwalter zurückspielen und danach Eigentümer und Rechte gegen die Erwartung prüfen. Eine Erfolgsmeldung des Werkzeugs beweist hier nichts, weil der relevante Fehler unterdrückt wurde.

Passwörter gehören nicht in Prozessargumente

Das Sicherungsskript war fertig, als eine automatische Sicherheitsprüfung anschlug: Das Archivpasswort wurde als Kommandozeilen-Argument übergeben.

Der Befund war berechtigt, und die Begründung ist grundsätzlicher, als man denkt. Argumentlisten laufender Prozesse sind auf Unix-Systemen für jeden Nutzer einsehbar. Das Standardwerkzeug zur Prozessanzeige braucht dafür keinerlei Sonderrechte — die Handbuchseite hält ausdrücklich fest, dass es ohne jede Privilegien auskommt. Bei einem großen Archiv steht das Passwort damit über Minuten oder Stunden offen. Zusätzlich landet der Aufruf in der Historie der Kommandozeile, sofern man ihn von Hand eingegeben hat.

Eine verbreitete Begründung dazu muss ich allerdings korrigieren, weil ich sie selbst geglaubt habe: Die Behauptung, Umgebungsvariablen seien aus demselben Grund unsicher, weil sie ebenfalls über das Kernel-Dateisystem lesbar wären, trifft nicht zu. Die Argumentliste ist für alle lesbar, die Umgebung ist es nicht — sie unterliegt einer Zugriffsprüfung, die dieselben Rechte verlangt wie das Anhängen eines Debuggers. Umgebungsvariablen sind gegenüber Argumenten also ein echter Fortschritt. Zweite Wahl bleiben sie trotzdem, aber aus anderen Gründen: Sie werden an alle Kindprozesse vererbt, landen in Speicherabzügen nach Abstürzen und tauchen in Fehlerprotokollen auf.

Die sauberen Wege sind Standardeingabe, ein Filedeskriptor oder eine Datei mit strengen Rechten. Andere Werkzeuge machen es vor: Ein verbreitetes Verschlüsselungsprogramm warnt in der eigenen Dokumentation vor seiner Passwort-Option („of very questionable security on a multi-user system"), Restic bietet sowohl eine Passwortdatei als auch einen Befehl, der es zur Laufzeit aus einem Passwortspeicher holt, und ein modernes Werkzeug verzichtet bewusst ganz auf eine Kommandozeilenoption für die Passphrase.

Bei 7z gibt es diesen Weg nicht. Die vollständige Schalterliste kennt genau eine Möglichkeit, ein Passwort zu übergeben — als Argument oder interaktiv. Kein Äquivalent zu einer Passwortdatei, kein Filedeskriptor. In der Praxis zeigte sich: Beim Erstellen nimmt 7z das Passwort über die Standardeingabe entgegen. Beim Entpacken nicht — dort verlangt es ein Terminal.

Was zunächst wie ein Hindernis aussah, ist sicherheitstechnisch die bessere Lösung. Für das Sichern läuft das Passwort jetzt über die Standardeingabe. Für das Wiederherstellen fragt 7z selbst — das Geheimnis läuft überhaupt nicht mehr durch das Skript, existiert in keiner Variablen und kann folglich auch nirgends auslaufen.

Die Reihenfolge beim Packen

Ein letzter Entwurfsgriff, klein und wirksam: Das Skript erzeugt ein zufälliges Archivpasswort, legt es zuerst im Passwortspeicher ab und packt erst danach.

Andersherum — packen und danach eintragen — gäbe es ein Zeitfenster, in dem ein verschlüsseltes Archiv existiert, dessen Passwort nur noch in einer Variablen lebt. Schlägt das Hinterlegen dann fehl, hat man eine unlesbare Datei erzeugt. So bricht das Skript stattdessen ab, bevor überhaupt etwas entsteht. Nebeneffekt: Weil das Passwort maschinell erzeugt und direkt weitergereicht wird, ist es stärker als jedes selbst getippte — und der Nutzer bekommt es nie zu sehen.

Ehrlicherweise: Für diese Reihenfolge gibt es keine Norm, die sie vorschreibt. Ableiten lässt sie sich aus dem Schlüssel-Lebenszyklus der NIST-Empfehlung, in der die Bereitstellung eines Schlüssels seiner Nutzung zwingend vorausgeht — und die Nutzung ist hier der Packvorgang. Der Schaden, den sie verhindert, ist dagegen belegt: genau jene BSI-Gefährdung, mit der dieser Artikel begonnen hat.

Der Fehler, der zeigt, warum das alles nötig ist

Zum Schluss ein eigener Fehler, der sämtliche Regeln dieses Artikels auf einmal begründet.

Beim Erstellen des Schlüssel-Inventars sollten die Werte maskiert ausgegeben werden — man sieht, welche Schlüssel existieren, nicht deren Inhalt. Meine Maskierung erkannte Zeilen mit Doppelpunkt oder Gleichheitszeichen. Eine der Dateien nutzte ein anderes Format. Damit stand ein 32-stelliges Passwort im Klartext im Arbeitsprotokoll — nachweislich das Repo-Passwort einer der beiden Sicherungen.

Dazu kam ein zweiter Befund: Ausgerechnet diese Datei trug als einzige die Rechte 0644, war also für jeden Nutzer des Systems lesbar. Alle anderen Schlüsseldateien standen korrekt auf 0600.

Die Lehre ist unbequem und einfach: Ein Werkzeug, das Geheimnisse verarbeitet, muss das Format kennen, bevor es etwas ausgibt. Eine Maskierung, die auf Mustern beruht, ist eine Annahme über Daten — und Annahmen über Daten haben an diesem Tag mehrfach nicht gehalten.

Immerhin ist der Schaden begrenzbar, und auch das gehört zu einem Notfallkonzept: Bei Restic lässt sich das Repo-Passwort austauschen, ohne die Daten neu zu verschlüsseln. Der Hauptschlüssel bleibt, nur die Schlüsseldatei wird ersetzt — neues Passwort hinzufügen, altes entfernen. Ein Passwortwechsel kostet damit Sekunden statt Stunden, was die Hemmschwelle senkt, ihn im Zweifel wirklich durchzuführen.

Was ein Notfallkoffer leisten muss

Vier Eigenschaften haben sich als die wesentlichen herausgestellt:

Er ist nicht zirkulär. Kein Schritt der Einstiegskette setzt ein funktionierendes Backup voraus. Der erste Schlüssel liegt außerhalb, an mindestens zwei unabhängigen Stellen.

Er enthält kein Klartext-Geheimnis. Deshalb darf er überallhin — und ist im Ernstfall tatsächlich da.

Er ist mit verbreiteten Werkzeugen zu öffnen. Nicht das beste Verfahren gewinnt, sondern das, das in zwei Jahren auf einem fremden Rechner verfügbar ist.

Er ist erprobt. Und zwar so, dass ein Test, der nicht läuft, nicht als bestanden durchgeht. Nach diesem Tag prüfe ich bei jedem grünen Ergebnis zuerst, ob der Befehl überhaupt ausgeführt wurde.

Das ist die Klammer über alle vier Teile dieser Serie. Die Fehler lagen nie dort, wo die Aufmerksamkeit war. Sie lagen in einer Liste, die nicht enthalten konnte, woran niemand gedacht hatte; in Zahlen, die etwas anderes zählten als angenommen; in einem Wächter, dessen Ausfall wie Ruhe aussah; und in einer Schlüsselkette, die sich im Kreis schloss. Was sie verbindet, ist nicht mangelnde Sorgfalt — sondern dass jede dieser Stellen ein plausibles, beruhigendes Ergebnis lieferte.

Ein Backup ist nicht dann gut, wenn es Erfolg meldet. Es ist dann gut, wenn man weiß, woran man erkennen würde, dass die Erfolgsmeldung falsch ist.

Quellenverzeichnis

Alle Quellen abgerufen am 20.08.2026.

• BSI IT-Grundschutz, Baustein CON.3 „Datensicherungskonzept", Edition 2023 — Gefährdung 2.8 (verschlüsselte Sicherung ohne getrennt aufbewahrten Schlüssel), Gefährdung 2.4 (nur digital vorliegende Wiederherstellungsinformation), Anforderungen CON.3.A13, CON.3.A6 und CON.3.A12.
• BSI IT-Grundschutz, Baustein DER.4 „Notfallmanagement", Edition 2023 — Anforderung DER.4.A1 (Notfallhandbuch, Angabe: „Es SOLLTE auch im Notfall zugänglich sein").
• NIST SP 800-57 Part 1 Rev. 5, „Recommendation for Key Management" — § 8.3.1 (Angabe: archiviertes Schlüsselmaterial „shall be stored separately from operational data"), § 6.2.2.1 und § 6.2.2.2 (Kopien an getrennten Orten), Kapitel 8 (Reihenfolge von Bereitstellung und Nutzung).
• NIST SP 800-34 Rev. 1, „Contingency Planning Guide" — § 3.6 (Kopie des Plans am Ausweichstandort und bei den Sicherungsmedien), § 3.4.2 (Auslagerung, Auswahlkriterium der räumlichen Entfernung).
• PKWARE, „.ZIP File Format Specification", Version 6.3.10 vom 01.11.2022 — Abschnitt 7.1.6 (Angabe: „information leakage… a file's name, its original size, timestamp and CRC32 value"), 7.1.10 (Verzeichnisverschlüsselung als optionale Erweiterung), 7.3.1 (Maskierung im lokalen Kopfsatz).
• 7-Zip, Programmhilfe, Abschnitte „-m (Set compression Method) switch" und „-p (set Password) switch" — Angabe zur Voreinstellung der Header-Verschlüsselung („The default mode is he=off") und zur Wirkung auf die Dateinamen; vollständige Schalterliste ohne Option für Passwortdatei oder Filedeskriptor. Ausgeliefert mit 7-Zip und p7zip; Projektseite: 7-zip.org.
• OpenSSH, ssh(1) — Angabe zu privaten Schlüsseldateien („ssh will simply ignore a private key file if it is accessible by others"); sshd_config(5) — Prüfung von Rechten und Eigentümerschaft, standardmäßig aktiv.
• OpenSSH, Quellcode authfile.c — Prüfbedingung für zulässige Rechte und Eigentümerschaft privater Schlüssel.
• ps(1) — Angabe: liest die virtuellen Dateien des Kernel-Dateisystems und benötigt dafür keine Privilegien; proc_pid_environ(5) — Zugriffsprüfung auf die Prozessumgebung.
• GnuPG-Handbuch — Warnungen zu Passphrase per Argument und per Datei, Beschreibung der Übergabe per Filedeskriptor.
• Restic-Dokumentation, Handbuch — Passwortdatei und Passwortbefehl; „Restoring from backup" — Wiederherstellung von Rechten und erweiterten Attributen.