Sélectionner vos préférences de cookies

Nous utilisons des cookies essentiels et des outils similaires qui sont nécessaires au fonctionnement de notre site et à la fourniture de nos services. Nous utilisons des cookies de performance pour collecter des statistiques anonymes afin de comprendre comment les clients utilisent notre site et d’apporter des améliorations. Les cookies essentiels ne peuvent pas être désactivés, mais vous pouvez cliquer sur « Personnaliser » ou « Refuser » pour refuser les cookies de performance.

Si vous êtes d’accord, AWS et les tiers approuvés utiliseront également des cookies pour fournir des fonctionnalités utiles au site, mémoriser vos préférences et afficher du contenu pertinent, y compris des publicités pertinentes. Pour accepter ou refuser tous les cookies non essentiels, cliquez sur « Accepter » ou « Refuser ». Pour effectuer des choix plus détaillés, cliquez sur « Personnaliser ».

Le problème de l'adjoint confus

Mode de mise au point
Le problème de l'adjoint confus - AWS Identity and Access Management

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.

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.

Le problème de député confus est un problème de sécurité dans lequel une entité qui n’est pas autorisée à effectuer une action peut contraindre une entité plus privilégiée à le faire. Pour éviter cela, AWS fournit des outils qui vous aident à protéger votre compte si vous fournissez à des tiers (comptes croisés) ou à d'autres AWS services (appelés interservices) un accès aux ressources de votre compte.

Il peut arriver que vous deviez accorder à un tiers l'accès à vos AWS ressources (accès délégué). Par exemple, vous décidez de faire appel à une société tierce appelée Example Corp pour surveiller vos coûts Compte AWS et vous aider à optimiser les coûts. Afin de suivre vos dépenses quotidiennes, Example Corp doit accéder à vos AWS ressources. Example Corp surveille également de nombreux autres Comptes AWS pour d'autres clients. Vous pouvez utiliser un IAM rôle pour établir une relation de confiance entre votre compte Compte AWS et le compte Example Corp. L'un des aspects importants de ce scénario est l'ID externe, un identifiant facultatif que vous pouvez utiliser dans une politique de confiance des IAM rôles pour désigner les personnes habilitées à assumer le rôle. La fonction principale de l’ID externe est de traiter et de prévenir le problème du délégué confus.

