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.

Ce scénario suppose que :

Voici ce qui se produit :

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.

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.

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/*"
      }
    }
  }
}