Qu'est-ce que le Cloud Security en 2026 ? Définition

Le cloud security (sécurité du cloud) est la discipline qui protège les données, applications, identités et infrastructures hébergées dans un environnement cloud (AWS, Azure, GCP, OCI, Alibaba Cloud, OVH Cloud, Scaleway), en s'appuyant sur un modèle de responsabilité partagée entre le fournisseur cloud et le client. Cette discipline ajoute des classes de risques spécifiques aux risques cybersécurité classiques (misconfigurations IAM, buckets de stockage publics, RBAC Kubernetes laxistes, secrets dans Terraform state, dérive de posture continue) tout en bénéficiant de services natifs absents de l'on-premise (AWS GuardDuty, Azure Defender for Cloud, Google Security Command Center). En 2026, la maturité cloud security se mesure sur cinq piliers : IAM (gestion des identités), sécurité réseau (VPC, segmentation), sécurité des données (chiffrement, classification), posture management (CSPM, audit continu), runtime security (CWPP, détection comportementale). Cet article détaille la définition rigoureuse, le modèle de responsabilité partagée par type de service (IaaS, PaaS, SaaS), les cinq piliers techniques, l'écosystème d'outils 2026 (CSPM, CWPP, CNAPP, CIEM, KSPM, DSPM), les référentiels structurants (CSA CCM v4, NIST CSF 2.0, CIS Benchmarks, ISO 27017, ENISA), les spécificités multi-cloud et les incidents historiques majeurs.

Définition et périmètre

Le cloud security couvre quatre dimensions distinctes mais interconnectées.

Sécurité de l'infrastructure cloud : protection des composants infrastructure (VMs, containers, serverless functions, services managés) contre les vulnérabilités, les misconfigurations, les compromissions runtime. Inclut le hardening des OS guest, le patch management, la gestion de la posture, la détection runtime.

Sécurité des identités et accès : authentification, autorisation, fédération entre identités sur plusieurs comptes/tenants/projets, gestion fine des permissions (least privilege), détection des accès anormaux, gestion des secrets et credentials.

Sécurité des données : chiffrement at rest et in transit, gestion des clés (KMS, HSM, BYOK), classification, protection contre l'exfiltration (DLP), conformité géographique (data residency), audit des accès.

Sécurité applicative cloud-native : sécurité des applications déployées dans le cloud, incluant la chaîne de livraison (CI/CD), les containers, le serverless, les APIs, les architectures microservices.

Le modèle de responsabilité partagée

Pierre angulaire du cloud security. Définit ce que sécurise le fournisseur (responsabilité of the cloud) et ce que sécurise le client (responsabilité in the cloud). La répartition exacte varie selon le service consommé.

La règle invariante : peu importe le modèle de service, les identités, les configurations sécurité et les données restent toujours la responsabilité du client. La majorité des incidents cloud documentés viennent d'une mauvaise compréhension de cette frontière.

Variations par fournisseur

AWS, Azure, GCP publient leurs propres versions du modèle de responsabilité partagée, avec des nuances mais le principe reste identique. AWS distingue Security of the Cloud (AWS) et Security in the Cloud (client). Azure utilise les mêmes catégories avec des termes proches. GCP parle de « shared fate » (en complément du shared responsibility) pour souligner les outils que GCP fournit pour aider le client.

Exemple Capital One 2019 (rappel pédagogique)
---------------------------------------------
- Modèle : EC2 = IaaS
- AWS responsable : hyperviseur, datacenter (sécurisés)
- Capital One responsable : config IAM, WAF, application
 
Vulnérabilité exploitée :
1. SSRF dans une application Capital One sur EC2.
2. Application requête EC2 metadata service (IMDSv1) sans contrôle.
3. Récupération du rôle IAM attaché à l'instance EC2.
4. Le rôle IAM avait des permissions excessives (S3 list + read).
5. Exfiltration de 100M de comptes depuis S3 buckets.
 
Aucune CVE AWS exploitée. 100 % responsabilité Capital One :
SSRF côté code applicatif, IMDSv1 non désactivé, IAM trop large.
Amende 80 M$ + class actions.

Les 5 piliers du cloud security

Pilier 1 — IAM (Identity and Access Management)

Le pilier le plus critique. La majorité des incidents cloud impliquent une mauvaise gestion des identités ou des permissions.

Composants principaux :

