Sicherungspfade implementieren: Rechte, Schlüssel, Fenster, Überwachung

Vier Dinge, die der Entwurf nicht enthält

Ein Schutzentwurf sagt, wie viele Kopien wohin gehören und wie lange sie bleiben. Er sagt nichts darüber, unter welchem Konto sie entstehen, mit welchem Schlüssel sie verschlüsselt sind, in welchem Zeitfenster sie geschrieben werden und woran man merkt, dass sie ausbleiben.

Genau diese vier Punkte entscheiden darüber, ob aus dem Entwurf ein Schutz wird. Sie haben eine unangenehme Gemeinsamkeit: Wenn sie falsch gesetzt sind, läuft die Sicherung trotzdem — grün, pünktlich und über Jahre. Ihr Fehler wird nicht gemeldet, er wird eingelöst.

Das Sicherungskonto ist das mächtigste Konto im Haus

Eine Sicherung muss alles lesen können — jede Datei, jedes Postfach, jede Datenbank. Das übliche Prinzip der geringsten Rechte greift auf der Leseseite deshalb kaum: Was gesichert werden soll, muss lesbar sein. Diese Rechnung geht auf, solange man die andere Seite betrachtet.

Zweiseitige Rechteprüfung — Die Trennung zwischen dem, was ein Sicherungskonto auf der Quelle darf (viel lesen), und dem, was es auf dem Ziel darf (schreiben — und möglichst nichts löschen). Beide Seiten werden getrennt entworfen, weil sie verschiedene Angriffe abwehren.

Praktisch heißt das: Auf der Quelle ist ein weitreichendes Leserecht unvermeidbar und muss durch Überwachung und Trennung von interaktiven Anmeldungen abgesichert werden. Auf dem Ziel ist es dagegen fast immer möglich und fast nie umgesetzt, das Löschen wegzunehmen — und genau dort entscheidet sich, was ein kompromittierter Server anrichten kann.

• Keine interaktive Anmeldung. Ein Dienstkonto, an dem sich jemand anmelden kann, ist ein Verwaltungskonto mit sehr weitreichenden Leserechten — und wird als solches auch benutzt, sobald es einmal bequem war.
• Kein gemeinsames Konto über alle Systeme. Ein Konto je Umgebung begrenzt, was die Übernahme eines einzelnen Systems einbringt; ein einziges Konto für die ganze Flotte ist ein Generalschlüssel.
• Getrennte Anmeldung für die Verwaltung des Sicherungssystems. Wer Sicherungen konfiguriert, braucht kein Leserecht auf alle Nutzdaten — das sind zwei Aufgaben und sollten zwei Konten sein.
• Sichtbare Benutzung. Anmeldungen des Sicherungskontos außerhalb der Sicherungsfenster sind ein Befund, kein Rauschen — und eine der wenigen Auswertungen, die sich mit wenig Aufwand einrichten lässt.

Wer verbindet sich zu wem

Die Frage klingt nach einem Detail der Netzarchitektur und ist eine der folgenreichsten Entscheidungen des ganzen Themas. Sie entscheidet, ob die Zugangsdaten zum Sicherungsziel auf dem zu sichernden System liegen.

Quelle schiebt (Push)

Das zu sichernde System kennt Adresse und Zugangsdaten des Ziels. Wer den Server übernimmt, findet beides — und kann damit auch löschen, sofern das Ziel es zulässt.

Ziel holt (Pull)

Das Sicherungssystem verbindet sich zur Quelle. Auf der Quelle liegen keine Zugangsdaten zum Ziel; die Übernahme des Servers gibt keinen Zugriff auf die Sicherungen.

Push mit eingeschränktem Ziel

Die Quelle schiebt, das Ziel erlaubt aber nur Anlegen — kein Ändern, kein Löschen. Der praktikable Mittelweg, wenn Pull organisatorisch nicht geht.

Was Append-only kostet

Der Preis ist real und wird gern übersehen: Wenn die schreibende Anmeldung nicht löschen darf, kann sie auch keine abgelaufenen Stände aufräumen. Aufbewahrung ist aber nichts anderes als geplantes Löschen.

• Das Aufräumen wandert auf die Zielseite. Es läuft dort unter einer anderen Anmeldung, zu der die Quelle keinen Zugang hat — ein eigener Auftrag mit eigener Überwachung.
• Der Speicherbedarf steigt, wenn dieser Auftrag ausfällt. Und er fällt leiser aus als eine Sicherung, weil niemand ihn vermisst.
• Fehlerhafte Läufe bleiben stehen. Ein versehentlich in voller Größe geschriebener Bestand lässt sich nicht mehr im Vorbeigehen entfernen.
• Der Notfallweg muss existieren. Wenn im Ernstfall doch gelöscht werden muss, braucht es eine benannte Rolle und einen dokumentierten Ablauf — sonst wird die Trennung im ersten Engpass abgeschaltet.

