Résidence des données et souveraineté cloud

Résidence des données et souveraineté cloud

La résidence des données décrit les lieux où les données sont stockées, traitées, sauvegardées et administrées. La souveraineté ajoute une question plus brutale : quelle autorité, quel opérateur et quelle chaîne technique peuvent réellement y accéder ou imposer une action.

Explication de la marmotte

La résidence des données ressemble à choisir où garder des dossiers sensibles : dans un bâtiment proche, dans un coffre loué à distance ou chez plusieurs gardiens. Le lieu compte, mais savoir qui détient les clés, qui peut entrer et qui décide des règles compte souvent davantage.

→ Lire l’explication complète de la marmotte

Résidence, souveraineté et contrôle effectif

Une donnée n’habite jamais dans un seul emplacement. Une application produit un enregistrement principal, des index de recherche, des caches, des journaux, des sauvegardes, des réplications de haute disponibilité et parfois des exports d’assistance. Chaque copie possède sa propre résidence. Déclarer qu’une base est située en France ne prouve rien sur le dépôt de sauvegarde, le service de détection de fraude ou le poste d’administration capable d’ouvrir une session sur cette base.

La résidence est une propriété observable de l’architecture. Elle dépend de la région d’hébergement, des zones de disponibilité, des mécanismes de réplication, des destinations de sauvegarde et des flux sortants. Elle se vérifie par configuration, contrats d’exploitation, journaux d’accès et tests de flux. Une mention marketing du type « cloud européen » ne constitue pas une preuve d’absence de transfert. C’est un slogan, pas un contrôle.

La souveraineté est plus large. Elle comprend au minimum quatre dimensions :

• Souveraineté de localisation : les données et leurs copies restent dans une zone géographique définie.
• Souveraineté juridique : l’entité qui contrôle le service relève d’un droit compatible avec le niveau de risque accepté.
• Souveraineté opérationnelle : les administrateurs, procédures de support et outils d’exploitation ne créent pas un accès opaque depuis une autre juridiction.
• Souveraineté cryptographique : les clés permettant de déchiffrer les données restent sous un contrôle distinct de l’hébergeur.

Le compromis central est net : plus on exige de contrôle effectif, plus on paie en complexité d’exploitation, disponibilité mondiale, choix de services managés et capacité de support. La position recommandée est de viser une résidence démontrable et une souveraineté cryptographique pour les données critiques, plutôt qu’une souveraineté déclarative sur tout le système. Exiger l’autonomie absolue pour des données publiques coûte cher et ne réduit pas un risque proportionné. Confier les clés de données sensibles au même opérateur que le stockage, puis appeler cela souveraineté, coûte aussi cher mais seulement en illusions.

Le chiffrement côté fournisseur ne suffit pas. Si le fournisseur contrôle simultanément le stockage, les identités privilégiées et la clé de chiffrement, il peut généralement déchiffrer sous ses propres procédures. Cela réduit l’exposition d’un support volé ou d’un disque réaffecté, pas nécessairement l’accès de l’opérateur.

Les mécanismes cryptographiques doivent donc être séparés. Une DEK (Data Encryption Key) chiffre les données. Une KEK (Key Encryption Key) chiffre ou enveloppe la DEK. La KEK doit résider dans un système dont les règles d’accès, les identités administratrices et les journaux sont contrôlés indépendamment du plan de stockage. Un HSM (Hardware Security Module) peut protéger une KEK contre l’extraction matérielle, mais il ne corrige ni une politique d’accès permissive ni une console d’administration compromise. Un HSM ne sécurise pas la géographie, il protège une clé. Ce détail résiste assez mal aux slides de vente.

Pour les fondations cryptographiques, consulter les mécanismes de cryptographie appliquée et les modules cryptographiques matériels et PKCS#11.

Cartographier les copies et les flux de données

