Schutzdesign: unabhängige Kopien, Aufbewahrungstiefe, Unveränderbarkeit

Drei Kopien, zwei Medien, eine außer Haus — und trotzdem alles weg, weil ein einziges Verwaltungskonto alle drei erreichte. Dieses Modul ersetzt das Zählen von Kopien durch den Entwurf gegen benannte Schadenswege: Was schützt gegen einen Standortausfall, was gegen einen acht Wochen alten Datenfehler, und was gegen jemanden, der gültige Zugangsdaten besitzt und sie gezielt gegen die Sicherung richtet. Unveränderbarkeit kommt dabei mit zwei Stufen und zwei sehr verschiedenen Preisen — einer davon ist unwiderruflich.

Lehrtext · 11 Abschnitte · zuletzt geprüft: 2026-09-04

Die Frage hinter der Kopienzahl

„Drei Kopien, zwei Medien, eine außer Haus“ ist die bekannteste Merkregel des Fachgebiets. Sie stammt nicht aus einer Norm, sondern aus der Praxis, und sie ist als Merkregel brauchbar — als Entwurfsgrundlage ist sie es nicht. Sie zählt Kopien, und Kopien sind nicht das, was zählt.

Fehlerdomäne — Der Bereich, den ein einzelnes Ereignis gemeinsam trifft. Zwei Kopien liegen in derselben Fehlerdomäne, wenn ein Ereignis beide gleichzeitig unbrauchbar machen kann — unabhängig davon, wie weit sie räumlich auseinanderliegen.

Damit wird aus der Zählfrage eine Entwurfsfrage: Nicht „wie viele Kopien haben wir“, sondern „welches einzelne Ereignis nimmt uns alle auf einmal“. Drei Kopien in drei Rechenzentren, verwaltet von einem Konto mit Löschrechten auf alle drei, sind gegen den Ausfall eines Gebäudes gut geschützt und gegen einen Angreifer mit diesem Konto genauso wertlos wie eine einzige.

Vier Schadenswege, vier verschiedene Antworten

Ein Schutzentwurf, der nicht sagt, wogegen er schützt, ist nicht prüfbar. Vier Wege decken den überwiegenden Teil der Fälle ab, und keine einzelne Maßnahme deckt mehr als zwei davon.

Ausfall von Gerät oder Standort: Hardware stirbt, Feuer, Stromausfall. Antwort: eine Kopie in einer anderen räumlichen Domäne.
Bedienfehler: Jemand löscht oder überschreibt versehentlich. Antwort: Aufbewahrung — ein Stand, der älter ist als der Fehler.
Stille Verfälschung: Datenfehler, fehlerhafte Anwendung, defekter Datenträger. Fällt spät auf. Antwort: Aufbewahrungstiefe plus regelmäßige Prüfung der Lesbarkeit.
Angriff mit gültigen Zugangsdaten: Der Angreifer hat Rechte und benutzt sie, auch gegen die Sicherung. Antwort: eine Kopie, die diese Rechte nicht erreichen.

Der Satz „keine Maßnahme deckt mehr als zwei“ ist die eigentliche Nutzung dieser Tabelle. Ein zweiter Standort beantwortet Zeile eins und sonst nichts. Aufbewahrung beantwortet Zeile zwei und drei und hilft gegen Zeile vier nur, wenn der Angreifer die alten Stände nicht erreicht. Unveränderbarkeit beantwortet Zeile vier und lässt Zeile drei offen, weil eine unveränderlich gespeicherte Verfälschung unveränderlich falsch bleibt. Wer den Entwurf gegen die vier Zeilen prüft, findet die Lücke, bevor sie jemand anders findet.

Warum die vierte Zeile alles ändertDie ersten drei Wege sind Unfälle: Sie treffen die Sicherung nicht gezielt. Der vierte tut es. Der #StopRansomware-Leitfaden von CISA und MS-ISAC beschreibt genau das als Regelverhalten — viele Schadprogramme suchen erreichbare Sicherungen und löschen oder verschlüsseln sie, damit eine Wiederherstellung ohne Zahlung unmöglich wird. Ein Entwurf, der nur die ersten drei Zeilen bedient, ist gegen den heute häufigsten Totalschaden blank.

