5 La conformité S3 désigne l’ensemble des contrôles applicables qui rendent un stockage objet S3 ou compatible S3 acceptable aux yeux d’un régulateur : une rétention qui ne peut pas être discrètement annulée, un chiffrement dont vous détenez réellement les clés, et des journaux qui résistent à l’examen d’un auditeur. C’est une question différente de la compatibilité S3, qui se contente de vérifier qu’une plateforme parle l’API. Les deux notions sont constamment confondues lors des achats. Une plateforme peut implémenter correctement chaque opération S3 et échouer quand même à un contrôle, car les règles qui encadrent les enregistrements réglementés ne portent pas sur l’étendue de l’API. Elles portent sur ce qui se passe lorsqu’une personne disposant d’identifiants d’administration tente de supprimer quelque chose qu’elle ne devrait pas pouvoir supprimer. Ce que signifie réellement la conformité S3 Trois conditions doivent être réunies en même temps. La couche de stockage doit appliquer les contrôles plutôt que les proposer comme de simples paramètres, ce qui signifie que l’application se situe sous la couche qu’un administrateur peut modifier. Le système doit produire des preuves : non seulement qu’une politique existait, mais qu’elle a tenu. Et les contrôles doivent correspondre à une obligation précise que vous pouvez nommer, car « nous utilisons du stockage immuable » ne répond pas à la question « quelle règle, et pour combien de temps ? ». Le test utile consiste à savoir si un contrôle résiste à un administrateur compromis. Les politiques de bucket n’y résistent pas : ce sont des objets IAM, et quiconque peut modifier l’IAM peut les modifier. L’expiration par cycle de vie en est une bonne illustration. AWS indique qu’une politique de bucket ne peut pas empêcher les suppressions effectuées par une règle de cycle de vie, et que même une politique refusant toutes les actions à tous les principaux laisse le cycle de vie fonctionner normalement. Object Lock, en revanche, l’empêche, car il est appliqué sous la couche des politiques. C’est pourquoi les régulateurs attachent de l’importance à cette différence. Les règles qui déterminent les exigences de conformité S3 Dans les services financiers américains, la référence est la règle SEC 17a-4. Les amendements de 2022 (adoptés le 12 octobre 2022, en vigueur le 3 janvier 2023, avec une mise en conformité des broker-dealers au 3 mai 2023) ont modifié la nature de l’exigence d’une manière que la plupart des documents de fournisseurs présentent encore mal. La règle 17a-4(f)(2)(i) propose désormais deux options reliées par un « ou » : conserver les enregistrements dans un format non réinscriptible et non effaçable, la voie WORM traditionnelle, ou les conserver avec une piste d’audit horodatée complète qui enregistre chaque modification et suppression, leur date, leur auteur, et suffisamment d’informations pour reconstituer l’original. Le WORM n’est plus la seule voie. La règle FINRA 4511(c) reprend automatiquement la norme amendée, puisqu’elle renvoie dynamiquement à la règle 17a-4. La règle CFTC 1.31 repose sur un modèle différent, et cette différence pèse lors de la planification des niveaux de stockage. Le modèle SEC impose de conserver les enregistrements six ans, dont les deux premières années en accès « facile ». La CFTC exige que les enregistrements réglementaires électroniques restent facilement accessibles pendant toute la période, généralement cinq ans ; la fenêtre de deux ans ne s’applique qu’au papier. Faire basculer un enregistrement CFTC électronique vers une archive lente la troisième année est un problème de conformité, et non une optimisation des coûts. Dans le secteur de la santé, HIPAA est souvent mal citée. Il n’existe pas de durée fédérale de conservation des dossiers médicaux au titre de HIPAA (c’est le droit des États qui la fixe). La règle des six ans du 45 CFR 164.316(b)(2)(i) s’applique à la documentation : politiques, procédures et comptes rendus écrits des évaluations exigées par la Security Rule. Le chiffrement doit aussi être décrit avec précision, car à la mi-2026 il reste addressable (à évaluer) plutôt qu’obligatoire. « Addressable » ne signifie pas facultatif (vous devez l’évaluer, documenter toute décision de ne pas le mettre en œuvre et mettre en place une mesure équivalente), mais ce n’est pas une obligation. Une proposition de règle de janvier 2025 rendrait le chiffrement et la MFA obligatoires ; elle n’est pas définitive et son adoption a été repoussée à une date prévue en 2027. Dans l’UE, DORA s’applique aux entités financières depuis le 17 janvier 2025, et son article 12 encadre la sauvegarde et la restauration. Un détail fréquemment surinterprété : l’article 12(3) exige que les systèmes utilisés pour restaurer les données soient physiquement et logiquement séparés du système source. Il n’impose pas de séparation aux copies de sauvegarde elles-mêmes. Le texte contraignant le plus fort en matière de copies séparées et immuables se trouve dans le règlement d’exécution de NIS2 applicable aux infrastructures numériques et aux fournisseurs cloud, qui exige des copies de sauvegarde stockées à des emplacements qui ne sont pas sur le même réseau que le système et suffisamment éloignés pour échapper à un sinistre touchant le site principal. La rétention : comment S3 Object Lock l’applique S3 Object Lock est le mécanisme au niveau de l’API ; il comporte deux modes ainsi qu’une conservation légale (legal hold) indépendante. En mode conformité, aucun utilisateur ne peut écraser ou supprimer une version d’objet protégée ni raccourcir sa rétention, y compris le compte root. En mode gouvernance, un contournement est possible, mais il exige deux éléments réunis : l’autorisation s3:BypassGovernanceRetention et un en-tête de requête explicite. La rétention peut être prolongée dans les deux modes ; elle ne peut être raccourcie qu’en mode gouvernance, jamais en mode conformité. La rétention maximale est de 100 ans. Une affirmation répandue veut que seul le mode conformité satisfasse à la règle SEC 17a-4. L’évaluation habituellement citée à l’appui de cette conclusion dit le contraire : Object Lock satisfait à l’exigence de format non réinscriptible et non effaçable dans l’un ou l’autre mode, le mode gouvernance étant accepté sur la base de contrôles compensatoires qui imposent un contrôle procédural et une surveillance des administrateurs disposant de l’autorisation de contournement. Le mode gouvernance est défendable, mais seulement si vous pouvez démontrer ces contrôles complémentaires, ce qui constitue une charge de gouvernance plutôt qu’une contrainte technique. Trois détails opérationnels sont à l’origine de véritables constats d’audit. Object Lock exige le versioning, et une fois activé, il ne peut plus être désactivé ni le versioning suspendu. Les conservations légales n’ont pas de date d’expiration, persistent jusqu’à leur retrait explicite quelle que soit la rétention, et ne sont pas levées par le contournement du mode gouvernance. Et celui qui surprend : une demande de suppression sans identifiant de version réussit et insère un marqueur de suppression, car les marqueurs de suppression ne sont pas eux-mêmes protégés. Les données sont intactes, mais l’objet semble avoir disparu. Quiconque teste l’immuabilité avec une simple suppression et obtient une réponse 200 en tire exactement la mauvaise conclusion. Chiffrement, clés et ce que signifie vraiment « certifié FIPS » Le chiffrement au repos est devenu un choix par défaut plutôt qu’une décision ; la question qui fait la différence dans toute stratégie de chiffrement des données réglementées est donc la garde des clés. Le chiffrement côté serveur avec des clés gérées par la plateforme protège contre le vol de supports ; il ne rend pas les données opaques pour l’opérateur. Les clés gérées par le client, idéalement adossées à un HSM externe, sont ce qui permet d’affirmer que le fournisseur ne peut pas lire les enregistrements, et elles permettent le crypto-shredding lors de la mise hors service. Soyez prudent avec le crypto-shredding comme argument de conformité, en particulier face au droit à l’effacement du RGPD. La position du Comité européen de la protection des données est que des données personnelles chiffrées restent des données personnelles, que le seuil de l’effacement est une anonymisation effective plutôt qu’une inaccessibilité, et que la robustesse du chiffrement se dégrade sur les horizons de plusieurs décennies qu’implique la rétention WORM. La destruction des clés réduit fortement le risque, mais ne constitue pas un substitut acquis à la suppression. Concernant la validation FIPS 140, la précision compte, car le vocabulaire des appels d’offres se trompe souvent. Ce sont les modules cryptographiques qui sont validés, et non les plateformes ou les produits. Un produit est soit lui-même un module validé, soit il en contient simplement un, et le programme de certification utilise une formulation approuvée différente pour chaque cas. L’échéance de transition est aussi proche : tous les certificats FIPS 140-2 passent sur la liste historique le 21 septembre 2026, après quoi ils peuvent servir pour des systèmes existants, mais pas pour de nouveaux achats. Preuves d’audit : des journaux qui tiennent C’est là que des déploiements par ailleurs bien conçus échouent, et la raison tient en une phrase de la documentation AWS. La journalisation des accès serveur S3 fait l’objet d’une clause de non-garantie explicite : la livraison n’est pas garantie, les enregistrements peuvent arriver avec des heures de retard ou ne jamais arriver, et il est impossible de savoir si tous les enregistrements d’un intervalle ont été livrés. Elle est décrite comme n’étant pas destinée à rendre compte de manière exhaustive des requêtes. C’est rédhibitoire pour une chaîne de conservation des preuves. La journalisation d’audit au niveau de l’API (CloudTrail chez AWS, ses équivalents ailleurs) ne comporte pas cette clause et ajoute les propriétés qui rendent les preuves défendables : validation cryptographique de l’intégrité des fichiers journaux, chiffrement, livraison vers un autre compte afin que le compte audité ne puisse pas modifier ses propres enregistrements, et champs qui capturent les paramètres d’Object Lock. La rétention par défaut est courte, généralement 90 jours ; les obligations à long horizon exigent donc un magasin d’événements immuable ou un export vers un SIEM ou un bucket verrouillé. Dans tous les cas, la piste d’audit doit bénéficier de la même rétention que les enregistrements qu’elle documente, ce que les équipes oublient régulièrement de budgéter. Résidence des données, et le conflit entre rétention et effacement La fausse prémisse la plus courante dans les discussions sur la souveraineté est que le RGPD impose de conserver les données personnelles dans l’UE. Ce n’est pas le cas. Le chapitre V encadre les transferts internationaux au moyen de décisions d’adéquation, de clauses contractuelles types et de règles d’entreprise contraignantes, et les transferts vers une juridiction adéquate sont traités comme des transferts au sein de l’UE. Le droit européen interdit même la plupart des exigences de localisation pour les données à caractère non personnel. Lorsque des obligations de résidence existent réellement, elles proviennent de règles sectorielles, du droit national, des politiques d’achat ou des contrats. DORA, par exemple, exige que les contrats indiquent où les données sont stockées et que tout changement soit notifié, ce qui est une obligation de transparence et non de localisation. La distinction mérite d’être bien comprise, car plaider pour une infrastructure souveraine sur une base juridique inexistante ne résiste pas à l’examen. La tension la plus forte oppose la rétention immuable au droit à l’effacement. L’article 17(3) la résout de manière restrictive : l’effacement ne s’applique pas « dans la mesure où » le traitement est nécessaire pour respecter une obligation légale, ou à la constatation, à l’exercice ou à la défense de droits en justice. Deux conséquences en découlent. Une obligation légale ne fait obstacle à une demande d’effacement que pour les données et la période qu’elle couvre réellement ; un bucket immuable global ne vaut donc pas exemption globale. Et la limitation de la conservation joue dans l’autre sens : une fois l’obligation éteinte, conserver la copie immuable devient en soi une infraction. Une rétention qui n’expire jamais n’est pas l’option sûre qu’elle semble être. Liste de contrôle : évaluer les capacités de conformité S3 Object Lock en mode conformité et en mode gouvernance, avec des conservations légales indépendantes de la rétention et des valeurs par défaut au niveau du bucket appliquées de manière centralisée. Une réponse documentée sur le comportement des marqueurs de suppression, afin que « supprimé » dans la console corresponde à quelque chose que vous pouvez expliquer à un contrôleur. Des clés gérées par le client avec intégration à un HSM ou un KMS externe, et un modèle de garde des clés qui résiste à la question « l’opérateur peut-il lire ceci ? ». Des modules cryptographiques disposant d’une validation en cours, vérifiée par numéro de certificat plutôt que par une allégation marketing, et un plan pour la transition FIPS 140-2 de septembre 2026. Une journalisation d’audit au niveau de l’API avec validation de l’intégrité et une livraison en écriture unique ou vers un autre compte, conservée aussi longtemps que les enregistrements qu’elle atteste. Une séparation des tâches qui permet aux administrateurs du stockage de gérer la capacité sans lire le contenu des enregistrements, et une surveillance de toute personne disposant du contournement du mode gouvernance. Une rétention qui expire à la fin de l’obligation, et un processus d’effacement capable d’agir sur les données hors périmètre tout en laissant intacts les enregistrements verrouillés. L’export des preuves dans un format électronique exploitable, pistes d’audit comprises, dans les délais fixés par votre régulateur. Synthèse Les organisations qui passent les contrôles sans difficulté ont généralement fait une chose peu spectaculaire : associer chaque contrôle à une obligation nommée et à une durée définie, plutôt que d’acheter un ensemble de fonctionnalités et de supposer qu’il couvre tout. L’immuabilité sans calendrier de rétention lié à une règle n’est qu’un stockage coûteux. Une piste d’audit que personne n’a essayé d’exporter est une supposition, pas une preuve. Les briques techniques de la conformité S3 sont matures et largement disponibles sur les différentes plateformes en 2026 ; l’échec ne vient donc presque jamais d’une fonctionnalité manquante. Il vient d’un contrôle configuré une fois, jamais testé face à un scénario hostile et jamais associé à la règle qu’il était censé satisfaire. Questions fréquentes La conformité S3 est-elle la même chose que la compatibilité S3 ? Non. La compatibilité S3 décrit la fidélité avec laquelle une plateforme implémente l’API, y compris sa prise en charge d’opérations comme Object Lock et le versioning. La conformité S3 décrit sa capacité à appliquer les contrôles de rétention, d’accès, de chiffrement et de preuve qu’exige une réglementation donnée. Une plateforme peut obtenir un bon résultat sur le premier point et échouer sur le second, le plus souvent sur les preuves d’audit et la garde des clés. La règle SEC 17a-4 exige-t-elle Object Lock en mode conformité ? Pas nécessairement. L’évaluation indépendante habituellement citée conclut qu’Object Lock satisfait à l’exigence de format non réinscriptible et non effaçable dans l’un ou l’autre mode, le mode gouvernance dépendant de contrôles procéduraux compensatoires sur les administrateurs disposant de l’autorisation de contournement. Par ailleurs, les amendements de 2022 ont ajouté une alternative fondée sur la piste d’audit à la voie WORM : le WORM est une voie possible, pas la seule. Le RGPD impose-t-il que les données restent dans l’UE ? Non. Il encadre les transferts internationaux plutôt que de les interdire, et autorise les transferts vers des juridictions couvertes par une décision d’adéquation ou protégées par des garanties comme les clauses contractuelles types. Les véritables exigences de résidence proviennent de règles sectorielles, du droit national, des politiques d’achat ou des contrats. Le droit européen interdit par ailleurs la plupart des exigences de localisation pour les données à caractère non personnel. Comment la rétention immuable et le droit à l’effacement coexistent-ils ? Grâce à une exemption restrictive plutôt que générale. L’effacement ne s’applique pas dans la mesure où le traitement est nécessaire au respect d’une obligation légale ou à des droits en justice ; vous devez donc pouvoir nommer l’obligation et démontrer son périmètre. Les données hors de ce périmètre doivent rester effaçables, et une fois l’obligation éteinte, la limitation de la conservation impose leur suppression. La rétention doit avoir une fin définie autant qu’un début. Les journaux d’accès serveur S3 suffisent-ils comme piste d’audit ? Non, et c’est documenté, pas une question d’opinion. AWS indique que la livraison des journaux d’accès serveur n’est pas garantie, que les enregistrements peuvent être fortement retardés ou jamais livrés, et qu’il est impossible de confirmer que tous les enregistrements d’un intervalle sont arrivés. Utilisez une journalisation d’audit au niveau de l’API avec validation de l’intégrité pour tout ce qui doit servir de preuve. Pour aller plus loin Pour le détail règle par règle derrière cette synthèse, voir la conformité SEC 17a-4, la liste de contrôle du stockage conforme CJIS, la conformité SOX et à quoi ressemble un stockage réellement immuable.
