Unité 5.2 : Object Storage

Introduction

Object Storage est le point de référence de l'architecture des données. C'est là que les exports de journaux d'audit de l'unité 2.3 atterrissent pour leur vie à long terme, avec preuve de non-altération, où les dumps de Backup Service et de base de données sont transférés vers REST, où les jeux de données ML et les artefacts de construction sont stockés, et où les lettres mortes de diffusion d'événements s'accumulent. Il occupe cette position parce qu'il est durable, compatible S3, et tarifé pour le bulk. Les deux décisions qui font ou détruisent cela, cependant, sont prises une fois et ne peuvent pas être annulées : le type et la région du bucket, et si Object Lock est activé. Cette unité traite ces décisions en premier, puis crée le bucket dans le Data Center Designer avec les verrous et les règles de cycle de vie qui transforment le stockage brut en un niveau de rétention conforme.

1. Ce qu'est Object Storage et les rôles qu'il joue

IONOS Cloud Object Storage est conforme au S3 API d'AWS (v2 du protocole S3), donc les mêmes outils, SDK et applications qui ciblent les plateformes compatibles S3 fonctionnent avec lui. Les données sont stockées dans un espace de noms plat : des objets (chacun portant des métadonnées et une clé unique) à l'intérieur de buckets, sans arbre de répertoires réel en dessous. L'authentification est effectuée par une paire de clé d'accès et de clé secrète générée par utilisateur (92 et 64 caractères dans le format actuel, jusqu'à 5 clés par utilisateur) ; le DCD utilise ces informations d'identification pour piloter l'interface web, et la même paire est ce que tout client S3 ou SDK présente. Un objet unique peut atteindre 5 To, et la seule classe de stockage est STANDARD. La tarification est à la demande sur le stockage et le transfert sortant par gigaoctet, sans frais par requête, ce qui explique pourquoi les charges de travail de stockage en bloc et d'archivage atterrissent ici plutôt que sur Block Storage.

Ces propriétés déterminent où Object Storage s'intègre dans l'architecture de FinCorp :

• Archive d'audit. Les Activity Logs sont par contrat, en lecture seule, et conservés pendant seulement 35 jours (Unité 2.3). Les exporter vers un bucket avant la fin de cette période donne à FinCorp la rétention de plusieurs années, avec preuve de non-altération, que ses régulateurs attendent. Object Lock (Section 2) est ce qui rend cette archive avec preuve de non-altération.
• Cible de sauvegarde. Les Backup Service et la sortie de dump/restore de base de données (Unités 5.3, 5.7) écrivent ici. Notez la limite honnête : la portée de Backup Service (Acronis) est les machines virtuelles et Block Storage, elle ne sauvegarde pas les bases de données gérées, et elle ne fournit pas de sauvegardes immuables elle-même. Object Lock sur le bucket de destination est comment FinCorp ajoute l'immutabilité que Backup Service ne fournit pas.
• Magasin de jeux de données et d'artefacts. Le niveau IA (Module 6) lit son corpus de formation et stocke des artefacts de modèle ici ; un corpus de génération augmentée de récupération construit par le client vit également dans Object Storage. L'espace de noms plat est bien adapté à de grands volumes de données non structurées en dehors d'une base de données.
• Destination de lettres mortes. Les Kafka gérés (Unité 5.6) écrivent leur archive et leur queue de lettres mortes dans un bucket, où les enregistrements non traités s'accumulent à faible coût pour une inspection ultérieure.

Les cas d'utilisation documentés de la plateforme comprennent également le stockage d'actifs de site Web, l'hébergement de sites Web statiques, l'hébergement d'actifs multimédias et le stockage de fichiers privés ; pour FinCorp, la sauvegarde/restauration et le stockage de données non structurées sont les utilisations principales.

2. Les deux décisions irréversibles : type de bucket, région et verrouillage d'objet

2.1 Type de bucket et région liés à la création

Un bucket est soit possédé par le contrat ou possédé par l'utilisateur, et le type contraint également les régions disponibles. Cela modifie la propriété, la visibilité et les points de terminaison qui servent le bucket.

• Les buckets possédés par le contrat font du propriétaire du contrat le propriétaire de chaque bucket. Tout utilisateur du contrat peut voir la liste complète des buckets, et le propriétaire du contrat ou un administrateur accorde l'accès et définit les autorisations via les paramètres de stratégie de bucket. C'est le modèle approprié pour une organisation unique comme FinCorp qui souhaite une gouvernance centralisée.
• Les buckets possédés par l'utilisateur sont possédés de manière indépendante par chaque utilisateur, qui les crée et les gère sans l'approbation du propriétaire du contrat, sans liste combinée entre les utilisateurs. Cela précède les buckets possédés par le contrat et convient aux cas où les utilisateurs sont des entités distinctes.

La sélection de la région est contrainte par le type. Les deux tableaux ci-dessous sont les listes de régions autorisées par type de bucket.

Les buckets possédés par le contrat ne peuvent être créés que dans les régions suivantes :

Les buckets possédés par l'utilisateur ne peuvent être créés que dans les régions suivantes :

Chaque région a son propre URL de point de terminaison, et un nom de bucket doit être universellement unique dans tout Object Storage (3 à 63 caractères). La région est importante pour la proximité (latence et coût de sortie près de l'application ou des utilisateurs) et pour la redondance (une sauvegarde ou un archive appartient à une région géographiquement distincte de la principale afin qu'elle survive à une panne locale). Pour FinCorp sous GDPR et BSI, c'est la décision de résidence de l'unité 1.4 appliquée en pratique : garder l'archive d'audit et les sauvegardes de base de données dans des centres de données allemands (de, eu-central-3, ou eu-central-4) plutôt que us-central-1. Le service S3 Object Storage est couvert à la fois par l'attestation de type 1 de BSI C5 (accordée le 2023-11-07, centres de données allemands) et le certificat ISO 27001 basé sur IT-Grundschutz (accordé le 2022-09-14) ; placer l'archive dans une région allemande est ce qui la maintient dans cette portée. La durabilité entre régions est atteinte grâce à la réplication que vous concevez, et non à une propriété automatique d'un seul bucket.

2.2 Verrouillage d'objet et cycle de vie : preuve de non-altération et contrôle des coûts

Le verrouillage d'objet met en œuvre Write Once Read Many (WORM) : un objet ne peut pas être effacé ou modifié pendant une période de rétention. Il a deux modes :

• Le mode GOVERNANCE protège les objets contre la suppression ordinaire tout en permettant aux utilisateurs privilégiés de contourner le verrou.
• Le mode COMPLIANCE est absolu : jusqu'à ce que la date de rétention passe, l'objet est immuable, le mode ne peut pas être désactivé, et la période de rétention ne peut pas être raccourcie, même par le propriétaire du bucket. C'est le mode pour l'archive réglementaire de FinCorp, où l'exigence est que personne, y compris un administrateur, ne peut altérer la preuve.

La rétention peut être configurée jusqu'à 365 jours via DCD ; API prend en charge jusqu'à 100 ans. La contrainte décisive est la chronologie : le verrouillage d'objet ne peut être activé que lorsque le bucket est créé, et non ajouté par la suite. L'activation de celui-ci active également la versionnage, et une fois activé, ni l'un ni l'autre ne peut être désactivé. Une limite de composition compte : un bucket avec le verrouillage d'objet activé ne peut pas être une source pour la réplication ou le tiering, bien qu'il puisse en être la destination. Si FinCorp a besoin à la fois d'un archive verrouillé et d'une réplication sortante à partir des mêmes données, la réplication doit provenir d'un bucket non verrouillé et cibler le bucket verrouillé.

Les règles de cycle de vie traitent des coûts. Une configuration peut contenir jusqu'à 1 000 règles, chacune étant étendue à tous les objets ou à un seul préfixe (une règle par préfixe). Les actions sont : expirer les versions actuelles après un certain nombre de jours ou à une date ; supprimer définitivement les versions non actuelles ; supprimer les marqueurs de suppression d'objets expirés ; et supprimer les téléchargements multipartis incomplets. Puisque la seule classe de stockage est STANDARD, le cycle de vie ne peut pas transiter les objets vers un niveau moins cher ; ici, il s'agit d'un outil d'expiration et de nettoyage, et non d'un outil de tiering. Il s'associe naturellement au verrouillage d'objet : le verrou COMPLIANCE garantit que les données survivent au moins à la période de rétention, tandis qu'une règle d'expiration du cycle de vie garantit qu'elles ne persistent pas et n'engendrent pas de coûts une fois l'obligation expirée. Définissez l'expiration à ou au-delà de la rétention du verrou afin que les deux ne soient jamais en conflit.

3. DCD Implementation Walkthrough

Vous allez créer l'archive d'audit et de sauvegarde de FinCorp : un seau appartenant à un contrat dans une région allemande, avec Object Lock activé en mode COMPLIANCE lors de la création, et une règle de cycle de vie qui expire les objets une fois que leur obligation de rétention a expiré. Cela réalise le niveau de rétention tampon qui dépend de l'exportation d'audit de l'unité 2.3 et des sauvegardes de l'unité 5.7.

Objectif de construction : Créer un seau, définir un verrou d'objet et une politique de cycle de vie.

Prérequis : Un utilisateur avec le privilège d'utilisation de Object Storage (accordé via l'appartenance à un groupe, unité 2.2), et une clé Object Storage générée pour cet utilisateur. La première génération de clé est également ce qui permet d'accéder à l'ID d'utilisateur canonique nécessaire pour accorder l'accès entre utilisateurs plus tard.

