Amazon AWS ajoute Private Key JWT à AgentCore Identity, remplaçant les secrets partagés par le contrôle de KMS

Amazon AWS a ajouté l’authentification Private Key JWT à AgentCore Identity, offrant aux agents automatisés une nouvelle alternative aux secrets client OAuth à longue durée de vie. Ce changement fait évoluer l’authentification du client vers des assertions signées à courte durée de vie, prises en charge par AWS Key Management Service. Il crée également un enregistrement plus clair de chaque demande de signature dans AWS CloudTrail.

Cette combinaison est importante, car un agent autonome peut demander des jetons bien plus fréquemment qu’une application classique destinée aux employés. Un secret client copié peut rester exploitable jusqu’à ce que quelqu’un le fasse pivoter ou le révoque. Une assertion Private Key JWT expire rapidement et nécessite l’accès à une clé de signature protégée pour chaque nouvelle demande.

L’enjeu central ne se résume pas à opposer clés et mots de passe. Amazon Bedrock AgentCore Identity promet désormais un contrôle renforcé sans obliger les développeurs à construire et exploiter leur propre service de signature. La concrétisation de cette promesse dépend de la compatibilité avec les fournisseurs d’identité, de la configuration précise des revendications, des autorisations KMS et d’une couverture d’audit complète.

Amazon AWS déplace l’authentification client OAuth vers KMS

Le changement important est qu’AgentCore Identity peut authentifier un client OAuth sans stocker de secret client réutilisable.

Dans le nouveau modèle décrit dans l’annonce Private Key JWT, AgentCore Identity construit un JSON Web Token et le signe via AWS KMS. Le fournisseur d’identité vérifie cette signature à l’aide de la clé publique correspondante.

La clé privée reste dans KMS. Un agent, un processus applicatif ou un administrateur n’a pas besoin d’exporter la clé dans un fichier de configuration, une image de conteneur, une variable d’environnement ou un magasin de secrets distinct.

Le JWT signé est une assertion client, ce qui signifie qu’il prouve l’identité du client OAuth auprès d’un serveur d’autorisation. Il ne s’agit pas du jeton d’accès finalement présenté à une API. Le serveur d’autorisation valide l’assertion avant d’émettre ce jeton d’accès.

Cette distinction est facile à manquer. L’authentification client OAuth détermine si l’application qui demande un jeton est bien le client enregistré. Le grant OAuth détermine quelle autorité représente le jeton résultant et quelles autorisations il reçoit.

Private Key JWT peut donc fonctionner avec plusieurs flux de grant. AgentCore Identity prend en charge l’accès délégué à l’utilisateur via le grant authorization code et l’accès machine-à-machine via client credentials. Ses modèles d’authentification plus larges couvrent également les configurations d’échange de jetons on-behalf-of.

Pour une demande déléguée à l’utilisateur, une personne autorise d’abord l’accès via le fournisseur d’identité. AgentCore Identity authentifie ensuite le client OAuth lors de l’échange du code d’autorisation contre des jetons. L’approbation de l’utilisateur et l’identité du client restent des contrôles distincts.

Pour une demande machine-à-machine, aucun utilisateur ne passe par un écran de consentement interactif. L’agent demande un jeton d’accès sous l’autorité propre de l’application. Private Key JWT authentifie cette application lors de l’échange client credentials.

Cette fonctionnalité est donc pertinente au-delà de la connexion. Elle vise l’accès sortant des agents aux API d’entreprise, aux services logiciels et à d’autres ressources protégées. Ce sont précisément les connexions où une information d’identification statique peut devenir une contrainte opérationnelle.

AgentCore Identity agit déjà comme intermédiaire entre les agents, les serveurs d’autorisation et les serveurs de ressources. Il récupère des informations d’identification tout en gardant les secrets à long terme et les jetons de rafraîchissement hors du code des agents. Private Key JWT étend cette frontière au matériel d’authentification du client OAuth.

Le chemin de la demande comporte désormais plusieurs étapes explicites. L’agent demande à AgentCore Identity un accès autorisé. AgentCore Identity crée une assertion à durée limitée, appelle KMS pour la signer et l’envoie au point de terminaison de jetons du fournisseur d’identité.

