Flux inter-cloud et résidence réelle des données

Flux inter-cloud et résidence réelle des données

La résidence déclarée décrit généralement l’emplacement du stockage principal, pas l’ensemble des chemins empruntés par une donnée. Entre un appel applicatif, une réplication, un journal, un service de support ou un moteur d’analyse, la frontière géographique annoncée peut devenir une frontière assez décorative.

Explication de la marmotte

Une donnée hébergée dans un pays ressemble à un dossier rangé dans une armoire locale, mais confié à un service qui peut l’ouvrir, le photocopier ou le transporter pour faire son travail. L’étiquette sur l’armoire rassure, mais elle ne raconte pas tous les déplacements du dossier.

→ Lire l’explication complète de la marmotte

Résidence déclarée, traitement réel et métadonnées

La résidence des données désigne l’emplacement contractuel ou technique où le fournisseur stocke les données persistantes d’un service. Une région annoncée comme européenne peut donc héberger les volumes, les sauvegardes et les répliques synchrones. Cela ne démontre pas que chaque traitement reste dans cette région.

Il faut distinguer quatre catégories, car les contrats les mélangent volontiers sous le mot pratique de « données », lequel ne résout rien à lui seul :

1. Données de contenu : objets, documents, lignes de base de données, messages, sauvegardes.
2. Données de contrôle : identifiants de ressource, politiques d’accès, configuration, inventaire, jetons d’authentification et état du plan de contrôle.
3. Données d’observabilité : journaux, traces, métriques, captures d’erreur, en-têtes de requêtes et métadonnées réseau.
4. Données de support : extraits transmis à un outil d’assistance, captures de diagnostic, exports de configuration et sessions d’administration.

Le plan de données transporte ou stocke le contenu métier. Le plan de contrôle crée, configure et autorise les ressources. Un service peut localiser le premier dans une région donnée tout en exploitant un plan de contrôle distribué. La création d’un compte, l’évaluation d’une politique d’accès ou la gestion d’une clé peuvent alors appeler des composants situés dans une autre zone.

Les métadonnées ne sont pas inoffensives parce qu’elles ne contiennent pas un fichier complet. Une suite d’adresses Internet Protocol (IP), d’horodatages, de noms de ressources et de tailles d’objets peut révéler une activité métier, une structure d’organisation ou un rythme de production. Chiffrer le contenu et exporter les journaux vers une plateforme mondiale revient parfois à mettre le coffre dans la bonne région et son inventaire détaillé dans le hall d’entrée.

La règle de conception est nette : considérer toute donnée envoyée à un service managé comme susceptible d’être traitée dans un périmètre plus large que celui du stockage déclaré, tant qu’une preuve technique et contractuelle contraire n’existe pas. Une mention marketing de souveraineté ne constitue pas une preuve d’itinéraire. C’est une phrase sur une slide, et les slides traversent très bien les frontières.

Les chemins inter-cloud invisibles dans le contrat standard

Un flux inter-cloud apparaît dès qu’une application consomme plusieurs services dont les périmètres d’exploitation diffèrent. Le cas le plus fréquent n’est pas une réplication explicite entre deux stockages. C’est une chaîne de services : application dans une région, fournisseur d’identité, réseau de diffusion, surveillance, moteur d’analyse, service de tickets et sauvegarde externalisée.

La résolution par le Domain Name System (DNS) peut déjà orienter une requête vers un point d’entrée différent de la région attendue. Un nom régional peut renvoyer une adresse anycast, c’est-à-dire une adresse annoncée depuis plusieurs emplacements. Le point de terminaison vu par le client n’indique alors ni l’emplacement du traitement final, ni celui des journaux générés pendant la transaction.

Le chiffrement Transport Layer Security (TLS) protège le flux entre deux extrémités identifiées. Il ne contraint pas la localisation de ces extrémités, ni les systèmes qui reçoivent une copie légitime après déchiffrement. Une passerelle TLS mondiale peut terminer la session hors de la région, puis ouvrir une seconde session chiffrée vers le service régional. Sur le réseau, tout est chiffré. Pour la résidence, rien n’est démontré.

Les services d’observabilité sont une source classique d’écart. Une erreur applicative contient souvent l’URL, des en-têtes Hypertext Transfer Protocol (HTTP), un identifiant de session, un message d’exception et parfois une charge utile. Un collecteur de traces centralisé reçoit ces éléments avant que les règles de masquage ne les filtrent, ou après, ce qui est une nuance assez coûteuse. Le masquage côté collecteur protège trop tard.

Le support distant pose le même problème. Une autorisation temporaire d’accès peut permettre l’extraction d’un journal, d’une configuration ou d’un échantillon de données vers un environnement d’analyse global. Désactiver l’accès de support par défaut, exiger une activation à durée bornée et journaliser chaque export doivent faire partie du socle, pas d’une option découverte pendant l’incident.

La gouvernance des données doit donc inventorier les flux de diagnostic et d’administration au même niveau que les flux métier. Les architectures décrites dans la section cloud restent insuffisantes si les dépendances externes de chaque service ne sont pas cartographiées.

