Einheit 5.2: Object Storage

Einführung

Object Storage ist die Grundlage der Datenarchitektur. Hier landen die Audit-Log-Exporte aus Einheit 2.3 für ihr langfristiges, manipulationsfestes Leben, wo Backup Service und Datenbankdumps zu REST kommen, wo ML-Datensätze und Build-Artifakte platziert sind und wo Event-Streaming-Dead-Letters akkumulieren. Es verdient diese Position, weil es langlebig, S3-kompatibel und für den Großhandel preisgünstig ist. Die zwei Entscheidungen, die es machen oder brechen, werden jedoch einmal getroffen und können nicht rückgängig gemacht werden: die Art des Buckets und die Region, und ob Object Lock aktiviert ist. Diese Einheit behandelt diese Entscheidungen zuerst, dann wird das Bucket im Data Center Designer mit den Sperren und Lebenszyklusregeln erstellt, die den rohen Speicher in eine konforme Aufbewahrungsstufe verwandeln.

1. Was Object Storage Ist, und die Rollen, die es Spielt

IONOS Cloud Object Storage hält sich an das AWS S3 API (v2 des S3-Protokolls), sodass die gleichen Tools, SDKs und Anwendungen, die auf S3-kompatible Plattformen abzielen, auch gegen diese Plattform funktionieren. Die Daten leben in einem flachen Namensraum: Objekte (jedes trägt Metadaten und einen eindeutigen Schlüssel) innerhalb von Buckets, ohne ein echtes Verzeichnisbaum-Unterbau. Die Authentifizierung erfolgt durch ein Zugriffsschlüssel- und Geheimschlüsselpaar, das pro Benutzer generiert wird (92 und 64 Zeichen im aktuellen Format, bis zu 5 Schlüssel pro Benutzer); die DCD verwendet diese Anmeldedaten, um die Web-Oberfläche zu steuern, und das gleiche Paar ist das, was jeder S3-Client oder SDK präsentiert. Ein einzelnes Objekt kann bis zu 5 TiB groß sein, und die einzige Speicherklasse ist STANDARD. Die Preise sind Pay-as-you-go basierend auf Speicher und ausgehender Übertragung pro Gigabyte, ohne pro-Anfrage-Gebühr, was der Grund ist, warum Massen- und Archiv-Workloads hier landen, anstatt auf Block Storage.

Diese Eigenschaften entscheiden, wo Object Storage in der FinCorp-Architektur passt:

• Audit-Archiv. Activity Logs sind pro Vertrag, schreibgeschützt und nur 35 Tage lang aufbewahrt (Einheit 2.3). Das Exportieren in ein Bucket, bevor dieses Fenster schließt, gibt FinCorp die mehrjährige, manipulationsbeweisbare Aufbewahrung, die ihre Aufsichtsbehörden erwarten. Object Lock (Abschnitt 2) ist das, was dieses Archiv manipulationsbeweisbar macht.
• Sicherungsziel. Backup Service und Datenbank-Dump-/Wiederherstellungs-Ausgaben (Einheiten 5.3, 5.7) schreiben hier. Beachten Sie die ehrliche Grenze: Der Umfang von Backup Service (Acronis) umfasst virtuelle Maschinen und Block Storage, es sichert jedoch keine gemanagten Datenbanken und bietet keine unveränderlichen Sicherungen selbst. Object Lock im Ziel-Bucket ist die Möglichkeit, wie FinCorp die Unveränderlichkeit hinzufügt, die Backup Service nicht bietet.
• Datensatz- und Artefakt-Speicher. Die KI-Ebene (Modul 6) liest ihren Trainingskorpus und speichert Modell-Artefakte hier; ein kundenspezifischer Retrieval-augmentierter-Generation-Korpus lebt auch in Object Storage. Der flache Namensraum eignet sich gut für große Mengen unstrukturierter Daten außerhalb einer Datenbank.
• Totbrief-Ziel. Gemanagtes Kafka (Einheit 5.6) schreibt sein Archiv und Totbrief-Schwanz in ein Bucket, wo unverarbeitete Aufzeichnungen billig für spätere Inspektionen angesammelt werden.

