Pentest cloud AWS, Azure et GCP : méthodologie et autorisations

Le pentest cloud est fondamentalement différent du pentest traditionnel. Les cibles ne sont plus des serveurs dans une salle machine mais des APIs, des services managés, des fonctions serverless et des politiques IAM hébergés chez AWS, Azure ou GCP. Les techniques d'attaque diffèrent, les outils changent, et surtout — les règles d'autorisation sont strictement encadrées par les fournisseurs cloud. Ce guide explique comment réaliser un test d'intrusion cloud professionnel, de l'obtention des autorisations à la restitution du rapport.

Autorisations et règles d'engagement par provider

Amazon Web Services (AWS)

AWS autorise les tests de sécurité sur votre propre infrastructure sans demande préalable pour la plupart des services (EC2, RDS, Lambda, ECS, API Gateway, S3, ELB). Les restrictions concernent les services managés partagés : vous ne pouvez pas tester la couche physique des datacenters, les hyperviseurs, ou les services AWS eux-mêmes. Les attaques DoS et le fuzzing agressif sur les APIs AWS sont interdits sans accord explicite. La politique AWS Penetration Testing est disponible dans la documentation officielle et doit être lue attentivement avant chaque engagement.

Microsoft Azure

Microsoft demande une notification préalable via le portail de notification de pentest Azure pour les tests impliquant des ressources partagées ou des services Microsoft. Pour votre propre abonnement Azure avec vos propres ressources isolées, aucune notification n'est requise. Microsoft publie ses règles d'engagement ("Penetration Testing Rules of Engagement") qui définissent les activités autorisées et interdites.

Google Cloud Platform (GCP)

GCP adopte une position similaire à AWS : les tests sur vos propres projets sont autorisés sans demande préalable. Les restrictions portent sur les couches d'infrastructure partagées et les APIs GCP elles-mêmes. Google publie ses directives dans la section "Vulnerability Reward Program" de son site de sécurité.

Méthodologie de pentest cloud

Phase 1 : Reconnaissance

La reconnaissance cloud commence par l'OSINT : énumération des sous-domaines de l'organisation (souvent révélateurs des services cloud utilisés), recherche de credentials dans des dépôts GitHub publics (avec des outils comme GitDorker ou TruffleHog), identification des buckets S3/Blob/GCS publics (BucketFinder, GrayhatWarfare), et recherche de services exposés (Shodan, Censys pour AWS, Azure, GCP). L'objectif est d'identifier la surface d'attaque externe avant d'accéder à l'environnement cible.

Phase 2 : Compromission initiale

Les vecteurs d'entrée les plus fréquents en pentest cloud : credentials AWS/Azure exposés (dans le code, des fichiers de configuration, des logs publics), buckets S3/Blob exposés contenant des fichiers de configuration sensibles, services web vulnérables hébergés sur des instances cloud (SSRF pour atteindre le service de métadonnées), fonctions Lambda/Azure Functions avec des permissions excessives et des entrées non validées, et APIs mal sécurisées (absence d'authentification, injections).

Phase 3 : Attaques sur les métadonnées cloud

Le service de métadonnées d'instance (IMDS) est une cible privilégiée en pentest cloud. Sur AWS, l'endpoint http://169.254.169.254/latest/meta-data/iam/security-credentials/ retourne les credentials temporaires du rôle IAM attaché à l'instance. Une vulnérabilité SSRF dans une application web peut permettre à un attaquant externe d'interroger ce service et d'obtenir des credentials cloud valides. La protection : activer IMDSv2 (nécessite un header de session préalable) et désactiver IMDSv1. Azure et GCP ont des services similaires avec leurs propres protections.

Phase 4 : Escalade de privilèges IAM

Après avoir obtenu des credentials cloud, l'objectif est d'escalader les privilèges. Les techniques d'escalade IAM sur AWS incluent : l'ajout de politiques à son propre utilisateur (si la permission iam:AttachUserPolicy est accordée), la création d'un rôle plus privilégié (iam:CreateRole + iam:AttachRolePolicy), l'exploitation de confiance de rôles mal configurées (sts:AssumeRole sur des rôles trop permissifs), la modification de politiques de rôles existants, et la création d'utilisateurs avec des droits Admin. Pacu (l'équivalent cloud de Metasploit) et Pmapper sont les outils de référence pour cette phase.

Phase 5 : Mouvement latéral et exfiltration

Une fois des droits élevés obtenus, le pentest explore le mouvement latéral : accès aux autres services (RDS, DynamoDB, Secrets Manager, SSM Parameter Store), pivot entre régions et comptes via les rôles cross-account, accès aux données sensibles (buckets, bases de données), et extraction de secrets. Dans un contexte multi-compte AWS Organizations, compromettre un compte de faible criticité peut permettre d'atteindre des comptes de production via des trusts mal configurés.

Outils spécialisés pour le pentest cloud

Pacu (Rhino Security Labs) : framework d'exploitation AWS similaire à Metasploit, avec des modules pour l'énumération, l'escalade de privilèges IAM, la persistance et l'exfiltration. Prowler : outil d'audit de sécurité AWS avec plus de 300 checks de sécurité et conformité. ScoutSuite (NCC Group) : outil multi-cloud (AWS, Azure, GCP, Alibaba) pour l'audit de configuration avec reporting HTML. ROADtools : framework d'audit Azure AD/Entra ID et Azure. PowerZure : framework PowerShell pour les tests d'intrusion Azure.

Livrables d'un pentest cloud professionnel

Un rapport de pentest cloud qualifié PASSI doit inclure : un résumé exécutif en langage métier (impact business de chaque finding), une méthodologie détaillée (phases, outils, durée), un inventaire des ressources testées, le détail de chaque vulnérabilité avec preuve d'exploitation (screenshots, commandes exécutées), la classification CVSS de chaque finding, des recommandations de remédiation spécifiques aux services cloud concernés, et une cartographie des chemins d'attaque exploités. La restitution inclut une présentation orale à l'équipe technique et, si souhaité, une session au COMEX.