Unabhängigkeit ist nicht Entfernung

Der häufigste Entwurfsfehler ist, Unabhängigkeit räumlich zu denken. Entfernung schützt gegen Ereignisse, die sich räumlich ausbreiten — Feuer, Wasser, Stromausfall. Gegen alles, was sich über Rechte ausbreitet, hilft sie überhaupt nicht.

Gemeinsame Anmeldung. Wenn dasselbe Konto beide Kopien löschen kann, ist es eine Domäne — auch über Kontinente hinweg.
Gemeinsame Verwaltungsebene. Zwei Speichersysteme unter einer Verwaltungsoberfläche teilen deren Kompromittierung.
Gemeinsames Netz ohne Grenze. Erreichbarkeit ist Voraussetzung für Verschlüsselung durch einen Angreifer.
Gemeinsamer Anbieter, gemeinsames Konto. Zwei Regionen desselben Kontos schützen gegen Regionsausfall, nicht gegen Kontoverlust oder Fehlbedienung.

Daraus wird eine Prüffrage, die sich in fünf Minuten beantworten lässt und erstaunlich oft ein unangenehmes Ergebnis liefert: Welche Anmeldung erreicht welche Kopie? Man schreibt die Kopien in eine Spalte, die Konten und Rollen in die andere und zieht Striche. Jede Kopie, die von demselben Konto erreichbar ist wie das Original, ist gegen den vierten Schadensweg keine eigene Domäne — auch wenn sie in einer anderen Stadt liegt und der Vertrag sie „georedundant“ nennt.

Kurzcheck

Ein Betrieb sichert nachts auf ein Speichersystem im selben Haus und repliziert die Sicherung anschließend in ein zweites Rechenzentrum. Beide Systeme werden über dasselbe Verwaltungskonto administriert. Wie viele unabhängige Domänen liegen gegen einen Angriff mit diesem Konto vor?

Eine.
Zwei, weil die Kopien an getrennten Standorten liegen.
Zwei, weil die Replikation zeitversetzt läuft und damit ein älterer Stand erhalten bleibt.

Treffer. Richtig. Gegen räumliche Ereignisse sind es zwei Domänen, gegen die Kompromittierung des Verwaltungskontos eine — der Angreifer erreicht beide Kopien mit derselben Anmeldung.

Replikation ist keine Sicherung

Replikation — Verfahren, das Änderungen fortlaufend auf eine zweite Kopie überträgt, damit diese dem Original möglichst nahe kommt. Ihr Zweck ist Verfügbarkeit: Fällt eine Seite aus, übernimmt die andere.

Genau diese Eigenschaft macht sie als Schutz gegen Datenschäden untauglich. Eine gelöschte Datei wird repliziert. Ein verschlüsselter Datenträger wird repliziert. Eine fehlerhafte Anwendung, die über Nacht falsche Werte schreibt, wird repliziert. Die Replikation tut, was sie soll — und das ist der Schaden.

Replikation beantwortet: Was passiert, wenn eine Seite ausfällt? Ziel: kurze Ausfallzeit.
Sicherung beantwortet: Was passiert, wenn die Daten falsch werden? Ziel: ein Stand von vorher.
Beide zusammen: Der Normalfall in Klasse A: Replikation für die Wiederanlaufzeit, Sicherung für die Rückkehr zu einem früheren Stand.

Die Formulierung, die den Unterschied trägtEin einzelner Satz trennt beide Begriffe zuverlässig: Eine Sicherung ist eine Kopie, die sich nicht mit dem Original ändert. Alles, was dem Original folgt — Replikation, Spiegelung, fortlaufende Synchronisierung — schützt Verfügbarkeit. Alles, was stehen bleibt, schützt Wiederherstellbarkeit. Ein Speicher-Snapshot liegt dazwischen: Er bleibt stehen, teilt aber Fehlerdomäne und Verwaltung mit dem Original.

Aufbewahrung: Rhythmus ist nicht Tiefe

Der Rhythmus bestimmt, wie viel bei einem plötzlichen Verlust fehlt. Die Tiefe bestimmt, wie weit zurück man greifen kann, wenn der Schaden nicht plötzlich war. Beide Größen werden regelmäßig verwechselt, und die Verwechslung kostet genau dann, wenn es am meisten wehtut.

