Pentest cloud : comment tester la sécurité de votre infrastructure AWS, Azure ou GCP

Une entreprise du secteur des services avait migré l’essentiel de son système d’information vers AWS deux ans plus tôt. Le discours en interne était rassurant : « Amazon gère la sécurité, on est chez un des plus gros du marché. » Ce discours a volé en éclat le jour où un chercheur en sécurité a signalé, par un simple email, qu’un bucket S3 contenant des contrats clients et des bulletins de paie était accessible publiquement depuis n’importe quel navigateur, sans mot de passe, indexé par un moteur de recherche spécialisé. Personne n’avait piraté quoi que ce soit. Il suffisait de connaître l’adresse.

Cette histoire, ou une variante très proche, revient régulièrement dans les retours d’expérience des consultants en cybersécurité qui interviennent sur des environnements cloud. Elle illustre une confusion fréquente chez les dirigeants et les équipes IT : migrer vers AWS, Azure ou GCP ne transfère pas la responsabilité de la sécurité au fournisseur. Elle la déplace, et souvent elle la complexifie.

Cet article détaille ce qu’un pentest cloud vérifie concrètement, en quoi il diffère d’un test d’intrusion classique, les particularités propres à AWS, Azure et GCP, et les erreurs de configuration qui reviennent le plus souvent dans les missions menées sur ces environnements.

Le mythe du cloud sécurisé par défaut

Les fournisseurs cloud s’appuient sur un principe appelé modèle de responsabilité partagée. AWS, Microsoft et Google sécurisent effectivement l’infrastructure physique : les data centers, le matériel, le réseau global, la virtualisation. Cette partie de l’équation est solide, auditée en continu, et largement hors de portée d’une entreprise cliente de toute façon.

Ce que ces fournisseurs ne font pas, en revanche, c’est configurer correctement votre environnement. La gestion des identités et des accès, les règles réseau, le chiffrement des données, les permissions accordées à chaque service, la fermeture des ports inutiles : tout cela reste entièrement à la charge du client. Un fournisseur cloud peut proposer l’option de chiffrement la plus robuste du marché. Si personne ne l’active sur le bon compartiment de stockage, elle ne sert à rien.

Cette confusion coûte cher parce qu’elle est rassurante en apparence. Une entreprise qui migre vers le cloud a souvent l’impression de déléguer un problème complexe à un spécialiste. Elle délègue en réalité une partie du problème, celle qui concerne l’infrastructure physique, et hérite d’un nouveau problème, celui de la configuration d’un environnement dont la complexité dépasse largement ce que gérait son ancien serveur on-premise.

Ce qu’un pentest cloud teste concrètement

Un test d’intrusion cloud ne ressemble pas à un scan de vulnérabilités automatisé sur une liste d’adresses IP. Il porte sur des couches spécifiques à l’architecture cloud, que la plupart des outils traditionnels ne couvrent pas correctement. Ce positionnement le distingue d’ailleurs des autres types de pentests plus classiques, centrés sur le réseau ou les applications.

• La gestion des identités et des accès, ou IAM, constitue généralement le point d’entrée le plus riche pour un pentester. Il s’agit de vérifier si des comptes disposent de droits excessifs par rapport à leur usage réel, si des chaînes de délégation de rôles permettent une élévation de privilèges, ou si des comptes de service oubliés conservent des accès actifs plusieurs mois après la fin d’un projet.
• Le stockage constitue le deuxième axe majeur : buckets S3 chez AWS, Blob Storage chez Azure, Cloud Storage chez GCP. Le test vérifie les permissions d’accès, la présence de données sensibles non chiffrées, et la configuration des politiques d’accès public qui, une fois mal comprises, exposent des volumes entiers de documents à quiconque connaît ou devine l’adresse.
• La configuration réseau vient ensuite : groupes de sécurité et VPC chez AWS, groupes de sécurité réseau et VNet chez Azure, règles de pare-feu et VPC chez GCP. Un pentest vérifie si des ports sensibles restent ouverts sur Internet, si la segmentation entre environnements de production et de test est réellement étanche, et si des interfaces d’administration sont accessibles depuis l’extérieur alors qu’elles ne devraient l’être que depuis un réseau interne ou un VPN.
• Les services managés et applicatifs, fonctions serverless, conteneurs, clusters Kubernetes managés, complètent le périmètre. Ces briques accélèrent le développement mais introduisent des surfaces d’attaque nouvelles : variables d’environnement contenant des secrets en clair, images de conteneurs obsolètes, API exposées sans authentification suffisante.
• Enfin, la journalisation et la détection font l’objet d’une attention particulière : CloudTrail chez AWS, Azure Monitor et Microsoft Sentinel chez Azure, Cloud Logging chez GCP. Un environnement mal surveillé peut subir une intrusion pendant des semaines sans qu’aucune alerte ne se déclenche, ce qui rend le pentest d’autant plus utile pour vérifier la capacité de détection réelle, et pas seulement théorique.

En quoi un pentest cloud diffère d’un test d’intrusion classique

La première différence, souvent méconnue, tient au cadre légal et contractuel. Contrairement à un test d’intrusion sur une infrastructure on-premise, un pentest cloud implique de respecter les règles d’engagement fixées par le fournisseur. AWS, Microsoft et Google publient chacun une politique précisant les tests autorisés sans notification préalable et ceux qui nécessitent une autorisation explicite, et ces règles peuvent évoluer. Les ignorer expose l’entreprise, et le prestataire, à une suspension de compte en plein test, voire à des conséquences contractuelles plus lourdes.