Étapes (dans le Data Center Designer) :

1. Ouvrez la section Object Storage de DCD et allez à l'onglet Seaux. Choisissez de créer un seau appartenant à un utilisateur ou à un contrat ; pour l'archive de FinCorp, créez un seau appartenant à un contrat afin que la gouvernance reste avec le propriétaire du contrat.
2. Entrez un nom de seau unique dans le monde (3 à 63 caractères) et sélectionnez la région. Pour l'archive de FinCorp, choisissez une région allemande dans l'ensemble autorisé du type de seau (pour un seau appartenant à un contrat, eu-central-4 Francfort ou eu-central-3 Berlin), en gardant l'archive à l'intérieur de C5 et de la portée IT-Grundschutz.
3. Activez Object Lock pendant cette étape de création. C'est la seule occasion de l'activer ; il ne peut pas être ajouté par la suite, et l'activer active également la versionnage. Créez le seau.
4. Après la création, ouvrez le seau, cliquez sur Paramètres du seau, et allez au paramètre Object Lock sous la section Gestion des données. Définissez le mode sur COMPLIANCE et la période de rétention sur l'horizon réglementaire (jusqu'à 365 jours via DCD). Ces valeurs par défaut s'appliquent aux objets nouvellement téléchargés ; les objets déjà présents suivent les paramètres appliqués lors de la création.
5. Toujours dans les paramètres du seau, allez au paramètre Cycle de vie sous Gestion des données et cliquez sur Ajouter une règle.
6. Donnez un nom unique à la règle de cycle de vie et définissez sa portée : tous les objets, ou les objets limités à un seul préfixe (chaque préfixe ne peut avoir qu'une seule règle).
7. Sélectionnez les actions de cycle de vie. Pour l'archive, choisissez Expirer les versions actuelles après un certain nombre de jours qui répond ou dépasse la rétention du verrou, et ajoutez Supprimer définitivement les versions non actuelles et Supprimer les téléchargements multipartis incomplets pour contrôler les coûts liés au versionnage et aux téléchargements échoués. Enregistrez la règle.
8. Vérifiez dans la liste des seaux que le seau affiche le type correct, la région et la date de création, et confirmez que les paramètres Object Lock et cycle de vie sont présents sous les paramètres du seau.

Erreurs courantes :

• Oublier Object Lock lors de la création. Il ne peut pas être activé sur un seau existant. Si vous le manquez, vous devez créer un nouveau seau et migrer les données. Déterminez WORM avant de cliquer sur Créer.
• Choisir le mode COMPLIANCE sans certitude. En mode COMPLIANCE, vous ne pouvez pas raccourcir la rétention ou désactiver le verrou, même en tant que propriétaire du seau. Utilisez GOVERNANCE pendant les tests et réservez COMPLIANCE pour les données dont la rétention est ferme.
• Choisir la mauvaise région pour la résidence. La région est fixée lors de la création et dicte le point de terminaison. Une région américaine (us-central-1) place l'archive d'audit d'une entreprise allemande en dehors de la portée du centre de données allemand des informations d'identification BSI. Déterminez la résidence avant de nommer le seau.
• Supposer qu'un nom de seau non unique fonctionnera. Les noms sont uniques dans le monde entier pour tous les Object Storage, et non seulement pour votre contrat. Espacez-les (par exemple, préfixez-les avec l'organisation) pour éviter les collisions.
• S'attendre à ce que le cycle de vie répartisse les données sur un stockage moins coûteux. Seule la classe STANDARD existe, donc les règles de cycle de vie expirent et nettoient ; elles ne déplacent pas les objets vers un niveau plus froid. Le contrôle des coûts vient de la suppression, et non du répartition.
• Brancher la réplication à partir d'un seau verrouillé. Un seau avec Object Lock activé ne peut pas être une source de réplication ou de répartition. Si vous avez besoin de réplication, originez-la à partir d'un seau non verrouillé et faites du seau d'archive verrouillé la destination.

