Gestion des identités machines

Tout ce qui s'authentifie sans personne au clavier: comptes de service qui exécutent des traitements batch, clés d'API entre systèmes internes et vers un prestataire, certificats TLS qui permettent à deux services de se faire confiance, identités de workload dans une plateforme de conteneurs, identifiants derrière un chatbot ou un robot de reporting. Le Non-Human Identities Top 10 de l'OWASP les décrit comme des identités applicatives qu'il faut identifier en production et cite comme exemples comptes de service, clés d'API, clés d'accès, clés de chiffrement, jetons et certificats.

La liste de l'OWASP décrit des défaillances comme désactivation incorrecte de comptes et de clés inutilisés, fuite de secrets vers des endroits qui n'étaient pas faits pour les stocker, identités aux droits excessifs, secrets à longue durée de vie dont l'expiration est lointaine ou absente, même identité réutilisée entre développement, test et production, et personnes qui utilisent un compte de service pour un travail manuel. La NIST SP 800-207 traite l'identité de workload comme un sujet à part entière d'une architecture zero trust pour la même raison.

La question de gouvernance est de savoir qui, nommément, répond de chaque identifiant. Un identifiant qui a un responsable nommé est revu, voit ses droits réduits quand la tâche change, et est désactivé quand le système qu'il servait est retiré. Un identifiant dont le responsable est parti en 2019 ne connaît rien de tout cela, et il continue de fonctionner, ce qui pose problème.

La question du responsable est le point central de l'analyse de la sécurisation des banques face à la croissance des identités non humaines. Le cycle de revue est le même que pour les droits d'accès des salariés, et c'est là que les orientations de l'EBA sur la gestion des risques TIC et de sécurité placent l'attente sur la gestion des droits d'accès. Le zero trust dans la banque présente l'architecture dans laquelle ces identités s'inscrivent.

Les types se comportent différemment: un compte de service a un mot de passe et un jeu de droits, une clé d'API est un jeton au porteur qui fonctionne pour quiconque la détient, un certificat a une date d'expiration et une chaîne de confiance, une identité de workload est émise dynamiquement et peut vivre quelques minutes. Chacun demande un contrôle différent, et les traiter tous comme des « identifiants » produit une politique qui ne convient à aucun.

Le rapport entre identités machines et humaines et son évolution, avec les types d'identifiants concernés, est le sujet de cette analyse du problème des identités machines. L'utilité pratique d'une taxonomie est de vous dire quel contrôle construire en premier: une identité de workload de courte durée a besoin d'un mécanisme d'émission, tandis qu'une clé d'API de longue durée dans une intégration fournisseur a besoin d'une rotation et d'un plan pour le jour où elle fuit.

Un certificat atteint sa date d'expiration, deux services cessent de se faire confiance, et une interface de paiement ou un canal client tombe.

Vous ne pouvez pas renouveler ce que vous n'avez pas trouvé, ni remplacer un algorithme dans un parc que vous ne savez pas énumérer, donc l'inventaire des certificats sert à la fois la disponibilité et la cryptographie. L'agilité cryptographique en finance traite du volet algorithmes, et les recommandations du BSI sur les mécanismes cryptographiques sont la référence allemande pour le contenu des certificats.

Un agent qui lit une boîte mail, interroge un système et rédige une réponse a besoin d'une identité comme toute autre charge de travail. Un agent qui peut initier un paiement, modifier une limite ou lever un blocage a besoin de trois choses: une identité propre, un mandat qui dit ce qu'il peut faire avec des limites explicites, et une trace qui relie chaque action à la personne qui en répond.

Un agent qui agit selon une règle fixée par une personne ne supprime pas la responsabilité de cette personne, comme le soutient l'argument selon lequel les agents d'IA dépendent de la gouvernance des identités humaines. L'AI Act de l'UE exige une surveillance humaine pour les systèmes à haut risque, donc pour une banque, la chaîne de responsabilité est une exigence légale et non une préférence d'ingénierie. Les agents d'IA en finance présente ce que font ces agents, l'AI Act de l'UE en finance la réglementation, et la conformité IA en Allemagne l'approche de la BaFin.

DORA exige une gestion des risques TIC, des mesures de protection incluant la gestion des droits d'accès et des identités, et des politiques sur les contrôles cryptographiques et la gestion des clés, et aucune de ces dispositions ne distingue entre un identifiant utilisé par une personne et un identifiant utilisé par un service.

DORA en Allemagne présente la réglementation, la cybersécurité dans la finance allemande le tableau de sécurité plus large, et l'open banking en Allemagne les interfaces où beaucoup de ces identifiants franchissent une frontière entre établissements.

Commencez par les identifiants qui peuvent déplacer de l'argent ou atteindre des données clients, et donnez à chacun un responsable nommé, un objet documenté et une date d'expiration. C'est une liste courte par rapport au parc complet, et c'est la liste dont parlerait un incident.

Traitez ensuite les problèmes récurrents comme certificats sans processus de renouvellement, secrets stockés dans des dépôts de code et des fichiers de configuration, et comptes dont la dernière utilisation enregistrée est antérieure à la plateforme actuelle. L'IA dans la banque en Allemagne présente l'évolution qui ne cesse d'augmenter le décompte, et c'est la raison de bien régler le processus avant l'arrivée du volume.

Tout identifiant qui s'authentifie auprès d'un système sans personne au clavier: un compte de service, une clé d'API, un certificat TLS, une identité de workload dans une plateforme de conteneurs, un identifiant de bot. L'OWASP les appelle identités non humaines et les traite comme des identités applicatives qu'il faut identifier en production.

Parce que chaque intégration, service, traitement et automatisation en crée au moins une, alors qu'une personne en crée une. Les architectures de microservices, les plateformes cloud et les intégrations fournisseurs multiplient chacune le décompte, et presque rien ne les supprime, car la mise hors service d'un système inclut rarement la révocation des identifiants qu'il utilisait.

Oui, et partager l'identifiant d'une personne est la conception à éviter, car la piste d'audit dit alors qu'une personne a fait quelque chose qu'elle n'a pas fait. L'agent a besoin de sa propre identité, d'un mandat avec des limites explicites sur ce qu'il peut faire, et d'un lien enregistré vers la personne qui répond de ses actions, ce que l'exigence de surveillance humaine de l'AI Act de l'UE rend légal pour les usages à haut risque.

Les exigences de DORA sur la gestion des risques TIC, les mesures de protection, les droits d'accès et la gestion des identités, ainsi que sur les contrôles cryptographiques et la gestion des clés, ne distinguent pas entre identifiants humains et machines, donc un compte de service sans responsable ou un parc de certificats non géré entre dans le champ des obligations existantes.