Le problème de l'adjoint confus

Le problème de l'adjoint confus est un problème de sécurité dans lequel une entité qui n'a pas l'autorisation d'effectuer une action peut contraindre une entité plus privilégiée à effectuer cette action. Pour éviter cela, AWS fournit des outils qui vous aident à protéger votre compte si vous donnez à des tiers (compte croisé) ou à d'autres services AWS (service croisé) l'accès aux ressources de votre compte.

Parfois, vous pouvez avoir besoin d'accorder à un tiers l'accès à vos ressources AWS (déléguer l'accès). Par exemple, disons que vous décidez d'embaucher une entreprise tierce appelée Example Corp pour surveiller votre Compte AWS et vous aider à optimiser les coûts. Pour effectuer le suivi de vos dépenses quotidiennes, Example Corp doit accéder à vos ressources AWS. Example Corp surveille également de nombreux autres Comptes AWS pour d'autres clients. Vous pouvez utiliser un rôle IAM pour établir une relation de confiance entre votre Compte AWS et le compte Exemple 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.

Dans l'interface AWS, l'usurpation d'identité entre services peut entraîner le problème de l'adjoint confus. 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 empêche Exemple Corp d'être un adjoint confus et d'accorder l'accès aux ressources AWS 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 autorise Example Corp à assumer le rôle uniquement si l'appel d'API AssumeRole inclut la valeur d'ID externe 12345. Example Corp s'assure que chaque fois qu'elle endosse un rôle pour le compte d'un client, elle inclut toujours la valeur d'ID externe de ce client dans l'appel AssumeRole. Même si un autre client fournit à Example Corp votre ARN, 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. Utilisez aws:SourceArn pour associer une seule ressource à l’accès interservice. Utilisez aws:SourceAccount pour permettre à n’importe quelle ressource de ce compte d’être associée à l’utilisation interservice. Utilisez aws:SourceOrgID pour permettre à n’importe quelle ressource de n’importe quel compte au sein d’une organisation d’être associée à l’utilisation interservice. Utilisez aws:SourceOrgPaths pour associer n’importe quelle ressource des comptes d’un chemin d’accès AWS Organizations à l’utilisation interservice. 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 d'approbation des rôles non liées à un service, chaque service de la politique d'approbation a effectué l'action iam:PassRole visant à vérifier que le rôle appartient au même compte que le service appelant. 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. Certains Services AWS utilisent aws:SourceAccount et aws:SourceArn dans les politiques d'approbation pour les rôles nouvellement créés, mais l'utilisation des clés n'est pas requise pour les rôles existants dans votre compte.

Prévention du problème de l'adjoint confus entre services pour l'interface AWS Security Token Service

De nombreux services AWS exigent que vous utilisiez des rôles pour autoriser le service à 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, par exemple 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 appelle l'interface sts: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'autorisations 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 Systems Manager en votre nom. Le document d'automatisation peut inclure des plans de réponse automatisés pour les incidents initiés par des alarmes CloudWatch ou des événements EventBridge. 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/*"
      }
    }
  }
}