Audit de Sécurité Cloud : Checklist Conformite 2026

L'audit sécurité cloud checklist conformité 2026 est l'un des exercices les plus complexes du portfolio des équipes de sécurité modernes. Contrairement aux audits d'infrastructure traditionnelle, le cloud public impose un modèle de responsabilité partagée (shared responsibility model) où la frontière entre les responsabilités du fournisseur cloud et celles du client n'est pas toujours intuitive. AWS, Azure et GCP sécurisent l'infrastructure sous-jacente (data centers, hyperviseurs, réseau backbone), mais la configuration des services cloud, la gestion des identités et des accès, le chiffrement des données et la surveillance restent de la responsabilité exclusive du client. En 2026, les principales causes de compromission cloud ne sont pas des failles dans l'infrastructure AWS ou Azure — elles résultent de mauvaises configurations client : buckets S3 publics, clés d'API exposées dans le code source, règles de sécurité réseau trop permissives, MFA non activé sur les comptes admin. Cette checklist en 7 domaines et 50 points de contrôle permet de structurer un audit cloud complet, que vous conduisiez l'évaluation manuellement ou à l'aide d'outils d'automatisation CSPM.

Le modèle de responsabilité partagée : qui fait quoi en sécurité cloud ?

Avant toute checklist d'audit, il est fondamental de comprendre le modèle de responsabilité partagée propre à chaque fournisseur cloud. Ce modèle définit les frontières de sécurité entre le fournisseur et le client selon le type de service (IaaS, PaaS, SaaS).

En mode IaaS (Infrastructure as a Service — ex : EC2, VMs Azure, GCE) : le fournisseur sécurise le data center physique, le réseau backbone et l'hyperviseur. Le client sécurise le système d'exploitation, les applications, les données, les groupes de sécurité réseau et la gestion des identités.

En mode PaaS (ex : RDS, Azure SQL, Cloud SQL) : le fournisseur étend sa responsabilité au middleware et au runtime. Le client reste responsable des données, de la gestion des accès aux services et de la configuration des paramètres de sécurité de la plateforme.

En mode SaaS (ex : Microsoft 365, Salesforce) : le fournisseur gère la sécurité de la quasi-totalité de la stack. Le client est responsable de la configuration du tenant (permissions, partage de données, accès externes) et de la gestion des comptes utilisateurs.

L'audit cloud doit systématiquement identifier le type de service pour chaque composant audité et adapter le périmètre de contrôle en conséquence.

Domaine 1 : IAM (Identity and Access Management)

L'IAM est le domaine le plus critique de l'audit cloud. 60 % des incidents de sécurité cloud impliquent une gestion des identités défaillante.

• MFA obligatoire sur tous les comptes root/admin cloud (AWS root account, Azure Global Admin)
• Pas de clés d'accès longue durée sur le compte root AWS
• Principe du moindre privilège : révision des IAM policies, identification des politiques trop permissives (wildcards, AdministratorAccess non justifié)
• Rotation des clés d'accès IAM (AWS Access Keys) tous les 90 jours maximum
• Désactivation des utilisateurs IAM inactifs depuis plus de 90 jours
• Utilisation des rôles IAM (AWS IAM Roles, Azure Managed Identities) plutôt que des clés statiques pour les applications
• Séparation des environnements (prod/dev/test) via des comptes cloud distincts ou des souscriptions séparées
• Revue des permissions des comptes de service et des applications tierces (OAuth grants)
• Absence de credentials hard-codés dans le code source (scan GitLeaks, Trufflehog)

Domaine 2 : Chiffrement des données

