HYCU erläutert Notwendigkeit und Ansatz

Amazon S3 war 2006 Vorreiter im Bereich Cloud-Objektspeicherung im Internet. Seitdem hat es sich von einem skalierbaren Speicherdienst zu einer Kerninfrastruktur für moderne Anwendungen entwickelt. Es ist nicht mehr nur ein Ziel für archivierte Daten. Heute verlassen sich Unternehmen darauf, um KI-Pipelines, Echtzeitanalysen und Cloud-native Workloads zu betreiben. Da mittlerweile hochwertige, geschäftskritische Daten über Amazon S3 fließen, ist die Sicherung dieser Daten wichtiger denn je.

Native Funktionen gewährleisten keine umfassende Datensicherung

Amazon S3 bietet hohe Ausfallsicherheit und operative Sicherheitsvorkehrungen, wie z. B. eine Objekt-Ausfallsicherheit von 99,999999999 Prozent über mehrere Verfügbarkeitszonen hinweg, Bucket-Versionierung mit Löschmarkierungen, Replikation und Lebenszyklusrichtlinien. Hinzukommen optionale Kontrollen wie Amazon S3 Object Lock und MFA Delete. Diese Funktionen tragen dazu bei, Hardwareausfälle zu minimieren und alltägliche Fehler zu reduzieren. Was sie jedoch nicht garantieren, ist die Ausfallsicherheit, wenn die Steuerungsebene kompromittiert wird, beispielsweise durch gestohlene Anmeldedaten, zu großzügige Automatisierung, falsch angewandtes Identity Access Management (IAM) oder Richtlinien oder groß angelegte Bedienungsfehler. Da viele Funktionen den aktuellen Zustand widerspiegeln, können sie Löschungen, Beschädigungen oder Richtlinienänderungen genauso schnell weitergeben wie einen fehlerfreien Zustand. Selbst wenn native Funktionen aktiviert sind, können wichtige Daten dennoch verloren gehen, oft ohne Vorwarnung, bis es zu spät ist.

Fünf Gründe für ein Backup von Amazon S3

Die folgenden fünf Gründe zeigen, warum Unternehmen ein unveränderliches, separat verwaltetes Backup für ihre Amazon S3-Daten benötigen.  

1. Sicherheitsvorfälle

Amazon S3 speichert oft riesige Mengen wertvoller Geschäftsdaten. Wenn jedoch Zugriffskontrollen missbraucht oder Anmeldedaten kompromittiert werden, kann dies schwerwiegende Folgen haben. Angreifer können Daten löschen, Schutzeinstellungen deaktivieren oder Änderungen vornehmen, die sich auf ganze Umgebungen auswirken. Selbst mit integrierten Sicherheitsvorkehrungen wie Object Lock bleiben Umgebungen ohne strengere Einstellungen anfällig für Manipulationen und potenziellen Datenverlust.

So berichteten Forscher im Januar 2025 über eine Ransomware-Kampagne namens Codefinger, bei der die serverseitige Verschlüsselung mit vom Kunden bereitgestellten Schlüsseln (SSE-C) von Amazon S3 missbraucht wurde. Nach dem Diebstahl gültiger AWS-Anmeldedaten verwendeten die Angreifer Standard-S3-Aufrufe, um Daten zu überschreiben und mit Schlüsseln neu zu verschlüsseln, die nur sie kontrollierten. Dabei wurde keine Schwachstelle von AWS ausgenutzt, sondern es wurden nach der Kompromittierung der Anmeldedaten native Funktionen missbraucht. Das Ergebnis war ein sofortiger Verlust des Zugriffs für die Opfer, da AWS keine vom Kunden bereitgestellten Schlüssel speichert. In mehreren Berichten wurde auch die Verwendung von Lebenszykluseinstellungen zur Planung einer schnellen Löschung erwähnt, wodurch der Druck zur Zahlung erhöht wurde. Die öffentliche Bekanntgabe begann im Januar 2025, gefolgt von Leitlinien zur Erkennung und Blockierung unbeabsichtigter SSE-C-Aktivitäten.

