

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

# Authentification et sécurité
<a name="connecting-to-devops-agent-remote-servers-authentication-and-security"></a>

Deux méthodes d'authentification sont disponibles pour les terminaux MCP et A2A :
+ **Jeton d'accès (porteur) ** : jeton unique limité à un espace d'agent. Configuration la plus simple pour une utilisation individuelle.
+ **AWS SIGv4 ** : AWS authentification basée sur les informations d'identification. Supporte plusieurs espaces d'agents et s'intègre à la gouvernance des AWS identités existante. Géré automatiquement par [ mcp-proxy-for-aws](https://github.com/aws/mcp-proxy-for-aws), un proxy local qui signe les demandes à l'aide de vos informations d'identification. AWS 

## Création d'un jeton d'accès
<a name="create-an-access-token"></a>

### Conditions préalables
<a name="prerequisites"></a>
+ La fonctionnalité des jetons d'accès doit être activée sur votre espace agent.
+ Vous devez disposer des autorisations IAM pour gérer les jetons d'accès (`aidevops:CreateAccessToken`,`aidevops:RevokeAccessToken`,`aidevops:RotateAccessToken`). Pour obtenir la liste complète, consultez [DevOps Autorisations IAM des agents](aws-devops-agent-security-devops-agent-iam-permissions.md).

### Activer les jetons d'accès
<a name="enable-access-tokens"></a>

1. Connectez-vous à la console de AWS gestion et ouvrez la console de l' AWS DevOps agent.

1. Choisissez votre espace d'agent.

1. Cliquez sur l’onglet **Configuration**.

1. Dans la ** section Jetons d'**accès, choisissez ** Activer**.

1. Confirmez l’action.

### Créez un jeton
<a name="create-a-token"></a>

1. Ouvrez l'application Web DevOps Agent pour votre espace agent, puis dans le menu de navigation, choisissez ** Paramètres**, puis choisissez ** Access Tokens**.

1. Choisissez **Generate token (Générer le jeton)**.

1. Entrez un nom pour le jeton.

1. Choisissez un scope :
   + `read`— Consultez les enquêtes, les recommandations, les discussions et les ressources de l'espace agent.
   + `operate`— Accès complet. Inclut tout`read`, y compris l'envoi de messages, la création de discussions et la gestion des tâches et des recommandations du backlog.

1. Choisissez un type de client :
   + `human`— Pour l'utilisation de l'IDE et de la CLI (Kiro, Claude Code, Cursor et autres outils interactifs).
   + `agent`— Pour les intégrations A2A autonomes et les agents programmatiques.

1. Définissez une date d'expiration (1 à 60 jours).

1. Copiez la valeur du jeton et stockez-la dans un endroit sûr et sécurisé, tel que [AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html). Vous ne pouvez pas le récupérer à nouveau.

Après avoir créé un jeton, l'application Web affiche un exemple de configuration que vous pouvez copier directement dans votre client.

## Utiliser l'authentification Sigv4
<a name="use-sigv4-authentication"></a>

L'authentification Sigv4 utilise vos AWS informations d'identification au lieu d'un jeton d'accès. Les plugins Kiro power et Claude Code incluent le support SIGv4 intégré via`mcp-proxy-for-aws`, qui signe les demandes à l'aide de vos informations d'identification locales AWS .

### Quand SIGv4 est utilisé
<a name="when-sigv4-is-used"></a>
+ Comme ** solution de repli ** lorsque le jeton d'accès n'est pas configuré ou échoue (expiré, non valide).
+ En tant qu'**authentification ** principale lorsque vous disposez de plusieurs espaces d'agent et que vous devez les acheminer `agent_space_id` par appel d'outil.
+ Au choix ** de ** l'utilisateur, dans Claude Code, exécutez la compétence de configuration pour passer du jeton Bearer à l'authentification SigV4.

