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.

Le problème de l'adjoint confus

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é). Supposons, par exemple, que vous décidiez 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 en surveille également de nombreux autres Comptes AWS pour le compte d'autres clients. Vous pouvez utiliser un rôle IAM pour établir une relation de confiance entre votre compte Compte AWS et le compte Example Corp. Un aspect important de ce scénario est l'ID externe, informations facultatives que vous pouvez utiliser dans une politique d'approbation des rôles IAM afin de désigner l'utilisateur autorisé à endosser le rôle. La fonction principale de l'ID externe consiste à traiter et à prévenir le problème du député confus.

En AWS, l'usurpation d'identité interservices peut entraîner un problème de confusion chez les adjoints. L’usurpation d’identité entre services peut se produire lorsqu’un service (le service appelant) appelle un autre service (le service appelé). Le service appelant peut être manipulé pour utiliser ses autorisations afin d'agir sur les ressources d'un autre client de sorte qu'il n'y aurait pas accès autrement.

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 le vôtre 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 l'ARN AWS 1 : ExampleRole à Example Corp.

  2. Example Corp utilise cet ARN de rôle pour obtenir des informations d'identification 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 l'ARN 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 sont des GUID. 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'appel d' AssumeRole API 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 votre ARN à Example Corp, il ne peut pas contrôler l'ID 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 l'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 ID externe (12345) dans l'appel d' AssumeRole API. L'ID externe correspond à la politique de confiance du rôle, de sorte que l'appel d' AssumeRole API aboutit et Example Corp obtient des informations de sécurité temporaires pour accéder aux ressources de votre. Compte AWS

  3. Un autre AWS client commence également à utiliser le service d'Example Corp et, comme auparavant, ce client fournit également l'ARN 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 ID externe (12345) à la politique de confiance de AWS 1 : ExampleRole, l'appel d' AssumeRole API é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

Nous recommandons d'utiliser les clés de contexte de condition globale aws:SourceArn, aws:SourceAccount, aws:SourceOrgID ou aws:SourceOrgPaths dans les politiques basées sur les ressources pour limiter les autorisations dont dispose un service pour une ressource spécifique. aws:SourceArnÀ utiliser pour associer une seule ressource à un accès multiservice. aws:SourceAccountÀ utiliser pour associer n'importe quelle ressource de ce compte à l'utilisation interservices. aws:SourceOrgIDÀ utiliser pour permettre à n'importe quelle ressource provenant de n'importe quel compte au sein d'une organisation d'être associée à l'utilisation interservices. aws:SourceOrgPathsÀ utiliser pour associer toute ressource provenant de comptes situés dans un AWS Organizations chemin à l'utilisation interservices. Pour de plus amples informations sur l'utilisation et la compréhension des chemins, veuillez consulter Présentation du chemin d'entité AWS Organizations.

Le moyen le plus granulaire de se protéger contre le problème de l'adjoint confus est d'utiliser la clé de contexte de condition globale aws:SourceArn avec l'ARN complet de la ressource dans vos politiques basées sur les ressources. Si vous ne connaissez pas l'ARN complet de la ressource ou si vous spécifiez plusieurs ressources, utilisez la clé de contexte de condition globale aws:SourceArn avec des caractères génériques (*) pour les parties inconnues de l'ARN. Par exemple, arn:aws:servicename:*:123456789012:*.

Si la valeur aws:SourceArn ne contient pas l'ID du compte, tel qu'un ARN de compartiment Amazon S3, vous devez utiliser à la fois aws:SourceAccount et aws:SourceArn pour limiter les autorisations.

Pour se protéger contre le problème de l'adjoint confus à grande échelle, utilisez la clé de contexte de condition globale aws:SourceOrgID ou aws:SourceOrgPaths avec l'ID de l'organisation ou le chemin de l'organisation de la ressource dans vos politiques basées sur les ressources. Lorsque vous ajoutez, supprimez et déplacez des comptes dans votre organisation, les politiques qui contiennent la clé aws:SourceOrgID ou aws:SourceOrgPaths incluront automatiquement les bons comptes et vous n'avez pas besoin de mettre manuellement à jour les polices.