2. Administrative Fehlkonfigurationen

Nicht jeder Datenverlust wird durch eine externe Bedrohung verursacht. Oft handelt es sich um menschliches Versagen. Eine falsch eingegebene Regel oder eine übersehene Einstellung kann zu versehentlichen Löschungen, überschriebenen Dateien oder Speicherübergängen führen, die Workflows unterbrechen. Ohne Versionierung oder Unveränderlichkeit können kleine Fehler schnell zu irreparablen Schäden führen.

Der Amazon S3 Bucket eines US-amerikanischen Gesundheitsdienstleisters war falsch konfiguriert, sodass ein Zugriff ohne ordnungsgemäße Authentifizierung möglich war. Ein unbefugter Akteur nutzte diesen Zugriff, um Daten herunterzuladen und dann Löschvorgänge für den Bucket durchzuführen, wodurch medizinische Daten von etwa 3,25 Millionen Personen ohne Wiederherstellungsmöglichkeit gelöscht wurden. Der Vorfall wurde im Januar 2021 öffentlich bekannt gegeben. Der Bucket verfügte weder über Versionierung noch über Objektsperren, sodass nach dem Löschen der Objekte keine native Möglichkeit bestand, die neuesten Kopien wiederherzustellen. Der Anbieter musste die Daten aus anderen Systemen wiederherstellen. Dieser Vorfall ist ein Beispiel dafür, wie eine falsch konfigurierte Richtlinie zu einem dauerhaften Datenverlust führen kann.

3. Durchsetzung von Compliance und Governance

Die Erfüllung von Compliance-Anforderungen erfordert oft strenge Datenkontrollen wie Aufbewahrungsregeln, gesetzliche Aufbewahrungspflichten und Unveränderbarkeitseinstellungen. Diese Maßnahmen sind für die Audit-Bereitschaft und den langfristigen Schutz von entscheidender Bedeutung, können jedoch zu operativen Reibungsverlusten führen. Lange Aufbewahrungsfristen können die Speicherkosten erhöhen, und starre Richtlinien können die Bereinigung verlangsamen oder die Wiederherstellung beeinträchtigen.

Ein auf AWS beschriebener Vorfall schilderte, wie ein Ingenieurteam eine Lebenszyklusregel hinzufügte, um Logs zu löschen, die älter als 30 Tage waren, um die Speicherkosten zu senken. Die Regel passte unbeabsichtigt auf Log-Prefixes, die eine Aufbewahrungsdauer von 90 Tagen erforderten. Da Lebenszyklusregeln für bestehende Objekte gelten, stellte Amazon S3 diese Logs zur Löschung in die Warteschlange und entfernte sie im nächsten Zyklus. Infolgedessen verlor das Unternehmen Monate an Audit-Historie, hatte Lücken in der Analyse und musste die Transparenz aus sekundären Systemen wiederherstellen. Eine falsch konfigurierte Richtlinie führte zu einem dauerhaften Datenverlust und einem erheblichen operativen Rückschlag.

4. Betriebs- und Plattformausfälle

Selbst in gut verwalteten Umgebungen kann es zu Störungen kommen. Fehlgeschlagene Uploads, Verarbeitungsverzögerungen oder falsch konfigurierte Automatisierungen können Daten beschädigen oder den Zugriff darauf blockieren. In seltenen Fällen können Probleme auf der Plattformseite oder toolbezogene Fehler das Problem noch verschlimmern. Wenn mehrere Systeme gleichzeitig von Amazon S3 abhängig sind, können selbst kleine Störungen erhebliche Auswirkungen haben.