Un court équivalent de client S3 rend la nature de création d'Object Lock concrète ; le drapeau est défini sur create-bucket et n'a pas de contrepartie d'ajout plus tard :

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

Résumé

Object Storage est l'architecture solide, compatible S3, et à prix en gros : archive d'audit, cible de sauvegarde, magasin de données et d'artefacts, et queue de lettres mortes. Son pouvoir en tant que niveau de conformité vient de deux décisions prises une fois lors de la création, le type de bucket avec sa contrainte de région, et Object Lock, et des règles de cycle de vie superposées pour le contrôle des coûts. Assurez-vous de choisir le bon type, la bonne région et le bon verrouillage lors de la création, car aucun d'entre eux ne peut être modifié par la suite.

Points clés :

• Object Storage utilise l'AWS S3 API (v2), un espace de noms d'objets et de buckets plat, et une authentification par clé d'accès et clé secrète (92 et 64 caractères ; jusqu'à 5 clés par utilisateur) ; les objets peuvent atteindre 5 To et la seule classe est STANDARD.
• Le type de bucket (appartenant au contrat ou à l'utilisateur) est lié à la création et restreint les régions disponibles ; le type appartenant au contrat convient à une gouvernance centralisée, et les noms de buckets sont uniques à l'échelle mondiale.
• Object Lock offre WORM en mode GOVERNANCE ou COMPLIANCE, doit être activé lors de la création (ne peut pas être ajouté plus tard), active également la versionning, et en mode COMPLIANCE est irréversible ; la rétention DCD est de jusqu'à 365 jours, celle de API de jusqu'à 100 ans.
• Les règles de cycle de vie (jusqu'à 1 000, étendues à tous les objets ou à un seul préfixe) expirent et nettoient les objets pour le contrôle des coûts, mais ne peuvent pas être hiérarchisés dans une classe moins chère, puisque seule la classe STANDARD existe.
• Placez l'archive d'audit et de sauvegarde de FinCorp dans une région allemande avec Object Lock en mode COMPLIANCE pour la garder à l'épreuve des manipulations et à l'intérieur de la portée du service BSI C5 et IT-Grundschutz.

Terminologie importante :

• Object Lock (WORM) : Rétention Write Once Read Many appliquée aux objets ; GOVERNANCE permet une override privilégiée, COMPLIANCE est immuable jusqu'à la date de rétention et ne peut pas être raccourcie ou désactivée.
• Règle de cycle de vie : Une action automatisée (expiration des versions actuelles, suppression des versions non actuelles, suppression des marqueurs de suppression expirés, suppression des téléchargements multipartis incomplets) étendue à un bucket ou à un seul préfixe d'objet.
• Bucket appartenant au contrat ou à l'utilisateur : Le modèle de propriété et de visibilité, fixé lors de la création, qui détermine également quels régions et points de terminaison sont disponibles.

Lecture supplémentaire

• Unité 2.3, Activity Logs et la piste d'audit (la limite d'export de 35 jours que cette archive satisfait).
• Unité 5.7, Protection des données et cycle de vie (composition de la sauvegarde, des instantanés, de PITR et de l'archive d'Object-Storage en un plan de continuité).
• Unité 5.1, Stockage de blocs et de fichiers (lorsqu'un fichier partagé régional ou un bloc unique VM convient mieux qu'un objet).