3 Introduction Vos données n’existent pas dans le vide. Dès qu’elles franchissent une frontière, physiquement ou logiquement, elles entrent dans une autre juridiction. Les règles changent : qui peut y accéder, combien de temps vous devez les conserver, et ce qui se passe lorsqu’un gouvernement vient frapper à la porte. Pour les entreprises présentes dans plusieurs régions, la souveraineté des données n’est plus une simple case à cocher en matière de conformité. C’est une décision d’infrastructure fondamentale, qui touche l’architecture de stockage, le choix des fournisseurs, la stratégie de sauvegarde et la planification de la reprise après sinistre. Ce guide présente les bonnes pratiques de souveraineté des données les plus importantes pour les équipes IT et de protection des données : des mesures concrètes à mettre en œuvre, et pas seulement des principes. Qu’est-ce que la souveraineté des données (et pourquoi devient-elle plus difficile) ? La souveraineté des données désigne le principe selon lequel les données sont soumises aux lois du pays où elles sont stockées ou traitées. Elle est liée à la résidence des données (leur emplacement physique) et à la confidentialité des données (leur protection), sans se confondre avec elles. La difficulté tient au fait que l’infrastructure d’entreprise moderne est distribuée par nature. Les données sont répliquées entre zones de disponibilité, sauvegardées chez des fournisseurs cloud, mises en cache en périphérie et traitées par des plateformes SaaS tierces. Chacune de ces étapes est un événement potentiel de souveraineté. Parmi les réglementations qui compliquent la souveraineté des données au quotidien : RGPD (UE) : limite le transfert de données personnelles hors de l’Espace économique européen sans garanties appropriées NIS2 (UE) : renforce les exigences de sécurité et de signalement des incidents pour les opérateurs d’infrastructures critiques DORA (services financiers, UE) : impose la résilience opérationnelle et la localisation des données aux entités financières CJIS (États-Unis) : exige que les données de justice pénale restent sous juridiction américaine, avec des contrôles d’accès stricts PDPL saoudienne et PDPL émirienne : nouvelles réglementations du Golfe avec des exigences explicites de localisation des données Loi indienne DPDP : limite les transferts transfrontaliers et impose la localisation pour les catégories de données sensibles Si votre organisation opère dans plusieurs zones géographiques (États-Unis, Royaume-Uni, région DACH, pays nordiques, Golfe, Asie du Sud-Est), vous êtes probablement soumis à plusieurs de ces textes en même temps. 1. Cartographier vos données avant de pouvoir les contrôler Vous ne pouvez pas imposer la souveraineté sur des données que vous n’avez pas localisées. La première bonne pratique est une cartographie complète des données, qui répond aux questions suivantes : Quelles catégories de données détenons-nous (personnelles, financières, de santé, opérationnelles) ? Où chaque catégorie est-elle stockée, traitée et sauvegardée ? Quelles juridictions chaque jeu de données touche-t-il ? Qui, en interne comme en externe, y a accès ? Ce n’est pas un exercice ponctuel. Les cartographies de données doivent être des documents vivants, mis à jour lorsque vous déployez de nouvelles applications, migrez des charges de travail ou intégrez de nouveaux fournisseurs. Pour les équipes d’infrastructure de stockage, cela signifie étiqueter les buckets de stockage objet, les volumes NAS et les référentiels de sauvegarde selon la classification et la localisation des données. La gestion des métadonnées devient un outil de souveraineté, et pas seulement un outil opérationnel. 2. Séparer les domaines de souveraineté au niveau de l’infrastructure La séparation logique ne suffit pas. Une véritable application de la souveraineté exige une séparation physique ou au niveau de l’infrastructure des données par juridiction. Les bonnes pratiques sont notamment les suivantes : Des clusters de stockage dédiés par région. Ne vous reposez pas sur une plateforme de stockage mondiale unique en supposant que les contrôles d’accès suffiront à garantir la souveraineté. Exploitez des clusters de stockage objet distincts dans chaque zone réglementée, sans réplication interrégionale des données souveraines, sauf si elle est explicitement requise et autorisée. Des copies de sauvegarde isolées (air gap) pour les données réglementées. Pour les charges réglementées les plus sensibles (secteur public, services financiers, santé), conservez des copies de sauvegarde physiquement isolées et inaccessibles depuis l’extérieur de la juridiction. Le stockage objet immuable avec S3 Object Lock est très utilisé dans ce cas. Une gestion des clés de chiffrement distincte par juridiction. Le chiffrement n’est souverain que si les clés le sont. Si vos clés sont gérées par un fournisseur cloud américain, une décision de justice américaine peut imposer l’accès, quel que soit l’emplacement physique des données. Utilisez une gestion des clés locale à la juridiction, ou des modules matériels de sécurité (HSM) situés dans la zone réglementée. 3. Contrôler votre chaîne d’approvisionnement cloud et fournisseurs L’un des échecs de souveraineté les plus fréquents n’est pas une erreur de configuration : c’est une relation fournisseur qui n’a pas été examinée d’assez près. Lorsque vous évaluez des fournisseurs cloud, des éditeurs de logiciels de sauvegarde et des prestataires de services managés, posez ces questions : Sous quelle juridiction le fournisseur est-il immatriculé ? Où se trouvent ses équipes de support et d’exploitation, et ont-elles accès à vos données ? Quelles demandes d’accès gouvernementales a-t-il reçues, et comment y répond-il ? Peut-il démontrer sa conformité aux référentiels pertinents (ISO 27001, CSA STAR, FedRAMP, SecNumCloud) ? Pour les organisations européennes en particulier, l’invalidation du Privacy Shield et l’examen continu des hyperscalers américains en font un risque bien réel, et non théorique. La qualification française SecNumCloud, par exemple, interdit explicitement à des entités non européennes d’accéder à l’infrastructure qualifiée. Les fournisseurs on-premise ou de cloud souverain, notamment les neoclouds opérant dans des juridictions précises, sont de plus en plus choisis justement pour éviter ces risques de souveraineté liés à la chaîne d’approvisionnement. 4. Mettre en place des contrôles de résidence dans votre architecture de sauvegarde La sauvegarde et la reprise après sinistre sont les domaines où les politiques de souveraineté défaillent le plus souvent. Pour tenir leurs objectifs de RTO et de RPO, les équipes répliquent les données partout où une infrastructure de restauration est disponible, ce qui peut signifier franchir des frontières. Pour préserver la souveraineté dans votre architecture de sauvegarde : Définissez les politiques de résidence au niveau des politiques de sauvegarde. Votre logiciel de sauvegarde doit vous permettre d’indiquer que certaines charges de travail ne peuvent être sauvegardées que vers des cibles situées dans un périmètre géographique défini. Imposez-le par la politique, pas seulement par l’usage. Utilisez un stockage objet géolocalisé comme cible de sauvegarde. Un stockage objet compatible S3 déployé dans un pays ou une région donnés, on-premise ou dans un cloud souverain, vous offre une cible de sauvegarde conforme sans dépendre de la géographie des hyperscalers. Testez la restauration au sein de la juridiction. Des tests de reprise qui démarrent des charges de travail dans des régions cloud hors juridiction peuvent techniquement enfreindre les exigences de souveraineté, même si les données de production ne sortent jamais. Testez à l’intérieur de votre périmètre de souveraineté. Documentez le parcours des données. Dans les secteurs réglementés, les auditeurs demanderont non seulement où les données sont stockées, mais aussi par où elles transitent pendant les opérations de sauvegarde, de réplication et de restauration. Connaissez l’intégralité de ce parcours. 5. Établir des politiques claires de conservation et de suppression des données La souveraineté ne concerne pas seulement l’emplacement des données : elle concerne aussi leur durée de vie et ce qui se passe à l’expiration des périodes de conservation. Le droit à l’effacement du RGPD, combiné aux obligations de conservation sectorielles (documents financiers au titre de MiFID II, données de santé au titre de HIPAA ou de ses équivalents locaux), impose un cadre de conservation applicable au niveau de la couche de stockage. Les bonnes pratiques sont notamment les suivantes : Mettre en place des politiques de cycle de vie des objets qui suppriment ou archivent automatiquement les données à l’expiration des périodes de conservation Utiliser un stockage WORM (Write Once Read Many) pour les documents qui doivent être conservés sans pouvoir être modifiés : cela répond à la fois aux exigences d’immuabilité et aux obligations réglementaires de conservation Tenir un journal d’audit de tous les événements de suppression, indiquant qui a lancé la suppression et quand Veiller à inclure les copies de sauvegarde dans les politiques de conservation et de suppression : un enregistrement supprimé en production mais conservé dans une copie de sauvegarde non encadrée reste un risque de non-conformité 6. Se préparer aux demandes d’accès gouvernementales La gouvernance de la souveraineté des données doit prévoir un processus défini pour traiter les demandes d’accès gouvernementales, qu’elles émanent de votre propre gouvernement ou de juridictions étrangères. Concrètement : Connaissez vos obligations légales dans chaque juridiction. Certains pays vous obligent à communiquer des données aux autorités sans en informer la personne concernée. D’autres vous interdisent de communiquer des données à des gouvernements étrangers sans décision d’un tribunal local. Nommez un délégué à la protection des données ou un représentant légal local dans chaque juridiction où c’est requis (le RGPD l’impose aux organisations non européennes qui traitent à grande échelle des données de résidents de l’UE). Journalisez tous les accès aux données souveraines. Les pistes d’audit sont à la fois une protection juridique et une nécessité opérationnelle. Si des données sont consultées en dehors des schémas habituels, y compris par des utilisateurs internes privilégiés, vous devez le savoir. Définissez un circuit d’escalade. Lorsqu’une demande arrive, votre équipe IT ne doit pas prendre de décisions juridiques dans l’urgence. Prévoyez un processus d’escalade qui implique un conseil juridique avant toute communication de données. 7. Traiter la souveraineté comme un programme continu, pas comme un projet La conformité en matière de souveraineté des données n’est pas un déploiement que l’on termine et que l’on clôt. Les réglementations évoluent, votre infrastructure change et de nouvelles catégories de données entrent constamment dans le périmètre. Intégrez la souveraineté à votre rythme opérationnel : Revue trimestrielle des cartographies de données par rapport à la topologie de stockage actuelle Évaluations annuelles des risques fournisseurs intégrant des critères de souveraineté Veille continue des évolutions réglementaires dans vos zones d’activité Intégration des exigences de souveraineté dans la gestion des changements : toute nouvelle charge de travail, tout nouveau fournisseur ou toute nouvelle zone géographique doit déclencher une revue de souveraineté Les organisations qui traitent la souveraineté comme une question d’infrastructure, et pas seulement de conformité, sont mieux armées pour réagir vite lorsque les réglementations changent, pour entrer sur de nouveaux marchés ou pour répondre aux audits sans précipitation. Comment le stockage objet soutient la souveraineté des données Le stockage objet moderne compatible S3 est de plus en plus utilisé comme socle des infrastructures de données souveraines, car il donne aux organisations un contrôle direct sur l’emplacement des données, leur chiffrement et les personnes qui peuvent y accéder. Les principales capacités qui répondent aux exigences de souveraineté : Déploiement géolocalisé : les clusters de stockage objet peuvent être déployés on-premise ou dans des environnements de cloud souverain au sein d’une juridiction donnée, sans dépendre de l’infrastructure des hyperscalers S3 Object Lock / WORM : impose l’immuabilité pour les exigences réglementaires de conservation Chiffrement avec gestion locale des clés : données chiffrées au repos avec des clés qui ne quittent jamais la juridiction Politiques au niveau des buckets et IAM : contrôles d’accès fins capables d’imposer des restrictions d’accès selon la juridiction Journalisation d’audit : enregistrement complet de tous les événements d’accès pour les rapports de conformité Pour les organisations présentes dans plusieurs régions, un stockage objet doté d’une API compatible S3 cohérente permet de conserver un modèle opérationnel unique pour des déploiements souverains dans différentes zones géographiques, sans compromettre l’isolation qu’exige la souveraineté. Récapitulatif : liste de contrôle des bonnes pratiques de souveraineté des données Cartographier toutes les données par catégorie, emplacement et juridiction Séparer l’infrastructure de stockage par domaine de souveraineté Gérer les clés de chiffrement au sein de chaque juridiction Contrôler les chaînes d’approvisionnement fournisseurs et cloud au regard du risque de souveraineté Imposer la résidence des données dans les politiques de sauvegarde et de reprise après sinistre Mettre en œuvre et automatiser la conservation et la suppression au niveau de la couche de stockage Prévoir un processus défini pour les demandes d’accès gouvernementales Intégrer des revues de souveraineté aux processus opérationnels et de gestion des changements Lectures complémentaires Souveraineté ou résidence des données : les différences clés Exigences du RGPD en matière de stockage des données pour les équipes IT et stockage Qu’est-ce que NIS2 ? La directive européenne sur la cybersécurité expliquée Le règlement sur la résilience opérationnelle numérique (DORA) expliqué S3 Object Lock : immuabilité et WORM