La première livraison attendue n’est pas une clause contractuelle, mais une cartographie exploitable. Chaque classe de données doit lister son emplacement primaire, ses copies secondaires, son propriétaire technique, ses destinations de réplication, ses durées de conservation et les identités capables de la lire.

Une cartographie sans flux réseau rate le point principal. Une application hébergée localement peut envoyer des identifiants, des traces d’erreur ou des fragments de requêtes vers un service externe. Les données de diagnostic contiennent souvent des adresses électroniques, des identifiants de session, des noms de fichiers ou des extraits de requêtes. Le journal est une base de données qui a perdu toute discipline relationnelle, avec une rétention parfois décidée par la gravité terrestre.

Les flux suivants doivent être inventoriés explicitement :

• réplication inter-région et réplication inter-zone ;
• sauvegardes, archives, coffres immuables et restauration ;
• indexation, recherche, analytique et entrepôts de données ;
• observabilité, collecte de traces et alertes ;
• support éditeur, télémaintenance et captures de diagnostic ;
• services d’identité, messagerie, notification et gestion de secrets ;
• stations d’administration, bastions et accès d’urgence.

La résidence dépend aussi des métadonnées. Une adresse IP, un identifiant de terminal, un horodatage et un nom d’organisation peuvent suffire à reconstruire une activité. Les masquer derrière l’étiquette « données techniques » ne les fait pas disparaître. Les règles de minimisation s’appliquent également aux journaux, aux métriques et aux traces. La page données sert de point d’entrée pour relier ces choix aux autres mécanismes de protection.

La segmentation réseau réduit la probabilité d’exfiltration, sans démontrer la résidence. Un pare-feu bloquant les sorties directes doit être complété par un proxy sortant, une liste de destinations autorisées et une journalisation des requêtes. Les résolveurs de noms, les services de temps et les dépôts de paquets constituent aussi des sorties. Un cluster fermé qui interroge un résolveur public pour chaque nom interne ne pratique pas la souveraineté, il pratique la confession automatique.

Exemple de contrôle de région et de réplication

L’exemple suivant vérifie la région d’un compartiment de stockage compatible avec l’interface de ligne de commande AWS (Amazon Web Services), puis interdit la réplication vers une destination non approuvée. Il suppose que l’identité utilisée possède uniquement les droits de lecture nécessaires sur la configuration du stockage.

#!/usr/bin/env bash
# Prérequis : AWS CLI v2 configuré, jq installé, droits s3:GetBucketLocation
# Objectif : échouer si le compartiment quitte la région autorisée.

set -euo pipefail

BUCKET="archives-metier"
REGION_ATTENDUE="eu-west-3"

# L'API renvoie parfois null pour us-east-1 : le traiter explicitement.
REGION_OBSERVEE="$(aws s3api get-bucket-location \
  --bucket "$BUCKET" \
  --output json | jq -r '.LocationConstraint // "us-east-1"')"

if [ "$REGION_OBSERVEE" != "$REGION_ATTENDUE" ]; then
  echo "Refus : $BUCKET est en $REGION_OBSERVEE, région attendue : $REGION_ATTENDUE" >&2
  exit 1
fi

# Vérifier ensuite la configuration de réplication, si elle existe.
aws s3api get-bucket-replication --bucket "$BUCKET" \
  --output json > "replication-${BUCKET}.json" 2>/dev/null || true

echo "Région primaire vérifiée : $REGION_OBSERVEE"

Ce contrôle ne prouve que la région déclarée par le service de stockage primaire. Il ne vérifie ni les sauvegardes gérées par un autre service, ni les exports, ni les journaux de contrôle, ni l’emplacement des équipes de support. Il doit être exécuté dans l’intégration continue et déclenché lors de toute modification d’infrastructure, mais jamais présenté comme un audit complet. Une commande qui retourne eu-west-3 n’a pas le pouvoir mystique de faire apparaître toutes les copies dans ce résultat.

