L'étape de validation du CTEM dans AWS, avec des chiffres réels

Par l'équipe Pathbreak · 25 octobre 2026 · 6 min de lecture

Le continuous threat exposure management est une structure de programme en cinq étapes. Le cadrage décide quels systèmes font partie du programme. La découverte trouve les expositions qu'ils contiennent. La priorisation classe les expositions. La validation prouve quelles expositions classées un attaquant pourrait utiliser. La mobilisation fait corriger celles qui sont prouvées par les personnes qui en sont responsables. La définition est bien couverte ailleurs, donc cet article porte sur la quatrième étape, dans AWS, avec les chiffres d'un compte réel.

Là où les programmes AWS calent

La découverte dans AWS est bien couverte. Un CSPM ou un scanner produira des milliers de constats en un après-midi : buckets publics, politiques trop larges, clés inutilisées, chiffrement absent, rôles avec une confiance wildcard. La priorisation est aussi bien couverte, avec des scores de sévérité, des scores d'exploitabilité et des étiquettes de criticité des actifs qui trient la liste.

Le blocage survient à l'étape suivante. Une liste classée de 3,000 constats reste 3,000 constats, et le classement est une estimation. Un constat critique sur un rôle qu'une SCP a déjà cloisonné ne change rien. Un constat moyen sur un rôle qui fait confiance au compte d'un fournisseur pourrait être le chemin vers la production. Sans validation, l'équipe choisit son travail d'après un score, et ce score a été calculé sans lire l'autorisation qui décide si une attaque fonctionne.

À quoi ressemble la validation dans le plan de contrôle AWS

Dans AWS, les mouvements de l'attaquant sont des appels d'API. Chaque appel est autorisé ou refusé par un ensemble de documents qu'AWS évalue ensemble : les politiques d'identité de l'appelant, une éventuelle permission boundary, les service control policies de l'unité organisationnelle, la politique de confiance ou de ressource de la cible, et les conditions de chaque instruction. Valider signifie construire la chaîne candidate, puis résoudre ces documents pour chaque étape de la chaîne, comme AWS le ferait. Si chaque étape se résout en allow, le chemin est prouvé. Si une étape se résout en deny, le chemin est retiré de la liste.

Rien de tout cela n'exige d'exécuter quoi que ce soit. La preuve est le résultat de l'autorisation, et lire des politiques ne demande qu'un accès en lecture. C'est ce qui rend l'étape continue en pratique : elle peut tourner chaque jour sur chaque compte sans fenêtre de changement.

Les chiffres du compte de laboratoire

Le compte de laboratoire Pathbreak est l'environnement derrière les chiffres de la page d'accueil. Voici ce que l'étape de validation y a produit.

Ces chiffres montrent à quoi sert la validation. Des milliers de chemins candidats n'étaient pas des milliers de problèmes indépendants. La plupart passaient par les mêmes quelques rôles, de sorte qu'un petit nombre de changements, placés sur les bons principals, a brisé la plupart des chemins prouvés d'un coup. Une liste triée par sévérité aurait présenté le même compte comme 4,942 éléments de poids à peu près égal et envoyé l'équipe les corriger un par un.

Ce que la mobilisation attend de la validation

La cinquième étape échoue quand la personne responsable du rôle reçoit un constat sur lequel elle ne peut pas agir. La validation devrait transmettre trois choses. Le chemin prouvé, sous forme de chaîne avec chaque saut nommé, pour que le responsable voie pourquoi le rôle en fait partie. Le changement précis qui le brise : une instruction Deny, une condition iam:PassedToService, une politique de confiance plus étroite, une permission retirée, écrit comme le changement lui-même, prêt à appliquer. Et une confirmation : une fois le changement déployé, le chemin est réévalué et le résultat enregistré, de sorte que le ticket se ferme sur des preuves.

Dans le laboratoire, 81 pour cent des correctifs tenaient en une seule commande. Cela compte pour la mobilisation, parce qu'un changement d'une ligne dans une politique IAM passe en revue en quelques minutes, alors qu'une refonte de la hiérarchie des rôles part au trimestre suivant.

Rendre l'étape continue

Les comptes dérivent à chaque déploiement. Un nouveau rôle, une politique de confiance élargie, un pipeline qui reçoit iam:PassRole sur un wildcard, et un chemin fermé le mois dernier est de nouveau ouvert. L'étape de validation ne reste utile que si elle tourne selon un calendrier et rapporte ce qui a changé, pour que l'équipe voie les nouveaux chemins prouvés le jour où ils apparaissent et les correctifs confirmés qui ont depuis régressé.

La validation en lecture seule rend cela peu coûteux. Il n'y a ni agent, ni fenêtre de changement, ni risque pour la production venant du test lui-même, de sorte que des exécutions quotidiennes sur chaque compte sont la norme.

Quoi demander à une plateforme CTEM au sujet d'AWS

Résout-elle les SCP, les permission boundaries, les politiques de confiance et les clés de condition pour chaque étape d'un chemin ? Classe-t-elle selon ce qu'un chemin atteint, à travers les comptes ? Nomme-t-elle le changement qui brise chaque chemin, et confirme-t-elle ensuite le changement ? Peut-elle tourner chaque jour sans rien exécuter dans le compte ? Les réponses vous disent ce que la plateforme remettra à votre équipe à l'étape de mobilisation.

Pathbreak est conçu pour cette étape dans AWS. L'article sur l'AEV pour AWS couvre la méthode de validation plus en profondeur, et l'article analyse vs validation suit une chaîne d'atteignable à prouvée.

Questions fréquentes