if ( !emtpy($headline_subheadline ) ) : ?>
Une surveillance plus stricte, des jetons à durée de vie plus courte et des contrôles plus stricts sur la façon dont les jetons sont utilisés après l’authentification sont nécessaires, car les agents d’IA compliquent la situation à qui et à quoi les entreprises peuvent faire confiance dans leurs systèmes.
endif; ?>
Les actions des agents d’IA sont hors de portée des nouvelles directives des autorités américaines sur la sécurisation des jetons d’identité et d’accès, mais les entreprises peuvent encore faire beaucoup de choses pour protéger leurs systèmes contre les humains malveillants et les agents d’IA.
« Protéger les jetons et les assertions contre la falsification, le vol et l’utilisation abusive », un nouveau rapport du National Institute of Standards and Technology (NIST) avec l’aide de la Cybersecurity and Infrastructure Security Agency (CISA), propose des conseils aux opérateurs de systèmes qui utilisent des jetons signés numériquement pour prendre des décisions d’accès, y compris l’authentification unique et l’accès aux API.
Les directives, également connues sous le nom de NIST IR 8587, traitent de ce qui se passe après l’authentification : les jetons et les assertions peuvent contenir une preuve d’authentification ou d’autorisation entre les systèmes, permettant à un attaquant qui les compromet d’exploiter l’accès déjà accordé. Le NIST recommande une surveillance continue, ainsi que des contrôles plus stricts tout au long du cycle de vie du jeton.
Cette question revêt une importance particulière pour la CISA. En mai, un référentiel public GitHub qui aurait été géré par un sous-traitant de la CISA s’est avéré contenir des informations d’identification gouvernementales sensibles, notamment des jetons AWS et des jetons d’accès GitHub. La CISA a déclaré à l’époque que rien n’indiquait que des données sensibles avaient été compromises.
La question non résolue de l’autorité de l’agent
Le NIST recommande d’appliquer les mêmes directives pour sécuriser les jetons signés utilisés par les agents d’IA que pour sécuriser ceux utilisés par les humains, mais note que les risques d’accès posés par l’IA et les agents d’IA « créent des défis IAM supplémentaires qui nécessitent des directives supplémentaires et, dans certains cas, des normes et protocoles nouveaux ou étendus ».
Le NIST et le CISA y travaillent toujours, mais les équipes informatiques peuvent faire certaines choses entre-temps pour sécuriser les systèmes agentiques.
La gestion du cycle de vie de l’identité d’un agent fait partie du défi, a déclaré Yih Khai Wong, directeur de recherche senior pour les services de sécurité chez IDC Asie/Pacifique.
Les entreprises ont besoin de visibilité sur la personne qui a fourni les informations d’identification d’un agent et sur ce que ces informations d’identification autorisent, a déclaré Wong. L’accès doit également être retiré à la fin de la tâche de l’agent.
« Le renforcement des jetons suppose que le détenteur du jeton est un acteur connu et limité », a déclaré Wong. « Un système agent brise cette hypothèse. »
La délégation peut rendre cette frontière plus difficile à établir, a déclaré Amit Kumar Jena, responsable du développement de l’IA chez Kanerika. Un agent peut agir au nom d’un utilisateur, appeler un outil puis accéder à un autre service, ce qui rend de plus en plus difficile la détermination de l’autorité exercée à mesure que la chaîne se développe.
Jena a déclaré qu’une injection rapide pourrait également orienter un agent détenant un jeton valide vers une action que l’utilisateur n’a jamais demandée. La vérification du jeton ne détecterait pas nécessairement cette utilisation abusive, car le jeton lui-même pourrait toujours être légitime.
Jain a fait valoir que les RSSI devraient traiter les agents d’IA comme des identités non humaines peu fiables, en accordant uniquement l’accès requis pour une tâche. Les actions à plus haut risque devraient nécessiter l’approbation humaine, a-t-il ajouté.
Wong a également recommandé de conserver un inventaire des agents et de séparer ces identités des comptes humains. Les informations d’identification devraient expirer une fois la tâche terminée, a-t-il déclaré.
Pourquoi les jetons valides peuvent toujours être dangereux
Selon Jonathan Ong, analyste principal des services de sécurité gérés chez Omdia, une faiblesse courante consiste à supposer que parce qu’un jeton est valide, l’activité qui lui est associée est légitime.
Les organisations doivent tenir compte du contexte dans lequel un jeton est présenté, notamment si un utilisateur accède à des systèmes sensibles depuis un emplacement inhabituel ou à un moment inattendu, a déclaré Ong. La détection doit également corréler l’activité dans les domaines de sécurité pour identifier les comportements qui peuvent sembler inoffensifs isolément.
Le confinement présente un autre défi une fois qu’un jeton a été compromis. « La révocation des jetons n’est pas toujours possible en raison de limitations architecturales », a déclaré Ong.
D’autres contrôles peuvent limiter l’utilité d’un jeton compromis. Neil Shah, vice-président de la recherche et partenaire chez Counterpoint Research, a déclaré que les recommandations du NIST peuvent réduire à la fois la durée et la portée d’un compromis symbolique.
Les restrictions d’audience peuvent limiter l’endroit où un jeton volé est accepté, tandis que la liaison cryptographique d’un jeton au client détenant la clé privée correspondante rend la relecture par un attaquant plus difficile.
Le rapport oriente également les organisations vers des mécanismes de signal partagé tels que le profil d’évaluation d’accès continu (CAEP) et le partage et la coordination des incidents de risque (RISC), qui peuvent aider les systèmes connectés à réagir lorsque les conditions de sécurité liées aux jetons changent, a déclaré Shah.
La sécurité des jetons s’étend au-delà de l’IAM
L’exposition des informations d’identification CISA met également en évidence la façon dont la sécurité des jetons peut s’effondrer en dehors des contrôles IAM traditionnels, a déclaré Jain. Les informations d’identification peuvent apparaître dans le code source, les pipelines CI/CD, les journaux et les environnements des sous-traitants, même lorsque les politiques d’accès elles-mêmes sont solides.
« Si un entrepreneur peut copier un identifiant cloud sur sa machine locale, la gouvernance des identités a déjà échoué », a déclaré Shah.
La gestion de ce risque par le seul biais de politiques peut s’avérer difficile dans les environnements DevOps, où les informations d’identification peuvent être copiées sur les machines des développeurs ou exposées via des pipelines automatisés, a déclaré Shah. Il a fait valoir que les entreprises devraient éliminer autant que possible les jetons statiques et les remplacer par des informations d’identification de courte durée.
L’incident de la CISA révèle également une limite dans les directives du NIST, a déclaré Jena. L’IR 8587 se concentre sur les jetons signés asymétriquement et place explicitement les mécanismes tels que les clés API en dehors de la portée de ses contrôles. Le NIST exige néanmoins que les jetons couverts soient tenus à l’écart des journaux, des pipelines CI/CD et des artefacts de build.
