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

Le problème des adjoints 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 à effectuer l'action. Entrée AWS, l'usurpation d'identité interservices peut créer de la 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 d'appel peut être manipulé pour utiliser ses autorisations afin d'agir sur les ressources d'un autre client d'une manière à laquelle il ne devrait pas être autorisé à accéder autrement. Pour éviter cela, AWS fournit des outils qui vous aident à protéger vos données pour tous les services dont les responsables ont obtenu l'accès aux ressources de votre compte.

Nous recommandons d'utiliser les clés contextuelles de condition aws:SourceAccount globale aws:SourceArn et les clés contextuelles dans les politiques de ressources afin de limiter les autorisations accordées par Identity and Access Management (IAM) à Amazon Nimble Studio pour accéder à vos ressources. Si vous utilisez les deux clés contextuelles de condition globale, la aws:SourceAccount valeur et le compte figurant dans la aws:SourceArn valeur doivent utiliser le même identifiant de compte lorsqu'ils sont utilisés dans la même déclaration de politique.

La valeur de aws:SourceArn doit être celle du studio ARN et aws:SourceAccount doit être votre identifiant de compte. Vous ne saurez pas quel est l'identifiant du studio tant que celui-ci n'est pas créé, car il est généré par Nimble Studio. Une fois votre studio créé, vous pouvez mettre à jour la politique de confiance en définissant l'identifiant final du studio comme étant leaws:SourceArn.

Le moyen le plus efficace de se protéger contre le problème de confusion des adjoints consiste à utiliser la clé de contexte de la condition aws:SourceArn globale avec l'intégralité ARN de la ressource. Si vous ne connaissez pas l'intégralité ARN de la ressource ou si vous spécifiez plusieurs ressources, utilisez la clé de condition contextuelle aws:SourceArn globale avec des caractères génériques (*) pour les parties inconnues duARN. Par exemple, arn:aws:nimble::123456789012:*.

Vos utilisateurs finaux assument votre rôle de studio lorsqu'ils se connectent au portail Nimble Studio. Lorsque vous créez votre studio, AWS configure le rôle et évalue la politique. AWS évalue la politique chaque fois qu'un de vos utilisateurs se connecte au portail Nimble Studio. Lorsque vous créez un studio, vous ne pouvez pas modifier leaws:SourceArn. Une fois que vous avez fini de créer votre studio, vous pouvez utiliser votre studioArn pour leaws:SourceArn.

L'exemple suivant est une politique d'acceptation des rôles qui montre comment utiliser les clés contextuelles aws:SourceArn et les clés de contexte de condition aws:SourceAccount globale dans Nimble Studio pour éviter le problème de confusion des adjoints.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "identity.nimble.amazonaws.com"
      },
      "Action": [
        "sts:AssumeRole",
        "sts:TagSession"
      ],
      "Condition": {
        "StringEquals": {
          "aws:SourceAccount": "123456789012"
        },
        "StringLike": {
          "aws:SourceArn": "arn:aws:nimble:us-west-2:123456789012:studio/*"
        }
      }
    }
  ]
}