57 Prozent aller Backup-Kompromittierungsversuche durch Ransomware-Gruppen sind erfolgreich. Nicht weil AES-256 gebrochen wird. Sondern weil Backup-Verschlüsselung als Schalter behandelt wird, nicht als System.
Das Backup ist vorhanden. Die Verschlüsselung ist aktiv. Die Wiederherstellung schlägt trotzdem fehl: Der Schlüssel liegt auf demselben Server, den die Angreifer als erstes kompromittiert haben.
AES-256 ist robust. Das ist keine Meinung, das ist kryptografischer Konsens: Keine praktikablen Brute-Force-Angriffe auf den Algorithmus selbst, De-facto-Standard von Regierungen über Banken bis zu Cloud-Anbietern weltweit. Nach aktuellem NIST-Stand gilt AES-256 auch gegenüber Quantencomputern als ausreichend sicher, für symmetrische Verschlüsselung ist keine Migration geplant.
Das Problem sitzt also nicht im Algorithmus. Es sitzt im System darum herum.
AES-256 schützt gespeicherte Daten vor physischem Diebstahl des Speichermediums. Es schützt Backup-Dateien vor direktem Lese-Zugriff ohne Schlüssel. Was es nicht schützt: kompromittierte Schlüssel, Insider-Zugriffe mit legitimen Rechten, schwache Passphrasen als Schlüsselbasis, und Daten, die unverschlüsselt zum Backup-Server übertragen werden, obwohl sie am Zielort verschlüsselt landen.
Hier liegt das häufigste Missverständnis: Wer Backups verschlüsselt speichert, aber den Übertragungsweg nicht absichert, exponiert die Daten im Transit. Wer TLS auf dem Transferweg nutzt, aber unverschlüsselt speichert, hinterlässt sie am Ziel offen. Encryption at Rest und Encryption in Transit sind keine Alternativen. Beide Schichten müssen gleichzeitig aktiv sein. Nur dann gibt es Ende-zu-Ende-Schutz.
Und selbst dann: Der entscheidende Faktor ist nicht, ob AES-256 aktiv ist. Es ist, wer den Schlüssel kontrolliert.
Das ist nicht Theorie. Das sind Muster aus realen Incident-Response-Berichten.
1. Der Schlüssel liegt neben den Daten. Die Backup-Software speichert die .key-Datei im selben S3-Bucket wie die verschlüsselten Backup-Files. Wer das Backup stiehlt, bekommt den Schlüssel automatisch dazu. AES-256 wird damit faktisch wertlos.
2. Hartcodierte Schlüssel in Automatisierungsskripten. Cron-Jobs, Ansible-Playbooks, Bash-Skripte: klassisches Anti-Pattern in automatisierten Backup-Pipelines. Der Schlüssel steht im Klartext in einer Konfigurationsdatei, die in einem Git-Repository liegt. Manchmal öffentlich.
3. Schwache Passphrasen als Schlüsselbasis. Im Dashboard steht: «AES-256 aktiviert». Dahinter steckt ein menschlich gewähltes Passwort. AES-256 mit einer achtstelligen Passphrase ist de facto deutlich schwächer als AES-256 mit einem kryptografisch zufällig generierten Schlüssel, auch wenn das Label im Dashboard identisch aussieht.
4. Fehlende Schlüsselrotation und kein Schlüssel-Backup. Schlüssel, die seit Jahren unverändert im Einsatz sind, erhöhen das Risiko bei einem Leak massiv. Und wenn der Schlüssel durch Systemausfall oder Personalwechsel verloren geht, sind alle damit verschlüsselten Backups dauerhaft unlesbar. Nicht wiederherstellbar. Weg.
Ein Fall, der diese Schwäche besonders klar illustriert: Bei einem EY-Datenleck lagen vier Terabyte SQL-Server-Backups unverschlüsselt öffentlich im Netz. Nicht weil die eingesetzte Software keine Verschlüsselung unterstützte, sondern weil die Funktion schlicht nicht aktiviert war. «Encryption available» ist nicht dasselbe wie «Encryption enabled». Und «Encryption enabled» ist noch immer nicht dasselbe wie «Encryption correctly implemented».
Moderne Ransomware-Gruppen wie Scattered Spider, LockBit oder BlackCat/ALPHV folgen einem dokumentierten Playbook. Initial Access → Privilege Escalation → Backup-Infrastruktur identifizieren → Backup-Verwaltungskonten kompromittieren → Backups löschen oder verschlüsseln → erst dann: Produktivdaten angreifen.
Die Reihenfolge ist kein Zufall. Wer das Backup kontrolliert, kontrolliert die Verhandlung.
Laut einer Sophos-Studie waren 57 Prozent aller Backup-Kompromittierungsversuche durch Ransomware-Gruppen erfolgreich. Bei Unternehmen, deren Backups kompromittiert wurden, verschlüsselten die Angreifer in 85 Prozent der Fälle auch die Produktivdaten, verglichen mit nur 52 Prozent bei Unternehmen mit intakten Backups. Die Gesamtkosten der Recovery lagen laut derselben Sophos-Erhebung achtmal höher als bei Unternehmen, die ihre Backups schützen konnten.
Wer Backup-Verschlüsselungsschlüssel mit denselben Admin-Rechten verwaltet wie die Produktionssysteme, liefert Angreifern den Schlüssel zum Gesamtsystem mit. Genau das wissen die Angreifer, und sie suchen gezielt danach.
Der Schutz durch Verschlüsselung greift erst, wenn Schlüssel und Daten getrennt sind. Wenn Zugriffsrechte auf das Key Management strikt vom Produktivbetrieb isoliert sind. Wenn Backupdaten ausgelagert werden und administrative Zugriffsrechte minimiert sind.
Verschlüsselung ist kein Schalter, sie ist ein System. Diese vier Massnahmen machen den Unterschied zwischen Schein und Schutz:
1. Beide Schichten aktiv. Encryption at Rest und Encryption in Transit gleichzeitig. Kein Entweder-oder. Standard für den Übertragungsweg ist TLS 1.2 oder 1.3.
2. Dediziertes Key Management System (KMS). AWS KMS, Azure Key Vault, HashiCorp Vault: Ein KMS trennt Schlüssel physisch und logisch von den Backup-Daten. Alle Schlüsselzugriffe werden protokolliert. Schlüssel verlassen das System nicht als Klartext. Für die meisten KMU sind Cloud-KMS-Lösungen mit Customer-Managed Keys (CMK) der verhältnismässige Einstieg.
3. Customer-Managed Keys. «Encrypted by provider» bedeutet nicht Ende-zu-Ende-verschlüsselt. Wenn der Backup-Anbieter die Schlüssel hält und ein Angreifer den Anbieter-Account kompromittiert, sind die Daten trotz aktivierter Verschlüsselung zugänglich. Entscheidend ist: Wer kontrolliert den Schlüssel?
4. Schlüsselrotation und gesichertes Key-Backup. Beides ist keine Option, beides ist Pflicht. Fehlende Rotation erhöht das Risiko bei einem Leak massiv. Ein fehlendes Key-Backup bedeutet bei Schlüsselverlust dauerhaften Datenverlust. Immutable Backups ergänzen diese Massnahmen: Sie schützen den Backup-Bestand auch dann, wenn Schlüssel kompromittiert werden.
Zum Performance-Einwand: AES-256-Beschleunigung ist in modernen CPUs über AES-NI hardwareseitig implementiert. Bei aktueller Hardware ist der Performance-Impact gering bis vernachlässigbar. Das Argument «zu aufwändig» greift technisch nicht mehr.
Regulatorisch ist das alles keine Kür. Die DSGVO (Art. 32) nennt Verschlüsselung explizit als geeignete technische Massnahme zum Schutz personenbezogener Daten. Das nDSG, in Kraft seit 1. September 2023, stellt vergleichbare Anforderungen. Und die NIS2-Richtlinie geht weiter als beide: Art. 21 Abs. 2(h) fordert nicht bloss «Verschlüsselung aktivieren», sondern ein dokumentiertes Schlüsselmanagement mit definierten Prozessen für Generierung, Rotation, Widerruf und Protokollierung. Für Schweizer Unternehmen mit EU-Kundschaft oder EU-Niederlassung gilt das direkt. Für alle anderen ist es der Stand der Technik, an dem sich Auditoren orientieren.
AES-256 ist nicht das Problem. Die Implementierung ist das Problem, und die lässt sich lösen.
Drei Punkte, die nach diesem Artikel feststehen sollten:
Für Unternehmen, die Verschlüsselung und Key Management nicht intern stemmen wollen (und das ist keine Frage der Grösse, sondern der Prioritäten): Backup ONE Managed Backup erfüllt diese Anforderungen out-of-the-box. Datenhaltung ausschliesslich in der Schweiz, nDSG- und DSGVO-konform, mit Customer-Managed Keys und dokumentierten Key-Management-Prozessen. Der Schlüssel bleibt dort, wo er hingehört: unter Ihrer Kontrolle.
Das sind weitere Beiträge, die Sie interessieren könnten.
Zur Blogübersicht