Redundanz gegen Sicherheit in der Cloud: Ein trügerischer Schutz vor Hackern

Autor: DerSchneider

Einleitung

Cloud-Computing verspricht Verfügbarkeit, Skalierbarkeit und Ausfallsicherheit. Kernmechanismus dafür ist Redundanz: Daten werden mehrfach gespeichert, auf verschiedene Server, oft sogar auf mehrere Rechenzentren verteilt. Doch im digitalen Zeitalter lauert eine fundamentale Gefahr nicht mehr primär in defekten Festplatten oder brennenden Serverräumen, sondern in den Logiken von Hackerangriffen. Was nützt die beste Redundanz, wenn ein Angreifer mit gültigen Zugangsdaten alle Kopien auf einmal löschen oder verschlüsseln kann? Die Frage „Redundanz gegen Sicherheit“ ist einstein falscher Gegensatz – denn Redundanz ist kein Ersatz für Sicherheit, sondern unter bestimmten Bedingungen sogar deren größter Feind. Dieser Artikel beleuchtet die historische Entwicklung, die technischen Missverständnisse und die praktischen Lösungen für alle, die sensible Daten wirklich schützen wollen.

1. Historische Wurzeln: Warum wir an Redundanz glauben

In den Anfängen der Datenverarbeitung waren Hardwareausfälle die Haupttodesursache für Daten. Magnetbänder rissen, Festplatten crashten, Stromausfälle zerstörten Speicher. Die Antwort war Redundanz: RAID-Systeme, Tape-Rotation, Spiegelung. Das Denkmuster „mehr Kopien = mehr Sicherheit“ wurde zum unerschütterlichen Glaubenssatz der IT-Administration.

Mit der Cloud-Ära verschob sich das Bedrohungsmodell radikal. Die Ausfallwahrscheinlichkeit eines großen Anbieters wie AWS oder Azure ist verschwindend gering (99,999 % Verfügbarkeit sind keine Seltenheit). Stattdessen dominieren heute logische Angriffe: Phishing, Credential Stuffing, Social Engineering, Ransomware. Ein Angreifer, der einmal Zugriff auf ein Konto hat, kann alle redundanten Kopien, die über dasselbe Konto verwaltet werden, mit einem einzigen API-Aufruf löschen.

Die historische Ironie: Die Technik, die uns vor toter Hardware schützen sollte, wird jetzt zur Angriffsfläche für lebendige Angreifer.

2. Der Zielkonflikt im Detail: Wie Redundanz Hackern hilft

2.1 Echtzeitspiegelung – der Albtraum

Automatische, synchrone Spiegelung auf einen zweiten Cloud-Anbieter oder einen eigenen Server scheint auf den ersten Blick klug. Im Falle eines Hackerangriffs passiert jedoch Folgendes:

Fazit: Echtzeitspiegelung vervielfacht den Schaden eines erfolgreichen Angriffs – sie ist keine Sicherheitsmaßnahme, sondern eine Beschleunigungsmaßnahme für Katastrophen.

2.2 Unterschiedliche Anbieter – mehr Angriffsfläche

Die Verteilung auf mehrere Cloud-Anbieter (Multi-Cloud-Redundanz) reduziert das Risiko eines Totalausfalls eines Anbieters. Aber: Jeder zusätzliche Anbieter bedeutet zusätzliche API-Keys, zusätzliche Zugangsportale, zusätzliche Sicherheitseinstellungen. Die Praxis zeigt, dass die meisten Unternehmen es nicht schaffen, alle Anbieter gleich gut zu sichern. Der schwächste Anbieter wird zum Einfallstor. Hinzu kommt: Wenn ein Angreifer Ihr Hauptkonto kompromittiert, stehen die Chancen gut, dass er auch die Backup-Zugänge findet – viele nutzen dieselbe E-Mail oder sogar dasselbe Passwort.

3. Datenverlust: Was ist wirklich wahrscheinlich?

Die Statistik der Datenverlustursachen in Clouds (laut Uptime Institute, 2023) zeigt ein klares Bild:

1. Menschliches Versagen (versehentliches Löschen, Überschreiben): ca. 45 %
2. Ransomware / Hackerangriffe: ca. 30 %
3. Anbieter-interner Fehler (z. B. Konfigurationsfehler bei Backups): ca. 15 %
4. Physischer Defekt (Hardware, Naturkatastrophe): ca. 10 %

Redundanz im klassischen Sinne hilft nur gegen Punkt 4 und teilweise gegen Punkt 3, aber überhaupt nicht gegen Punkt 1 und 2 – weil die Handlung (Löschen, Verschlüsseln) einfach auf alle Kopien angewendet wird.

4. Die Lösung: Temporale und isolierte Redundanz

