Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Modèle de sécurité et autorisations pour les instances d'exécution
Lorsque vous hébergez des agents sur le type de calcul Instances, vos agents s'exécutent sur des instances Amazon EC2 dans votre propre AWS compte. Cela modifie le modèle de responsabilité partagée par rapport au type de calcul microVM sans serveur : les instances s'exécutent dans votre compte et votre VPC, vos agents s'exécutent avec les autorisations du rôle d'exécution d'exécution et les données les concernant restent dans votre compte. Cette rubrique décrit le modèle de sécurité pour les instances, les autorisations impliquées et les pratiques à suivre pour les déploiements multi-locataires.
Cette rubrique complète les Runtime-wide conseils contenus dans les meilleures pratiques de sécurité pour AgentCore Runtime. Les pratiques qui s'y appliquent (minimum de privilèges IAM, authentification, chiffrement, sécurité du réseau et audit) s'appliquent également aux instances. Pour savoir comment les volumes EBS attachés à vos sessions sont chiffrés, consultez la section Chiffrement au repos pour les instances d'exécution.
Rubriques
Modèle de sécurité
-
L'instance se trouve dans votre compte : les instances EC2 lancées par un fournisseur de capacité sont exécutées sur votre compte et le VPC en tant qu'instances gérées par Amazon EC2. Vous pouvez les inspecter, appliquer vos propres contrôles et auditer leur activité via CloudTrail les journaux de flux VPC de votre compte.
-
Les agents d'une instance ne sont pas isolés les uns des autres : plusieurs agents peuvent s'exécuter sur la même instance et partager son système de fichiers. Les agents s'exécutent sur l'instance soit dans des conteneurs, soit, pour les agents déployés directement, en tant que processus directement sur l'instance. Aucun des deux ne fournit de limite de sécurité entre les charges de travail d'une même instance. Tous les agents qui partagent une instance doivent bénéficier d'une confiance mutuelle.
-
La session est l'unité d'isolation : une session, identifiée par la combinaison du fournisseur de capacité et de l'ID de session, est mappée à une instance EC2 (1:1). Le même identifiant de session sous deux fournisseurs de capacité différents fait référence à deux sessions différentes sur deux instances différentes. Les agents que vous souhaitez isoler les uns des autres ne doivent pas partager une session.
-
Vente d'informations d'identification : distribue les AgentCore informations d'identification des rôles d'exécution aux agents qui s'exécutent sur l'instance et les actualise régulièrement. Tout code exécuté sur l'instance peut lire les informations d'identification disponibles. Étendez le rôle d'exécution de chaque environnement d'exécution au minimum requis par son agent. Pour plus d'informations, consultez la section Gestion des informations d'identification.
-
Les contrôles de votre compte s'appliquent : étant donné que les instances s'exécutent sur votre compte, les politiques de contrôle AWS des services (SCP), les limites d'autorisation et les contrôles VPC de votre organisation régissent les actions entreprises sur votre compte. AgentCore agit par le biais du rôle d'infrastructure que vous fournissez ou approuvez ; définissez-le en fonction de conditions IAM (par exemple, pour des VPC, des sous-réseaux ou des types d'instances spécifiques). L'exception concerne le rôle AgentCore lié à un service utilisé pour supprimer et nettoyer les ressources, qui n'est pas limité par les SCP, conformément à la façon dont les rôles liés à un service sont traités en AWS général.
-
Résidence des données : les agents s'exécutent dans le VPC, les sous-réseaux, le compte et la région que vous spécifiez, et les données de session et les volumes EBS restent dans votre compte.
Autorisations requises
L'hébergement d'agents sur des instances implique les rôles suivants, en plus du rôle d'exécution de l'agent d'exécution qui accorde à votre code d'agent ses autorisations d'exécution.
-
Profil d'instance : attaché à l'instance EC2. AgentCore l'utilise pour collecter les journaux système de l'instance ; il n'accorde pas d'autorisations au code de votre agent (c'est le rôle d'exécution de l'agent qui le fait).
-
Rôle d'infrastructure : AgentCore assume ce rôle pour provisionner et gérer les instances EC2 de votre compte en votre nom, en lançant, balisant et configurant la mise en réseau des instances et de leurs interfaces réseau. Étant donné que ce rôle AgentCore autorise la gestion du calcul dans votre compte, limitez-le au minimum requis par vos charges de travail et utilisez les conditions IAM pour le limiter à des VPC, des sous-réseaux ou des types d'instances spécifiques, le cas échéant.
Pour les étapes de configuration des rôles, consultez la section Commencer à utiliser les instances.
Routage des sessions et isolation multi-locataires
AgentCore Runtime autorise les appels sur l'ARN de la ressource d'exécution de l'agent, et non sur des sessions individuelles.
Lorsque vous appelez un agent, vous fournissez et AgentCore validez le format de cet identifiant de sessionruntimeSessionId, mais vous ne vérifiez pas qu'il appartient à l'identité de l'appelant. Cela a une conséquence importante pour les déploiements multi-locataires :
Important
Dans les déploiements où un seul principal IAM invoque pour le compte de plusieurs utilisateurs finaux, la plateforme n'impose pas que a sessionId appartient à l'utilisateur appelant. Vous êtes responsable de vous assurer que votre backend transmet le bon signal sessionId par utilisateur.
Si plusieurs utilisateurs finaux partagent le même principal IAM (par exemple, un rôle d'exécution de backend unique qui appelle InvokeAgentRuntime tous les utilisateurs) et que votre backend ne lie pas les sessions aux utilisateurs, un utilisateur authentifié peut fournir l'ID de session d'un autre utilisateur et acheminer une demande vers la session de cet utilisateur. Les pratiques suivantes permettent d'atténuer ce problème.
Appliquez la liaison de session à utilisateur dans votre backend
Implémentez la liaison session-utilisateur au niveau de l'application dans votre backend. Conservez le mappage entre chaque utilisateur final et ses identifiants de session dans votre application, et assurez-vous qu'une demande pour un utilisateur ne puisse jamais être émise avec celle d'un autre utilisateurruntimeSessionId. Traitez-le runtimeSessionId comme une valeur côté serveur dérivée de l'utilisateur final authentifié. Ne l'acceptez jamais directement à partir d'une entrée client non fiable. Pour les déploiements à principal partagé et à locataires multiples, la liaison au niveau de l'application dans votre backend est le contrôle qui empêche un utilisateur d'acheminer une demande vers la session d'un autre utilisateur.
Utilisez des principes IAM distincts pour les déploiements multi-locataires de haute sécurité
Pour les déploiements multi-locataires hautement sécurisés, utilisez des principaux IAM distincts par utilisateur final (ou par groupe de locataires) pour invoquer les agents, plutôt qu'un seul principal partagé. Lorsque chaque utilisateur ou locataire invoque via son propre principal, IAM applique lui-même la portée de la session : un principal ne peut invoquer que les environnements d'exécution autorisés par sa politique, ce qui supprime le risque de routage de session de la classe des principaux partagés. Il s'agit du contrôle le plus puissant et il est recommandé chaque fois que le déploiement peut prendre en charge des principaux par utilisateur ou par locataire.
Audit et surveillance
Utilisez l'audit pour détecter la reconnaissance du routage des sessions et les accès anormaux :
-
Corréler le principal et l'ID de session : AWS CloudTrail enregistre à la fois le principal authentifié et la cible
sessionIdlors d'un mêmeInvokeAgentRuntimeévénement. Utilisez-le pour détecter un routage principal vers une session créée par un autre principal. -
Appliquez les pratiques Runtime-wide d'audit : activez les journaux de flux CloudTrail et VPC, corrélez les journaux à l'aide des ID de demande et configurez des filtres métriques et des alarmes, comme décrit dans Audit et surveillance.
Bonnes pratiques
-
Séparez les charges de travail par niveau de confiance : utilisez des sessions différentes pour les charges de travail qui ne sont pas mutuellement fiables. Ne colocalisez pas des agents non fiables sur la même session.
-
Appliquez le minimum de privilèges à chaque rôle : limitez le rôle d'exécution de l'agent d'exécution à l'exécution et le rôle d'infrastructure aux seules actions et ressources dont chacun a besoin.
-
Liez les sessions aux utilisateurs de votre backend : pour tout déploiement dans lequel un principal dessert plusieurs utilisateurs finaux, appliquez la liaison de session à utilisateur dans votre couche d'application.
-
Préférez les principaux par utilisateur ou par locataire — Dans la mesure du possible, invoquez-les via des principaux IAM distincts afin qu'IAM applique la portée des sessions.
-
Surveiller le routage entre principaux : permet CloudTrail de détecter les anomalies de routage, telles qu'un routage principal vers une session créée par un autre principal.
Pour obtenir des conseils Runtime-wide de sécurité qui s'appliquent également aux instances, consultez la section Meilleures pratiques en matière de sécurité pour AgentCore Runtime.
