Einheit 5.2: Object Storage

Einführung

Object Storage ist das letzte Glied der Datenarchitektur. Hier landen die Audit-Log-Exports aus Einheit 2.3 für ihr langfristiges, manipulationssicheres Dasein. Hier finden Backup Service und Datenbank-Dumps ihren endgültigen Ruheplatz. Hier lagern ML-Datensätze und Build-Artefakte. Und hier sammeln sich Dead Letters aus Event-Streaming-Systemen. Diese Position verdankt Object Storage seiner hohen Ausdauer, seiner S3-Kompatibilität und seinen Preisen für Massenlagerung. Die beiden Entscheidungen, die über Erfolg oder Misserfolg entscheiden, werden jedoch nur einmal getroffen und können nicht rückgängig gemacht werden: der Typ und die Region des Buckets sowie die Frage, ob Object Lock aktiviert ist. Diese Einheit behandelt diese Entscheidungen zuerst und baut anschließend das Bucket im Data Center Designer auf, mit den Locks und Lifecycle-Regeln, die rohe Speicherung in eine konforme Aufbewahrungsstufe verwandeln.

1. Was Object Storage ist und welche Rollen es erfüllt

IONOS Cloud Object Storage folgt der AWS S3 API (Version 2 des S3-Protokolls), sodass dieselben Tools, SDKs und Anwendungen, die auf S3-kompatible Plattformen abzielen, auch damit funktionieren. Die Daten befinden sich in einem flachen Namensraum: Objekte (jeweils mit Metadaten und einem eindeutigen Schlüssel) in Buckets, ohne einen echten Verzeichnisbaum darunter. Die Authentifizierung erfolgt über ein pro Benutzer generiertes Access Key- und Secret Key-Paar (92 und 64 Zeichen im aktuellen Format, bis zu 5 Schlüssel pro Benutzer). Der DCD verwendet diese Zugangsdaten für die Steuerung der Web-Oberfläche, und dasselbe Paar wird von jedem S3-Client oder SDK vorgelegt. Ein einzelnes Objekt kann bis zu 5 TiB groß sein, und die einzige Speicherklasse ist STANDARD. Die Abrechnung erfolgt nach dem Pay-as-you-go-Modell für Speicher und ausgehenden Datentransfer pro Gigabyte, ohne Gebühr pro Anfrage. Aus diesem Grund werden Massen- und Archivierungsworkloads hier abgelegt und nicht auf Block Storage.

Diese Eigenschaften bestimmen, wo Object Storage in der FinCorp-Architektur seinen Platz findet:

• Audit-Archiv. Activity Logs sind pro Vertrag, schreibgeschützt und werden nur 35 Tage aufbewahrt (Einheit 2.3). Das Exportieren in ein Bucket, bevor dieses Zeitfenster schließt, ermöglicht FinCorp die mehrjährige, manipulationssichere Aufbewahrung, die seine Aufsichtsbehörden erwarten. Object Lock (Abschnitt 2) ist der Mechanismus, der dieses Archiv manipulationssicher macht.
• Backup-Ziel. Backup Service und die Ausgabe von Datenbank-Dump- und Restore-Vorgängen (Einheiten 5.3, 5.7) schreiben hierhin. Beachten Sie die klare Abgrenzung: Der Umfang von Backup Service (Acronis) beschränkt sich auf VMs und Block Storage. Es sichert verwaltete Datenbanken nicht und bietet selbst keine unveränderlichen Sicherungen. Object Lock auf dem Ziel-Bucket ist der Weg, wie FinCorp die Unveränderlichkeit ergänzt, die Backup Service nicht bietet.
• Datensatz- und Artefakt-Speicher. Die KI-Ebene (Modul 6) liest ihren Trainingskorpus und speichert Modell-Artefakte hier; ein von Kunden erstellter Korpus für Retrieval-augmented Generation befindet sich ebenfalls in Object Storage. Der flache Namensraum eignet sich gut für große Mengen unstrukturierter Daten außerhalb einer Datenbank.
• Ziel für Dead-Letter-Nachrichten. Managed Kafka (Einheit 5.6) schreibt sein Archiv und seinen Dead-Letter-Anteil in ein Bucket, wo verarbeitete Aufzeichnungen kostengünstig für spätere Prüfung gesammelt werden.

