5 Gründe, warum Sie Ihr Amazon S3 sichern sollten

Amazon S3 leistete 2006 Pionierarbeit bei der Cloud-Objektspeicherung im Internet-Maßstab. Seitdem hat es sich von einem skalierbaren Speicherdienst zu einer zentralen Infrastruktur für moderne Anwendungen entwickelt. Er ist nicht mehr nur ein Ziel für archivierte Daten. Heute verlassen sich Unternehmen darauf, um KI-Pipelines, Echtzeit-Analysen und Cloud-native Workloads zu betreiben.

Da hochwertige, geschäftskritische Daten heute über Amazon S3 fließen, stand der Schutz dieser Daten noch nie so sehr auf dem Spiel.

Native Funktionen gewährleisten keinen umfassenden Datenschutz

Amazon S3 bietet starke Haltbarkeits- und Betriebsgarantien, wie z.B. eine Objekthaltbarkeit von elf Neunen über mehrere Availability Zones, Bucket Versioning mit Löschmarkierungen, Replikation, Lebenszyklusrichtlinien und optionale Kontrollen wie Amazon S3 Object Lock und MFA Delete. Diese Funktionen tragen dazu bei, Hardwareausfälle abzumildern und alltägliche Fehler zu reduzieren.

Was sie jedoch nicht garantieren, ist die Ausfallsicherheit, wenn die Control-Plane kompromittiert wird, z.B. durch gestohlene Anmeldeinformationen, übermäßige Automatisierung, falsch angewandtes Identity Access Management (IAM) oder Richtlinien oder groß angelegte Bedienungsfehler. Da viele Funktionen den aktuellen Zustand spiegeln, können sie Löschungen, Beschädigungen oder Richtlinienänderungen genauso schnell weitergeben wie einen gesunden Zustand. Selbst bei aktivierten nativen Funktionen können wichtige Daten verloren gehen, oft ohne Vorwarnung, bis es zu spät ist.

Hier sind fünf Gründe, warum Sie ein unveränderliches, separat verwaltetes Backup für Ihre Amazon S3-Daten benötigen.

1. Sicherheitsvorfälle

Amazon S3 speichert oft große Mengen wertvoller Geschäftsdaten. Wenn jedoch die Zugriffskontrollen missbraucht oder die Zugangsdaten kompromittiert werden, kann dies schwerwiegende Folgen haben. Angreifer können Daten löschen, Schutzeinstellungen deaktivieren oder Änderungen vornehmen, die ganze Umgebungen betreffen. Selbst mit eingebauten Schutzmechanismen wie Object Lock bleiben Umgebungen ohne strengere Einstellungen anfällig für Manipulationen und möglichen Datenverlust.

Dokumentierter Vorfall: Im Januar 2025 berichteten Forscher über eine Ransomware-Kampagne namens Codefinger, die Amazon S3 Server-Side Encryption with Customer-Provided Keys (SSE-C) missbrauchte. Nachdem sie gültige AWS-Anmeldedaten gestohlen hatten, verwendeten die Angreifer Standard-S3-Aufrufe, um Daten zu überschreiben und mit Schlüsseln, die nur sie kontrollierten, neu zu verschlüsseln. Dabei wurde kein AWS-Fehler ausgenutzt, sondern der Missbrauch nativer Funktionen nach der Kompromittierung von Anmeldeinformationen.

Das Ergebnis war der sofortige Verlust des Zugangs für die Opfer, da AWS keine vom Kunden bereitgestellten Schlüssel speichert. In mehreren Berichten wurde auch festgestellt, dass Lebenszyklus-Einstellungen verwendet wurden, um eine schnelle Löschung zu planen und so den Druck zu erhöhen, zu zahlen. Die Veröffentlichung begann im Januar 2025, gefolgt von einer Anleitung zur Erkennung und Blockierung unbeabsichtigter SSE-C-Aktivitäten. [^1] [^2]

2. Administrative Fehlkonfigurationen

Nicht jeder Datenverlust wird durch eine externe Bedrohung verursacht. Oft ist es menschliches Versagen. Eine falsch geschriebene Regel oder eine übersehene Einstellung kann zu versehentlichen Löschungen, überschriebenen Dateien oder Speicherübergängen führen, die Arbeitsabläufe unterbrechen. Ohne Versionierung oder Unveränderbarkeit können kleine Fehler schnell unwiederbringlich werden.

