AWS DevOps Sécurité des agents

Ce document fournit des informations sur les considérations de sécurité, la protection des données, les contrôles d'accès et les fonctionnalités de conformité de AWS DevOps l'Agent. Utilisez ces informations pour comprendre comment AWS DevOps l'agent est conçu pour répondre à vos exigences de sécurité et de conformité.

Sécurité à plusieurs niveaux

AWS DevOps L'agent implémente la sécurité à plusieurs niveaux. Même si des autorisations plus larges sont accordées au rôle IAM de l'agent, celui-ci applique ses propres contrôles d'accès internes afin de limiter la portée de ses actions. Par exemple, si un client ajoute une politique IAM d'accès complète à Amazon S3 au rôle IAM de l' AWS DevOps agent, celui-ci veillera à ce que seuls les journaux lus après le AWSLogs préfixe soient lus à des fins de résolution des problèmes.

Nous recommandons de suivre le principe du moindre privilège lors de la configuration des autorisations IAM pour AWS DevOps l'agent et de mettre en œuvre la sécurité à plusieurs niveaux. Une défense approfondie garantit qu'aucune erreur de configuration ne peut compromettre la sécurité de votre environnement.

Espaces réservés aux agents

Les espaces d'agent constituent la principale limite de sécurité dans AWS DevOps Agent. Chaque espace d'agent :

• 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 espaces d'agent maintiennent une isolation stricte afin de garantir la sécurité et d'empêcher tout accès involontaire entre différents environnements ou équipes.

Traitement régional et flux de données

AWS DevOps L'agent opère dans le monde entier avec des capacités de traitement régionales. L'agent récupère les données opérationnelles des AWS régions de tous les AWS comptes autorisés à accéder au sein de l'espace agent configuré. Cette collecte de données multi-régions entre comptes garantit une analyse complète des incidents tout en respectant les limites géographiques pour le traitement des inférences.

Utilisation d'Amazon Bedrock et inférence entre régions

AWS DevOps L'agent sélectionnera automatiquement la région optimale de votre zone géographique pour traiter vos demandes d'inférence. Cela permet d'optimiser les ressources informatiques disponibles, la disponibilité des modèles et d'offrir la meilleure expérience client. Vos données resteront stockées uniquement dans la région où votre espace agent a été créé. Toutefois, les demandes de saisie et les résultats de sortie peuvent être traités en dehors de cette région, comme décrit dans la liste suivante. Toutes les données seront transmises chiffrées sur le réseau sécurisé d’Amazon.

AWS DevOps L'agent acheminera en toute sécurité vos demandes d'inférence vers les ressources informatiques disponibles dans la zone géographique d'origine de la demande, comme suit :

• 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 d'Amérique.

• DevOps Agent et Bedrock ne sont pas concernés par les politiques relatives aux clients énoncées dans Service Control Policies (SCPs) ou Control Tower qui limitent le contenu client à des régions spécifiques

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

Gestion des identités et des accès

Méthodes d’authentification

AWS DevOps L'agent propose deux méthodes d'authentification pour se connecter à l'application Web AWS DevOps Agent Space :

• AWS Intégration à Identity Center : la principale méthode d'authentification utilise la OAuth version 2.0 avec une authentification basée sur les sessions à l'aide de cookies HTTP uniquement. AWS Identity Center peut se fédérer avec des fournisseurs d'identité externes via les 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 par le biais de votre fournisseur d'identité. AWS Identity Center utilise par défaut des sessions d'une durée maximale de 12 heures et peut être configuré selon la durée souhaitée.

• Lien d'authentification IAM : une autre méthode fournit un accès direct à l'application Web depuis la console de AWS gestion à l'aide de jetons JWT dérivés d'une session de console de gestion existante AWS . Cette option est utile pour évaluer l' AWS DevOps agent avant de mettre en œuvre l'intégration complète d'Identity Center, ainsi que 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 séances sont limitées à 10 minutes.

Rôles IAM

AWS DevOps L'agent utilise les rôles IAM pour définir les autorisations d'accès :

• Rôle de compte principal : accorde à l'agent l'accès aux ressources du AWS compte sur lequel vous créez l'espace d'agent ainsi que l'accès aux rôles de compte secondaires.

• Rôles de compte secondaires — Permet à l'agent d'accéder aux ressources de AWS comptes supplémentaires connectés à l'espace agent.

• Rôle d'application Web — Permet aux utilisateurs d'accéder aux données et aux résultats des enquêtes de l' AWS DevOps agent dans l'application Web.

Ces rôles doivent être configurés selon le principe du moindre privilège, en accordant uniquement les autorisations de lecture seule nécessaires aux enquêtes.