Die dokumentierten Anwendungsfälle der Plattform umfassen auch die Speicherung von Website-Assets, die statische Website-Hostung, die Multimediainhalte-Hostung und die private Dateispeicherung; für FinCorp sind jedoch Sicherung/Wiederherstellung und die Speicherung unstrukturierter Daten die primären Anwendungen.

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

2.1 Bucket-Typ und Region sind bei der Erstellung gebunden

Ein Bucket ist entweder vertragsgeprüft oder benutzergeprüft, und der Typ beschränkt auch, welche Regionen verfügbar sind. Es ändert den Besitz, die Sichtbarkeit und welche Endpunkte den Bucket bedienen.

• Vertragsgeprüfte Buckets machen den Vertragsbesitzer zum Besitzer jedes Buckets. Jeder Benutzer im Vertrag kann die vollständige Bucket-Liste sehen, und der Vertragsbesitzer oder ein Administrator gewährt den Zugriff und definiert die Berechtigungen über die Bucket-Richtlinien-Einstellungen. Dies ist das richtige Modell für eine einzelne Organisation wie FinCorp, die eine zentrale Governance wünscht.
• Benutzergeprüfte Buckets sind unabhängig von jedem Benutzer besessen, der sie erstellt und verwaltet, ohne die Zustimmung des Vertragsbesitzers, mit keiner kombinierten Liste über die Benutzer hinweg. Dies geht den vertragsgeprüften Buckets voraus und eignet sich für Fälle, in denen die Benutzer separate Einheiten sind.

Die Regionenauswahl ist durch den Typ beschränkt. Die beiden Tabellen unten sind die autoritativen Regionenlisten pro Bucket-Typ.

Vertragsgeprüfte Buckets können nur in den folgenden Regionen erstellt werden:

Benutzergeprüfte Buckets können nur in den folgenden Regionen erstellt werden:

Jede Region hat ihre eigene Endpunkt-URL, und ein Bucket-Name muss global eindeutig sein über alle Object Storage hinweg (3 bis 63 Zeichen). Die Region ist wichtig für die Nähe (Latenz und Ausgangskosten in der Nähe der Anwendung oder Benutzer) und für die Redundanz (eine Sicherung oder ein Archiv gehört in eine Region, die geografisch getrennt von der primären ist, damit es einen lokalen Ausfall überlebt). Für FinCorp unter GDPR und BSI ist dies die Residenzentscheidung aus Einheit 1.4 in der Praxis umgesetzt: die Audit-Archive und Datenbank-Sicherungen in deutschen Rechenzentren (de, eu-central-3 oder eu-central-4) aufbewahren, anstatt us-central-1. Der S3 Object Storage-Dienst wird von beiden dem BSI C5-Typ-1-Attest (erteilt am 2023-11-07, deutsche Rechenzentren) und dem IT-Grundschutz-basierten ISO 27001-Zertifikat (erteilt am 2022-09-14) abgedeckt; das Archiv in einer deutschen Region zu platzieren, hält es innerhalb dieses Umfangs. Die Cross-Region-Dauerhaftigkeit wird durch die von Ihnen entworfene Replikation erreicht, nicht durch eine automatische Eigenschaft eines Buckets.

2.2 Object Lock und Lebenszyklus: Manipulationssicherheit und Kosteneinfluss

Object Lock implementiert Write Once Read Many (WORM): ein Objekt kann nicht gelöscht oder geändert werden, solange die Aufbewahrungsfrist nicht abgelaufen ist. Es gibt zwei Modi:

• GOVERNANCE-Modus schützt Objekte vor dem gewöhnlichen Löschen, während er gleichzeitig privilegierten Benutzern erlaubt, den Lock zu übersteuern.
• COMPLIANCE-Modus ist absolut: bis zum Ablauf des Aufbewahrungsdatums ist das Objekt unveränderlich, der Modus kann nicht deaktiviert werden, und die Aufbewahrungsfrist kann nicht verkürzt werden, nicht einmal durch den Bucket-Besitzer. Dies ist der Modus für FinCorps regulatorisches Archiv, in dem die Anforderung besteht, dass niemand, einschließlich eines Administrators, die Beweise manipulieren kann.