• Identités humaines : utilisateurs, fédération SSO via SAML ou OIDC depuis l'IdP entreprise (Okta, Entra ID, Google Workspace, Keycloak), MFA obligatoire.
• Identités machines : rôles IAM (AWS), Managed Identity (Azure), Service Account (GCP), workload identity federation.
• Permissions : policies IAM, RBAC, ABAC, principe du least privilege, séparation des duties.
• Audit : CloudTrail (AWS), Activity Logs (Azure), Cloud Audit Logs (GCP).

Bonnes pratiques 2026 :

• Aucune identité humaine avec credentials long-lived. Fédération SSO + MFA obligatoire.
• Aucun secret long-lived dans la CI/CD. OIDC federation systématique.
• Rotation automatique des credentials résiduels (90 jours maximum).
• Permission boundaries pour limiter le scope possible des rôles.
• Détection automatique des permissions excessives via CIEM (AWS Access Analyzer, Wiz CIEM, Sonrai).

Pilier 2 — Sécurité réseau

Architecture réseau sécurisée par défaut, segmentation, contrôle des flux.

Composants :

• VPC isolé par environnement (prod, staging, dev).
• Security Groups et NACLs stateful/stateless, deny by default.
• Private endpoints (VPC Endpoints AWS, Private Link Azure, Private Service Connect GCP) pour éviter le trafic via Internet.
• WAF (AWS WAF, Azure Front Door WAF, GCP Cloud Armor) en frontage des applications publiques.
• DDoS protection native (Shield Standard AWS, Azure DDoS Protection, GCP Cloud Armor).
• Segmentation Kubernetes via NetworkPolicy, service mesh (Istio, Linkerd, Cilium).

Anti-pattern courant : Security Group avec ingress 0.0.0.0/0 sur port 22 ou 3389. Détecté immédiatement par tout CSPM mais reste fréquent en démarrage de projet.

Pilier 3 — Sécurité des données

Protection en confidentialité, intégrité, disponibilité des données.

Composants :

• Chiffrement at rest : par défaut activé sur la majorité des services managés (S3 SSE, EBS, RDS, Azure Storage, GCS), gestion des clés via KMS managé ou customer-managed keys (CMK).
• Chiffrement in transit : TLS 1.2+ obligatoire, désactivation des cipher suites faibles, certificats gérés (ACM, Azure Key Vault Certificates, Google-managed SSL).
• Classification : tagging des données par niveau de sensibilité (public, internal, confidential, restricted), application automatique de policies selon la classe.
• DLP (Data Loss Prevention) : détection automatique de données sensibles (PII, secrets, propriété intellectuelle) via Macie (AWS), Microsoft Purview, GCP DLP.
• Backup et résilience : snapshots automatisés, recovery time objective (RTO) et recovery point objective (RPO) testés.
• Data residency : contrôle géographique du stockage (UE pour RGPD, Suisse pour LPD, etc.).

Pilier 4 — Posture management (CSPM)

Audit continu des configurations cloud contre des benchmarks et règles personnalisées.

Outils dominants 2026 :

• Cloud-native : AWS Security Hub + Config + Inspector, Azure Defender for Cloud, Google Security Command Center.
• Open source : Prowler (AWS, Azure, GCP), ScoutSuite (multi-cloud), Cloud Custodian (multi-cloud, policy enforcement), Steampipe (SQL queries on cloud config).
• Commercial CNAPP : Wiz, Orca Security, Prisma Cloud (Palo Alto), Lacework, Sysdig, CrowdStrike Falcon Cloud Security, Tenable Cloud Security.

Cadres de conformité standard : CIS AWS Foundations Benchmark v3.0, CIS Azure Foundations Benchmark v3.0, CIS GCP Foundations, CIS Kubernetes Benchmark v1.9, NIST CSF 2.0, ISO 27017, PCI-DSS, HIPAA, SOC 2.

# Exemple : audit AWS rapide avec Prowler open source
docker run -ti --rm \
  --name prowler \
  --volume "$HOME/.aws:/home/prowler/.aws:ro" \
  --volume "$(pwd)/output:/home/prowler/output" \
  toniblyx/prowler:latest \
  -M html json-asff -F report-$(date +%Y%m%d)
 
# Audit ciblé sur un service spécifique
prowler aws --services s3 iam ec2 --severity high critical
 
# Audit multi-cloud (AWS + Azure + GCP)
prowler aws && prowler azure && prowler gcp

Pilier 5 — Runtime security (CWPP)

Détection en temps réel des comportements anormaux des workloads, équivalent EDR adapté au cloud.

Capabilités CWPP modernes :