Der Fehler, der acht Wochen alt ist

Szenario

Eine Schnittstelle schreibt seit acht Wochen falsche Preise in einen Teil der Artikelstammdaten. Aufgefallen ist es durch eine Kundenbeschwerde. Die Sicherung läuft stündlich und wird 30 Tage aufbewahrt.

Anforderungen

Der letzte nachweislich korrekte Stand der betroffenen Datensätze soll wiederhergestellt werden.
Die Änderungen der übrigen Artikel aus acht Wochen sollen erhalten bleiben.

Schritte

Feststellen, dass ein stündlicher Rhythmus hier nichts nützt: Jede der vorhandenen Kopien ist jünger als der Fehler.
Die Aufbewahrungstiefe prüfen: Die älteste Kopie ist 30 Tage alt, der Fehler ist 56 Tage alt. Kein vorhandener Stand ist nachweislich korrekt.
Den Umfang eingrenzen: Nicht die ganze Datenbank ist betroffen, sondern ein Teil der Artikel — ein vollständiger Restore würde acht Wochen korrekter Arbeit vernichten.
Nach anderen Quellen für den korrekten Stand suchen: Lieferantenlisten, Ausdrucke, ein Auswertungssystem mit eigener Historie.
Für die Zukunft die Tiefe entlang der realistischen Erkennungszeit festlegen — Monatsstände über ein Jahr kosten wenig und decken genau diesen Fall.

Merksatz: Rhythmus schützt gegen plötzlichen Verlust, Tiefe gegen spät entdeckte Verfälschung. Die richtige Frage für die Tiefe lautet nicht „wie lange wollen wir aufbewahren“, sondern „wie lange kann ein Fehler bei uns unbemerkt bleiben“ — und die Antwort darauf ist fast immer länger als 30 Tage.

Dichtes kurzes Fenster: Stündlich, 30 Tage. Rund 720 Stände. Deckt plötzlichen Verlust hervorragend ab und endet bei 30 Tagen.
Gestaffelt: Stündlich für 48 Stunden, täglich für 30 Tage, monatlich für 12 Monate. Rund 90 Stände. Deckt beides ab und reicht ein Jahr zurück.
Was die Staffel kostet: Alte Stände sind grobkörnig: Zwischen zwei Monatsständen liegt ein Monat, aus dem nichts zurückzuholen ist.

Warum Tiefe billig istEin Jahr Monatsstände sind zwölf Kopien; 30 Tage Tagesstände sind dreißig. Gestaffelte Aufbewahrung — dichte junge Stände, dünne alte — kostet meist weniger Speicher als ein dichtes kurzes Fenster und deckt einen erheblich größeren Teil der Schadensfälle ab. Der Preis steht im vorigen Modul: Was lange aufbewahrt wird, kollidiert mit Löschpflichten und braucht einen dokumentierten Plan.

Unveränderbarkeit: was das technisch bedeutet

WORM — write once, read many — Eine Speichereigenschaft, bei der ein einmal geschriebener Bestand für eine festgelegte Dauer gelesen, aber nicht mehr geändert oder gelöscht werden kann — durchgesetzt vom Speichersystem selbst, nicht von einer Berechtigung darüber.

Gegen den vierten Schadensweg — den Angreifer mit gültigen Rechten — hilft nur eine Kopie mit dieser Eigenschaft. Objektspeicher setzen sie über Sperren um, die je Objektversion gelten und deshalb Versionierung voraussetzen. Das ist eine Feinheit mit Folgen: Ohne Versionierung gibt es keine Objektversion, auf der eine Sperre liegen könnte, und eine Überschreibung erzeugt eine neue Version, die die Aufbewahrungseinstellungen der alten nicht erbt. Zwei Anbieterbeispiele zeigen dieselbe Struktur.

