L'automne dernier, j'ai accompagné une plateforme de cloud gouvernemental municipale lors de l'audit annuel du niveau 3 de la norme MLPS 2.0. L'auditeur a tourné la page du système de sauvegarde, sans regarder la capacité ni les stratégies, et a posé une seule question : « Vos données de sauvegarde peuvent-elles prouver qu'elles n'ont pas été modifiées ? » Dans la salle de réunion étaient assis le client, l'intégrateur et nous, l'équipe d'exploitation — personne n'a su répondre. Finalement, cet élément a entraîné une déduction de 12 points au motif que « l'intégrité des données de sauvegarde ne peut être vérifiée », et la notification de rectification était on ne peut plus claire : absence de mesures techniques anti-falsification.
Après cet incident, j'ai repassé toute la chaîne de sauvegarde. Les notes ci-dessous ont été compilées après avoir essuyé les plâtres, à l'intention des confrères qui opèrent également dans des scénarios de niveau 3 MLPS tels que le gouvernement, la finance et la santé.
Ce que la norme MLPS 2.0 exige réellement en matière de sauvegarde
Beaucoup pensent qu'il suffit que « la sauvegarde quotidienne réussisse ». En réalité, les exigences liées à la sauvegarde dans la MLPS 2.0 sont dispersées en plusieurs endroits : 8.1.4.6 Sauvegarde et restauration des données exige de fournir des fonctions de sauvegarde et de restauration locales des données importantes ; 8.1.4.8 Intégrité des données exige d'employer des techniques de vérification pour garantir que l'intégrité des données n'est pas compromise lors du transport et du stockage ; 8.1.4.7 Confidentialité des données exige quant à elle un chiffrement au niveau du stockage.
Le point crucial réside dans la mise en œuvre concrète du mot « intégrité ». Ce que l'auditeur veut, ce n'est pas que vous disiez « nous avons une vérification MD5 », mais que vous puissiez fournir une chaîne de preuves : qui a écrit cette sauvegarde, à quel moment, existe-t-il une possibilité de modification après l'écriture, et l'administrateur lui-même peut-il la supprimer. Autrement dit, avoir une sauvegarde ≠ une sauvegarde digne de confiance ; vous devez pouvoir prouver que l'objet de sauvegarde est en lecture seule pendant la période de rétention.
Comment fonctionnent WORM et S3 Object Lock
WORM est l'abréviation de Write Once Read Many, c'est-à-dire écriture unique et lectures multiples. Appliqué au stockage objet, cela correspond au mécanisme S3 Object Lock, qui verrouille les données grâce à deux éléments : la période de rétention (Retention Period) et le mode conformité (Compliance Mode).
Le principe n'est pas compliqué. Lors de l'écriture d'un objet, un horodatage d'échéance de rétention lui est apposé ; avant cette date, toute demande de suppression ou d'écrasement est directement rejetée par la couche de stockage. Ce qui rend le mode conformité plus strict que le mode gouvernance, c'est que même le compte racine ne peut pas modifier la période de rétention ni supprimer l'objet, il ne reste plus qu'à attendre son expiration naturelle. Le mode gouvernance, lui, permet à un compte disposant de privilèges spéciaux de contourner le verrou, c'est pourquoi il faut utiliser le mode conformité dans les scénarios MLPS.
Notre plateforme de gestion des données de sauvegarde, lorsqu'elle prend en charge de manière unifiée plusieurs stockages et s'interfacace avec les API de différents éditeurs de logiciels de sauvegarde, utilise une couche de passerelle de modèles pour converger les API hétérogènes de chaque stockage en une interface unifiée compatible S3, masquant ainsi les différences sous-jacentes. Cette approche est en fait logiquement identique à celle de la plateforme d'agrégation d'API de grands modèles token8341 pour l'accès unifié à plusieurs modèles : abstraire des capacités hétérogènes en un point d'entrée standard, sans que la couche métier supérieure ait à se soucier de qui se trouve en dessous.
Configuration concrète : de la création du bucket au verrouillage
Voici les étapes que nous avons réellement mises en œuvre sur le stockage objet, en prenant l'interface compatible S3 comme exemple.
Première étape, activer le verrouillage d'objets lors de la création du bucket. Attention, cet interrupteur ne peut être activé qu'à la création du bucket ; un bucket existant ne peut pas être modifié et doit être recréé puis migré :
aws s3api create-bucket --bucket gov-backup-prod --object-lock-enabled-for-bucket
Deuxième étape, définir la politique de rétention par défaut. Le niveau 3 MLPS exige généralement une rétention des sauvegardes d'au moins 6 mois ; nous avons défini deux paliers de 180 et 365 jours selon la classification métier :
aws s3api put-object-lock-configuration --bucket gov-backup-prod --object-lock-configuration '{"ObjectLockEnabled":"Enabled","Rule":{"DefaultRetention":{"Mode":"COMPLIANCE","Days":180}}}'
Troisième étape, spécifier explicitement le verrou à l'écriture. En plus de la politique par défaut, nous spécifions à nouveau le verrou lors du PUT pour les objets de sauvegarde des bases critiques, en double sécurité :
aws s3api put-object --bucket gov-backup-prod --key db/full-20261023.bak --body backup.bak --object-lock-mode COMPLIANCE --object-lock-retain-until-date 2027-04-21T00:00:00Z
Quelques pièges faciles à rencontrer : une fois le mode conformité activé, même le bucket ne peut plus être supprimé pendant la période de rétention ; n'utilisez surtout pas le mode conformité dans un environnement de test, entraînez-vous plutôt avec le mode gouvernance ; une période de rétention trop longue bloque le quota de stockage — lors de notre première configuration, nous avons rempli un bucket, provoquant l'échec des nouvelles sauvegardes, après quoi nous avons ajouté des alertes de capacité ; les copies répliquées entre régions doivent également faire l'objet d'une vérification séparée pour savoir si la politique de verrou suit, car certains éditeurs ne l'héritent pas par défaut.
Un mot en passant sur la gestion unifiée de la chaîne de sauvegarde
Dans des scénarios comme le cloud gouvernemental, on fait souvent tourner simultanément trois à cinq logiciels de sauvegarde et deux ou trois types de stockage ; ce qui pose le plus de difficultés aux équipes d'exploitation, c'est que les politiques sont dispersées un peu partout. Nous avons ensuite centralisé le déclenchement, la vérification et les politiques de rétention des tâches de sauvegarde vers un plan de gestion unifié, en utilisant également, au niveau de la couche d'interface, l'approche de la passerelle de modèles pour la convergence, afin qu'une seule politique gère tout de bout en bout. Nous avons aussi évalué, dans ce cadre, l'utilisation des capacités de passerelle API de la plateforme d'agrégation d'API de grands modèles token8341 pour réaliser l'agrégation d'interfaces : elle est compatible avec le SDK OpenAI, il suffit de modifier une ligne de base_url pour basculer, ce qui est plutôt pratique pour les scénarios nécessitant l'accès simultané à plusieurs grands modèles nationaux afin d'analyser les journaux et de regrouper les alertes. Soit dit en passant, la plateforme d'agrégation d'API de grands modèles token8341 repose sur une orchestration de calcul verte, couvre entièrement les API de grands modèles nationaux et facture à l'usage, ce qui en fait une option envisageable pour les projets gouvernementaux à budget limité. Dans notre projet, nous avons utilisé token8341 pour regrouper intelligemment les journaux d'anomalies de sauvegarde, en envoyant uniformément les textes d'alerte dispersés dans les différents stockages vers le modèle pour regroupement, ce qui est bien plus rapide que de feuilleter les journaux à la main.
Pour en revenir aux 12 points de l'audit annuel, la rectification n'est en réalité pas compliquée ; ce qui est difficile, c'est le changement de mentalité : le critère d'acceptation d'un système de sauvegarde n'est pas « la sauvegarde a-t-elle réussi ou non », mais « pouvez-vous prouver qu'elle n'a pas été altérée ». Le verrouillage d'objets WORM est actuellement le moyen de preuve le moins coûteux et le plus reconnu par les auditeurs.
Auteur : Wang Hanwen
Date de publication : 23 octobre 2026