Le fournisseur d’identité vérifie la signature par rapport à la clé publique enregistrée. Il évalue également les revendications qui identifient le client, l’audience, l’heure d’émission et l’expiration. Si ces contrôles réussissent, le fournisseur renvoie un jeton d’accès via AgentCore Identity.

Cette conception n’élimine pas la confiance. Elle la déplace vers les politiques KMS, les rôles IAM, la configuration OAuth et l’enregistrement de clé publique du fournisseur d’identité. Ces contrôles sont plus granulaires qu’une chaîne copiée, mais ils introduisent aussi davantage d’endroits où une incompatibilité peut bloquer l’authentification.

Comment Private Key JWT transforme le modèle des secrets

Private Key JWT réduit la dépendance aux secrets partagés, mais sa sécurité dépend du contrôle de ceux qui peuvent demander à KMS de signer.

L’authentification client OAuth traditionnelle utilise couramment client_secret_basic ou client_secret_post. Ces deux méthodes envoient un ID client et un secret partagé au serveur d’autorisation. La différence réside dans le fait que ces informations d’identification apparaissent dans un en-tête HTTP Basic ou dans le corps de la demande.

La documentation AWS décrit HTTP Basic comme méthode par défaut pour les fournisseurs AgentCore Identity personnalisés. Le secret reste réutilisable jusqu’à sa rotation, son expiration ou sa révocation. Chaque système qui en détient une copie fait partie du périmètre de sécurité de cette information d’identification.

Private Key JWT remplace ce modèle symétrique par une paire de clés asymétriques. Une partie contrôle la clé de signature privée, tandis que le fournisseur d’identité ne stocke que la clé de vérification publique. L’exposition de la clé publique ne permet pas à un attaquant de générer des assertions valides.

Cette approche suit le profil OAuth JWT, qui définit les JWT pour l’authentification client et les grants d’autorisation. La demande de jeton inclut une assertion client et l’identifie comme une assertion JWT bearer.

Une assertion typique contient une revendication d’émetteur identifiant le client, une revendication de sujet pour ce client et une revendication d’audience désignant le point de terminaison de jetons. Elle inclut également des heures d’expiration et d’émission. Un identifiant JWT unique peut aider un fournisseur d’identité à détecter les tentatives de rejeu.

Ces champs ne constituent pas des métadonnées décoratives. Une audience incorrecte peut rendre un JWT correctement signé invalide. Un décalage d’horloge peut conduire le fournisseur à rejeter une assertion comme prématurée ou expirée.

Private Key JWT ne garantit pas non plus automatiquement la protection contre le rejeu. RFC 7523 laisse certaines défenses contre le rejeu à la politique de déploiement. Les fournisseurs d’identité doivent appliquer des limites de durée de vie adaptées et, lorsqu’ils le prennent en charge, un suivi des assertions uniques.

De courtes fenêtres d’expiration réduisent l’utilité d’une assertion interceptée. Elles ne protègent pas un système où un attaquant est autorisé à invoquer à répétition la clé de signature. C’est pourquoi la politique de clé KMS et les autorisations IAM deviennent la couche d’application centrale.

AWS KMS représente une clé asymétrique comme une paire publique et privée liée. Pour les clés de signature, le composant privé reste protégé au sein du service. Le composant public peut être téléchargé et enregistré auprès d’un fournisseur d’identité externe.

KMS prend en charge plusieurs types de clés asymétriques, notamment des clés RSA et à courbe elliptique pour la signature et la vérification. Le type de clé et l’algorithme choisis doivent correspondre à ceux acceptés par le fournisseur d’identité.

AgentCore Identity doit disposer de l’autorisation d’utiliser la clé configurée pour signer. AWS indique que les appelants de l’opération KMS Sign nécessitent l’autorisation kms:Sign via la politique de clé. Le service utilise alors le composant privé sans le renvoyer.

Il s’agit d’une amélioration significative du confinement. Une fuite de configuration exposant un ARN de clé ne révèle pas le matériel de clé privée. Un attaquant aurait encore besoin d’identifiants AWS et d’une autorisation effective pour invoquer la clé.

