Pentest Cloud — AWS, Azure & GCP

Un audit cloud (Prowler, ScoutSuite) analyse la configuration par rapport aux CIS Benchmarks de manière passive. Un pentest cloud va plus loin : il exploite réellement les misconfigurations pour démontrer l'impact concret — escalade IAM vers admin, extraction de secrets depuis le metadata service, accès non autorisé aux données. Notre prestation inclut les deux approches : audit de configuration + exploitation active.

Oui. AWS, Azure et GCP autorisent les tests d'intrusion sur vos propres ressources sans notification préalable (depuis 2019 pour AWS). Les seules restrictions concernent le déni de service (DDoS) et le test de l'infrastructure du fournisseur lui-même. Nous respectons scrupuleusement les conditions d'utilisation de chaque CSP et n'effectuons jamais d'actions pouvant impacter la disponibilité de vos services.

Absolument, c'est même notre spécialité. Les environnements multi-cloud (AWS + Azure, Azure + GCP, etc.) présentent des risques supplémentaires : identités fédérées cross-cloud, interconnexions réseau, driften de configuration entre CSP. Nous testons chaque CSP individuellement puis les interactions entre eux pour identifier les chemins d'escalade cross-cloud.

Comptez 15 à 25 jours ouvrés selon le nombre de CSP et la complexité de l'environnement. Pour un seul CSP (AWS ou Azure) avec 1-2 comptes, 15 jours suffisent. Pour un multi-cloud avec Kubernetes, serverless et multiples comptes, prévoyez 20-25 jours. Le délai inclut la reconnaissance, l'exploitation, le rapport et la restitution. Le retest à 3 mois est inclus.

Oui, le pentest cloud répond directement aux exigences SOC 2 (Trust Services Criteria CC7.1 - System Operations) et ISO 27001 (A.8.8 - Gestion des vulnérabilités techniques, A.8.34 - Tests d'intrusion). Le rapport est formaté pour servir de preuve d'audit. Pour SOC 2 Type II, le pentest cloud est quasi-obligatoire pour les éditeurs SaaS.

En boîte grise (recommandé), vous créez un utilisateur IAM/Entra ID avec des permissions limitées (lecture seule sur quelques services) pour simuler un attaquant qui a obtenu des identifiants. En boîte noire, nous testons uniquement la surface externe. En boîte blanche, nous disposons d'un accès lecture complète pour maximiser la couverture. Nous recommandons la boîte grise pour un équilibre optimal.

Oui. Les pipelines CI/CD sont un vecteur d'attaque majeur : un accès au pipeline permet souvent d'escalader vers l'infrastructure cloud entière. Nous testons la sécurité des pipelines (GitHub Actions, GitLab CI, Azure DevOps), l'exposition du state Terraform (S3, Azure Blob), les secrets dans les variables d'environnement et les permissions des service accounts utilisés par l'IaC.