• Threat detection runtime sur containers et VMs (Falco, Tetragon, Aqua Runtime, Sysdig Secure).
• Behavioral analysis : détection de processus inattendus, connexions sortantes anormales, fichiers modifiés.
• File integrity monitoring (FIM).
• Vulnerability runtime : détection de CVE exploitables au runtime (pas seulement en image scan).
• Container drift detection : alerte si un container diffère de son image source.
• Network observation : détection de lateral movement, beaconing C2.

# Exemple Falco rule custom : détection d'accès au cloud metadata depuis container
- rule: Cloud Metadata Service Access
  desc: Détection d'accès au IMDS AWS, Azure ou GCP depuis un container
  condition: >
    container and
    (fd.sip = "169.254.169.254" or
     fd.sip = "fd00:ec2::254" or
     fd.sip = "100.100.100.200")
  output: >
    Cloud metadata access from container
    (user=%user.name container=%container.name image=%container.image.repository
    target_ip=%fd.sip)
  priority: WARNING
  tags: [cloud, mitre_credential_access]

L'écosystème CNAPP : convergence des outils

Le terme CNAPP (Cloud Native Application Protection Platform), introduit par Gartner en 2021, désigne la convergence des familles d'outils cloud security en une plateforme unifiée. La plupart des leaders 2026 (Wiz, Orca, Prisma Cloud, Lacework) couvrent simultanément CSPM + CWPP + CIEM + KSPM + DSPM + parfois ASPM.

Choix pragmatique 2026 : pour une organisation de moins de 500 développeurs, démarrer avec les outils cloud-natifs (Security Hub AWS, Defender Azure, SCC GCP) + Prowler open source pour le multi-cloud. Pour une organisation plus grande ou multi-cloud, basculer vers une CNAPP commerciale (Wiz, Orca) qui consolide les vues et alertes.

Référentiels structurants

Six référentiels orientent la pratique cloud security en 2026.

CSA Cloud Controls Matrix (CCM) v4

Publiée par Cloud Security Alliance, dernière version v4. 197 contrôles répartis en 17 domaines. Mapping vers ISO 27001, NIST 800-53, COBIT, PCI-DSS. Inclut le CAIQ (Consensus Assessments Initiative Questionnaire) pour évaluer un fournisseur cloud.

NIST CSF 2.0 (publié février 2024)

Cybersecurity Framework, structure 6 fonctions : Govern (nouveau v2.0), Identify, Protect, Detect, Respond, Recover. Applicable à tout périmètre cloud avec mapping vers SP 800-53.

NIST SP 800-53 Rev 5

Catalogue de 1 000+ contrôles techniques détaillés. Référence US obligatoire pour FedRAMP. Largement utilisé en privé pour structurer les contrôles internes.

CIS Benchmarks

Checklists techniques opérationnelles publiées par Center for Internet Security :

• CIS AWS Foundations Benchmark v3.0 (publié juillet 2023, mis à jour 2024).
• CIS Azure Foundations Benchmark v3.0 (publié septembre 2023).
• CIS GCP Foundations Benchmark.
• CIS Kubernetes Benchmark v1.9 (publié 2024).
• CIS Docker Benchmark v1.7.
• CIS Microsoft 365 Foundations.

Ces benchmarks sont implémentés dans la plupart des CSPM (Prowler, Wiz, etc.) en règles automatisées.

ISO/IEC 27017 et 27018

ISO/IEC 27017 (2015) : contrôles spécifiques au cloud, complément à ISO 27001. ISO/IEC 27018 (2019) : protection des PII (informations personnelles identifiables) en cloud public.

ENISA Cloud Security Guide

European Union Agency for Cybersecurity. Guide cloud security adapté au contexte européen, prend en compte NIS2, DORA, GDPR.

Spécificités multi-cloud

Une organisation multi-cloud (AWS + Azure + GCP, par exemple) ajoute trois complexités.

Hétérogénéité des modèles : chaque fournisseur a ses propres concepts IAM, networking, services managés. Un IAM Role AWS, une Managed Identity Azure et un Service Account GCP sont des cousins mais pas équivalents. Les équipes doivent maintenir une expertise parallèle.

Centralisation des outils : impossible de scaler sans un CNAPP multi-cloud (Wiz, Orca, Prisma Cloud) ou des outils open source unifiés (Prowler, Steampipe, Cloud Custodian) qui agrègent la posture des trois plateformes.

Identity federation cross-cloud : pattern type fédération depuis l'IdP entreprise (Okta, Entra ID) vers AWS, Azure et GCP simultanément. Workload identity federation pour les workloads multi-cloud (Lambda qui appelle GCP, Cloud Run qui lit S3).

Incidents cloud marquants

