Backup und Disaster Recovery: Ransomware-sichere Datensicherung

“Wir haben Backups.” - Das sagen fast alle Unternehmen. Aber: Werden die Backups regelmäßig auf Wiederherstellbarkeit getestet? Sind sie vom primären Netzwerk getrennt (damit Ransomware sie nicht erreicht)? Wurde jemals ein vollständiges Disaster-Recovery-Szenario durchgespielt?

Laut Veeam Data Protection Trends Report 2024 hatten 76% der Unternehmen im letzten Jahr mindestens einen Ransomware-Angriff. Von denen die Lösegeld zahlten, konnten trotzdem 24% ihre Daten nicht vollständig wiederherstellen. Die häufigste Ursache: Backups waren ebenfalls verschlüsselt.

Die Evolution der Backup-Regeln

Klassisch: 3-2-1-Regel

3 Kopien der Daten
2 verschiedene Medientypen (z.B. Disk + Tape)
1 Offsite-Kopie (außerhalb des Unternehmens)

Die 3-2-1-Regel ist ein guter Start - aber für Ransomware-Schutz nicht ausreichend, weil:

• Alle 3 Kopien können vom selben Ransomware-Angriff erreicht werden
• Offsite muss nicht online sein um sicher zu sein

Modern: 3-2-1-1-0-Regel

3 Kopien der Daten
2 verschiedene Medientypen
1 Offsite-Kopie
1 Air-Gapped / Offline / Immutable Kopie  ← NEU
0 Fehler - verifikationsfähige Backups (regelmäßige Restore-Tests)  ← NEU

Das “1 Offline/Immutable” ist der entscheidende Zusatz für Ransomware-Resilienz.

Immutable Backups: Was bedeutet das?

Immutable (unveränderlich) bedeutet: Einmal geschrieben, kann das Backup nicht mehr geändert oder gelöscht werden - auch nicht von Admins oder Ransomware.

Implementierungsoptionen

Object Storage mit WORM (Write Once Read Many):

AWS S3 Object Lock:
  Governance Mode: Nur Root-User kann löschen (gut)
  Compliance Mode: Niemand kann vor Ablauf löschen (besser für kritische Backups)

Azure Blob Storage Immutability Policies:
  Time-based Retention: Daten unveränderlich für X Tage
  Legal Hold: Bis explizit freigegeben

Wasabi S3-kompatibel (günstiger als AWS):
  Object Lock aktivierbar, sehr gutes Preis-Leistung

Tape / Offline-Storage:

• Klassisches Tape Offline (LTFS, LTO-9): physisch getrennt → Ransomware kommt nicht ran
• Moderne Tape-Libraries mit Air Gap: automatisches Trennen nach Backup

Dedizierte Backup-Appliances mit Immutability:

• Dell PowerProtect (PowerScale, EMC DataDomain)
• HPE StoreOnce Catalyst
• Veeam Hardened Repository (Linux mit immutable flags)

Backup-Architekturen für verschiedene Unternehmensgrößen

KMU (< 50 Mitarbeiter)

Primäre Daten: NAS im Büro
                ↓
Backup-Job:    Veeam/Acronis → lokale Backup-NAS (täglich, 30 Tage)
                ↓
Offsite:       Automatisches Backup in Cloud (Wasabi/Backblaze B2)
               Immutable Object Lock aktiviert

Kosten: ~200 €/Monat für 5 TB Cloud-Storage + Backup-Software

Mittelstand (50-500 Mitarbeiter)

Primäre Daten:  SAN/NAS + VMware-VMs + M365
                ↓
Backup Tier 1:  Veeam → Hardened Linux Repository (immutable, 30 Tage)
                         im selben Rechenzentrum - fast Recovery
Backup Tier 2:  Veeam → Backup-Standort (20km entfernt, täglich, 90 Tage)
Backup Tier 3:  Azure/AWS S3 Object Lock (wöchentlich, 1 Jahr)

M365 Backup:   Veeam for M365 / Acronis Cyber Protect Cloud
               (E-Mails, SharePoint, Teams, OneDrive)

Enterprise (> 500 Mitarbeiter)

Multi-Site mit synchroner Replikation für Tier-1-Daten
Backup mit Veeam Enterprise / Commvault / Zerto
Air-Gapped Tape-Library für kritische Daten (jährlich, 10 Jahre)
Dedicated Recovery Site / Cloud DR (Azure Site Recovery, Zerto)
Separate Backup-AD-Infrastruktur (Ransomware auf Produktions-AD kompromittiert nicht Backup-AD)

Microsoft 365 Backup - Oft vergessen!

Microsoft garantiert nur Verfügbarkeit - kein echtes Backup:

Standard-Retention in M365:
  Gelöschte Mails: 30-90 Tage wiederherstellbar
  Gelöschte Teams-Nachrichten: 30 Tage
  SharePoint-Versioning: 500 Versionen oder 30 Tage