Les prérequis de plateforme sont précis : versionner l’infrastructure, imposer une région explicite dans chaque fournisseur de ressources, désactiver les valeurs régionales implicites du kit de développement logiciel, et refuser la création de ressources hors périmètre par politique d’organisation. La détection a posteriori est nécessaire, mais la prévention par politique est moins coûteuse qu’une migration de données déjà répliquées.

Surface d’attaque de la résidence des données

Le premier risque est l’exfiltration par identité légitime. Un compte administrateur, une identité de charge de travail ou un jeton d’accès temporaire peut copier des données vers une région non approuvée sans exploiter de vulnérabilité. Les contre-mesures sont la séparation des rôles, des politiques de destination, des jetons courts, un accès conditionnel et l’alerte sur les opérations de copie, d’export ou de génération de lien signé.

Le deuxième risque est la réplication implicite. Certains services activent une redondance multi-région, une analyse centralisée ou un support distant par défaut. La contre-mesure consiste à examiner les options de chaque service managé avant adoption, puis à tester la création d’une ressource avec des paramètres interdits. Une architecture ne doit pas dépendre d’une case cochée dans une console pour respecter une contrainte durable.

Le troisième risque est la compromission du plan de contrôle. Le plan de contrôle est l’ensemble des interfaces qui créent, modifient ou suppriment les ressources. Un attaquant capable de modifier une règle de réplication, une politique de sauvegarde ou une clé d’accès peut déplacer les données sans toucher à l’application. L’authentification multifacteur, les comptes d’administration séparés, les journaux immuables et les validations à deux personnes pour les changements de destination réduisent ce risque.

Le quatrième risque concerne les clés. Une clé exportable, une sauvegarde de clé non chiffrée ou une autorisation large sur une KEK annule la promesse de contrôle cryptographique. Les opérations de déchiffrement doivent être journalisées, limitées à des identités applicatives précises et refusées depuis des réseaux ou régions non approuvés. La rotation d’une KEK réenveloppe les DEK, mais ne rechiffre pas automatiquement toutes les données. Cette distinction doit être connue avant d’annoncer une rotation annuelle dans un tableau de conformité, ce sport de glisse administratif.

Exploitation, rotation et reprise hors région

Une résidence défendable nécessite un inventaire vivant des données, pas un document PDF fossilisé. Chaque ressource doit porter une classification, une région autorisée, une durée de conservation et une destination de sauvegarde. Les dérogations doivent expirer automatiquement. Une exception sans date de fin devient une architecture, mais sans les tests ni le budget.

La sauvegarde est le piège récurrent. Une sauvegarde disponible uniquement dans la même zone protège contre la suppression logique, pas contre une indisponibilité régionale. Une sauvegarde dans une autre région améliore la reprise, mais rompt potentiellement une exigence de résidence. Le choix dépend de la criticité :

• pour une donnée soumise à une résidence stricte, conserver la reprise dans le même périmètre juridique avec plusieurs sites ou zones indépendants ;
• pour une donnée dont l’indisponibilité est plus coûteuse que le transfert contrôlé, documenter une région de secours et chiffrer les copies avec des clés séparées ;
• pour une donnée non récupérable hors région, accepter explicitement le temps maximal de reprise plutôt que prétendre disposer d’un plan de continuité.

Les objectifs de temps de reprise et de point de reprise doivent être testés. Le premier mesure le délai acceptable avant remise en service. Le second mesure la perte maximale de données acceptable. Une restauration réussie doit inclure la restauration des clés, des politiques d’accès, des journaux et des dépendances d’identité. Restaurer les octets sans pouvoir les déchiffrer est une forme assez coûteuse de décoration numérique.

La supervision doit alerter sur les créations de réplication, les changements de région, les exports massifs, les accès aux clés et les désactivations de journalisation. Les journaux eux-mêmes exigent une résidence définie, une rétention limitée et un contrôle d’intégrité. Pour articuler ces contrôles avec les choix de plateforme, consulter l’architecture cyber et les services cloud.