Die dokumentierten Anwendungsfälle der Plattform umfassen außerdem die Speicherung von Website-Assets, das Hosting statischer Websites, das Hosting von Multimedia-Assets und die private Dateispeicherung. Für FinCorp sind Sicherung/Restore und die Speicherung unstrukturierter Daten die primären Verwendungszwecke.

2. Die zwei irreversiblen Entscheidungen: Bucket-Typ, Region und Object Lock

2.1 Bucket-Typ und Region sind bei der Erstellung festgelegt

Ein Bucket ist entweder contract-owned oder user-owned, und der Typ bestimmt auch, welche Regionen verfügbar sind. Er beeinflusst die Eigentümerschaft, die Sichtbarkeit und welche Endpunkte den Bucket bedienen.

• Contract-owned Buckets machen den Vertragsinhaber zum Eigentümer jedes Buckets. Jeder Benutzer im Vertrag kann die vollständige Bucket-Liste einsehen, und der Vertragsinhaber oder ein Administrator gewährt Zugriff und definiert Berechtigungen über die Bucket Policy-Einstellungen. Dies ist das richtige Modell für eine einzelne Organisation wie FinCorp, die eine zentrale Governance anstrebt.
• User-owned Buckets werden unabhängig von jedem Benutzer besessen, der sie ohne die Genehmigung des Vertragsinhabers erstellt und verwaltet, wobei es keine kombinierte Liste über Benutzer hinweg gibt. Dieses Modell ist älter als contract-owned Buckets und eignet sich für Fälle, in denen Benutzer separate Entitäten sind.

Die Regionenauswahl ist durch den Typ eingeschränkt. Die beiden folgenden Tabellen sind die maßgeblichen Regionslisten pro Bucket-Typ.

Contract-owned Buckets können nur in den folgenden Regionen erstellt werden:

User-owned Buckets können nur in den folgenden Regionen erstellt werden:

Jede Region hat ihre eigene Endpunkt-URL, und ein Bucket-Name muss in Object Storage global eindeutig sein (3 bis 63 Zeichen). Die Region ist wichtig für die Nähe (Latenz und Egress-Kosten in der Nähe der Anwendung oder der Benutzer) und für Redundanz (eine Sicherung oder ein Archiv sollte in einer geografisch getrennten Region liegen, damit sie bei einem lokalen Ausfall übersteht). Für FinCorp unter DSGVO und BSI ist dies die in Einheit 1.4 beschriebene Entscheidung zur Datenhoheit, angewendet in der Praxis: Bewahren Sie das Audit-Archiv und die Datenbanksicherungen in deutschen Rechenzentren (de, eu-central-3 oder eu-central-4) auf, nicht in us-central-1. Der S3 Object Storage-Dienst ist sowohl durch die BSI C5 Type 1-Zertifizierung (erteilt am 2023-11-07, deutsche Rechenzentren) als auch durch das auf IT-Grundschutz basierende ISO 27001-Zertifikat (erteilt am 2022-09-14) abgedeckt; die Platzierung des Archivs in einer deutschen Region stellt sicher, dass es innerhalb dieses Geltungsbereichs bleibt. Die Dauerhaftigkeit über Regionen hinweg wird durch von Ihnen konzipierte Replikation erreicht, nicht durch eine automatische Eigenschaft eines einzelnen Buckets.

2.2 Object Lock und Lebenszyklus: Manipulationssicherheit und Kostenkontrolle

Object Lock implementiert Write Once Read Many (WORM): Ein Objekt kann während einer Aufbewahrungsfrist nicht gelöscht oder geändert werden. Es hat zwei Modi:

• Der GOVERNANCE-Modus schützt Objekte vor der regulären Löschung, erlaubt jedoch privilegierten Benutzern, das Sperren zu umgehen.
• Der COMPLIANCE-Modus ist absolut: Bis das Aufbewahrungsdatum überschritten ist, ist das Objekt unveränderbar, der Modus kann nicht deaktiviert werden und die Aufbewahrungsfrist kann nicht verkürzt werden, nicht einmal durch den Bucket-Eigentümer. Dies ist der Modus für das regulatorische Archiv von FinCorp, bei dem die Anforderung lautet, dass niemand, einschließlich eines Administrators, die Beweise manipulieren kann.