Toutefois, l’autorisation de signer reste sensible. Un rôle disposant d’un accès étendu à kms:Sign pourrait potentiellement demander des signatures en dehors du chemin de charge de travail prévu. Les équipes doivent lier les autorisations aux rôles d’exécution AgentCore appropriés et éviter les accès généraux avec caractères génériques.

Ce changement affecte également la rotation. Avec un secret partagé, les deux parties doivent remplacer la même valeur confidentielle. Avec l’authentification asymétrique, les équipes peuvent introduire une nouvelle clé publique auprès du fournisseur d’identité tout en conservant l’ancien vérificateur pendant une transition contrôlée.

Ce chevauchement peut réduire les interruptions, à condition que le fournisseur d’identité prenne en charge plusieurs clés actives. S’il n’accepte qu’une seule clé publique, la rotation exige toujours une synchronisation coordonnée. Private Key JWT modifie le matériel faisant l’objet de la rotation, mais pas la nécessité d’un processus de rotation testé.

Les flux de grant pris en charge correspondent à différentes identités d’agent

Private Key JWT authentifie le client OAuth, tandis que le grant sélectionné détermine si un agent agit pour lui-même ou pour un utilisateur.

Le grant authorization code convient aux agents qui accèdent à des ressources au nom d’une personne. Un utilisateur se connecte via un fournisseur d’identité et approuve les autorisations demandées. Le serveur d’autorisation renvoie un code que le client échange contre des jetons.

Lors de cet échange, AgentCore Identity utilise l’assertion Private Key JWT pour prouver que le client enregistré effectue la demande. L’assertion ne remplace pas le consentement de l’utilisateur. Elle renforce l’authentification au point de terminaison de jetons.

Ce flux convient à un agent qui lit le calendrier d’un utilisateur, recherche les dossiers autorisés d’un employé ou met à jour un système de gestion de la relation client dans le cadre d’autorisations déléguées. L’accès résultant reste lié à l’utilisateur et aux scopes approuvés.

Le grant client credentials répond à un cas différent. Ici, la charge de travail agit en son propre nom, sans utilisateur interactif. Un agent planifié peut appeler une API interne d’inventaire, traiter des alertes de service ou récupérer des données opérationnelles approuvées.

Private Key JWT authentifie ce client machine avant que le serveur d’autorisation n’émette un jeton d’application. Comme aucune personne n’est présente, l’identité du client, les scopes du jeton et la politique d’autorisation en aval portent une plus grande part de la charge de sécurité.

Les organisations ne doivent pas considérer les deux grants comme des options de déploiement interchangeables. Utiliser client credentials pour une tâche qui devrait préserver l’identité de l’utilisateur peut brouiller la responsabilité. Utiliser un flux délégué pour un travail de service en arrière-plan peut créer des dépendances fragiles à des comptes individuels.

L’accès on-behalf-of introduit une autre variante. Un agent reçoit la preuve d’une identité utilisateur existante et l’échange contre un jeton adapté à une autre ressource. Le flux doit préserver la relation entre l’utilisateur, l’agent et le service de destination.

La documentation AgentCore Identity décrit à la fois les approches standard d’échange de jetons et de grant d’autorisation basé sur JWT pour ces cas. La prise en charge dépend toujours du serveur d’autorisation externe et de ses règles d’échange de jetons.

Private Key JWT peut authentifier le client qui participe à cet échange. Il ne détermine pas si le jeton utilisateur entrant est valide ni si la délégation demandée doit être autorisée. Ces décisions restent du ressort des systèmes d’identité et d’autorisation concernés.

Cette séparation constitue l’un des points architecturaux les plus solides de cette fonctionnalité. Les équipes peuvent choisir un grant selon l’autorité dont un agent a besoin, puis choisir Private Key JWT selon la manière dont le client doit prouver son identité.

Elle souligne également pourquoi le modèle mental d’une unique « information d’identification d’agent » est peu sûr. Un agent peut avoir une identité de charge de travail, agir pour un utilisateur, appeler plusieurs serveurs de ressources et utiliser des jetons différents pour chaque destination.

