Test d'intrusion de sécurité cloud
Les erreurs de configuration n'apparaissent pas sur les listes de contrôle de conformité. Les attaquants les trouvent quand même.
Les environnements cloud introduisent une classe de risque de sécurité entièrement différente, que les cadres de conformité n'ont pas été conçus pour détecter et à laquelle l'expertise de sécurité sur site ne se transpose pas directement. Les rôles IAM mal configurés, les buckets de stockage exposés, les identifiants fuités dans les pipelines CI/CD, les comptes de service surprivilégiés et les chemins de mouvement latéral via les services cloud natifs sont les conditions que les attaquants réels exploitent systématiquement.
Evaluris évalue votre posture cloud du point de vue d'un attaquant sur AWS et Azure, identifiant chaque chaîne d'erreurs de configuration exploitable, chemin d'escalade de privilèges et scénario de compromission inter-comptes qui représente un risque métier réel.
Le déficit de sécurité cloud
La plupart des organisations pensent que leur environnement cloud est sécurisé parce qu'elles ont passé un audit de conformité ou parce que leur fournisseur cloud indique que le modèle de responsabilité partagée est traité. Aucun de ces éléments ne signifie que votre configuration est sécurisée.
Le modèle de responsabilité partagée signifie que le fournisseur cloud sécurise l'infrastructure. Vous êtes responsable de tout ce que vous configurez par-dessus, et les configurations par défaut de la plupart des services cloud sont permissives, pas restrictives. Les organisations qui ont migré rapidement vers le cloud, celles qui ont fait croître leur empreinte cloud de manière organique, et celles où les développeurs ont un accès direct au cloud ont presque toujours des erreurs de configuration exploitables qui n'ont jamais été intentionnellement introduites et n'ont jamais été testées.
Le vecteur d'attaque initial le plus courant dans les compromissions cloud n'est pas un exploit zero-day. C'est une permission mal configurée, une clé API exposée ou un bucket de stockage public oublié.
Méthodologie
Découverte et énumération des actifs cloud
Inventaire complet des actifs cloud dans le périmètre de la mission : instances de calcul, buckets de stockage, bases de données, fonctions serverless, registres de conteneurs, passerelles API, utilisateurs IAM, rôles et politiques. Identification des ressources exposées sur internet et des configurations d'accès public.
Analyse IAM et des permissions
Analyse des documents de politique pour les rôles surprivilégiés, chemins d'escalade de privilèges via IAM, analyse des chaînes d'assume-role, configurations d'accès inter-comptes, lacunes des politiques de contrôle de service et faiblesses des limites de permissions.
Tests d'exposition du stockage et des données
Tests d'accès public aux buckets S3 (AWS) et Blob storage (Azure), abus d'URL pré-signées, mauvaise configuration des politiques de buckets et analyse des politiques de cycle de vie pour l'exposition de données sensibles.
Découverte d'identifiants et de secrets
Scan de secrets dans les pipelines CI/CD, exposition de variables d'environnement dans les fonctions serverless, abus du service de métadonnées d'instances EC2 (IMDSv1), identifiants codés en dur dans les images de conteneurs et clés API exposées dans les dépôts de code source.
Mouvement latéral et escalade de privilèges
Chaînes d'escalade de privilèges IAM, abus de rôles EC2, abus de fonctions Lambda, chemins d'évasion de conteneurs, mouvement latéral inter-services et identification de mécanismes de persistance.
Configuration réseau et périmètre
Mauvaise configuration des groupes de sécurité, exposition de sous-réseaux publics, abus de confiance de peering VPC, analyse des règles d'équilibreur de charge et tests de contournement du WAF.
Ce que nous testons
- Environnements Amazon Web Services (AWS)
- Environnements Microsoft Azure
- Configurations, rôles et politiques IAM
- Services de stockage (S3, Azure Blob, EFS, Azure Files)
- Fonctions serverless (Lambda, Azure Functions)
- Services de conteneurs (ECS, EKS, AKS, ACR, ECR)
- Pipelines CI/CD (GitHub Actions, Azure DevOps, CodePipeline)
- Passerelles API et architectures de microservices
- Configuration réseau (VPC, groupes de sécurité, NACL, NSG)
- Entra ID (Azure AD) et AWS IAM Identity Center
Alignement de conformité
| Cadre | Exigence |
|---|---|
| ISO 27001:2022 | A.8.8, gestion des vulnérabilités techniques ; A.5.23, sécurité de l'information pour les services cloud |
| PCI DSS v4.0.1 | Exigences de test pour les environnements de données de cartes hébergés dans le cloud |
| DORA Art. 25 | Tests d'infrastructure TIC incluant les environnements cloud |
| CSA Cloud Controls Matrix | Évaluation technique de sécurité alignée sur les domaines CCM |
| NIS2 Art. 21 | Obligations de sécurité et de résilience de l'infrastructure cloud |
| CBUAE / SAMA | Infrastructure financière hébergée dans le cloud incluse dans le périmètre VAPT |
Livrables
- Inventaire des actifs cloud, carte complète des ressources découvertes, points d'exposition et configurations d'accès
- Rapport des chemins d'attaque IAM, chaînes d'escalade de privilèges et chemins de mouvement latéral documentés visuellement
- Synthèse exécutive, constats classés par risque pour la posture de sécurité cloud
- Rapport technique, preuves complètes d'exploitation, scoring CVSS et recommandations de remédiation cloud natives
- Notes de remédiation Terraform / IaC, recommandations de correction exprimées en termes d'infrastructure-as-code lorsque applicable
- Fenêtre de retest, vérification post-remédiation
Prêt à cadrer cette mission ?
Parlez-nous de votre environnement, de vos exigences réglementaires et de votre calendrier. Nous alignerons méthodologie, périmètre et exigences de preuves avant le début des tests.