Tokens, API, workloads : les identités invisibles qu’il faut cartographier

Quand on parle d’identité dans le système d’information, on pense d’abord aux utilisateurs : collaborateurs, administrateurs, prestataires et comptes privilégiés.

Pourtant, une part croissante des accès n’est déclenchée par aucun humain au moment où elle se produit. Un microservice appelle une API, un pipeline déploie une application, une fonction serverless accède à un stockage, un agent interroge un service cloud.

Ces composants disposent eux aussi d’une identité — ou au minimum d’un moyen de prouver qui ils sont et ce qu’ils ont le droit de faire.

Le NIST vient de finaliser l’IR 8587 consacré à la protection des tokens et assertions. La version finale ajoute explicitement les scénarios d’identité de workload et insiste sur l’usage de jetons de courte durée plutôt que sur des secrets statiques.12

Pour l’architecture du SI, la conséquence est simple : cartographier les comptes humains ne suffit plus à cartographier la confiance.

Une application peut avoir une identité sans avoir de mot de passe

Une identité technique ne ressemble pas nécessairement à un compte de service historique.

Elle peut prendre la forme d’un rôle cloud assumé temporairement, d’un certificat, d’un jeton OAuth, d’une identité Kubernetes, d’une identité managée ou d’une assertion émise par un fournisseur d’identité.

Dans tous ces cas, la question reste la même :

quel composant peut prouver une identité, auprès de qui, et pour obtenir quel accès ?

Le NIST distingue notamment les rôles du fournisseur d’identité, du serveur d’autorisation et des systèmes qui consomment les tokens ou assertions.1 Les recommandations sur la fédération décrivent de leur côté les relations entre fournisseurs d’identité et parties utilisatrices.3

Ce sont des relations d’architecture, pas seulement des paramètres IAM.

Le chemin à représenter dépasse le compte de service

Une cartographie traditionnelle peut montrer :

application → API → base de données

Une cartographie de confiance ajoute :

workload → fournisseur d’identité → token → API → privilège → ressource

Elle permet de poser des questions différentes.

Qui émet le token ? Quelle identité peut le demander ? À quelle audience est-il destiné ? Combien de temps reste-t-il valide ? Quel système vérifie sa signature ? Quel privilège obtient-il ? Quelle ressource devient accessible ?

Deux applications qui communiquent peuvent ainsi dépendre d’un troisième composant invisible dans une vue de flux : l’autorité qui établit la confiance entre elles.

Un token est une dépendance temporaire, mais critique

Un secret statique peut rester valide pendant des mois. Un token peut ne vivre que quelques minutes.

Cela ne le rend pas secondaire.

Pendant sa durée de validité, il peut porter une autorisation suffisante pour appeler une API, lire des données ou modifier une ressource. L’IR 8587 traite précisément des risques de falsification, vol et mauvais usage des tokens et assertions, ainsi que de leur vérification, de la gestion des clés et de leur cycle de vie.1

La durée de vie devient donc un attribut d’architecture utile.

À une relation A peut accéder à B, il faut parfois ajouter :

par quel mécanisme, avec quel jeton, pour quelle audience, pendant combien de temps et avec quelle possibilité de révocation ?

Les secrets statiques masquent souvent la vraie dépendance

Une clé API enregistrée dans une variable d’environnement ou un secret CI/CD semble être un simple paramètre technique.

Mais elle matérialise une relation de confiance durable.

Si dix workloads utilisent le même secret, ils partagent aussi une partie de leur risque. Si ce secret donne un accès étendu, la compromission d’un seul workload peut ouvrir un chemin vers d’autres ressources.

La recommandation du NIST en faveur de tokens courts pour les identités de workload pousse à déplacer le raisonnement :

secret possédé → identité prouvée → autorisation temporaire.2

Pour la cartographie, cela signifie qu’il faut documenter l’émetteur et la relation de confiance, pas seulement l’emplacement où un secret est stocké.

Le rayon de compromission d’une identité machine

Une identité technique devient particulièrement importante lorsqu’elle est réutilisée ou très privilégiée.

Prenons un service A autorisé à obtenir un token pour une API B. L’API B peut ensuite écrire dans une base C. Un pipeline D possède par ailleurs le droit de déployer une nouvelle version du service A.

La vue applicative montre :

A → B → C

La vue de confiance révèle :

IdP → identité A → token → B → privilège → C

et :

