Spécification d'un principal Compte AWS principes Principaux de rôles IAM Principaux de séance de rôle Principaux de l'utilisateur IAM Principaux d'Identity Center Principaux de séance d'utilisateur fédéré AWS principes de service AWS principes de service dans les régions adhérentes Tous les principaux En savoir plus

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

Note

Après avoir créé le rôle, vous pouvez remplacer le compte par « * » pour autoriser tout le monde à endosser le rôle. Dans ce cas, nous vous recommandons vivement de limiter les personnes autorisées à accéder au rôle d'une autre manière, par exemple avec un élément Condition qui limite l'accès à certaines adresses IP. Votre rôle ne doit pas être accessible à n'importe qui !

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.

Rubriques

Spécification d'un principal
Compte AWS principes
Principaux de rôles IAM
Principaux de séance de rôle
Principaux de l'utilisateur IAM
Principaux d'IAM Identity Center
AWS STS principes de session utilisateur fédérée
AWS principes de service
AWS principes de service dans les régions adhérentes
Tous les principaux
En savoir plus

Spécification d'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 :

Compte AWS et utilisateur root
Rôles IAM
Séances de rôle
Utilisateurs IAM
Séances d'utilisateur fédéré
AWS services
Tous les principaux

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

Note

Vous ne pouvez pas utiliser un caractère générique pour faire correspondre une partie d'un nom de principal ou d'un ARN.

Compte AWS principes

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, 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 une forme abrégée composée du préfixe suivi de l'identifiant du compte. "AWS":

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.

Note

Lorsque vous enregistrez une politique basée sur les ressources qui inclut l'ID du compte abrégé, le service peut le convertir en ARN principal. Cela ne modifie pas la fonctionnalité de la politique.

