Elementos da política JSON da AWS:NotPrincipal - AWS Identity and Access Management

Elementos da política JSON da AWS:NotPrincipal

Você pode usar o elemento do NotPrincipal para negar o acesso a todas as entidades principais exceto o usuário do IAM, usuário federado, perfil do IAM, Conta da AWS, serviço da AWS ou outra entidade principal especificado no elemento do NotPrincipal.

Você pode usá-lo em políticas baseadas em recursos para alguns serviços da AWS, incluindo endpoints da VPC. As políticas baseadas em recursos são políticas que você incorpora diretamente em um recurso. Não é possível usar o elemento NotPrincipal em uma política baseada em identidade do IAM ou em uma política de perfil do IAM de confiança.

NotPrincipal deve ser usado com "Effect":"Deny". O uso de "Effect":"Allow" não é compatível.

Importante

Muitos poucos cenários exigem o uso de NotPrincipal. Recomendamos que você explore outras opções de autorização antes de decidir usar NotPrincipal. Quando você usa NotPrincipal, pode ser difícil solucionar os problemas causados por vários tipos de política. Em vez disso, recomendamos usar a chave de contexto aws:PrincipalArn com operadores de condição de ARN. Para obter mais informações, consulte Todas as entidades principais.

Especificar NotPrincipal com Deny

Quando você usar NotPrincipal com Deny, você também deve especificar o ARN da conta principal não negada. Caso contrário, a política pode negar o acesso à conta por completo contendo o principal. Dependendo do serviço que você incluir em sua política, a AWS pode validar primeiro a conta e, em seguida, o usuário. Se um usuário de função assumida (alguém que esteja usando uma função) está sendo avaliado, AWS pode validar primeiro a conta, em seguida, a função e, por fim, o usuário de função assumida. O usuário de função assumida é identificado pelo nome de sessão da função, especificado quando ele assumiu a função. Portanto, é recomendável incluir explicitamente o ARN para uma conta de usuário, ou incluir o ARN para a função e o ARN para a conta que contém essa função.

Importante

Não use declarações de política baseadas em recursos que incluam um elemento de política NotPrincipal com um efeito Deny para usuários ou perfis do IAM que tenham uma política de limite de permissões anexada. O elemento NotPrincipal com um efeito Deny sempre negará qualquer entidade principal do IAM que tenha uma política de limite de permissões anexada, independentemente dos valores especificados no elemento NotPrincipal. Isso faz com que alguns usuários ou perfis do IAM que, de outra forma, teriam acesso ao recurso, percam o acesso. Recomendamos alterar suas declarações de política baseadas em recursos para usar o operador de condição ArnNotEquals com a chave de contexto aws:PrincipalArn para limitar o acesso, em vez do elemento NotPrincipal. Para obter mais informações sobre esses limites de permissões, consulte Limites de permissões para entidades do IAM.

nota

Como prática recomendada, você deve incluir os ARNs para a conta em sua política. Alguns serviços exigem o ARN da conta, embora isso não seja necessário em todos os casos. Todas as políticas existentes sem o ARN necessário continuarão funcionando, mas as novas políticas que incluírem esses serviços deverão atender a esse requisito. O IAM não rastreia esses serviços e, portanto, recomenda que você sempre inclua o ARN da conta.

Os exemplos a seguir mostram como usar NotPrincipal e "Effect": "Deny" na mesma declaração de política com eficácia.

exemplo Exemplo de usuário do IAM na mesma conta ou em outra conta

No exemplo a seguir, todas as entidades principais, exceto o usuário de nome Bob na Conta da AWS 444455556666, têm o acesso explicitamente negado a um recurso. Observe que, como prática recomendada, o elemento NotPrincipal contém o ARN do usuário Bob e da Conta da AWS à qual Bob pertence (arn:aws:iam::444455556666:root). Se o elemento NotPrincipal contivesse apenas o ARN de Bob, o efeito da política poderia ser negar explicitamente o acesso à Conta da AWS que contém esse usuário. Em alguns casos, um usuário não pode ter mais permissões do que sua conta pai, portanto, se a conta de Bob tem o acesso explicitamente negado, Bob também pode ser incapaz de acessar o recurso.

Este exemplo funciona conforme o esperado quando faz parte de uma instrução de política em uma política baseada em recurso que está anexada a um recurso na mesma conta ou em outra Conta da AWS (diferente de 444455556666). Este exemplo por si só não concede acesso a Bob, ele apenas omite Bob da lista de principais que são explicitamente negados. Para conceder a Bob acesso ao recurso, outra declaração de política deve explicitamente permitir o acesso usando "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/*" ] }] }
exemplo Exemplo de função do IAM na mesma conta ou em outra conta

No exemplo a seguir, todas as entidades principais, exceto o usuário de perfil assumido denominado cross-account-audit-app na Conta da AWS 444455556666, têm o acesso explicitamente negado a um recurso. Como prática recomendada, o elemento NotPrincipal contém o ARN do usuário de perfil assumido (cross-account-audit-app), o perfil (cross-account-read-only-role) e a Conta da AWS à qual o perfil pertence (444455556666). Se o elemento NotPrincipal não continha o ARN da função, o efeito da política poderia negar explicitamente o acesso à função. Da mesma forma, se o elemento NotPrincipal não contivesse o ARN da Conta da AWS à qual o perfil pertence, o efeito da política poderia ser negar explicitamente o acesso à Conta da AWS e todas as entidades nessa conta. Em alguns casos, os usuários de perfil assumido não podem ter mais permissões do que seu perfil pai, e perfis não podem ter mais permissões do que sua Conta da AWS pai, de forma que quando o perfil ou a conta tem o acesso explicitamente negado, o usuário de perfil assumido poderia ser incapaz de acessar o recurso.

Este exemplo funciona conforme o esperado quando faz parte de uma instrução de política em uma política baseada em recurso anexada a um recurso em outra Conta da AWS (exceto 444455556666). Este exemplo por si só não concede acesso ao usuário de função assumida cross-account-audit-app, ele apenas omite o cross-account-audit-app da lista de principais que são explicitamente negados. Para conceder a cross-account-audit-app acesso ao recurso, outra declaração de política deve explicitamente permitir o acesso usando "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/*" ] }] }

Ao especificar uma sessão de função assumida em um elemento NotPrincipal, não é possível usar um curinga (*) para significar "todas as sessões". Os principais devem sempre nomear uma sessão específica.