### Conditions préalables
<a name="prerequisites"></a>
+ AWS informations d'identification disponibles dans l'environnement (via le SSO, les variables d'environnement ou le fichier d'informations d'identification).
+ Vos informations d'identification doivent être autorisées à invoquer les actions de AWS DevOps l'Agent. Pour les autorisations requises, consultez [DevOps Autorisations IAM des agents](aws-devops-agent-security-devops-agent-iam-permissions.md).
+ `uvx`installé (le proxy fonctionne`uvx mcp-proxy-for-aws@latest`).

### Exemple de configuration
<a name="example-configuration"></a>

Pour configurer un client MCP afin qu'il utilise SIGv4 au lieu d'un jeton d'accès, exécutez le serveur via. `mcp-proxy-for-aws` Remplacez `{region}` par la région de votre espace agent (par exemple,`us-east-1`) :

```
{
  "mcpServers": {
    "aws-devops-agent": {
      "command": "uvx",
      "timeout": 120000,
      "args": [
        "mcp-proxy-for-aws@latest",
        "https://connect.aidevops.{region}.api.aws/mcp",
        "--service", "aidevops",
        "--region", "{region}"
      ]
    }
  }
}
```

Le proxy signe chaque demande avec vos AWS informations d'identification locales, aucun jeton d'accès n'est donc requis.

### Multi-Agent-Space routage
<a name="multi-agent-space-routing"></a>

En mode SIGv4, `agent_space_id` transmettez chaque appel d'outil pour spécifier l'espace d'agent à utiliser. Cela permet d'acheminer des données à travers plusieurs espaces d'agent à partir d'un seul client.

## Considérations sur la sécurité
<a name="security-considerations"></a>

### Définition de la portée des jetons
<a name="token-scoping"></a>
+ Utilisez le moindre privilège : optez `read` pour les intégrations en lecture seule, `operate` uniquement lorsque le client doit envoyer des messages ou gérer des tâches.
+ Faites pivoter les jetons périodiquement. Les jetons expirent après la durée configurée (maximum 60 jours).
+ Stockez les jetons dans des variables d'environnement ou des gestionnaires de secrets. Ne codez pas les jetons en dur dans le code source.
+ N'exécutez pas automatiquement les réponses des agents sans examen humain.

### Liste d'adresses IP autorisées
<a name="ip-allowlist"></a>

Lors de la création d'un jeton d'accès, vous pouvez éventuellement spécifier une liste d'adresses IP autorisées. Une fois configuré, le jeton ne peut être utilisé qu'à partir des adresses IP ou des plages d'adresses CIDR spécifiées. Les demandes provenant d'autres adresses IP sont rejetées avec une erreur d'accès refusé.

### Rotation et révocation des jetons
<a name="token-rotation-and-revocation"></a>
+ **Rotation ** : faites pivoter un jeton pour générer une nouvelle valeur de jeton tout en préservant le nom, l'étendue et la liste d'adresses IP autorisées du jeton. L'ancien jeton est immédiatement invalidé. Mettez à jour la configuration de votre client avec la nouvelle valeur du jeton. La rotation permet également de créer un nouvel historique des discussions. Consultez la section suivante.
+ **Révocation ** — Si un jeton est compromis, révoquez-le immédiatement. Les jetons révoqués ne peuvent pas être utilisés et ne peuvent pas être restaurés.

#### Historique des discussions et rotation des jetons
<a name="chat-history-and-token-rotation"></a>

Chaque jeton possède son propre historique des discussions. Lorsque vous faites pivoter un jeton, AWS DevOps l'Agent traite la nouvelle valeur du jeton comme une nouvelle identité. Les discussions que vous avez créées avec le jeton précédent n'apparaissent plus via le serveur distant.

#### Réagir à un jeton compromis
<a name="responding-to-a-compromised-token"></a>

Si vous pensez qu'un jeton a été compromis, procédez comme suit :

1. **Bloquer l'accès à tous les jetons ** : dans la AWS DevOps console de l'agent, ouvrez votre espace agent, choisissez l'**onglet ** Configuration, puis choisissez ** Désactiver ** dans la section Jetons d'accès. Cela bloque immédiatement tout accès basé sur des jetons à l'espace agent.

1. **Révoquer les jetons compromis ** : dans l'application Web, accédez à ** Paramètres ** > Jetons ** d'accès**, choisissez le jeton compromis, puis choisissez ** Révoquer**. Vous pouvez révoquer des jetons même si les jetons d'accès sont désactivés.

1. **Re-enable jetons d'accès ** : après avoir révoqué les jetons compromis, réactivez les jetons d'accès depuis l'**onglet ** Configuration si vous avez toujours besoin d'un accès basé sur des jetons.

#### Révocation de jetons par programmation
<a name="revoking-tokens-programmatically"></a>

Vous pouvez également révoquer des jetons par programmation à l'aide de. `awscurl` Les commandes suivantes utilisent l'authentification SIGv4. Remplacez la région (`us-east-1`) par la région dans laquelle votre espace d'agent est créé.

**Remarque : ** L'étape 1 utilise l' AWS interface de ligne de commande. Les étapes 2 et 3 utilisent [ awscurl](https://github.com/okigan/awscurl), un outil de ligne de commande qui signe les requêtes HTTP avec Sigv4, car les opérations relatives aux jetons d'accès ne disposent pas encore de commandes CLI dédiées. AWS 

**Étape 1 : Répertoriez vos espaces d'agent **

```
aws aidevops list-agent-spaces --region us-east-1
```

**Étape 2 : Répertorier les jetons d'accès à un espace d'agent **

```
awscurl --service aidevops --region us-east-1 \
  -H "Accept: application/json" \
  "https://cp.aidevops.us-east-1.api.aws/v1/agentspaces/{agentSpaceId}/access-tokens"
```

**Étape 3 : révoquer un jeton **

```
awscurl --service aidevops --region us-east-1 -X POST \
  -H "Accept: application/json" \
  "https://cp.aidevops.us-east-1.api.aws/v1/agentspaces/{agentSpaceId}/access-tokens/{accessTokenId}/revoke"
```

Remplacez `{agentSpaceId}` et `{accessTokenId}` par les valeurs des réponses précédentes.

### Traçabilité
<a name="traceability"></a>

AWS DevOps L'agent enregistre l'activité du serveur distant dans AWS CloudTrail. Utilisez ces enregistrements pour savoir qui a appelé un serveur distant et ce que l'agent a fait en conséquence. AWS DevOps L'agent transmet CloudTrail les événements au AWS compte qui héberge l'espace d'agent.

#### Événements d'authentification par jeton d'accès
<a name="access-token-authentication-events"></a>

Chaque fois que AWS DevOps l'agent authentifie un jeton d'accès pour un point de terminaison MCP ou A2A, il envoie un événement à. `AuthenticateAccessToken` CloudTrail AWS DevOps L'agent enregistre les authentifications réussies et les échecs. Utilisez ces enregistrements pour auditer les utilisations légitimes et détecter les tentatives rejetées. Les exemples incluent les jetons expirés ou révoqués et les demandes bloquées par une liste d'adresses IP autorisées.

L'événement présente les caractéristiques suivantes :
+ **Source de l'événement ** — `aidevops.amazonaws.com`
+ **Nom de l’événement** – `AuthenticateAccessToken`
+ **Événement de gestion ** : l'événement est un événement de gestion qui n'est pas en lecture seule. Il reste donc visible lorsque vous filtrez les événements en lecture seule.

L'événement inclut les domaines clés suivants :


| Champ | Description | 
| --- | --- | 
| userIdentity.principalId | L'ID du jeton d'accès qui a été présenté. | 
| userName | Le nom du jeton d'accès. | 
| requestParameters.agentSpaceId | L'espace agent auprès duquel le jeton s'authentifie. | 
| requestParameters.accessTokenId | L'ID du jeton d'accès. | 
| requestParameters.tokenName | Le nom du jeton d'accès. | 
| requestParameters.protocol | Le protocole qui a été utilisé... MCP ouA2A. | 
| responseElements.AuthenticateAccessToken | Le résultat... Success ouFailure. | 
| resources | La ressource Agent Space (AWS::AIDevOps::AgentSpace) auprès de laquelle le jeton s'authentifie, identifiée par son ARN. | 
| additionalEventData.roleSessionName | Pour des authentifications réussies, le nom de session du rôle en aval, au formattoken\_{spaceId}\_{timestamp}\_{tokenName}. Utilisez-le pour corréler l'authentification aux actions effectuées par l'agent. | 
| sourceIPAddress | Adresse IP du client. | 
| userAgent | La User-Agent chaîne du client, si elle est disponible. | 
| errorCode, errorMessage | En cas d'échec des authentifications, raison pour laquelle l'authentification a été rejetée. | 

**Note**  
** AWS DevOps L'agent n'enregistre jamais la valeur brute du jeton du porteur. Seul l'ID du jeton d'accès opaque apparaît lors de l'événement.

#### Événements d'action en aval
<a name="downstream-action-events"></a>

Lorsque vous utilisez un jeton d'accès, AWS DevOps l'agent joue un rôle en votre nom pour effectuer des actions. AWS DevOps L'agent enregistre cet `AssumeRole` appel à l' CloudTrail aide de balises de session qui identifient le jeton et l'appelant :
+ `AgentSpaceId`— Identifiant de l'espace agent.
+ `UserId`— Identité du créateur du jeton.
+ `AccessTokenId`— Identifiant unique du jeton.
+ `TokenName`— Nom du jeton d'accès utilisé.
+ `ClientType`— Le protocole utilisé (MCP, A2A).
+ `SourceIp`— Adresse IP du client.
+ `UserAgent`— User-Agent Chaîne client (si disponible).

Chaque action que l'agent effectue en votre nom est associée à un appel d' AWS API en aval correspondant qui est CloudTrail enregistré. Le nom de la session de rôle utilise ce format`token_{spaceId}_{timestamp}_{tokenName}`. Le nom de cette session correspond `roleSessionName` à celui de l'`AuthenticateAccessToken`événement. Utilisez-le pour effectuer le suivi d'une authentification jusqu'aux actions spécifiques qui l'ont suivie.

#### Invocations SigV4
<a name="sigv4-invocations"></a>

Les appels qui utilisent l'authentification AWS SIGv4 au lieu d'un jeton d'accès ne produisent `AuthenticateAccessToken` aucun événement. AWS DevOps L'agent attribue les requêtes SIGv4 à votre AWS identité de gestion des identités et des accès (IAM). Vous pouvez suivre les actions que l'agent effectue via les appels d' AWS API en aval qu'il déclenche.

### Limitation de la politique relative aux terminaux VPC
<a name="vpc-endpoint-policy-limitation"></a>

Les points de terminaison des serveurs distants ne prennent pas en charge les politiques relatives aux terminaux VPC. Les appels utilisant des jetons d'accès ou une authentification Sigv4 ne peuvent pas être restreints par les politiques relatives aux terminaux VPC.

### Désactivation des jetons d'accès
<a name="disabling-access-tokens"></a>

La fonctionnalité des jetons d'accès est désactivée par défaut. Pour le désactiver après l'avoir activé :

1. Ouvrez l'**onglet ** Configuration de votre espace agent.

1. Dans la ** section Jetons ** d'accès, choisissez ** Désactiver**.

La désactivation bloque immédiatement tous les accès basés sur des jetons. Les jetons existants ne sont pas supprimés mais ne peuvent pas être utilisés tant que la fonctionnalité n'est pas réactivée.

Pour empêcher les utilisateurs de votre organisation d'activer les jetons d'accès, créez une politique de contrôle des services (SCP) qui refuse les actions de l'API des jetons d'accès et l'`UpdateAgentSpace`action (qui contrôle le basculement des jetons d'accès) :

**Remarque : le ** refus empêche `aidevops:UpdateAgentSpace` également d'autres mises à jour de l'espace agent (nom, description, paramètres régionaux). Si cela est trop large, omettez-le du SCP. Les refus restants empêchent toujours la création et l'utilisation de jetons, même si quelqu'un active la fonctionnalité.

```
{
  "Version": "2012-10-17",		 	 	 		 	 	 
  "Statement": [
    {
      "Sid": "DenyAccessTokenOperations",
      "Effect": "Deny",
      "Action": [
        "aidevops:UpdateAgentSpace",
        "aidevops:CreateAccessToken",
        "aidevops:GetAccessToken",
        "aidevops:ListAccessTokens",
        "aidevops:RotateAccessToken",
        "aidevops:RevokeAccessToken"
      ],
      "Resource": "*"
    }
  ]
}
```

## Résolution des problèmes
<a name="troubleshooting"></a>


| Symptôme | Cause | Résolution | 
| --- | --- | --- | 
| HTTP 401 non autorisé | Le jeton n'est pas valide ou a expiré. | Créez un nouveau jeton ou faites pivoter le jeton existant dans l'application Web. | 
| A2A-Version En-tête HTTP 400 « obligatoire » | En-tête de version de protocole manquant. Seul le format A2A v1.0 est pris en charge. | Ajoutez un A2A-Version: 1.0 en-tête aux requêtes A2A. | 
| HTTP 400 « L'espace de l'agent n'est pas résolu à partir des informations d'identification » | Une requête A2A \+ SIGv4 n'inclut pas l'X-Agent-Space-Iden-tête. | Ajoutez X-Agent-Space-Id: <agentSpaceId> à la demande. | 
| Délai d'expiration de la demande | Les premières réponses prennent de 5 à 30 secondes. Les enquêtes durent de 5 à 8 minutes. | Réglez le délai d'expiration du client à au moins 120 secondes. | 
| Connexion refusée | URL ou région de point de terminaison incorrecte. | Vérifiez le format de l'URL : https://connect.aidevops.{region}.api.aws | 