AWS · Azure · Google Cloud
Test d’intrusion cloud sur AWS, Azure et Google Cloud
Dans le cloud, le test d’intrusion porte moins sur des CVE que sur des droits. Un rôle trop permissif, un bucket public et un secret oublié dans une variable d’environnement suffisent à ouvrir l’ensemble de votre plateforme.
Durée type : 1 à 3 semaines selon le nombre de comptes et d’abonnements.
Périmètre
Ce que nous testons dans votre cloud
Nous combinons revue de configuration et exploitation réelle des chemins d’attaque identifiés.
IAM et chemins d’élévation
Rôles, politiques et relations d’approbation entre comptes. Nous recherchons les enchaînements permettant à une identité peu privilégiée d’atteindre un rôle d’administration.
Stockage exposé
Buckets S3, conteneurs Blob et buckets GCS accessibles publiquement ou via une politique trop large, y compris les sauvegardes, les exports et les journaux applicatifs oubliés.
Secrets et variables d’environnement
Clés d’API, jetons et identifiants en clair dans les fonctions serverless, les images de conteneurs, les modèles d’infrastructure et les pipelines de déploiement.
Réseau et exposition
Groupes de sécurité permissifs, services d’administration exposés à Internet, points de terminaison privés mal cloisonnés et appairage entre environnements de production et de test.
Kubernetes et conteneurs
RBAC du cluster, conteneurs privilégiés, jetons de compte de service montés par défaut, échappement de conteneur et accès au service de métadonnées de l’instance.
Chaîne CI/CD
Droits des exécuteurs de pipeline, secrets accessibles aux branches non protégées, dépendances non vérifiées et possibilité d’injecter du code dans un artefact déployé en production.
Conformité
Le cloud vu par les régulateurs francophones
L’hébergement mutualisé déplace la charge de la preuve, il ne la supprime pas.
SecNumCloud
Le référentiel de qualification de l’ANSSI pour les services cloud fixe des exigences élevées de cloisonnement, de journalisation et de maîtrise des accès d’administration. Nos tests vérifient concrètement ces points sur votre propre configuration.
HDS
Héberger des données de santé en France impose de recourir à un hébergeur certifié HDS. La certification couvre l’hébergeur, pas votre application : le cloisonnement des dossiers et la gestion de vos droits IAM restent votre responsabilité, et c’est ce que nous testons.
RGPD et transferts hors UE
Nous documentons les régions réellement utilisées, les services activés par défaut dans d’autres zones et les flux sortants vers des sous-traitants tiers, éléments indispensables à votre registre des traitements.
NIS2
La directive vise explicitement la sécurité de la chaîne d’approvisionnement. Un rapport de test d’intrusion cloud documente vos dépendances, la maîtrise de vos accès d’administration et le traitement des vulnérabilités identifiées.
Déroulé
Une mission cloud en cinq temps
- 01
Inventaire
Comptes, abonnements, projets, régions et services activés. Nous établissons la surface réelle, souvent plus large que celle documentée en interne.
- 02
Revue de configuration
Analyse des politiques IAM, du chiffrement, de la journalisation et de l’exposition réseau, à partir d’un accès en lecture dédié à la mission.
- 03
Exploitation
Démonstration des chemins d’attaque : élévation de privilèges, accès à des données d’un autre environnement, prise de contrôle d’un pipeline.
- 04
Rapport
Cartographie des chemins d’attaque, criticité CVSS, correctifs recommandés et priorisation par impact métier réel.
- 05
Retest
Vérification gratuite et illimitée des correctifs, avec mise à jour du statut de chaque chemin d’attaque identifié.
Questions fréquentes
Test d’intrusion cloud : vos questions
À voir également
Vérifions qui peut vraiment accéder à votre cloud
Décrivez vos comptes et vos environnements : nous établissons un périmètre et un devis ferme.
Demander un devis