Pentest GCP
Test d'intrusion offensif de vos environnements Google Cloud. Nos experts reconstituent des chemins d'attaque réels : élévation de privilèges IAM, impersonation de service account, SSRF sur le serveur de métadonnées Compute Engine et compromission GKE. Chaque exploitation est menée dans le cadre d'un mandat signé, avec autorisation écrite et dans le respect des règles d'engagement de Google Cloud.
2-4 semaines
Rapport détaillé
AWS · Azure · GCP
Exploitation contrôlée, dans le cadre d'un mandat signé.
Ce que nous analysons
Une couverture complète pour identifier toutes les vulnérabilités
Élévation de Privilèges IAM
Recherche des chemins d'escalade GCP : abus de iam.serviceAccounts.actAs, impersonation via generateAccessToken, signJwt et signBlob, rôle serviceAccountTokenCreator et setIamPolicy jusqu'à l'obtention de roles/owner.
Exposition Cloud Storage
Détection et exploitation des buckets GCS ouverts à allUsers ou allAuthenticatedUsers, des ACL héritées, de l'accès uniforme désactivé et des objets sensibles exfiltrables (clés, sauvegardes, secrets).
SSRF & Vol de Jeton Metadata
Exploitation de SSRF applicatives pour interroger metadata.google.internal, voler le jeton de la service account par défaut de Compute Engine et abuser de scopes cloud-platform trop larges attachés aux instances.
GKE Offensif
Attaque des clusters GKE : Workload Identity mal configurée, RBAC Kubernetes permissif, API server exposé, accès au serveur de métadonnées depuis les pods et pivots vers les service accounts de nœuds.
Cloud Functions & Cloud Run
Abus des identités d'exécution : déploiement ou modification d'une fonction pour usurper une service account privilégiée, endpoints invoqués sans authentification (allUsers en rôle invoker) et secrets injectés en variables d'environnement.
Mouvement Latéral & Hiérarchie
Pivots à travers la hiérarchie des ressources (organisation, folders, projets), contournement des org policies, escalade horizontale inter-projets et exploitation des clés JSON de service account exposées dans le code ou la CI/CD.
Pourquoi choisir Cyvex ?
Notre expertise et notre méthodologie éprouvée vous garantissent des résultats concrets et actionnables.
Multicloud
AWS, Azure & GCP
Notre processus
Une méthodologie structurée pour des résultats optimaux
Cadrage & Autorisation
Définition du périmètre (organisation, folders, projets, service accounts), signature du mandat et de l'autorisation écrite, validation des règles d'engagement Google Cloud et mise en place d'un canal de communication.
Reconnaissance
Énumération des bindings IAM et des rôles, inventaire des ressources GCS, Compute Engine, GKE, Cloud Functions et Cloud Run, cartographie de la hiérarchie et recherche de clés de service account exposées.
Exploitation
Élévation de privilèges (actAs, impersonation), SSRF vers le serveur de métadonnées, mouvement latéral inter-projets et démonstration contrôlée de l'atteinte de roles/owner ou de l'exfiltration de données.
Restitution
Présentation des chaînes d'attaque documentées, preuves reproductibles, matrice de risques et plan de remédiation priorisé, avec débrief technique et synthèse pour la direction.
Livrables inclus
Prêt à sécuriser votre cloud ?
Contactez-nous pour discuter de vos besoins et obtenir un devis personnalisé.
Demander un devis gratuitServices complémentaires
Questions fréquentes
Comment encadrez-vous l'autorisation et le périmètre d'un pentest GCP ?
Chaque test d'intrusion est réalisé exclusivement dans le cadre d'un mandat signé, avec une autorisation écrite formelle et un périmètre défini au cadrage (organisation, folders, projets, service accounts concernés). Nous respectons les règles d'engagement de Google Cloud : les tests portent uniquement sur vos propres projets. Google n'exige pas de notification préalable pour tester vos ressources, mais sa politique d'usage acceptable s'applique et tout test de déni de service est exclu.
Un test d'intrusion GCP peut-il perturber notre production ?
Non. Nous pratiquons une exploitation contrôlée : la compromission est démontrée par une preuve reproductible, sans dégrader la disponibilité de vos services. Les attaques de déni de service (DoS/DDoS) sont d'ailleurs interdites par les règles d'engagement de Google Cloud. Selon votre tolérance au risque, nous travaillons sur un projet de test dédié, sur des fenêtres horaires convenues et avec un canal de communication direct pour suspendre immédiatement toute action sensible.
Combien de temps dure un pentest GCP et comment est-il tarifé ?
La durée dépend du périmètre : nombre de projets et de folders, ampleur des bindings IAM, présence de clusters GKE, de Cloud Functions ou de Cloud Run. Un périmètre mono-projet se teste généralement en 1 à 2 semaines, une organisation multi-projets en 2 à 4 semaines. La prestation est établie au forfait sur la base du périmètre défini au cadrage, avec un devis prévisible et sans coût caché. En tant qu'éditeur français indépendant, nous privilégions une tarification lisible.
Quelles techniques d'attaque GCP testez-vous en priorité ?
L'élévation de privilèges IAM est centrale : abus de iam.serviceAccounts.actAs, impersonation via generateAccessToken, signJwt ou signBlob, exploitation du rôle roles/iam.serviceAccountTokenCreator et modification de policy via setIamPolicy pour atteindre roles/owner. Nous testons aussi le vol du jeton de la service account par défaut de Compute Engine via SSRF sur metadata.google.internal, les buckets Cloud Storage exposés (allUsers/allAuthenticatedUsers), la Workload Identity et le RBAC GKE, ainsi que les clés JSON de service account laissées dans le code ou la CI/CD.