Check-list d'audit de sécurité cloud pour AWS, Azure et Google Cloud
La plupart des compromissions cloud ne commencent pas par une attaque sophistiquée. Elles commencent par une clé d'accès divulguée, un compte administrateur sans MFA, un bucket de stockage laissé public ou un port de base de données ouvert sur internet. Ce sont des problèmes de configuration, et une configuration s'audite. Cette check-list s'adresse aux décideurs et responsables techniques qui veulent savoir ce qu'un audit de sécurité cloud doit examiner, quels outils font le gros du travail, et à quoi ressemble un bon résultat.
Pourquoi un audit cloud dédié
Un audit d'infrastructure classique passe à côté de l'essentiel de la surface d'attaque cloud, car dans le cloud le plan de contrôle est le périmètre : qui détient les bons identifiants d'API peut créer, lire ou supprimer n'importe quoi, de n'importe où. Selon le modèle de responsabilité partagée publié par chaque fournisseur, celui-ci sécurise l'infrastructure, et vous sécurisez vos identités, configurations, données et charges de travail. Personne n'audite cette partie à votre place.
Les environnements cloud dérivent aussi très vite. Les équipes créent comptes et projets, les environnements de test survivent à leur projet, les permissions s'accumulent. Un audit donne un état à un instant donné ; le véritable objectif est de laisser en place l'outillage qui continuera à le mesurer.
Périmètre : commencer au niveau de l'organisation
Auditez au niveau où se posent les contrôles, pas compte par compte :
| Fournisseur | Structure de tête | Mécanisme de garde-fous |
|---|---|---|
| AWS | AWS Organizations, unités organisationnelles, comptes | Service control policies, IAM Identity Center |
| Azure | Tenant Microsoft Entra, groupes d'administration, abonnements | Azure Policy, contrôle d'accès basé sur les rôles |
| Google Cloud | Organisation, dossiers, projets | Organization Policy Service, IAM |
Le premier constat de nombreux audits est simplement que personne ne possède la liste complète des comptes, abonnements ou projets. Construire cet inventaire est la première étape.
Extrait de la fiche « Cloud Reference Architectures » · Demander la fiche complète
La check-list
1. Identités et accès
L'identité est le nouveau périmètre, et le domaine où l'effort rapporte le plus. Notre guide de la gestion des identités et des accès va plus loin.
| Vérification | À quoi ressemble le bon état |
|---|---|
| Comptes root / administrateur global | MFA (de préférence résistante au hameçonnage), pas de clés d'accès, usage réservé au bris de glace, alerte à chaque utilisation |
| Accès humains | Authentification unique depuis le fournisseur d'identité de l'entreprise, MFA imposée, pas d'utilisateurs IAM personnels durables |
| Accès machines | Identités de charge de travail, rôles ou jetons fédérés (par exemple OIDC depuis la CI/CD) plutôt que des clés statiques |
| Clés de longue durée | Inventoriées, renouvelées, supprimées si inutilisées ; aucune dans les dépôts de code |
| Moindre privilège | Pas de politiques d'administration génériques sur les rôles applicatifs ; permissions inutilisées revues |
| Accès externes | Relations de confiance inter-comptes et partages externes listés et justifiés (AWS IAM Access Analyzer y aide) |
| Revues d'accès | Périodiques, tracées, avec retrait des partants |
2. Journalisation et détection
| Vérification | À quoi ressemble le bon état |
|---|---|
| Journaux d'audit du plan de contrôle | AWS CloudTrail en trail d'organisation sur toutes les régions ; Activity Log Azure et journaux de connexion Entra exportés ; journaux Admin Activity de Google Cloud conservés (journaux Data Access activés là où vivent des données sensibles, car ils sont en grande partie désactivés par défaut) |
| Protection des journaux | Envoyés vers un compte ou projet séparé et verrouillé ; immuabilité ou suppression restreinte |
| Rétention | Définie selon les besoins légaux et d'investigation |
| Détection des menaces | Amazon GuardDuty, Microsoft Defender for Cloud ou Security Command Center activés sur toute l'organisation |
| Alertes | Sur l'usage du compte root, la désactivation de la MFA, les changements de politiques, l'arrêt de la journalisation, routées vers une astreinte |
3. Exposition réseau
| Vérification | À quoi ressemble le bon état |
|---|---|
| Règles entrantes | Aucun port SSH, RDP ou base de données ouvert à 0.0.0.0/0 |
| Administration | Via un bastion, un gestionnaire de sessions ou un proxy à identité, pas par IP publique |
| Points d'accès publics | Inventaire des load balancers, IP publiques, API gateways et URL serverless, chacun avec un responsable |
| Services managés | Bases, caches et moteurs de recherche sur points d'accès privés |
| Trafic sortant | Contrôlé pour les charges sensibles |
| Kubernetes | Serveur d'API non exposé publiquement sans restriction ; voir notre check-list de durcissement Kubernetes |
4. Protection des données et chiffrement
| Vérification | À quoi ressemble le bon état |
|---|---|
| Stockage public | Blocages d'accès public activés au niveau du compte (AWS S3 Block Public Access, paramètres des comptes de stockage Azure, public access prevention sur Google Cloud) |
| Chiffrement au repos | Activé partout par défaut ; clés gérées par le client là où la politique ou la réglementation l'exige |
| Gestion des clés | Politiques de clés restreintes, rotation activée, suppression protégée |
| Chiffrement en transit | TLS imposé sur le stockage et les bases |
| Secrets | Dans un gestionnaire de secrets, pas dans des fichiers d'environnement ou des images ; voir la gestion des secrets |
| Sauvegardes | Copies inter-comptes ou immuables, restaurations testées |
| Localisation des données | Régions restreintes par politique quand la résidence compte (voir le cloud souverain en Europe) |
5. Hygiène des charges de travail
| Vérification | À quoi ressemble le bon état |
|---|---|
| Métadonnées d'instance | IMDSv2 imposé sur AWS, pour bloquer le vol d'identifiants par falsification de requête côté serveur (SSRF) |
| Images | Analysées pour les vulnérabilités en CI et dans le registre |
| Correctifs | Délai défini pour l'OS et les images de base des conteneurs |
| Comptes de service par défaut | Non utilisés avec des permissions larges (problème fréquent sur Google Cloud et Kubernetes) |
6. Infrastructure as code et livraison
| Vérification | À quoi ressemble le bon état |
|---|---|
| Modifications | Faites par infrastructure as code et pull requests revues, pas dans la console |
| Contrôles de politique | IaC analysée avant application (Checkov, Trivy ou équivalent) |
| Identifiants des pipelines | Courte durée de vie, limités par environnement ; voir la sécurité de la chaîne CI/CD |
| Dérive | Détectée et signalée |
Outils de posture : laisser les machines compter
Personne ne devrait vérifier des centaines de paramètres à la main. Deux familles d'outils existent :
| Outil | Type | Couverture | Remarques |
|---|---|---|---|
| Prowler | CLI open source | AWS, Azure, Google Cloud, Kubernetes, Microsoft 365 et d'autres | Rattache les contrôles aux CIS Benchmarks et à des référentiels comme l'ISO 27001 ; fonctionne en lecture seule |
| ScoutSuite | CLI open source | AWS, Azure, Google Cloud et d'autres | Produit un rapport HTML hors ligne |
| AWS Security Hub | Natif | AWS | Agrège les constats, applique les standards CIS et AWS Foundational Security Best Practices |
| Microsoft Defender for Cloud | Natif | Azure (et connecteurs vers d'autres clouds) | Secure score fondé sur le Microsoft cloud security benchmark |
| Security Command Center | Natif | Google Cloud | Constats de mauvaise configuration et de menaces |
Les CIS Foundations Benchmarks, publiés gratuitement par le Center for Internet Security pour chaque grand fournisseur, sont la référence commune de la plupart de ces outils. Un bon audit utilise l'outil pour la couverture et l'humain pour le contexte : l'outil signale qu'un bucket est public, l'auditeur vérifie s'il doit l'être.
| Requirement | AWS | Azure | Google Cloud |
|---|---|---|---|
| Org-wide guardrails (deny risky actions for every account) | Service control policies (Organizations) | Azure Policy, management groups | Organization Policy constraints |
| Block public storage | S3 Block Public Access (account level) | allowBlobPublicAccess = false | Public access prevention (enforced) |
| Admin audit trail | CloudTrail, org trail, all regions | Activity Log + Entra audit logs to Log Analytics | Cloud Audit Logs (Admin Activity always on) |
| Posture management | Security Hub CSPM | Defender for Cloud (secure score) | Security Command Center |
| Threat detection | GuardDuty | Defender for Cloud plans, Sentinel | SCC Event Threat Detection |
| External access analysis | IAM Access Analyzer | Entra permissions reviews, Defender CIEM | Policy Analyzer, IAM Recommender |
| Metadata endpoint hardening (SSRF defence) | IMDSv2 required, hop limit 1 | IMDS needs Metadata: true header | needs Metadata-Flavor: Google header |
| Keyless workload identity | IAM roles, IRSA / EKS Pod Identity | Managed identities, workload identity federation | Service account impersonation, Workload Identity Federation |
Extrait de la fiche « Cloud Configuration Review » · Demander la fiche complète
Les constats les plus fréquents
Dans les rapports d'incidents publics et les recommandations des fournisseurs, les mêmes erreurs reviennent :
- Comptes administrateur ou root sans MFA
- Clés d'accès de longue durée, parfois commitées dans le code
- Rôles trop larges attachés aux applications et à la CI/CD
- Buckets ou snapshots publics
- Ports d'administration ou de base de données ouverts sur internet
- Journalisation d'audit incomplète, ou stockée là où un attaquant pourrait l'effacer
- Services de détection non activés sur tous les comptes et toutes les régions
- Ressources oubliées : anciens environnements de test, IP publiques non attachées, enregistrements DNS orphelins pointant vers des ressources libérées
Ce que l'audit doit livrer
- Un inventaire des comptes, abonnements et projets avec leurs responsables
- Les résultats des outils (bruts et filtrés), avec les faux positifs expliqués
- Des constats notés selon leur criticité dans votre contexte, chacun avec une correction observable
- Une feuille de route : d'abord les garde-fous (politiques d'organisation, journalisation, détection), ensuite les corrections compte par compte
- Idéalement, l'outil de posture configuré pour tourner régulièrement, afin que le score devienne un indicateur et non un exercice ponctuel
Questions à poser au prestataire
- Auditez-vous au niveau de l'organisation, y compris la configuration du fournisseur d'identité ?
- Sur quel référentiel la notation est-elle faite, et conserverons-nous les résultats bruts ?
- Avez-vous besoin d'accès en écriture ? (Un audit de posture ne demande que des rôles en lecture seule.)
- Nous aiderez-vous à corriger les garde-fous en code, ou seulement à les signaler ?
Notre accompagnement
Tadata réalise des audits de sécurité cloud sur AWS, Azure et Google Cloud et aide à mettre en œuvre les corrections en code dans le cadre de son offre sécurité cloud et DevSecOps ; voir notre page cybersécurité. Pour une vue plus large de la maturité de votre organisation, lisez ce que doit couvrir un audit de posture, et consultez notre bibliothèque de fiches pour des aide-mémoire.