Unité 5.2 : Object Storage

Introduction

Object Storage constitue le filet de sécurité de l'architecture des données. C'est là que les exports des journaux d'audit de l'unité 2.3 sont déposés pour leur conservation à long terme, avec une détection des altérations, là que les sauvegardes de Backup Service et les extractions de bases de données sont stockées, là que les jeux de données pour l'apprentissage automatique et les artefacts de compilation sont conservés, et là que les messages morts des flux d'événements s'accumulent. Object Storage occupe cette position car il est durable, compatible S3 et proposé à un prix adapté au stockage en volume. Les deux décisions qui déterminent son efficacité sont toutefois prises une seule fois et ne peuvent pas être annulées : le type et la région du bucket, ainsi que l'activation ou non de Object Lock. Cette unité aborde d'abord ces décisions, puis crée le bucket dans Data Center Designer avec les verrous et les règles de cycle de vie qui transforment le stockage brut en niveau de rétention conforme.

1. Qu'est-ce que le stockage objet et les rôles qu'il joue

IONOS Cloud Object Storage est conforme à l'API AWS S3 (version 2 du protocole S3), de sorte que les mêmes outils, SDK et applications destinés aux plateformes compatibles S3 peuvent l'utiliser. 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 véritable arborescence de répertoires en dessous. L'authentification s'effectue par une paire Access Key et Secret Key générée pour chaque utilisateur (92 et 64 caractères dans le format actuel, jusqu'à 5 clés par utilisateur) ; le DCD utilise ces identifiants pour piloter l'interface web, et c'est la même paire que tout client S3 ou SDK présente. Un objet unique peut atteindre 5 TiB, et la seule classe de stockage est STANDARD. La tarification est au paiement à l'usage pour le stockage et le transfert sortant par gigaoctet, sans frais par requête, ce qui explique pourquoi les charges de travail en masse et d'archivage sont placées ici plutôt que sur Block Storage.

Ces propriétés déterminent la place du stockage objet dans l'architecture de FinCorp :

• Archive d'audit. Les Activity Logs sont par contrat, en lecture seule, et conservés pendant 35 jours seulement (Unité 2.3). Les exporter vers un bucket avant la fin de cette fenêtre permet à FinCorp d'obtenir la rétention multi-années, infalsifiable, attendue par ses régulateurs. Object Lock (section 2) est ce qui rend cette archive infalsifiable.
• Cible de sauvegarde. Backup Service et les sorties de déchargement/restauration de bases de données (unités 5.3, 5.7) y écrivent. Notez la limite honnête : le périmètre de Backup Service (Acronis) couvre les VM et Block Storage, il ne sauvegarde pas les bases de données managées, et il ne fournit pas lui-même de sauvegardes immuables. Object Lock sur le bucket de destination est la manière dont FinCorp ajoute l'immuabilité que Backup Service ne fournit pas.
• Stockage de jeux de données et d'artefacts. La couche IA (Module 6) y lit son corpus d'entraînement et y stocke les artefacts de modèles ; un corpus de génération augmentée par récupération construit par un client est également hébergé dans le stockage objet. L'espace de noms à plat est bien adapté aux grands volumes de données non structurées en dehors d'une base de données.
• Destination de messages en échec. Kafka managé (Unité 5.6) y écrit son archive et sa file de messages en échec, où les enregistrements non traités s'accumulent à moindre coût pour inspection ultérieure.

Les cas d'utilisation documentés de la plateforme incluent é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 usages principaux.

2. Les deux décisions irréversibles : type de bucket, région et Object Lock

2.1 Le type de bucket et la région sont liés à la création

Un bucket est soit contract-owned (appartenant au contrat), soit user-owned (appartenant à l'utilisateur), et le type restreint également les régions disponibles. Il modifie la propriété, la visibilité et les points de terminaison qui servent le bucket.

• Les buckets contract-owned font du propriétaire du contrat le propriétaire de chaque bucket. Chaque 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 Bucket Policy. C'est le modèle approprié pour une organisation unique comme FinCorp qui souhaite une gouvernance centralisée.
• Les buckets user-owned sont possédés indépendamment 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. Ce modèle précède les buckets contract-owned et convient aux cas où les utilisateurs sont des entités distinctes.

Le choix de la région est contraint par le type. Les deux tableaux ci-dessous sont les listes officielles des régions par type de bucket.

Les buckets contract-owned ne peuvent être créés que dans les régions suivantes :

Les buckets user-owned ne peuvent être créés que dans les régions suivantes :

Chaque région dispose de sa propre URL de point de terminaison, et un nom de bucket doit être unique au niveau mondial dans l'ensemble d'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 une archive doit se trouver dans une région géographiquement distincte de la région principale afin de survivre à une panne locale). Pour FinCorp, au regard du RGPD et du BSI, il s'agit de la décision de résidence appliquée en pratique depuis l'Unité 1.4 : conserver 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 dans us-central-1. Le service S3 Object Storage est couvert à la fois par l'attestation BSI C5 Type 1 (accordée le 2023-11-07, centres de données allemands) et par le certificat ISO 27001 basé sur l'IT-Grundschutz (accordé le 2022-09-14) ; placer l'archive dans une région allemande est ce qui la maintient dans ce périmètre. La durabilité inter-régions est obtenue par une réplication que vous concevez, et non par une propriété automatique d'un bucket.

2.2 Object Lock et cycle de vie : preuve d'intégrité et contrôle des coûts

Object Lock implémente le mode Write Once Read Many (WORM) : un objet ne peut ni être effacé ni modifié pendant une période de rétention. Il comporte deux modes :

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

La rétention peut être configurée jusqu'à 365 jours via le DCD ; l'API prend en charge jusqu'à 100 ans. La contrainte décisive est le moment : Object Lock ne peut être activé que lors de la création du bucket, et jamais ajouté par la suite. Son activation active également le versioning, et une fois activé, ni l'un ni l'autre ne peuvent être désactivés. Une limite de composition est importante : un bucket avec Object Lock activé ne peut pas être une source pour la réplication ou le tiering, bien qu'il puisse être une destination. Si FinCorp a besoin à la fois d'une archive verrouillée 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 limitée à tous les objets ou à un préfixe unique (une règle par préfixe). Les actions sont : expirer les versions actuelles après un certain nombre de jours ou à une date donnée ; supprimer définitivement les versions non actuelles ; supprimer les marqueurs de suppression d'objets expirés ; et supprimer les téléchargements multipart incomplets. Étant donné que la seule classe de stockage est STANDARD, le cycle de vie ne peut pas faire passer les objets vers un niveau moins coûteux ; ici, c'est un outil d'expiration et de nettoyage, et non un outil de tiering. Il s'associe naturellement à Object Lock : le verrouillage COMPLIANCE garantit que les données survivent au moins pendant 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. Réglez l'expiration à la date de rétention du verrouillage ou après, afin que les deux ne soient jamais en conflit.

3. Déroulement de la mise en œuvre de DCD

Vous allez créer l'archive d'audit et de sauvegarde de FinCorp : un bucket appartenant au contrat dans une région allemande, avec Object Lock activé en mode COMPLIANCE à la création, et une règle de cycle de vie qui expire les objets une fois que leur obligation de rétention est écoulée. Cela réalise la couche de rétention infalsifiable sur laquelle dépendent l'export d'audit de l'unité 2.3 et les sauvegardes de l'unité 5.7.

Objectif de construction : Créer un bucket, configurer le verrouillage des objets et une politique de cycle de vie.

Prérequis : Un utilisateur disposant du privilège Use 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 fait apparaître l'identifiant d'utilisateur canonique (Canonical User ID) nécessaire pour accorder un accès inter-utilisateurs ultérieurement.

Étapes (dans Data Center Designer) :

1. Ouvrez la section Object Storage de DCD et accédez à l'onglet Buckets. Choisissez de créer un bucket appartenant à un utilisateur ou un bucket appartenant à un contrat ; pour l'archive FinCorp, créez un bucket appartenant à un contrat afin que la gouvernance reste entre les mains du propriétaire du contrat.
2. Saisissez un nom de bucket unique au niveau mondial (de 3 à 63 caractères) et sélectionnez la région. Pour l'archive FinCorp, choisissez une région allemande au sein de l'ensemble autorisé par le type de bucket (pour un bucket appartenant à un contrat, eu-central-4 Francfort ou eu-central-3 Berlin), en gardant l'archive dans le périmètre de C5 et d'IT-Grundschutz.
3. Activez Object Lock lors de cette étape de création. C'est la seule occasion de l'activer ; il ne peut pas être ajouté ultérieurement, et son activation active également le versioning. Créez le bucket.
4. Après la création, ouvrez le bucket, cliquez sur Paramètres du bucket, et accédez 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éversés ; les objets déjà présents suivent les paramètres appliqués à la création.
5. Toujours dans Paramètres du bucket, accédez au paramètre Cycle de vie sous Gestion des données et cliquez sur Ajouter une règle.
6. Donnez à la règle de cycle de vie un nom unique et définissez son périmètre : tous les objets, ou des objets limités à un préfixe unique (chaque préfixe ne peut porter qu'une seule règle).
7. Sélectionnez les actions de cycle de vie. Pour l'archive, choisissez Expire les versions actuelles après un nombre de jours qui satisfait ou dépasse la rétention du verrouillage, et ajoutez Supprimer définitivement les versions non actuelles et Supprimer les téléversements multipart incomplets pour contrôler les coûts liés au versioning et aux téléversements échoués. Enregistrez la règle.
8. Vérifiez dans la liste des Buckets que le bucket affiche le type, la région et la date de création corrects, et confirmez que les paramètres Object Lock et de cycle de vie sont présents sous Paramètres du bucket.

Erreurs courantes :

• Oublier Object Lock à la création. Il ne peut pas être activé sur un bucket existant. Si vous l'oubliez, vous devez créer un nouveau bucket et migrer les données. Décidez du WORM avant de cliquer sur Créer.
• Choisir le mode COMPLIANCE sans certitude. En mode COMPLIANCE, vous ne pouvez pas raccourcir la rétention ni désactiver le verrouillage, même en tant que propriétaire du bucket. Utilisez GOVERNANCE pendant les tests et réservez COMPLIANCE pour les données dont l'exigence de rétention est ferme.
• Choisir la mauvaise région pour la résidence. La région est fixée à la création et détermine le point d'accès. Une région américaine (us-central-1) place l'archive d'audit d'une entreprise allemande hors du périmètre des centres de données allemands des accréditations BSI. Décidez de la résidence avant de nommer le bucket.
• Supposer qu'un nom de bucket non unique fonctionnera. Les noms sont uniques au niveau mondial sur l'ensemble d'Object Storage, et non seulement sur votre contrat. Espacez-les (par exemple, préfixez avec l'organisation) pour éviter les collisions.
• S'attendre à ce que le cycle de vie classe vers un stockage moins cher. Seule la classe STANDARD existe, donc les règles de cycle de vie expirent et nettoient ; elles ne déplacent pas les objets vers une couche plus froide. Le contrôle des coûts provient de la suppression, pas du classement.
• Configurer la réplication en dehors d'un bucket verrouillé. Un bucket avec Object Lock activé ne peut pas être une source de réplication ou de classement. Si vous avez besoin de réplication, faites-la partir d'un bucket non verrouillé et faites de l'archive verrouillée la destination.

Un équivalent client S3 court rend concret le caractère exclusif à la création d'Object Lock ; le drapeau est défini sur create-bucket et n'a pas d'équivalent d'ajout ultérieur :

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 constitue le filet de sécurité durable, compatible S3 et au tarif par volume de l'architecture : archive d'audit, cible de sauvegarde, dépôt de jeux de données et d'artefacts, et file de messages en échec. Son efficacité en tant que niveau de conformité repose sur deux décisions prises une seule fois lors de la création, le type de bucket avec sa contrainte de région, et Object Lock, ainsi que sur des règles de cycle de vie superposées pour le contrôle des coûts. Il convient de bien définir le type, la région et le verrouillage lors de la création, car aucun de ces paramètres ne peut être modifié ultérieurement.

Points clés :

• Object Storage utilise l'API AWS S3 (v2), un espace de noms à plat pour les objets et les buckets, ainsi que l'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 TiB et la seule classe disponible est STANDARD.
• Le type de bucket (appartenant au contrat ou appartenant à l'utilisateur) est fixé lors de la création et restreint les régions disponibles ; le type appartenant au contrat convient à la gouvernance centralisée, et les noms de buckets sont uniques au niveau mondial.
• Object Lock offre une rétention WORM en mode GOVERNANCE ou COMPLIANCE, doit être activé lors de la création (il ne peut pas être ajouté ultérieurement), active également le versionnement, et en mode COMPLIANCE, il est irréversible ; la rétention DCD est de 365 jours maximum, l'API de 100 ans maximum.
• Les règles de cycle de vie (jusqu'à 1 000, applicables à tous les objets ou à un préfixe unique) font expirer et nettoient les objets pour le contrôle des coûts, mais ne permettent pas de passer à une classe moins coûteuse, car 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 afin de la rendre infalsifiable et de la maintenir dans le périmètre de service BSI C5 et IT-Grundschutz.

Terminologie importante :

• Object Lock (WORM) : Rétention « écriture unique, lecture multiple » appliquée aux objets ; le mode GOVERNANCE autorise un contournage par un utilisateur privilégié, tandis que le mode COMPLIANCE est immuable jusqu'à la date de rétention et ne peut ni être raccourci ni désactivé.
• 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éversements multipartis incomplets) applicable à un bucket ou à un préfixe d'objet unique.
• Bucket appartenant au contrat vs bucket appartenant à l'utilisateur : Le modèle de propriété et de visibilité, fixé lors de la création, qui détermine également les régions et points d'accès disponibles.

Lectures complémentaires

• Unité 2.3, Activity Logs et piste d'audit (délai d'exportation 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'archivage Object-Storage en un seul plan de continuité).
• Unité 5.1, Stockage bloc et fichier (quand le fichier partagé régional ou le stockage bloc mono-VM est plus adapté que l'objet).