Certains AWS services (services d'appel) utilisent leur principal de AWS service pour accéder aux AWS ressources d'autres AWS services (appelés services). Dans certaines de ces interactions de service, vous pouvez configurer les services d'appel pour communiquer avec les ressources d'un service appelé dans un autre pays Compte AWS. C'est le cas, par exemple, AWS CloudTrail de la configuration pour écrire dans un compartiment Amazon S3 central situé dans un autre compartiment Compte AWS. Le service d'appel CloudTrail est autorisé à accéder à votre compartiment s3 conformément à la politique du compartiment s3 en ajoutant une instruction d'autorisation pour cloudtrail.amazonaws.com.

Lorsqu'un principal de AWS service d'un service appelant accède à une ressource à partir d'un service appelé, la politique de ressources du service appelé autorise uniquement le principal de AWS service, et non l'acteur qui a configuré le service d'appel. Par exemple, un compartiment Amazon S3 qui fait confiance au principal du CloudTrail service sans aucune condition peut recevoir CloudTrail des journaux de la Comptes AWS part d'un administrateur de confiance configuré, mais également CloudTrail des journaux provenant d'un acteur non autorisé Compte AWS, s'il connaît le nom du compartiment Amazon S3.

Le problème des adjoints confus se pose lorsqu'un acteur utilise la confiance du directeur de AWS service d'un service pour accéder à des ressources auxquelles il n'est pas censé avoir accès.

Prévention du problème de l'adjoint confus entre comptes

Le diagramme suivant illustre le problème de l'adjoint confus entre comptes.

Description d'un problème de député confus.

Ce scénario suppose que :

  • AWS 1 est votre Compte AWS.

  • AWS 1 : ExampleRole est un rôle dans votre compte. La politique d'approbation du rôle approuve Example Corp en désignant le compte AWS d'Example Corp comme celui qui peut endosser le rôle.

Voici ce qui se produit :

  1. Lorsque vous commencez à utiliser le service d'Example Corp, vous fournissez le ARN code AWS 1 : ExampleRole à Example Corp.

  2. Example Corp utilise ce rôle ARN pour obtenir des informations de sécurité temporaires afin d'accéder aux ressources de votre Compte AWS. Ainsi, vous approuvez Example Corp en tant que « député » autorisé à agir pour votre compte.

  3. Un autre AWS client commence également à utiliser le service d'Example Corp, et ce client fournit également le ARN service AWS 1 : ExampleRole for Example Corp à utiliser. On peut supposer que l'autre client a appris ou deviné le AWS 1 : ExampleRole, ce qui n'est pas un secret.

  4. Lorsque l'autre client demande à Example Corp d'accéder aux AWS ressources (qu'il prétend être) de son compte, Example Corp utilise AWS 1 : ExampleRole pour accéder aux ressources de votre compte.

C'est ainsi que l'autre client peut obtenir un accès non autorisé à vos ressources. Du fait que cet autre client a été en mesure de tromper Example Corp pour agir involontairement sur vos ressources, Example Corp est à présent un « député confus ».

Exemple Corp peut résoudre le problème de l'adjoint confus en exigeant que vous incluiez la vérification de la condition ExternalId dans la politique d'approbation du rôle. Exemple Corp génère une valeur ExternalId unique pour chaque client et utilise cette valeur dans sa demande de prise en charge du rôle. La valeur ExternalId doit être unique parmi les clients d'Example Corp et contrôlée par Example Corp, et non par ses clients. C'est pourquoi vous l'obtenez d'Example Corp et que vous ne créez pas le vôtre. Cela évite à Example Corp d'être un adjoint confus et d'accorder l'accès aux AWS ressources d'un autre compte.

Dans notre scénario, imaginez que l'identifiant unique d'Example Corp pour vous soit 12345, et que son identifiant pour l'autre client soit 67890. Ces identifiants sont simplifiés pour ce scénario. En général, ces identifiants sontGUIDs. Supposons que ces identifiants sont uniques pour chaque client d'Example Corp, ils constituent des valeurs sensibles à utiliser pour l'ID externe.

Example Corp vous attribue la valeur d'ID externe 12345. Vous devez ensuite ajouter un élément Condition à la politique d'approbation du rôle qui nécessite que la valeur de sts:ExternalId soit 12345, comme suit :

{ "Version": "2012-10-17", "Statement": { "Effect": "Allow", "Principal": { "AWS": "Example Corp's AWS Account ID" }, "Action": "sts:AssumeRole", "Condition": { "StringEquals": { "sts:ExternalId": "12345" } } } }

L'élément Condition de cette politique permet à Example Corp d'assumer le rôle uniquement lorsque l' AssumeRole APIappel inclut la valeur d'ID externe 12345. Example Corp s'assure que chaque fois qu'elle assume un rôle au nom d'un client, elle inclut toujours la valeur d'identifiant externe de ce client dans l' AssumeRole appel. Même si un autre client fournit le vôtre à Example CorpARN, celui-ci ne peut pas contrôler l'identifiant externe qu'Example Corp inclut dans sa demande AWS. Cela permet d'éviter qu'un client non autorisé obtienne l'accès à vos ressources.

Le schéma suivant illustre ce processus.

Procédure pour résoudre un problème de député confus.
  1. Comme précédemment, lorsque vous commencez à utiliser le service d'Example Corp, vous fournissez le ARN AWS 1 : ExampleRole à Example Corp.

  2. Lorsque Example Corp utilise ce rôle ARN pour assumer le rôle AWS 1 : ExampleRole, Example Corp inclut votre identifiant externe (12345) dans l' AssumeRole APIappel. L'identifiant externe correspond à la politique de confiance du rôle. L' AssumeRole APIappel est donc réussi et Example Corp obtient des informations de sécurité temporaires pour accéder aux ressources de votre compte. Compte AWS

  3. Un autre AWS client commence également à utiliser le service d'Example Corp et, comme auparavant, ce client fournit également le service ARN de AWS 1 : ExampleRole for Example Corp à utiliser.

  4. Mais cette fois, lorsque Example Corp tente d'assumer le rôle AWS 1 : ExampleRole, elle fournit l'ID externe associé à l'autre client (67890). L'autre client est dans l'impossibilité de changer cela. Example Corp procède ainsi, car la demande pour utiliser le rôle provient de l'autre client, 67890 indique donc les circonstances dans lesquelles Example Corp agit. Comme vous avez ajouté une condition avec votre propre identifiant externe (12345) à la politique de confiance de AWS 1 : ExampleRole, l' AssumeRole APIappel échoue. L'autre client se voit refuser l'autorisation d'accéder aux ressources de votre compte (indiqué par la croix « X » rouge dans le diagramme).

L'ID externe empêche tout autre client de forcer Example Corp de manière trompeuse à accéder involontairement à vos ressources.

Prévention du problème de l’adjoint confus entre services

Le schéma suivant illustre le problème de confusion entre les services adjoints en utilisant l' CloudTrail exemple d'interaction avec Amazon S3, dans lequel un acteur non autorisé écrit CloudTrail des journaux dans un compartiment Amazon S3 auquel il n'est pas autorisé à accéder.

Un acteur non autorisé est autorisé à accéder à un compartiment Amazon S3 dans un autre compte en utilisant le CloudTrail service principal.

Pour éviter qu'un acteur non autorisé n'utilise la confiance d'un AWS mandant pour accéder à vos ressources, les responsables de AWS service incluent des informations sur la AWS ressource et AWS l'organisation pour laquelle ils agissent pour le compte. Compte AWS

Ces informations sont disponibles sous forme de valeurs de clé de condition globale qui peuvent être utilisées dans une politique de ressources ou dans une politique de contrôle des ressources pour les demandes effectuées par les principaux AWS fournisseurs de service. Nous vous recommandons d'utiliser lois : SourceArnlois : SourceAccount,lois : SourceAccount, ou lois : SourceOrgPaths dans vos politiques de ressources chaque fois qu'un directeur de AWS service est autorisé à accéder à l'une de vos ressources. Ces clés de condition vous permettent de tester dans vos politiques de ressources, ou vos politiques de contrôle des ressources, que les responsables de AWS service accédant à vos ressources le font au nom des AWS ressources Comptes AWS, ou comme AWS Organizations vous vous y attendez.

  • aws:SourceArnÀ utiliser pour autoriser un directeur de AWS service à accéder à vos ressources au nom d'une ressource spécifique, telle qu'un AWS CloudTrail sentier ou une AppStream flotte spécifique.

  • aws:SourceAccountÀ utiliser pour autoriser un directeur AWS de service à accéder à vos ressources pour le compte d'une personne en particulier Compte AWS.

  • aws:SourceOrgIDÀ utiliser pour autoriser un directeur AWS de service à accéder à vos ressources pour le compte d'une personne en particulier AWS Organizations.

  • aws:SourceOrgPathsÀ utiliser pour autoriser le principal de AWS service à accéder à vos ressources au nom d'un AWS Organizations chemin spécifique.

Le schéma suivant illustre le scénario d'un adjoint confus entre services lorsqu'une ressource est configurée avec la clé de contexte de condition aws:SourceAccount globale et qu'un acteur non autorisé d'un autre compte tente d'accéder à AWS des ressources auxquelles il n'est pas censé avoir accès.

Un acteur non autorisé se voit refuser l'accès à un compartiment Amazon S3 dans un autre compte en utilisant le CloudTrail service principal.

L'utilisation de clés de condition aws:SourceArn aws:SourceAccountaws:SourceOrgID,, et aws:SourceOrgPaths globales dans une politique vous permet de vous assurer que les responsables du service accèdent à vos ressources en votre nom. Nous recommandons d'utiliser ces clés de condition chaque fois que l'accès à l'une de vos ressources est accordé à un principal AWS de service.

Note

Certaines Service AWS interactions comportent des contrôles supplémentaires qui permettent de se protéger contre les problèmes liés à la confusion entre les services qui mettent à l'épreuve l'accès des utilisateurs à une ressource. Par exemple, lorsqu'une attribution de KMS clé est accordée à un Service AWS, AWS KMS utilise le contexte de chiffrement associé à la ressource et l'octroi de clés pour éviter les problèmes de confusion entre les services adjoints.

Consultez la documentation des services que vous utilisez pour plus d'informations sur les mécanismes spécifiques aux services qui peuvent aider à éviter les risques liés à la confusion entre les services, et pour savoir si, aws:SourceArn aws:SourceAccountaws:SourceOrgID, et aws:SourceOrgPaths sont pris en charge.

Le cross-service a confondu protection des adjoints avec les politiques basées sur les ressources

L'exemple de politique suivant accorde au principal de service l'cloudtrail.amazonaws.com.rproxy.goskope.comaccès au compartiment Amazon S3, arn:aws:s3 : ::amzn-s3-demo-bucket1, uniquement lorsque le principal de service agit pour le compte de 111122223333. Compte AWS

{ "Version": "2012-10-17", "Statement": [ { "Sid": "CloudTrailAclCheck", "Effect": "Allow", "Principal": {"Service": "cloudtrail.amazonaws.com"}, "Action": "s3:GetBucketAcl", "Resource": "arn:aws:s3:::amzn-s3-demo-bucket1", "Condition": { "StringEquals": { "aws:SourceAccount": "111122223333" } } }, { "Sid": "AWSCloudTrailWrite", "Effect": "Allow", "Principal": {"Service": "cloudtrail.amazonaws.com"}, "Action": "s3:PutObject", "Resource": "arn:aws:s3:::amzn-s3-demo-bucket1/[optionalPrefix]/Logs/myAccountID/*", "Condition": { "StringEquals": { "aws:SourceAccount": "111122223333" } } } ] }

Cet exemple de politique de compartiment accorde au principal du service l'appstream.amazonaws.com.rproxy.goskope.comaccès au script PowerShell examplefile.psh sur le site s3://amzn-s3-demo-bucket2 uniquement lorsqu'il agit pour le compte de la AppStream flotte Amazon spécifiée, en spécifiant l'ARN de la flotte avec. aws:SourceArn

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": [ "appstream.amazonaws.com" ] }, "Action": "s3:GetObject", "Resource": "arn:aws:s3:::amzn-s3-demo-bucket2/examplefile.psh", "Condition": { "ArnEquals": { "aws:SourceArn": "arn:aws:appstream:us-east-1:111122223333:fleet/ExampleFleetName" } } } ] }

Les services interservices ont confondu protection des adjoints et politiques de contrôle des ressources

Vous pouvez utiliser les politiques de contrôle des ressources (RCP) pour appliquer des contrôles adjoints confus entre services aux ressources prises en charge Services AWS. RCPsvous permettent d'appliquer de manière centralisée des contrôles adjoints interservices confus sur vos ressources. Vous pouvez utiliser des clés de condition aws:SourceOrgId aws:SourceOrgPaths RCPs associées à vos unités organisationnelles ( AWS Organizations UO) ou Comptes AWS au sein de votre organisation sans ajouter d'instructions à des politiques spécifiques basées sur les ressources. Pour plus d'informations sur les services pris en charge RCPs et les services pris en charge, consultez la section Politiques de contrôle des ressources (RCPs) dans le guide de AWS Organizations l'utilisateur.

L'exemple suivant RCP refuse aux principaux de AWS service l'accès aux compartiments Amazon S3 de vos comptes membres lorsque la valeur n'aws:SourceOrgIDest pas égale à o-. ExampleOrg Une autorisation correspondante doit être présente dans la politique basée sur les ressources du compartiment Amazon S3 pour autoriser les principaux de AWS service ayant un SourceOrg ID égal à o- S. ExampleOrg

Cette politique applique le contrôle uniquement aux demandes des principaux de service ("Bool": {"aws:PrincipalIsAWSService": "true"}) dont la aws:SourceAccount clé est présente ("Null": {"aws:SourceAccount": "false"}), afin que les intégrations de services qui ne nécessitent pas l'utilisation de la clé de condition et les appels de vos principaux ne soient pas affectées. Si la clé de aws:SourceAccount condition est présente dans le contexte de la demande, la condition Null sera considérée comme vraie, ce qui entraînera aws:SourceOrgID son application. Vous pouvez utiliser aws:SourceAccount plutôt que aws:SourceOrgID l'opérateur de condition Null afin que le contrôle s'applique toujours si la demande provient d'un compte qui n'appartient pas à une organisation.

{ "Version": "2012-10-17", "Statement": [ { "Sid": "RCPEnforceConfusedDeputyProtectionForS3", "Effect": "Deny", "Principal": "*", "Action": [ "s3:*" ], "Resource": "*", "Condition": { "StringNotEqualsIfExists": { "aws:SourceOrgID": "o-ExampleOrg" }, "Null": { "aws:SourceAccount": "false" }, "Bool": { "aws:PrincipalIsAWSService": "true" } } } ] }

Rubrique suivante :

Scénarios courants

Rubrique précédente :

Rôles
ConfidentialitéConditions d'utilisation du sitePréférences de cookies
© 2025, Amazon Web Services, Inc. ou ses affiliés. Tous droits réservés.