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

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

Utiliser les rôles pour déléguer l'accès aux ressources d'un autre Compte AWS resources

Pour un didacticiel expliquant comment utiliser les IAM rôles pour accorder aux utilisateurs d'un seul compte l'accès à AWS ressources qui se trouvent dans un autre compte, voirIAMtutoriel : Déléguer l'accès à travers AWS comptes utilisant des IAM rôles.

Important

Vous pouvez inclure le ARN pour un rôle ou un utilisateur spécifique dans l'Principalélément d'une politique de confiance des rôles. Lorsque vous enregistrez la politique, AWS le transforme ARN en un identifiant 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. Normalement, vous ne voyez pas cet identifiant dans la console, car il y a également une transformation inverse vers le ARN moment où la politique de confiance 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'identifiant principal apparaît dans la console car AWS ne peut plus le mapper à unARN. Par conséquent, si vous supprimez et recréez un utilisateur ou un rôle référencé dans l'Principalélément d'une politique de confiance, vous devez modifier le rôle pour remplacer leARN. 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, Amazon EMR et AWS Data Pipeline, pour assumer 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. Le compte B crée ensuite une politique IAM utilisateur pour déléguer cet accès au bucket 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 s'appelle amzn-s3-demo-bucket, 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:::amzn-s3-demo-bucket",
      "arn:aws:s3:::amzn-s3-demo-bucket/*"
    ]
  }
}

Le compte A peut également utiliser les listes de contrôle d'accès Amazon S3 (ACLs) pour accorder au compte B l'accès à un compartiment S3 ou à un seul objet au sein d'un compartiment. Dans ce cas, la seule chose qui change est 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 IAM groupe du compte B, comme décrit dans la partie suivante 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 mettre en œuvre cette politique, le compte B l'associe à l'utilisateur (ou au groupe) approprié dans le compte B. IAM

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

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

Dans l'exemple suivant, le compte A possède une SQS file d'attente Amazon qui utilise une politique basée sur les ressources attachée à la file d'attente pour accorder l'accès à la file d'attente au compte B. Ensuite, le compte B utilise une politique de IAM groupe 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 mettre en œuvre 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 permet IAM d'associer cette politique à un groupe (ou à un utilisateur).

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

Dans l'exemple de politique IAM utilisateur précédent, le compte B utilise un caractère générique pour accorder à ses utilisateurs l'accès à toutes les SQS actions Amazon sur 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 ne peut effectuer que les ReceiveMessage actions SendMessage et, comme défini dans la politique de SQS file d'attente Amazon 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 celui-ci a explicitement refusé 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 rédige une politique IAM utilisateur 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 se propage aux utilisateurs du compte B. Il remplace la politique IAM utilisateur accordant l'accès à l'utilisateur du compte B. (Pour des informations détaillées sur la manière dont les autorisations sont évaluées, voirLogique d’évaluation de stratégies.)

La politique de compartiment du compte A peut se présenter comme suit. Dans cet exemple, le compartiment S3 du compte A s'appelle amzn-s3-demo-bucket et le numéro de 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:::amzn-s3-demo-bucket/*"
  }
}

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