• Chiffrement au repos activé pour tous les services de stockage (S3 SSE-S3 ou SSE-KMS, Azure Encryption at Rest, GCP CMEK)
• Chiffrement en transit : HTTPS/TLS 1.2+ obligatoire, désactivation de TLS 1.0/1.1, HTTP redirigé vers HTTPS
• Gestion des clés : utilisation d'AWS KMS, Azure Key Vault ou GCP Cloud KMS pour les clés de chiffrement critiques
• Pas de clés de chiffrement stockées dans le code source ou les variables d'environnement en clair
• Rotation automatique des clés KMS configurée
• Chiffrement des volumes de stockage des instances (EBS encryption, Azure Disk Encryption)
• Chiffrement des sauvegardes RDS/Azure SQL/Cloud SQL

Domaine 3 : Sécurité réseau

• VPC/VNET configurés avec segmentation en sous-réseaux privés/publics
• Pas de règles de sécurité autorisant 0.0.0.0/0 sur les ports SSH (22), RDP (3389) ou base de données
• AWS Security Groups en mode "deny by default" — seuls les flux nécessaires sont autorisés
• Network ACLs (NACLs) configurés en complément des Security Groups
• VPN ou AWS PrivateLink pour accès aux services cloud depuis les réseaux on-premise
• WAF (Web Application Firewall) activé devant les applications web exposées
• AWS Shield Standard (DDoS) activé — Shield Advanced pour les applications critiques
• Pas d'instances EC2/VMs avec adresse IP publique directe sans Load Balancer ou bastion

Domaine 4 : Journalisation et détection

La journalisation est l'un des domaines les plus négligés dans les environnements cloud, alors qu'elle est essentielle pour détecter les incidents et répondre aux exigences réglementaires (NIS 2, ISO 27001 clause 8.15).

• AWS CloudTrail activé dans toutes les régions, y compris région globale (pour IAM, STS, CloudFront)
• CloudTrail logs chiffrés (KMS) et intégrité des logs validée
• Azure Activity Log activé et centralisé dans un Log Analytics Workspace
• Google Cloud Audit Logs : Admin Activity et Data Access logs activés
• Rétention des logs : minimum 90 jours accessible, 1 an en archivage froid (conformité NIS 2, ISO 27001)
• Alertes sur les actions à haut risque : création de comptes IAM admin, modification des Security Groups, désactivation du MFA, export de données massif
• SIEM cloud : Splunk, Microsoft Sentinel ou AWS Security Hub pour la corrélation des événements
• GuardDuty (AWS) ou Microsoft Defender for Cloud activé pour la détection des menaces basée sur ML

Domaine 5 : Gestion de la configuration et hardening

Les CIS Cloud Benchmarks fournissent les références de configuration sécurisée pour AWS, Azure et GCP. Ces benchmarks, téléchargeables sur cisecurity.org, définissent des centaines de contrôles prescriptifs avec les commandes de vérification et de remédiation.

• AWS Config activé pour la détection automatique des drifts de configuration
• Azure Policy pour l'application des configurations sécurisées obligatoires dans les souscriptions
• S3 Block Public Access activé au niveau account AWS (pas uniquement par bucket)
• IMDSv2 (Instance Metadata Service v2) imposé sur toutes les instances EC2 (protection contre SSRF)
• Tags de classification obligatoires sur tous les ressources (owner, environment, data-classification)
• AWS Trusted Advisor / Azure Advisor : revue des recommandations de sécurité en attente

Outils d'audit cloud : Prowler, ScoutSuite, Steampipe, Wiz

Les outils d'audit cloud automatisent la vérification de la majorité des contrôles de la checklist. En 2026, le marché se divise entre outils open source et solutions CSPM commerciales :

Prowler : outil open source Python développé par Toni de la Fuente (ex-Amazon), devenu la référence pour l'audit cloud multi-cloud. Prowler 3.x couvre AWS, Azure et GCP avec plus de 800 contrôles alignés sur CIS Benchmarks, NIST CSF, ISO 27001 et PCI DSS. Commande type : prowler aws --compliance cis_level2_aws. Disponible sur GitHub, gratuit, idéal pour les audits ponctuels ou l'intégration CI/CD.

