Snapshots sind keine Backups: Ein CTO‑Playbook für ransomware‑sichere Wiederherstellung

In der Woche, in der ein weiteres nationales Grundbuchregister ausgelöscht wurde und ein US‑Healthcare‑Anbieter „erhebliche“ Daten verlor, wurde eine Wahrheit noch lauter: Wenn Ihre „Backups“ dort leben, wo Ihr Produktions‑IAM sie erreichen kann, sind es keine Backups. Es sind Verhandlungsmasse.

Sie brauchen keinen weiteren Grundsatzvortrag über Ransomware. Sie brauchen einen Recovery‑Plan, der einen Breach mit Root‑Rechten ohne Drama übersteht, schnell genug zurückspielt, um das Geschäft zu retten, und nur einen einstelligen Prozentsatz Ihrer Infra‑Kosten verschlingt. Dieser Beitrag liefert diesen Plan.

Das Problem: Snapshots sind verhandelbar, Backups nicht

Ransomware‑Gruppen beginnen nicht mit dem Verschlüsseln von Dateien. Sie beginnen damit, Wiederherstellungspfade zu löschen. Wenn Ihr Recovery‑Pfad aus EC2/EBS‑Snapshots besteht, kann ein kompromittiertes Admin‑Token diese in Minuten bereinigen. Selbst Cross‑Region‑Replikation hilft nicht, wenn dieselbe Föderationskette auch dort löschen kann. Gleiches gilt für Persistent Volumes in Kubernetes, Datenbank‑Autosnapshots am selben Control Plane sowie „wöchentliche Exporte“, die in einem S3‑Bucket liegen, in den Ihre App‑Rolle schreiben kann.

Zwei aktuelle Schlagzeilen sollten jede CTO ernüchtern: Ein Angreifer hat die Datenbank eines nationalen Grundbuchamts gelöscht; ein US‑Anbieter für tausende Krankenhäuser meldete großen Datendiebstahl und Betriebsstörungen. In beiden Fällen hing die Kontinuität davon ab, ob Backups unveränderlich, isoliert und durch Drills bewiesen waren. Die meisten sind es nicht.

Der Entscheidungsrahmen: Bewerten Sie Ihre Recovery‑Position auf fünf Achsen

Bevor Sie etwas kaufen, bewerten Sie Ihre Wiederherstellungsfähigkeit entlang von fünf Achsen. Sie brauchen alle fünf auf Grün.

1) Mutierbarkeit: Kann ein Angreifer mit Prod‑Admin‑Creds Ihre Backups ändern oder löschen?

• Akzeptabel: S3 Object Lock (compliance mode) oder GCS Bucket Lock mit Retention. Azure Immutable Blob mit zeitbasierter Retention.
• Nicht akzeptabel: Snapshots oder Objekte, die von denselben IAM‑Principals löschbar sind, die Prod betreiben, oder über einen beliebigen föderierten SSO‑Pfad, der im Alltag genutzt wird.

2) Isolation: Befinden sich Backups in einem separaten Blast Radius?

• Akzeptabel: Separates Cloud‑Konto/Projekt/Tenant mit Service Control Policies (SCPs), die Richtlinien‑ oder Lock‑Änderungen verhindern; separate Admin‑Kette, separates KMS‑Root, separate MFA und Hardware‑Tokens.
• Nicht akzeptabel: Dasselbe Konto, dasselbe KMS oder irgendein Break‑Glass, das ein kompromittierter IdP annehmen kann.

3) Schlüsselunabhängigkeit: Können Sie entschlüsseln, wenn Ihr primäres KMS ausfällt oder verbrannt ist?

• Akzeptabel: Dedizierte KMS‑Schlüssel im Backup‑Konto, deren Schlüsselmateriel und Admins nicht mit Prod geteilt sind. Optional in einem HSM hinterlegt oder per Split‑Knowledge‑Verfahren.
• Nicht akzeptabel: Backup‑Daten ausschließlich unter denselben KMS‑Schlüsseln verschlüsselt, die auch Prod nutzt.

4) Recoverability‑SLOs: Haben Sie ein gemessenes RPO/RTO?

