Pentest cloud et pentest infrastructure classique, ce qui change
Un pentest infrastructure traditionnel cible des machines, des ports ouverts, des services réseau exposés. Un pentest cloud regarde ailleurs, la surface d'attaque la plus critique en environnement AWS, Azure ou GCP se trouve dans la gestion des identités et des accès (IAM), la configuration du stockage, et les liens de confiance entre services cloud-natifs. Une entreprise peut avoir un pentest web et un pentest réseau irréprochables tout en laissant un compartiment de stockage public ou une identité managée sur-privilégiée grande ouverte.
Ce que chaque fournisseur cloud autorise
Contrairement à une idée reçue encore répandue, les principaux fournisseurs cloud n'exigent plus d'autorisation préalable pour tester ses propres ressources sur la majorité des services :
| Fournisseur | Autorisation et restrictions |
|---|---|
| AWS | Autorisation préalable non requise depuis 2019 pour les services autorisés. Restent interdits ou soumis à accord, le déni de service, le DNS zone walking sur Route 53, et tout test contre l'infrastructure AWS elle-même. |
| Microsoft Azure | Autorisation préalable non requise depuis 2017. Le respect des Microsoft Cloud Unified Penetration Testing Rules of Engagement reste obligatoire. |
| Google Cloud | Autorisé sur vos propres projets. Le test doit rester strictement limité à vos projets GCP et respecter la politique de sécurité de Google. |
Dans tous les cas, une autorisation écrite interne (mandat de test) reste indispensable avant toute intervention, même si le fournisseur cloud lui-même n'exige plus d'accord préalable.
Les zones à risque prioritaires en environnement cloud
- IAM et privilèges, rôles trop larges, chemins d'escalade de privilèges entre comptes et services
- Stockage exposé, buckets S3 ou comptes de stockage Azure accessibles publiquement par erreur de configuration
- Identités et service principals, comptes de service sur-privilégiés, secrets stockés en clair dans du code ou des variables d'environnement
- Fonctions serverless, permissions excessives accordées à une fonction Lambda ou Azure Function
- Conteneurs et Kubernetes, configuration des clusters, exposition du plan de contrôle
- Journalisation cloud, capacité réelle à détecter une activité suspecte après coup (CloudTrail, Azure Monitor)
Méthodologie en 5 étapes
- Cadrage et autorisation écrite, définir le périmètre exact (comptes, projets, régions) et obtenir le mandat de test interne
- Cartographie de l'environnement, inventaire des ressources, comptes, rôles IAM et services exposés
- Analyse IAM et privilèges, recherche de chemins d'escalade et de permissions excessives
- Tests d'exposition, stockage public, endpoints accessibles, secrets exposés dans le code ou la configuration
- Rapport et priorisation, classement des failles par impact réel plutôt que par sévérité théorique
Appliquer une méthodologie de pentest web ou infrastructure classique à un environnement cloud sans l'adapter. La majorité des failles graves en environnement cloud ne se trouvent ni dans un port ouvert ni dans une application web, mais dans la configuration IAM et les liens de confiance entre services, un point qu'un pentest générique ne couvre pas.
Questions fréquentes
Qu'est-ce qu'un pentest cloud ?
C'est un test d'intrusion ciblant spécifiquement un environnement cloud (AWS, Azure, GCP), qui évalue la configuration IAM, les identités, le stockage exposé et les services cloud-natifs, plutôt que l'infrastructure réseau classique.
Faut-il l'autorisation d'AWS ou d'Azure avant de tester ?
Non, ni AWS ni Azure n'exigent d'autorisation préalable pour tester ses propres ressources sur la plupart des services depuis respectivement 2019 et 2017, mais certaines activités (déni de service, DNS zone walking) restent interdites ou soumises à autorisation.
Quelle différence entre pentest cloud et audit de configuration cloud ?
L'audit de configuration vérifie la conformité à des référentiels de bonnes pratiques de façon statique. Le pentest cloud simule une exploitation réelle des failles identifiées pour en mesurer l'impact concret.
À quelle fréquence faire un pentest cloud ?
Au minimum une fois par an, et après tout changement significatif d'architecture cloud, migration, nouvel environnement, refonte des droits IAM, car un environnement cloud évolue plus vite qu'une infrastructure classique.
Besoin d'un pentest de votre environnement cloud ?
ONYX-CYBER réalise des tests d'intrusion adaptés aux environnements AWS, Azure et GCP, au-delà d'un simple audit de configuration.
Demander un accompagnement