Checklist audit sécurité cloud 2026 : 7 domaines (IAM, chiffrement, réseau, logging), outils Prowler/ScoutSuite/Wiz, CIS Benchmarks AWS/Azure/GCP, CSPM.
TL;DR — En résumé
95 % des violations de sécurité cloud résultent d'erreurs de configuration client, non de failles chez les fournisseurs AWS, Azure ou GCP. Le modèle de responsabilité partagée impose au client la sécurisation de l'IAM, du chiffrement, du réseau et de la journalisation, sur sept domaines et 50 points de contrôle alignés CIS Cloud Benchmarks. Des outils open source comme Prowler, ScoutSuite ou Steampipe, complétés par des solutions CSPM commerciales (Wiz, Orca Security, Prisma Cloud), automatisent jusqu'à 80 % de ces vérifications en continu. Les rapports d'audit, classifiés Confidentiel, doivent être conservés trois ans minimum selon ISO 27001 et servent de preuves de diligence en cas d'incident ou de contrôle NIS 2/DORA.
L'audit securite cloud checklist 2026 constitue l'exercice le plus structurant pour les équipes qui exploitent des infrastructures AWS, Azure ou GCP. L'enseignement de la dernière décennie est sans appel : la très grande majorité des violations de sécurité cloud provient d'erreurs de configuration côté client, et non de failles dans l'infrastructure des fournisseurs. Buckets de stockage exposés, rôles IAM surprivilégiés, groupes de sécurité ouverts sur Internet, chiffrement désactivé ou journalisation incomplète : ces angles morts persistent parce que le modèle de responsabilité partagée reste mal compris. Face au durcissement réglementaire porté par NIS2, DORA et l'évolution des référentiels ISO 27001 et SecNumCloud, une démarche d'audit formalisée n'est plus optionnelle. Cette checklist vous fournit un cadre méthodique, du périmétrage initial à la remédiation priorisée, pour évaluer votre posture cloud et documenter votre conformité de façon défendable.
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.
À retenir
- Shared responsibility : le fournisseur cloud sécurise l'infrastructure, vous sécurisez la configuration, les données et les identités — 95 % des violations cloud résultent d'erreurs de configuration client.
- CIS Cloud Benchmarks : les benchmarks CIS pour AWS, Azure et GCP fournissent 100-200 contrôles prescriptifs par plateforme, base de référence idéale pour l'audit cloud.
- Outils open source : Prowler (AWS/Azure/GCP), ScoutSuite (multi-cloud), CloudSploit et Steampipe permettent d'automatiser 70-80 % des contrôles de la checklist.
- CSPM (Cloud Security Posture Management) : les solutions commerciales Wiz, Orca et Prisma Cloud offrent une détection continue des mauvaises configurations, des vulnérabilités et des risques cloud.
- IAM est le domaine prioritaire : 60 % des incidents cloud impliquent une gestion des identités défaillante (MFA absent, permissions excessives, clés longue durée).
Lors de nos missions d'accompagnement NIS 2, les écarts les plus fréquents ne sont pas techniques mais documentaires : des mesures en place depuis des années, mais non formalisées, non auditées, et donc indémontrables lors d'un contrôle.
— Retour terrain, Ayi NEDJIMI Consultants
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é
| Domaine | AWS | Azure | GCP |
|---|---|---|---|
| IAM | IAM, STS, Cognito | Entra ID, Azure RBAC | Cloud IAM, Workforce Identity |
| Détection des menaces | GuardDuty | Microsoft Defender for Cloud | Security Command Center |
| Journalisation | CloudTrail, CloudWatch | Activity Log, Monitor | Cloud Audit Logs, Cloud Monitoring |
| Gestion des secrets | Secrets Manager, SSM | Key Vault | Secret Manager |
| Config & compliance | AWS Config, Security Hub | Azure Policy, Compliance | Security Command Center |
| WAF | AWS WAF + Shield | Azure WAF + DDoS Protection | Cloud Armor |
| Scan vulnérabilités | Amazon Inspector | Microsoft Defender CSPM | Artifact Analysis |
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.
Auditez la sécurité de votre infrastructure cloud
Ayi NEDJIMI Consultants propose des audits de sécurité cloud complets : exécution de Prowler/ScoutSuite, évaluation de la conformité CIS Benchmarks, test d'intrusion cloud et recommandations de remédiation priorisées. Découvrez notre offre RSSI externalisé pour un pilotage continu de la sécurité cloud.
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.
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 :
- 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.
- 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).
- 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.
- Plan d'action priorisé : matrice risque/effort pour chaque finding critique, proposant un séquençage de remédiation sur 30/60/90 jours.
- 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.
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.
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.
Télécharger cet article en PDF
Format A4 optimisé pour l'impression et la lecture hors ligne
À propos de l'auteur
Ayi NEDJIMI
Auditeur Senior Cybersécurité & Consultant IA
Expert Judiciaire — Cour d'Appel de Paris
Habilitation Confidentiel Défense
ayi@ayinedjimi-consultants.fr
Ayi NEDJIMI est un vétéran de la cybersécurité avec plus de 25 ans d'expérience sur des missions critiques. Ancien développeur Microsoft à Redmond sur le module GINA (Windows NT4) et co-auteur de la version française du guide de sécurité Windows NT4 pour la NSA.
À la tête d'Ayi NEDJIMI Consultants, il réalise des audits Lead Auditor ISO 42001 et ISO 27001, des pentests d'infrastructures critiques, du forensics et des missions de conformité NIS2 / AI Act.
Conférencier international (Europe & US), il a formé plus de 10 000 professionnels.
Domaines d'expertise
Ressources & Outils de l'auteur
Testez vos connaissances
Mini-quiz de certification lié à cet article — propulsé par CertifExpress
Articles connexes
Mise en conformité NIS 2 et ISO 27001
Accompagnement sur mesure pour les PME et ETI soumises à NIS 2 ou engagées dans une démarche ISO 27001. Gap analysis, plan d'action, audit interne.
Commentaires
Aucun commentaire pour le moment. Soyez le premier à commenter !
Laisser un commentaire