Le jeton d’accès de charge de travail d’AgentCore Identity ajoute une couche supplémentaire. AWS indique que ce jeton peut porter l’identité de l’agent et celle de l’utilisateur final lorsque l’agent demande des identifiants au coffre-fort. AgentCore Runtime peut le fournir automatiquement aux agents hébergés.

Ce jeton de charge de travail autorise l’accès à AgentCore Identity. Le jeton d’accès OAuth externe autorise l’accès à l’API de destination. L’assertion Private Key JWT authentifie le client OAuth lors de l’émission du jeton.

Trois jetons peuvent donc apparaître dans une transaction de bout en bout, chacun remplissant un rôle différent. Les confondre peut entraîner une validation incorrecte, une journalisation excessive ou une exposition accidentelle.

Les revues de sécurité doivent associer chaque jeton à son émetteur, son audience, son détenteur, sa durée de vie et sa destination. Elles doivent également déterminer quel composant peut le renouveler ou le remplacer. Cet exercice permet de détecter des erreurs de conception que les schémas au niveau du produit peuvent masquer.

La pression concurrentielle plus large porte sur les intégrations d’agents fondées sur des secrets. Les secrets client statiques sont familiers et largement pris en charge, mais ils passent mal à l’échelle lorsque de nombreuses charges de travail autonomes nécessitent des autorisations et des pistes d’audit indépendantes.

Private Key JWT accroît la charge de configuration tout en réduisant la duplication des identifiants. Pour les équipes qui exploitent déjà AWS IAM, KMS et CloudTrail, ce compromis peut être intéressant. Pour les déploiements plus modestes, la surface de politiques supplémentaire peut l’emporter sur le bénéfice immédiat.

Configurer la chaîne de confiance exige davantage que de sélectionner une méthode

La configuration ne réussit que lorsque KMS, IAM, AgentCore Identity et le fournisseur d’identité externe s’accordent sur les mêmes paramètres cryptographiques et OAuth.

La première exigence est une clé KMS asymétrique configurée pour la signature et la vérification. Les clés de chiffrement ne peuvent pas remplir ce rôle. La spécification de la clé et l’algorithme de signature doivent correspondre à une combinaison acceptée par le fournisseur d’identité cible.

AWS KMS expose la partie publique d’une clé de signature asymétrique. Les équipes enregistrent cette clé publique auprès de leur fournisseur d’identité, directement ou par l’intermédiaire d’une configuration JSON Web Key prise en charge.

Le fournisseur d’identité doit associer la clé au bon client OAuth. Il doit également prendre en charge Private Key JWT sur son point de terminaison de jeton. Les interfaces d’enregistrement et les algorithmes acceptés diffèrent selon les fournisseurs, cette étape reste donc propre à chacun d’eux.

Ensuite, les administrateurs créent ou mettent à jour un fournisseur d’identifiants OAuth personnalisé dans la console Amazon Bedrock AgentCore. La configuration nécessite les informations de découverte du fournisseur, l’identifiant client, l’ARN de la clé KMS et l’algorithme de signature.

La découverte OAuth permet à AgentCore Identity de localiser les points de terminaison d’autorisation et de jeton à partir des métadonnées du fournisseur. Les équipes doivent vérifier que le point de terminaison de jeton découvert correspond à la valeur d’audience attendue par le fournisseur d’identité.

AgentCore Identity doit également être autorisé à appeler KMS. L’opération de signature KMS exige une clé avec l’usage SIGN_VERIFY et un algorithme compatible avec cette clé.

KMS accepte soit un message brut, soit un condensat précalculé, selon le type de message sélectionné. Une implémentation JWT doit éviter un double hachage accidentel, car la vérification externe suppose le comportement de hachage défini par l’algorithme.

La configuration de l’en-tête JWT est également importante. Le fournisseur d’identité peut utiliser un identifiant de clé pour sélectionner la clé publique appropriée. Un identifiant absent ou incorrect devient particulièrement problématique lors de la rotation, lorsque plusieurs clés publiques peuvent être actives.

Les revendications de la charge utile exigent la même attention. L’émetteur et le sujet correspondent généralement à l’ID client OAuth. L’audience identifie normalement le point de terminaison de jeton du serveur d’autorisation, bien que les exigences du fournisseur doivent déterminer la valeur exacte.