Diese vier Punkte sind kein Argument gegen die Trennung, sondern ihre Betriebskosten. Wer sie nicht einplant, baut die Trennung ein und wieder aus — und hat danach beides nicht: weder den Schutz noch das Vertrauen in die Maßnahme.

Schlüssel: nicht beim Original, nicht nirgends

Verschlüsselte Sicherungen sind Standard und richtig. Sie verschieben das Problem aber vollständig auf den Schlüssel: Er ist ab jetzt der Gegenstand, dessen Verlust die Wiederherstellung beendet — endgültig und ohne Ausweg.

Schlüssel beim Original

Der häufigste Zustand. Der Ausfall, gegen den gesichert wird, nimmt den Schlüssel mit. Die Sicherung ist dann vorhanden und nutzlos.

Schlüssel nur bei einer Person

Funktioniert, bis diese Person im Urlaub, krank oder ausgeschieden ist. Ein Notfall wartet nicht auf ihre Rückkehr.

Schlüssel getrennt verwahrt, mit zweitem Zugang

Der Zielzustand: der Schlüssel liegt außerhalb der gesicherten Domäne, und mindestens zwei benannte Wege führen zu ihm.

Ein zweiter Punkt fällt regelmäßig erst nach Jahren auf: Ein Schlüsselwechsel wirkt nach vorn, nicht nach hinten. Bereits geschriebene Bestände bleiben mit dem alten Schlüssel verschlüsselt, solange sie nicht neu geschrieben werden. Wer im Rahmen eines Sicherheitsvorhabens Schlüssel turnusmäßig wechselt und die alten aufräumt, macht damit die Aufbewahrungstiefe unlesbar, für die er gerade Speicher bezahlt. Jeder Schlüssel muss deshalb mindestens so lange verfügbar bleiben, wie der älteste damit verschlüsselte Bestand aufbewahrt wird.

Die Prüffrage für den Betrieb lautet nicht „ist verschlüsselt?“, sondern: Wer kann diesen Bestand morgen früh entschlüsseln, wenn das Rechenzentrum heute Nacht abbrennt? Wenn die Antwort einen Namen enthält und keinen Ort, ist die Antwort nicht vollständig.

Das Sicherungsfenster ist nicht der Zeitplan

Sicherungsfenster — Die Zeitspanne, in der ein Sicherungslauf abgeschlossen sein muss — begrenzt durch den Beginn des nächsten Laufs und durch die Zeit, ab der die Last auf der Quelle den Betrieb stört. Der Zeitplan legt den Start fest, das Fenster die zulässige Dauer.

Der zweite Wert wird selten festgelegt und noch seltener überwacht. Dabei verändert er sich als einziger von allein: Der Datenbestand wächst, die Laufzeit wächst mit, und irgendwann läuft die Sicherung in den Arbeitsbeginn hinein oder in den nächsten Lauf.

• Überlappung. Ein Lauf, der länger dauert als das Intervall, trifft auf den nächsten. Manche Systeme überspringen dann, manche laufen doppelt — beides ist schlecht, und man sollte wissen, welches davon gilt.
• Last auf der Quelle. Sicherung liest mit voller Geschwindigkeit, wenn man sie lässt. Unter Linux begrenzen nice und ionice Prozessor- und Ein-/Ausgabepriorität; die meisten Sicherungswerkzeuge bringen zusätzlich eine eigene Durchsatzgrenze mit.
• Wachstum. Ein Fenster, das heute zu 60 Prozent gefüllt ist, ist in zwei Jahren zu klein. Die Auslastung des Fensters gehört überwacht, nicht nur sein Ergebnis.
• Der Zeitstempel. Ein Lauf von 23:00 bis 03:00 erzeugt keinen einheitlichen Stand — für die Wiederherstellung zählt, welcher Teil wann gelesen wurde.

Was Überwachung tatsächlich beweisen muss

Die verbreitetste Überwachung meldet fehlgeschlagene Sicherungsläufe. Sie hat eine Lücke, die genau im schlimmsten Fall aufgeht: Ein Lauf, der überhaupt nicht startet, meldet keinen Fehlschlag. Der Zeitplan wurde gelöscht, der Dienst läuft nicht mehr, das Konto ist gesperrt, die virtuelle Maschine wurde umbenannt — in all diesen Fällen bleibt es still, und Stille sieht aus wie Erfolg.

