Le cloud change la nature du risque, pas seulement l'infrastructure
Migrer vers le cloud (AWS, Azure, GCP ou solutions SaaS) transforme profondément la manière dont une organisation doit penser sa sécurité. Ce n'est pas simplement « le même système d'information hébergé ailleurs » : le cloud introduit de nouveaux modèles de responsabilité, de nouveaux types de configuration à maîtriser, une facilité déconcertante à créer et détruire des ressources, et une élasticité qui peut aussi bien être un atout qu'un facteur de risque si elle n'est pas maîtrisée correctement dès le départ. Une entreprise qui aborde sa transformation cloud uniquement sous l'angle technique ou financier, sans intégrer la sécurité dès la phase de conception, s'expose à devoir corriger après coup des choix structurants bien plus difficiles à revoir une fois le projet en production. Ce constat vaut particulièrement pour les organisations qui migrent progressivement, application par application, sans disposer d'une vision d'ensemble cohérente de leur exposition cloud globale, et qui découvrent parfois tardivement qu'aucune équipe n'a de vue consolidée sur l'ensemble des ressources cloud réellement déployées.
La mauvaise configuration, premier risque cloud
Une part importante des incidents de sécurité observés dans le cloud provient non pas d'une faille technique du fournisseur cloud lui-même, mais d'une mauvaise configuration côté client : stockage rendu accessible publiquement par erreur, règles de pare-feu trop permissives, services exposés sans authentification suffisante, journalisation désactivée par défaut. La flexibilité du cloud, qui permet de créer et modifier des ressources en quelques clics sans passer par un processus de validation formel, augmente aussi le risque qu'une configuration incorrecte passe inaperçue si elle n'est pas revue régulièrement par une équipe compétente. C'est cette rapidité de déploiement, généralement perçue comme un avantage du cloud, qui devient un facteur de risque lorsqu'elle n'est pas accompagnée d'un contrôle de sécurité systématique à chaque changement.
Le modèle de responsabilité partagée, souvent mal compris
Les fournisseurs cloud sécurisent l'infrastructure sous-jacente (centres de données, réseau physique, virtualisation, disponibilité des services de base), mais la sécurité de ce qui est construit dessus — configuration des ressources, gestion des identités, sécurité des données et des applications, gestion des correctifs sur les systèmes exploités par le client — reste de la responsabilité du client. Ce partage des responsabilités est souvent mal compris, certaines organisations supposant à tort que « être dans le cloud » signifie que le fournisseur gère l'ensemble de la sécurité, y compris les choix de configuration effectués par leurs propres équipes. Clarifier précisément cette frontière, service par service, est une étape essentielle avant toute migration, et devrait être formalisée dans la gouvernance interne du projet plutôt que laissée à l'interprétation de chacun.
La prolifération des identités et des accès (IAM sprawl)
Le cloud facilite la création de comptes, de rôles et de permissions, ce qui conduit souvent à une accumulation d'accès accordés au fil du temps sans révision régulière : comptes de service créés pour un projet ponctuel puis oubliés, permissions trop larges accordées « pour aller plus vite » lors d'une phase de développement sous pression, accès d'anciens collaborateurs ou d'anciens prestataires jamais désactivés après leur départ. Cette prolifération des identités (IAM sprawl) élargit la surface d'attaque de façon souvent invisible tant qu'un audit régulier des accès n'est pas mené, car chaque accès pris isolément peut sembler mineur alors que leur accumulation représente un risque significatif.
La résidence des données : où sont réellement stockées vos données ?
Les grands fournisseurs cloud opèrent des centres de données dans plusieurs régions du monde, ce qui offre en théorie une grande flexibilité de déploiement. Selon la configuration choisie, les données d'une entreprise peuvent toutefois être stockées dans une région géographique différente de celle attendue, ce qui a des implications en matière de conformité réglementaire et de droit applicable — notamment pour les données personnelles soumises à des exigences de localisation ou de contrôle. Vérifier et configurer explicitement la localisation des données est une étape souvent négligée lors d'une migration cloud, réalisée dans l'urgence d'un projet, alors qu'elle peut avoir des conséquences directes sur les obligations de conformité de l'entreprise vis-à-vis de ses clients, de ses partenaires ou des autorités compétentes.
Comment sécuriser une migration cloud sans la freiner
Sécuriser une transformation cloud ne signifie pas ralentir le projet, mais l'intégrer dès la conception plutôt que de la traiter comme une contrainte de dernière minute. Cela passe par plusieurs réflexes concrets : auditer la configuration des ressources avant et après migration, revoir régulièrement les droits IAM plutôt qu'une seule fois à la création des comptes, chiffrer les données sensibles au repos et en transit, et intégrer des vérifications de sécurité automatisées dans les pipelines de déploiement (DevSecOps) plutôt que de les traiter comme une étape manuelle réalisée en fin de projet, quand les délais sont déjà sous pression. Une gouvernance cloud claire, avec des responsabilités explicitement définies en interne entre les équipes IT, sécurité et métiers, reste le facteur le plus déterminant pour éviter que la flexibilité du cloud ne se transforme en angle mort de sécurité difficile à corriger a posteriori. Impliquer la sécurité comme partie prenante du projet de migration, au même titre que les équipes techniques et métier, plutôt que comme un contrôle final, change fondamentalement la façon dont ces risques sont anticipés et traités.