Aufbewahrungsfrist: Eine Sperre bis zu einem Zeitpunkt. Sie lässt sich verlängern, aber nicht verkürzen — das ist bei beiden Anbietern der Kern der Zusage.
Rechtliche Sperre: Eine Sperre ohne Frist. Sie gilt, bis jemand sie aufhebt, und wirkt unabhängig von einer laufenden Aufbewahrungsfrist.
Umkehrbare Stufe: Bei S3 der Modus GOVERNANCE, bei Azure die nicht gesperrte Richtlinie. Zum Erproben gedacht: Frist änderbar, Richtlinie löschbar.
Endgültige Stufe: Bei S3 der Modus COMPLIANCE, bei Azure die gesperrte Richtlinie. Nicht rücknehmbar, nicht verkürzbar — auch nicht durch den Kontoinhaber.

Der Satz, der die Tragweite zeigtDie AWS-Dokumentation formuliert für COMPLIANCE unmissverständlich: Eine geschützte Objektversion kann von keinem Nutzer überschrieben oder gelöscht werden, einschließlich des Root-Nutzers des Kontos — und der einzige Weg, sie vor Ablauf der Frist loszuwerden, ist die Löschung des gesamten AWS-Kontos. Wer diesen Modus mit einer zu langen Frist auf einen zu großen Bestand legt, hat die Kosten für diese Frist unwiderruflich eingekauft.

Die Falle in der umkehrbaren Stufe

Die umkehrbare Stufe wirkt wie der vernünftige Kompromiss: geschützt gegen die meisten, korrigierbar für wenige. Genau in dieser Konstruktion steckt der Fehler, der sie gegen den vierten Schadensweg wirkungslos macht.

Bei S3 lässt sich eine GOVERNANCE-Sperre umgehen, wenn zwei Bedingungen zusammenkommen: die Berechtigung s3:BypassGovernanceRetention und der Kopfzeileneintrag x-amz-bypass-governance-retention:true in der Anfrage. Die zweite Bedingung klingt nach einer bewussten Hürde — und die Dokumentation stellt in einem Hinweis klar, dass die S3-Konsole diesen Kopfzeileneintrag standardmäßig mitschickt. Wer die Berechtigung hat, löscht geschützte Objekte über die Konsole also ohne jeden zusätzlichen Schritt.

Woran die Prüffrage hängtDamit verlagert sich die ganze Schutzwirkung auf eine einzige Frage: Wer besitzt `s3:BypassGovernanceRetention`? Ist es dieselbe Rolle, die auch die Sicherung betreibt, ist die Sperre gegen einen Angreifer mit dieser Rolle wirkungslos. Dasselbe gilt für die rechtliche Sperre: Sie kann von jedem, der s3:PutObjectLegalHold besitzt, ebenso frei aufgehoben wie gesetzt werden. Unveränderbarkeit ist immer nur so stark wie die Trennung der Berechtigung, die sie aufhebt.

Löschmarkierung ist keine Löschung

Bei aktivierter Objektsperre verhalten sich Löschanfragen unterschiedlich, je nachdem, ob sie eine Version benennen. Der Unterschied ist im Betrieb regelmäßig eine Überraschung — in beide Richtungen.

Löschanfrage mit Versionsangabe: Wird abgelehnt: 403 Forbidden. Die geschützte Version bleibt bestehen, und der Versuch ist ein sichtbares Ereignis.
Löschanfrage ohne Versionsangabe: Wird mit 200 OK beantwortet. Es entsteht eine Löschmarkierung, die zur aktuellen Version wird; die geschützte Version bleibt darunter erhalten.

Die zweite Zeile hat zwei Gesichter. Für die Wiederherstellung ist sie gut: Ein Angreifer, der „erfolgreich“ gelöscht hat, hat nichts vernichtet — die Daten liegen unter der Markierung. Für den Betrieb ist sie tückisch: Eine Aufräumaktion meldet Erfolg, der Speicherplatz wird nicht frei, und wer die Kosten kontrolliert, sucht an der falschen Stelle. Beides gehört in den Wiederanlaufplan: die Markierung zu entfernen ist ein eigener Schritt.

Für die Betriebspraxis folgen daraus zwei Gewohnheiten. Erstens: Eine Meldung „gelöscht“ aus einem versionierten Speicher ist ohne Prüfung der Version keine Aussage über den Bestand — weder im guten noch im schlechten Sinn. Zweitens: Die Antwort 403 Forbidden auf eine versionsbezogene Löschanfrage ist kein Betriebsfehler, sondern der Beweis, dass die Sperre wirkt. Wer sie in der Überwachung als Störung führt, bekommt genau dann eine Meldung, wenn alles richtig läuft — und trainiert sich an, sie wegzuklicken.