Erwartungsbasierte Überwachung — Eine Prüfung, die nicht auf ein Ereignis wartet, sondern das Ausbleiben eines erwarteten Ereignisses meldet. Für Sicherungen: das Alter des jüngsten erfolgreichen Laufs je Dienst, geprüft gegen die zugesagte Verlustgrenze.

Diese eine Kennzahl ersetzt ein halbes Dutzend Einzelmeldungen und hat einen zusätzlichen Vorteil: Sie ist in derselben Einheit formuliert wie die Zusage. „Der jüngste erfolgreiche Lauf für den Auftragsdienst ist 31 Stunden alt, zugesagt sind vier“ ist eine Aussage, die auch außerhalb der IT verstanden wird — im Unterschied zu „Job 4711 mit Warnung beendet“.

Erfolg ist nicht Vollständigkeit

Der zweitgefährlichste Zustand nach der Stille ist der teilweise Erfolg. Ein Lauf, der 98 Prozent geschafft hat, ist in vielen Umgebungen ein grüner Lauf — und die fehlenden zwei Prozent sind bevorzugt genau die Dateien, die zum Sicherungszeitpunkt geöffnet waren.

Wie leicht das durchrutscht, zeigt ein Blick in rsync(1). Die Handbuchseite unterscheidet unter anderem den Rückgabewert 23 — teilweise Übertragung wegen eines Fehlers — von 24, teilweise Übertragung wegen verschwundener Quelldateien. Der zweite Fall gilt vielerorts als harmlos, weil temporäre Dateien nun einmal verschwinden. Wer daraufhin beide Werte gemeinsam als „in Ordnung“ behandelt, hat die Meldung über echte Lesefehler mit abgeschaltet.

Die allgemeine Regel dahinter ist unabhängig vom Werkzeug: Jedes Sicherungsprogramm kennt einen Zustand zwischen Erfolg und Fehlschlag, und dieser Zustand ist der interessante. Er heißt Warnung, Teilerfolg, „completed with exceptions“ oder trägt einen eigenen Rückgabewert. Wer ihn beim Einrichten nicht ausdrücklich einer Seite zuordnet — meldenswert oder nicht — bekommt die Voreinstellung des Herstellers, und die ist auf ruhige Bildschirme optimiert, nicht auf Wiederherstellbarkeit.

Der Weg zurück braucht eigene Zugangsdaten

Eine Frage, die bei der Einrichtung fast nie gestellt wird: Womit meldet man sich am Sicherungssystem an, wenn der Verzeichnisdienst nicht läuft? In vielen Umgebungen lautet die ehrliche Antwort „gar nicht“ — die Verwaltungsoberfläche der Sicherung hängt an derselben zentralen Anmeldung wie alles andere.

• Ein lokaler Notfallzugang am Sicherungssystem, unabhängig vom zentralen Verzeichnis, mit langem Kennwort und dokumentierter Verwahrung.
• Auf Papier oder in einem getrennten Tresor, nicht in dem Kennwortspeicher, der ebenfalls an der zentralen Anmeldung hängt.
• Regelmäßig erprobt, denn ein nie benutzter Notfallzugang ist häufig abgelaufen, gesperrt oder falsch notiert.
• Protokolliert, weil ein Zugang ohne zentrale Kontrolle nur dann vertretbar ist, wenn seine Benutzung sichtbar wird.

Dieselbe Frage gilt für den Schlüssel, für die Dokumentation des Ablaufs und für die Kontaktliste. Alles, was zur Wiederherstellung gebraucht wird und ausschließlich in der Umgebung liegt, die wiederhergestellt werden soll, ist im Ernstfall nicht verfügbar. Das ist eine der wenigen Regeln dieses Tracks ohne Ausnahme.

Die Inbetriebnahme-Prüfliste

Bevor ein Sicherungspfad als produktiv gilt, sind sechs Fragen beantwortet. Sie kosten zusammen einen halben Tag und ersparen die Erfahrung, sie im Ernstfall zu beantworten.

Abgrenzung

Wie ein Bestand fachlich konsistent wird — ruhiggestellte Anwendungen, Datenbanken im richtigen Zustand — steht im Modul über Daten- und Anwendungskonsistenz. Wie Schlüssel, Identitäten und Notfallzugänge als eigener Recovery-Gegenstand betrieben werden, im Modul über IAM und Schlüssel-Recovery.