Protection des données

Chiffrement des données

AWS DevOps L'agent chiffre toutes les données des clients :

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

• Chiffrement en transit : tous les journaux, indicateurs, éléments de connaissances, métadonnées des tickets et autres données récupérés sont chiffrés pendant le transfert au sein du réseau privé de l'agent et vers des réseaux externes.

Stockage et conservation des données

Les données sont stockées dans la région où votre espace d'agent a été créé, tandis que le traitement des inférences peut avoir lieu dans votre zone géographique, comme décrit dans la section sur l'utilisation d'Amazon Bedrock ci-dessus.

Informations personnelles identifiables (PII)

AWS DevOps L'agent ne filtre pas les informations personnelles lorsqu'il résume les données collectées lors d'enquêtes, d'évaluations de recommandations ou de réponses au chat. Il est recommandé de supprimer les données d'identification personnelle avant de les stocker dans des journaux d'observabilité.

Journal de l'agent et journalisation des audits

Journal de l'agent

Les fonctionnalités d'investigation et de prévention des incidents tiennent à jour des journaux détaillés qui :

• Enregistrez chaque étape de raisonnement et chaque action entreprise

• Créez une transparence totale dans les processus décisionnels des agents

• Ne peut pas être modifié par les agents une fois enregistré, ce qui permet de minimiser les attaques telles que l'injection rapide pour masquer des actions importantes

• Inclure tous les messages de chat de la page d'investigation

AWS CloudTrail intégration

Tous les appels d'API de l' AWS DevOps agent sont automatiquement AWS CloudTrail capturés par le AWS compte d'hébergement. À l'aide des informations collectées par CloudTrail, vous pouvez déterminer :

• 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

Protection contre les injections rapides

Une attaque par injection rapide se produit lorsqu'un attaquant intègre des instructions malveillantes dans des données externes, telles qu'une page Web ou un document, qu'un système d'IA générative traitera ultérieurement. AWS DevOps L'agent consomme nativement de nombreuses sources de données dans le cadre de ses opérations normales, notamment les journaux, les balises de ressources et d'autres données opérationnelles. AWS DevOps L'agent protège contre les attaques par injection rapide grâce aux mesures de protection ci-dessous, mais il est important de s'assurer que toutes les sources de données connectées et l'accès des utilisateurs à ces sources de données sont fiables. Voir la section Modèle de responsabilité partagée pour en savoir plus.

Garanties d'injection rapide :

• 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 de tickets et de demandes d'assistance. Cela empêche les instructions malveillantes de modifier votre infrastructure ou vos applications.

• Application des limites de compte — AWS DevOps L'agent n'opère que dans les limites autorisées par les rôles assignés à l'agent dans le compte principal et le AWS compte secondaire connecté. L'agent ne peut pas accéder aux ressources ou 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 3 (ASL-3) basées sur l'IA. Ces protections incluent des classificateurs qui détectent et empêchent les attaques par injection rapide avant qu'elles n'affectent le comportement des agents.

• Piste d'audit immuable : le journal de l'agent enregistre chaque étape de raisonnement et chaque action entreprise. Les entrées du 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.

Bien que AWS DevOps l'agent fournisse plusieurs niveaux de protection contre les attaques par injection rapide, certaines configurations peuvent augmenter les risques :

• Outils de serveur MCP personnalisés — La fonctionnalité bring-your-own MCP vous permet d'introduire des outils personnalisés dans l'agent, ce qui peut offrir des opportunités supplémentaires d'injection rapide. Les outils personnalisés peuvent ne pas avoir les mêmes contrôles de sécurité que les outils d' AWS DevOps agent natifs, et des instructions malveillantes peuvent potentiellement exploiter ces outils de manière involontaire. Voir 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.

Pour atténuer ces risques :

1. Passez en revue et testez attentivement les serveurs MCP personnalisés avant de les déployer dans Agent Spaces.

   1. Assurez-vous qu'ils ne sont autorisés à effectuer que des actions en lecture seule

   2. Vérifiez que les utilisateurs des outils externes auxquels accèdent les serveurs MCP sont des entités fiables, car les AWS DevOps agents interagissant avec MCP s'appuient sur la relation de confiance implicite établie entre ces utilisateurs d'outils et l'agent AWS DevOps

2. Appliquer le principe du moindre privilège lorsque vous accordez aux utilisateurs l'accès aux systèmes qui fournissent des données à l'agent

3. Vérifiez régulièrement quels serveurs MCP sont connectés à vos agents Spaces

4. Étant donné que tout contenu extrait de la liste d'autorisation URLs peut tenter de manipuler le comportement de l'agent, n'incluez que des sources fiables dans votre liste d'autorisation.