Dokumentierter Vorfall: Das Amazon S3-Bucket eines US-Gesundheitsdienstleisters war falsch konfiguriert, was den Zugriff ohne ordnungsgemäße Authentifizierung ermöglichte. Ein unbefugter Akteur nutzte diesen Zugriff, um Daten herunterzuladen und dann Löschvorgänge gegen den Bucket durchzuführen, wodurch die medizinischen Daten von etwa 3,25 Millionen Personen ohne Wiederherstellungsmöglichkeit gelöscht wurden. Der Verstoß wurde im Januar 2021 öffentlich bekannt gegeben. Der Bucket verfügte über keine Versionierung oder Objektsperre, so dass es nach dem Löschen von Objekten keinen nativen Pfad zur Wiederherstellung der letzten Kopien gab. Der Anbieter musste die Daten aus anderen Systemen wiederherstellen und eine Kreditüberwachung anbieten. Dieser Vorfall ist ein Beispiel dafür, wie eine falsch konfigurierte Richtlinie zu einem dauerhaften Datenverlust führen kann. [^3]

3. Compliance- und Governance-Durchsetzung

Die Erfüllung von Compliance-Anforderungen beinhaltet oft strenge Datenkontrollen wie Aufbewahrungsregeln, gesetzliche Sperrfristen und Unveränderbarkeitseinstellungen. Diese Maßnahmen sind für die Revisionssicherheit und den langfristigen Schutz von entscheidender Bedeutung, können jedoch zu betrieblichen Problemen führen. Weit gefasste Aufbewahrungsfristen können die Speicherkosten erhöhen, und starre Richtlinien können die Bereinigung verlangsamen oder die Wiederherstellung behindern.

Dokumentierter Vorfall: In einem auf AWS in Plain English geteilten Vorfall wurde beschrieben, wie ein Technikteam eine Lebenszyklusregel zum Löschen von Protokollen, die älter als 30 Tage sind, einführte, um die Speicherkosten zu senken. Die Regel passte versehentlich zu Protokoll-Präfixen, die eine Aufbewahrung von 90 Tagen erforderten. Da sich Lebenszyklusregeln auf bestehende Objekte beziehen, stellte Amazon S3 diese Protokolle in die Warteschlange für die Löschung und entfernte sie im nächsten Zyklus.

Das Ergebnis war, dass das Unternehmen monatelang den Prüfungsverlauf verlor, Lücken in der Analyse hatte und die Sichtbarkeit von sekundären Systemen wiederherstellen musste. Eine falsch konfigurierte Richtlinie führte zu dauerhaftem Datenverlust und einem großen operativen Rückschlag. [^4]

4. Betriebs- und Plattformausfälle

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

Dokumentierter Vorfall: Bei einem viel beachteten globalen Ausfall am 20. Oktober 2025 führten interne AWS-Netzwerkfehler und DNS-Probleme zu kaskadenartigen Serviceunterbrechungen bei vielen Diensten, einschließlich S3. Obwohl AWS angab, dass es keine bestätigten Datenverluste gab, kam es bei vielen Benutzern zu fehlgeschlagenen Uploads, Zeitüberschreitungen und Verzögerungen beim Zugriff auf oder beim Schreiben von Daten, wodurch sich das Risiko eines möglichen Datenverlusts für Systeme erhöhte, die nicht in der Lage waren, Schreibvorgänge abzuschließen oder unvollständige Transaktionen wiederherzustellen. [^5]

5. Kompromittierung der Lieferkette durch den Cloud-Anbieter

Jedes Unternehmen unterliegt einem Lieferkettenrisiko, und Hyperscale-Cloud-Anbieter bilden da keine Ausnahme. Probleme, die AWS oder seine vorgelagerten Abhängigkeiten betreffen, können sich auf viele Kunden auswirken und Unterbrechungen des Datenzugriffs verursachen, selbst wenn die Kontokonfigurationen korrekt sind. Zu den Auswirkungen gehören fehlgeschlagene Ver- oder Entschlüsselungsvorgänge (für KMS-abhängige Arbeitslasten), blockierter Zugriff auf Buckets, gestoppte Replikation oder Lebenszyklusverarbeitung und eine allgemeine Instabilität der Control-Plane.

