Multi-cloud : le risque se trouve parfois entre les clouds

Une entreprise peut avoir correctement sécurisé chacun de ses environnements cloud et conserver malgré tout une architecture difficile à maîtriser.

Azure possède ses règles.

AWS possède les siennes.

GCP possède les siennes.

Un quatrième fournisseur héberge éventuellement certaines charges ou sauvegardes.

Pris séparément, chaque environnement peut sembler cohérent.

Mais l’application métier, elle, ne s’arrête pas à la frontière d’un fournisseur.

En août 2026, le NIST a publié un projet de rapport consacré précisément à cette difficulté. Son groupe de travail sur la sécurité multi-cloud a identifié 23 catégories de problèmes qui apparaissent ou deviennent plus importantes lorsque plusieurs silos cloud autonomes doivent fonctionner ensemble.1

La conclusion architecturale est importante : le risque multi-cloud ne réside pas seulement dans chaque cloud. Il se trouve aussi entre eux.

Trois clouds ne forment pas une architecture unique

Prenons une organisation utilisant :

Entra ID → identité

AWS → applications

GCP → données et IA

un fournisseur européen → sauvegardes ou workloads spécifiques

Du point de vue du métier, cet ensemble peut fournir un seul service.

Du point de vue technique, il s’agit pourtant de plusieurs univers disposant de leurs propres modèles IAM, journaux, services réseau, mécanismes de chiffrement, rôles, API, consoles, politiques et responsabilités partagées.

Le problème n’est donc pas seulement d’administrer plusieurs clouds.

Il faut réussir à construire un contrôle cohérent au-dessus de systèmes qui ont été conçus pour être autonomes.

Le NIST identifie 23 zones de friction

Le NIST IR 8613 traite des difficultés de sécurité et d’autorisation propres ou particulièrement amplifiées dans les architectures multi-cloud.1

Le groupe de travail a consolidé les problèmes en 23 domaines.

Trois difficultés structurelles ressortent particulièrement : les différences significatives entre services cloud natifs, la complexité organisationnelle et humaine des environnements hétérogènes et la difficulté à mettre en œuvre des capacités de sécurité réellement centralisées au-delà des frontières des fournisseurs.1

Ces difficultés se concentrent ensuite particulièrement sur cinq domaines :

IAM

télémétrie et journalisation

configuration et gestion des changements

protection des données

conformité et autorisation

Ces cinq domaines ont un point commun : ils doivent fonctionner transversalement.

L’IAM est cohérent jusqu’à la frontière suivante

Imaginons qu’Entra ID soit l’identité principale de l’entreprise.

Un utilisateur s’authentifie puis accède à AWS par fédération.

Dans AWS, son identité devient un rôle.

Ce rôle autorise ensuite l’accès à une application.

L’application appelle enfin une API hébergée ailleurs.

La chaîne peut devenir :

utilisateur → Entra ID → fédération → rôle AWS → application → API externe

Chaque étape possède son propre modèle d’autorisation.

Une revue des utilisateurs dans Entra ID ne décrit donc pas nécessairement les droits effectifs dans AWS.

Une revue des rôles AWS ne décrit pas nécessairement l’origine de l’identité.

La question devient :

« pouvons-nous reconstruire toute la chaîne d’autorisation d’un utilisateur jusqu’à la ressource finale ? »

Les architectures fédérées sont anciennes : le NIST décrivait déjà en 2020 des modèles structurés autour de plans de confiance, de sécurité et de partage des ressources.2

Le multi-cloud moderne multiplie le nombre et la diversité de ces relations.

Quatre consoles de logs ne créent pas une vision transverse

Le deuxième problème concerne l’observation.

Chaque fournisseur peut produire d’excellents journaux.

Mais un incident ne respecte pas nécessairement leurs frontières.

Un événement peut suivre :

identité → cloud A → API → cloud B → base de données

Si chaque étape est enregistrée dans une plateforme différente avec horodatages, identifiants, formats, rétentions et équipes différents, l’organisation possède beaucoup de logs sans nécessairement posséder une chronologie exploitable.