identité du pipeline D → plateforme de déploiement → A

La compromission du pipeline peut donc conduire indirectement jusqu’à C, même s’il n’existe aucun flux réseau direct entre D et la base.

C’est précisément l’intérêt d’une cartographie des relations de confiance : faire apparaître les chemins de pouvoir qui ne sont pas des chemins réseau.

Cas pratique : un microservice dans Kubernetes

Imaginons une application de commande composée de plusieurs microservices.

Le service de facturation doit appeler une API de paiement. Plutôt que de stocker une clé permanente, le workload présente son identité à un fournisseur de confiance et obtient un token court destiné à l’API.

La chaîne devient :

pod → identité du workload → fournisseur d’identité → token → API paiement → autorisation

Pour documenter correctement cette relation, six informations sont utiles :

1. Workload — quel composant demande l’accès ?
2. Émetteur — qui atteste son identité ou délivre le token ?
3. Audience — quel service doit accepter le token ?
4. Privilège — quelles opérations deviennent possibles ?
5. Durée — combien de temps l’autorisation reste-t-elle exploitable ?
6. Révocation/rotation — comment couper la relation en cas d’incident ?

On obtient alors une cartographie exploitable aussi bien pour l’architecture que pour la réponse à incident.

La fédération crée des frontières de confiance

Les recommandations NIST SP 800-63C-4 rappellent qu’une fédération permet à un fournisseur d’identité de fournir des informations d’authentification à des parties administrées séparément.3

Dans une entreprise, ces frontières peuvent traverser plusieurs environnements : cloud public, SaaS, cluster Kubernetes, API internes ou services d’un partenaire.

Une cartographie utile doit donc distinguer :

qui administre le composant

de :

à quelle autorité d’identité le composant fait confiance.

Un service SaaS peut être externe tout en dépendant de l’IdP interne. Une API interne peut accepter une identité issue d’un cloud. Un workload peut obtenir temporairement un rôle dans un autre environnement.

La frontière organisationnelle et la frontière de confiance ne coïncident pas toujours.

Authentification et autorisation ne doivent pas être confondues

Les Digital Identity Guidelines du NIST séparent clairement les mécanismes d’authentification et les mécanismes de fédération/assertion.34

Pour une cartographie, cette distinction évite une erreur fréquente : considérer qu’un composant « utilise l’IdP » sans préciser ce que cette relation permet réellement.

S’authentifier établit une identité.

Obtenir un token ou une assertion transporte une information de confiance.

Être autorisé détermine l’action permise sur la ressource.

Les trois relations peuvent être représentées séparément.

Une vue « identité machine et confiance »

Pour les architectures cloud et distribuées, une vue dédiée peut regrouper :

workloads et services techniques

fournisseurs d’identité et serveurs d’autorisation

identités managées, rôles et comptes de service

tokens, assertions et certificats utilisés comme mécanismes de confiance

API et ressources cibles

privilèges associés

durées de vie et mécanismes de révocation

L’objectif n’est pas de transformer la cartographie du SI en coffre-fort à secrets. Les valeurs de tokens, clés ou mots de passe n’ont évidemment pas à y figurer.

Ce qui compte est de documenter l’existence de la relation, son autorité, sa portée et son rayon de compromission.

Sept questions à poser à son architecture

1. Quelles applications et workloads possèdent une identité propre ?
2. Quels composants peuvent émettre des tokens ou assertions acceptés dans le SI ?
3. Quelles API acceptent ces identités et avec quels privilèges ?
4. Où utilisons-nous encore des secrets statiques pour des communications machine-à-machine ?
5. Plusieurs workloads partagent-ils la même identité ou le même secret ?
6. Pouvons-nous révoquer rapidement une relation de confiance compromise ?
7. Pouvons-nous visualiser le rayon de compromission d’une identité technique ?

Cartographier la confiance, pas seulement les utilisateurs

Les identités humaines restent essentielles. Mais elles ne représentent qu’une partie des acteurs capables d’agir dans un SI moderne.

Plus l’architecture devient distribuée, automatisée et cloud, plus des logiciels obtiennent eux-mêmes des autorisations pour agir sur d’autres logiciels.

La cartographie doit suivre cette évolution.

Un inventaire sait qu’une API existe. Une cartographie de confiance doit aussi pouvoir expliquer qui peut obtenir le droit de l’appeler, par quel mécanisme et jusqu’où cet accès peut conduire.