Quatre incidents qui structurent la compréhension des risques cloud en 2026.

Capital One — mai 2019

CVSS 9.8, 100 millions de comptes exposés. Détaillé en exemple plus haut. Cause racine : SSRF + IAM permissions excessives + IMDSv1. Amende 80 M$. A déclenché une vague de migrations vers IMDSv2 chez tous les utilisateurs AWS sérieux.

Microsoft Storm-0558 — juillet 2023

Compromission d'une clé de signature Azure AD permettant la création de tokens d'authentification valides. Accès aux mailboxes Outlook de 25 organisations dont US State Department, US Department of Commerce. Attribué à un acteur étatique chinois. Microsoft a publié un post-mortem détaillé en septembre 2023, déclenchant des évolutions importantes du Secure Future Initiative Microsoft.

Snowflake supply chain — mai 2024

Pas une compromission de Snowflake mais des comptes clients sans MFA, dont les credentials avaient été volés via infostealers (RedLine, Vidar). 165+ tenants Snowflake compromis, exfiltration massive : Ticketmaster (560 M de records), AT&T (109 M), Santander, Pure Storage. Snowflake a forcé la mise en place de MFA obligatoire en juillet 2024. Leçon : la sécurité d'un SaaS dépend autant de l'hygiène des comptes clients que de la sécurité du fournisseur.

MOVEit Transfer — mai 2023

CVE-2023-34362, SQLi exploitée par le groupe Clop. 2 600+ organisations touchées, 90 millions de personnes impactées. Détaillé dans l'article injection SQL. Pertinent ici : nombreuses organisations victimes utilisaient MOVEit en SaaS hébergé chez Progress Software, démontrant que SaaS managé n'élimine pas la responsabilité de surveiller les CVE des produits achetés.

Pièges fréquents observés en France

Cinq écueils récurrents en programmes cloud security 2022-2025.

Configuration laxiste par défaut héritée : un compte AWS ouvert il y a 5 ans avec root user MFA absent, IAM Access Analyzer désactivé, CloudTrail logs partiels. La dette s'accumule silencieusement.

Multi-cloud sans gouvernance : équipes différentes sur AWS et Azure avec posture security divergente. Aucune vue consolidée. Vulnérabilité critique sur Azure pendant que l'attention est sur AWS.

Services nouveaux non couverts par CSPM : un service AWS lancé après l'achat du CSPM n'est pas audité. Délai 6 à 18 mois avant que les CSPM commerciaux couvrent les nouveaux services. Auditer manuellement les services récents.

IAM excessif persistant : la majorité des organisations donnent *:* à de nombreux rôles « pour démarrer » et oublient de réduire. Pas de revue périodique. CIEM peu déployé.

Confiance excessive dans les SaaS : achat d'un SaaS sans évaluer la posture sécurité du fournisseur (CSA STAR registry, SOC 2 report, pen test report). Le shared responsibility ignoré.

Points clés à retenir

• Le cloud security est une discipline qui combine sécurité d'infrastructure cloud, gestion des identités, protection des données et sécurité des applications cloud-natives, encadrée par un modèle de responsabilité partagée entre fournisseur et client.
• Le modèle de responsabilité partagée varie par type de service (IaaS, PaaS, SaaS) mais une règle reste invariante : identités, configurations sécurité et données sont toujours la responsabilité du client.
• Cinq piliers techniques structurent la pratique : IAM, sécurité réseau, sécurité des données, posture management (CSPM), runtime security (CWPP). Les CNAPP convergent ces familles depuis 2021.
• Six référentiels orientent la pratique en 2026 : CSA CCM v4, NIST CSF 2.0, NIST SP 800-53 Rev 5, CIS Benchmarks (AWS, Azure, GCP, K8s), ISO 27017/27018, ENISA. Combinaison pragmatique pour démarrer : CIS + NIST CSF + CSA CAIQ.
• Les incidents Capital One, Microsoft Storm-0558, Snowflake et MOVEit illustrent que les risques cloud sont concrets, chiffrés en centaines de millions, et toujours attribuables à une mauvaise compréhension du shared responsibility ou à des hygiènes de base manquantes.

Pour aller plus loin

• Roadmap Cloud Security - parcours d'apprentissage 12 à 18 mois pour devenir Cloud Security Engineer.
• Qu'est-ce que le DevSecOps - approche complémentaire intégrant la sécurité au cycle de développement.
• Sécurité des images de conteneurs - sécurité des workloads cloud-natifs containerisés.
• CI/CD sécurisée : définition - sécurité de la chaîne de livraison vers le cloud.