Nicht abgedeckt:
  - Ransomware die SharePoint/OneDrive verschlüsselt
  - Böswilliges Löschen durch Insider
  - Accidental Mass-Deletion
  - Daten nach Ablauf der Retention-Periode

M365-Backup-Lösungen:

• Veeam Backup for Microsoft 365
• Acronis Cyber Protect Cloud
• Druva inSync
• NAKIVO for M365

Recovery-Tests: Das Wichtigste wird am häufigsten vergessen

Ungetestete Backups sind wertlos. Aus verschiedenen Gründen scheitern Backups bei der Wiederherstellung:

• Backup-Job lief fehl, niemand prüfte Alerts
• Restore-Tool ist nicht installiert auf Recovery-System
• Backup enthält nur inkrementelle Daten ohne Basis-Backup
• Festplatte ist kaputt (Bit Rot bei Tapes)
• Recovery-Prozess wurde nie dokumentiert

Empfohlene Test-Frequenz:

Backup-Typ	Restore-Test-Frequenz
Kritische Systeme (DC, ERP)	Monatlich
Wichtige Systeme (File Server)	Quartalsweise
Standard-Systeme	Halbjährlich
Vollständiger DR-Test	Jährlich

Automatisierter SureBackup (Veeam):

Jeden Morgen: Veeam startet Backup automatisch in isolierter Sandbox
Boot-Test: System startet erfolgreich?
Application-Test: Datenbank antwortet auf Queries?
Ergebnis: E-Mail mit "Backup OK" oder "Restore fehlgeschlagen"

Disaster Recovery: Mehr als Backup

Disaster Recovery (DR) ist der Prozess zur Wiederherstellung nach einem Komplettausfall:

Recovery Time Objective (RTO) und Recovery Point Objective (RPO)

Unternehmen A definiert:
  ERP-System: RTO = 4 Stunden, RPO = 1 Stunde

Bedeutet:
  Nach Ausfall: System muss in max. 4 Stunden wieder laufen
  Datenverlust: Maximal 1 Stunde (stündliche Backups nötig)

Technische Umsetzung:
  Synchrone Replikation: RPO = ~0 (kein Datenverlust), teuer
  Stündliche Snapshots: RPO = 1 Stunde, günstig
  Tägliches Backup: RPO = 24 Stunden, sehr günstig

DR-Szenarien für Ransomware

Szenario: Ransomware verschlüsselt 80% der Systeme

Frage 1: Welche Systeme zuerst wiederherstellen?
  Priorität 1: Active Directory (alles andere hängt davon ab)
  Priorität 2: VPN + E-Mail (Kommunikation und Remote-Zugang)
  Priorität 3: ERP/Kerngeschäft

Frage 2: Aus welchem Backup?
  → Backup vor Ransomware-Infektion (oft Wochen früher!)
  → Analyse nötig: Wann war "clean state"?

Frage 3: In welche Umgebung wiederherstellen?
  → NICHT in infizierte Umgebung
  → Saubere, frische Infrastruktur aufbauen
  → Dann aus Backup restoren

Frage 4: Dauert das?
  100 Server × 2 Stunden Restore = 200 Stunden / 10 parallele Restores = 20 Stunden
  → RTO-Planung muss realistische Restore-Zeiten berücksichtigen

Backup-Checkliste: Audit Ihrer Backup-Strategie

□ 3-2-1-1-0-Regel implementiert?
□ Mindestens eine Immutable/Offline-Kopie vorhanden?
□ M365 (E-Mail, SharePoint, Teams) separat gesichert?
□ Backup-Infrastruktur vom primären Netzwerk getrennt?
  (Eigene AD-Domäne, eigene Credentials für Backup-Zugang)
□ Backup-Jobs täglich auf Erfolg überwacht?
□ Restore-Tests quartalsweise durchgeführt und dokumentiert?
□ RTO und RPO für kritische Systeme definiert?
□ Disaster Recovery Plan dokumentiert und bekannt?
□ Jährlicher DR-Test durchgeführt?
□ Aufbewahrungsfristen (GoBD: 10 Jahre für Buchungsbelege)?

Compliance-Anforderungen

GoBD: 6-10 Jahre steuerrelevante Unterlagen. Backup muss unveränderliche Aufbewahrung gewährleisten (WORM oder revisionssichere Archivierung).

BSI IT-Grundschutz CON.3: Detailliertes Datensicherungskonzept als Anforderung.

NIS2 Art. 21: Business Continuity und Backup explizit als Pflichtmaßnahme.

ISO 27001 A.8.13: Datensicherung - regelmäßige Tests der Wiederherstellbarkeit.

DSGVO Art. 32: Wiederherstellbarkeit personenbezogener Daten als technische Maßnahme.