5 S3-Compliance umfasst die durchsetzbaren Kontrollen, die S3- oder S3-kompatiblen Objektspeicher für eine Aufsichtsbehörde akzeptabel machen: eine Aufbewahrung, die sich nicht stillschweigend rückgängig machen lässt, eine Verschlüsselung, deren Schlüssel Sie tatsächlich selbst besitzen, und Protokolle, die einer Prüfung standhalten. Das ist eine andere Frage als die der S3-Kompatibilität, bei der es nur darum geht, ob eine Plattform die API beherrscht. In der Beschaffung werden beide ständig vermengt. Eine Plattform kann jedes S3-Verb korrekt implementieren und trotzdem bei einer Prüfung durchfallen, denn bei den Regeln für regulierte Aufzeichnungen geht es nicht um den Funktionsumfang der API. Es geht darum, was passiert, wenn jemand mit administrativen Anmeldedaten versucht, etwas zu löschen, das er nicht löschen können sollte. Was S3-Compliance tatsächlich bedeutet Drei Dinge müssen gleichzeitig zutreffen. Die Speicherebene muss Kontrollen durchsetzen, statt sie nur als Einstellungen anzubieten – die Durchsetzung muss also unterhalb der Ebene liegen, die ein Administrator bearbeiten kann. Das System muss Nachweise erzeugen: nicht nur, dass eine Richtlinie existierte, sondern dass sie gehalten hat. Und die Kontrollen müssen einer konkret benennbaren Pflicht zugeordnet sein, denn „Wir nutzen unveränderlichen Speicher“ ist keine Antwort auf die Frage „Welche Regel, und für wie lange?“ Der sinnvolle Test lautet, ob eine Kontrolle einen kompromittierten Administrator übersteht. Bucket-Richtlinien tun das nicht: Sie sind IAM-Objekte, und wer IAM bearbeiten kann, kann auch sie bearbeiten. Lifecycle-Ablaufregeln verdeutlichen das gut. AWS dokumentiert, dass eine Bucket-Richtlinie Löschungen durch eine Lifecycle-Regel nicht verhindern kann und dass selbst eine Richtlinie, die allen Prinzipalen alle Aktionen verweigert, den Lifecycle normal weiterlaufen lässt. Object Lock hält das auf, weil es unterhalb der Richtlinienebene durchgesetzt wird. Genau wegen dieser Lücke ist der Unterschied für Aufsichtsbehörden wichtig. Die Regeln hinter den Anforderungen an S3-Compliance Bei Finanzdienstleistungen in den USA ist der Anker die SEC Rule 17a-4. Die Änderungen von 2022 (verabschiedet am 12. Oktober 2022, wirksam ab 3. Januar 2023, Compliance für Broker-Dealer ab 3. Mai 2023) haben die Anforderung auf eine Weise verändert, die das meiste Anbietermaterial nach wie vor falsch darstellt. Rule 17a-4(f)(2)(i) bietet nun zwei Alternativen, verbunden durch „oder“: Aufzeichnungen in einem nicht überschreibbaren, nicht löschbaren Format aufzubewahren – der klassische WORM-Weg – oder sie mit einem vollständigen, mit Zeitstempeln versehenen Audit-Trail aufzubewahren, der jede Änderung und Löschung, den Zeitpunkt, den Akteur und genug Informationen zur Rekonstruktion des Originals erfasst. WORM ist nicht mehr der einzige Weg. FINRA Rule 4511(c) übernimmt den geänderten Standard automatisch, da sie dynamisch auf 17a-4 verweist. Die CFTC Rule 1.31 folgt einem anderen Modell, und der Unterschied wird bei der Planung von Speicherebenen relevant. Das SEC-Muster sieht eine Aufbewahrung von sechs Jahren vor, davon die ersten zwei „leicht zugänglich“. Die CFTC verlangt, dass elektronische regulatorische Aufzeichnungen während des gesamten Zeitraums, in der Regel fünf Jahre, jederzeit zugänglich sind; das Zweijahresfenster gilt nur für Papier. Eine elektronische CFTC-Aufzeichnung im dritten Jahr in ein langsames Archiv zu verschieben, ist ein Compliance-Problem – keine Kostenoptimierung. Im Gesundheitswesen wird HIPAA häufig falsch zitiert. Es gibt keine bundesweite HIPAA-Aufbewahrungsfrist für Patientenakten (das regelt das Recht der Bundesstaaten). Die Sechsjahresregel in 45 CFR 164.316(b)(2)(i) gilt für Dokumentation: Richtlinien, Verfahren und die schriftlichen Aufzeichnungen der Bewertungen, die die Security Rule verlangt. Auch die Verschlüsselung muss präzise dargestellt werden, denn sie ist Stand Mitte 2026 weiterhin adressierbar (addressable) und nicht verpflichtend. Adressierbar heißt nicht optional (Sie müssen sie bewerten, jede Entscheidung gegen eine Umsetzung dokumentieren und eine gleichwertige Maßnahme einführen), ist aber keine Pflicht. Eine im Januar 2025 vorgeschlagene Regel würde Verschlüsselung und MFA verpflichtend machen; sie ist nicht endgültig, und die abschließende Entscheidung wurde auf voraussichtlich 2027 verschoben. In der EU gilt DORA seit dem 17. Januar 2025 für Finanzunternehmen; Artikel 12 regelt Backup und Wiederherstellung. Ein häufig überinterpretiertes Detail: Artikel 12(3) verlangt, dass Systeme zur Wiederherstellung von Daten physisch und logisch vom Quellsystem getrennt sind. Eine Trennung der Backup-Kopien selbst schreibt er nicht vor. Die verbindlichere Vorgabe für getrennte, unveränderliche Kopien findet sich in der NIS2-Durchführungsverordnung für digitale Infrastruktur und Cloud-Anbieter: Sie verlangt Backup-Kopien an Standorten, die nicht im selben Netzwerk wie das System liegen und weit genug entfernt sind, um einer Katastrophe am Hauptstandort zu entgehen. Aufbewahrung: wie S3 Object Lock sie durchsetzt S3 Object Lock ist der Mechanismus auf API-Ebene; er hat zwei Modi und zusätzlich einen unabhängigen Legal Hold. Im Compliance-Modus kann kein Benutzer eine geschützte Objektversion überschreiben, löschen oder ihre Aufbewahrung verkürzen – auch nicht das Root-Konto. Im Governance-Modus ist eine Außerkraftsetzung möglich, erfordert aber zweierlei zugleich: die Berechtigung s3:BypassGovernanceRetention und einen expliziten Request-Header. Die Aufbewahrung lässt sich in beiden Modi verlängern; verkürzen lässt sie sich nur im Governance-Modus, nie im Compliance-Modus. Die maximale Aufbewahrung beträgt 100 Jahre. Eine verbreitete Behauptung lautet, dass nur der Compliance-Modus SEC 17a-4 erfüllt. Das Gutachten, das dafür üblicherweise zitiert wird, sagt das Gegenteil: Object Lock erfüllt die Anforderung an ein nicht überschreibbares, nicht löschbares Format in beiden Modi, wobei der Governance-Modus auf Basis kompensierender Kontrollen besteht, die eine organisatorische Kontrolle und Überwachung der Administratoren mit Bypass-Berechtigung voraussetzen. Der Governance-Modus ist vertretbar, aber nur, wenn Sie die begleitenden Kontrollen nachweisen können – eine Governance-Last, keine technische. Drei betriebliche Details führen zu echten Prüfungsfeststellungen. Object Lock erfordert Versionierung, und einmal aktiviert, lässt es sich nicht abschalten, und die Versionierung kann nicht ausgesetzt werden. Legal Holds haben kein Ablaufdatum, bleiben unabhängig von der Aufbewahrung bestehen, bis sie ausdrücklich aufgehoben werden, und lassen sich nicht per Governance-Bypass umgehen. Und das Detail, das viele überrascht: Eine Löschanfrage ohne Versions-ID ist erfolgreich und fügt einen Delete Marker ein, da Delete Marker selbst nicht geschützt sind. Die Daten sind intakt, aber das Objekt scheint verschwunden. Wer Unveränderlichkeit mit einem einfachen Löschbefehl testet und eine 200-Antwort sieht, zieht genau den falschen Schluss. Verschlüsselung, Schlüssel und was „FIPS-zertifiziert“ wirklich bedeutet Verschlüsselung im Ruhezustand ist seit Langem Standard statt Entscheidung. Die entscheidende Frage jeder Verschlüsselungsstrategie für regulierte Daten ist daher die Verwahrung der Schlüssel. Serverseitige Verschlüsselung mit plattformverwalteten Schlüsseln schützt vor dem Diebstahl von Medien, macht die Daten aber für den Betreiber nicht undurchsichtig. Kundenverwaltete Schlüssel, idealerweise gestützt auf ein externes HSM, ermöglichen die Aussage, dass der Anbieter die Aufzeichnungen nicht lesen kann, und erlauben Crypto-Shredding bei der Außerbetriebnahme. Seien Sie vorsichtig mit Crypto-Shredding als Compliance-Argument, insbesondere gegenüber dem Recht auf Löschung nach der DSGVO. Der Europäische Datenschutzausschuss vertritt die Auffassung, dass verschlüsselte personenbezogene Daten weiterhin personenbezogene Daten sind, dass die Messlatte für eine Löschung eine wirksame Anonymisierung und nicht bloße Unzugänglichkeit ist und dass die Stärke einer Verschlüsselung über die jahrzehntelangen Zeiträume, die eine WORM-Aufbewahrung impliziert, nachlässt. Die Vernichtung von Schlüsseln ist eine starke Risikominderung, aber kein gesicherter Ersatz für eine Löschung. Bei der FIPS-140-Validierung kommt es auf Präzision an, weil Beschaffungsunterlagen sie oft falsch darstellen. Validiert werden kryptografische Module, nicht Plattformen oder Produkte. Ein Produkt ist entweder ein validiertes Modul oder enthält lediglich eines, und das Zertifizierungsprogramm schreibt für beide Fälle unterschiedliche zulässige Formulierungen vor. Auch die Übergangsfrist rückt näher: Alle FIPS-140-2-Zertifikate wandern am 21. September 2026 auf die Historical List und können danach bestehende Systeme, aber keine neuen Beschaffungen mehr stützen. Audit-Nachweise: Protokolle, die standhalten Hier scheitern ansonsten gut konzipierte Bereitstellungen, und der Grund steht in einem einzigen Satz der AWS-Dokumentation. Für S3 Server Access Logging wird ausdrücklich jede Gewähr ausgeschlossen: Die Zustellung ist nicht garantiert, Einträge können Stunden zu spät oder gar nicht ankommen, und es gibt keine Möglichkeit festzustellen, ob alle Einträge eines Zeitraums zugestellt wurden. Es wird ausdrücklich nicht als vollständige Erfassung aller Anfragen beschrieben. Für eine Beweismittelkette ist das fatal. Audit-Logging auf API-Ebene (CloudTrail bei AWS, entsprechende Dienste anderswo) hat keinen solchen Haftungsausschluss und bietet die Eigenschaften, die Nachweise belastbar machen: kryptografische Integritätsprüfung der Log-Dateien, Verschlüsselung, kontenübergreifende Zustellung, damit das geprüfte Konto seine eigenen Einträge nicht verändern kann, sowie Felder, die Object-Lock-Parameter erfassen. Die Standardaufbewahrung ist kurz, typischerweise 90 Tage; langfristige Pflichten erfordern daher einen unveränderlichen Event Store oder einen Export in ein SIEM oder einen gesperrten Bucket. In jedem Fall braucht der Audit-Trail dieselbe Aufbewahrung wie die Aufzeichnungen, die er beschreibt – was Teams regelmäßig vergessen einzuplanen. Datenresidenz – und wo Aufbewahrung und Löschung kollidieren Die häufigste falsche Prämisse in Gesprächen über Souveränität lautet, die DSGVO verlange, dass personenbezogene Daten in der EU bleiben. Das tut sie nicht. Kapitel V regelt internationale Übermittlungen über Angemessenheitsbeschlüsse, Standardvertragsklauseln und verbindliche interne Datenschutzvorschriften, und Übermittlungen in ein Land mit angemessenem Schutzniveau werden ähnlich behandelt wie solche innerhalb der EU. Das EU-Recht verbietet sogar die meisten Lokalisierungsanforderungen für nicht personenbezogene Daten. Wo Residenzpflichten tatsächlich bestehen, ergeben sie sich aus Branchenvorschriften, nationalem Recht, Beschaffungsrichtlinien oder Verträgen. DORA etwa verlangt, dass Verträge offenlegen, wo Daten gespeichert werden, und Änderungen ankündigen – eine Transparenzpflicht, keine Lokalisierungspflicht. Die Unterscheidung ist wichtig, denn wer souveräne Infrastruktur mit einer Rechtsgrundlage begründet, die es nicht gibt, hält keiner Prüfung stand. Die schärfere Spannung besteht zwischen unveränderlicher Aufbewahrung und dem Recht auf Löschung. Artikel 17(3) löst sie eng: Das Recht auf Löschung gilt nicht, „soweit“ die Verarbeitung zur Erfüllung einer rechtlichen Verpflichtung oder zur Geltendmachung, Ausübung oder Verteidigung von Rechtsansprüchen erforderlich ist. Daraus folgen zwei Konsequenzen. Eine gesetzliche Pflicht steht einem Löschantrag nur für die Daten und den Zeitraum entgegen, die sie tatsächlich abdeckt – ein pauschal unveränderlicher Bucket ist also keine pauschale Ausnahme. Und die Speicherbegrenzung wirkt in die andere Richtung: Sobald die Pflicht entfällt, wird das Behalten der unveränderlichen Kopie selbst zum Verstoß. Eine Aufbewahrung, die nie abläuft, ist nicht die sichere Option, als die sie erscheint. Checkliste: Fähigkeiten für S3-Compliance bewerten Object Lock im Compliance- und im Governance-Modus, mit Legal Holds unabhängig von der Aufbewahrung und zentral durchgesetzten Standards auf Bucket-Ebene. Eine dokumentierte Antwort auf das Verhalten von Delete Markern, damit „gelöscht“ in der Konsole etwas bedeutet, das Sie einem Prüfer erklären können. Kundenverwaltete Schlüssel mit Integration eines externen HSM oder KMS sowie ein Verwahrungsmodell, das der Frage „Kann der Betreiber das lesen?“ standhält. Kryptografische Module mit aktueller Validierung, geprüft anhand der Zertifikatsnummer statt einer Marketingaussage, sowie ein Plan für den Übergang von FIPS 140-2 im September 2026. Audit-Logging auf API-Ebene mit Integritätsprüfung und Write-Once- oder kontenübergreifender Zustellung, aufbewahrt so lange wie die Aufzeichnungen, die es belegt. Funktionstrennung, damit Speicheradministratoren Kapazität verwalten können, ohne Inhalte von Aufzeichnungen zu lesen, und Überwachung aller Inhaber eines Governance-Bypass. Eine Aufbewahrung, die mit dem Ende der Pflicht abläuft, und ein Lösch-Workflow, der auf Daten außerhalb des Anwendungsbereichs zugreifen kann und gesperrte Aufzeichnungen unberührt lässt. Export von Nachweisen in einem nutzbaren elektronischen Format, einschließlich Audit-Trails, innerhalb der von Ihrer Aufsichtsbehörde vorgegebenen Frist. Alles zusammengeführt Organisationen, die Prüfungen souverän bestehen, haben meist eine unspektakuläre Sache getan: Sie haben jede Kontrolle einer benannten Pflicht mit festgelegter Dauer zugeordnet, statt ein Bündel von Fähigkeiten zu kaufen und eine Abdeckung anzunehmen. Unveränderlichkeit ohne einen an eine Regel gebundenen Aufbewahrungsplan ist nur teurer Speicher. Ein Audit-Trail, den noch niemand zu exportieren versucht hat, ist eine Annahme, kein Nachweis. Die technischen Bausteine für S3-Compliance sind Stand 2026 ausgereift und plattformübergreifend breit verfügbar; der Fehler liegt daher fast nie in einer fehlenden Funktion. Er liegt in einer Kontrolle, die einmal konfiguriert, nie gegen ein feindliches Szenario getestet und nie der Regel zugeordnet wurde, die sie erfüllen sollte. Häufig gestellte Fragen Ist S3-Compliance dasselbe wie S3-Kompatibilität? Nein. S3-Kompatibilität beschreibt, wie getreu eine Plattform die API umsetzt – einschließlich der Frage, ob sie Operationen wie Object Lock und Versionierung überhaupt unterstützt. S3-Compliance beschreibt, ob sie die Kontrollen für Aufbewahrung, Zugriff, Verschlüsselung und Nachweise durchsetzt, die eine bestimmte Vorschrift verlangt. Eine Plattform kann beim Ersten gut abschneiden und beim Zweiten scheitern – meist bei Audit-Nachweisen und der Verwahrung von Schlüsseln. Verlangt SEC 17a-4 Object Lock im Compliance-Modus? Nicht unbedingt. Das unabhängige Gutachten, das hier meist zitiert wird, kommt zu dem Schluss, dass Object Lock die Anforderung an ein nicht überschreibbares, nicht löschbares Format in beiden Modi erfüllt, wobei der Governance-Modus von kompensierenden organisatorischen Kontrollen über Administratoren mit Bypass-Berechtigung abhängt. Zudem haben die Änderungen von 2022 eine Audit-Trail-Alternative zum WORM-Weg eingeführt; WORM ist also ein Weg, nicht der einzige. Verlangt die DSGVO, dass Daten in der EU bleiben? Nein. Sie regelt internationale Übermittlungen, statt sie zu verbieten, und erlaubt Übermittlungen in Länder mit Angemessenheitsbeschluss oder unter Garantien wie Standardvertragsklauseln. Echte Residenzanforderungen ergeben sich aus Branchenvorschriften, nationalem Recht, Beschaffungsrichtlinien oder Verträgen. Das EU-Recht verbietet zudem die meisten Lokalisierungsanforderungen für nicht personenbezogene Daten. Wie vertragen sich unveränderliche Aufbewahrung und das Recht auf Löschung? Über eine eng gefasste statt einer allgemeinen Ausnahme. Das Recht auf Löschung gilt nicht, soweit die Verarbeitung für eine rechtliche Verpflichtung oder für Rechtsansprüche erforderlich ist; Sie müssen die Pflicht also benennen und ihren Umfang nachweisen können. Daten außerhalb dieses Umfangs müssen weiterhin löschbar sein, und sobald die Pflicht endet, verlangt die Speicherbegrenzung die Entsorgung. Eine Aufbewahrung braucht ein definiertes Ende ebenso wie einen Anfang. Reichen S3 Server Access Logs als Audit-Trail aus? Nein – und das ist dokumentiert, keine Meinungsfrage. AWS erklärt, dass die Zustellung von Server Access Logs nicht garantiert ist, dass Einträge erheblich verzögert oder nie zugestellt werden können und dass sich nicht bestätigen lässt, ob alle Einträge eines Zeitraums angekommen sind. Nutzen Sie für alles, was als Nachweis dienen muss, Audit-Logging auf API-Ebene mit Integritätsprüfung. Weiterführende Artikel Die Details zu den einzelnen Regeln hinter diesem Überblick finden Sie unter SEC-17a-4-Compliance, in der Checkliste für CJIS-konformen Speicher, SOX-Compliance sowie unter was echten unveränderlichen Speicher ausmacht (auf Englisch).