• Akzeptabel: Definiertes und getestetes RPO ≤ 15 Minuten für primäre OLTP‑Daten; RTO ≤ 4 Stunden für eine vollständige Stack‑Wiederherstellung Ihres kritischen Services.
• Nicht akzeptabel: „Wir glauben, wir können in einem Tag wiederherstellen.“ Wenn Sie es nicht gestoppt haben, existiert es nicht.

5) Abdeckung: Ist alles, was Sie betreiben und worauf Sie sich verlassen, wiederherstellbar?

• Akzeptabel: Datenbanken, Objektspeicher, Infrastruktur‑State, Container‑Images, Secrets, CI‑Artefakte und SaaS‑Abhängigkeiten (GitHub, Slack, Google Workspace, Notion) mit Export‑Automatisierung.
• Nicht akzeptabel: Nur Datenbanken oder nur VM‑Snapshots.

Die Referenzarchitektur: ransomware‑resiliente Backups in der Public Cloud

Dieses Muster geht von AWS aus, aber dieselben Bausteine existieren in GCP und Azure.

Kernmuster: Doppel‑Konto, Object‑Locked, versionierte Backups

1. Erstellen Sie ein dediziertes „Backup“‑Konto mit eigenem Root, MFA und Hardware‑Sicherheitsschlüsseln. Keine Föderation von Ihrem Corporate‑IdP für Root‑Zugriff. Wenden Sie SCPs an, die Änderungen an Object‑Lock‑Einstellungen, KMS‑Schlüssel‑Löschungen und Rollen‑Modifikationen verbieten – außer über einen kontrollierten Break‑Glass‑Pfad.
2. Provisionieren Sie S3‑Buckets mit aktiviertem Object Lock im compliance mode, Versionierung an und einem Default‑Retention‑Fenster (z. B. 30 Tage). Governance Mode genügt nicht; Compliance Mode verhindert selbst für Root das Entfernen der Retention bis zum Ablauf.
3. Nutzen Sie Cross‑Account‑Replikation von einem „Staging Vault“‑Bucket in Ihrem Prod‑Konto in die Object‑Locked‑Buckets im Backup‑Konto. Replikation sollte einseitig sein und von einer dedizierten Replikationsrolle im Backup‑Konto initiiert werden, nicht aus Prod. Der Ziel‑Bucket erzwingt Object Lock beim Schreiben.
4. Verschlüsseln Sie mit einem KMS‑Schlüssel des Backup‑Kontos (SSE‑KMS), der keinerlei Grants an Prod‑Rollen hat. Halten Sie Key‑Admins in einer separaten Security‑Gruppe mit Hardware‑Tokens und Out‑of‑Band‑Notfallkontakten.
5. Tiering des Speichers: 30 Tage in S3 Standard‑IA für schnelle Restores; monatliche Fulls in Glacier Deep Archive für 12 Monate. Object Lock gilt über Versionen und Storage‑Klassen hinweg.

Datenmover: Applikationsbewusst, inkrementell, verifizierbar

• Postgres: Verwenden Sie pgBackRest oder WAL‑G, um Base‑Backups und WAL in den Staging Vault zu schicken, dann in den Locked‑Bucket zu replizieren. Konfigurieren Sie kontinuierliches Archiving auf ein „append‑only“‑Präfix, das eine Prod‑App‑Rolle weder auflisten noch löschen kann. Führen Sie tägliche Restore‑Verify‑Jobs aus, die eine temporäre Instanz starten, WAL bis zu einem Zielzeitpunkt einspielen, CHECKPOINT ausführen und einen Satz logischer Sanity‑Queries laufen lassen.
• MySQL: XtraBackup Full + Inkrementals, Binlog‑Shipping und tägliche Restore‑Verifikation.
• MongoDB: Kontinuierliches Oplog‑Capturing mit periodischem mongod‑Snapshot und Replay; nach dem Restore Kollections‑Counts und Hashes validieren.
• Blob‑Stores: Spiegeln Sie nicht stündlich den ganzen Bucket. Generieren Sie inhaltsadressierte Bundles mit Manifests und Hashes (z. B. zstd‑komprimierte Tarballs pro Partition/Tag), sodass Integrität verifizierbar und Restore parallelisierbar ist.
• Infra‑State: Terraform‑State Remote Backend mit Versionierung und Object Lock, plus regelmäßige Snapshots in den Locked‑Bucket. Bewahren Sie AMIs oder Image‑Snapshots für goldenes Basis‑OS im Backup‑Konto auf.
• Secrets: Nächtlicher Export und Neuverschlüsselung von Vault/Secrets Manager‑Einträgen ins Backup‑Konto unter dem Backup‑KMS. Nach dem Restore alles rotieren.

