Publié le 7 juillet 2026 · Sécurité cloud

Méthodologie d’un pentest cloud : de la reconnaissance à la remédiation

Un test d’intrusion cloud ne ressemble pas à un pentest classique. Il ne s’agit plus d’attaquer un périmètre réseau derrière un pare-feu, mais un ensemble d’API, d’identités (IAM) et de services managés. La surface d’exposition n’est plus une adresse IP publique : c’est un jeton d’accès, un rôle mal cloisonné ou un bucket ouvert. Le plan de contrôle — le control plane qui pilote l’ensemble des ressources via l’API du fournisseur — devient une cible de premier ordre.

Cet article décrit la méthodologie que suit une mission de pentest d’infrastructure cloud professionnelle, phase par phase. Un préalable non négociable : tout test est mandaté, autorisé par écrit et strictement encadré par des règles d’engagement. On ne teste que des ressources dont le client est propriétaire, dans le respect des politiques d’usage acceptable des fournisseurs cloud. Ce qui suit décrit une démarche et des catégories de technique, pas un mode opératoire clé en main contre une cible en production.

Les cadres de référence

Une mission sérieuse ne s’improvise pas : elle s’appuie sur des référentiels reconnus qui structurent la démarche et rendent les résultats reproductibles. Le PTES (Penetration Testing Execution Standard) définit le déroulé général d’un test d’intrusion, du cadrage à la restitution. Les guides OWASP couvrent les faiblesses applicatives, y compris côté cloud-native. La MITRE ATT&CK Cloud Matrix fournit une taxonomie des tactiques et techniques (TTP) réellement observées chez les attaquants, adaptée aux environnements cloud. Les référentiels NIST et ceux de la Cloud Security Alliance (CSA) complètent le cadre sur les aspects gouvernance et bonnes pratiques.

En France, le PASSI est le référentiel de l’ANSSI qui qualifie les prestataires d’audit de sécurité, dont les tests d’intrusion font partie. Il fixe des exigences de méthode, de déontologie et de compétence. Il ne remplace pas les cadres techniques précédents : il encadre la manière dont un prestataire mène et documente ses missions.

Les six phases d’une mission

Quel que soit le fournisseur, une mission de pentest cloud suit une trame stable. Chaque phase produit des livrables qui alimentent la suivante, et l’ensemble converge vers un objectif unique : démontrer, preuve à l’appui, ce qu’un attaquant pourrait réellement accomplir.

1. Cadrage et règles d’engagement

Tout commence par la définition du périmètre : comptes et abonnements concernés, services et applications inclus, fenêtres de test, personnes à prévenir en cas d’incident. On formalise l’autorisation écrite, les règles d’engagement (ce qui est permis, ce qui est exclu) et l’analyse des politiques d’usage acceptable des fournisseurs cloud, car certaines activités doivent être notifiées ou restent proscrites. Cette phase n’est pas une formalité : elle protège le client comme le prestataire.

2. Reconnaissance

Le testeur cartographie la surface : énumération des identités et des rôles, des services exposés, des buckets et espaces de stockage, des endpoints d’API. L’objectif est de dresser un inventaire fidèle de ce qui est atteignable et de comprendre les relations entre ressources, sans encore chercher à exploiter quoi que ce soit.

3. Identification des vulnérabilités et mauvaises configurations

À partir de la cartographie, le testeur repère les faiblesses : configurations dangereuses, permissions excessives, services exposés sans nécessité, secrets potentiellement accessibles. C’est ici que l’expertise humaine prend le pas sur l’outillage : un scanner liste des constats, l’analyste identifie ceux qui pourraient s’enchaîner.

4. Exploitation contrôlée

Le testeur valide l’exploitabilité des faiblesses retenues, de façon maîtrisée et réversible. Les grandes catégories de technique sont bien connues : l’escalade de privilèges IAM (par exemple des relations de confiance ou un usage de iam:PassRole mal maîtrisés), l’abus du service de métadonnées d’instance (IMDS) pour récupérer des informations d’identification, l’exploitation de secrets exposés dans le code, les variables d’environnement ou les images, et l’accès à des stockages mal configurés. L’objectif reste la preuve, jamais la nuisance.

5. Post-exploitation et mouvement latéral

Une fois un premier accès obtenu, la question devient : jusqu’où peut-il mener ? Le testeur évalue les possibilités de rebond — chaînes d’assume-role, franchissement cross-account entre comptes, pivot vers d’autres services managés. C’est cette étape qui transforme une faiblesse isolée en chaîne d’escalade complète et mesure le rayon d’impact réel.

