AWS Éléments de politique JSON: Principal

Utilisez l'élément Principal dans une politique JSON basée sur les ressources pour spécifier le principal qui est autorisé ou non à accéder à une ressource.

Vous devez utiliser l'élément Principal dans les politiques basées sur les ressources. Plusieurs services prennent en charge les politiques basées sur les ressources, y compris IAM. Le type de politique basée sur les ressources IAM est une politique d'approbation de rôle. Dans les rôles IAM, utilisez l'élément Principal dans la politique d'approbation du rôle pour spécifier qui peut endosser le rôle. Lorsqu'il s'agit d'un accès entre comptes, vous devez spécifier l'identifiant à 12 chiffres du compte approuvé. Pour savoir si les principaux des comptes situés en dehors de votre zone de confiance (organisation ou compte de confiance) ont accès à vos rôles, consultez Qu'est-ce que l'Analyseur d'accès IAM ?.

D'autres exemples de ressources prenant en charge les politiques basées sur les ressources incluent un compartiment Amazon S3 ou une interface AWS KMS key.

Vous ne pouvez pas utiliser l'élément Principal dans une politique basée sur l'identité. Les politiques basées sur l'identité sont des politiques d'autorisations que vous attachez aux identités IAM (utilisateur, groupes ou rôles) . Dans ces cas, le principal est implicitement l'identité à laquelle est attachée la politique.

Comment spécifier un principal

Vous spécifiez un principal dans l'élément Principal d'une politique basée sur les ressources ou des clés de condition prenant en charge les principaux.

Vous pouvez spécifier l'un des principaux suivants dans une politique :

Vous ne pouvez pas identifier un groupe d'utilisateurs en tant que principal dans une politique (telle qu'une politique basée sur les ressources), car les groupes concernent les autorisations, et non l'authentification, et les principaux sont des entités IAM authentifiées.

Vous pouvez spécifier plus d'un principal pour chacun des types de principaux dans les sections suivantes, à l'aide d'un tableau. Les tableaux peuvent inclure une ou plusieurs valeurs. Lorsque vous spécifiez plus d'un principal dans un élément, vous accordez des autorisations à chaque principal. Ceci est un OR logique et non un AND logique, car vous êtes authentifié comme un unique principal à la fois. Si vous incluez plus d'une valeur, utilisez des crochets ([ et ]) et délimitez chaque entrée du tableau par une virgule. L'exemple de politique suivant définit les autorisations pour le compte 123456789012 ou le compte 555555555555.

"Principal" : { 
"AWS": [ 
  "123456789012",
  "555555555555" 
  ]
}

Principaux Compte AWS

Vous pouvez spécifier les identifiants de l'Compte AWS dans l'élément Principal d'une politique basée sur les ressources ou dans les clés de condition qui prennent en charge les principaux. Cela délègue l'autorité sur le compte. Lorsque vous autorisez l'accès à un autre compte, un administrateur de ce compte doit alors accorder l'accès à une identité (utilisateur ou rôle IAM) de ce compte. Lorsque vous spécifiez un Compte AWS, vous pouvez utiliser l'ARN du compte (arn:aws:iam::account-ID:root), ou un format abrégé composé du préfixe "AWS": suivi de l'ID du compte.

Par exemple, soit un ID de compte 123456789012, vous pouvez utiliser l'une des méthodes suivantes pour spécifier ce compte dans l'élément Principal :

"Principal": { "AWS": "arn:aws:iam::123456789012:root" }

"Principal": { "AWS": "123456789012" }

L'ARN du compte et l'ID de compte abrégé se comportent de la même manière. Les deux délèguent des autorisations au compte. L'utilisation de l'ARN du compte dans l'élément Principal ne limite pas les autorisations au seul utilisateur racine du compte.

Certains services AWS prennent en charge des options supplémentaires pour la spécification d'un compte de principal. Par exemple, Amazon S3 vous permet de spécifier un ID d'utilisateur canonique à l'aide du format suivant :

"Principal": { "CanonicalUser": "79a59df900b949e55d96a1e698fbacedfd6e09d98eacf8f8d5218e7cd47ef2be" }

