Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

AWS JSONéléments de politique : Principal

Utilisez l'Principalélément d'une JSON politique basée sur les ressources pour spécifier le principal auquel l'accès à une ressource est autorisé ou refusé.

Vous devez utiliser l'élément Principal dans les politiques basées sur les ressources. Plusieurs services soutiennent les politiques basées sur les ressources, notamment. IAM Le type de stratégie IAM basé sur les ressources est une politique de confiance des rôles. Dans IAM les rôles, utilisez l'Principalélément de la politique de confiance des rôles pour spécifier qui peut assumer 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 responsables de comptes situés en dehors de votre zone de confiance (organisation de confiance ou compte) ont accès à vos rôles, voir Qu'est-ce qu'IAMAccess Analyzer ? .

Parmi les autres exemples de ressources qui prennent en charge les politiques basées sur les ressources, citons un compartiment Amazon S3 ou un 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'autorisation que vous associez aux IAM identités (utilisateurs, 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 stratégie (telle qu'une stratégie basée sur les ressources) car les groupes sont liés aux autorisations et non à l'authentification, et les principaux sont des entités authentifiées. IAM

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" 
  ]
}

Compte AWS principals

Vous pouvez spécifier Compte AWS des identifiants dans l'Principalélément d'une politique basée sur les ressources ou dans des 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, l'administrateur de ce compte doit alors accorder l'accès à une identité (IAMutilisateur ou rôle) dans ce compte. Lorsque vous spécifiez un Compte AWS, vous pouvez utiliser le compte ARN (arn:aws:iam : :account-ID:root), ou une forme abrégée composée du "AWS": préfixe 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" }

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

Momentanée AWS les services proposent des options supplémentaires pour spécifier un principal de compte. 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 utilisateur canonique) en tant que principal utilisant 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"
}

IAMprincipes de rôle

Vous pouvez spécifier le IAM rôle principal ARNs dans l'Principalélément d'une politique basée sur les ressources ou dans des clés de condition qui prennent en charge les principaux. IAMles rôles sont des identités. DansIAM, 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. Cela inclut un directeur dans AWS ou un utilisateur 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 session pour effectuer des opérations dans AWS, ils deviennent un rôle principal de session.

IAMles rôles sont des identités qui existent dansIAM. Les rôles font confiance à une autre identité authentifiée, telle qu'un principal dans AWS ou un utilisateur d'un fournisseur d'identité externe. Lorsqu'un principal ou une identité endossent un rôle, ils reçoivent des informations d'identification de sécurité temporaires. Ils peuvent ensuite utiliser ces informations d'identification en tant que rôle principal de session pour effectuer des opérations dans AWS.

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 stratégies.

Pour spécifier le rôle ARN dans l'Principalélément, 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 rôle principal de session reçoit les autorisations en fonction ARN du rôle assumé, et non ARN de la session résultante. Parce que AWS ne convertit pas la clé ARNs de condition enIDs, les autorisations accordées au ARN rôle sont conservées 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 session pour effectuer des opérations dans AWS, ils deviennent un rôle principal de session.

Le format que vous utilisez pour un rôle principal de session dépend du AWS STS opération qui a été utilisée pour assumer 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 le rôle en ARN tant que principal dans la clé de aws:PrincipalArn 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 IAMprincipes de rôle.

Principaux de session à rôle endossé

Un principal de session assumé est un principal de session qui résulte de l'utilisation du AWS STS AssumeRoleopération. Pour de plus amples informations sur les principaux pouvant endosser un rôle à l'aide de cette opération, veuillez consulter Comparez les AWS STS informations d'identification.

Pour spécifier la session assumée ARN dans l'Principalélément, 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.

OIDCprincipes de session

Un principal de OIDC session est un principal de session qui résulte de l'utilisation du AWS STS AssumeRoleWithWebIdentityopération. Vous pouvez utiliser un OIDC fournisseur externe (IdP) pour vous connecter, puis assumer un IAM rôle à l'aide de cette opération. Cela tire parti de la fédération d'identité et génère une séance de rôle. Pour de plus amples informations sur les principaux pouvant endosser un rôle à l'aide de cette opération, veuillez consulter Comparez les AWS STS informations d'identification.

Lorsque vous attribuez un rôle à un OIDC fournisseur, vous obtenez ce type spécial de principal de session qui inclut des informations sur le OIDC fournisseur.

Utilisez ce type de principal dans votre politique pour autoriser ou rejeter l'accès en fonction du fournisseur d'identité web approuvé. Pour spécifier la session de OIDC rôle ARN dans l'Principalélément d'une politique de confiance des rôles, utilisez le format suivant :

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

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

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

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