Die Aufbewahrungsfrist kann über den DCD bis zu 365 Tage festgelegt werden; die API unterstützt bis zu 100 Jahre. Die entscheidende Einschränkung ist der Zeitpunkt: Object Lock kann nur bei der Erstellung des Buckets aktiviert werden, nie nachträglich. Die Aktivierung schaltet auch die Versionierung ein, und einmal aktiviert, kann keines der beiden deaktiviert werden. Eine Kompositionsbeschränkung ist wichtig: Ein Bucket mit aktiviertem Object Lock kann keine Quelle für Replikation oder Tiering sein, kann aber ein Ziel sein. Wenn FinCorp sowohl ein gesperrtes Archiv als auch eine ausgehende Replikation von denselben Daten benötigt, muss die Replikation von einem nicht gesperrten Bucket ausgehen und das gesperrte Bucket als Ziel haben.

Lebenszyklusregeln adressieren die Kosten. Eine Konfiguration kann bis zu 1.000 Regeln enthalten, die jeweils auf alle Objekte oder auf ein einzelnes Präfix beschränkt sind (eine Regel pro Präfix). Die Aktionen sind: aktuelle Versionen nach einer Anzahl von Tagen oder an einem Datum ablaufen lassen; nicht aktuelle Versionen dauerhaft löschen; abgelaufene Objekt-Löschmarker löschen; und unvollständige Multipart-Uploads löschen. Da die einzige Speicherklasse STANDARD ist, können Lebenszyklusregeln Objekte nicht in eine günstigere Ebene überführen; hier ist es ein Werkzeug für Ablauf und Aufräumen, nicht für Tiering. Es passt natürlich zu Object Lock: Die COMPLIANCE-Sperre garantiert, dass die Daten mindestens die Aufbewahrungsfrist überstehen, während eine Lebenszyklus-Ablaufregel garantiert, dass sie nicht verbleiben und Kosten verursachen, sobald die Verpflichtung endet. Setzen Sie den Ablaufzeitpunkt auf oder nach der Sperren-Aufbewahrungsfrist, damit die beiden niemals in Konflikt geraten.

3. DCD-Implementierungsanleitung

Sie erstellen das Audit- und Backup-Archiv von FinCorp: einen vertragsgebundenen Bucket in einer deutschen Region, bei dem Object Lock im COMPLIANCE-Modus bei der Erstellung aktiviert wird, sowie eine Lifecycle-Regel, die Objekte nach Ablauf ihrer Aufbewahrungspflicht abläuft. Damit wird die manipulationssichere Aufbewahrungsstufe umgesetzt, auf die der Audit-Export aus Einheit 2.3 und die Sicherungen aus Einheit 5.7 angewiesen sind.

Bauziel: Einen Bucket erstellen, Object Lock und eine Lifecycle-Richtlinie festlegen.

Voraussetzungen: Ein Benutzer mit dem Recht „Use Object Storage“ (vergeben über Gruppenmitgliedschaft, Einheit 2.2) und ein für diesen Benutzer generierter Object Storage-Schlüssel. Die erste Schlüsselgenerierung ist auch der Schritt, bei dem die Canonical User ID angezeigt wird, die später für den Zugriff zwischen Benutzern benötigt wird.

Schritte (im Data Center Designer):

