Exemples de politiques pour la délégation d'accès

Les exemples suivants montrent comment vous pouvez autoriser ou accorder à un Compte AWS l'accès aux ressources d'un autre Compte AWS. Pour apprendre à créer une politique IAM à l'aide de ces exemples de document de politique JSON, consultez Création de politiques à l'aide de l'éditeur JSON.

Utilisation de rôles pour la délégation d'accès aux ressources d'un autre Compte AWS

Vous trouverez un didacticiel qui montre comment utiliser des rôles IAM pour accorder aux utilisateurs d'un compte l'accès aux ressources AWS d'un autre compte ici : Didacticiel IAM : déléguer l'accès entre des comptes AWS à l'aide des rôles IAM.

Important

Vous pouvez inclure l'ARN d'un rôle ou d'un utilisateur dans l'élément Principal de la politique d'approbation d'un rôle. Lorsque vous enregistrez la politique, AWS transforme l'ARN en un ID de principal unique. Cela permet de réduire le risque d'escalade des privilèges par la suppression et la nouvelle création du rôle ou de l'utilisateur. Cet ID n'est pas fréquent dans la console, car il existe également une transformation inverse, pour revenir à l'ARN, lorsque la politique d'approbation est affichée. Cependant, si vous supprimez le rôle ou l'utilisateur, la relation est interrompue. La politique ne s'applique plus, même si vous recréez l'utilisateur ou le rôle, étant donné qu'il ne correspond pas à l'ID du principal stocké dans la politique d'approbation. Dans ce cas, l'ID du principal s'affiche dans la console car AWS ne peut plus le faire correspondre à un ARN. Le résultat final est que si vous supprimez et recréez un utilisateur ou un rôle référencé dans l'élément Principal d'une politique d'approbation, vous devez modifier le rôle afin de remplacer l'ARN. Il deviendra le nouvel ID du principal lorsque vous enregistrez la politique.

Utilisation d'une politique pour la délégation d'accès à des services

L'exemple suivant illustre une politique qui est peut être attachée à un rôle. La politique autorise deux services, à savoir Amazon EMR et AWS Data Pipeline, à endosser le rôle. Les services peuvent ensuite effectuer toutes les tâches autorisées par la politique d'autorisation affectée au rôle (non illustré). Pour définir plusieurs principaux de service, vous ne spécifiez pas deux éléments Service ; vous ne devez en avoir qu'un seul. À la place, vous utilisez un tableau de plusieurs principaux de service comme valeur d'un élément Service unique.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": [
          "elasticmapreduce.amazonaws.com",
          "datapipeline.amazonaws.com"
        ]
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

Utilisation d'une politique basée sur les ressources pour la délégation de l'accès à un compartiment Amazon S3 dans un autre compte

Dans cet exemple, le compte A utilise une politique basée sur les ressources (une politique de compartiment Amazon S3) pour octroyer au compte B l'accès complet au compartiment S3 du compte A. Ensuite, le compte B crée une politique d'utilisateur IAM pour déléguer l'accès au compartiment du compte A à l'un des utilisateurs du compte B.

La politique de compartiment S3 du compte A peut se présenter comme suit. Dans cet exemple, le compartiment S3 du compte A est nommé mybucket, et le numéro de compte du compte B est 111122223333. Il ne spécifie pas d'utilisateurs ou de groupes dans le compte B, simplement le compte proprement dit.

{
  "Version": "2012-10-17",
  "Statement": {
    "Sid": "AccountBAccess1",
    "Effect": "Allow",
    "Principal": {"AWS": "111122223333"},
    "Action": "s3:*",
    "Resource": [
      "arn:aws:s3:::mybucket",
      "arn:aws:s3:::mybucket/*"
    ]
  }
}

En variante, le compte A peut utiliser des Listes de contrôle d'accès (ACL) Amazon S3 pour accorder l'accès au compte B à un compartiment S3 ou à un seul objet dans un compartiment. Dans ce cas, seule change la façon dont le compte A accorde l'accès au compte B. Le compte B utilise toujours une politique pour déléguer l'accès à un groupe IAM dans le compte B, comme décrit dans la dernière partie de cet exemple. Pour plus d’informations sur le contrôle de l'accès aux compartiments et aux objets S3, veuillez consulter contrôle des accès dans le guide de l'utilisateur du service de stockage simple Amazon.