Die Aufbewahrungsfrist kann bis zu 365 Tage über den DCD eingerichtet werden; der API unterstützt bis zu 100 Jahre. Die entscheidende Einschränkung ist die Zeit: Object Lock kann nur bei der Bucket-Erstellung aktiviert werden, nie danach hinzugefügt. Die Aktivierung schaltet auch die Versionierung ein, und sobald aktiviert, kann weder Object Lock noch Versionierung deaktiviert werden. Eine Zusammensetzungsgrenze ist wichtig: ein Bucket mit aktiviertem Object Lock kann nicht die Quelle für Replikation oder Tiering sein, obwohl es das Ziel sein kann. Wenn FinCorp sowohl ein gesperrtes Archiv als auch eine ausgehende Replikation aus demselben Datenbestand benötigt, muss die Replikation aus einem ungesperrten Bucket stammen und das gesperrte Ziel sein.

Lebenszyklusregeln befassen sich mit den Kosten. Eine Konfiguration kann bis zu 1.000 Regeln enthalten, von denen jede auf alle Objekte oder auf ein einzelnes Präfix (eine Regel pro Präfix) angewendet wird. Die Aktionen sind: aktuelle Versionen nach einer bestimmten Anzahl von Tagen oder an einem bestimmten Datum ablaufen lassen; nicht aktuelle Versionen dauerhaft löschen; abgelaufene Objekt-Löschmarkierungen löschen; und unvollständige Mehrteil-Uploads löschen. Da nur der STANDARD-Speicherclass vorhanden ist, kann der Lebenszyklus keine Objekte in eine günstigere Ebene verschieben; hier ist es ein Ablauf- und Bereinigungstool, kein Tiering-Tool. Es paart sich natürlicherweise mit Object Lock: der COMPLIANCE-Lock garantiert, dass die Daten mindestens die Aufbewahrungsfrist überleben, während eine Lebenszyklus-Ablaufregel garantiert, dass sie nicht verweilen und Kosten verursachen, sobald die Verpflichtung abgelaufen ist. Setzen Sie das Ablaufdatum auf oder über die Lock-Aufbewahrungsfrist, damit die beiden nie in Konflikt geraten.

3. DCD Implementierung Schritt-für-Schritt

Sie erstellen das FinCorp-Audit- und Sicherungsarchiv: ein vertragsbesitzter Bucket in einer deutschen Region, mit Object Lock aktiviert im COMPLIANCE-Modus bei der Erstellung und einer Lebenszyklusregel, die Objekte nach Ablauf ihrer Aufbewahrungsfrist verfallen lässt. Dies realisiert die manipulationsfesten Aufbewahrungsstufe, auf die die Audit-Exporte von Einheit 2.3 und die Sicherungen von Einheit 5.7 angewiesen sind.

Ziel: Erstellen Sie einen Bucket, legen Sie Object Lock und eine Lebenszykluspolitik fest.

Voraussetzungen: Ein Benutzer mit der Berechtigung zur Verwendung von Object Storage (über Gruppenmitgliedschaft, Einheit 2.2) und ein für diesen Benutzer generierter Object Storage-Schlüssel. Die erste Schlüsselgenerierung ist auch das, was die Canonical User ID benötigt, um später den Zugriff zwischen Benutzern zu gewähren.

Schritte (in der Data Center Designer):

