Le courtage d'identité pour les machines ? Mais pourquoi donc ?

Si les meilleures pratiques imposent aux utilisateurs de s'authentifier via SSO, que ce soit pour le VPN ou une application d'entreprise, pourquoi devrait-il en être autrement pour les machines ?

S’agissant de la gestion des secrets, une des questions que l’on me pose le plus souvent est la suivante : en quoi Hashicorp Vault diffère-t-il d’un keystore ? Est-il similaire à AWS Secrets Manager ou à Azure Key Vault, ou s’agit-il d’une solution qui ne dépend pas du cloud, lorsqu’il s’agit de la gestion de secrets statiques ?

Plutôt semblable

Les keystores statiques permettent généralement de stocker des secrets de manière sécurisée et de les récupérer via une API. Tous les principaux fournisseurs de services de cloud proposent leur propre système de stockage de secrets et il existe plusieurs solutions agnostiques sur le marché. Dans le cas du stockage de secrets par CSP, l’authentification est généralement basée sur l’identité native fournie par le cloud, telle que l’identité d’une machine virtuelle dans Azure ou un rôle IAM dans AWS. 

D’autre part, les keystores autonomes s’appuient souvent sur un ensemble prédéfini de certificats ou de challenges, y compris les liaisons IP, pour authentifier et autoriser fréquemment un utilisateur de manière très transactionnelle.

Ou plutôt différent

Bien que Vault soit certainement capable d’agir en tant que gestionnaire de secrets et de gérer des relations individuelles, le principal élément distinctif de Vault est sa capacité de courtage d’identité. Le courtage d’identité permet d’assurer que l’identité d’origine peut être utilisée dans tous les environnements, que ce soit sur site ou sur différents clouds, sans dépendre d’une IP spécifique ou de l’établissement d’un challenge initial.

Le courtage d’identité permet de gagner en flexibilité, en authentification sécurisée à tous les niveaux de la pile d’applications et en observabilité entre les systèmes. Le courtage permettant la mise en relation d’entités multiples, la complexité opérationnelle est réduite car il y a moins de relations individuelles à gérer, ce qui génère une valeur ajoutée car la priorité est à l’authentification et à l’autorisation déclaratives et relationnelles.

En fait, le courtage d’identité, c’est quoi ?

Le courtage est un concept assez courant dans le monde des affaires. Ainsi, un particulier peut faire appel à un courtier financier pour accéder à un portefeuille d’actifs ; les sinistres d’assurance maladie peuvent être traités et agrégés par un courtier pour le compte d’un assureur pour permettre à ce dernier de regrouper ses paiements. Le concept de courtage d’identité suit un schéma similaire.

L’utilisation la plus courante du courtage d’identité est l’authentification unique (SSO), offrant aux utilisateurs humains la possibilité de se connecter à un point unique qui fédère à son tour cet accès à travers plusieurs systèmes d’authentification. Le SSO permet à l’utilisateur de s’authentifier à un point unique qui propage ensuite son identité à travers différents systèmes en garantissant l’authentification et l’autorisation correctes de l’utilisateur final, un peu comme un individu s’adressant à un courtier financier pour obtenir un portefeuille diversifié de produits.

On a tendance, cependant, à oublier que l’identité des machines doit elle aussi être gérée, de la même manière qu’on utilise le SSO pour l’identité humaine. Comme les microservices continuent d’être au cœur de la conception architecturale, il est de plus en plus nécessaire pour les applications d’accéder à de multiples ressources. Par exemple, une application qui a besoin d’accéder à une base de données, à SSH et à DataDog, peut s’appuyer sur un courtage d’identité pour que ces ressources soient gérées par un seul mécanisme d’authentification. Dans le cas de ressources partagées, il est encore plus crucial de disposer d’une solution d’observabilité et de contrôle centralisée pour pouvoir surveiller es ressources authentifiées.

Le courtage d’identité vaut-il la peine pour un seul cloud ?

Le passage au cloud est complexe et il est rare que l’on s’en tienne à une stratégie de cloud unique ; cela peut être dû à un changement de stratégie, à la réglementation, à la difficulté de migrer depuis une infrastructure existante ou encore à une acquisition. En outre, les architectures de microservices sont de plus en plus omniprésentes et, par conséquent, les ressources sont partagées. Le partage d’informations d’identification via e-mail ou messagerie est bien plus fréquent que l’on ne voudrait l’admettre, ce qui représente non seulement un risque de fuite d’informations d’identification, mais aussi un risque réel de prolifération des informations d’identification.

En cas de prolifération des données, les informations d’identification sont insuffisamment gérées et contrôlées ; de plus, elles présentent un risque d’indisponibilité, en particulier à mesure que l’on adopte des architectures plus complexes où la possibilité de services partagés est plus élevée. Par exemple, si Jane, une développeuse, change le mot de passe de la base de données de l’application A sans en informer l’application B, cette dernière peut subir une interruption de service. À l’inverse, si on négocie les permissions de la base de données en fonction de l’identité, on peut changer le mot de passe de la base de données sans craindre une panne de service.

Toujours sceptique ?

Actuellement, plus de 50 % des organisations utilisent une version de Kubernetes, sans compter les entreprises qui utilisent d’autres systèmes de conteneurisation, comme Rancher ou Nomad. Bien qu’étant « cloud native », l’utilisation de Kubernetes dans le cloud pose ses propres challenges en matière de gestion des identités.

Par exemple, à l’heure où nous écrivons ces lignes, la maîtrise de la gestion de Kubernetes diffère énormément d’un fournisseur de cloud à l’autre. Dans AWS, il est possible de gérer les clusters à l’aide de l’IAM AWS natif, mais comme chez tous les grands fournisseurs de cloud, l’identité reste au niveau du cluster, ce qui rend la gestion de l’identité au niveau du pod presque impossible sans l’utilisation d’un pilote CSI ou d’un outil tiers. Dans Azure, l’identité machine n’est pas disponible pour AKS ; il en résulte que la gestion de l’identité du cluster est liée à l’identité de l’utilisateur, ce qui est loin d’être idéal si la non-répudiation est une priorité. Dans le cas de GKE, si l’on utilise l’identité de la charge de travail lors du démarrage d’un nouveau pod, « les premières secondes de la vie d’un pod peuvent être un échec ». Il en résulte une gestion incohérente des charges de travail.

On exige un SSO pour les humains, alors pourquoi pas pour les machines ?

On s’appuie sur l’authentification SSO pour les utilisateurs depuis près de trente ans dans le but d’unifier les identités humaines et l’authentification. Il est facile de spéculer sur les raisons pour lesquelles la fédération des identités d’application n’est pas plus fréquente, qu’il s’agisse de la nature, jusqu’il y a peu, statique des infrastructures, ou de l’utilisation omniprésente d’architectures monolithiques, ou d’une combinaison des deux ; quoi qu’il en soit, l’état actuel des identités d’application se caractérise par une approche fragmentée, décentralisée et hautement manuelle. 

Bien que la plupart des fournisseurs de cloud disposent d’identités natives pour leurs ressources, l’unification de ces identités en un flux de travail unique, vérifiable et contrôlé sans courtage centralisé est complexe, peu lisible pour l’humain et peu évolutive du fait de la complexité requise pour l’automatisation. En utilisant un mécanisme de courtage, on peut garantir un workflow unifié sur toutes les couches d’application requises, du réseau à l’application et ce, sur plusieurs ressources.

Si les meilleures pratiques imposent aux utilisateurs de s’authentifier via SSO, que ce soit pour le VPN ou une application d’entreprise, pourquoi devrait-il en être autrement pour les machines ?