Vous pouvez également spécifier plusieurs Compte AWS (ou ID d'utilisateur canonique) en tant que principal à l'aide d'un tableau. Par exemple, vous pouvez spécifier un principal dans une politique de compartiment à l'aide des trois méthodes.

"Principal": { 
  "AWS": [
    "arn:aws:iam::123456789012:root",
    "999999999999"
  ],
  "CanonicalUser": "79a59df900b949e55d96a1e698fbacedfd6e09d98eacf8f8d5218e7cd47ef2be"
}

Principaux de rôles IAM

Vous pouvez spécifier les ARN principaux du rôle IAM dans l'élément Principal d'une politique basée sur les ressources ou des clés de condition prenant en charge les principaux. Les rôles IAM sont des identités. Dans IAM, les identités sont des ressources auxquelles vous pouvez attribuer des autorisations. Les rôles font confiance à une autre identité authentifiée pour endosser ce rôle. Il s'agit notamment d'un principal dans l’interface AWS ou d'un utilisateur provenant d'un fournisseur d'identité externe (IdP). Lorsqu'un principal ou une identité endosse un rôle, ils reçoivent des informations d'identification de sécurité temporaires avec les autorisations du rôle endossé. Lorsqu'ils utilisent ces informations d'identification de séance pour effectuer des opérations dans l’interface AWS, elles deviennent un principal de séance de rôle.

Lorsque vous spécifiez un principal de rôle dans une politique basée sur les ressources, les autorisations effectives du principal sont limitées par tous les types de politique limitant les autorisations pour le rôle. Cela inclut les politiques de séance et les limites d'autorisations. Pour plus d’informations sur l'évaluation des autorisations effectives pour une séance de rôle, veuillez consulter Logique d'évaluation de politiques.

Pour spécifier l'ARN du rôle dans l'élément Principal, utilisez le format suivant :

"Principal": { "AWS": "arn:aws:iam::AWS-account-ID:role/role-name" }

Vous pouvez également spécifier le principal du rôle comme principal dans une politique basée sur les ressources ou créer une politique d'autorisation étendue qui utilise la clé de condition aws:PrincipalArn. Lorsque vous utilisez cette clé, le principal de séance de rôle reçoit les autorisations en fonction de l'ARN du rôle qui a été endossé, et non de l'ARN de la séance résultante. Du fait que l’interface AWS ne convertit pas les ARN de clé de condition en ID, les autorisations accordées à l'ARN du rôle persistent si vous supprimez le rôle, puis créez un nouveau rôle portant le même nom. Les types de politiques basées sur l'identité, tels que les limites de permissions ou les politiques de session, ne limitent pas les autorisations accordées à l'aide de la clé de condition aws:PrincipalArn avec un caractère générique(*) dans l'élément Principal, à moins que les politiques basées sur l'identité ne contiennent un rejet explicite.

Principaux de séance de rôle

Vous pouvez spécifier des séances de rôle dans l'élément Principald'une politique basée sur les ressources ou des clés de condition prenant en charge les principaux. Lorsqu'un principal ou une identité endosse un rôle, ils reçoivent des informations d'identification de sécurité temporaires avec les autorisations du rôle endossé. Lorsqu'ils utilisent ces informations d'identification de séance pour effectuer des opérations dans l’interface AWS, elles deviennent un principal de séance de rôle.

Le format que vous utilisez pour un principal de séance de rôle dépend de l'opération AWS STS qui a été utilisée pour endosser le rôle.

En outre, les administrateurs peuvent concevoir un processus pour contrôler la façon dont les séances de rôle sont émises. Par exemple, ils peuvent fournir une solution en un clic à leurs utilisateurs qui crée un nom de séance prévisible. Si votre administrateur procède ainsi, vous pouvez utiliser des principaux de séance de rôle dans vos politiques ou clés de condition. Sinon, vous pouvez spécifier l'ARN du rôle comme principal dans la aws:PrincipalArn clé de condition. La façon dont vous spécifiez le rôle comme principal peut modifier les autorisations effectives pour la séance résultante. Pour plus d’informations, veuillez consulter Principaux de rôles IAM.

Principaux de session à rôle endossé

Un principal de séance à rôle endossé est un principal de séance qui résulte de l'utilisation de l'opération AWS STS AssumeRole. Pour de plus amples informations sur les principaux pouvant endosser un rôle à l'aide de cette opération, veuillez consulter Comparaison des informations d’identification AWS STS.

Pour spécifier l'ARN de la séance à rôle endossé dans l'élément Principal, utilisez le format suivant :

"Principal": { "AWS": "arn:aws:sts::AWS-account-ID:assumed-role/role-name/role-session-name" }

Lorsque vous spécifiez une session à rôle endossé dans un élément Principal, vous ne pouvez pas utiliser un caractère générique « * » pour signifier toutes les sessions. Les principaux doivent toujours nommer une session spécifique.

Principaux fédérés OIDC

Un principal fédéré OIDC est le principal utilisé lors de l’appel d’une API AssumeRoleWithWebIdentity AWS STS avec un jeton Web JSON (JWT) à partir d’un IDP compatible OIDC, également appelé fournisseur OpenID (OP), pour demander des informations d’identification AWS temporaires. Un principal fédéré OIDC peut représenter un IDP OIDC dans votre compte AWS, ou les 4 fournisseurs d’identité intégrés : Login with Amazon, Google, Facebook et Amazon Cognito.

Les utilisateurs, les charges de travail ou les systèmes auxquels un JWT a été délivré par leur IDP OIDC peuvent appeler AssumeRoleWithWebIdentity à l’aide du JWT pour demander des informations d’identification de sécurité AWS temporaires pour un rôle IAM configuré pour faire confiance à l’IDP OIDC qui a délivré le JWT. Le JWT peut être un jeton d’identification, un jeton d’accès ou un jeton JWT délivré par toute autre méthode, à condition qu’il réponde aux exigences énumérées par AWS STS. Pour plus d’informations, consultez les Scénarios courants et Demande d’informations d’identification par le biais d’un fournisseur OIDC.

Utilisez ce type principal dans votre politique de confiance des rôles pour autoriser ou refuser les autorisations d’appel à AssumeRoleWIthWebIdentity à l’aide d’un IDP OIDC qui existe dans votre Compte AWS, ou l’un des quatre IDP intégrés. Pour spécifier l’ARN du principal fédéré OIDC dans l’élément Principal d’une politique de confiance de rôle, utilisez l’un des quatre formats suivants pour les IDP OIDC intégrés :

"Principal": { "Federated": "cognito-identity.amazonaws.com" }

"Principal": { "Federated": "www.amazon.com" }

"Principal": { "Federated": "graph.facebook.com" }

"Principal": { "Federated": "accounts.google.com" }

Lorsque vous utilisez un fournisseur OIDC que vous ajoutez à votre compte, tel que GitHub, vous spécifiez l’ARN du fournisseur dans la politique de confiance de votre rôle. Cette configuration vous permet de rédiger des politiques IAM qui contrôlent spécifiquement l’accès des utilisateurs authentifiés via votre fournisseur d’identité personnalisé.

"Principal": { "Federated": "arn:aws:iam::AWS-account-ID:oidc-provider/full-OIDC-identity-provider-URL" }

Par exemple, si GitHub était le fournisseur d’identité Web de confiance, l’ARN de session de rôle OIDC dans l’élément Principal d’une politique de confiance de rôle utilise le format suivant :

"Principal": { "Federated": "arn:aws:iam::AWS-account-ID:oidc-provider/tokens.actions.githubusercontent.com" }

Pour plus d’informations, consultez Configuration d’OpenID Connect dans Amazon Web Services.

Les principaux fédérés OIDC ne sont pas pris en charge dans les types de politiques autres que les politiques de confiance des rôles.

Principaux fédérés SAML

Un principal fédéré SAML est un principal utilisé lors de l’appel d’une API AssumeRoleWithSAML AWS STS pour demander des informations d’identification AWS temporaires à l’aide d’une assertion SAML. Vous pouvez utiliser votre fournisseur d’identité (IdP) SAML externe (IdP) pour vous connecter, puis endosser un rôle IAM à l’aide de cette opération. Tout comme AssumeRoleWithWebIdentity, AssumeRoleWithSAML ne nécessite pas d’informations d’identification AWS pour l’authentification. Au lieu de cela, les utilisateurs s’authentifient d’abord auprès de leur fournisseur d’identité SAML, puis effectuent l’appel API AssumeRoleWithSAML à l’aide de leur assertion SAML, ou sont redirigés vers la page de connexion/SAML d’AWS pour se connecter à AWS Management Console. Pour de plus amples informations sur les principaux pouvant endosser un rôle à l'aide de cette opération, veuillez consulter Comparaison des informations d’identification AWS STS.

Utilisez ce type de principal dans votre politique de confiance des rôles pour autoriser ou rejeter des autorisations en fonction du fournisseur d’identité SAML approuvé. Pour spécifier l'ARN de séance du rôle d'identité SAML dans l'élément Principal d'une politique d'approbation de rôle, utilisez le format suivant :

"Principal": { "Federated": "arn:aws:iam::AWS-account-ID:saml-provider/provider-name" }

Principaux de l'utilisateur IAM

Vous pouvez spécifier des utilisateurs IAM dans l'élément Principal d'une politique basée sur les ressources ou dans les clés de condition qui prennent en charge les principes.

"Principal": { "AWS": "arn:aws:iam::AWS-account-ID:user/user-name" }

"Principal": {
  "AWS": [
    "arn:aws:iam::AWS-account-ID:user/user-name-1", 
    "arn:aws:iam::AWS-account-ID:user/user-name-2"
  ]
}

Lors de la spécification d'utilisateurs dans un élément Principal, il n'est pas possible d'utiliser un caractère générique (*) signifiant « tous les utilisateurs ». Les principaux doivent toujours nommer des utilisateurs spécifiques.

Principaux d'IAM Identity Center

Dans IAM Identity Center, le principal d'une politique basée sur les ressources doit être défini comme étant le principal Compte AWS. Pour spécifier l'accès, faites référence à l'ARN du rôle du jeu d'autorisations dans le bloc de conditions. Pour en savoir, consultez Référencement des jeux d'autorisations dans les politiques de ressources, Amazon EKS et AWS KMS (français non garanti) dans le Guide de l'utilisateur IAM Identity Center.

principaux d’utilisateur fédéré AWS STS

Vous pouvez spécifier des séances d'utilisateur fédéré dans l'élément Principal d'une politique basée sur les ressources ou dans les clés de condition qui prennent en charge les principaux.

Un principal utilisateur fédéré AWS STS est créé par le biais de l’opération GetFederationToken appelée avec des informations d’identification IAM de longue durée. Les autorisations utilisateur fédérées correspondent à l’intersection entre le principal qui a appelé GetFederationToken et les politiques de session transmises en tant que paramètres à l’API GetFederationToken.

Dans l'interface AWS, les utilisateurs IAM ou un Utilisateur racine d'un compte AWS peuvent s'authentifier à l'aide de clés d'accès à long terme. Pour plus d'informations sur les principaux qui peuvent se fédérer à l'aide de cette opération, veuillez consulter Comparaison des informations d’identification AWS STS.

Lorsqu'un utilisateur IAM ou un utilisateur racine demande des informations d'identification temporaires à l’interface AWS STS à l'aide de cette opération, il démarre une séance d'utilisateur fédéré temporaire. L'ARN de cette séance est basé sur l'identité originale qui a été fédérée.

Pour spécifier l'ARN de la séance d'utilisateur fédéré dans l'élément Principal, utilisez le format suivant :

"Principal": { "AWS": "arn:aws:sts::AWS-account-ID:federated-user/user-name" }

AWStitulaires de service

Vous pouvez spécifier les services AWS dans l'élément Principal d'une politique basée sur les ressources ou dans les clés de condition qui prennent en charge les principaux. Un principal de service est un identifiant pour un service.

Les rôles IAM qui peuvent être endossés par un service AWS sont appelés rôles de service. Les rôles de service doivent inclure une politique d'approbation. Les politiques d'approbation sont des politiques basées sur les ressources attachées à un rôle qui définit les principaux qui peuvent endosser le rôle. Certains rôles de service disposent de politiques d'approbation prédéfinies. Toutefois, dans certains cas, vous devez spécifier le principal du service dans la politique d'approbation. Le principal de service d’une politique IAM ne peut pas être "Service": "*".

Le principal de service est défini par le service. Vous pouvez rechercher le principal de service pour certains services en ouvrant l’interface AWSServices qui fonctionnent avec IAM, en vérifiant si le service indique Oui dans la colonne Rôle lié à un service et en ouvrant le lien Oui pour afficher la documentation du rôle lié à un service pour ce service. Recherchez la section Autorisations de rôles liés à un service correspondant à ce service pour afficher le principal du service.

L'exemple suivant illustre une politique qui est peut être attachée à un rôle de service. La politique permet à deux services, Amazon ECS et Elastic Load Balancing, d'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.

"Principal": {
    "Service": [
        "ecs.amazonaws.com",
        "elasticloadbalancing.amazonaws.com"
   ]
}

Principaux de service AWS dans les régions d'adhésion

Vous pouvez lancer des ressources dans plusieurs régions AWS et vous devez vous inscrire pour certaines de ces régions. Pour obtenir la liste complète des régions pour lesquelles vous devez vous inscrire, consultez la section Gestion des régions AWS (français non garanti) dans le guide Références générales AWS.

Lorsqu'un service AWS d'une région d'adhésion fait une demande dans la même région, le format du nom du principal de service est identifié comme la version non régionalisée de son nom du principal de service :

service-name.amazonaws.com

Lorsqu'un service AWS d'une région d'adhésion adresse une demande inter-région à une autre région, le format du nom du principal de service est identifié comme la version régionalisée de son nom du principal de service :

service-name.{region}.amazonaws.com

Par exemple, vous avez une rubrique Amazon SNS dans la région ap-southeast-1 et un compartiment Amazon S3 dans la région d'adhésion ap-east-1. Vous voulez configurer les notifications du compartiment S3 pour publier des messages dans la rubrique SNS. Pour permettre au service S3 de publier des messages dans la rubrique SNS, vous devez accorder au principal de service S3 une autorisation sns:Publish via la stratégie d'accès basée sur les ressources de la rubrique.

Si vous spécifiez la version non régionalisée du principal de service S3, s3.amazonaws.com, dans la stratégie d'accès à la rubrique, la demande sns:Publish du compartiment vers la rubrique échouera. L'exemple suivant indique le principal de service S3 non régionalisé dans l'élément de stratégie Principal de la stratégie d'accès à la rubrique SNS.

"Principal": { "Service": "s3.amazonaws.com" }

Étant donné que le compartiment se trouve dans une région d'adhésion et que la demande est faite en dehors de cette même région, le principal de service S3 apparaît comme le nom du principal de service régionalisé, s3.ap-east-1.amazonaws.com. Vous devez utiliser le nom du principal de service régionalisé lorsqu'un service AWS d'une région d'adhésion adresse une demande à une autre région. Une fois que vous avez spécifié le nom du principal de service régionalisé, si le compartiment adresse une demande sns:Publish à la rubrique SNS située dans une autre région, la demande sera réussie. L'exemple suivant indique le principal de service S3 régionalisé dans l'élément de stratégie Principal de la stratégie d'accès à la rubrique SNS.

"Principal": { "Service": "s3.ap-east-1.amazonaws.com" }

Les stratégies de ressources ou les listes d'autorisation basées sur le principal de service pour les demandes inter-région d'une région d'adhésion vers une autre région ne seront réussies que si vous spécifiez le nom du principal de service régionalisé.

Tous les principaux

Vous pouvez utiliser un caractère générique (*) pour spécifier tous les principaux dans l'élément Principal d'une politique basée sur les ressources ou dans les clés de condition prenant en charge les principaux. Politiques basées sur les ressources accorde des autorisations et les clés de condition sont utilisées pour limiter les conditions d'une déclaration de politique.

Pour les politiques basées sur les ressources, utiliser un caractère générique (*) avec un effect Allow accorde l'accès à tous les utilisateurs, y compris les utilisateurs anonymes (accès public). Pour les utilisateurs IAM et les principaux de rôle de votre compte, aucune autre autorisation n'est requise. Pour les principaux d'autres comptes, ils doivent également disposer d'autorisations basées sur l'identité dans leur compte qui les autorise à accéder à votre ressource. C'est ce que l'on appelle l'accès entre comptes.

Pour les utilisateurs anonymes, les éléments suivants sont équivalents :

"Principal": "*"

"Principal" : { "AWS" : "*" }

Vous ne pouvez pas utiliser un caractère générique pour une correspondance à une partie d’un nom ou d’un ARN principal.

L'exemple suivant montre une politique basée sur les ressources qui peut être utilisée à la place de AWS Éléments de politique JSON: NotPrincipal dans le but de refuser explicitement tous les principaux, à l'exception de ceux qui sont spécifiés dans l'élément Condition. Cette politique doit être ajoutée à un compartiment Amazon S3.

JSON

{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Sid": "UsePrincipalArnInsteadOfNotPrincipalWithDeny",
      "Effect": "Deny",
      "Action": "s3:*",
      "Principal": "*",
      "Resource": [
        "arn:aws:s3:::amzn-s3-demo-bucket/*",
        "arn:aws:s3:::amzn-s3-demo-bucket"
      ],
      "Condition": {
        "ArnNotEquals": {
          "aws:PrincipalArn": "arn:aws:iam::444455556666:user/user-name"
        }
      }
    }
  ]
}

En savoir plus

Pour plus d’informations, consultez les ressources suivantes :