Sécurité de l'intégration

AWS DevOps L'agent prend en charge plusieurs types d'intégration, chacun ayant son propre modèle de sécurité :

• Intégrations bidirectionnelles natives : intégrations intégrées 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 des flux d'authentification OAuth 2.0 et des clés d'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 le code d'authentification des messages basé sur le hachage (HMAC) 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 l'agent mais ne prennent pas encore en charge la communication bidirectionnelle.

Fournisseurs d'enregistrement

Certains outils externes sont authentifiés au niveau du compte et partagés entre tous les espaces d'agent du compte. Lorsque vous enregistrez ces outils, vous vous authentifiez une fois au niveau du compte, puis chaque espace agent peut se connecter à des ressources spécifiques au sein de cette connexion enregistrée.

Les outils suivants utilisent l'enregistrement au niveau du compte :

• GitHub— Utilise OAuth le flux pour l'authentification. Une fois enregistré GitHub au niveau du compte, chaque agent Space peut se connecter à des référentiels spécifiques au sein de votre GitHub organisation.

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

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

• Datadog — Utilise MCP avec un OAuth flux pour l'authentification. Après avoir enregistré Datadog au niveau du compte, chaque Agent Space peut se connecter à des ressources de supervision Datadog spécifiques.

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

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

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

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

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

La connectivité réseau

AWS DevOps L'agent se connecte à vos systèmes tiers et à vos serveurs MCP distants pour effectuer des enquêtes et d'autres opérations.

Trafic entrant de l' AWS DevOps agent vers vos systèmes

AWS DevOps L'agent initie des connexions sortantes vers vos systèmes tiers et vos serveurs MCP distants, qui arrivent sous forme de trafic entrant vers votre infrastructure. La façon dont vous sécurisez ce trafic dépend de la manière dont vos outils sont hébergés :

• 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 le maintenir 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 listes d'adresses IP autorisées ou des règles de pare-feu, vous devez autoriser le trafic entrant provenant des adresses IP sources des AWS DevOps agents suivantes :

  • Asie-Pacifique (Sydney) (ap-southeast-2)

    • 13.237.95.197

    • 13.238.84.102

  • Asie-Pacifique (Tokyo) (ap-northeast-1)

    • 13.192.12.233

    • 35.74.181.230

    • 57.183.50.158

  • Europe (Francfort) (eu-central-1)

    • 18.158.110.140

    • 52.57.96.160

    • 52.59.55.56

  • Europe (Irlande) (eu-west-1)

    • 34.251.85.24

    • 52.30.157.157

    • 52.51.192.222

  • USA Est (Virginie du Nord) (us-east-1)

    • 34.228.181.128

    • 44.219.176.187

    • 54.226.244.221

  • USA Ouest (Oregon) (us-west-2)

    • 34.212.16.133

    • 52.89.67.212

    • 54.187.135.61

Trafic sortant de votre AWS DevOps VPC vers l'agent

Pour le trafic sortant de votre AWS VPC AWS DevOps vers l'agent (par exemple, Invocation de DevOps l'agent via Webhook en utilisant), vous pouvez utiliser des points de terminaison VPC pour isoler ce trafic réseau des réseaux. AWS Pour de plus amples informations, veuillez consulter Points de terminaison d'un VPC AWS PrivateLink.

Modèle de responsabilité partagée

AWS responsabilités

AWS est chargé de :

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

• Sécurisation des outils natifs mis à la disposition de l'agent

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

Responsabilités client

Les clients sont responsables de :

• Gestion de l'accès des utilisateurs à l'espace des agents

• 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 produisent 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 peu susceptibles d'être utilisées pour tenter des attaques par injection rapide

• Garantir le fonctionnement sécurisé des intégrations de serveurs bring-your-own MCP

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

• Rédaction des données d'identification personnelle avant de les stocker dans les journaux d'observabilité et autres sources de données des agents

• Respect de la pratique recommandée consistant à n'accorder des autorisations en lecture seule qu'aux sources de données connectées, y compris bring-your-own les serveurs MCP

Utilisation des données

AWS n'utilise pas les données des agents, les messages de chat ou les données provenant de sources de données intégrées pour entraîner des modèles ou améliorer le produit. The AWS DevOps Agent Space utilise les commentaires des clients intégrés au produit pour améliorer les réponses et les enquêtes des agents, mais AWS ne les utilise pas pour améliorer le service lui-même.

Conformité d’

Lors de la version préliminaire, AWS DevOps l'agent n'est pas conforme aux normes telles que SOC 2, PCI-DSS, ISO 27001 ou FedRAMP. AWS annoncera les certifications de conformité qui seront disponibles ultérieurement.