Bei einem viel beachteten weltweiten Ausfall am 20. Oktober 2025 führten interne AWS-Netzwerkausfälle und DNS-Probleme zu kaskadierenden Dienstunterbrechungen bei vielen Diensten, darunter auch S3. Obwohl AWS angab, dass kein Datenverlust bestätigt wurde, kam es bei vielen Benutzern zu fehlgeschlagenen Uploads, Zeitüberschreitungen und Verzögerungen beim Zugriff auf oder beim Schreiben von Daten. Dies erhöhte das Risiko eines potenziellen Datenverlusts für Systeme, die keine Schreibvorgänge abschließen oder unvollständige Transaktionen wiederherstellen konnten.

5. Gefährdung der Lieferkette durch den Cloud-Anbieter

Jedes Unternehmen ist Risiken in der Lieferkette ausgesetzt, und Hyperscale-Cloudprovider bilden da keine Ausnahme. Probleme, die AWS oder seine vorgelagerten Abhängigkeiten betreffen, können sich ausweiten und viele Kunden beeinträchtigen, was zu Störungen beim Datenzugriff führen kann, selbst wenn die Konfiguration der Konten korrekt ist. Zu den Auswirkungen können fehlgeschlagene Ver- oder Entschlüsselungsvorgänge (bei KMS-abhängigen Workloads), blockierter Zugriff auf Buckets, stockende Replikation oder Lebenszyklusverarbeitung sowie eine allgemeine Instabilität der Steuerungsebene gehören.

Im Juli 2025 gab AWS bekannt, dass die Amazon Q Developer VS Code-Erweiterung Version 1.84.0 kurzzeitig mit bösartigem Code ausgeliefert wurde, nachdem ein Angreifer ein zu freizügiges GitHub-Token verwendet hatte, um Änderungen in die Build-Pipeline zu übertragen. AWS zog die Version zurück und veröffentlichte eine korrigierte Version. Der injizierte Code war darauf ausgelegt, lokale Dateien zu löschen und Cloud-Ressourcen, einschließlich S3-Buckets, zu entfernen. Dies hätte zu einem weitreichenden Datenverlust führen können, wenn er in großem Umfang auf allen installierten Erweiterungen ausgeführt worden wäre. AWS widerrief die Anmeldedaten, entfernte den eingeschleusten Code und meldete, dass keine Kundenressourcen betroffen waren. Dieser Vorfall zeigt, wie selbst der Fehler eines vertrauenswürdigen Anbieters zu destruktiven Zugriffen innerhalb gut konfigurierter Kundenumgebungen führen kann.

Unveränderliche, logisch isolierte Backups für eine schnelle Wiederherstellung

Wenn es einen Ansatz gibt, der die operative Ausfallsicherheit in den oben genannten Szenarien gewährleistet, dann ist es ein unveränderliches, logisch isoliertes Backup mit unabhängigen Richtlinien und Point-in-Time-Wiederherstellung. „Logisch isoliert” bedeutet, dass Backups in einem separaten AWS-Konto mit eindeutigen Anmeldedaten und Rollen gespeichert sind, unveränderlich sind oder zeitbasiert aufbewahrt werden, sodass Änderungen in der Produktion die Backup-Kopien nicht verändern oder löschen können. Selbst wenn der Produktionszugriff oder die Konfiguration manipuliert wird, bleiben diese Kopien intakt und stellen einen sauberen, bekannten und bewährten Wiederherstellungspfad in großem Maßstab bereit.

HYCU bietet in Zusammenarbeit mit Dell kostengünstige, Ransomware-resistente Backups für Amazon S3, damit Unternehmen selbst in den schwierigsten Szenarien sicher wiederherstellen können. Hierbei ist DDVE auf AWS als primäres Backup-Ziel für Amazon S3-Daten vorgesehen. Für BCDR (Business Continuity Disaster Recovery) müssen Unternehmen eine unveränderliche sekundäre Kopie von DDVE auf AWS zu DDVE auf Google Cloud oder Azure replizieren. Dieser Ansatz hilft, die Cloud-übergreifenden Ausgangs- und Speicherkosten zu minimieren und gleichzeitig die damit verbundenen Risiken durch Probleme mit Providern und regionale Abhängigkeiten zu reduzieren.