Pentest cloud
Un pentest cloud (test d’intrusion cloud) mesure jusqu’où va un attaquant dans AWS, Microsoft Azure ou Google Cloud une fois qu’il détient une clé d’accès, un compte utilisateur ou l’adresse d’un espace de stockage laissé ouvert. Nous cherchons les erreurs de configuration, les privilèges excessifs et les chemins de latéralisation d’un compte à l’autre, sans interrompre votre production.
Nous vérifions qui peut réellement accéder à quoi : rôles IAM et politiques attachées, règles de pare-feu, réseaux virtuels, droits sur les espaces de stockage, secrets oubliés dans les chaînes CI/CD et faiblesses de l’identité fédérée — Entra ID (anciennement Azure AD), authentification unique, comptes de service. Tout ce qui est joignable depuis Internet fait l’objet d’un examen distinct.
Vous ne recevez pas la liste de tous les écarts détectés, mais un ordre de traitement : ce qui doit changer cette semaine et ce qui peut attendre la prochaine fenêtre de maintenance. Le contre-audit après correction est compris dans le prix.
Ils nous font confiance
Objectifs d’un pentest cloud
AWS, Microsoft et Google sécurisent leur propre infrastructure. La manière dont votre environnement est configuré à l’intérieur reste votre responsabilité : c’est le modèle de responsabilité partagée, et c’est précisément cette moitié que nous testons — modèle de droits, segmentation réseau, paramètres de stockage, journalisation. C’est là que commencent la quasi-totalité des fuites de données et des élévations de privilèges.
Un scan de configuration compare vos réglages aux recommandations de l’éditeur. C’est utile, mais cela ne répond pas à la seule question qui décide d’un budget : cet écart est-il réellement exploitable, et jusqu’où mène-t-il ? Nous le vérifions à la main, preuve d’exploitation à l’appui.
Savoir ce qui est réellement exploitable
Une alerte de conformité n’est pas une vulnérabilité. Nous validons chaque écart manuellement et seul ce qu’un attaquant peut effectivement enchaîner figure au rapport, avec le chemin d’attaque reconstitué.
Mesurer la portée d’un compte compromis
Si un jeton d’accès de développeur fuite demain, jusqu’où mène-t-il ? Nous partons d’un accès à faible privilège et nous remontons : rôles cumulés, politiques trop larges, relations de confiance entre comptes et abonnements.
Vérifier l’exposition réelle des données
Espaces de stockage lisibles sans authentification, sauvegardes oubliées, instantanés de bases partagés trop largement, secrets laissés dans des variables d’environnement ou dans l’historique d’un dépôt.
Savoir si vous auriez vu passer l’attaque
Nos actions laissent des traces. Nous comparons ce que vos journaux d’audit ont enregistré avec ce que nous avons réellement fait, et nous vous indiquons ce qui est passé inaperçu.
Périmètre
Types de pentest cloud et périmètre couvert
Un pentest cloud ne se limite pas à la gestion des identités. Selon votre environnement, le périmètre couvre tout ou partie des huit domaines ci-dessous ; il est arrêté au cadrage et écrit dans le devis.
AWS, Azure, GCP et Microsoft 365
Les trois hyperscalers et leurs services natifs. Dans beaucoup d’organisations françaises, le cloud commence par Microsoft 365 et Entra ID : nous l’intégrons par défaut au périmètre. Un environnement entièrement AWS ou un socle multi-cloud nous sont tout aussi familiers.
IAM et privilèges excessifs
Qui détient quoi, où le principe du moindre privilège cède, quels rôles cumulent des permissions qui ne devaient jamais se croiser. Les politiques génériques, les rôles de service oubliés et les clés d’accès sans rotation sont le premier chemin d’élévation que nous trouvons.
Buckets et stockage exposés
S3, Blob Storage, Cloud Storage : droits d’accès, chiffrement, instantanés et sauvegardes. Les données personnelles font l’objet d’un traitement distinct dans le rapport, car une fuite relève de l’article 33 du RGPD et d’une notification à la CNIL dans les 72 heures.
Secrets dans les chaînes CI/CD
Clés d’API, jetons de déploiement et identifiants de service dans les variables de pipeline, les images de conteneurs, l’historique des dépôts et les journaux de compilation. C’est aujourd’hui l’un des points d’entrée les plus rentables pour un attaquant.
Conteneurs et Kubernetes
EKS, AKS, GKE et clusters autogérés : RBAC, comptes de service, politiques d’admission, échappement de conteneur et accès à l’API du cluster depuis un pod compromis.
Segmentation réseau
VPC et VNet, groupes de sécurité, règles de pare-feu, appairages et liaisons hybrides vers le système d’information interne — en pratique bien plus permissives que ne le décrit le schéma d’architecture.
Services exposés sur Internet
Points d’entrée ouverts, environnements de recette oubliés, interfaces d’administration joignables publiquement et fonctions serverless déclenchables sans authentification.
Journalisation et détection
Ce que vos journaux d’audit enregistrent, ce qui déclenche une alerte et si votre équipe — ou votre prestataire de supervision — remarque nos actions pendant qu’elles ont lieu.
Approches
Approches : boîte noire, boîte grise, boîte blanche
L’approche retenue détermine ce que vous achetez réellement : un test en boîte noire mesure votre exposition vue de l’extérieur, un test en boîte blanche mesure la solidité de votre configuration. Dans le cloud, où l’essentiel du risque se situe derrière l’authentification, c’est la boîte grise que nous recommandons dans la grande majorité des missions. Le choix de l’approche est arrêté au cadrage et inscrit dans le devis ; il détermine directement le nombre de jours-homme à prévoir.
Boîte noire (black box)
Nous partons sans aucun accès, comme un attaquant qui découvre votre organisation : recensement des domaines et des ressources exposées, moteurs de recherche de services, dépôts publics, espaces de stockage accessibles sans authentification, identifiants déjà compromis en circulation. Cette approche mesure votre surface d’exposition réelle, mais elle laisse dans l’ombre tout ce qui se joue derrière l’authentification.
Boîte grise (grey box)
Vous nous remettez un compte ou un rôle à privilèges limités, tel qu’en disposerait un développeur ou un prestataire. Nous partons de là et nous cherchons jusqu’où il est possible de remonter. C’est l’approche que nous recommandons dans le cloud : elle reproduit le scénario le plus fréquent — un identifiant compromis — et couvre en quelques jours ce qu’un test en boîte noire mettrait des semaines à atteindre.
Boîte blanche (white box)
Accès en lecture à la configuration, aux politiques IAM, aux modèles d’infrastructure as code et, le cas échéant, au code des fonctions. La couverture est maximale et le rapport devient un plan de remédiation directement applicable. C’est l’approche à retenir avant une mise en production, une migration ou un audit de certification.
Cadrage
Périmètre, cadrage et règles du fournisseur cloud
Le cadrage précède le devis. Nous listons les comptes AWS, abonnements Azure, projets GCP et tenants Microsoft 365 concernés, les services activés, les clusters, les environnements explicitement exclus et les créneaux d’intervention. Ce qui ne figure pas dans la note de cadrage n’est pas testé, et ce qui y figure est testé en totalité.
Un environnement cloud ne se teste pas uniquement selon nos règles : celles de votre fournisseur s’appliquent aussi. AWS, Microsoft et Google publient chacun leur politique de tests d’intrusion. Une large part des tests menés sur vos propres ressources est autorisée sans démarche préalable ; certaines catégories exigent une déclaration ; d’autres actions restent interdites quel que soit votre mandat — déni de service, tests visant l’infrastructure partagée ou des ressources appartenant à d’autres clients. Nous vérifions ces règles pour chaque plateforme du périmètre avant de commencer, nous préparons la déclaration lorsqu’elle est nécessaire, et nous indiquons dans le rapport les vérifications écartées pour cette raison.
Tous nos tests d’intrusion sont réalisés sur mandat écrit, dans un périmètre défini contractuellement (articles 323-1 et suivants du code pénal). Si votre environnement est administré par un intégrateur ou fourni en mode SaaS, son autorisation écrite est requise en plus de la vôtre ; nous vous aidons à la formaliser pendant le cadrage.
Méthodologie
Notre méthodologie et le déroulement de la mission
Nous nous appuyons sur des référentiels publics plutôt que sur une méthode maison invérifiable : PTES pour la conduite de la mission, le guide OWASP WSTG pour les interfaces web et les API exposées par vos services cloud, les CIS Benchmarks AWS, Azure et GCP comme base de comparaison des configurations, et la matrice MITRE ATT&CK Cloud pour nommer les techniques employées. Vos équipes peuvent ainsi relire nos constats sans avoir à nous croire sur parole. Le détail de nos méthodologies de test est publié sur une page dédiée, dont notre lecture du référentiel OWASP.
La part outillée existe — recensement des ressources, collecte de configuration, détection des écarts — mais elle sert à cadrer le travail manuel, pas à le remplacer : elle occupe la première journée, le reste de la mission est conduit à la main par un pentesteur.
Cadrage et autorisation
Nous définissons avec vous les objectifs, les comptes et abonnements concernés, les ressources critiques et les actions exclues. Vous recevez une note de cadrage, un planning et un devis à prix ferme. Le mandat écrit et, si nécessaire, la déclaration auprès de votre fournisseur cloud sont réglés à cette étape.
Reconnaissance et collecte de configuration
Recensement de ce qui est exposé depuis Internet, puis lecture de la configuration : politiques IAM et rôles, services activés, découpage réseau, paramètres de stockage, journalisation. Nous établissons la carte des droits réels — celle qui s’écarte toujours un peu de l’organigramme.
Exploitation et latéralisation
Nous vérifions quelles erreurs de configuration sont réellement exploitables et jusqu’où elles mènent : élévation de privilèges, passage d’un compte à un autre, accès aux données, rebond du cloud vers le système d’information interne. Chaque constat est étayé par une preuve d’exploitation.
Rapport et restitution
Vous recevez le rapport rédigé en français, les constats classés par criticité, puis nous le présentons en visioconférence à vos équipes techniques et à votre direction. Les questions se traitent pendant la restitution, pas par courriel trois semaines plus tard.
Contre-audit
Après vos corrections, nous retestons les vulnérabilités identifiées et nous délivrons une attestation de contre-audit. C’est compris dans le prix, sans surcoût, dans les 90 jours suivant la remise du rapport.
Livrables
Livrables : rapport, restitution et contre-audit
Un livrable de test d’intrusion s’adresse à deux publics : l’ingénieur qui corrige et le comité qui arbitre le budget. Le nôtre est écrit pour les deux, en français.
Synthèse managériale
Trois pages sans jargon : niveau de risque global, ce qui doit être corrigé en priorité, la charge que cela représente. Lisible par un comité de direction ou par un client qui vous audite.
Rapport technique détaillé
Chaque constat avec sa criticité (CVSS), le chemin d’attaque reconstitué, les éléments qui l’établissent et la correction précise à appliquer côté AWS, Azure, GCP ou Entra ID.
Plan de remédiation priorisé
Les constats classés par couple risque/effort, pour que votre équipe sache par quoi commencer lundi matin plutôt que de recevoir une liste de cent écarts sans ordre.
Export vers Jira ou Azure DevOps
Les constats livrés au format attendu par votre outil de suivi, afin qu’ils entrent directement dans votre cycle de développement.
Restitution en visioconférence
Une séance avec vos équipes cloud et, si vous le souhaitez, votre direction. Nous rejouons les chemins d’attaque et répondons aux questions en direct.
Contre-audit inclus
Un contre-audit complet après correction, compris dans le prix et sans surcoût, avec une attestation écrite utilisable dans votre dossier de conformité ou auprès de votre client.
Comparatif
Pentest cloud ou audit de configuration automatisé ?
Un audit automatisé recense rapidement les écarts par rapport aux recommandations de l’éditeur. Un test d’intrusion démontre lequel de ces écarts conduit à un incident réel et ce que l’attaquant en obtient. Les deux sont complémentaires : ils ne répondent simplement pas à la même question.
| Critère | Audit de configuration automatisé | Pentest cloud |
|---|---|---|
| Objectif | Détecter les écarts de configuration par rapport aux bonnes pratiques. | Démontrer qu’un écart est exploitable et en mesurer l’impact. |
| Méthode | Scans automatisés et comparaison à une configuration de référence. | Test manuel, enchaînement de chemins d’attaque et latéralisation. |
| Profondeur | Couverture large, sans preuve d’exploitation. | Vérification ciblée, avec preuve d’exploitation à l’appui. |
| Faux positifs | Nombreux : chaque écart est signalé, qu’il soit atteignable ou non. | Écartés pendant le test ; seul ce qui est démontré figure au rapport. |
| Livrable | Liste d’écarts et recommandations génériques. | Rapport priorisé, plan de remédiation et contre-audit inclus. |
| Rythme | En continu, intégré à la chaîne de déploiement. | Ponctuel : à chaque évolution majeure et au moins une fois par an. |
Vous hésitez entre les deux ? Commencez par un audit de vulnérabilités pour cartographier l’existant, puis un pentest cloud sur le périmètre le plus exposé. Voir aussi nos pages pentest web et test d’intrusion interne et externe.
Témoignages clients
Ce que nos clients disent de nous
Pourquoi confier votre pentest cloud à Haxoris ?
Nous sommes un prestataire européen et nous ne détenons aucune qualification délivrée par un organisme public français. Nous préférons l’écrire ici plutôt que de vous laisser le découvrir. Voici les trois engagements vérifiables que nous mettons en face.
Certifications de notre équipe
Contre-audit inclus, sans surcoût
Après vos corrections, nous retestons chaque vulnérabilité identifiée et nous vous remettons une attestation écrite. C’est compris dans le prix initial, dans les 90 jours suivant la remise du rapport. Un rapport qui n’est suivi d’aucune vérification ne prouve rien.
Nos tarifs sont publics
Nos fourchettes en euros HT et notre volume de jours-homme sont annoncés avant le premier échange, pas après trois réunions. Vous savez ce que coûte une mission cloud de cinq jours avant de nous appeler, et le devis remis après le cadrage est ferme.
Vous savez qui teste
Les pentesteurs affectés à votre mission sont nommés dans le devis, avec leurs certifications individuelles (OSCP, OSWE, CISSP). Vous leur parlez directement pendant le test, pas à un chef de projet intermédiaire.
Souveraineté et traitement des données
La question revient dans presque tous les cadrages cloud en France, et elle mérite une réponse nette. Nous testons votre tenant, nous ne l’hébergeons pas. Haxoris n’est ni fournisseur d’infrastructure, ni revendeur, ni intégrateur : nous n’avons aucun intérêt à ce que vous restiez sur une plateforme plutôt qu’une autre, et aucune de vos données de production ne transite par une infrastructure que nous exploiterions à votre place. Le pentest s’exécute depuis nos postes d’audit, sur les accès que vous nous ouvrez et que vous refermez.
Haxoris est une société établie dans l’Union européenne. Les accès qui nous sont confiés sont nominatifs, limités au périmètre convenu et révoqués à la fin de la mission. Les éléments collectés pendant le test — captures, extraits de configuration, preuves d’exploitation — sont conservés chiffrés au sein de l’Union européenne, traités au titre du RGPD, et supprimés à votre demande ou à l’échéance contractuelle. La liste de nos sous-traitants vous est communiquée sur demande, avant signature.
Si votre environnement est soumis à des exigences particulières de localisation ou de confidentialité, indiquez-le au cadrage : nous adaptons la durée de conservation des preuves, le canal de transmission du rapport et le niveau de chiffrement des échanges. Pour le détail de nos engagements, voir la page à propos de Haxoris.
Dernière vérification : 11 septembre 2026.
Foire aux questions
01 Combien coûte un pentest cloud ?
Le prix suit le périmètre : nombre de comptes, d’abonnements et de projets, nombre de services activés, complexité du modèle de droits, présence ou non de conteneurs. Une mission délimitée sur un seul fournisseur démarre autour de 2 000 € HT ; un environnement de production réparti sur plusieurs comptes et plusieurs plateformes se situe nettement plus haut.
Nos fourchettes et notre taux jours-homme sont publics : vous connaissez l’ordre de grandeur avant le premier échange, et le devis remis après le cadrage est ferme. Le contre-audit est compris dans ce prix.
02 Combien de jours-homme faut-il prévoir ?
Entre 5 et 15 jours-homme dans la grande majorité des missions cloud. Un compte unique avec une dizaine de services activés représente 3 à 5 jours ; un environnement multi-comptes avec Entra ID, des clusters Kubernetes et des chaînes CI/CD demande plutôt 10 à 15 jours. Comptez deux à trois semaines de délai calendaire entre le lancement du test et la restitution.
Le nombre de jours est arrêté au cadrage et figure au devis. Nous ne facturons aucun jour supplémentaire sans accord écrit préalable.
03 Boîte noire ou boîte grise pour un environnement cloud ?
La boîte grise, dans la plupart des cas. Un test en boîte noire mesure votre exposition depuis Internet, ce qui est utile, mais laisse de côté tout ce qui se joue une fois l’attaquant à l’intérieur — et dans le cloud, l’essentiel du risque est là : privilèges excessifs, relations de confiance entre comptes, secrets accessibles depuis une machine de rebond.
En boîte grise, vous nous remettez un compte à privilèges limités et nous consacrons les jours achetés à la progression plutôt qu’à la phase de découverte. La boîte blanche, avec accès en lecture à la configuration et aux modèles d’infrastructure as code, offre la couverture la plus complète : c’est le choix pertinent avant une mise en production ou un audit de certification.
04 Le contre-audit est-il inclus ?
Oui, et sans surcoût. Après vos corrections, nous retestons les vulnérabilités identifiées et nous délivrons une attestation de contre-audit écrite, exploitable dans un dossier de conformité ou face à un client qui vous audite. Le contre-audit s’exerce dans les 90 jours suivant la remise du rapport.
C’est un point sur lequel nous nous distinguons délibérément : chez la plupart des prestataires, le contre-audit est une journée facturée en supplément.
05 Faut-il un prestataire qualifié ?
Pour un test d’intrusion commandé par une entreprise privée sur son propre environnement, aucune qualification délivrée par un organisme public n’est exigée. Ces qualifications relèvent de démarches volontaires ; elles deviennent déterminantes dans certains marchés publics et pour les contrôles imposés aux opérateurs d’importance vitale au titre de l’article L. 1332-6-3 du code de la défense. Nous ne détenons aucune qualification de ce type et nous ne soumissionnons pas sur ces prestations.
Ce qu’il faut alors demander à un prestataire : la méthodologie et les référentiels qu’il applique, les certifications individuelles nominatives des intervenants, un rapport d’exemple anonymisé avant signature, son assurance responsabilité civile professionnelle et son traitement des données collectées. Nous répondons à ces cinq points — voir la page à propos de Haxoris et nos témoignages clients.
06 Devons-nous prévenir notre fournisseur cloud ?
Cela dépend de la plateforme et des actions prévues. AWS, Microsoft et Google publient chacun leur politique de tests d’intrusion : une large part des tests menés sur vos propres ressources est autorisée sans démarche préalable, certaines catégories exigent une déclaration, et d’autres actions demeurent interdites quel que soit votre mandat — déni de service, tests visant l’infrastructure partagée ou des ressources appartenant à d’autres clients.
Nous vérifions ces règles pour chaque plateforme du périmètre pendant le cadrage, nous préparons la déclaration lorsqu’elle est nécessaire et nous documentons dans le rapport les vérifications écartées pour cette raison. Si votre environnement est administré par un intégrateur ou fourni en mode SaaS, son autorisation écrite est requise en plus de la vôtre.
07 Vos tests peuvent-ils perturber notre production ?
Le risque n’est jamais nul et nous ne prétendrons pas le contraire ; il se gère. Nous excluons par principe les tests de déni de service et les actions destructives, nous convenons d’une fenêtre d’intervention et d’un canal d’alerte direct, et les manipulations sensibles — modification d’une politique, création d’un rôle, suppression d’une ressource — sont annoncées avant d’être réalisées, ou rejouées dans un environnement de recette.
Toute vulnérabilité critique vous est signalée immédiatement, pendant le test, sans attendre la remise du rapport.