Dokumentierter Vorfall: 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 Bedrohungsakteur einen übermäßig permissiven GitHub-Token verwendet hatte, um Änderungen in die Build-Pipeline zu übertragen. AWS zog die Version zurück und gab eine korrigierte Version heraus.

Der eingeschleuste Code war so konzipiert, dass er lokale Dateien löschte und Cloud-Ressourcen, einschließlich S3-Buckets, löschte, was zu einem weitreichenden Datenverlust hätte führen können, wenn er in großem Umfang über die installierte Basis der Erweiterung ausgeführt worden wäre. AWS widerrief die Zugangsdaten, entfernte den eingeschleusten Code und meldete, dass keine Kundenressourcen betroffen waren. Dieser Vorfall zeigt, wie selbst der Fehler eines vertrauenswürdigen Anbieters zu einem zerstörerischen Zugriff in gut konfigurierten Kundenumgebungen führen kann. [^6]

Immutable, Logically Air-Gapped Backups for Rapid Recovery

Wenn es einen Ansatz gibt, der die betriebliche Ausfallsicherheit in den oben genannten Szenarien sicherstellt, dann ist es ein unveränderliches, Logically Air-Gapped Backup mit unabhängigen Richtlinien und Point-in-Time Recovery.

"Logically air-gapped" bedeutet, dass Ihre Backups in einem separaten AWS-Konto mit eigenen Anmeldeinformationen und Rollen gespeichert werden, mit unveränderlicher oder zeitbasierter Aufbewahrung, so dass Änderungen in der Produktion keine Sicherungskopien ändern oder löschen können. Selbst wenn der Zugriff auf die Produktion oder die Konfiguration manipuliert wird, bleiben diese Kopien intakt, so dass Sie einen sauberen, bekannt guten Wiederherstellungspfad in großem Umfang haben.

HYCU, in Partnerschaft mit Dell, bietet genau das. Wir bieten kosteneffiziente, Ransomware-resistente Backups für Amazon S3, so dass Sie selbst in den schwierigsten Szenarien mit Zuversicht wiederherstellen können. Verwenden Sie DDVE on AWS als Ihr primäres Sicherungsziel für Amazon S3-Daten.

Für BCDR replizieren Sie eine unveränderliche Sekundärkopie von DDVE auf AWS zu DDVE auf Google Cloud oder Azure. Dieser Ansatz trägt dazu bei, die Kosten für den Cloud-übergreifenden Ausstieg und die Speicherung zu minimieren und gleichzeitig die damit verbundenen Risiken aufgrund von Providerproblemen und regionalen Abhängigkeiten zu verringern.

Schnelle Bereitstellung. Einfach zu verwalten. Von vornherein unveränderlich.

Schauen Sie sich https://www.hycu.com/solutions/data-protection/dell-powerprotect-data-domain an, um zu sehen, wie HYCU und Dell kosteneffiziente und belastbare Datensicherung für Amazon S3 bereitstellen.

1. Halcyon RISE Team. (2025, Januar 13). Missbrauch der nativen AWS-Services: Ransomware verschlüsselt S3-Buckets mit SSE-C. Halcyon.ai.
2. Arghire, I. (2025, Januar 14). Kompromittierte AWS-Schlüssel für Codefinger-Ransomware-Angriffe missbraucht. SecurityWeek.
3. Alder, S. (2021, Dezember 30). Die größten Datenschutzverletzungen im Gesundheitswesen im Jahr 2021. HIPAA Journal.
4. Sandesh. (2025, Juni 18). Unser Fehler mit den S3-Lebenszyklusregeln (und wie wir den Datenverlust behoben haben). AWS in Plain English.
5. Amazon. (2025, Oktober 20). Update - AWS-Dienste arbeiten normal. Über Amazon.
6. Amazon Web Services. (2025, Juli 23). Sicherheitsupdate für Amazon Q Developer Extension für Visual Studio Code (Version 1.84). AWS Security Bulletins.