AWS DevOps Agentensicherheit

Arbeitet unabhängig mit eigenen Konfigurationen und Berechtigungen

Definiert, AWS auf welche Konten und Ressourcen der Agent zugreifen kann

Stellt Verbindungen zu Plattformen von Drittanbietern her

Inferenzanfragen mit Ursprung in der Europäischen Union werden innerhalb der Europäischen Union bearbeitet.

Inferenzanfragen mit Ursprung in den Vereinigte Staaten werden in den Vereinigte Staaten bearbeitet.

Inferenzanfragen mit Ursprung in Australien werden innerhalb Australien bearbeitet.

Inferenzanfragen mit Ursprung in Japan werden innerhalb Japan bearbeitet.

Wenn eine Inferenzanfrage aus einem Gebiet stammt, das nicht aufgeführt ist, wird sie standardmäßig in den Vereinigte Staaten bearbeitet.

DevOps Agent und Bedrock sind nicht von Kundenrichtlinien in Service Control Policies (SCPs) oder Control Tower betroffen, die Kundeninhalte auf bestimmte Regionen beschränken.

Bedrock kann andere Regionen als die Ursprungsregion innerhalb Ihrer Region verwenden, um staatenlose Inferenzen durchzuführen, um Leistung und Verfügbarkeit zu optimieren

AWS Identity Center-Integration — Die primäre Authentifizierungsmethode verwendet OAuth 2.0 mit sitzungsbasierter Authentifizierung, die nur HTTP-Cookies verwendet. AWS Identity Center kann sich über Standard-OIDC- und SAML-Protokolle mit externen Identitätsanbietern verbinden, darunter Anbieter wie Okta, Ping Identity und Microsoft Entra ID. Diese Methode unterstützt die Multi-Faktor-Authentifizierung über Ihren Identitätsanbieter. AWS Identity Center verwendet standardmäßig eine Sitzungsdauer von bis zu 12 Stunden und kann auf eine gewünschte Dauer konfiguriert werden.

IAM-Authentifizierungslink — Eine alternative Methode ermöglicht den direkten Zugriff auf die Web-App von der AWS Management Console aus mithilfe von JWT-basierten Tokens, die aus einer bestehenden Management Console-Sitzung stammen. AWS Diese Option ist nützlich, um den AWS DevOps Agenten vor der Implementierung der vollständigen Identity Center-Integration zu testen und Administratorzugriff zu erhalten, falls die AWS DevOps Agent-Web-App durch die Identity Center-basierte Authentifizierung nicht mehr zugänglich ist. Die Sitzungen sind auf 10 Minuten begrenzt.

Primäre Kontorolle — Gewährt dem Agenten Zugriff auf Ressourcen in dem AWS Konto, in dem Sie den Agent Space erstellen, sowie Zugriff auf sekundäre Kontorollen.

Sekundäre Kontorollen — Gewährt dem Agenten Zugriff auf Ressourcen in zusätzlichen AWS Konten, die mit dem Agent Space verbunden sind.

Web-App-Rolle — Gewährt Benutzern Zugriff auf die Ermittlungsdaten und Ergebnisse des AWS DevOps Agenten in der Web-App.

Verschlüsselung im Ruhezustand — Alle Daten werden mit AWS verwalteten Schlüsseln verschlüsselt.

Verschlüsselung bei der Übertragung — Alle abgerufenen Protokolle, Metriken, Wissenselemente, Ticket-Metadaten und andere Daten werden bei der Übertragung innerhalb des privaten Netzwerks des Agenten und in externe Netzwerke verschlüsselt.

Protokollieren Sie alle Argumentationsschritte und ergriffenen Maßnahmen

Schaffen Sie vollständige Transparenz in den Entscheidungsprozessen der Agenten

Kann von den Agenten nach der Aufzeichnung nicht geändert werden, wodurch Angriffe, wie z. B. die sofortige Injektion, durch das Verbergen wichtiger Aktionen minimiert werden

Schließt alle Chat-Nachrichten von der Investigation-Seite ein