SaaS‑Abhängigkeiten: Automatisieren Sie die langweiligen Exporte

• GitHub: Spiegeln Sie Repos auf schreibgeschützte Backup‑Remotes im Backup‑Konto oder einen neutralen Gitea‑Mirror; exportieren Sie Issues und PR‑Metadaten wöchentlich.
• Slack: Enterprise Export API für öffentliche und private Channels; rechtliche Aufbewahrungsrichtlinie anwenden. Exporte unter Object Lock speichern.
• Google Workspace/Microsoft 365: Vault/Compliance‑Exporte für Mail und Drive nutzen; monatlich für nicht regulierte, wöchentlich für regulierte Teams.
• CI/CD: Build‑Cache und essentielle Artefakte snappen; Docker‑Image‑Digests und eine Kopie kritischer Images im Backup‑Registry vorhalten.

Zahlen, die zählen: Größe, Geschwindigkeit und Kosten

Veranschaulichen wir das mit einem realistischen Startup‑Profil:

• Primäre OLTP‑Postgres: 4 TB
• Objektdaten: 12 TB
• Infra/Config/Secrets/sonstiges: 4 TB Äquivalent
• Gesamt primär: ~20 TB

Angenommen 2 % tägliche Änderungsrate über die Datensätze und 40 % Kompression/Dedupe bei Backups.

• Speicher‑Footprint: ~8 TB Basis‑Full + ~400 GB/Tag Inkrementals. 30‑Tage‑Hot‑Fenster ≈ 8 TB + (0,4 TB × 30) = ~20 TB in S3 Standard‑IA.
• Monatliche Hot‑Storage‑Kosten (us‑east‑1): ~20 TB × $0,0125/GB ≈ $250. Verdoppeln für Cross‑Account‑Replikation ≈ $500. Puffer für Requests/Retrievals: nennen wir es $700–$900/Monat.
• Cold Archive: Monatlich ein Full in Glacier Deep Archive für 12 Monate: 8 TB × 12 ≈ 96 TB × ~$0,001/GB ≈ $100/Monat.
• Restore‑Durchsatz: Ziel 1 TB/Stunde pro Datenbank und 2–3 TB/Stunde für Objektdaten per parallelem Pull. Damit ist Ihre 4‑TB‑DB in 4 Stunden zurück; Blobs in ~4–6 Stunden.

Fazit: Eine ransomware‑resiliente Position für dieses Profil liegt deutlich unter 1–2 % einer Cloud‑Rechnung von $50–100K/Monat. Die wahren Kosten sind die ingenieurmäßige Disziplin, es zu üben.

Runbooks, die wirklich funktionieren (und wie man es beweist)

SLOs definieren, bevor Sie Schritte schreiben

• RPO: ≤ 15 Minuten für OLTP, 1 Stunde für Blobs.
• RTO: ≤ 4 Stunden bis zum nutzersichtbaren Service, ≤ 24 Stunden für Long‑Tail‑Daten.

Reihenfolge der Wiederherstellung

1. Eindämmung: IdP sperren, Break‑Glass rotieren. Prod‑Konten einfrieren. Forensik bewahren: Speicher, Disks und Logs in einen WORM‑Evidence‑Bucket schreiben, getrennt von Ihren Backup‑Buckets.
2. Fundamente zuerst neu aufbauen: Identity (Okta/AD), Netzwerk‑Primitiven, KMS im sauberen Konto.
3. Secrets und Images: Vault/Secrets Manager aus dem Backup hochziehen. Keys, Tokens und Datenbank‑Passwörter unmittelbar nach dem Restore rotieren.
4. Datenbanken: Base wiederherstellen, WAL/Binlogs bis zum RPO‑Ziel einspielen, Schema, Counts und Hashes validieren. Zunächst Read‑Only promoten, dann auf Primary umschalten.
5. Blob/Objektspeicher: Parallele Wiederherstellung nach Partition/Tag. Manifeste/Hashes validieren.
6. Apps/Dienste: Aus Golden Images deployen; unbekannte AMIs und unsignierte Container strikt blockieren.
7. Traffic: Stufenweiser Cutover hinter Feature Flag oder zunächst Read‑Only, dann voller Schreib‑Traffic.