Certains AWS 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 en spécifier plusieurs Compte AWS(ou ID 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 session pour effectuer des opérations AWS, ils jouent le rôle principal de session.

Les rôles IAM sont des identités existantes dans IAM. Les rôles font confiance à une autre identité authentifiée, telle qu'une identité principale AWS ou un utilisateur provenant 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 comme principal de séance de rôle pour effectuer des opérations dans l’interface 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 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" }

Important

Si votre élément Principal dans une politique d'approbation de rôle contient un ARN qui pointe vers un rôle IAM spécifique, alors cet ARN se transforme en l'ID principal unique du rôle lorsque vous enregistrez la politique. Cela permet de réduire le risque d'escalade des privilèges par la suppression et la nouvelle création du rôle. Normalement, vous ne voyez pas cet ID dans la console, car IAM utilise une transformation inverse pour revenir au rôle ARN lorsque la politique d'approbation est affichée. Cependant, si vous supprimez le rôle, vous interrompez la relation. La politique ne s'applique plus, même si vous recréez le rôle, étant donné que le nouvel ID du principal du nouveau rôle ne correspond pas à l'ID stocké dans la politique d'approbation. Dans ce cas, l'ID principal apparaît dans les politiques basées sur les ressources, car il n'est plus AWS possible de le mapper à un ARN valide. Le résultat final est que si vous supprimez et recréez 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'ID du principal, qui est désormais incorrect, par l'ARN correct. L'ARN se transforme à nouveau en nouvel ID principal du rôle lorsque vous enregistrez la politique.

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. Comme il AWS ne convertit pas les ARN des clés de condition en identifiants, les autorisations accordées à l'ARN du 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 AWS, ils jouent le rôle principal de session.

Le format que vous utilisez pour un rôle principal de session dépend de l' AWS STS opération 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 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 session assumé est un principal de session 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 opérations AWS STS d'API.

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.

Principes des sessions de l'OIDC

Un principal de session OIDC est un principal de session qui résulte de l'utilisation de l' AWS STS AssumeRoleWithWebIdentityopération. Vous pouvez utiliser un fournisseur OIDC (IdP) externe pour vous connecter, puis assumer un rôle IAM à 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 Comparaison des opérations AWS STS d'API.

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

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 l'ARN de session de rôle OIDC 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" }

Principaux de séance SAML

Un principal de session SAML est un principal de session qui résulte de l'utilisation de l' AWS STS AssumeRoleWithSAMLopération. Vous pouvez utiliser un fournisseur d'identité SAML externe (IdP) pour vous connecter, puis endosser un rôle IAM à 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 Comparaison des opérations AWS STS d'API.

Lorsque vous émettez un rôle à partir d'un fournisseur d'identité SAML, vous obtenez ce type spécial de principal de séance qui comprend des informations sur le fournisseur d'identité SAML.

Utilisez ce type de principal dans votre politique pour autoriser ou rejeter l'accès 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.

Note

Dans un élément Principal, le nom utilisateur faisant partie d'Amazon Resource Name (ARN) est sensible à la casse.


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

Important

Si votre élément Principal dans une politique d'approbation de rôle comporte un ARN qui pointe vers un utilisateur IAM spécifique, IAM transforme l'ARN en ID du principal unique de l'utilisateur lorsque vous enregistrez la politique. Cela permet de réduire le risque d'escalade des privilèges par la suppression et la nouvelle création de l'utilisateur. Cet ID n'est pas fréquent dans la console, car il existe également une transformation inverse, pour revenir à l'ARN de l'utilisateur, lorsque la politique d'approbation est affichée. Cependant, si vous supprimez l'utilisateur, vous interrompez la relation La politique ne s'applique plus, même si vous recréez l'utilisateur. Cela est dû au fait que le nouvel ID du principal du nouvel utilisateur ne correspond pas à l'ID stocké dans la politique d'approbation. Dans ce cas, l'ID principal apparaît dans les politiques basées sur les ressources, car il n'est plus AWS possible de le mapper à un ARN valide. Par conséquent, si vous supprimez et recréez un utilisateur référencé dans l'élément Principal d'une politique d'approbation, vous devez modifier le rôle afin de remplacer l'ID du principal qui est désormais incorrect par l'ARN correct. IAM transforme à nouveau l'ARN en le nouvel ID du principal de l'utilisateur lorsque vous enregistrez la politique.

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.

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.

Important

AWS recommande d'utiliser des sessions utilisateur AWS STS fédérées uniquement lorsque cela est nécessaire, par exemple lorsqu'un accès utilisateur root est requis. Au lieu de cela, utilisez les rôles pour déléguer les autorisations.

Un principal de session utilisateur AWS STS fédéré est un principal de session qui résulte de l'utilisation de l' AWS STS GetFederationTokenopération. Dans ce cas, AWS STS utilise la fédération d'identité comme méthode permettant d'obtenir des jetons d'accès temporaires au lieu d'utiliser les rôles IAM.

Dans AWS, les utilisateurs IAM ou an 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 opérations AWS STS d'API.

Utilisateur fédéré IAM – Un utilisateur IAM se fédère à l'aide de l'opération GetFederationToken qui donne lieu à un principal de séance d'utilisateur fédéré pour cet utilisateur IAM.
Utilisateur racine fédéré – Un utilisateur racine se fédère à l'aide de l'opération GetFederationToken qui donne lieu à un principal de séance d'utilisateur fédéré pour cet utilisateur racine.

Lorsqu'un utilisateur IAM ou un utilisateur root demande des informations d'identification temporaires pour AWS STS utiliser cette opération, il ouvre une session utilisateur fédérée 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" }

AWS principes de service

Vous pouvez spécifier AWS des services 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. Un principal de service est un identifiant pour un service.

Les rôles IAM qui peuvent être assumés par un AWS service 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 l'être"Service": "*".

L'identifiant d'un principal de service inclut le nom du service et se présente généralement dans le format suivant :

service-name.amazonaws.com

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

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

Vous pouvez lancer des ressources dans plusieurs AWS régions et vous devez vous inscrire dans certaines d'entre elles. Pour obtenir la liste complète des régions auxquelles vous devez adhérer, consultez la section Gestion des AWS régions dans le Références générales AWSguide.

Lorsqu'un AWS 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

Lorsqu'un AWS service d'une région optionnelle adresse 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 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 principal du service régionalisé lorsqu'un AWS service d'une région optionnelle 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é.

Note

Pour les stratégies d'approbation de rôle IAM, nous recommandons d'utiliser le nom du principal de service non régionalisé. Les ressources IAM sont globales et le même rôle peut donc être utilisé dans n'importe quelle région.

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.

Important

Nous vous recommandons fortement de ne pas utiliser de caractère générique (*) dans l'élément Principal d'une politique basée sur les ressources avec un effet Allow, sauf si vous avez l'intention d'accorder un accès public ou anonyme. Sinon, indiquez les principaux, les services ou les comptes AWS visés dans l'élément Principal, puis restreignez davantage l'accès dans l'élément Condition. Cela est particulièrement vrai pour les politiques de confiance des rôles IAM, car elles permettent à d'autres principaux de devenir un principal dans votre compte.

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 faire correspondre une partie d'un nom de principal ou d'un ARN.

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:::BUCKETNAME/*",
        "arn:aws:s3:::BUCKETNAME"
      ],
      "Condition": {
        "ArnNotEquals": {
          "aws:PrincipalArn": "arn:aws:iam::444455556666:user/user-name"
        }
      }
    }
  ]
}

En savoir plus

Pour plus d’informations, consultez les ressources suivantes :

Exemples de politique de compartiment dans le Guide de l'utilisateur service de stockage simple Amazon
Exemples de politiques pour Amazon SNS dans le Guide du développeur Amazon Simple Notification Service
Exemples de politique Amazon SQS dans le Guide du développeur Amazon Simple Queue Service
Politiques de clé dans le Guide du développeur AWS Key Management Service
Identifiants de compte (français non garanti) dans Références générales AWS
Fédération OIDC

Avertissement JavaScript est désactivé ou n'est pas disponible dans votre navigateur.

Pour que vous puissiez utiliser la documentation AWS, Javascript doit être activé. Vous trouverez des instructions sur les pages d'aide de votre navigateur.

Conventions de rédaction

Effect

NotPrincipal