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, die ihren Ursprung in der Europäischen Union haben, werden innerhalb der Europäischen Union bearbeitet.

Inferenzanfragen mit Ursprung in den Vereinigten Staaten werden innerhalb der Vereinigten Staaten bearbeitet.

Inferenzanfragen mit Ursprung in Australien werden in Australien bearbeitet.

Inferenzanfragen, die ihren Ursprung in Japan haben, werden in Japan bearbeitet.

Wenn eine Inferenzanfrage aus einem nicht aufgeführten Gebiet stammt, wird sie standardmäßig innerhalb der Vereinigten 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 verwendet möglicherweise andere Regionen als die ursprüngliche Region in Ihrer Region, um statusfreie Inferenzen durchzuführen und so die Leistung und Verfügbarkeit zu optimieren

Asia Pacific (Singapore) – ap-southeast-1

Asia Pacific (Mumbai) – ap-south-1

Südamerika (São Paulo) – sa-east-1

AWS Identity Center-Integration — Die primäre Authentifizierungsmethode verwendet OAuth 2.0 mit sitzungsbasierter Authentifizierung mithilfe von Cookies. HTTP-only AWS Identity Center kann über Standard-OIDC- und SAML-Protokolle eine Verbindung zu externen Identitätsanbietern herstellen, einschließlich Anbietern wie Okta, Ping Identity und Microsoft Entra ID. Diese Methode unterstützt die mehrstufige Authentifizierung durch 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-based Tokens, die aus einer vorhandenen AWS Management Console-Sitzung stammen. 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 der Zugriff auf die AWS DevOps Agenten-Web-App über die Identity Center-basierte Authentifizierung nicht mehr möglich 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 Agentenbereich erstellen.

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

Web-App-Rolle — Gewährt Benutzern Zugriff auf Ermittlungsdaten und Ergebnisse von 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, Kennzahlen, Wissenselemente, Ticket-Metadaten und andere Daten werden bei der Übertragung innerhalb des privaten Netzwerks des Agenten und zu externen Netzwerken verschlüsselt.

Protokollieren Sie alle Überlegungen, Schritte und ergriffenen Maßnahmen

Schaffen Sie vollständige Transparenz über die Entscheidungsprozesse der Agenten

Kann von den Agenten nicht geändert werden, wenn sie einmal aufgezeichnet wurden. Dadurch werden Angriffe wie Prompt-Injection minimiert, sodass wichtige Aktionen nicht ausgeblendet werden

Schließt alle Chat-Nachrichten von der Seite „Untersuchung“ 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 Schreibfunktionen — Die Tools, die dem Agenten zur Verfügung stehen, sind nicht in der Lage, Ressourcen zu verändern, mit Ausnahme des Öffnens von Tickets und Support-Anfragen. Dadurch wird verhindert, dass böswillige Anweisungen Ihre Infrastruktur oder Anwendungen verändern.

Durchsetzung der Kontogrenzen — Der AWS DevOps Agent arbeitet nur innerhalb der Grenzen, die die Rollen zulassen, die dem Agenten im primären und verbundenen sekundären AWS Konto zugewiesen sind. Der Agent kann nicht auf Ressourcen zugreifen oder diese ändern, die außerhalb seines konfigurierten Bereichs liegen.

KI-Sicherheitsschutz — AWS DevOps Der Agent verwendet Modelle mit Schutzmaßnahmen der KI-Sicherheitsstufe 3 (ASL-3), die integrierte Klassifikatoren enthalten, die Versuche einer sofortigen Injektion erkennen und ihnen widerstehen. Der Agent verwendet außerdem den Prompt-Angriffsfilter von Amazon Bedrock Guardrails, um Prompt-Injections- und Jailbreak-Versuche zu erkennen und zu blockieren, bevor sie das Verhalten des Agenten beeinflussen können.

Unveränderlicher Audit-Trail — Das Agenten-Journal protokolliert jeden Schritt zur Argumentation und die ergriffenen Maßnahmen. Journaleinträge können vom Agenten nicht mehr geändert werden, sobald sie aufgezeichnet wurden. Dadurch wird verhindert, dass durch Prompt-Injection-Angriffe bösartige Aktionen verborgen werden.

Benutzerdefinierte MCP-Servertools — Mit der Funktion „Bring-your-own MCP“ können Sie dem Agenten benutzerdefinierte Tools zur Verfügung stellen, was zusätzliche Möglichkeiten für eine schnelle Injection 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 nutzt, z. B. Protokolle oder Ressourcen-Tags, sodass böswillige Anweisungen, die der Agent verarbeitet, einfacher einbetten können.

Native bidirektionale Integrationen — Built-in 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 — Untersuchungen werden von Remote-Diensten wie Tickets oder Beobachtungssystemen ausgelöst. Webhooks verwenden aus Sicherheitsgründen entweder HMAC-Signaturen ( Hash-based Message Authentication Code) oder einen API-Schlüssel (Bearer-Token).

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

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

Dynatrace — Verwendet die OAuth-Token-Authentifizierung. Nach der Registrierung von Dynatrace auf Kontoebene kann jeder Agent Space eine Verbindung zu bestimmten Dynatrace-Umgebungen oder Überwachungskonfigurationen herstellen.

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

Datadog — Verwendet MCP mit OAuth-Flow zur Authentifizierung. Nach der Registrierung von Datadog auf Kontoebene kann jeder Agent Space eine Verbindung zu bestimmten Datadog-Überwachungsressourcen 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 Inhaber-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-Client-Authentifizierung. key/token Nach der Registrierung ServiceNow auf Kontoebene kann jeder Agent Space eine Verbindung zu bestimmten ServiceNow Instanzen oder Ticketwarteschlangen herstellen.

Allgemein öffentlich zugängliche Remote-MCP-Server — Verwenden Sie den 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 bereitgestellt 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 von AWS Netzwerken 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 der systemeigenen Tools, die dem Agenten zur Verfügung stehen

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

Verwaltung des Benutzerzugriffs auf den Agentenbereich

Beschränken Sie den Zugriff 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 — mit denen versucht werden kann, böswillige Eingabeaufforderungen einzuschleusen.

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 Bring-Your-Own-MCP-Serverintegrationen sicher funktionieren

Sicherstellen, dass die dem Agenten zugewiesenen IAM-Rollen den richtigen Geltungsbereich haben

Redigieren von PII-Daten vor dem Speichern in Observability-Protokollen und anderen Agentendatenquellen

Halten Sie sich an die empfohlene Praxis, verbundenen Datenquellen, einschließlich eigener MCP-Server, nur Leseberechtigungen zu gewähren