L’expiration doit rester courte. L’heure d’émission doit refléter une horloge synchronisée. Un identifiant de jeton unique est utile lorsque le fournisseur enregistre les assertions précédemment acceptées.

Après avoir enregistré le fournisseur d’identifiants, les équipes doivent tester indépendamment chaque type d’autorisation prévu. Une requête client credentials réussie ne prouve pas que l’échange de code d’autorisation ou l’échange de jeton est correctement configuré.

Les tests doivent commencer avec des portées minimales. Si l’authentification réussit mais que l’autorisation échoue, la distinction devient plus facile à diagnostiquer. Ajouter de larges autorisations pour contourner une erreur peut masquer un problème d’audience ou d’enregistrement du client.

Les équipes doivent également tester les chemins négatifs. Une requête signée avec la mauvaise clé doit échouer. Une assertion expirée doit échouer. Une audience incorrecte et un appelant KMS non autorisé doivent chacun produire des éléments de preuve distincts.

C’est à ce stade que le compromis opérationnel devient visible. Les secrets partagés sont suffisamment simples pour que les équipes ne valident souvent que le chemin nominal. Private Key JWT offre des frontières plus solides, mais celles-ci nécessitent des tests explicites.

La configuration crée également des dépendances entre les équipes administratives. Une équipe de sécurité cloud peut être responsable des politiques KMS et IAM. Une équipe chargée de l’identité peut contrôler le client OAuth et l’enregistrement de la clé publique.

Les propriétaires d’applications configurent AgentCore Identity et déterminent les portées d’autorisation. Les équipes d’audit décident quels enregistrements CloudTrail doivent être conservés et faire l’objet d’alertes. Aucune sélection dans une console unique ne résout ces questions de responsabilité.

Un déploiement utile commence par une intégration non critique. Les équipes peuvent documenter les exigences de revendications, les réponses aux échecs, les étapes de rotation et la responsabilité d’escalade avant d’appliquer la méthode à de nombreux agents.

L’automatisation doit suivre ce premier déploiement validé. Les modèles d’infrastructure peuvent standardiser les politiques de clés et les paramètres des fournisseurs d’identifiants, mais ils ne doivent pas présumer du comportement du fournisseur d’identité.

Le résultat n’est pas un système sans secrets. Les jetons existent toujours, les serveurs d’autorisation conservent la confiance et les autorisations AWS restent des identifiants. L’affirmation plus restreinte est plus défendable : le client OAuth ne dépend plus d’un secret partagé et réutilisable.

CloudTrail transforme chaque signature en signal d’audit

La signature adossée à KMS fournit aux défenseurs un événement côté AWS qu’ils peuvent corréler avec les requêtes de jetons et l’activité des agents.

AWS KMS s’intègre à CloudTrail, qui enregistre les appels effectués par les utilisateurs, les rôles et les services AWS. Sa journalisation d’audit KMS comprend les opérations cryptographiques ainsi que les actions de gestion des clés.

Une transaction Private Key JWT devrait donc créer des éléments de preuve autour de la requête de signature KMS. L’événement peut identifier l’opération, la région, l’heure, la clé concernée et le principal AWS ou le contexte de service impliqué.

Cet enregistrement ne raconte toutefois pas toute l’histoire à lui seul. CloudTrail montre qu’une identité AWS autorisée a demandé une signature. Les journaux du fournisseur d’identité externe montrent s’il a accepté l’assertion et émis un jeton.

Les journaux d’audit du service de destination montrent ce qu’a fait le jeton d’accès résultant. Une enquête efficace corrèle les trois couches au lieu de considérer l’événement KMS comme une preuve d’accès réussi à une ressource.

CloudTrail peut néanmoins répondre à des questions importantes. Les enquêteurs peuvent rechercher un volume de signatures inattendu, des requêtes provenant du mauvais rôle, des appels dans une région non approuvée ou une activité impliquant une clé en dehors de son calendrier habituel.