Compromis central : services managés ou maîtrise des frontières

Le compromis est brutal : les services managés réduisent l’exploitation quotidienne, mais élargissent la confiance accordée à l’opérateur et à sa chaîne technique. À l’inverse, isoler les flux, auto-héberger les briques de contrôle et opérer ses propres passerelles réduit l’exposition géographique, mais transfère la charge de disponibilité, de sécurité et de reprise.

La position recommandée est de réserver les données soumises à une contrainte territoriale forte à une architecture où trois conditions sont réunies :

• le plan de données est régional et documenté ;
• les données de contrôle et d’observabilité sont minimisées, filtrées et localisées ou chiffrées avant émission ;
• les clés de chiffrement restent sous contrôle dans un domaine distinct du fournisseur de traitement.

Cette recommandation vaut lorsque la confidentialité dépend réellement du territoire ou de l’entité capable d’accéder au contenu. Elle ne vaut pas pour chaque journal technique sans valeur métier : vouloir rapatrier toute télémétrie dans une forteresse locale peut rendre la détection d’incident aveugle. Le choix dépend de la classification de la donnée, de la tolérance à la latence, des capacités d’exploitation internes et du risque accepté sur les métadonnées.

Une clé gérée par le client n’est pas automatiquement une clé souveraine. Si le fournisseur peut demander le déchiffrement via une autorisation de service, le contrôle reste partiel. Un HSM (Hardware Security Module) externe ou dédié ne change la situation que si la politique d’autorisation, les identités techniques et le chemin réseau empêchent effectivement un déchiffrement non voulu. La cryptographie appliquée commence là où s’arrête l’icône de cadenas.

Le chiffrement côté client apporte la meilleure séparation : l’application chiffre avant l’envoi, et le service cloud ne reçoit que du texte chiffré. Le prix est réel : recherche limitée, indexation compliquée, analyse managée amputée, rotation de clés plus lourde et reprise après incident à concevoir. Une donnée chiffrée sans clé récupérable est parfaitement confidentielle, y compris pour son propriétaire. Le castor apprécie rarement cette forme de réussite.

Contrôles techniques pour prouver les flux inter-cloud

Une preuve exploitable combine documentation, observation et test. Les attestations de fournisseur décrivent un périmètre, mais ne remplacent pas une capture de flux, une configuration exportée ou une analyse de dépendance.

Commencer par établir, pour chaque service, une matrice contenant : type de donnée, région de stockage, région de traitement annoncée, destinations de journalisation, mécanisme de support, sauvegarde, clés utilisées et sous-traitants techniques. Toute valeur « global » ou « selon disponibilité » doit être traitée comme un risque ouvert, pas comme une localisation implicite.

Ensuite, observer les sorties réseau depuis les charges de travail. Le trafic sortant doit passer par une passerelle contrôlée, avec journalisation des noms demandés, des adresses de destination et de l’identité du service émetteur. Une capture réseau seule ne révèle pas le contenu TLS, mais elle révèle les dépendances et les chemins. Le chiffrement ne transforme pas une destination inconnue en destination acceptable.

Les politiques Identity and Access Management (IAM), ou gestion des identités et des accès, doivent interdire l’activation libre de services globaux. Autoriser la création de ressources sans restreindre les régions autorisées garantit qu’une ressource finira ailleurs. C’est moins une prédiction qu’une loi de gravité opérationnelle.

Enfin, tester les scénarios dégradés : bascule régionale, restauration de sauvegarde, ouverture d’un ticket de support, export de journaux, analyse de sécurité et rotation de clés. Une architecture reste locale jusqu’au premier incident, moment où les procédures d’urgence découvrent soudain une vocation internationale.

Exemple de vérification d’un point de terminaison régional

Cette vérification ne prouve pas le lieu de traitement final. Elle établit seulement la résolution DNS, l’adresse atteinte et le certificat TLS présenté depuis un réseau donné. Répéter le test depuis chaque zone réseau contrôlée et conserver les résultats avec la matrice de flux.

# Remplacer par un point de terminaison régional documenté par le fournisseur.
ENDPOINT="service.example-region.provider.net"

# Enregistrer les adresses renvoyées par le DNS.
dig +short "$ENDPOINT" | tee "dns-${ENDPOINT}.txt"

# Vérifier le nom présenté dans le certificat TLS et la chaîne reçue.
# Le paramètre servername force l'indication du nom attendu lors de la connexion.
openssl s_client \
  -connect "${ENDPOINT}:443" \
  -servername "$ENDPOINT" \
  -showcerts </dev/null 2>&1 \
  | tee "tls-${ENDPOINT}.txt"

# Journaliser l'adresse réellement contactée et les en-têtes de réponse.
curl --verbose --head --max-time 15 "https://${ENDPOINT}/" \
  2>&1 | tee "http-${ENDPOINT}.txt"