Pour les politiques de confiance en matière de non-service-linked rôle, chaque service inclus dans la politique de confiance a effectué l'iam:PassRoleaction nécessaire pour vérifier que le rôle se trouve sur le même compte que le service d'appel. Par conséquent, l'utilisation de aws:SourceAccount, aws:SourceOrgID ou aws:SourceOrgPaths avec ces politiques d'approbation n'est pas nécessaire. L'utilisation de aws:SourceArn dans une politique d'approbation vous permet de spécifier les ressources pour lesquelles un rôle peut être assumé en son nom, comme l'ARN d'une fonction Lambda. Certaines politiques Services AWS d'utilisation aws:SourceAccount et aws:SourceArn de confiance s'appliquent aux rôles nouvellement créés, mais l'utilisation des clés n'est pas obligatoire pour les rôles existants dans votre compte.

Note

Services AWS qui s'intègrent à AWS Key Management Service l'utilisation de l'attribution de clés KMS ne prennent pas en charge les clés aws:SourceArnaws:SourceAccount,aws:SourceOrgID, ou les clés de aws:SourceOrgPaths condition. L'utilisation de ces clés de condition dans une politique de clé KMS entraînera un comportement inattendu si la clé est également utilisée par le Services AWS biais de l'attribution de clés KMS.

Prévention interservices confuse des adjoints pour AWS Security Token Service

De nombreux AWS services nécessitent que vous utilisiez des rôles pour permettre au service d'accéder aux ressources d'un autre service en votre nom. Un rôle qu'un service endosse pour effectuer des actions en votre nom s'appelle un rôle de service. Un rôle nécessite deux politiques : une politique d'approbation de rôle qui spécifie le principal autorisé à endosser le rôle et une politique d'autorisations qui spécifie ce qui peut être fait avec le rôle. Une politique d'approbation de rôle est le seul type de politique basée sur les ressources dans IAM. D'autres Services AWS ont des politiques basées sur les ressources, telles qu'une politique de compartiment Amazon S3.

Lorsqu'un service endosse un rôle en votre nom, le principal du service doit être autorisé à effectuer l'action sts:AssumeRole dans la politique d'approbation des rôles. Lorsqu'un service appellests:AssumeRole, AWS STS renvoie un ensemble d'informations d'identification de sécurité temporaires que le principal du service utilise pour accéder aux ressources autorisées par la politique d'autorisation du rôle. Lorsqu'un service endosse un rôle dans votre compte, vous pouvez inclure les clés de contexte de condition globale aws:SourceArn, aws:SourceAccount, aws:SourceOrgID ou aws:SourceOrgPaths dans votre politique d'approbation des rôles afin de limiter l'accès au rôle aux seules demandes générées par les ressources attendues.

Par exemple, dans AWS Systems Manager Incident Manager, vous devez choisir un rôle pour autoriser Incident Manager à exécuter un document d'automatisation de Systems Manager en votre nom. Le document d'automatisation peut inclure des plans de réponse automatisés pour les incidents déclenchés par des CloudWatch alarmes ou EventBridge des événements. Dans l'exemple de politique d'approbation de rôle suivant, vous pouvez utiliser la clé de condition aws:SourceArn pour limiter l'accès à la fonction du service sur la base de l'ARN de l'enregistrement d'incident. Seuls les enregistrements d'incidents qui sont créés à partir de la ressource myresponseplan du plan de réponse peuvent utiliser ce rôle.

{ "Version": "2012-10-17", "Statement": { "Effect": "Allow", "Principal": { "Service": "ssm-incidents.amazonaws.com" }, "Action": "sts:AssumeRole", "Condition": { "ArnLike": { "aws:SourceArn": "arn:aws:ssm-incidents:*:111122223333:incident-record/myresponseplan/*" } } } }
Note

Toutes les intégrations de services ne sont pas accompagnées aws:SourceArn de aws:SourceAccount clés de AWS STS support ou de aws:SourceOrgPaths condition. aws:SourceOrgID L'utilisation de ces clés dans les politiques d'approbation IAM avec des intégrations non prises en charge peut entraîner un comportement inattendu.