Résumé exécutif
L'hypothèse la plus dangereuse des projets de migration cloud est que la responsabilité de la sécurité serait transférée au fournisseur en même temps que l'infrastructure. La prévision largement citée de Gartner — « d'ici 2025, 99 % des défaillances de sécurité cloud seront imputables au client » — s'est vérifiée sur le terrain : l'infrastructure des grands fournisseurs cloud est rarement compromise ; ce qui l'est, ce sont les brèches que le client laisse dans son propre périmètre de responsabilité.[1]
Le volet financier pointe dans la même direction. Selon le rapport IBM Cost of a Data Breach 2025, le coût moyen mondial d'une violation atteint 4,44 millions de dollars ; les violations impliquant des données réparties sur plusieurs environnements se situent au-dessus de la moyenne.[2] Le constat frappant du rapport 2023 d'IBM clarifie le tableau : 82 % des violations examinées impliquaient des données stockées dans le cloud.[3] Selon l'étude de Flexera, environ 89 % des organisations utilisent plusieurs clouds — cette surface de risque n'est donc pas le problème d'un fournisseur unique, mais celui de l'incohérence entre les environnements.[4]
Ce rapport examine la couche la plus mal comprise du modèle de responsabilité partagée : la distribution et la protection des applications. Il décompose la matrice de responsabilité couche par couche, recense les erreurs de configuration de la couche applicative que nous observons le plus souvent sur le terrain et analyse pourquoi la dérive de politiques est la faille la moins repérée dans les environnements hybrides.
La faille de sécurité cloud en chiffres
Part du client dans les défaillances de sécurité cloud (prévision Gartner)
Moyenne mondiale (IBM 2025)
Part des violations examinées (IBM 2023)
Organisations utilisant plusieurs clouds (Flexera)
Le modèle est simple, son interprétation ne l'est pas
Le modèle de responsabilité partagée n'est pas complexe en soi : le fournisseur est responsable de la sécurité du cloud, le client de la sécurité de ce qui se trouve dans le cloud. La complexité naît du déplacement de la frontière selon le modèle de service et du fait que les organisations la situent plus haut qu'elle ne l'est. En IaaS, tout appartient au client à partir du système d'exploitation ; en PaaS, la plateforme passe au fournisseur, mais pas la configuration applicative ; même en SaaS, la classification des données, les politiques d'accès et la configuration d'identité restent au client.
Le point critique est le suivant : quel que soit votre modèle, le contrôle du trafic qui atteint votre application — qui y accède, quelle requête est légitime, quelles données en sortent — ne passe jamais au fournisseur. Le fournisseur peut vous fournir des outils ; il n'assume pas la responsabilité.
La matrice de responsabilité, couche par couche
| Couche | IaaS | PaaS | SaaS |
|---|---|---|---|
| Infrastructure physique et hyperviseur | Fournisseur | Fournisseur | Fournisseur |
| Contrôles réseau | Partagé | Partagé | Fournisseur |
| Système d'exploitation et middleware | Client | Fournisseur | Fournisseur |
| Application et politiques de trafic | Client | Client | Partagé |
| Données, identité et configuration des accès | Client | Client | Client |
Les erreurs de couche applicative les plus fréquentes sur le terrain
Les erreurs qui alimentent les violations cloud n'ont rien d'exotique ; les mêmes schémas se répètent. Dans les classements de menaces de la Cloud Security Alliance, la mauvaise configuration et le contrôle des changements insuffisant occupent le haut du tableau depuis des années.[5] Voici ce que nous observons le plus souvent :
WAF oublié en mode détection
Les politiques WAF passées en mode détection pendant la migration « pour observer d'abord » ne sont jamais basculées en mode protection dans la précipitation de la mise en production. L'organisation se croit protégée ; le WAF ne produit que des journaux.
Règles réseau trop permissives
Les règles NSG/groupes de sécurité élargies pour un dépannage deviennent permanentes. Les exceptions 0.0.0.0/0 « temporaires » laissent des endpoints d'administration hors inventaire exposés sur internet.
Trafic en clair après la terminaison
TLS est terminé sur l'équilibreur de charge, et le trafic circule en clair sur le réseau interne. Dans le cloud, la notion de « réseau interne » est plus poreuse qu'en centre de données ; laisser le trafic est-ouest non chiffré est la faille la plus silencieuse de votre périmètre de responsabilité.
Endpoints d'API absents de l'inventaire
Chaque microservice migré vers le cloud crée de nouveaux endpoints d'API. Les endpoints non découverts et sans schéma échappent à la couverture du WAF ; les attaquants préfèrent les endpoints non documentés aux endpoints documentés.
Dérive de règles entre environnements
Le jeu de règles affiné pendant des années on-prem est traduit « approximativement » vers un autre moteur dans le cloud. Les deux moteurs prennent des décisions différentes sur la même requête ; personne ne sait quel environnement a raison.
Configuration d'identité par défaut
L'accès conditionnel, l'application du MFA et les politiques de session sont laissés par défaut « en attendant un durcissement ultérieur ». Dans le cloud, l'identité a remplacé le périmètre réseau ; une configuration d'identité par défaut équivaut à un mur d'enceinte par défaut.
La faille de sécurité hybride la plus répandue n'est pas une CVE, mais une défaillance de processus : mature dans le centre de données, par défaut dans le cloud. Pendant que la copie on-prem d'une application est derrière une politique WAF stricte, sa copie cloud tourne des mois avec le jeu de signatures de base. Les attaquants scannent les deux copies et entrent par la plus faible. La dérive de politiques ne se corrige pas d'elle-même avec le temps ; tant qu'elle n'est pas mesurée, elle grandit.
Le coût réel de la complexité hybride
Exploiter deux moteurs WAF distincts ne se résume pas à deux licences. Ce sont deux langages de règles, deux listes d'exceptions, deux processus de test, deux jeux de preuves d'audit et deux expertises distinctes. L'équipe sécurité conçoit chaque changement deux fois, le teste deux fois, le documente deux fois. Cette charge cognitive se manifeste précisément aux moments les plus critiques — pendant la réponse à incident : répondre à la question « quelle règle était active dans quel environnement » prend des heures, pas des minutes.
Côté audit, le coût est encore plus visible. PCI DSS, le KVKK/RGPD et les réglementations sectorielles exigent des preuves d'audit pour chaque environnement entrant dans le périmètre. Prouver la même protection sous deux formes différentes dans deux produits différents multiplie le temps de préparation des audits ; les constats d'incohérence naissent le plus souvent des écarts d'interprétation entre les deux produits.
Le multi-cloud n'agrandit pas ce tableau de façon linéaire, mais multiplicative. Les données de Flexera montrent que la grande majorité des organisations utilisent plusieurs clouds ;[4] chaque nouvel environnement apporte un nouveau jeu de services de sécurité natifs et un nouveau langage de configuration. À mesure que le nombre d'environnements augmente, l'affirmation « la même protection dans chaque environnement » devient indéfendable tant qu'elle n'est pas construite au niveau des politiques plutôt qu'au niveau des outils.
Implications défensives
Inventoriez les flux de données
Quelle application tourne dans quel environnement, quelles données touche-t-elle, qui contrôle son trafic ? Sans inventaire, la matrice de responsabilité reste sur le papier.
Formalisez la matrice de responsabilité par écrit
Documentez explicitement la frontière fournisseur/client pour chaque modèle de service et ne laissez aucune couche orpheline. Vérifiez l'hypothèse « le fournisseur s'en charge » par un engagement écrit.
Mettez en place un plan de politiques unique
Exécutez le même jeu de contrôles — même moteur WAF, même langage de règles, même processus d'exceptions — dans chaque environnement. Quand la traduction de règles disparaît, la dérive de politiques est empêchée structurellement.
Assurez le chiffrement et la visibilité de bout en bout
Imposez TLS non seulement en périphérie, mais aussi sur le trafic est-ouest ; inspectez le trafic chiffré sans laisser d'angle mort.
Validez en continu
Testez l'équivalence des politiques en continu, pas lors d'un audit annuel : la même requête doit recevoir la même décision dans chaque environnement. Un écart doit être une alerte, pas un constat d'audit.
L'approche TR7 : la même protection dans chaque environnement
La réponse de TR7 à ce tableau est l'exécution de la même plateforme dans chaque environnement :
La même image sur Azure Marketplace
La plateforme virtuelle TR7 est proposée sous forme d'image prête à l'emploi sur Azure Marketplace ; le même moteur que sur le matériel tourne dans le cloud.
Portabilité des politiques
Les règles WAF, les profils SSL/TLS et les politiques d'accès se transfèrent entre les environnements sans traduction de règles ; une seule liste d'exceptions, un seul jeu de preuves d'audit.
Portabilité des licences
Les licences sont liées à l'organisation, pas à la plateforme ; elles se déplacent avec la charge de travail entre Azure, GCP et les hyperviseurs pris en charge.
Gestion du trafic hybride
GTM route le trafic entre les branches on-prem et cloud selon la santé, la géographie et la latence ; il constitue l'épine dorsale de la migration progressive.
Références et sources
Source de la prévision « d'ici 2025, 99 % des défaillances de sécurité cloud seront imputables au client ». https://www.gartner.com/smarterwithgartner/is-the-cloud-secure
Source principale pour le coût moyen mondial d'une violation (4,44 millions de dollars) et la ventilation des coûts par environnement. https://www.ibm.com/reports/data-breach
Constat selon lequel 82 % des violations examinées impliquaient des données stockées dans le cloud.
Étude annuelle sur les taux d'adoption du multi-cloud et les stratégies cloud des entreprises. https://www.flexera.com/blog/cloud/cloud-computing-trends-flexera-state-of-the-cloud-report/
Classement des menaces où la mauvaise configuration et le contrôle des changements insuffisant occupent le haut du tableau. https://cloudsecurityalliance.org/research/top-threats
Documentation officielle des frontières de responsabilité fournisseur/client selon les modèles de service. https://learn.microsoft.com/azure/security/fundamentals/shared-responsibility
La même protection dans chaque environnement
Vous n'avez pas à reconstruire votre couche de sécurité lors de la migration cloud. TR7 transfère vers Azure les politiques de protection et de distribution de votre centre de données avec le même moteur ; il fournit un plan de politiques unique, une gestion unique et un seul jeu de preuves d'audit.
Découvrir la solution WAAP