Chaque migration vers le cloud déplace la question de la sécurité, mais ne l’efface pas. Trois grands providers dominent le marché — Microsoft Azure, Amazon Web Services et Google Cloud — et chacun propose un cadre de protection distinct. Comprendre ce cadre, identifier les outils associés et poser les bons contrôles reste la responsabilité de l’entreprise, quelle que soit la plateforme retenue. Ce guide analyse les mécanismes concrets disponibles sur chacune d’elles.
Vos 3 priorités avant de démarrer :
- Cartographier votre périmètre de responsabilité selon le modèle partagé de votre provider
- Activer et configurer les outils natifs de supervision de sécurité (Microsoft Defender for Cloud, AWS Security Hub, Google Security Command Center)
- Mettre en œuvre le chiffrement des données et la gestion fine des identités dès le premier déploiement
La sécurité dans le cloud n’est pas un interrupteur que l’on actionne une fois. C’est un ensemble de couches — contrôle des accès, chiffrement, surveillance des configurations, conformité réglementaire — que chaque organisation doit orchestrer activement. Avant d’examiner les outils disponibles, il est utile de poser le cadre juridique et contractuel dans lequel ces outils s’inscrivent.
Selon le baromètre 2025 de l’ANSSI, l’Agence Nationale de la Sécurité des Systèmes d’Information a recensé 3 739 incidents de sécurité en 2024, soit une hausse de 10 % par rapport à 2023, avec les ransomwares représentant 42 % des incidents. Un contexte qui illustre l’urgence d’une posture de sécurité cloud structurée et non laissée aux paramètres par défaut.
- Le modèle de responsabilité partagée : ce que le provider couvre (et ce qu’il ne couvre pas)
- Les outils de sécurité natifs sur Azure, AWS et Google Cloud
- Chiffrement et gestion des clés : les approches comparées
- Conformité RGPD et certifications : ce que l’entreprise doit vérifier
- Votre plan d’action pour sécuriser votre environnement cloud
Le modèle de responsabilité partagée : ce que le provider couvre (et ce qu’il ne couvre pas)
Chaque provider de cloud public formalise contractuellement une ligne de démarcation entre ce qu’il sécurise et ce qui reste à la charge du client. Ce modèle — souvent désigné par l’expression Shared Responsibility Model — est documenté par Azure, AWS et Google Cloud dans leurs documentations officielles respectives. La frontière varie selon le mode de service utilisé : infrastructure (IaaS), plateforme (PaaS) ou logiciel (SaaS).
En IaaS, le provider assure la sécurité physique des datacenters, la disponibilité du réseau et la virtualisation. L’entreprise prend en charge le système d’exploitation, les applications, les données et la gestion des accès. En PaaS, la frontière remonte : le provider gère également le système d’exploitation et les middlewares, mais la configuration des services et la protection des données restent côté client. La confusion entre ces périmètres est l’une des sources les plus fréquentes d’exposition involontaire de données.
La mise en place d’une connectivité cloud privée dédiée constitue une première barrière concrète pour éviter que les échanges entre le réseau d’entreprise et l’infrastructure cloud ne transitent par l’internet public — un point d’exposition que le modèle partagé ne couvre pas.
Cas pratique : exposition d’un bucket de stockage
Prenons une situation classique : une équipe DevOps déploie un stockage objet sur une plateforme IaaS pour héberger des fichiers de configuration. Les droits d’accès sont laissés aux paramètres par défaut du provider. Résultat : le bucket est accessible en lecture publique. Le provider a bien sécurisé son infrastructure physique — sa responsabilité contractuelle est respectée. L’entreprise, elle, n’a pas configuré les politiques d’accès. La fuite de données qui s’ensuit est entièrement imputable à ce que le modèle partagé place dans la zone de responsabilité client. Ce type d’incident, loin d’être exceptionnel, illustre pourquoi la compréhension du périmètre propre à chaque service est un préalable non négociable.
Les trois providers proposent des guides de configuration sécurisée (« Security Baselines ») qui détaillent, service par service, les paramètres à activer. Ces guides constituent le point de départ recommandé pour toute équipe qui déploie un nouvel environnement cloud, avant même d’aborder les outils de surveillance.
Les outils de sécurité natifs sur Azure, AWS et Google Cloud
Chaque plateforme propose un hub centralisé de gestion de la posture de sécurité. Ces outils analysent en continu la configuration des ressources, détectent les dérives par rapport aux bonnes pratiques et génèrent des alertes. Leur périmètre et leur ergonomie diffèrent, mais leur logique de fonctionnement est comparable.
Le récapitulatif ci-dessous synthétise les principales caractéristiques de chaque outil natif. Chaque ligne présente le nom de la solution, sa fonction centrale et une spécificité technique notable. Ces informations permettent d’identifier rapidement quelle plateforme couvre le mieux les besoins d’une organisation selon sa stack existante.
| Provider | Outil principal | Fonction centrale | Particularité |
|---|---|---|---|
| Microsoft Azure | Microsoft Defender for Cloud | Score de sécurité, détection des menaces, recommandations de remédiation | Intégration native avec Microsoft Sentinel (SIEM) |
| Amazon AWS | AWS Security Hub | Agrégation des alertes multi-services, conformité aux standards CIS | Connecteurs natifs avec GuardDuty et Inspector |
| Google Cloud | Google Security Command Center | Cartographie des actifs, détection des configurations à risque, threat intelligence | Intégration avec Chronicle (SIEM Google) |
La gestion des identités et des accès constitue le second pilier opérationnel. Microsoft Entra ID (anciennement Azure Active Directory) centralise l’authentification et les politiques d’accès conditionnel dans l’écosystème Microsoft. Sur AWS, Identity and Access Management (IAM) permet de définir des rôles et des politiques d’autorisation granulaires, service par service et ressource par ressource. Google Cloud IAM fonctionne sur une logique similaire, avec une gestion des permissions par projet et par hiérarchie organisationnelle. Les trois implémentent le principe du moindre privilège, qui consiste à n’accorder que les droits strictement nécessaires à chaque identité.
Les recommandations officielles de la CNIL en matière de sécurisation du cloud insistent sur la combinaison du chiffrement avec une gestion des accès robuste et l’activation systématique de l’authentification multi-facteurs (MFA). Ces deux mesures restent parmi les plus efficaces pour contenir les conséquences d’une compromission de credentials.
Chiffrement et gestion des clés : les approches comparées
Le chiffrement des données est documenté comme actif par défaut sur les trois plateformes pour le stockage au repos, généralement en AES-256. Le chiffrement en transit repose sur TLS pour les échanges entre services et entre le client et l’infrastructure. Ces comportements par défaut couvrent la base — mais la question de la gestion des clés de chiffrement est celle qui détermine réellement le niveau de contrôle dont dispose l’entreprise.
Trois modèles coexistent sur les principales plateformes. Dans le modèle cloud-native, le provider génère et gère les clés dans son propre HSM (Hardware Security Module). L’entreprise délègue entièrement cette responsabilité. Dans le modèle BYOK (Bring Your Own Key), l’entreprise génère ses propres clés et les importe dans le service de gestion de clés du provider (Azure Key Vault, AWS KMS, Google Cloud KMS). Le provider accède encore techniquement aux clés pour opérer les chiffrements. Le modèle HYOK (Hold Your Own Key) pousse le contrôle plus loin : les clés sont stockées dans un HSM que l’entreprise maîtrise entièrement, en dehors de l’infrastructure du provider.
- Si vos données ne sont pas soumises à des réglementations sectorielles strictes :
Le chiffrement cloud-native offre un bon niveau de protection avec une complexité opérationnelle minimale.
- Si vous traitez des données à caractère personnel ou des données métier sensibles :
Le modèle BYOK renforce votre position en cas d’audit RGPD et vous permet de révoquer l’accès aux données en supprimant la clé.
- Si vous opérez dans un secteur régulé (santé, finance, défense) :
Le modèle HYOK ou une solution souveraine certifiée HDS/SecNumCloud est à examiner en priorité.
- Si vous gérez un environnement multi-cloud :
Une solution de KMS externe et indépendante du provider (ex : Thales CipherTrust, HashiCorp Vault) évite les silos de clés et simplifie la gouvernance.
La pratique démontre que la configuration par défaut du chiffrement ne suffit pas dès lors que l’entreprise cherche à prouver sa maîtrise de l’accès aux données — notamment face à la CNIL ou à un client exigeant des garanties contractuelles sur la localisation et la protection des données.
Les directives 2024 du NIST dans sa publication SP 800-207 définissent le modèle Zero Trust comme une architecture qui supprime toute confiance implicite : chaque requête d’accès, qu’elle provienne d’un utilisateur interne ou externe, d’un appareil connu ou inconnu, fait l’objet d’une vérification continue. Les trois providers proposent des blueprints d’architecture Zero Trust adaptés à leurs services respectifs.
Conformité RGPD et certifications : ce que l’entreprise doit vérifier
Le Règlement général sur la protection des données (UE 2016/679) s’applique à tout responsable de traitement établi en Europe ou traitant des données de résidents européens — indépendamment du provider cloud choisi. L’utilisation d’AWS, d’Azure ou de Google Cloud ne transfère pas la responsabilité de conformité RGPD vers le provider. Ce dernier agit en tant que sous-traitant au sens de l’article 28 du Règlement, ce qui impose la signature d’un accord de traitement des données (DPA) formalisant les obligations de chaque partie.
Les trois providers ont obtenu des certifications internationales qui couvrent tout ou partie de leurs services : ISO 27001 (management de la sécurité de l’information), SOC 2 Type II (contrôles de sécurité et disponibilité), et, pour les usages en santé en France, l’hébergement de données de santé (HDS). Ces certifications ne dispensent pas l’entreprise de ses propres obligations de configuration, mais elles constituent une base de diligence raisonnable qui peut être opposée lors d’un audit.
Bon à savoir : Les transferts de données hors Union européenne vers des datacenters américains restent un point de vigilance RGPD, même avec un DPA signé. Azure, AWS et Google Cloud proposent des régions Europe (dont des régions France et Allemagne) permettant de localiser les données sur le territoire de l’UE. Vérifiez que vos services sont configurés pour utiliser ces régions et non des régions par défaut situées aux États-Unis.
Au-delà des certifications, la gestion des méthodes de sécurisation des données professionnelles au sens large — journalisation des accès, détection des comportements anormaux, gestion des droits d’accès des prestataires — conditionne la capacité à démontrer la conformité lors d’un contrôle. L’activation des journaux d’audit (CloudTrail sur AWS, Azure Monitor Logs, Cloud Audit Logs sur GCP) est un prérequis documenté par la CNIL pour toute organisation gérant des données personnelles dans le cloud.
Un environnement cloud correctement configuré permet également de s’appuyer sur les méthodes de sécurisation des données professionnelles déjà en place dans l’organisation, en les étendant au périmètre cloud plutôt qu’en construisant une politique distincte.
Votre plan d’action pour sécuriser votre environnement cloud
Les points traités dans cet article dessinent un chemin structuré : comprendre le périmètre de responsabilité, activer les outils de surveillance natifs, choisir un modèle de gestion des clés adapté, et formaliser la conformité RGPD. Ces quatre axes ne sont pas séquentiels — ils doivent progresser en parallèle dès le démarrage d’un projet cloud.
Les organisations qui attendent que leur environnement soit pleinement déployé pour aborder la sécurité se retrouvent à corriger des architectures existantes, exercice nettement plus coûteux et risqué que d’intégrer les contrôles dès la conception. La pratique du marché démontre que les incidents de sécurité cloud les plus courants ne résultent pas de vulnérabilités zero-day, mais de configurations incorrectes et de droits d’accès non révoqués — deux problèmes que les outils natifs détectent, à condition d’être activés et surveillés.
- Cartographier les services cloud actifs et identifier pour chacun le périmètre de responsabilité client selon le mode IaaS/PaaS/SaaS
- Activer Microsoft Defender for Cloud, AWS Security Hub ou Google Security Command Center et traiter les recommandations critiques en priorité
- Auditer les politiques IAM : supprimer les rôles non utilisés, activer le MFA sur tous les comptes à privilèges élevés
- Vérifier que les données sensibles sont chiffrées avec un modèle de clés adapté à votre niveau de sensibilité (cloud-native, BYOK ou HYOK)
- Confirmer la signature d’un DPA avec chaque provider et vérifier que les régions de stockage actives correspondent aux exigences RGPD
La sécurité cloud n’est pas un état figé : c’est un processus de surveillance continue. Les providers enrichissent régulièrement leurs services, les surfaces d’attaque évoluent, et les réglementations s’affinent. Pour les organisations qui souhaitent aller plus loin, notamment sur la continuité d’activité et les solutions de stockage redondantes, les solutions de stockage en ligne et leur expertise sur les serveurs dédiés offrent un complément utile pour sécuriser l’accessibilité des données critiques.
3 739incidents
Incidents de sécurité recensés par l’ANSSI en France en 2024, en hausse de 10 % sur un an
Le provider cloud est-il responsable de la sécurité de mes données ?
Non, pas entièrement. Le modèle de responsabilité partagée distingue ce que le provider sécurise (infrastructure physique, virtualisation, réseau du datacenter) et ce qui reste à la charge du client (configuration des services, gestion des accès, chiffrement des données applicatives). En mode IaaS, la grande majorité des contrôles de sécurité applicatifs incombent à l’entreprise cliente.
Le chiffrement par défaut suffit-il pour la conformité RGPD ?
Le chiffrement par défaut (AES-256 au repos, TLS en transit) constitue une base, mais il ne couvre pas l’ensemble des obligations RGPD. La localisation des données, la gestion des droits d’accès, les journaux d’audit et la signature d’un accord de traitement des données (DPA) avec le provider sont des éléments tout aussi essentiels que le seul chiffrement technique.
Peut-on utiliser plusieurs providers cloud sans multiplier les risques de sécurité ?
Une architecture multi-cloud est techniquement viable sur le plan de la sécurité, à condition de ne pas fragmenter la gouvernance. Cela implique une politique IAM centralisée ou fédérée entre providers, une solution de gestion des clés indépendante des providers, et des outils de surveillance capables d’agréger les alertes des différentes plateformes en un tableau de bord unique.
Ce qu’il faut garder à l’esprit :
- Ce contenu est informatif et ne remplace pas un audit de sécurité personnalisé pour votre infrastructure.
- Les configurations et services de sécurité dépendent de votre contexte et de vos besoins spécifiques.
- Les normes et recommandations évoluent rapidement : vérifiez toujours les dernières directives des providers.
Pour toute décision engageant la sécurité de votre système d’information, consultez un expert certifié en sécurité cloud (CISSP, CCSK) ou un RSSI qualifié.