1. Öffnen Sie den Object Storage-Bereich von DCD und gehen Sie zum Buckets-Tab. Wählen Sie entweder einen benutzerbesitzten oder vertragsbesitzten Bucket; für das FinCorp-Archiv erstellen Sie einen vertragsbesitzten Bucket, damit die Governance beim Vertragsbesitzer bleibt.
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 zulässigen Satzes für den Bucket-Typ (für einen vertragsbesitzten Bucket, eu-central-4 Frankfurt oder eu-central-3 Berlin), um das Archiv innerhalb des C5 und des IT-Grundschutz-Umfelds zu halten.
3. Aktivieren Sie Object Lock während dieses Erstellungsschritts. Dies ist die einzige Gelegenheit, es zu aktivieren; es kann nicht später hinzugefügt werden, und die Aktivierung ermöglicht auch die Versionierung. Erstellen Sie den Bucket.
4. Nach der Erstellung öffnen Sie den Bucket, klicken auf Bucket-Einstellungen und gehen zum Object Lock-Einstellung unter dem Datenmanagement-Bereich. Setzen Sie den Modus auf COMPLIANCE und die Aufbewahrungsfrist auf den regulatorischen Horizont (bis zu 365 Tagen über DCD). Diese Standardwerte gelten für neu hochgeladene Objekte; Objekte, die bereits vorhanden sind, folgen den Einstellungen, die bei der Erstellung angewendet wurden.
5. Immer noch in den Bucket-Einstellungen, gehen Sie zum Lebenszyklus-Einstellung unter Datenmanagement und klicken auf Eine Regel hinzufügen.
6. Geben Sie der Lebenszyklusregel einen eindeutigen Namen und legen Sie ihren Umfang 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 Lebenszyklus-Aktionen. Für das Archiv wählen Sie Verfallen der aktuellen Versionen nach einer Anzahl von Tagen, die der Aufbewahrungsfrist entspricht oder diese überschreitet, und fügen Sie Permanentes Löschen nicht aktueller Versionen und Löschen unvollständiger Uploads hinzu, um die Kosten durch Versionierung und fehlgeschlagene Uploads zu kontrollieren. Speichern Sie die Regel.
8. Überprüfen Sie in der Bucket-Liste, dass der Bucket den richtigen Typ, die Region und das Erstellungsdatum zeigt und bestätigen Sie, dass die Object Lock- und Lebenszyklus-Einstellungen unter den Bucket-Einstellungen vorhanden sind.

Häufige Fehler:

• Vergessen von Object Lock bei der Erstellung. Es kann nicht auf einem bestehenden Bucket aktiviert werden. Wenn Sie es verpassen, müssen Sie einen neuen Bucket erstellen und die Daten migrieren. Entscheiden Sie sich für WORM, bevor Sie auf Erstellen klicken.
• Wählen von COMPLIANCE-Modus ohne Sicherheit. Im COMPLIANCE-Modus können Sie die Aufbewahrungsfrist nicht verkürzen oder die Sperre deaktivieren, auch nicht als Bucket-Besitzer. Verwenden Sie GOVERNANCE während des Testens und reservieren Sie COMPLIANCE für Daten, deren Aufbewahrungsanforderung fest ist.
• Wählen der falschen Region für die Residenz. Die Region ist bei der Erstellung festgelegt und bestimmt den Endpunkt. Eine US-Region (us-central-1) legt das Audit-Archiv einer deutschen Firma außerhalb des deutschen Rechenzentrums-Umfelds der BSI-Anmeldeinformationen. Entscheiden Sie sich für die Residenz, bevor Sie den Bucket-Namen festlegen.
• Annehmen, dass ein nicht eindeutiger Bucket-Name funktioniert. Namen sind global eindeutig über alle Object Storage-Instanzen hinweg, nicht nur innerhalb Ihres Vertrags. Benennen Sie sie (zum Beispiel durch Voranstellen der Organisation), um Kollisionen zu vermeiden.
• Erwarten, dass der Lebenszyklus auf ein billigeres Speichermedium umstellt. Es existiert nur die STANDARD-Klasse, sodass Lebenszyklusregeln verfallen und aufräumen; sie bewegen Objekte nicht auf ein kälteres Medium. Die Kostenkontrolle erfolgt durch Löschung, nicht durch Umstellung.
• Verbinden der Replikation aus einem gesperrten Bucket. Ein Bucket mit aktiviertem Object Lock kann nicht die Quelle für Replikation oder Umstellung sein. Wenn Sie Replikation benötigen, initiieren Sie sie aus einem ungesperrten Bucket und machen das gesperrte Archiv zum Ziel.

