Aller au contenu

Blog 11 octobre 2026 3 min de lecture

Un chemin d’attaque cloud, c’est quoi, et comment on le note sur 100

En bref

Un chemin d’attaque est une suite de maillons anodins pris un à un : une adresse publique, une version vulnérable, un rôle trop large, une base qui contient des données personnelles. Ctadel les relie dans un graphe de vos clouds et note chaque chemin de 1 à 100 d’après trois facteurs publiés : l’exposition, l’exploitabilité et la valeur de la cible.

Une équipe sécurité reçoit chaque semaine des centaines de constats de configuration. Pris un par un, presque aucun n’est grave. Le problème, c’est quand quatre d’entre eux s’alignent.

Des maillons anodins, un chemin dangereux

Prenez un serveur web avec une adresse publique. Seul, c’est normal. Ce serveur embarque une bibliothèque Java avec une version vulnérable à Log4Shell. Seul, c’est une mise à jour à planifier. Ce serveur porte un rôle qui peut lire une base de données. Seul, c’est son métier. Cette base contient des numéros de compte et des adresses. Seule, c’est une base clients comme une autre.

Alignés, ces quatre maillons forment un chemin qu’un attaquant suit en une soirée : il atteint le serveur depuis internet, exploite la vulnérabilité, récupère l’identité du serveur, et lit la base.

C’est ce que Ctadel appelle une combinaison toxique. Elle n’existe dans aucun scanner pris isolément : le scanner de configuration voit l’adresse publique, celui des vulnérabilités voit la version, celui des identités voit le rôle, celui des données voit les numéros de compte. Il faut un graphe qui les relie.

Le graphe, et deux façons de le parcourir

Tout ce que Ctadel lit dans vos comptes, et dans vos dépôts de code, rejoint un même graphe : les ressources, leurs relations réelles (ce serveur porte ce rôle, ce rôle lit ce bucket) et les constats de chaque scanner, attachés à la ressource qu’ils concernent.

Deux mécanismes produisent les chemins.

  • Des chaînes écrites à la main décrivent des combinaisons connues : une instance publique qui livre son rôle sans jeton, un rôle qui lit un bucket classé données personnelles. Chaque maillon est décrit par un concept (« public », « administrateur », « données sensibles ») qui se résout en règles réelles du catalogue.
  • Un moteur de chemins calculés part de chaque point d’entrée joignable depuis internet, suit les faiblesses, les identités et les accès, et s’arrête sur les cibles : données classées sensibles, identité administratrice, clé de chiffrement, cluster Kubernetes. Il n’a besoin d’aucune règle préécrite.

Le même chemin retrouvé au parcours suivant reste le même constat, avec son historique. Il se ferme quand un maillon disparaît : la version corrigée, le rôle réduit, l’adresse retirée. N’importe lequel suffit.

Pourquoi un score de 1 à 100

La sévérité d’un constat vient de sa règle. Elle ne dit rien de la situation réelle de la ressource. Un chemin d’attaque, lui, porte un score de risque de 1 à 100 qui combine trois facteurs.

  1. L’exposition : la première ressource est-elle joignable depuis internet, directement, derrière un équilibreur de charge, ou par un service Kubernetes exposé.
  2. L’exploitabilité : la faiblesse est-elle exploitable à distance. Pour une vulnérabilité, la probabilité suit la publication EPSS, relevée quand la CVE figure au catalogue des vulnérabilités exploitées ou sert à un rançongiciel.
  3. La cible : contient-elle des données classées sensibles, une identité administratrice, une clé, un plan de contrôle.

Pour un chemin calculé, le score est la probabilité du chemin multipliée par la valeur de sa cible, ramenée sur 100. Chaque étape a une probabilité fixe, la même pour tous les clients, publiée dans la documentation des chemins d’attaque pour qu’un auditeur puisse la lire et la contester.

Le résultat trie la page des combinaisons toxiques. Le chemin de l’exemple ci-dessus sort à 96. Une clé d’accès valide trouvée dans un bucket public sort à 81. Un chemin dont l’entrée est un point d’accès de cluster privé et la cible une base non classée descend bien en dessous.

Ce que ça change pour l’équipe

Le lundi matin, la question n’est plus « lesquels de nos huit cents constats traiter ? » mais « lesquels de nos douze chemins casser en premier ? ». Et pour chaque chemin, la réponse est dans le panneau : le maillon le moins cher à retirer, la commande ou la ligne Terraform qui le retire, et le ticket qui suit la correction.

Le score du tableau de bord suit la même logique : il ne compte que les combinaisons toxiques ouvertes, pondérées par sévérité et rapportées au nombre de ressources. Un périmètre sans aucun chemin vaut 100, même avec des constats de configuration ouverts. C’est volontaire : c’est le chemin qui blesse, pas le constat. Le détail du calcul est dans Sévérité et score.

Vous pouvez voir des chemins réels sur la démonstration en ligne, ouverte à tous.

Voyez-le sur vos comptes

La démonstration en ligne est ouverte à tous, sur des données fictives. Pour une instance sur vos propres comptes, demandez une démonstration.