6. Restitution et remédiation

La mission se conclut par un rapport documenté : chaînes d’attaque démontrées, preuves, priorisation par impact métier et non par simple score technique, et un plan de remédiation actionnable. La valeur d’un pentest se juge ici : un rapport clair, hiérarchisé, qui permet aux équipes de corriger les bonnes choses dans le bon ordre.

Spécificités AWS, Azure et GCP

La méthodologie reste la même, mais chaque fournisseur a ses modèles d’identité et ses pièges propres. Sur AWS, le cœur du sujet est le système de rôles IAM et de relations de confiance, ainsi que la version du service de métadonnées d’instance (IMDSv1, plus permissif, contre IMDSv2, protégé par jeton). Des outils d’audit et de reconnaissance légitimes comme Prowler (revue de configuration), Pacu (cadre d’analyse offensive) ou pMapper (analyse des relations de permissions) aident à cartographier l’environnement.

Sur Azure, l’attention porte sur les identités managées et sur Entra ID (anciennement Azure AD), qui gouverne l’authentification et les rôles. Des outils comme MicroBurst ou Stormspotter servent à explorer et visualiser ces relations. Sur GCP, ce sont les comptes de service et leurs rattachements qui structurent la surface ; ScoutSuite permet un audit de configuration multicloud. Dans tous les cas, ces outils restent des instruments d’audit et de reconnaissance : l’analyse et le jugement du testeur font la différence. Pour le volet applicatif, la démarche se prolonge dans un pentest d’application cloud-native.

Pentest vs scan de posture : ce que l’un prouve et l’autre non

La différence est structurelle. Un audit de configuration (posture, de type CSPM) énumère des constats isolés : ce bucket est public, ce rôle est trop large, ce chiffrement est absent. Il couvre l’étendue et signale des symptômes, mais il ne dit pas lesquels sont réellement exploitables ni comment ils se combinent.

Un pentest prouve l’exploitabilité : il enchaîne plusieurs faiblesses modérées en un chemin d’attaque complet et démontre l’impact concret sur les données ou les services. Là où le scanner produit une liste, le pentest produit une démonstration. Les deux sont complémentaires : la posture surveille en continu et couvre le volume ; le pentest valide en profondeur, à un instant donné, ce qu’un attaquant peut réellement obtenir.

Questions fréquentes

Un pentest cloud est-il autorisé par AWS, Azure et GCP ?

Oui, pour vos propres ressources et dans le respect des politiques d’usage acceptable du fournisseur. AWS, Azure et GCP autorisent les tests d’intrusion sur les comptes et abonnements que vous contrôlez, sans notification préalable pour la majorité des services. Certaines activités restent encadrées ou nécessitent une notification (tests de déni de service, envois massifs, services partagés). Un prestataire sérieux vérifie ces règles au cadrage et fait signer une autorisation écrite avant tout test.

Combien de temps dure un pentest cloud ?

La durée dépend du périmètre : nombre de comptes ou d’abonnements, de services managés, d’applications et d’identités concernés. Une mission ciblée sur un seul compte se déroule souvent sur une à deux semaines de tests, hors cadrage et restitution. Un environnement multicloud avec plusieurs comptes et une application cloud-native demande généralement trois à quatre semaines. Le budget associé est détaillé dans notre article sur le prix d’un pentest cloud.

Quelle différence entre un pentest cloud et un audit de configuration ?

Un audit de configuration (posture, type CSPM) inventorie les ressources et liste les écarts par rapport aux bonnes pratiques : bucket public, chiffrement absent, rôle trop permissif. Il produit des constats isolés. Un pentest cloud va plus loin : il prouve l’exploitabilité en enchaînant plusieurs faiblesses en un chemin d’attaque réel, du point d’entrée jusqu’à l’impact métier. L’audit dit ce qui est mal configuré ; le pentest démontre ce qu’un attaquant peut réellement en faire.

Faut-il un prestataire PASSI pour un pentest cloud ?

Le PASSI est le référentiel de l’ANSSI qui qualifie les prestataires d’audit de sécurité, dont les tests d’intrusion. La qualification est exigée pour certains contextes réglementés (opérateurs d’importance vitale, services essentiels). Pour la plupart des entreprises, elle n’est pas obligatoire : ce qui compte est la rigueur méthodologique, l’encadrement contractuel, la clarté des règles d’engagement et la qualité du rapport. Le PASSI reste une référence utile pour évaluer le sérieux d’un prestataire.