Le problème n’est donc plus seulement la collecte.

C’est la capacité à relier les événements.

La responsabilité partagée est elle-même distribuée

Dans un cloud unique, le modèle de responsabilité partagée peut déjà demander un effort important.

Dans un environnement multi-cloud, l’organisation doit composer plusieurs variantes de ce modèle.

Un service peut être IaaS chez un fournisseur, PaaS chez un autre et SaaS ailleurs.

Pour une même fonction métier, les responsabilités sur le système, le moteur de base de données, l’identité ou l’infrastructure peuvent être réparties différemment.

La question utile n’est alors plus simplement :

« qui est responsable de ce service ? »

mais :

« qui est responsable de chaque contrôle nécessaire au fonctionnement complet de la chaîne ? »

Le changement dans un cloud peut casser un autre cloud

La configuration constitue une troisième zone de friction.

Une modification de route, de certificat, de règle réseau, de rôle IAM ou d’API peut avoir des conséquences en dehors du fournisseur où elle est effectuée.

Prenons :

application AWS → API GCP

Si l’équipe GCP modifie une politique d’accès, le service AWS peut devenir indisponible.

Si AWS change un certificat ou une adresse de sortie, la politique GCP peut ne plus reconnaître l’appel.

Les deux environnements peuvent donc être individuellement conformes à leurs standards internes tout en créant ensemble une défaillance.

La dépendance pertinente est :

configuration A → dépendance B → comportement C

C’est précisément ce type de relation que les approches multi-cloud rendent difficile à documenter de manière uniforme.

Les données possèdent plusieurs géographies

Le multi-cloud complique également une question apparemment simple :

où se trouve cette donnée ?

Une donnée peut être créée dans un cloud, traitée dans un deuxième, mise en cache dans un troisième puis sauvegardée dans un quatrième.

La représentation réelle devient :

source → traitement → stockage → réplication → sauvegarde

Chaque étape peut avoir sa propre localisation, juridiction, politique de chiffrement, clé, rétention et mécanisme de suppression.

Le problème de gouvernance n’est donc pas uniquement de connaître le fournisseur principal.

Il faut reconstruire le parcours de la donnée entre fournisseurs.

Le périmètre du système devient difficile à tracer

Le rapport NIST souligne une difficulté particulièrement intéressante : les processus d’autorisation reposent traditionnellement sur une définition claire du périmètre du système, de son architecture réseau, de sa documentation de sécurité et de ses contrôles.1

Or, en multi-cloud, cette frontière peut devenir floue.

Est-ce que le système est :

le compte AWS ?

le tenant Azure ?

le projet GCP ?

l’application métier ?

toute la chaîne technique nécessaire à son fonctionnement ?

Pour la gouvernance et l’analyse de risque, la dernière définition est souvent la plus utile.

Mais c’est aussi la plus difficile à documenter.

Le NIST a lui-même utilisé une analyse graphique des problèmes

Le groupe de travail Multi-Cloud Security du NIST a travaillé sur une analyse des relations entre difficultés multi-cloud.

Son approche représente les problèmes comme des nœuds et les relations comme des liens exprimant notamment dépendance, causalité, conflit et amplification.3

L’idée est particulièrement intéressante pour l’architecture.

Le problème « IAM hétérogène » n’est pas isolé.

Il peut amplifier la journalisation fragmentée, la difficulté d’autorisation, la gestion des configurations ou la complexité organisationnelle.

Le risque multi-cloud ressemble donc moins à une liste de 23 cases indépendantes qu’à un graphe de problèmes interdépendants.

Cas construit : un service métier réparti sur quatre fournisseurs

Prenons un service de gestion documentaire fictif.

Les salariés utilisent Entra ID.

L’application fonctionne dans AWS.

Un moteur d’analyse documentaire est hébergé dans GCP.

Les sauvegardes sont stockées chez un fournisseur européen.

Le chemin devient :

utilisateur → Entra ID → AWS → application → API GCP → données → sauvegarde externe

Un audit séparé peut conclure que chaque environnement est correctement configuré.