Offline und Luftspalt: der teure, harte Schutz

Die härteste Trennung ist die physische. Eine Kopie, die nicht angeschlossen ist, lässt sich weder verschlüsseln noch löschen — von niemandem, mit keiner Berechtigung. Der #StopRansomware-Leitfaden nennt genau das als erste Empfehlung: verschlüsselte Sicherungen offline vorhalten und ihre Verfügbarkeit und Unversehrtheit regelmäßig in einem Wiederherstellungsszenario prüfen.

Was „offline“ wirklich verlangt. Nicht erreichbar heißt: kein Netzpfad, keine Anmeldung, kein Automatismus, der sie zum Schreiben verbindet. Ein Band im Laufwerk ist online; ein Band im Schrank ist offline.
Was es kostet. Handarbeit, eine benannte Zuständigkeit, Transport und Lagerung — und im Ernstfall eine deutlich längere Wiederanlaufzeit, weil das Medium erst geholt und eingelesen werden muss.
Was dabei gern vergessen wird. Das Lesegerät. Eine Kopie auf einem Medium, für das im Ernstfall kein funktionierendes Laufwerk erreichbar ist, ist keine Kopie.
Wofür es sich lohnt. Nicht für den gesamten Bestand, sondern für den Kern, aus dem sich der Betrieb wieder aufbauen lässt — Verzeichnisdienst, Schlüssel, Konfiguration, die Daten der Klasse A.

Die ehrliche Warnung aus dem CISA-LeitfadenDerselbe Leitfaden, der unveränderbaren Speicher empfiehlt, rät ausdrücklich zur Vorsicht: Er erfülle nicht für jede Regulierung die Vorgaben, und eine Fehlkonfiguration könne erhebliche Kosten verursachen. Das ist der Preis der richtigen Wahl, und er gehört in jede Entscheidungsvorlage — eine zu lang gesetzte, endgültige Sperre auf einem großen Bestand ist ein Kostenposten, den niemand mehr abstellen kann.

Der Entwurf in fünf Zeilen

Ein Schutzentwurf für eine Schutzklasse lässt sich in fünf Zeilen aufschreiben. Sie sind die Übersetzung der Klassenzusage aus dem vorigen Modul in etwas, das jemand bauen kann.

Rhythmus — aus der Verlustgrenze→Tiefe — aus der realistischen Erkennungszeit→Domänen — je Schadensweg eine Antwort→Unveränderbarkeit — Stufe und getrennte Berechtigung→Prüfung — wie Lesbarkeit und Umfang belegt werden

Jede Zeile nennt den Schadensweg, den sie beantwortet

Die Zeile, die am häufigsten fehltDie fünfte. Ein Entwurf ohne Prüfung ist eine Absichtserklärung — und Unveränderbarkeit macht das schlimmer statt besser, weil sie das Gefühl von Sicherheit erzeugt, ohne dass jemals jemand gelesen hätte, was in den unveränderlichen Objekten steht. Wie dieser Nachweis aussieht, ist das Thema des Moduls über den Nachweis von Restores.

Was dieses Modul offenlässt

Hier steht, wie viele Kopien es braucht, wie unabhängig sie sein müssen und wie lange sie bestehen bleiben. Offen bleibt, mit welchem Verfahren sie entstehen — Vollsicherung, inkrementell, Snapshot, Replikation — und welches Medium die gerechnete Wiederanlaufzeit einhalten kann. Das ist die Recovery-Architektur im nächsten Modul.

AbgrenzungDie Absicherung des Angriffswegs selbst — Segmentierung, Rechtevergabe, Erkennung — steht in den Sicherheitsmodulen der Nachbartracks. Hier interessiert nur, was davon den Entwurf der Sicherungskopien bestimmt: welche Berechtigung welche Kopie erreicht.

Jetzt anwenden

Diesen Stoff gibt es als Modul mit bewerteten Entscheidungs-Checks — dieselbe Einführung, danach die Übungen.

Zum Modul →

Quellen & Aktualität5 Primärquellen · zuletzt geprüft: 2026-09-04