Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
# Authentifizierung und Sicherheit
Zwei Authentifizierungsmethoden sind sowohl für MCP- als auch für A2A-Endpunkte verfügbar:
+ **Zugriffstoken (Bearer) ** — Ein einzelnes Token, das auf einen Agentenbereich beschränkt ist. Einfachste Einrichtung für den individuellen Gebrauch.
+ **AWS SigV4 ** — auf AWS Anmeldeinformationen basierende Authentifizierung. Unterstützt mehrere Agent Spaces und lässt sich in die bestehende AWS Identity Governance integrieren. Wird automatisch von [ mcp-proxy-for-aws verarbeitet](https://github.com/aws/mcp-proxy-for-aws), einem lokalen Proxy, der Anfragen mit Ihren Anmeldeinformationen signiert. AWS
## Erstellen Sie ein Zugriffstoken
### Voraussetzungen
+ Die Zugriffstoken-Funktion muss in Ihrem Agent Space aktiviert sein.
+ Sie müssen über IAM-Berechtigungen verfügen, um Zugriffstoken (`aidevops:CreateAccessToken`,`aidevops:RevokeAccessToken`,`aidevops:RotateAccessToken`) verwalten zu können. Eine vollständige Liste finden Sie unter [DevOps IAM-Berechtigungen für Agenten](aws-devops-agent-security-devops-agent-iam-permissions.md).
### Zugriffstoken aktivieren
1. Melden Sie sich bei der AWS Management Console an und öffnen Sie die AWS DevOps Agent-Konsole.
1. Wählen Sie Ihren Agentenbereich aus.
1. Wählen Sie die Registerkarte **Konfiguration** aus.
1. Wählen Sie im ** Abschnitt ** Zugriffstoken die Option ** Aktivieren aus**.
1. Bestätigen Sie die Aktion.
### Erstellen Sie ein Token
1. Öffnen Sie die DevOps Agent-Web-App für Ihren Agent Space, wählen Sie dann im Navigationsmenü ** Einstellungen ** und anschließend ** Zugriffstoken aus**.
1. Wählen Sie **Generate token (Token erstellen)** aus.
1. Geben Sie einen Namen für das Token ein.
1. Wählen Sie einen Bereich:
+ `read`— Sehen Sie sich Untersuchungen, Empfehlungen, Chats und Agent Space-Ressourcen an.
+ `operate`— Voller Zugriff. Beinhaltet alle Funktionen `read` sowie das Senden von Nachrichten, das Erstellen von Chats und das Verwalten von Backlog-Aufgaben und Empfehlungen.
1. Wählen Sie einen Kundentyp:
+ `human`— Für IDE- und CLI-Nutzung (Kiro, Claude Code, Cursor und andere interaktive Tools).
+ `agent`— Für autonome A2A-Integrationen und programmatische Agenten.
1. Legen Sie ein Ablaufdatum fest (1 bis 60 Tage).
1. Kopieren Sie den Token-Wert und speichern Sie ihn an einem sicheren Ort, z. B. im [AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html). Sie können ihn nicht erneut abrufen.
Nach dem Erstellen eines Tokens zeigt die Web-App ein Konfigurationsbeispiel an, das Sie direkt in Ihren Client kopieren können.
## Verwenden Sie die SigV4-Authentifizierung
Die SigV4-Authentifizierung verwendet Ihre AWS Anmeldeinformationen anstelle eines Zugriffstokens. Das Kiro Power- und das Claude Code-Plugin verfügen über eine integrierte SigV4-Unterstützung`mcp-proxy-for-aws`, die Anfragen mit Ihren lokalen Anmeldeinformationen signiert. AWS
### Wenn SigV4 verwendet wird
+ Als ** Fallback, ** wenn das Zugriffstoken nicht konfiguriert ist oder ausfällt (abgelaufen, ungültig).
+ Als ** primäre ** Authentifizierung, wenn Sie mehrere Agent Spaces haben und `agent_space_id` pro Tool-Aufruf eine Weiterleitung durchführen müssen.
+ Als ** Benutzeroption ** — führen Sie in Claude Code den Setup-Skill aus, um vom Bearer-Token zur SigV4-Authentifizierung zu wechseln.
### Voraussetzungen
+ AWS Anmeldeinformationen, die in der Umgebung verfügbar sind (über SSO, Umgebungsvariablen oder Anmeldeinformationsdatei).
+ Ihre Anmeldeinformationen müssen berechtigt sein, AWS DevOps Agentenaktionen aufzurufen. Die erforderlichen Berechtigungen finden Sie unter [DevOps IAM-Berechtigungen für Agenten](aws-devops-agent-security-devops-agent-iam-permissions.md).
+ `uvx`installiert (der Proxy läuft durch`uvx mcp-proxy-for-aws@latest`).
### Beispielkonfiguration
Um einen MCP-Client so zu konfigurieren, dass er SigV4 anstelle eines Zugriffstokens verwendet, führen Sie den Server durch. `mcp-proxy-for-aws` `{region}`Ersetzen Sie durch die Region Ihres Agentenbereichs (z. B.`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}"
]
}
}
}
```
Der Proxy signiert jede Anfrage mit Ihren lokalen AWS Anmeldeinformationen, sodass kein Zugriffstoken erforderlich ist.
### Multi-Agent-Space Routing
Geben Sie im SigV4-Modus `agent_space_id` bei jedem Toolaufruf an, welcher Agent Space verwendet werden soll. Dadurch ist es möglich, von einem einzigen Client aus mehrere Agent Spaces zu routen.
## Sicherheitsüberlegungen
### Gültigkeitsbereich der Token
+ Verwenden Sie die geringsten Rechte: Wählen Sie diese Option `read` für Integrationen, die nur zum Lesen verwendet werden, `operate` wenn der Client Nachrichten senden oder Aufgaben verwalten muss.
+ Rotieren Sie die Token regelmäßig. Die Token laufen nach der konfigurierten Dauer ab (maximal 60 Tage).
+ Speichern Sie Token in Umgebungsvariablen oder Secrets-Managern. Codieren Sie Tokens nicht fest im Quellcode.
+ Führen Sie Agentenantworten nicht automatisch ohne menschliche Überprüfung aus.
### Liste zugelassener IP-Adressen
Beim Erstellen eines Zugriffstokens können Sie optional eine IP-Zulassungsliste angeben. Wenn das Token konfiguriert ist, kann es nur für die angegebenen IP-Adressen oder CIDR-Bereiche verwendet werden. Anfragen von anderen IP-Adressen werden mit dem Fehler „Zugriff verweigert“ abgelehnt.
### Rotation und Widerruf des Tokens
+ **Rotation ** — Rotiert ein Token, um einen neuen Tokenwert zu generieren, wobei der Name, der Geltungsbereich und die IP-Zulassungsliste des Tokens beibehalten werden. Das alte Token wird sofort ungültig. Aktualisieren Sie Ihre Client-Konfiguration mit dem neuen Token-Wert. Durch Rotation wird auch ein neuer Chatverlauf gestartet — siehe den folgenden Abschnitt.
+ **Widerruf ** — Wenn ein Token kompromittiert ist, widerrufe es sofort. Widerrufene Token können nicht verwendet und nicht wiederhergestellt werden.
#### Chatverlauf und Token-Rotation
Jedes Token hat seinen eigenen Chat-Verlauf. Wenn Sie ein Token rotieren, behandelt der AWS DevOps Agent den neuen Tokenwert als neue Identität. Chats, die Sie mit dem vorherigen Token erstellt haben, werden nicht mehr auf dem Remoteserver angezeigt.
#### Reagiert auf ein kompromittiertes Token
Wenn Sie vermuten, dass ein Token kompromittiert wurde, gehen Sie wie folgt vor:
1. **Allen Token-Zugriff blockieren ** — Öffnen Sie in der AWS DevOps Agent-Konsole Ihren Agent-Bereich, wählen Sie die ** Registerkarte ** Konfiguration und wählen Sie ** im Abschnitt Zugriffstoken die ** Option Deaktivieren aus. Dadurch wird sofort der gesamte tokenbasierte Zugriff auf den Agentenbereich gesperrt.
1. **Kompromittierte Token widerrufen ** — Gehen Sie in der Web-App zu ** Einstellungen ** > ** Zugriffstoken**, wählen Sie das kompromittierte Token aus und wählen Sie Widerrufen. ** ** Du kannst Tokens auch dann widerrufen, wenn die Zugriffstoken deaktiviert sind.
1. **Re-enable Zugriffstoken ** — Nachdem Sie die kompromittierten Token gesperrt haben, aktivieren Sie die Zugriffstoken auf der ** Registerkarte „**Konfiguration“ erneut, falls Sie weiterhin tokenbasierten Zugriff benötigen.
#### Programmgesteuertes Widerrufen von Tokens
Sie können Token auch programmgesteuert mit widerrufen. `awscurl` Die folgenden Befehle verwenden die SigV4-Authentifizierung. Ersetzen Sie die Region (`us-east-1`) durch die Region, in der Ihr Agent Space erstellt wird.
**Hinweis: ** Schritt 1 verwendet die AWS CLI. In den Schritten 2 und 3 wird [ awscurl verwendet](https://github.com/okigan/awscurl), ein Befehlszeilentool, das HTTP-Anfragen mit SigV4 signiert, da Zugriffstoken-Operationen noch keine dedizierten CLI-Befehle haben. AWS
**Schritt 1: Listen Sie Ihre Agent Spaces auf **
```
aws aidevops list-agent-spaces --region us-east-1
```
**Schritt 2: Listet die Zugriffstoken für einen Agentenbereich auf **
```
awscurl --service aidevops --region us-east-1 \
-H "Accept: application/json" \
"https://cp.aidevops.us-east-1.api.aws/v1/agentspaces/{agentSpaceId}/access-tokens"
```
**Schritt 3: Widerrufen Sie ein Token **
```
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"
```
Ersetzen Sie `{agentSpaceId}` und `{accessTokenId}` durch die Werte aus den vorherigen Antworten.
### Rückverfolgbarkeit
AWS DevOps Der Agent zeichnet die Aktivitäten des Remoteservers in auf AWS CloudTrail. Verwenden Sie diese Aufzeichnungen, um nachzuverfolgen, wer einen Remoteserver aufgerufen hat und was der Agent daraufhin getan hat. AWS DevOps Der Agent übermittelt CloudTrail Ereignisse an das AWS Konto, das den Agent Space hostet.
#### Ereignisse bei der Zugriffstoken-Authentifizierung
Jedes Mal, wenn der AWS DevOps Agent ein Zugriffstoken für einen MCP- oder A2A-Endpunkt authentifiziert, sendet er ein Ereignis an. `AuthenticateAccessToken` CloudTrail AWS DevOps Der Agent zeichnet sowohl erfolgreiche als auch fehlgeschlagene Authentifizierungen auf. Verwenden Sie diese Aufzeichnungen, um die legitime Nutzung zu überprüfen und abgelehnte Versuche zu erkennen. Beispiele hierfür sind abgelaufene oder widerrufene Tokens und Anfragen, die durch eine IP-Zulassungsliste blockiert wurden.
Das Ereignis weist die folgenden Merkmale auf:
+ **Quelle des Ereignisses ** — `aidevops.amazonaws.com`
+ **Event name (Ereignisname)** – `AuthenticateAccessToken`
+ **Verwaltungsereignis ** — Das Ereignis ist ein Verwaltungsereignis und nicht schreibgeschützt. Es bleibt also sichtbar, wenn Sie schreibgeschützte Ereignisse herausfiltern.
Das Ereignis umfasst die folgenden Schlüsselfelder:
| Feld | Description |
| --- | --- |
| userIdentity.principalId | Die ID des Zugriffstokens, das präsentiert wurde. |
| userName | Der Name des Zugriffstokens. |
| requestParameters.agentSpaceId | Der Agent Space, gegen den sich das Token authentifiziert. |
| requestParameters.accessTokenId | Die Zugriffstoken-ID. |
| requestParameters.tokenName | Der Name des Zugriffstokens. |
| requestParameters.protocol | Das verwendete Protokoll— MCP oderA2A. |
| responseElements.AuthenticateAccessToken | Das Ergebnis — Success oderFailure. |
| resources | Die Agent Space-Ressource (AWS::AIDevOps::AgentSpace), für die sich das Token authentifiziert, identifiziert durch ihren ARN. |
| additionalEventData.roleSessionName | Für erfolgreiche Authentifizierungen ist dies der Sitzungsname der Downstream-Rolle im folgenden Format. token\_{spaceId}\_{timestamp}\_{tokenName} Verwenden Sie ihn, um die Authentifizierung mit den Aktionen zu korrelieren, die der Agent ausführt. |
| sourceIPAddress | Die IP-Adresse des Clients. |
| userAgent | Die User-Agent Client-Zeichenfolge, sofern verfügbar. |
| errorCode, errorMessage | Bei fehlgeschlagenen Authentifizierungen der Grund, warum die Authentifizierung abgelehnt wurde. |
**Anmerkung**
** AWS DevOps Der Agent zeichnet niemals den Raw-Bearer-Token-Wert auf. In dem Ereignis wird nur die undurchsichtige Zugriffstoken-ID angezeigt.
#### Ereignisse nachgelagerter Aktionen
Wenn Sie ein Zugriffstoken verwenden, übernimmt der AWS DevOps Agent in Ihrem Namen eine Rolle, um Aktionen auszuführen. AWS DevOps Der Agent meldet diesen `AssumeRole` Anruf CloudTrail mit Sitzungs-Tags an, die das Token und den Anrufer identifizieren:
+ `AgentSpaceId`— Bezeichner des Agentenbereichs.
+ `UserId`— Identität des Token-Erstellers.
+ `AccessTokenId`— Eindeutige Kennung des Tokens.
+ `TokenName`— Name des verwendeten Zugriffstokens.
+ `ClientType`— Das verwendete Protokoll (MCP, A2A).
+ `SourceIp`— IP-Adresse des Clients.
+ `UserAgent`— User-Agent Client-Zeichenfolge (falls verfügbar).
Jede Aktion, die der Agent in Ihrem Namen ausführt, hat einen entsprechenden AWS Downstream-API-Aufruf, der CloudTrail protokolliert wird. Der Name der Rollensitzung verwendet das Format`token_{spaceId}_{timestamp}_{tokenName}`. Dieser Sitzungsname entspricht dem `roleSessionName` in der `AuthenticateAccessToken` Veranstaltung. Verwenden Sie ihn, um von einer Authentifizierung bis zu den spezifischen Aktionen, die darauf folgten, nachzuverfolgen.
#### SigV4-Aufrufe
Aufrufe, die die AWS SigV4-Authentifizierung anstelle eines Zugriffstokens verwenden, erzeugen keine Ereignisse. `AuthenticateAccessToken` AWS DevOps Der Agent ordnet SigV4-Anfragen Ihrer AWS Identity and Access Management (IAM) -Identität zu. Sie können die Aktionen, die der Agent ausführt, anhand der von ihm ausgelösten AWS Downstream-API-Aufrufe verfolgen.
### Beschränkung der VPC-Endpunktrichtlinien
Die Remoteserver-Endpunkte unterstützen keine VPC-Endpunktrichtlinien. Aufrufe, die entweder Zugriffstoken oder SigV4-Authentifizierung verwenden, können nicht durch VPC-Endpunktrichtlinien eingeschränkt werden.
### Zugriffstoken deaktivieren
Die Zugriffstoken-Funktion ist standardmäßig deaktiviert. Um sie nach der Aktivierung zu deaktivieren:
1. Öffnen Sie die ** Registerkarte „**Konfiguration“ in Ihrem Agent Space.
1. Wählen Sie im ** Abschnitt ** Zugriffstoken die Option ** Deaktivieren aus**.
Durch die Deaktivierung wird sofort der gesamte tokenbasierte Zugriff gesperrt. Bestehende Token werden nicht gelöscht, können aber erst verwendet werden, wenn die Funktion wieder aktiviert wird.
Um zu verhindern, dass Benutzer in Ihrer Organisation Zugriffstoken aktivieren, erstellen Sie eine Service Control Policy (SCP), die die API-Aktionen für Zugriffstoken und die `UpdateAgentSpace` Aktion (die das Umschalten der Zugriffstoken steuert) verweigert:
**Hinweis: Durch das ** Ablehnen werden `aidevops:UpdateAgentSpace` auch andere Agent Space-Updates (Name, Beschreibung, Gebietsschema) verhindert. Wenn dies zu weit gefasst ist, lassen Sie es im SCP weg. Die verbleibenden Ablehnungen verhindern immer noch die Erstellung und Verwendung von Token, selbst wenn jemand die Funktion aktiviert.
```
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyAccessTokenOperations",
"Effect": "Deny",
"Action": [
"aidevops:UpdateAgentSpace",
"aidevops:CreateAccessToken",
"aidevops:GetAccessToken",
"aidevops:ListAccessTokens",
"aidevops:RotateAccessToken",
"aidevops:RevokeAccessToken"
],
"Resource": "*"
}
]
}
```
## Fehlerbehebung
| Symptom | Ursache | Auflösung |
| --- | --- | --- |
| HTTP 401 Nicht autorisiert | Das Token ist ungültig oder abgelaufen. | Erstellen Sie ein neues Token oder rotieren Sie das vorhandene Token in der Web-App. |
| HTTP 400 "A2A-Version Header erforderlich“ | Fehlender Header für die Protokollversion. Nur A2A v1.0 wird unterstützt. | Fügen Sie A2A-Version: 1.0 A2A-Anfragen einen Header hinzu. |
| HTTP 400 „Der Agentenbereich wurde nicht anhand der Anmeldeinformationen aufgelöst“ | Eine A2A\+-SigV4-Anfrage enthält den X-Agent-Space-Id Header nicht. | Zur X-Agent-Space-Id: Anfrage hinzufügen. |
| Anforderungstimeout | Erste Antworten dauern 5—30 Sekunden. Untersuchungen dauern 5—8 Minuten. | Stellen Sie das Client-Timeout auf mindestens 120 Sekunden ein. |
| Verbindung verweigert | Falsche Endpunkt-URL oder Region. | Überprüfen Sie das URL-Format: https://connect.aidevops.{region}.api.aws |