Übungsrhythmus und Metriken

• Monatlich: 2‑stündiger Teil‑Restore‑Drill (DB‑Ausschnitt + ein Service) während der Geschäftszeiten. Erfolg = RPO/RTO erreicht, Daten validiert, Runbook‑Schritte mit Zeitstempeln versehen.
• Quartalsweise: Ganztägige, red‑team‑unterstützte Tabletop‑Übung + Live‑Restore in ein isoliertes VPC. Inklusive SaaS‑Export‑Imports. Erfolg = Nutzer können sich einloggen und eine echte Transaktion durchführen.
• Tracken: Median/95. Perzentil der Restore‑Zeit, Verifikationsfehler, fehlende Abhängigkeiten und Überraschungen. Ihr Board‑Report sollte ein Recovery‑SLO zeigen, das Sie tatsächlich einhalten.

Antipatterns, die Sie dieses Quartal abstellen

• „Der Provider hat uns“: EBS‑Snapshots, RDS‑Automated Backups und GKE‑PV‑Snapshots liegen im selben Control Plane. Sie sind bequeme Restores, aber kein Ransomware‑Schutz.
• Geteiltes KMS: Backups mit denselben Schlüsseln oder denselben Admins wie Prod zu verschlüsseln bedeutet einen gemeinsamen Blast Radius.
• „Wir verlassen uns auf Versioning“: S3‑Versionierung ohne Object Lock ist von einem Admin löschbar.
• Nur‑Hot‑Posture: Ein 30‑Tage‑Hot‑Fenster ohne Cold Archive lässt Sie für Langzeit‑Manipulationen offen.
• Unverifizierbare Blobs: Zufällige Objektkopien ohne Manifeste und Hashes machen Integritätsbehauptungen zur Show.

Was ist mit Offline?

Echte Air‑Gap ist weiterhin der Goldstandard. Für die meisten Startups ist das operativ überdimensioniert. Ein pragmatischer Mittelweg:

• Quartalsweiser Offline‑Snapshot: Quartalsweise Fulls auf verschlüsselte LUKS‑Volumes auf entnehmbaren SSDs exportieren, in sicherer Offsite‑Lagerung mit Chain‑of‑Custody‑Protokoll aufbewahren. Das ist Ihre Meteor‑Strike‑Kopie.
• Cloud‑Air‑Gap‑Variante: Ein Backup‑Konto mit Object Lock + SCPs, kein stehendes Netzwerk‑Peering zu Prod und Admin‑Auth, die nicht vom Corporate‑IdP föderiert ist. Es ist keine buchstäbliche Air‑Gap, aber sie durchtrennt die meisten Breach‑Ketten.

Rechtliches und Forensik, die Sie sich wünschen werden

• WORM‑Evidence: Audit‑Logs, EDR‑Telemetrie und Snapshots kompromittierter Systeme in einen separaten WORM‑Bucket mit 1‑jähriger Retention schreiben. Logisch und administrativ vom Backup‑Volumen trennen.
• 72‑Stunden‑Bereitschaft: Viele Regime verlangen Incident‑Meldung in 72 Stunden. Vorab Templates, Kontakte und eine faktenbasierte Checkliste dessen vorbereiten, was Sie zusichern können (Retention‑Fenster, Verschlüsselung at rest/in transit, Object‑Lock‑IDs).
• Third‑Party‑Coverage: Dokumentieren, welche Anbieter Sie für Kontinuität benötigen und wie deren WORM/Immutability‑Posture aussieht. Klauseln zu Backup‑Immutability und Recovery‑Drills in MSAs aufnehmen.

Open Source, Agents und überall Inkremente

Zwei Trends aus der Tech‑Woche sind erwähnenswert. Erstens werden Bibliotheken für inkrementelle Berechnung so gut, dass kontinuierliche Verifizierung günstig wird. Wenden Sie diese Denkweise auf Backups an: Rolling Checksums und Verifikations‑Queries inkrementell statt in großen Wochenendjobs berechnen. Zweitens verleitet die AI‑Tooling‑Welle dazu, Ops‑Disziplin an „Agents“ zu delegieren. Tun Sie es nicht. Nutzen Sie Agents, um Restore‑Manifeste zu generieren und Records zu validieren, aber halten Sie die Befugnis zu löschen oder entsperren aus ihren Händen heraus. Im Breach gehört die Entscheidungshoheit den Menschen.