ScoutSuite : outil open source Python de NCC Group, multi-cloud (AWS, Azure, GCP, Alibaba, Oracle Cloud). Génère un rapport HTML interactif avec une cartographie visuelle des risques par service. Adapté aux audits de sécurité conduits par des consultants.

Steampipe : framework open source permettant d'interroger les APIs cloud via des requêtes SQL. Avec ses plugins AWS, Azure et GCP, Steampipe permet des requêtes cross-cloud complexes : "liste toutes les instances avec un groupe de sécurité autorisant SSH depuis 0.0.0.0/0". Particulièrement puissant pour les audits sur mesure.

CSPM commerciaux — pour une détection continue :

• Wiz : leader du marché CSPM en 2026, basé sur un graphe de risques contextuel ("security graph"). Détecte les combinaisons de mauvaises configurations créant des chemins d'attaque réels. Très apprécié des CISO pour la priorisation des risques.
• Orca Security : analyse sans agent ("agentless") via les snapshots cloud. Couvre CSPM, CWPP (Cloud Workload Protection) et gestion des vulnérabilités en une plateforme.
• Prisma Cloud (Palo Alto) : solution enterprise complète couvrant CSPM, CWPP, CNAPP et conformité réglementaire. Adapté aux grandes organisations multi-cloud.

Spécificités AWS vs Azure vs GCP pour l'audit sécurité

Domaines 6 et 7 : Conformité réglementaire et supply chain

Domaine 6 — Conformité réglementaire :

• Vérification de la localisation des données (région cloud) vs exigences RGPD/HDS/SecNumCloud
• DPA (Data Processing Agreement) signé avec le fournisseur cloud
• Rapport SOC 2 Type II du fournisseur cloud collecté et revu annuellement
• Certifications cloud pertinentes vérifiées : ISO 27001, HDS, PCI DSS (selon les services utilisés)
• Politique de protection des données du fournisseur cloud compatible RGPD

Domaine 7 — Supply chain cloud :

• Inventaire des services cloud tiers utilisés (Marketplace, intégrations SaaS, extensions)
• Évaluation de sécurité des services Marketplace avant déploiement (revue des permissions IAM demandées)
• Gestion des clés SSH/API pour les intégrations tierces : principe du moindre privilège, rotation
• Images Docker/AMI : scan de vulnérabilités systématique, utilisation d'images de base officielles
• Infrastructure as Code (Terraform, CloudFormation) : scan de sécurité (Checkov, tfsec) avant déploiement

Les ressources CISA Cloud Security Guidance, disponibles sur cisa.gov, fournissent une architecture de référence pour la sécurisation des environnements cloud gouvernementaux et privés. Le NIST SP 800-144 sur les lignes directrices de sécurité cloud est également une référence incontournable sur csrc.nist.gov.

Questions fréquentes sur l'audit de sécurité cloud

Quelle est la fréquence recommandée pour un audit de sécurité cloud ?

La combinaison recommandée est : une analyse CSPM continue (Wiz, Orca, ou Defender for Cloud en mode continu), un audit Prowler/ScoutSuite trimestriel pour couvrir l'ensemble du périmètre, et un audit de sécurité approfondi par un prestataire externe annuellement (incluant un test d'intrusion cloud). Pour les environnements soumis à des réglementations strictes (NIS 2, DORA, PCI DSS), l'audit de sécurité externe doit être documenté et les résultats transmis à l'autorité de supervision selon les délais réglementaires. Notre livre blanc pentest cloud détaille la méthodologie d'audit offensif.

Prowler ou ScoutSuite : lequel choisir pour un audit cloud ?

Les deux outils sont complémentaires. Prowler v3+ est plus adapté si vous ciblez une conformité réglementaire précise (CIS Level 1/2, ISO 27001, PCI DSS, NIS 2) car il aligne ses contrôles sur ces référentiels avec un reporting par framework. ScoutSuite est préférable pour une vue cartographique rapide des risques d'un compte cloud inconnu, grâce à son rapport HTML interactif très lisible. Pour un audit complet, l'idéal est d'exécuter les deux et de croiser les résultats.

