AWS DevOps Sécurité des agents

Fonctionne indépendamment avec ses propres configurations et autorisations

Définit AWS les comptes et les ressources auxquels l'agent peut accéder

Établit des connexions à des plateformes tierces

Les demandes d'inférence provenant de l'Union européenne seront traitées au sein de l'Union européenne.

Les demandes d'inférence provenant des États-Unis seront traitées aux États-Unis.

Les demandes d'inférence provenant de l'Australie seront traitées en Australie.

Les demandes d'inférence provenant du Japon seront traitées au Japon.

Si une demande d'inférence provient d'une zone non répertoriée, elle sera traitée par défaut aux États-Unis.

DevOps L'agent et Bedrock ne sont pas concernés par les politiques relatives aux clients figurant dans les politiques de contrôle des services (SCP) ou dans la tour de contrôle qui limitent le contenu client à des régions spécifiques

Bedrock peut utiliser des régions autres que la région d'origine de votre zone géographique pour effectuer une inférence sans état afin d'optimiser les performances et la disponibilité

Asie-Pacifique (Singapour) – ap-southeast-1

Asie-Pacifique (Mumbai) – ap-south-1

Amérique du Sud (São Paulo) – sa-east-1

AWS Intégration à Identity Center  : la principale méthode d'authentification utilise OAuth 2.0 avec une authentification basée sur les sessions à l'aide de cookies. HTTP-only AWS Identity Center peut se fédérer avec des fournisseurs d'identité externes via des protocoles OIDC et SAML standard, notamment des fournisseurs tels qu'Okta, Ping Identity et Microsoft Entra ID. Cette méthode prend en charge l'authentification multifactorielle via votre fournisseur d'identité. AWS Identity Center fixe par défaut des durées de session allant jusqu'à 12 heures et peut être configuré selon la durée souhaitée.

Lien d'authentification IAM  : une autre méthode permet d'accéder directement à l'application Web depuis la console de AWS gestion à l'aide de JWT-based jetons dérivés d'une session de console de AWS gestion existante. Cette option est utile pour évaluer l' AWS DevOps agent avant de mettre en œuvre l'intégration complète d'Identity Center et pour obtenir un accès administratif si l'application Web de l' AWS DevOps agent devient inaccessible via l'authentification basée sur Identity Center. Les sessions sont limitées à 10 minutes.

Rôle du compte principal  : permet à l'agent d'accéder aux ressources du AWS compte sur lequel vous créez l'espace agent.

Rôles du compte secondaire  : permet à l'agent d'accéder aux ressources de AWS comptes supplémentaires connectés à l'espace agent.

Rôle dans l'application Web  : permet aux utilisateurs d'accéder aux données d'enquête et aux conclusions de l' AWS DevOps agent dans l'application Web.

Chiffrement au repos  : toutes les données sont cryptées à l'aide de clés AWS gérées.

Chiffrement en transit  : tous les journaux, métriques, éléments de connaissance, métadonnées des tickets et autres données récupérés sont chiffrés en transit sur le réseau privé de l'agent et vers des réseaux extérieurs.

Enregistrez chaque étape de raisonnement et chaque action entreprise

Créez une transparence totale dans les processus de prise de décision des agents

Ne peut pas être modifié par les agents une fois enregistrés, ce qui permet de minimiser les attaques telles que l'injection rapide ou la masquage d'actions importantes

Incluez tous les messages de chat de la page Enquête

La demande qui a été faite à l'agent

L’adresse IP à partir de laquelle la demande a été effectuée

La personne ayant effectué la demande

Le moment où la demande a été formulée

Capacités d'écriture limitées  : les outils mis à la disposition de l'agent ne sont pas en mesure de modifier les ressources, à l'exception de l'ouverture des tickets et des demandes de support. Cela empêche les instructions malveillantes de modifier votre infrastructure ou vos applications.

Application des limites de compte — L' AWS DevOps agent agit uniquement dans les limites autorisées par les rôles attribués à l'agent dans les AWS comptes principal et secondaire connecté. L'agent ne peut pas accéder aux ressources ni les modifier en dehors de son périmètre configuré.

Protections de sécurité basées sur l'IA — AWS DevOps L'agent utilise des modèles dotés de protections de niveau de sécurité IA 3 (ASL-3), qui incluent des classificateurs intégrés qui détectent et résistent aux tentatives d'injection rapides. L'agent utilise également le filtre d'attaque rapide Amazon Bedrock Guardrails pour détecter et bloquer les tentatives d'injection rapide et de jailbreak avant qu'elles n'affectent le comportement de l'agent.

Piste d'audit immuable — Le journal de l'agent enregistre chaque étape du raisonnement et chaque action entreprise. Les entrées de journal ne peuvent pas être modifiées par l'agent une fois enregistrées, ce qui empêche les attaques par injection rapide de masquer des actions malveillantes.

Outils de serveur MCP personnalisés  : la fonctionnalité MCP à apporter vous-même vous permet d'introduire des outils personnalisés dans l'agent, ce qui peut offrir des possibilités supplémentaires d'injection rapide. Les outils personnalisés peuvent ne pas disposer des mêmes contrôles de sécurité que les outils d' AWS DevOps agent natifs, et des instructions malveillantes peuvent potentiellement utiliser ces outils de manière involontaire. Consultez la section Modèle de responsabilité partagée pour en savoir plus.