La présence d’un certificat valide ne prouve que l’identité cryptographique du point de terminaison. Elle ne prouve ni l’absence de relais, ni l’absence de réplication, ni la localisation d’un système de journalisation. Pour les flux critiques, compléter cette mesure par les journaux de passerelle, les traces applicatives expurgées et les engagements écrits portant explicitement sur les sous-traitants de traitement.

Exploitation : clés, sauvegardes et reprise territoriale

La gestion des clés décide de la valeur réelle du chiffrement. Une DEK (Data Encryption Key), ou clé de chiffrement de données, chiffre le contenu. Elle est généralement protégée par une KEK (Key Encryption Key), ou clé de chiffrement de clé. Si la KEK est disponible depuis une région non souhaitée, une copie chiffrée restaurée dans cette région peut redevenir lisible.

Conserver une hiérarchie de clés distincte par territoire limite ce risque. La rotation doit produire de nouvelles versions sans rendre les anciennes illisibles avant la fin de leur période de rétention. La suppression cryptographique, qui consiste à détruire la clé plutôt que chaque copie, ne fonctionne que si aucune autre clé ou export en clair ne subsiste. Les sauvegardes et les journaux d’export sont les coupables habituels.

La reprise doit être tranchée avant l’incident : accepter une restauration hors région, ou accepter l’indisponibilité jusqu’au rétablissement de la région autorisée. Il n’existe pas de troisième option magique où les données restent localisées, la disponibilité reste mondiale et personne ne paie le coût. Les promesses de résilience universelle méritent le même regard que les régimes miracles.

Superviser les changements de région, les exports, les ouvertures de support, les échecs de chiffrement et les accès aux clés. Une alerte sans procédure d’arrêt des flux ne protège rien. Prévoir une capacité de coupure : retirer une autorisation IAM, bloquer une destination réseau, suspendre une intégration ou désactiver une clé. La coupure de clé doit toutefois être testée : elle peut arrêter le flux indésirable et l’ensemble de l’activité, ce qui est rarement le moment préféré du comité de crise.

🐝 Ce qui arrive si on s’en passe

Sans cartographie des flux ni passerelle de sortie identifiant le service émetteur, une charge de travail compromise peut exfiltrer du contenu vers un compte contrôlé par l’attaquant chez le même fournisseur global : le nom DNS, l’adresse anycast et le certificat TLS sont identiques à ceux d’un usage légitime, donc un filtrage par domaine ou par adresse ne distingue pas les deux destinations. Après un incident, l’absence de journal des destinations empêche aussi de délimiter les systèmes ayant reçu une copie. Le périmètre d’une notification, d’une purge ou d’une demande d’effacement reste alors impossible à établir. Toute copie détenue par un outil d’observabilité ou de support non inventorié survit à la suppression de la source, et aucune preuve ne permet d’affirmer le contraire.

🦫 Explication de la marmotte 🍫

Une entreprise peut choisir une région pour conserver les fichiers et les bases de données. Cela signifie que les copies principales sont rangées dans cette région. Mais le service qui les utilise peut aussi envoyer des informations ailleurs pour vérifier un accès, enregistrer une erreur, aider une personne du support, faire une sauvegarde ou analyser une activité inhabituelle.

Le premier problème est que les informations envoyées ailleurs ne sont pas toujours le fichier entier. Un nom de fichier, une adresse réseau, l’heure d’une action, un identifiant de compte ou un message d’erreur peuvent déjà révéler beaucoup de choses. Le deuxième problème est que le chiffrement protège surtout le trajet entre deux systèmes. Il ne décide pas du pays où le système destinataire travaille.

Pour contrôler la situation, il faut lister chaque service utilisé et noter ce qu’il reçoit, où il conserve ces informations et où il peut les traiter. Il faut aussi observer les connexions réseau et vérifier ce qui se passe lors d’une panne, d’une restauration ou d’une demande d’assistance.

Les clés de chiffrement doivent rester sous un contrôle séparé. Si une copie des données est déplacée, elle reste illisible sans la clé. Si la clé peut être utilisée depuis n’importe quel endroit, cette protection perd une grande partie de son intérêt. En cas de doute sur une destination, le flux doit pouvoir être bloqué rapidement.

À lire aussi

• Résidence des données et souveraineté cloudRésidence des données et souveraineté : distinguer la localisation réelle des données, le contrôle technique et les dépendances juridiques.
• 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.
• Sécuriser les bases de données managées cloudSécuriser RDS, Cloud SQL et les bases managées contre les accès réseau exposés, les secrets applicatifs mal gérés et les instantanés partagés publiquement.
• Conformité export et sanctions numériquesSanctions numériques et géopolitique : architecturer les contrôles export, le filtrage des accès et les preuves de conformité cyber.

Pages voisines

La citent

• Cloud IaaS, PaaS, SaaS et modèles de déploiement, qui sécurise quoi
• Cyberspace Administration of China et conformité cybersécurité
• Résidence des données et souveraineté cloud

Flux inter-cloud et résidence réelle des données

Elle cite

• BGP, Internet, anycast et sécurité des annonces
• Comment détruire une clé pour effacer des données chiffrées
• HSM cloud ou on-premise pour les clés critiques