Comment prioriser les résultats d'un audit CSPM avec des centaines d'alertes ?

La principale difficulté des CSPM comme Wiz ou Orca est la génération de centaines à milliers d'alertes lors d'un premier scan. La priorisation recommandée : 1) Commencer par les findings "Critical" de la plateforme CSPM — ils représentent des risques de compromission immédiate. 2) Se concentrer sur les chemins d'attaque identifiés par Wiz (combinaisons de misconfigurations menant à une compromission). 3) Corriger en priorité les expositions réseau (ports 22/3389/3306 ouverts sur l'internet) et les accès IAM excessifs sur les comptes admin. 4) Planifier les corrections "High" sur 30 jours, "Medium" sur 90 jours. 5) Ne pas chercher à corriger 100 % des "Low" — prioriser le risque business réel.

Les outils CSPM remplacent-ils un pentest cloud ?

Non. Les CSPM et outils d'audit automatisés détectent les mauvaises configurations connues et les vulnérabilités cataloguées. Un pentest cloud offensif va au-delà : il simule un attaquant réel qui combine des failles, exploite des configurations légitimes (SSRF, metadata service, confused deputy), pivote entre services et tente d'exfiltrer des données. Les deux approches sont complémentaires : le CSPM pour la détection continue, le pentest pour valider la robustesse réelle de la défense. Notre guide des outils d'audit et les recommandations ANSSI sur la sécurité des environnements cloud complètent cette checklist.

Intégrer la sécurité cloud dans le pipeline CI/CD

En 2026, la sécurité cloud ne peut plus être une activité d'audit ponctuelle — elle doit être intégrée dans le cycle de vie du développement logiciel via le pipeline CI/CD. Le concept de shift-left security appliqué au cloud implique de détecter les mauvaises configurations infrastructure avant qu'elles n'arrivent en production.

Les outils de scan IaC (Infrastructure as Code) à intégrer dans le pipeline :

• Checkov : scanner open source de Bridgecrew (Palo Alto) analysant les fichiers Terraform, CloudFormation, Kubernetes et Helm. Détecte les mauvaises configurations de sécurité avant déploiement. Intégrable dans GitHub Actions, GitLab CI, Jenkins.
• tfsec : scanner Terraform spécifique, plus léger que Checkov, idéal pour les projets pure Terraform. Maintenu par Aqua Security.
• KICS (Keeping Infrastructure as Code Secure) : outil Checkmarx multi-technologies (Terraform, CloudFormation, Docker, K8s) avec plus de 2400 règles.
• Trivy : scanner multi-usage d'Aqua Security couvrant les images Docker (vulnérabilités CVE), les fichiers IaC et les packages open source. Recommandé pour unifier les scans dans un seul outil.

Une politique de sécurité cloud minimale dans le pipeline CI/CD devrait inclure : scan Checkov sur les PRs Terraform (échec si findings Critical/High), scan Trivy sur chaque build Docker (pas de déploiement si CVE CVSS > 9.0 non patchée), analyse des secrets (Gitleaks) sur chaque commit, et revue manuelle des exceptions par le RSSI avant merge.

Notre guide d'automatisation des audits de sécurité et notre livre blanc pentest cloud complètent cette approche shift-left avec des exemples concrets d'intégration sécurité dans les pipelines DevOps.

Audit cloud multi-comptes et multi-régions : défis et solutions

Les environnements cloud d'entreprise en 2026 sont rarement mono-compte. Une organisation moyenne dispose de 10 à 50 comptes AWS (ou souscriptions Azure, projets GCP) : un par environnement (dev, staging, prod), par business unit, par application critique. L'audit de sécurité dans cet environnement multi-comptes présente des défis spécifiques :