1. Öffnen Sie den Bereich Object Storage im DCD und wechseln Sie zum Tab „Buckets“. Wählen Sie, ob Sie einen benutzergebundenen oder einen vertragsgebundenen Bucket erstellen möchten; für das FinCorp-Archiv erstellen Sie einen vertragsgebundenen Bucket, damit die Governance beim Vertragsinhaber verbleibt.
2. Geben Sie einen global eindeutigen Bucket-Namen (3 bis 63 Zeichen) ein und wählen Sie die Region. Für das FinCorp-Archiv wählen Sie eine deutsche Region innerhalb des erlaubten Bereichs des Bucket-Typs (für einen vertragsgebundenen Bucket: eu-central-4 Frankfurt oder eu-central-3 Berlin), um das Archiv im Geltungsbereich von C5 und IT-Grundschutz zu halten.
3. Aktivieren Sie Object Lock in diesem Erstellungsschritt. Dies ist die einzige Gelegenheit, es zu aktivieren; es kann nachträglich nicht hinzugefügt werden, und die Aktivierung schaltet auch die Versionierung ein. Erstellen Sie den Bucket.
4. Öffnen Sie nach der Erstellung den Bucket, klicken Sie auf „Bucket-Einstellungen“ und gehen Sie zur Object Lock-Einstellung unter dem Abschnitt „Datenverwaltung“. Setzen Sie den Modus auf COMPLIANCE und die Aufbewahrungszeit auf den regulatorischen Zeithorizont (bis zu 365 Tage über das DCD). Diese Standardwerte gelten für neu hochgeladene Objekte; bereits vorhandene Objekte folgen den bei der Erstellung angewendeten Einstellungen.
5. Gehen Sie weiterhin in den Bucket-Einstellungen zur Lifecycle-Einstellung unter „Datenverwaltung“ und klicken Sie auf „Regel hinzufügen“.
6. Vergeben Sie einen eindeutigen Namen für die Lifecycle-Regel und legen Sie ihren Geltungsbereich fest: alle Objekte oder Objekte, die auf ein einzelnes Präfix beschränkt sind (jedes Präfix kann nur eine Regel tragen).
7. Wählen Sie die Lifecycle-Aktionen. Für das Archiv wählen Sie „Aktuelle Versionen nach einer Anzahl von Tagen ablaufen lassen“, die der Lock-Aufbewahrungszeit entspricht oder sie überschreitet, und fügen Sie „Nicht aktuelle Versionen dauerhaft löschen“ und „Unvollständige Multipart-Uploads löschen“ hinzu, um Kosten durch Versionierung und fehlgeschlagene Uploads zu steuern. Speichern Sie die Regel.
8. Prüfen Sie in der Bucket-Liste, dass der Bucket den richtigen Typ, die richtige Region und das richtige Erstellungsdatum anzeigt, und bestätigen Sie, dass die Object Lock- und Lifecycle-Einstellungen unter „Bucket-Einstellungen“ vorhanden sind.

Häufige Fehler:

• Object Lock bei der Erstellung vergessen. Es kann nicht in einem vorhandenen Bucket aktiviert werden. Wenn Sie es übersehen, müssen Sie einen neuen Bucket erstellen und die Daten migrieren. Entscheiden Sie sich für WORM, bevor Sie auf „Erstellen“ klicken.
• COMPLIANCE-Modus ohne Gewissheit wählen. Im COMPLIANCE-Modus können Sie die Aufbewahrungszeit nicht verkürzen und das Lock nicht deaktivieren, auch nicht als Bucket-Inhaber. Verwenden Sie GOVERNANCE während der Tests und reservieren Sie COMPLIANCE für Daten, deren Aufbewahrungspflicht feststeht.
• Falsche Region für die Datenhaltung wählen. Die Region ist bei der Erstellung festgelegt und bestimmt den Endpunkt. Eine US-Region (us-central-1) würde das Audit-Archiv eines deutschen Unternehmens außerhalb des deutschen Rechenzentrums-Geltungsbereichs der BSI-Zertifikate platzieren. Entscheiden Sie die Datenhaltung, bevor Sie den Bucket benennen.
• Annahme, ein nicht eindeutiger Bucket-Name würde funktionieren. Namen sind global eindeutig über das gesamte Object Storage, nicht nur innerhalb Ihres Vertrags. Verwenden Sie Namensräume (zum Beispiel mit dem Organisationstyp als Präfix), um Kollisionen zu vermeiden.
• Erwartung, dass Lifecycle auf günstigere Speicherarten umstellt. Es existiert nur die STANDARD-Klasse, daher laufen Lifecycle-Regeln ab und räumen auf; sie verschieben Objekte nicht in eine kühlere Stufe. Kostenkontrolle erfolgt durch Löschung, nicht durch Stufenbildung.
• Replikation aus einem gesperrten Bucket einrichten. Ein Bucket mit aktiviertem Object Lock kann keine Replikations- oder Stufenquelle sein. Wenn Sie Replikation benötigen, leiten Sie sie von einem entsperrten Bucket aus und machen Sie das gesperrte Archiv zum Ziel.