Ein kurzer S3-Client-Äquivalent macht die Erstellungsnatur von Object Lock konkreter; die Flagge wird auf create-bucket gesetzt und hat keine Nachträglichkeits-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 die Architektur der dauerhaften, S3-kompatiblen, großvolumigen Sicherung: Audit-Archiv, Sicherungsziel, Datensatz- und Artefakt-Speicher sowie Dead-Letter-Schwanz. Seine Macht als Compliance-Tier kommt von zwei Entscheidungen, die einmal bei der Erstellung getroffen werden: Bucket-Typ mit seiner Regionsbeschränkung und Object Lock, sowie von Lebenszyklusregeln, die für die Kosteneinflussnahme aufgesetzt werden. Der Typ, die Region und das Lock müssen bei der Erstellung richtig gewählt werden, da keines von ihnen danach geändert werden kann.

Wichtige Punkte:

• Object Storage verwendet das AWS S3 API (v2), ein flaches Objekt- und Bucket-Namensraum, und Access Key plus Secret Key Authentifizierung (92 und 64 Zeichen; bis zu 5 Schlüssel pro Benutzer); Objekte können bis zu 5 TiB erreichen und die einzige Klasse ist STANDARD.
• Bucket-Typ (vertragsbesitzt vs benutzerbesitzt) ist bei der Erstellung gebunden und beschränkt die verfügbaren Regionen; vertragsbesitzt eignet sich für eine zentrale Governance, und Bucket-Namen sind global eindeutig.
• Object Lock liefert WORM im GOVERNANCE- oder COMPLIANCE-Modus, muss bei der Erstellung aktiviert werden (kann nicht später hinzugefügt werden), aktiviert auch die Versionierung und ist im COMPLIANCE-Modus unumkehrbar; DCD-Aufbewahrungsfrist beträgt bis zu 365 Tage, die des API bis zu 100 Jahren.
• Lebenszyklusregeln (bis zu 1.000, auf alle Objekte oder ein Präfix beschränkt) verfallen und bereinigen Objekte für die Kosteneinflussnahme, können jedoch nicht auf eine günstigere Klasse umgestellt werden, da nur STANDARD existiert.
• Platzieren Sie das Audit- und Sicherungsarchiv von FinCorp in einer deutschen Region mit COMPLIANCE-Modus Object Lock, um es manipulationsfest zu halten und innerhalb des BSI C5 und IT-Grundschutz-Serviceumfangs zu behalten.

Wichtige Begriffe:

• Object Lock (WORM): Write Once Read Many Aufbewahrung, die auf Objekte angewendet wird; GOVERNANCE ermöglicht eine privilegierte Überschreibung, COMPLIANCE ist unveränderlich bis zum Aufbewahrungsdatum und kann nicht verkürzt oder deaktiviert werden.
• Lebenszyklusregel: Eine automatisierte Aktion (Verfallen der aktuellen Versionen, Löschen nicht aktueller Versionen, Löschen abgelaufener Löschtitel, Löschen unvollständiger Mehrteil-Uploads), die auf ein Bucket oder ein einzelnes Objektpräfix beschränkt ist.
• Vertragsbesitzt vs benutzerbesitzt Bucket: Das Eigentums- und Sichtbarkeitsmodell, das bei der Erstellung festgelegt wird und auch bestimmt, welche Regionen und Endpunkte verfügbar sind.

Weitere Lektüre

• Einheit 2.3, Activity Logs und die Audit-Trail (die 35-Tage-Exportfrist, die dieses Archiv erfüllt).
• Einheit 5.7, Datenschutz und Lebenszyklus (Zusammensetzen von Sicherung, Snapshots, PITR und Object-Storage-Archiv zu einer Kontinuitätsebene).
• Einheit 5.1, Block- und Dateispeicher (wenn regionale gemeinsame Datei oder einzelnes VM-Block besser geeignet ist als Objekt).