• Visibilité centralisée : AWS Organizations + AWS Security Hub (agrégateur) ou Azure Management Groups + Microsoft Defender for Cloud permettent de consolider les findings de sécurité de tous les comptes enfants dans un compte central.
• Standardisation des politiques : AWS Service Control Policies (SCPs) ou Azure Policy à l'échelle du Management Group permettent d'imposer des garde-fous de sécurité sur l'ensemble des comptes (ex : blocage de la création de ressources hors région EU, obligation de chiffrement sur tous les volumes S3/EBS).
• Audit Prowler multi-comptes : Prowler supporte le scan multi-comptes via AWS Organizations — une seule exécution scanne l'ensemble des comptes membres. Résultats agrégés dans un rapport HTML ou envoyés dans un S3 central pour analyse.
• Gouvernance des landing zones : AWS Control Tower ou Azure Landing Zone fournissent des architectures multi-comptes pré-configurées avec des guardrails de sécurité intégrés, facilitant la conformité CIS Benchmarks dès le départ.

Conclusion : l'audit de sécurité cloud en 2026, un exercice continu

L'audit de sécurité cloud n'est plus un événement annuel mais un processus continu en 2026. La combinaison d'outils open source (Prowler, ScoutSuite, Checkov dans le CI/CD) pour l'audit ponctuel et de CSPM commerciaux (Wiz, Orca, Defender for Cloud) pour la détection continue constitue le standard de facto pour les équipes de sécurité cloud matures.

La checklist en 7 domaines présentée dans cet article (IAM, chiffrement, réseau, logging, configuration, conformité réglementaire, supply chain) couvre les contrôles essentiels. Son exécution trimestrielle par Prowler, combinée à une détection continue CSPM et à l'intégration de Checkov dans le pipeline CI/CD, construit une posture de sécurité cloud robuste et documentée pour les audits réglementaires (NIS 2, ISO 27001, HDS). Les recommandations CIS pour AWS, Azure et GCP sont téléchargeables sur cisecurity.org. Pour un accompagnement de votre programme de sécurité cloud, consultez notre RSSI externalisé et notre offre de certification ISO 27001 qui intègre les contrôles cloud de l'Annexe A 2022.

Structurer un rapport d'audit cloud professionnel

La qualité du rapport d'audit cloud est aussi importante que la qualité de l'audit lui-même. Un rapport bien structuré permet à la direction de comprendre les risques, aux équipes techniques d'implémenter les corrections, et aux auditeurs réglementaires de vérifier la conformité. Structure recommandée :

1. Résumé exécutif (1-2 pages) : synthèse des résultats pour la direction. Score de sécurité global, top 5 des risques critiques, statut de conformité CIS Benchmark, budget estimé pour remédiation.
2. Périmètre d'audit : comptes cloud audités, régions, services couverts, date et durée de l'audit, outils utilisés (Prowler version X, ScoutSuite, Wiz).
3. Résultats par domaine : pour chacun des 7 domaines (IAM, chiffrement, réseau, logging, config, conformité, supply chain), tableau des findings avec sévérité (Critical/High/Medium/Low), description, impact business, recommandation et effort de remédiation.
4. Plan d'action priorisé : matrice risque/effort pour chaque finding critique, proposant un séquençage de remédiation sur 30/60/90 jours.
5. Annexes techniques : output brut Prowler/ScoutSuite, configurations problématiques avec captures, commandes de remédiation pour les équipes cloud.

Les rapports d'audit cloud sont des documents sensibles qui doivent être classifiés Confidentiel et distribués sur la base du besoin d'en connaître. Leur conservation doit respecter les obligations de rétention des documents RSSI (ISO 27001 clause 7.5 exige 3 ans minimum pour les enregistrements SMSI). Ils constituent des preuves de due diligence importantes en cas d'incident ou d'audit réglementaire NIS 2 ou DORA.

Pour des audits cloud avancés incluant des tests d'intrusion en conditions réelles, consultez notre livre blanc pentest cloud et notre guide des outils d'audit. Les ressources de sécurité CISA pour les environnements cloud gouvernementaux et privés sont disponibles sur cisa.gov.