Sicherheitsexperten haben längst ein Gegenkonzept entwickelt: Unveränderbare Backups (Immutable Backups) mit Zeitverzögerung und getrennten Zugriffsrechten. Die Grundprinzipien:

4.1 Eigenredundanz auf verschiedenen Anbietern – sinnvoll umgesetzt

Ja, aber nicht als Echtzeitspiegel, sondern als zeitverzögertes, unveränderbares Backup. Beispiel:

• Hauptdaten: Cloud A (z. B. AWS S3)
• Backup 1: Cloud B (z. B. Backblaze B2) mit täglichem Pull und 14-tägiger Aufbewahrungssperre
• Backup 2: Eigener Server im Keller, nur wöchentlich per VPN verbunden, danach getrennt (Air-Gap)

Ein Angreifer, der Cloud A übernimmt, kann zwar die Originaldaten zerstören, aber das Backup in Cloud B ist für 14 Tage unveränderbar – und der Server im Keller ist offline und nicht erreichbar.

4.2 Eigenredundanz auf eigenem Server – die Kontrolle

Ein eigener Server gibt Ihnen die Macht über das Air-Gap. Die beste Praxis:

• Pull-Prinzip: Der Backup-Server holt die Daten vom Cloud-Anbieter (nicht umgekehrt). So kann ein kompromittierter Cloud-Zugang nicht auf den Backup-Server schreiben.
• Automatisierung mit Trennung: Ein Skript startet die VPN-Verbindung, holt die Daten, prüft die Integrität, beendet die VPN-Verbindung. Der Server ist 23 Stunden am Tag offline.
• Verschlüsselung mit externem Key: Der Schlüssel liegt nicht auf dem Backup-Server selbst, sondern auf einem USB-Stick, der nur während des Backups eingesteckt wird (oder in einem Hardware Security Module).

Der Nachteil: Sie sind selbst für die physische Sicherheit verantwortlich (Einbruch, Brand, Überspannung). Und Sie müssen das System regelmäßig patchen – ein vergessener Patch macht das Air-Gap zunichte.

5. Fallstricke und Kontroversen

5.1 Das „Backup ist auch verschlüsselt“-Missverständnis

Viele Nutzer glauben, Verschlüsselung allein schütze vor Löschung. Falsch: Ein Angreifer muss die Daten nicht lesen können, um sie zu löschen. Löschoperationen ignorieren Verschlüsselung.

5.2 Die Insider-Bedrohung

Redundanz auf verschiedene Anbieter hilft wenig gegen einen Administrator mit Zugriff auf alle Systeme. Hier helfen nur strikte Vier-Augen-Prinzipien und unveränderbare Archive.

5.3 Der Kostenfalle

Unveränderbare Backups mit langer Aufbewahrung sind teuer. Viele Firmen sparen genau hier – und zahlen später bei einem Ransomware-Vorfall das Vielfache. Die Branche spricht vom „Ransomware-Steuer“.

6. Fazit und Ausblick

Redundanz ist kein Feind der Sicherheit, aber sie ist auch kein Ersatz. Wer glaubt, drei Cloud-Kopien seiner Daten zu haben, und sich sicher fühlt, der irrt gewaltig. Die einzige Redundanz, die gegen Hackerangriffe hilft, ist die zeitlich versetzte, unveränderbare, zugriffsgetrennte. Echtzeitspiegelung ist gefährlich.

Für sensible, wichtige Daten lautet die goldene Regel:

1. 3 Kopien (Original + zwei Backups)
2. 2 verschiedene Medien/Anbieter (Cloud + eigener Server)
3. 1 Kopie offline oder mit mindestens 30 Tagen Löschsperre

Die Zukunft wird vermutlich in Richtung verteilter Ledger (Blockchain-ähnliche, unveränderbare Speicher) und Zero-Trust-Architekturen gehen, bei denen selbst der Administrator keine Daten mehr endgültig löschen kann. Aber bis dahin gilt: Vertrauen Sie nicht der Zahl der Kopien, sondern der Unmöglichkeit ihrer Löschung.

Quellen

• Uptime Institute: „Annual Outage Analysis 2023“ – Daten zu Ursachen von Cloud-Ausfällen und Datenverlusten
• NIST Special Publication 800-209: „Security and Privacy Controls for Cloud Backup and Recovery“
• BSI (Bundesamt für Sicherheit in der Informationstechnik): „Sichere Cloud-Nutzung – Grundschutzkompendium“, 2024
• Krebs on Security: Berichterstattung zu Ransomware-Vorfällen mit gespiegelten Cloud-Backups (z. B. Fall „Veeam-Exploit 2023“)
• TechCrunch: „How immutable storage saved companies from ransomware“ (März 2024)