Les sélecteurs d’événements configurés sont importants. AWS classe les événements KMS comme des événements de gestion, et les pistes CloudTrail enregistrent normalement l’activité de gestion. Les administrateurs peuvent toutefois exclure explicitement les événements KMS.

AWS avertit que les opérations KMS peuvent générer des volumes d’événements élevés. Certaines organisations les filtrent afin de contrôler le volume de journalisation. Cela peut supprimer les éléments de preuve de signature mêmes qui rendent ce modèle d’authentification plus facile à auditer.

Les équipes qui adoptent Private Key JWT doivent examiner leurs paramètres d’événements de gestion. Elles doivent confirmer que l’activité KMS pertinente atteint la piste ou le magasin de données d’événements prévu.

La rétention et la possibilité de recherche comptent également. L’historique des événements est utile pour les enquêtes récentes, tandis qu’une piste ou un magasin de données d’événements CloudTrail Lake prend en charge des analyses sur une période plus longue. Les enregistrements exportés peuvent également alimenter les systèmes de surveillance de sécurité.

Une base de référence doit distinguer le comportement attendu de renouvellement des jetons des anomalies. Un agent machine fonctionnant en continu peut signer des assertions selon une cadence régulière. Un flux de travail délégué par un utilisateur peut créer des pics pendant les sessions actives.

De forts écarts peuvent indiquer une boucle de nouvelle tentative, un échec de configuration ou un usage abusif d’identifiants. Des signatures répétées suivies d’un rejet par le point de terminaison de jeton pourraient signaler une audience incorrecte, une clé publique expirée ou un problème d’horloge.

Une activité de signature sans requêtes AgentCore correspondantes mérite une inspection plus poussée. Il en va de même pour une émission de jeton réussie sans les appels en aval attendus. Chaque modèle identifie une rupture différente dans la chaîne de confiance.

Les événements du cycle de vie des clés doivent faire l’objet d’alertes distinctes. Désactiver une clé de signature peut interrompre chaque intégration dépendante. Les changements de politique peuvent étendre silencieusement les personnes autorisées à l’appeler.

CloudTrail aide également lors de la rotation. Les équipes peuvent observer si l’ancienne clé continue de recevoir des requêtes de signature après l’activation d’une nouvelle clé. Une activité persistante peut révéler un fournisseur d’identifiants oublié ou un déploiement retardé.

La visibilité d’audit reste néanmoins conditionnelle. Les journaux doivent être activés, conservés, protégés et examinés. Un événement enregistré mais jamais interrogé offre peu de défense pratique.

Les événements CloudTrail ne valident pas non plus le motif métier d’une requête. Un agent correctement autorisé peut tout de même demander un jeton d’accès au mauvais moment ou l’utiliser pour une tâche trop étendue.

Cette limite attire l’attention sur la conception des autorisations. Private Key JWT peut prouver que le client contrôle l’accès à une clé de signature. Il ne peut pas déterminer si l’objectif de l’agent, l’outil sélectionné ou l’opération demandée est approprié.

Les organisations ont besoin de restrictions de portée, de politiques de serveur de ressources, de contrôles de charges de travail et d’une surveillance comportementale autour de la preuve cryptographique. La signature est un signal de haute qualité, mais pas un système complet de gouvernance des agents.

Ce que les entreprises doivent surveiller après le lancement de Private Key JWT

Le prochain test consiste à déterminer si Private Key JWT devient une norme opérationnelle ou reste une option avancée pour des déploiements étroitement gérés.

Le premier signal est l’interopérabilité avec les fournisseurs d’identité. Une adoption réussie exige que les fournisseurs acceptent les algorithmes de signature sélectionnés, les revendications, le format d’audience et la méthode d’enregistrement de clé publique.

AWS peut simplifier son côté de l’échange, mais il ne peut pas standardiser le flux de travail administratif de chaque fournisseur. Des exemples clairs, propres à chaque fournisseur, réduiraient les déploiements défaillants et les contournements peu sûrs.

Le deuxième signal est le comportement de rotation. Les entreprises doivent savoir si elles peuvent enregistrer des clés publiques qui se chevauchent, mettre à jour les fournisseurs AgentCore sans interruption et confirmer la migration au moyen des enregistrements d’audit.