Wer besitzt das und wie staffen Sie es?

• Eindeutige Verantwortlichkeit: Benennen Sie eine Staff+ SRE als Recovery Owner. Ihre Scorecard sind RPO/RTO‑SLOs und die Drill‑Erfolgsquote.
• Budget: Planen Sie 1–2 % der Cloud‑Kosten ein. Das meiste ist Storage; der Rest sind Drill‑Stunden.
• Operations‑Stunden: Nutzen Sie ein Nearshore‑Team, um monatliche Drills durchzuführen und Runbooks frisch zu halten. Mit 6–8 Stunden US‑Overlap ruinieren Drills nicht Ihre Rufbereitschaft, und Sie haben dennoch Abdeckung für Frühereignisse.

Praktische Startpunkte für die nächsten 30 Tage

1. Schalten Sie Object Lock ein in einem neuen, dedizierten Backup‑Konto. Wenn das nicht geht, erstellen Sie einen neuen Bucket; auf bestehenden lässt es sich nicht nachträglich aktivieren.
2. Separates KMS in diesem Backup‑Konto und alle Prod‑Principals entfernen. Break‑Glass dokumentieren.
3. Verdrahten Sie einen Datenmover End‑to‑End: z. B. pgBackRest Base + WAL in den Staging Vault, repliziert in den Locked‑Bucket. Beweisen Sie einen 4‑Stunden‑Restore auf einem 500‑GB‑Ausschnitt.
4. Exportieren Sie ein SaaS, auf das Sie sich verlassen (GitHub oder Slack), und speichern Sie es unter Object Lock. Zeit stoppen.
5. Planen Sie Ihren ersten Drill im Kalender ein und laden Sie die Rechtsabteilung ein. Wenn es nicht terminiert ist, ist es nicht real.

Trade‑offs und Realitätschecks

• Immutability vs. Agilität: Object Lock im Compliance Mode wird Ihnen wehtun, wenn Sie Fehler machen. Das ist der Punkt. Nutzen Sie Staging‑Buckets, um Fehler abzufangen, bevor gelockt wird.
• Kosten vs. RTO: Glacier ist günstig, aber langsam. Halten Sie ein 30‑Tage‑Hot‑Fenster in IA, um Ihr RTO zu treffen; Älteres geht ins Deep Archive.
• Sicherheit vs. Bedienbarkeit: Separate Konten und Schlüssel bedeuten mehr Zeremonie. Schreiben Sie die Zeremonie auf und üben Sie sie, sonst erfinden Sie im Incident Abkürzungen.
• Menschen vs. Tools: Die beste Architektur hilft nicht, wenn die einzige Person mit den Restore‑Schritten im Urlaub ist. Cross‑Training und Screen‑Capture‑Walkthroughs aufzeichnen.

Wenn Sie sonst nichts tun

Wenn Sie in diesem Quartal nur eine Sache tun, machen Sie einen Datensatz wirklich unveränderlich und testen Sie einen getimten Restore. Sie lernen in diesem einen Drill mehr als in zehn Tabletop‑Übungen. Und Sie werden Snapshots nie wieder mit Backups verwechseln.

Wichtigste Erkenntnisse

• Snapshots sind keine Backups. Wenn Prod‑IAM Ihren Recovery‑Pfad löschen kann, kann es ein Angreifer auch.
• Nutzen Sie Object Lock/Bucket Lock in einem separaten Konto mit separaten KMS‑Schlüsseln und SCPs.
• Setzen und messen Sie RPO ≤ 15 Minuten und RTO ≤ 4 Stunden für Ihren kritischen Pfad.
• Monatlich drillen (teilweise) und quartalsweise (vollständig). Wenn es nicht getestet ist, existiert es nicht.
• Sichern Sie SaaS‑Abhängigkeiten, nicht nur Infra: GitHub, Slack, Google/Microsoft, CI.
• Zielen Sie auf 1–2 % der Cloud‑Ausgaben für resiliente Backups; der Rest ist Disziplin.
• Benennen Sie einen Recovery Owner und nutzen Sie ein Nearshore‑Team, um Runbooks mit 6–8 Stunden Overlap aktuell zu halten.