Die Anfrage, die an den Agenten gestellt wurde

Die IP-Adresse, von der die Anforderung erfolgt ist

Wer die Anforderung gestellt hat

Wann sie gestellt wurde.

Eingeschränkte Schreibmöglichkeiten — Die Tools, die dem Agenten zur Verfügung stehen, sind nicht in der Lage, Ressourcen zu verändern, mit Ausnahme von Tickets und Supportanfragen. Dadurch wird verhindert, dass böswillige Anweisungen Ihre Infrastruktur oder Anwendungen verändern.

Durchsetzung von Kontogrenzen — Der AWS DevOps Agent arbeitet nur innerhalb der Grenzen, die durch die Rollen, die dem Agenten in den primären und verbundenen sekundären AWS Konten zugewiesen wurden, zulässig sind. Der Agent kann nicht auf Ressourcen außerhalb seines konfigurierten Bereichs zugreifen oder diese ändern.

KI-Sicherheitsschutz — AWS DevOps Der Agent verwendet Modelle mit AI Safety Level 3 (ASL-3) -Schutz. Zu diesen Schutzmaßnahmen gehören Klassifikatoren, die Prompt-Injection-Angriffe erkennen und verhindern, bevor sie das Verhalten der Agenten beeinflussen können.

Unveränderlicher Prüfpfad — Das Agenten-Journal protokolliert alle Argumentationsschritte und ergriffenen Maßnahmen. Journaleinträge können vom Agenten nicht mehr geändert werden, sobald sie einmal aufgezeichnet wurden, wodurch verhindert wird, dass Prompt-Injection-Angriffe böswillige Aktionen verbergen.

Benutzerdefinierte MCP-Servertools — Die bring-your-own MCP-Funktion ermöglicht es Ihnen, benutzerdefinierte Tools für den Agenten einzuführen, was zusätzliche Möglichkeiten für eine sofortige Injektion bieten kann. Benutzerdefinierte Tools verfügen möglicherweise nicht über dieselben Sicherheitskontrollen wie native AWS DevOps Agent-Tools, und böswillige Anweisungen könnten diese Tools möglicherweise auf unbeabsichtigte Weise nutzen. Weitere Informationen finden Sie im Abschnitt Modell der geteilten Verantwortung.

Angriffe durch autorisierte Benutzer — Benutzer, die autorisiert sind, innerhalb der AWS Kontogrenzen oder verbundener Tools zu agieren, haben ein höheres Risiko, einen Angriff auf den Agenten zu versuchen. Diese Benutzer haben möglicherweise die Möglichkeit, Datenquellen zu ändern, die der Agent verwendet, z. B. Protokolle oder Ressourcen-Tags, wodurch es einfacher wird, bösartige Anweisungen einzubetten, die der Agent verarbeitet.

Native bidirektionale Integrationen — Integrierte Integrationen, die Daten an den Agenten senden und Updates vom Agenten empfangen können. Dabei werden die Authentifizierungsmethoden des Anbieters verwendet

MCP-Server — Remote Model Context Protocol-Server, die OAuth 2.0-Authentifizierungsabläufe und API-Schlüssel verwenden, um sicher mit externen Systemen zu kommunizieren.

Webhook-Trigger — Ermittlungsauslöser, die von Remote-Diensten wie Tickets oder Observability-Systemen ausgelöst werden. Webhooks verwenden aus Sicherheitsgründen den Hash-basierten Message Authentication Code (HMAC).

Ausgehende Kommunikation — Integrationen wie Slack und Ticketsysteme erhalten Updates vom Agenten, unterstützen aber noch keine bidirektionale Kommunikation.

GitHub— Verwendet OAuth Flow für die Authentifizierung. Nach der Registrierung GitHub auf Kontoebene kann jeder Agent Space eine Verbindung zu bestimmten Repositorys innerhalb Ihrer GitHub Organisation herstellen.