Une fonctionnalité qui ne fonctionne que lors de la configuration initiale ne résout que la moitié du problème. L’authentification en production exige aussi une récupération prévisible lorsqu’une clé est désactivée, remplacée ou compromise.

Le troisième signal est l’adoption de l’audit. CloudTrail donne aux équipes accès aux enregistrements de signature, mais les organisations doivent conserver les événements KMS et les relier aux journaux des fournisseurs d’identité et des serveurs de ressources.

Des recommandations de détection rendraient la fonctionnalité plus utile. Des taux de signature élevés, des principaux inconnus, des erreurs répétées et une activité régionale inattendue sont des candidats pratiques pour les alertes.

Les équipes de sécurité doivent également surveiller les limites du modèle d’autorisations d’AgentCore Identity. La politique idéale permet à une charge de travail d’utiliser une clé de signature pour un fournisseur approuvé, sans accorder d’accès de signature non lié.

Les clés intercomptes ajoutent de la flexibilité, mais exigent des politiques de ressources soigneusement conçues. AWS KMS prend en charge l’utilisation intercompte pour la signature lorsque les appelants spécifient l’ARN de la clé et reçoivent les autorisations requises.

Cette capacité peut favoriser une gestion centralisée de la sécurité. Elle peut également créer des dépendances entre les comptes applicatifs et un compte d’identité central. Les pannes ou erreurs de stratégie dans le compte central peuvent affecter de nombreux agents.

Les entreprises devraient mesurer les résultats opérationnels plutôt que de supposer que la conception cryptographique garantit le succès. Parmi les indicateurs utiles figurent la charge de travail liée à la rotation des secrets, les échecs de demande de jetons, les tentatives de signature non autorisées et le temps de rétablissement après des changements de clés.

Elles devraient également comparer Private Key JWT à l’authentification JWT signée avec AWS IAM. La documentation d’AgentCore Identity décrit une méthode AWS_IAM_ID_TOKEN_JWT qui utilise une assertion émise par IAM et exige que le serveur d’autorisation fasse confiance à AWS IAM.

Les deux approches s’éloignent des secrets client partagés, mais elles établissent la confiance de manière différente. Private Key JWT demande au fournisseur d’identité de faire confiance à une clé publique gérée par le client. La méthode IAM lui demande de faire confiance à AWS IAM en tant qu’émetteur.

La prise en charge par les fournisseurs déterminera souvent quelle voie est praticable. Certains systèmes d’identité prennent déjà en charge Private Key JWT pour les clients OAuth confidentiels. Moins nombreux seront ceux configurés pour accepter directement AWS IAM comme émetteur.

Private Key JWT occupe donc une position intermédiaire utile. Il applique une méthode d’authentification OAuth standard tout en conservant le matériel de signature privé sous le contrôle de KMS.

L’importance plus large de cette fonctionnalité réside dans sa manière de traiter un agent. Au lieu de lui attribuer une information d’identification réutilisable, la plateforme effectue une opération cryptographique étroitement autorisée lorsque l’accès est nécessaire.

Ce modèle réduit la valeur des données de configuration copiées. Il crée également un point de contrôle applicable pour chaque demande de jeton. Ce sont des améliorations concrètes pour les charges de travail autonomes qui fonctionnent fréquemment et avec une supervision limitée.

Le compromis est une précision accrue de la configuration. Les équipes doivent aligner les algorithmes, les clés publiques, les revendications JWT, les stratégies IAM, les autorisations OAuth, les portées des jetons et les contrôles de journalisation.

Amazon AWS a rendu cette complexité plus gérable en intégrant la signature à AgentCore Identity. Cela n’a toutefois pas fait disparaître les décisions de confiance qui l’entourent.

Avant d’adopter largement cette méthode, choisissez un agent représentatif et retracez l’intégralité de son parcours d’accès. Identifiez chaque principal, jeton, autorisation, portée, source de journaux et mécanisme de révocation impliqué.

Testez ensuite la rotation et les défaillances, et pas seulement une authentification réussie. Si votre équipe peut expliquer qui a demandé chaque signature et ce qui s’est passé ensuite, Private Key JWT fait plus que remplacer un secret.