Attaques d'utilisateurs autorisés — Les utilisateurs autorisés à opérer dans les limites du AWS compte ou des outils connectés ont plus de chances de tenter une attaque contre l'agent. Ces utilisateurs peuvent avoir la possibilité de modifier les sources de données consommées par l'agent, telles que les journaux ou les balises de ressources, afin de faciliter l'intégration d'instructions malveillantes que l'agent traitera.

Intégrations bidirectionnelles natives  : Built-in intégrations qui peuvent envoyer des données à l'agent et recevoir des mises à jour de la part de l'agent. Cela utilise les méthodes d'authentification du fournisseur

Serveurs MCP  : serveurs Remote Model Context Protocol qui utilisent les flux d'authentification OAuth 2.0 et les clés API pour communiquer en toute sécurité avec des systèmes externes.

Déclencheurs Webhook  : déclencheurs d'investigation provenant de services distants tels que des tickets ou des systèmes d'observabilité. Les webhooks utilisent soit des signatures HMAC ( Hash-based Message Authentication Code), soit une clé API (jeton porteur) pour des raisons de sécurité.

Communication sortante  : les intégrations telles que Slack et les systèmes de billetterie reçoivent des mises à jour de la part de l'agent mais ne prennent pas encore en charge la communication bidirectionnelle.

GitHub— Utilise le flux OAuth pour l'authentification. Après s'être enregistré GitHub au niveau du compte, chaque espace d'agent peut se connecter à des référentiels spécifiques au sein de votre GitHub organisation.

Dynatrace — Utilise l'authentification par jeton OAuth. Après avoir enregistré Dynatrace au niveau du compte, chaque espace d'agent peut se connecter à des environnements Dynatrace ou à des configurations de surveillance spécifiques.

Slack  : utilise l'authentification par jeton OAuth. Après avoir enregistré Slack au niveau du compte, chaque espace d'agent peut se connecter à des chaînes Slack spécifiques.

Datadog  : utilise MCP avec le flux OAuth pour l'authentification. Après avoir enregistré Datadog au niveau du compte, chaque espace d'agent peut se connecter à des ressources de supervision Datadog spécifiques.

New Relic — Utilise l'authentification par clé API. Après avoir enregistré New Relic au niveau du compte, chaque espace d'agent peut se connecter à des configurations de surveillance New Relic spécifiques.

Splunk — Utilise l'authentification par jeton du porteur. Après avoir enregistré Splunk au niveau du compte, chaque espace d'agent peut se connecter à des sources de données Splunk spécifiques.

GitLab— Utilise l'authentification par jeton d'accès. Après s'être enregistré GitLab au niveau du compte, chaque espace d'agent peut se connecter à des GitLab référentiels spécifiques.

ServiceNow— Utilise l'authentification du client key/token OAuth. Après s'être enregistré ServiceNow au niveau du compte, chaque espace d'agent peut se connecter à des ServiceNow instances ou à des files d'attente de tickets spécifiques.

Serveurs MCP distants accessibles au public  : utilisez le flux OAuth pour l'authentification. Après avoir enregistré un serveur MCP distant au niveau du compte, chaque espace d'agent peut se connecter à des ressources spécifiques exposées par ce serveur.

Outils hébergés en privé  : si vos outils sont accessibles depuis un AWS VPC, vous pouvez utiliser les connexions privées des AWS DevOps agents pour isoler le trafic des AWS réseaux et hors de l'Internet public. Pour de plus amples informations, veuillez consulter Connexion à des outils hébergés en privé.

Outils hébergés publiquement  : si vos outils sont accessibles via Internet public et utilisent des règles de liste d'adresses IP ou de pare-feu, vous devez autoriser le trafic entrant en provenance des adresses IP sources de l' AWS DevOps agent suivantes :

Maintien de la sécurité des données récupérées par l'agent

Sécurisation des outils natifs disponibles pour l'agent

Protection de l'infrastructure qui exécute AWS DevOps l'agent

Gestion de l'accès des utilisateurs à l'espace agent

Limiter l'accès aux utilisateurs fiables des systèmes externes qui fournissent des entrées à l'agent, tels que les services et les ressources qui génèrent des journaux, CloudTrail des événements, des tickets, etc., qui peuvent être utilisés pour tenter une injection rapide malveillante.

Assurez-vous que toutes les sources de données connectées disposent de données fiables qui ne seront probablement pas utilisées pour tenter des attaques par injection rapide

Garantir que les intégrations de serveurs MCP à emporter soi-même fonctionnent en toute sécurité

S'assurer que les rôles IAM attribués à l'agent sont correctement définis

Rédaction des données PII avant de les stocker dans des journaux d'observabilité et d'autres sources de données d'agent

Suivre la pratique recommandée qui consiste à n'accorder que des autorisations en lecture seule aux sources de données connectées, y compris aux serveurs MCP à emporter