Pourtant, plusieurs questions demeurent :

qui peut suivre l’identité de bout en bout ?

qui possède la chronologie complète d’un incident ?

où se trouve la donnée à chaque étape ?

quels changements peuvent casser une dépendance ?

quelle équipe est responsable de l’interface entre deux clouds ?

que se passe-t-il si un fournisseur devient indisponible ?

Aucun fournisseur ne peut répondre seul à ces questions.

La cartographie utile est celle des interfaces

Une représentation multi-cloud pertinente peut partir des objets suivants :

service métier → application → cloud → compte/projet/tenant → service → donnée → identité → flux → cloud suivant

Mais il faut surtout documenter les interfaces :

identité A → rôle B

workload A → API B

donnée A → réplication B

journal A → SIEM B

configuration A → dépendance B

équipe A → responsabilité sur B

C’est à ces frontières que les incohérences deviennent visibles.

Les équipes constituent elles aussi une dépendance multi-cloud

La complexité n’est pas uniquement technique.

Le NIST souligne aussi les difficultés organisationnelles et de staffing dans les environnements hétérogènes.1

Une organisation peut avoir une équipe Azure, une équipe AWS, une équipe data, une équipe sécurité, un SOC et plusieurs intégrateurs.

Chaque équipe connaît correctement son périmètre.

Mais qui possède la compréhension de la chaîne complète ?

Une architecture peut donc être techniquement documentée et rester organisationnellement fragmentée.

La relation à représenter devient :

composant → responsable → équipe → capacité d’intervention

Elle est particulièrement importante en incident.

Le multi-cloud peut augmenter la résilience et la complexité simultanément

Utiliser plusieurs fournisseurs peut répondre à de nombreux objectifs légitimes : éviter certaines dépendances, accéder aux meilleurs services, répondre à des contraintes de souveraineté, répartir les risques ou accompagner plusieurs métiers.

Le NIST IR 8613 ne dit pas que le multi-cloud est intrinsèquement mauvais.

Il met en évidence les frictions introduites lorsque plusieurs environnements indépendants doivent être gouvernés comme un ensemble.1

C’est une nuance importante.

La question n’est pas :

« faut-il éviter le multi-cloud ? »

mais :

« disposons-nous des mécanismes permettant de voir et gouverner ce qui se passe entre nos clouds ? »

Le contexte européen renforce aussi l’importance de cette visibilité : l’ENISA décrit des écosystèmes numériques de plus en plus interconnectés et suit la maturité des secteurs de haute criticité couverts par NIS2.45

Cinq tests simples à appliquer

Pour une application réellement multi-cloud, cinq exercices permettent rapidement de mesurer cette maîtrise.

1. Identité : partir d’un utilisateur et reconstruire ses droits jusqu’à la ressource finale.

2. Incident : partir d’un événement et reconstruire toute sa chronologie entre fournisseurs.

3. Donnée : partir d’une donnée et identifier chaque endroit où elle est stockée, traitée ou copiée.

4. Changement : modifier fictivement une configuration critique et identifier tous les composants susceptibles d’être impactés.

5. Responsabilité : sélectionner une interface entre deux clouds et désigner l’équipe qui en est réellement responsable.

Si ces réponses nécessitent plusieurs jours d’enquête, le problème n’est probablement pas l’absence d’informations.

C’est l’absence de vision transverse.

Le vrai objet à sécuriser est le service, pas chaque cloud

Une architecture multi-cloud ne devient pas maîtrisée parce que chacun de ses fournisseurs est bien sécurisé.

Les utilisateurs ne consomment pas des tenants, des subscriptions ou des projects.

Ils consomment des services.

Et ces services traversent parfois plusieurs fournisseurs.

Le changement de perspective consiste donc à passer de :

cloud A + cloud B + cloud C

à :

service métier → toutes ses dépendances, quel que soit leur fournisseur

Le principal enseignement du NIST IR 8613 est peut-être là : dans une architecture multi-cloud, les frontières entre clouds deviennent elles-mêmes des composants de l’architecture de sécurité.