L'administrateur du compte B peut créer l'exemple de politique suivant. La politique donne un accès en lecture à un groupe ou à un utilisateur au sein du compte B. La politique précédente accorde l'accès au compte B. Toutefois, des groupes et des utilisateurs spécifiques au sein du compte B ne peuvent pas accéder à la ressource tant qu'une politique de groupe ou d'utilisateur ne leur accorde pas explicitement des autorisations pour cette ressource. Les autorisations de cette politique peuvent uniquement être un sous-ensemble de celles de la politique intercompte précédente. Le compte B ne peut pas accorder plus d'autorisations à ses utilisateurs et groupes que le compte A ne lui a accordé dans la première politique. Dans cette politique, l'élément Action est défini explicitement pour autoriser uniquement les actions List, tandis que l'élément Resource de cette politique correspond à l'élément Resource pour la politique de compartiment implémentée par le compte A.

Pour implémenter cette politique, le compte B utilise IAM pour l'attacher à l'utilisateur (ou au groupe) approprié dans le compte B.

{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Action": "s3:List*",
    "Resource": [
      "arn:aws:s3:::mybucket",
      "arn:aws:s3:::mybucket/*"
    ]
  }
}

Utilisation d'une politique basée sur les ressources pour la délégation de l'accès à une file d'attente Amazon SQS dans un autre compte

Dans l'exemple suivant, le compte A est doté d'une file d'attente Amazon SQS qui utilise une politique basée sur les ressources attachée à celle-ci pour accorder au compte B l'accès à la file d'attente. Le compte B utilise ensuite une politique de groupe IAM pour déléguer l'accès à un groupe du compte B.

L'exemple de politique de file d'attente suivant accorde au compte B l'autorisation d'effectuer les actions SendMessage et ReceiveMessage dans la file d'attente du compte A nommée queue1, mais uniquement entre midi et 15 heures le 30 novembre 2014. Le numéro de compte du compte B est 1111-2222-3333. Le compte A utilise Amazon SQS pour implémenter cette politique.

{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Principal": {"AWS": "111122223333"},
    "Action": [
      "sqs:SendMessage",
      "sqs:ReceiveMessage"
    ],
    "Resource": ["arn:aws:sqs:*:123456789012:queue1"],
    "Condition": {
      "DateGreaterThan": {"aws:CurrentTime": "2014-11-30T12:00Z"},
      "DateLessThan": {"aws:CurrentTime": "2014-11-30T15:00Z"}
    }
  }
}

La politique du compte B pour la délégation d'accès à un groupe dans le compte B peut se présenter comme l'exemple suivant. Le compte B utilise IAM pour attacher cette politique à un groupe (ou utilisateur).

{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Action": "sqs:*",
    "Resource": "arn:aws:sqs:*:123456789012:queue1"
  }
}

Dans l'exemple de politique utilisateur IAM précédent, le compte B utilise un caractère générique pour accorder à son utilisateur l'accès à toutes les actions Amazon SQS dans la file d'attente du compte A. Cependant, le compte B peut déléguer l'accès dans la mesure où celui-ci lui a été accordé. Le groupe du compte B qui a une seconde politique peut accéder à la file d'attente uniquement entre midi et 15 heures le 30 novembre 2014. L'utilisateur peut uniquement effectuer les actions SendMessage et ReceiveMessage, tel que défini dans la politique de file d'attente Amazon SQS du compte A.

Délégation d'accès impossible lorsque l'accès est refusé au compte

Un Compte AWS ne peut pas déléguer l'accès aux ressources d'un autre compte si ce dernier a refusé explicitement l'accès au compte parent de l'utilisateur. Le rejet se propage aux utilisateurs sous ce compte, qu'ils aient ou non des politiques existantes leur accordant l'accès.

Par exemple, le compte A crée une politique de compartiment pour son compartiment S3 qui refuse explicitement au compte B l'accès à ce compartiment. Mais le compte B crée une politique d'utilisateur IAM qui accorde à un utilisateur du compte B l'accès au compartiment du compte A. Le refus explicite appliqué au compartiment S3 du compte A est propagé aux utilisateurs du compte B. Il remplace la politique d'utilisateur IAM qui accorde l'accès aux utilisateurs du compte B. (Pour des informations détaillées sur la façon dont les autorisations sont évaluées, consultez Logique d'évaluation de politiques.)

La politique de compartiment du compte A peut se présenter comme suit. Dans cet exemple, le compartiment S3 du compte A est nommé mybucket, et le numéro de compte du compte B est 1111-2222-3333. Le compte A utilise Amazon S3 pour implémenter cette politique.

{
  "Version": "2012-10-17",
  "Statement": {
    "Sid": "AccountBDeny",
    "Effect": "Deny",
    "Principal": {"AWS": "111122223333"},
    "Action": "s3:*",
    "Resource": "arn:aws:s3:::mybucket/*"
  }
}

Ce refus explicite remplace toutes les politiques au sein du compte B qui accordent l'accès au compartiment S3 du compte A.