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 : NotPrincipal
Vous pouvez utiliser l'NotPrincipalélément pour refuser l'accès à tous les principaux, à l'exception de l'IAMutilisateur, de l'utilisateur fédéré, du IAM rôle Compte AWS, du AWS service ou de tout autre principal spécifié dans l'NotPrincipalélément.
Vous pouvez l'utiliser dans les politiques basées sur les ressources pour certains AWS services, notamment VPC les points de terminaison. Les politiques basées sur les ressources sont des politiques que vous intégrez directement à une ressource. Vous ne pouvez pas utiliser l'NotPrincipalélément dans une stratégie IAM basée sur l'identité ni dans une politique de confiance des IAM rôles.
L'élément NotPrincipal doit être utilisé avec "Effect":"Deny". Son utilisation avec "Effect":"Allow" n'est pas prise en charge.
Important
Très peu de scénarios requièrent l'utilisation de l'élément NotPrincipal. Nous vous recommandons d'envisager d'autres options d'autorisation avant de choisir NotPrincipal. Lorsque vous utilisez l'élément NotPrincipal, il peut être difficile de résoudre les problèmes liés à plusieurs types de politique. Nous recommandons plutôt d'utiliser la clé de aws:PrincipalArn contexte avec les opérateurs de ARN condition. Pour de plus amples informations, veuillez consulter Tous les principaux.
Spécifier l'élément NotPrincipal avec Deny
Lorsque vous utilisez NotPrincipal avecDeny, vous devez également spécifier le compte ARN du principal non refusé. Dans le cas contraire, la politique peut refuser l'accès à l'ensemble du compte contenant le principal. En fonction du service que vous incluez dans votre politique, AWS peut valider d'abord le compte, puis l'utilisateur. Si un utilisateur assumant un rôle (une personne utilisant un rôle) est en cours d'évaluation, AWS vous pouvez d'abord valider le compte, puis le rôle, puis l'utilisateur assumé. Ce dernier est identifié par le nom de session de rôle qui est spécifié lorsqu'il endosse le rôle. Par conséquent, nous vous recommandons vivement d'inclure explicitement le ARN pour le compte d'un utilisateur, ou d'inclure à la fois le nom ARN ARN pour un rôle et le compte contenant ce rôle.
Important
N'utilisez pas de déclarations de politique basées sur les ressources qui incluent un élément de NotPrincipal stratégie ayant un Deny effet sur IAM les utilisateurs ou les rôles auxquels est attachée une politique de limites d'autorisations. L'NotPrincipalélément ayant un Deny effet refusera toujours tout IAM principal auquel est attachée une politique de limites d'autorisations, quelles que soient les valeurs spécifiées dans l'NotPrincipalélément. Cela entraîne la perte de l'accès de certains IAM utilisateurs ou rôles qui auraient autrement accès à la ressource. Nous vous recommandons de modifier vos déclarations de politique basée sur les ressources afin d'utiliser l'opérateur de condition ArnNotEquals avec la clé de contexte aws:PrincipalArn dans le but de limiter l'accès plutôt que l'élément NotPrincipal. Pour plus d'informations sur les limites des autorisations, veuillez consulter Limites d'autorisations pour des entités IAM.
Note
À titre de bonne pratique, vous devez inclure ARNs le nom du compte dans votre police. Certains services nécessitent le compteARN, bien que cela ne soit pas obligatoire dans tous les cas. Toutes les politiques existantes qui ne sont pas requises ARN continueront de fonctionner, mais les nouvelles politiques incluant ces services doivent répondre à cette exigence. IAMne suit pas ces services et vous recommande donc de toujours inclure le compteARN.
Les exemples suivants montrent comment utiliser NotPrincipal et "Effect":
"Deny" de manière optimale dans la même instruction de politique.
Exemple IAM d'utilisateur dans le même compte ou dans un compte différent
Dans l'exemple suivant, tous les principaux, à l'exception de l'utilisateur nommé Bob dans Compte AWS 444455556666, se voient explicitement refuser l'accès à une ressource. Notez que, conformément à la meilleure pratique, l'NotPrincipalélément contient à ARN la fois l'utilisateur Bob et Compte AWS celui auquel Bob appartient (arn:aws:iam::444455556666:root). Si l'NotPrincipalélément ne contient que celui de BobARN, la politique peut avoir pour effet de refuser explicitement l'accès à Compte AWS celui qui contient l'utilisateur Bob. Dans certains cas, un utilisateur ne peut pas disposer de plus d'autorisations que son compte parent. Ainsi, si l'accès est refusé explicitement au compte de Bob, Bob serait également dans l'impossibilité d'accéder à la ressource.
Cet exemple fonctionne comme prévu lorsqu'il fait partie d'une déclaration de politique d'une stratégie basée sur les ressources attachée à une ressource identique ou différente Compte AWS (et non 444455556666). Cet exemple seul n'accorde pas d'accès à Bob ; il omet simplement Bob de la liste des principaux auxquels l'accès est explicitement refusé. Pour permettre à Bob d'accéder à la ressource, une autre instruction de politique doit explicitement accorder l'accès à l'aide de "Effect":
"Allow".
{ "Version": "2012-10-17", "Statement": [{ "Effect": "Deny", "NotPrincipal": {"AWS": [ "arn:aws:iam::444455556666:user/Bob", "arn:aws:iam::444455556666:root" ]}, "Action": "s3:*", "Resource": [ "arn:aws:s3:::BUCKETNAME", "arn:aws:s3:::BUCKETNAME/*" ] }] }
Exemple de IAM rôle dans le même compte ou dans un compte différent
Dans l'exemple suivant, tous les principaux, à l'exception de l'utilisateur supposé nommé cross-account-audit-app dans Compte AWS 444455556666, se voient explicitement refuser l'accès à une ressource. Selon la meilleure pratique, l'NotPrincipalélément contient le ARN rôle assumé user (cross-account-audit-app), le rôle (cross-account-read-only-role) et le rôle auquel appartient le rôle ( Compte AWS 444455556666). Si l'NotPrincipalélément manquait le ARN rôle, la politique pourrait avoir pour effet de refuser explicitement l'accès au rôle. De même, s'il manquait ARN l'NotPrincipalélément auquel appartient le rôle, la politique peut avoir pour effet de refuser explicitement l'accès à toutes Compte AWS les entités de ce compte. Compte AWS
Dans certains cas, les utilisateurs assumant un rôle ne peuvent pas avoir plus d'autorisations que leur rôle parent, et les rôles ne peuvent pas avoir plus d'autorisations que leur parent. Ainsi Compte AWS, lorsque l'accès au rôle ou au compte est explicitement refusé, l'utilisateur du rôle assumé peut ne pas être en mesure d'accéder à la ressource.
Cet exemple fonctionne comme prévu lorsqu'il fait partie d'une déclaration de politique d'une stratégie basée sur les ressources attachée à une ressource d'une autre stratégie Compte AWS (et non 444455556666). Cet exemple en lui-même n'autorise pas l'accès à l'utilisateur assumé cross-account-audit-app, il ne figure que dans la liste des principaux utilisateurs explicitement refusés. cross-account-audit-app Pour donner cross-account-audit-app accès à la ressource, une autre déclaration de politique doit explicitement autoriser l'accès en utilisant"Effect":
"Allow".
{ "Version": "2012-10-17", "Statement": [{ "Effect": "Deny", "NotPrincipal": {"AWS": [ "arn:aws:sts::444455556666:assumed-role/cross-account-read-only-role/cross-account-audit-app", "arn:aws:iam::444455556666:role/cross-account-read-only-role", "arn:aws:iam::444455556666:root" ]}, "Action": "s3:*", "Resource": [ "arn:aws:s3:::Bucket_AccountAudit", "arn:aws:s3:::Bucket_AccountAudit/*" ] }] }
Lorsque vous spécifiez une session endossed-role dans un élément NotPrincipal, 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.
