Elemento de la política de JSON de AWS: NotPrincipal

Puede utilizar el elemento NotPrincipal para denegar el acceso a todas las entidades principales, excepto el usuario de IAM, el usuario federado, el rol de IAM, la Cuenta de AWS, el servicio de AWS u otra entidad principal especificada en el elemento NotPrincipal.

Puede utilizarlo en políticas basadas en recursos para servicios de AWS, incluidos los puntos de conexión de VPC. Las políticas basadas en recursos son políticas que se integran directamente en un recurso. No puede utilizar el elemento NotPrincipal en una política basada en identidad de IAM ni en una política de confianza de rol de IAM.

NotPrincipal se debe usar con "Effect":"Deny". No se admite su uso con "Effect":"Allow".

importante

En muy pocas situaciones se exige el uso de NotPrincipal. Le recomendamos que sopese otras opciones de autorización antes de decidirse por utilizar NotPrincipal. Cuando utilice NotPrincipal, puede ser difícil solucionar los efectos de varios tipos de política. En su lugar, recomendamos utilizar la clave de contexto aws:PrincipalArn con los operadores de condición de ARN. Para obtener más información, consulte Todas las entidades principales.

Especificar NotPrincipal con Deny

Cuando se utiliza NotPrincipal con Deny, también debe especificar el ARN de la cuenta del principal no denegado. De lo contrario, la política podría denegar el acceso a toda la cuenta que contenga el principal. En función del servicio que incluya en la política, AWS podría validar primero la cuenta y después al usuario. Si se está evaluando a un usuario de rol asumido (alguien que utiliza un rol), AWS podría validar primero la cuenta, después el rol y, por último, al usuario de rol asumido. El usuario de rol asumido se identifica mediante el nombre de la sesión de rol que se especifica cuando asumieron el rol. Por lo tanto, le recomendamos encarecidamente que incluya de forma explícita el ARN de la cuenta de un usuario, o que incluya tanto el ARN de un rol como el ARN de la cuenta que contenga dicho rol.

importante

No utilice instrucciones de política basadas en recursos que incluyan un elemento de política NotPrincipal con un efecto Deny para los usuarios o roles de IAM que tengan una política de límite de permisos adjunta. El elemento NotPrincipal con efecto Deny siempre denegará cualquier entidad principal de IAM que tenga una política de límite de permisos adjunta, independientemente de los valores especificados en el elemento NotPrincipal. Esto provoca que algunos usuarios o roles de IAM que de otro modo tendrían acceso al recurso pierdan dicho acceso. Recomendamos cambiar las instrucciones de política basadas en recursos y utilizar el operador de condición ArnNotEquals con la clave de contexto aws:PrincipalArn para limitar el acceso en lugar del elemento NotPrincipal. Para obtener información sobre los límites de permisos, consulte Límites de permisos para las entidades de IAM.

nota

Como práctica recomendada, debe incluir los ARN de la cuenta en su política. Algunos servicios requieren el ARN de la cuenta, aunque esto no es necesario en todos los casos. Cualquier política existente sin el ARN necesario seguirá funcionando, pero las nuevas políticas que incluyan estos servicios deben cumplir este requisito. IAM no realiza un seguimiento de estos servicios y, por lo tanto, recomienda que incluya siempre la cuenta ARN.

En los ejemplos siguientes se muestra cómo utilizar NotPrincipal y "Effect": "Deny" en la misma instrucción de política efectivamente.

ejemplo Ejemplo de usuario de IAM de la misma cuenta o de otra cuenta

En el siguiente ejemplo, se deniega explícitamente a todos las entidades principales el acceso a un recurso, excepto al usuario denominado Bob de la Cuenta de AWS 444455556666. Tenga en cuenta que, como práctica recomendada, el elemento NotPrincipal contiene el ARN tanto del usuario Bob como de la Cuenta de AWS a la que pertenece Bob (arn:aws:iam::444455556666:root). Si el elemento NotPrincipal contuviera únicamente el ARN de Bob, el efecto de la política podría ser denegar explícitamente el acceso a la Cuenta de AWS que contiene al usuario Bob. En algunos casos, un usuario no puede tener más permisos que su cuenta principal, de modo que si se deniega explícitamente el acceso a la cuenta de Bob, Bob tampoco podría obtener acceso al recurso.

Este ejemplo funciona según lo previsto cuando forma parte de una instrucción de una política basada en recursos asociada a un recurso en la misma Cuenta de AWS o en otra cuenta (no 444455556666). Este ejemplo por sí mismo no concede acceso a Bob, se limita a no mencionar a Bob en la lista de principales a los que se deniega el acceso de forma explícita. Para permitir a Bob el acceso al recurso, deberá haber otra instrucción en la política que permita el acceso de forma explícita con "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/*"
        ]
    }]
}

ejemplo Ejemplo de rol de IAM de la misma cuenta o de otra cuenta

En el siguiente ejemplo, se deniega explícitamente a todos las entidades principales el acceso a un recurso, excepto al usuario de rol asumido denominado cross-account-audit-app en la Cuenta de AWS 444455556666. Como práctica recomendada, el elemento NotPrincipal contiene el ARN del usuario del rol asumido (cross-account-audit-app), el rol (cross-account-read-only-role) y la Cuenta de AWS a la que pertenece el rol (444455556666). Si el elemento NotPrincipal no tuviese el ARN del rol, el efecto de la política podría ser denegar explícitamente el acceso al rol. Del mismo modo, si el elemento NotPrincipal no tuviese el ARN de la cuenta de Cuenta de AWS a la que pertenece el rol, el efecto de la política podría ser denegar explícitamente el acceso a la Cuenta de AWS y a todas las entidades de esa cuenta. En algunos casos, los usuarios de rol asumido no pueden tener más permisos que su rol principal y los roles no pueden tener más permisos que su Cuenta de AWS principal, por lo que cuando se deniega el acceso explícitamente al rol o la cuenta, el usuario del rol asumido podría no obtener acceso al recurso.

Este ejemplo funciona según lo previsto cuando forma parte de una instrucción de una política basada en recursos asociada a un recurso de otra Cuenta de AWS (no en 444455556666). En este ejemplo en sí no se permite el acceso al usuario de rol asumido cross-account-audit-app, simplemente no se menciona cross-account-audit-app en la lista de principales a los que se deniega el acceso explícitamente. Para dar a cross-account-audit-app acceso al recurso, la política debe tener otra instrucción que permita de forma explícita el acceso con "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/*"
        ]
    }]
}

Al especificar una sesión de rol asumido en un elemento NotPrincipal, no puede utilizar un comodín (*) para referirse a "todas las sesiones". Las entidades principales siempre deben designar a una sesión específica.