SAMLprincipes de session

Un principal de SAML session est un principal de session qui résulte de l'utilisation du AWS STS AssumeRoleWithSAMLopération. Vous pouvez utiliser un fournisseur d'SAMLidentité (IdP) externe pour vous connecter, puis assumer un IAM rôle à l'aide de cette opération. Cela tire parti de la fédération d'identité et génère une séance de rôle. Pour de plus amples informations sur les principaux pouvant endosser un rôle à l'aide de cette opération, veuillez consulter Comparez les AWS STS informations d'identification.

Lorsque vous attribuez un rôle à un fournisseur SAML d'identité, vous obtenez ce type spécial de principal de session qui inclut des informations sur le fournisseur SAML d'identité.

Utilisez ce type principal dans votre politique pour autoriser ou refuser l'accès en fonction du fournisseur SAML d'identité fiable. Pour spécifier la session du rôle SAML d'identité ARN dans l'Principalélément d'une politique de confiance des rôles, utilisez le format suivant :

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

IAMprincipes d'utilisation

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

"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.

IAMPrincipes du centre d'identité

Dans IAM Identity Center, le principal d'une politique basée sur les ressources doit être défini comme Compte AWS principal. Pour spécifier l'accès, faites référence au rôle ARN de l'autorisation définie dans le bloc de conditions. Pour plus de détails, consultez Référencer des ensembles d'autorisations dans les politiques relatives aux ressourcesEKS, Amazon et AWS KMSdans le guide de l'utilisateur d'IAMIdentity Center.

AWS STS principes de session utilisateur fédérée

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 AWS STS un principal de session utilisateur fédéré est un principal de session qui résulte de l'utilisation du AWS STS GetFederationTokenopération. Dans ce cas, AWS STS utilise la fédération d'identité comme méthode pour obtenir des jetons d'accès temporaires au lieu d'utiliser IAM des rôles.

Entrée AWS, IAM des utilisateurs ou un Utilisateur racine d'un compte AWS peut 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 Comparez les AWS STS informations d'identification.

Lorsqu'un IAM utilisateur ou un utilisateur root demande des informations d'identification temporaires à AWS STS à l'aide de cette opération, ils démarrent une session utilisateur fédérée temporaire. Cette session ARN est basée sur l'identité d'origine qui a été fédérée.

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

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

AWS principes de service

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

IAMrôles qui peuvent être assumés par un AWS les services 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 IAM politique ne peut pas l'ê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 AWS des services qui fonctionnent avec IAM, en vérifiant si le service indique Yes (Oui) dans la colonne Service-linked role (rôle lié à un service) et en ouvrant le lien Yes (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'assumer ce 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"
   ]
}

AWS principes de service dans les régions adhérentes

Vous pouvez lancer des ressources dans plusieurs AWS Régions et certaines de ces régions auxquelles vous devez vous inscrire. Pour une liste complète des régions auxquelles vous devez vous inscrire, voir Gestion AWSRégions du Références générales AWSguide.

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

service-name.amazonaws.com

Quand un AWS le service d'une région optionnelle envoie une demande interrégionale à une autre région, le format du nom principal du service est identifié comme étant la version régionalisée de son nom principal de service :

service-name.{region}.amazonaws.com

Par exemple, vous avez une SNS rubrique Amazon située dans Region ap-southeast-1 et un bucket Amazon S3 situé dans une Region opt-in. ap-east-1 Vous souhaitez configurer les notifications du compartiment S3 pour publier des messages sur le SNS sujet. Pour autoriser le service S3 à publier des messages sur le SNS sujet, vous devez accorder au service S3 l'sns:Publishautorisation principale via la politique d'accès basée sur les ressources du sujet.

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 de la Principal politique d'accès aux SNS rubriques.

"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 principal du service régionalisé lorsqu'un AWS le service d'une région optionnelle envoie une demande à une autre région. Une fois que vous avez spécifié le nom principal du service régionalisé, si le bucket sns:Publish envoie une demande au SNS sujet situé dans une autre région, la demande sera acceptée. L'exemple suivant indique le principal de service S3 régionalisé dans l'élément de stratégie de la Principal politique d'accès aux SNS rubriques.

"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). Aucune autre autorisation n'est requise pour les IAM utilisateurs et les responsables de rôles au sein de votre compte. 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 faire correspondre une partie d'un nom principal ouARN.

L'exemple suivant montre une politique basée sur les ressources qui peut être utilisée à la place de Spécifier l'élément NotPrincipal avec Deny dans le but de refuser explicitement tous les principaux, à l'exception de ceux qui sont spécifiés dans l'élément Condition.

{
  "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 :