La plus grande surface d'attaque aujourd'hui is your cloud.
Revue de configuration, d'identité et de cloisonnement sur AWS, Azure et GCP. La plupart des incidents dans le nuage ne commencent pas par une défaillance du fournisseur : ils commencent par une permission trop large, une ressource exposée sans le vouloir ou un secret oublié.
Dans le nuage, l'erreur est rarement celle du fournisseur
Le modèle de responsabilité partagée répartit le travail : le fournisseur sécurise l'infrastructure, la configuration vous revient. Les incidents se produisent dans votre moitié — un compartiment ouvert par commodité pour un essai, un rôle doté de droits d'administration accordés dans l'urgence, un réseau laissé sans cloisonnement parce que la livraison prenait du retard. Rien de cela n'apparaît comme vulnérabilité dans un balayage ; cela apparaît comme une décision de configuration que personne n'a réexaminée.
- Une permission accordée à titre temporaire n'est presque jamais retirée ensuite.
- Une ressource créée hors du processus standard n'hérite pas des protections que ce processus applique.
- Les secrets dans les variables d'environnement et les dépôts restent le chemin le plus court vers l'intérieur.
- Sans cloisonnement, un seul point d'appui atteint des comptes et des environnements censés être séparés.
What's included
Le périmètre ci-dessous est celui d'une mission type. Tout est ajustable pendant le cadrage, sans frais.
- Politiques larges et jokers dans les actions et ressources
- Rôles endossables et chaînes d'élévation de privilèges
- Clés d'accès de longue durée et rotation
- Fédération, fournisseur d'identité et sessions
- Comptes de service et permissions des charges de travail
- Séparation entre administration et exploitation
- Exposition publique d'objets et de conteneurs
- Chiffrement au repos et gestion des clés
- Politique d'accès et partage entre comptes
- Versionnage, rétention et protection contre la suppression
- Sauvegardes et essais de restauration
- Données sensibles hors du dépôt prévu
- Règles d'entrée ouvertes à tout internet
- Cloisonnement entre environnements et entre comptes
- Répartiteurs, passerelles et terminaison du trafic
- Services de gestion atteignables depuis l'extérieur
- Connectivité privée et appairage réseau
- Surface des conteneurs et de l'orchestration
- Piste d'audit active dans toutes les régions
- Rétention et protection des journaux eux-mêmes
- Couverture des événements du plan de contrôle
- Alerte sur les changements sensibles de permissions
- Centralisation dans un compte distinct
- Intégration à la supervision existante
- IAM, rôles, politiques et fédération d'identité
- VPC, groupes de sécurité, NACL, appairage et exposition publique
- S3, RDS, DynamoDB, Blob Storage et Cloud Storage
- EC2, Lambda, ECS, EKS, AKS et GKE
- CloudTrail, AWS Config, Microsoft Sentinel et Security Command Center
- Fournisseurs d'identité et SSO fédéré
Modalities
adjustable to scopeRevue de configuration
Lecture systématique de l'environnement depuis un rôle d'audit : identité, réseau, stockage, journalisation et protection des données, comparés à la documentation du fournisseur et à des références publiques.
Test de chemins
Plutôt que de lister la configuration, nous partons d'une position plausible — identifiant applicatif, conteneur compromis, utilisateur ordinaire — et vérifions jusqu'où elle porte dans l'environnement.
Revue continue et de l'infrastructure en tant que code
Analyse des gabarits et modules qui construisent l'environnement, complétée par un cycle de vérification récurrent. Corriger à la source empêche le même écart de revenir à chaque nouveau compte, projet ou déploiement.
Quand revoir l'environnement dans le nuage
La configuration dans le nuage change tous les jours, par de nombreuses mains. Certains moments concentrent le risque plus que d'autres.
Un environnement déplacé dans l'urgence traîne souvent des permissions larges accordées pour débloquer la bascule, avec la promesse de les resserrer plus tard — et ce plus tard arrive rarement.
Chaque équipe a créé le sien, chaque projet en a ouvert un autre. Sans standard central, les protections divergent et personne n'a la vue d'ensemble.
Une dépense anormale est parfois du gaspillage, parfois une ressource créée par quelqu'un qui n'aurait pas dû pouvoir la créer. Il vaut mieux savoir laquelle des deux.
La preuve des contrôles dans le nuage est désormais une rubrique obligatoire de la plupart des questionnaires. Mieux vaut trouver la lacune avant l'évaluateur.
How we conduct it
[pipeline]Relevé de l'environnement
Nous commençons par ce qui existe : comptes, abonnements, projets, régions actives et ressources en usage. Un environnement dans le nuage est presque toujours plus vaste que la documentation ne le laisse croire, et la ressource absente de l'inventaire est le plus souvent celle qui n'est pas protégée.
Analyse des identités et permissions
Nous cartographions qui peut faire quoi, y compris ce qui est possible par héritage et par endossement de rôle. Ce qui compte n'est pas la politique écrite mais la permission effective, généralement bien plus large que ne l'imagine qui l'a accordée.
Revue de configuration
Stockage, réseau, chiffrement, journalisation, sauvegardes et services gérés sont comparés à la documentation du fournisseur et à des références publiques de configuration sûre, en notant chaque écart et la raison pour laquelle il compte dans cet environnement.
Vérification de la portée
Nous simulons des positions de départ réalistes et mesurons la portée de chacune : ce qu'un identifiant applicatif peut lire, ce qu'atteint un conteneur compromis, s'il est possible de passer d'un environnement à un autre. C'est ce qui sépare une liste d'écarts d'un risque démontré.
Évaluation des journaux et alertes
Nous vérifions si les actions exécutées ont laissé une trace, si cette trace est protégée contre la suppression et si les changements sensibles de permissions déclenchent une alerte. Un environnement sans piste fiable ne permet pas d'enquêter après un incident.
Rapport et plan de correction
Les écarts sont regroupés par cause et non par ressource : dix éléments issus d'une même politique font une correction, pas dix. Chaque groupe reçoit des indications applicables et une suggestion pour empêcher la récidive à la source.
Références publiques qui encadrent le travail
La revue s'appuie sur la documentation des fournisseurs eux-mêmes et sur des références ouvertes de configuration, ce qui rend chaque point vérifiable de façon indépendante.
- CIS Benchmarks
- Les lignes de base de configuration pour AWS, Azure et GCP donnent une référence objective et vérifiable, point par point, pour comparer l'état de l'environnement.
- Well-Architected (pilier sécurité)
- Les documents d'architecture de chaque fournisseur décrivent la pratique qu'ils recommandent eux-mêmes, ce qui évite toute discussion sur l'origine d'une recommandation.
- Modèle de responsabilité partagée
- Il définit clairement où s'arrête la responsabilité du fournisseur et où commence la vôtre : exactement la frontière où survient la majorité des incidents.
- MITRE ATT&CK for Cloud
- La matrice propre au nuage nomme les techniques d'abus d'identité, de persistance et de collecte, et sert à évaluer la couverture de la détection.
- NIST SP 800-53
- Le catalogue de contrôles fait le pont entre le constat technique et le langage que la gouvernance et l'audit emploient déjà.
- Moindre privilège
- Ce n'est pas une norme mais le critère qui guide l'analyse des permissions : chaque identité ne devrait atteindre que le nécessaire, et tout écart demande une justification explicite.
- Azure Security Benchmark
- La ligne de base propre à Microsoft pour Azure, utile quand l'environnement est majoritairement Azure et que l'audit attend cette référence.
- CSA Cloud Controls Matrix
- La matrice de la Cloud Security Alliance cartographie les domaines de sécurité du nuage et renvoie à d'autres normes, ce qui aide quand le questionnaire client est long.
- ISO/IEC 27017 et 27018
- Les normes propres à la sécurité dans le nuage et aux données personnelles dans le nuage, fréquemment citées dans les contrats grands comptes.
- Correspondance avec le RGPD et PCI-DSS
- Lorsque l'environnement traite des données personnelles ou de porteur de carte, chaque constat est aussi rattaché à l'exigence correspondante, pour servir directement de preuve.
Deliverables
dual view · NDAInventaire de ce qui existe
La liste réelle des comptes, projets, régions et ressources actives. Pour beaucoup d'équipes c'est le premier livrable utile, car il révèle des environnements que personne ne se rappelait posséder.
Carte des permissions effectives
Qui atteint quoi en pratique, y compris par des chemins indirects d'héritage et d'endossement de rôle. C'est en général plus surprenant que la liste des configurations.
Écarts regroupés par cause
Les constats organisés par origine commune, chacun avec sa référence publique. Corriger la cause referme plusieurs points d'un coup et évite la récidive.
Chemins démontrés
Pour les risques les plus significatifs, le trajet concret : d'où il part, ce qu'il atteint et pourquoi cela compte. Cela transforme un écart de configuration en risque compréhensible.
Évaluation de la piste et de la détection
Ce qui a été enregistré des actions exécutées, ce qui était désactivé et quels changements sensibles passeraient aujourd'hui inaperçus.
Plan de correction priorisé
Un ordre de travail qui pèse risque et effort, en séparant ce qui se règle dans la configuration de ce qui doit changer dans l'infrastructure en tant que code pour ne pas revenir.
Frequently asked
Non. La revue s'effectue depuis un profil d'audit en lecture seule, que les trois fournisseurs proposent nativement. Pour la vérification de portée, nous convenons séparément d'identifiants spécifiques et limités, dont le périmètre et la durée sont définis par écrit.
Cela les complète plutôt que de les remplacer. Un outil de posture couvre le volume et suit l'écart en continu, ce qui a de la valeur. Ce qu'il ne fait pas, c'est enchaîner des permissions pour montrer qu'un identifiant applicatif atteint une donnée censée être isolée — et c'est cette démonstration qui change les priorités.
Oui. L'environnement mixte est le cas courant, et la comparaison entre fournisseurs révèle souvent une protection inégale : le même type de ressource verrouillé chez l'un et exposé chez l'autre, parce que des équipes différentes l'ont construit.
L'orchestration entre dans le périmètre : rôles et liaisons d'accès, contexte de sécurité des conteneurs, politique réseau entre services, exposition du plan de contrôle, gestion des secrets et lien entre l'identité du cluster et celle du nuage — un chemin d'élévation fréquent.
L'environnement qui sert la production, au minimum. Les comptes de développement et de recette méritent d'être inclus lorsqu'ils disposent d'un chemin réseau ou d'identité vers la production, ce qui est plus courant qu'on ne le suppose — et c'est justement là que la protection est la plus relâchée.
En corrigeant à la source. Quand l'environnement naît d'une infrastructure en tant que code, la correction va dans le module et vaut pour tout déploiement futur. Pour chaque groupe d'écarts, le rapport indique s'il doit être traité sur la ressource ou dans le gabarit qui la crée.
Oui. Chaque point porte sa référence publique et la preuve de la configuration observée, sous une forme qu'un auditeur peut vérifier de façon indépendante sans refaire l'analyse.
Prêt à découvrir vos failles ?
Premier appel de scoping gratuit et couvert par NDA. En 48 heures vous recevez proposition technique, portée et calendrier. Sans formulaires bureaucratiques.