La deuxième différence concerne la nature de la cible. Un pentest réseau classique cherche des failles dans une topologie relativement stable : serveurs, commutateurs, postes de travail. Un environnement cloud, lui, est vivant. L’infrastructure as code, l’autoscaling et les déploiements continus signifient que la configuration testée un lundi peut avoir changé le mercredi suivant. Un pentest cloud sérieux ne se contente donc pas d’un instantané : il évalue aussi les processus qui génèrent la configuration, pas uniquement l’état constaté le jour du test.

La troisième différence tient à la nature des failles recherchées. Sur une infrastructure classique, une part importante des vulnérabilités provient de logiciels non mis à jour. Sur le cloud, l’essentiel des failles exploitables provient de mauvaises configurations humaines, pas de failles logicielles dans les services eux-mêmes. C’est une bascule importante : corriger une configuration IAM excessive rapporte souvent davantage, en réduction de risque, que patcher un système d’exploitation. Une fois cette élévation de privilèges obtenue, ce qu’un attaquant peut en faire sur le reste de l’environnement dépend largement de la segmentation mise en place en amont.

Les particularités propres à AWS, Azure et GCP

Les trois grands fournisseurs partagent des principes communs mais diffèrent suffisamment dans leur implémentation pour qu’un pentest cloud efficace nécessite une expertise dédiée à chacun.

Chez AWS, la complexité vient de la richesse du système IAM : politiques écrites en JSON, rôles assumables en cascade, permissions qui peuvent s’accumuler de façon peu lisible même pour une équipe expérimentée. Les chemins d’élévation de privilèges indirects, où un utilisateur peut modifier sa propre politique ou assumer un rôle plus puissant via une série d’autorisations en apparence anodines, comptent parmi les découvertes les plus fréquentes lors des missions SkillX sur cet environnement.

Chez Azure, l’intégration étroite avec Entra ID (anciennement Azure Active Directory) rapproche fortement la sécurité cloud de la sécurité de l’annuaire d’entreprise. Un pentest cloud sur Azure recoupe ainsi souvent les mêmes enjeux qu’un audit Active Directory : comptes à privilèges excessifs, accès conditionnels mal configurés, synchronisation hybride entre l’annuaire local et le cloud qui peut ouvrir des chemins d’attaque inattendus entre les deux mondes.

Chez GCP, la structure hiérarchique des projets, organisée en organisation, dossiers et projets, introduit un enjeu spécifique d’héritage des permissions. Un rôle accordé au niveau de l’organisation se propage automatiquement vers tous les projets enfants, ce qui peut créer des accès bien plus larges que ce qu’imaginait la personne qui les a configurés, souvent par simple méconnaissance de cette propagation.

Les erreurs de configuration les plus fréquentes

Sur l’ensemble des missions de pentest cloud menées par nos équipes, un nombre restreint de failles revient de façon disproportionnée, tous fournisseurs confondus.

Les compartiments de stockage accessibles publiquement arrivent en tête, souvent parce qu’une option a été activée temporairement pour un partage ponctuel et jamais désactivée ensuite. Les clés d’accès et secrets stockés en clair dans du code source, parfois publiés par erreur sur des dépôts publics comme GitHub, constituent la deuxième source majeure de compromission, et l’une des plus rapides à exploiter pour un attaquant qui surveille ces plateformes.

Les rôles IAM disposant de droits d’administration par défaut, attribués par simplicité au moment de la création d’un projet et jamais restreints ensuite, figurent également parmi les constats récurrents. Vient ensuite l’absence d’authentification multifacteur sur les comptes à privilèges élevés, en particulier les comptes root ou les comptes propriétaires d’abonnement, dont la compromission donne un accès total à l’environnement.

Les groupes de sécurité ou règles de pare-feu ouverts sur l’ensemble des ports depuis Internet, souvent laissés dans cet état pendant une phase de test et jamais resserrés en production, complètent ce palmarès, aux côtés d’un chiffrement non activé sur des bases de données ou des volumes de stockage contenant pourtant des données sensibles.

Comment se préparer à un pentest cloud

Avant de lancer un test d’intrusion sur un environnement AWS, Azure ou GCP, plusieurs points méritent d’être clarifiés avec le prestataire retenu. Le périmètre doit être défini avec précision : comptes, projets ou abonnements concernés, environnements de production inclus ou exclus, services managés testés ou non. L’autorisation formelle auprès du fournisseur cloud, quand elle est requise, doit être obtenue avant le début des tests, pas en cours de mission.

Il est également utile de préciser si le test doit se dérouler en boîte noire, sans aucune information préalable sur l’architecture, ou en boîte grise, avec un accès limité type utilisateur standard, ce qui permet souvent d’aller plus loin dans le temps imparti sur des environnements complexes. Ce choix, comme les critères pour choisir son prestataire, mérite d’être posé en amont plutôt que découvert en cours de mission. Enfin, la restitution doit aboutir à un plan de remédiation hiérarchisé, distinguant les correctifs à traiter en urgence, comme un bucket public contenant des données sensibles, des ajustements plus structurels à planifier sur plusieurs mois.

Notre outil d’estimation de test d’intrusion Avant de lancer une démarche, vous vous demandez... Combien coûterait un pentest ? Estimez le tarif d’un test d’intrusion sur vos SI en quelques minutes grâce à notre questionnaire ! ● Estimer le prix d’un pentest sur mes SI

Un état qui se dégrade sans surveillance continue

Un environnement cloud bien configuré n’est pas un acquis définitif. C’est un état qui se dégrade naturellement avec le temps, à mesure que des équipes ajoutent des services, des accès et des intégrations sans toujours mesurer l’effet cumulé sur la surface d’attaque. Un pentest cloud régulier, réalisé au moins une fois par an ou après chaque évolution significative de l’architecture, reste l’une des méthodes les plus fiables pour vérifier que la promesse de sécurité de votre fournisseur cloud correspond bien à la réalité de votre propre configuration.