La résidence ne garantit pas la confidentialité contre une application vulnérable, un utilisateur autorisé malveillant, une mauvaise classification ou une clé compromise. Elle ne remplace ni le cloisonnement des identités, ni le chiffrement applicatif, ni une revue des contrats, ni une analyse de risque. Elle fixe où les données peuvent circuler. Le reste doit venir de l’architecture de sécurité et de l’exploitation.

🐝 Ce qui arrive si on s’en passe

Sans cartographie des copies ni contrôle de région, une question simple reste sans réponse : où se trouvent les données au moment d’un incident. Le périmètre d’une notification ne peut plus être délimité, puisque la liste des copies concernées (index, caches, journaux, archives, exports de support) n’existe pas. Une demande d’effacement ne peut pas être démontrée : les données disparaissent du stockage primaire et survivent dans une réplique ou un coffre immuable. L’analyse après coup perd ses repères, car les journaux d’accès sont dispersés dans des périmètres dont la rétention n’est pas fixée. La réversibilité devient une inconnue budgétaire : sortir d’un service managé impose de retrouver, déchiffrer et transférer des volumes dont ni l’emplacement ni le coût de transit ne sont connus à l’avance.

🦫 Explication de la marmotte 🍫

Une donnée peut exister à plusieurs endroits en même temps. L’application garde une copie principale, puis crée souvent des sauvegardes, des journaux d’activité, des copies pour éviter une panne et des données destinées à l’analyse. Pour connaître son lieu réel, il faut donc examiner chaque copie, pas seulement le serveur principal.

La résidence indique les pays ou zones où ces copies sont conservées ou traitées. La souveraineté demande aussi qui peut décider d’y accéder. Un hébergeur peut stocker les données dans le bon pays tout en gardant la capacité technique de les lire ou de répondre à une demande venant d’une autre autorité.

Le chiffrement protège le contenu en le rendant illisible sans une clé. Cette protection dépend de la personne ou de l’organisation qui contrôle la clé. Si le même opérateur contrôle les fichiers et la clé, il peut généralement lire les données. Il faut donc séparer le stockage et le contrôle des clés pour les données les plus sensibles.

Les erreurs arrivent souvent lors des sauvegardes, des copies de secours ou du support technique. Une configuration peut envoyer une copie ailleurs sans modification de l’application. Il faut surveiller les créations de copies, limiter les personnes autorisées à les créer et tester la restauration. Si une panne survient, restaurer les données ne suffit pas : les clés, les droits d’accès et les journaux nécessaires doivent aussi être disponibles.

À lire aussi

• HSM cloud ou on-premise pour les clés critiquesComparer un HSM cloud et un HSM physique on-premise pour choisir où héberger les clés cryptographiques les plus critiques.
• Cyberspace Administration of China et conformité cybersécuritéMandat, exigences de données et conséquences d’architecture du Cyberspace Administration of China pour les systèmes opérés en Chine.
• Effacement des données dans une architecture distribuéeLe droit à l'effacement confronte les architectures distribuées aux réplicas, sauvegardes, caches et mécanismes cryptographiques.
• Cycle de vie de la donnée de la collecte à la destruction prouvéeConcevoir le cycle de vie d’une donnée, depuis sa collecte contrôlée jusqu’à sa destruction vérifiable et prouvée.

Pages voisines

La citent

• AIPD RGPD article 35 : méthode, critères et impact sur l'architecture
• Cloud Act et assistants IA américains, le risque réel
• Cloud IaaS, PaaS, SaaS et modèles de déploiement, qui sécurise quoi

Résidence des données et souveraineté cloud

Elle cite

• Ce que « hébergé en France » garantit
• Flux inter-cloud et résidence réelle des données
• Séparer plan de contrôle et plan de données