Ein kurzes Äquivalent mit einem S3-Client macht die nur bei der Erstellung mögliche Natur von Object Lock greifbar; der Schalter wird bei create-bucket gesetzt und hat kein nachträgliches Gegenstück:

aws s3api create-bucket \
  --bucket fincorp-audit-archive \
  --object-lock-enabled-for-bucket \
  --region=eu-central-4 --create-bucket-configuration LocationConstraint=eu-central-4 \
  --endpoint-url https://s3.eu-central-4.ionoscloud.com

Zusammenfassung

Object Storage ist der dauerhafte, S3-kompatible, volumenbasiert preisgegebene Rückhalt der Architektur: Audit-Archiv, Sicherungsziel, Datenspeicher und Artefakt-Speicher sowie Dead-Letter-Ende. Seine Stärke als Compliance-Ebene ergibt sich aus zwei Entscheidungen, die einmalig bei der Erstellung getroffen werden: der Bucket-Typ mit seiner Regionsbeschränkung und Object Lock, sowie aus Lifecycle-Regeln, die darüber für die Kostenkontrolle aufgelegt werden. Bestimmen Sie Typ, Region und Lock korrekt bei der Erstellung, da sich keines davon nachträglich ändern lässt.

Wichtige Punkte:

• Object Storage nutzt die AWS S3 API (v2), einen flachen Objekt- und Bucket-Namensraum sowie die Authentifizierung mit Access Key und Secret Key (92 und 64 Zeichen; bis zu 5 Schlüssel pro Benutzer); Objekte können eine Größe von bis zu 5 TiB erreichen, und die einzige Klasse ist STANDARD.
• Der Bucket-Typ (vertragsgebunden vs. benutzereigen) wird bei der Erstellung festgelegt und beschränkt die verfügbaren Regionen; vertragsgebundene Buckets eignen sich für zentrale Governance, und Bucket-Namen sind global eindeutig.
• Object Lock bietet WORM im GOVERNANCE- oder COMPLIANCE-Modus, muss bei der Erstellung aktiviert werden (kann nicht nachträglich hinzugefügt werden), aktiviert auch die Versionierung, und ist im COMPLIANCE-Modus irreversibel; die Aufbewahrungsfrist in DCD beträgt bis zu 365 Tage, über die API bis zu 100 Jahre.
• Lifecycle-Regeln (bis zu 1.000, auf alle Objekte oder ein Präfix beschränkt) verfallen und räumen Objekte zur Kostenkontrolle auf, können jedoch nicht auf eine günstigere Klasse umstellen, da nur STANDARD existiert.
• Verlegen Sie das Audit- und Sicherungsarchiv von FinCorp in einer deutschen Region mit Object Lock im COMPLIANCE-Modus, um es manipulationssicher und innerhalb des Leistungsumfangs von BSI C5 und IT-Grundschutz zu halten.

Wichtige Begriffe:

• Object Lock (WORM): Write Once Read Many-Aufbewahrung, die auf Objekte angewendet wird; GOVERNANCE erlaubt privilegierte Überschreibung, COMPLIANCE ist bis zum Aufbewahrungsdatum unveränderlich und kann weder verkürzt noch deaktiviert werden.
• Lifecycle-Regel: Eine automatisierte Aktion (aktuelle Versionen verfallen lassen, nicht aktuelle Versionen löschen, abgelaufene Löschmarken löschen, unvollständige Multipart-Uploads löschen), die auf einen Bucket oder ein einzelnes Objekt-Präfix beschränkt ist.
• Vertragsgebundener vs. benutzereigener Bucket: Das bei der Erstellung festgelegte Eigentums- und Sichtbarkeitsmodell, das auch bestimmt, welche Regionen und Endpunkte verfügbar sind.

Weitere Lektüre

• Einheit 2.3, Activity Logs und Audit Trail (die 35-tägige Exportfrist, die dieses Archiv erfüllt).
• Einheit 5.7, Datenschutz und Lebenszyklus (Zusammenführung von Sicherung, Snapshots, PITR und Object-Storage-Archiv in einer einzigen Kontinuitätsebene).
• Einheit 5.1, Block- und Dateispeicher (wann regionaler geteilter Datei- oder Single-VM-Block besser geeignet ist als Objekt).