AWS Éléments de politique JSON : NotPrincipal

Vous pouvez utiliser l'élément NotPrincipal pour refuser l'accès à tous les principaux, à l'exception de l'utilisateur IAM, l'utilisateur fédéré, le rôle IAM, Compte AWS, le service AWS ou tout autre principal spécifié dans l'élément NotPrincipal.

Vous pouvez l'utiliser dans des politiques basées sur les ressources pour certains services AWS, y compris les points de terminaison d'un VPC. Les politiques basées sur les ressources sont des politiques que vous intégrez directement à une ressource. Vous ne pouvez pas utiliser l'élément NotPrincipal dans une politique IAM basée sur l'identité ni dans une politique d'approbation du rôle IAM.

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 l'utilisation de la clé de contexte aws:PrincipalArn avec les opérateurs de condition ARN. Pour de plus amples informations, veuillez consulter Tous les principaux.

Spécifier l'élément NotPrincipal avec Deny

Lorsque vous utilisez NotPrincipal avec Deny, vous devez également spécifier l'ARN du compte 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 qui endosse un rôle (quelqu'un qui utilise un rôle) est évalué, AWS peut valider d'abord le compte, puis le rôle et enfin, l'utilisateur qui endosse le rôle. 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 l'ARN du compte d'un utilisateur, ou inclure à la fois l'ARN d'un rôle et l'ARN du compte contenant le rôle.

Important

N'utilisez pas de déclarations de politique basée sur les ressources qui incluent un élément de politique NotPrincipal ayant un effet Deny sur les utilisateurs IAM ou les rôles auxquels est attachée une politique de limites des autorisations. L'élément NotPrincipal ayant un effet Deny refusera toujours tout principal IAM auquel est attachée une politique de limite des autorisations, quelles que soient les valeurs spécifiées dans l'élément NotPrincipal. Certains utilisateurs ou rôles IAM qui auraient autrement eu accès à la ressource n'y ont donc plus accès. 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 les entités IAM.

Note

En tant que bonne pratique, vous devez inclure les ARN pour le compte dans votre politique. Certains services nécessitent l'ARN du compte, bien que ce ne soit pas obligatoire dans tous les cas. Toutes les politiques existantes sans l'ARN requis continuent de fonctionner, mais les nouvelles politiques qui incluent ces services doivent répondre à cette exigence. IAM n'assure pas le suivi de ces services ; par conséquent nous recommandons de toujours inclure le compte ARN.

Les exemples suivants montrent comment utiliser NotPrincipal et "Effect": "Deny" de manière optimale dans la même instruction de politique.

Exemple d'utilisateur IAM dans le même compte ou un compte différent

Dans l'exemple suivant, l'accès à une ressource est explicitement refusé à tous les principaux, excepté à l'utilisateur nommé Bob, dans l'Compte AWS 444455556666. Notez que, selon les bonnes pratiques, l'élément NotPrincipal contient l'ARN de l'utilisateur Bob et de l'Compte AWS auquel Bob appartient (arn:aws:iam::444455556666:root). Si l'élément NotPrincipal ne contient que l'ARN de Bob, la politique peut avoir pour effet de refuser explicitement l'accès au Compte AWS contenant 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 instruction de politique dans une politique basée sur les ressources qui est attachée à une ressource dans le même compte ou dans un Compte AWS différent (pas 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 rôle IAM dans le même compte ou un compte différent

Dans l'exemple suivant, l'accès à une ressource est explicitement refusé à tous les principaux, excepté à l'utilisateur qui endosse le rôle nommé cross-account-audit-app dans l'Compte AWS 444455556666. Selon les bonnes pratiques, l'élément NotPrincipal contient l'ARN de l'utilisateur du rôle endossé (cross-account-audit-app), le rôle (cross-account-read-only-role) et l'Compte AWS auquel le rôle appartient (444455556666). Si l'élément NotPrincipal ne contient pas l'ARN du rôle, la politique refuserait explicitement l'accès au rôle. De la même façon, si l'élément NotPrincipal ne contient pas l'ARN de l'Compte AWS auquel appartient le rôle, la politique refuserait explicitement l'accès à l'Compte AWS ainsi qu'à toutes les entités qu'il contient. 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 compte Compte AWS. Ainsi, lorsque le rôle ou le compte se voit explicitement refuser l'accès, l'utilisateur assumant ce rôle peut être incapable d'accéder à la ressource.

Cet exemple fonctionne comme prévu lorsqu'il fait partie d'une instruction de politique dans une politique basée sur les ressources qui est attachée à une ressource appartenant à un autre Compte AWS (pas 444455556666). Cet exemple seul n'autorise pas l'accès à l'utilisateur qui endosse le rôle (cross-account-audit-app) ; il l'omet simplement de la liste des principaux auxquels l'accès est explicitement refusé. Pour accorder à l'utilisateur cross-account-audit-app l'accès à la ressource, une autre instruction de politique doit explicitement accorder cet accès à l'aide de "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.