Dynatrace — Verwendet OAuth Token-Authentifizierung. Nach der Registrierung von Dynatrace auf Kontoebene kann sich jeder Agent Space mit bestimmten Dynatrace-Umgebungen oder Überwachungskonfigurationen verbinden.

Slack — Verwendet Token-Authentifizierung. OAuth Nach der Registrierung von Slack auf Kontoebene kann sich jeder Agent Space mit bestimmten Channel-Kanälen von Slack verbinden.

Datadog — Verwendet MCP mit Flow zur Authentifizierung. OAuth Nach der Registrierung von Datadog auf Kontoebene kann jeder Agent Space eine Verbindung zu bestimmten Datadog-Monitoring-Ressourcen herstellen.

New Relic — Verwendet die API-Schlüsselauthentifizierung. Nach der Registrierung von New Relic auf Kontoebene kann jeder Agent Space eine Verbindung zu bestimmten New Relic-Überwachungskonfigurationen herstellen.

Splunk — Verwendet die Bearer-Token-Authentifizierung. Nach der Registrierung von Splunk auf Kontoebene kann jeder Agent Space eine Verbindung zu bestimmten Splunk-Datenquellen herstellen.

GitLab— Verwendet die Zugriffstoken-Authentifizierung. Nach der Registrierung GitLab auf Kontoebene kann jeder Agent Space eine Verbindung zu bestimmten GitLab Repositorys herstellen.

ServiceNow— Verwendet die OAuth key/token Client-Authentifizierung. Nach der Registrierung ServiceNow auf Kontoebene kann jeder Agent Space eine Verbindung zu bestimmten ServiceNow Instanzen oder Ticketwarteschlangen herstellen.

Allgemein zugängliche Remote-MCP-Server — Verwenden Sie OAuth Flow für die Authentifizierung. Nach der Registrierung eines Remote-MCP-Servers auf Kontoebene kann jeder Agent Space eine Verbindung zu bestimmten Ressourcen herstellen, die von diesem Server verfügbar gemacht werden.

Privat gehostete Tools — Wenn Ihre Tools von einer AWS VPC aus erreichbar sind, können Sie private AWS DevOps Agentenverbindungen verwenden, um den Datenverkehr zu AWS Netzwerken zu isolieren und vom öffentlichen Internet fernzuhalten. Weitere Informationen finden Sie unter Verbindung zu privat gehosteten Tools herstellen.

Öffentlich gehostete Tools — Wenn Ihre Tools über das öffentliche Internet erreichbar sind und IP-Allowlisting- oder Firewallregeln verwenden, müssen Sie eingehenden Datenverkehr von den folgenden AWS DevOps Agent-Quell-IP-Adressen zulassen:

Aufrechterhaltung der Sicherheit der vom Agenten abgerufenen Daten

Sicherung systemeigener Tools, die vom Agenten verwendet werden können

Schutz der Infrastruktur, auf der der AWS DevOps Agent ausgeführt wird

Verwaltung des Benutzerzugriffs auf den Agentenbereich

Beschränkung des Zugriffs auf vertrauenswürdige Benutzer externer Systeme, die Eingaben für den Agenten bereitstellen, z. B. Dienste und Ressourcen, die Protokolle, CloudTrail Ereignisse, Tickets und mehr erstellen, die für böswillige Prompt-Injection-Versuche verwendet werden können.

Stellen Sie sicher, dass alle verbundenen Datenquellen über vertrauenswürdige Daten verfügen, die wahrscheinlich nicht für Prompt-Injection-Angriffe verwendet werden

Stellen Sie sicher, dass die bring-your-own MCP-Serverintegrationen sicher funktionieren

Stellen Sie sicher, dass die dem Agenten zugewiesenen IAM-Rollen den richtigen Umfang haben

Bearbeitung personenbezogener Daten vor der Speicherung in Observability-Logs und anderen Agentendatenquellen

Wir halten uns an die empfohlene Vorgehensweise, verbundenen Datenquellen, einschließlich MCP-Servern, nur Leseberechtigungen zu gewähren bring-your-own