Ir para o conteúdo
Ao usar o AWS re:Post, você concorda com os AWS re:Post Termos de uso
AWS re:Postre:Post
sobre o re:Post

Como soluciono mensagens de erro de negação explícita quando solicito chamadas de API com perfis ou usuários do IAM?

9 minuto de leitura
0

Quero solucionar uma mensagem de erro de negação explícita ao fazer uma chamada de API com um perfil ou usuário do AWS Identity and Access Management (AWS IAM).

Breve descrição

Para que um perfil ou usuário do IAM faça uma chamada de API bem-sucedida, a entidade deve atender às seguintes condições:

  • O perfil ou o usuário tem as permissões corretas para solicitar uma chamada de API.
  • Nenhuma declaração nas políticas que se aplicam ao contexto da solicitação nega a permissão.

Se sua entidade do IAM não atender a essas condições, a chamada de API falhará e retornará um erro de acesso negado semelhante ao seguinte:

  • "IAM user or role that has the issue: arn:aws:iam::444455556666:role/ExampleRole"
  • "Error: An error occurred (AccessDenied) when calling the RunInstances operation: User: arn:aws:iam::444455556666:user/ExampleUser is not authorized to perform: ec2:RunInstances on resource: arn:aws:ec2:us-east-1:444455556666:volume/* with an explicit deny"

Observação: as etapas de solução de problemas neste artigo tratam especificamente de erros de negação explícita, não de erros de negação implícita. Para obter mais informações sobre erros de negação implícita, consulte A diferença entre negações explícitas e implícitas.

Resolução

Erros de negação explícita ocorrem devido a problemas em um ou mais dos seguintes tipos de política:

  • Políticas baseadas em identidade
  • Políticas baseadas em recursos
  • Limite de permissões
  • Políticas de controle de serviços
  • Políticas de controle de recursos
  • Políticas de sessão

Políticas baseadas em identidade

A política baseada em identidade controla a ação permitida ou negada de uma entidade. Use essas etapas de solução de problemas para identificar problemas com políticas baseadas em identidade.

Observação: é uma prática recomendada usar Deny com StringNotLike em condições para evitar bloqueio acidental.

  1. Verifique se não existe nenhuma declaração de negação em sua política baseada em identidade. Este exemplo contém uma declaração de negação:

    {
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Deny",
            "Action": "iam:DeleteRole",
            "Resource": "*"
        }
    ]
}

  2. Verifique se a autenticação multifator (MFA) é aplicada em sua política. Se sua entidade do IAM se autenticar sem MFA e uma política de imposição de MFA se aplicar a ela, a permissão será negada. Veja este exemplo de imposição de MFA:

    {
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "DenyAllExceptListedIfNoMFA",
            "Effect": "Deny",
            "NotAction": [
                "iam:CreateVirtualMFADevice",
                "iam:EnableMFADevice",
                "iam:GetUser",
                "iam:ListMFADevices",
                "iam:ListVirtualMFADevices",
                "iam:ResyncMFADevice",
                "sts:GetSessionToken"
            ],
            "Resource": "*",
            "Condition": {
                "BoolIfExists": {
                    "aws:MultiFactorAuthPresent": "false"
                }
            }
        }
    ]
}

    Essa política nega explicitamente todas as chamadas de API, exceto aquelas mencionadas no elemento de política NotAction se a entidade do IAM não estiver autenticada com a MFA.

  3. Certifique-se de que sua política atenda a todas as condições exigidas. Se sua política tiver vários operadores de condição ou várias chaves, a AWS avalia as condições com a lógica AND. Cada chave de contexto de condição deve ser usada em declarações separadas para obter a mesma lógica AND. Este é um exemplo de um problema comum que faz com que a chamada de API falhe:

    {
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowRunInstancesWithRestrictions",
            "Effect": "Deny",
            "Action": [
                "ec2:CreateVolume",
                "ec2:RunInstances"
            ],
            "Resource": [
                "arn:aws:ec2:*:*:volume/*",
                "arn:aws:ec2:*:*:instance/*"
            ],
            "Condition": {
                "ForAllValues:StringNotLike": {
                    "aws:TagKeys": "Production"
                },
                "StringEquals": {
                    "ec2:InstanceType": "t2.micro"
                }
            }
        }
    ]
}

    Para evitar um erro de negação explícita de acesso para essas chamadas de API, verifique se você atende à condição.
    Observação: a condição aws:TagKeys diferencia maiúsculas de minúsculas.

Políticas baseadas em recursos

A política baseada em recursos permite ou nega o acesso a um recurso. Diferentemente das políticas baseadas em identidade do IAM, que são unificadas, os serviços projetam as políticas baseadas em recursos. As etapas de solução de problemas a seguir usam políticas baseadas em recursos do Amazon Simple Storage Service (Amazon S3) e uma política de endpoint da VPC como exemplos.

Avaliação da política de bucket do S3

A avaliação da política de bucket do Amazon S3 funciona da seguinte forma:

  • Para acessar um bucket na mesma conta, uma entidade do IAM precisa de permissões na política com base na identidade do IAM OU na política de bucket.
  • Para acessar um bucket em uma conta diferente, uma entidade do IAM precisa de permissões na política de bucket E na política com base na identidade do IAM para obter acesso.

Observação: isso pressupõe que a ACL do bucket esteja definida como padrão.

  1. Verifique as declarações de negação na política baseada em recursos. Este exemplo mostra uma declaração de negação na política de bucket:

    {
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Deny",
            "Principal": {
                "AWS": "arn:aws:iam::444455556666:role/Role"
            },
            "Action": "s3:ListBucket",
            "Resource": "arn:aws:s3:::example-bucket"
        }
    ]
}

  2. Verifique se os ARNs em sua política estão corretos.

  3. A política de bucket nega acesso se o aws:userid do usuário atual não for igual ao definido na política. Neste exemplo:

    {
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Deny",
            "Principal": "*",
            "Action": "s3:*",
            "Resource": [
                "arn:aws:s3:::example-bucket",
                "arn:aws:s3:::example-bucket/*"
            ],
            "Condition": {
                "StringNotLike": {
                    "aws:userid": [
                        "AROAEXAMPLEID:*",
                        "AIDAEXAMPLEID",
                        "444455556666"
                    ]
                }
            }
        }
    ]
}

Endpoint da VPC

Uma política de endpoint da VPC é uma política de recursos do IAM anexada a um endpoint. Essa política não apaga nem substitui as políticas de usuário do IAM ou políticas específicas do serviço, como as políticas de bucket do S3.

Há duas maneiras de controlar o acesso aos seus dados do Amazon S3 ao usar um endpoint de interface para se conectar ao Amazon S3:

  • É possível controlar as entidades principais da AWS (contas da AWS, usuários do IAM e perfis do IAM) que podem usar o endpoint da VPC para acessar o serviço do endpoint
  • É possível controlar as VPCs ou os endpoints de VPC que têm acesso aos seus buckets usando as políticas de bucket do Amazon S3

O exemplo abaixo é uma política de bucket do Amazon S3. A política restringe o acesso a um bucket específico, chamado example-bucket, do endpoint da VPC com o ID vpce-1a2b3c4d. A política nega todo acesso ao bucket se não usar o endpoint especificado. A condição aws:SourceVpce especifica o endpoint.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AccessSpecificVPCEOnly",
            "Principal": "*",
            "Action": "s3:*",
            "Effect": "Deny",
            "Resource": [
                "arn:aws:s3:::example-bucket",
                "arn:aws:s3:::example-bucket/*"
            ],
            "Condition": {
                "StringNotEqualsIfExists": {
                    "aws:SourceVpce": "vpce-1a2b3c4d"
                }
            }
        }
    ]
}

Sempre verifique se o endpoint da VPC não nega explicitamente o acesso ao recurso.

Limite de permissões

O limite de permissões é uma política gerenciada que define o máximo de permissões que uma política baseada em identidade pode conceder a uma entidade do IAM. Essa política gerenciada pode restringir as permissões às entidades, o que pode resultar em mensagens de erro de negação explícita.

Este exemplo mostra uma ação que a política do IAM permite, mas o limite de permissões nega explicitamente. Veja o limite de permissões abaixo:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Deny",
            "Action": "ec2:*",
            "Resource": "*"
        }
    ]
}

O usuário tem as seguintes permissões:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "ec2:RunInstances",
            "Resource": "*"
        }
    ]
}

Embora o usuário tenha a permissão RunInstances, ele recebe uma mensagem de negação explícita quando a solicita. Para resolver esse erro, certifique-se de que seu limite de permissões e a política do IAM permitam explicitamente essa ação.

Políticas de controle de serviços

Uma política de controle de serviços (SCP) permite que você gerencie as permissões em sua organização. O exemplo a seguir mostra uma declaração de negação na SCP. Neste exemplo, a SCP é anexada a uma conta de membro ou a uma Unidade Organizacional (UO) específica. Ela nega explicitamente o acesso à ação RunInstances:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Deny",
            "Action": "ec2:RunInstances",
            "Resource": "*"
        }
    ]
}

Para resolver erros de negação explícita, separe as políticas de controle de serviços (SCPs) da conta. Ou adicione uma condição à declaração de negação para excluir algum caso de uso.

Por exemplo, a SCP neste exemplo não nega ec2:RunInstances se a entidade principal do IAM usar o perfil ExampleCloudOps:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Deny",
            "Action": "ec2:RunInstances",
            "Resource": "*",
            "Condition": {
                "ArnNotLike": {
                    "aws:PrincipalARN": "arn:aws:iam::444455556666:role/ExampleCloudOps"
                }
            }
        }
    ]
}

Políticas de controle de recursos

As políticas de controle de recursos (RCPs) permitem que você controle centralmente o máximo de permissões disponíveis para recursos em sua organização. As RCPs são compatíveis com os seguintes tipos de recursos:

  • Amazon S3
  • Serviço de token de segurança da AWS
  • Serviço de gerenciamento de chaves da AWS
  • Amazon SQS
  •  AWS Secrets Manager
  •  Amazon Elastic Container Registry
  • Amazon OpenSearch Sem Servidor

Neste exemplo, você anexa a RCP a uma Unidade Organizacional (UO) ou a uma conta de membro. Ela nega explicitamente a ação DeleteObject em todos os buckets do S3:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Deny",
            "Principal": "*",
            "Action": "s3:DeleteObject",
            "Resource": "*"
        }
    ]
}

Para resolver erros de negação explícita, separe as políticas de controle de recursos (RCPs) da conta. Ou adicione uma condição à declaração de negação para excluir algum caso de uso.

Por exemplo, essa RCP neste exemplo NÃO nega ec2:RunInstances se a entidade principal do IAM usar o perfil ExampleCloudOps:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Deny",
            "Action": "ec2:RunInstances",
            "Resource": "*",
            "Condition": {
                "ArnNotLike": {
                    "aws:PrincipalARN": "arn:aws:iam::444455556666:role/ExampleCloudOps"
                }
            }
        }
    ]
}

Políticas de sessão

As políticas de sessão são políticas avançadas que você passa como parâmetro ao criar programaticamente uma sessão temporária para um perfil ou usuário. É possível criar uma sessão de perfil e passar políticas de sessão com as operações de API AssumeRole, AssumeRoleWithSAML ou AssumeRoleWithWebIdentity.

Por exemplo, essa política gera o erro de negação explícita quando o usuário tenta fazer uma chamada de API RunInstances. Sempre verifique se há declarações de negação na política da sessão:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Deny",
            "Action": "ec2:RunInstances",
            "Resource": "*"
        }
    ]
}

Informações relacionadas

Como usar políticas de controle de serviços para definir barreiras de proteção em todas as contas na AWS Organization

Limites de permissões para entidades do IAM

Como restringir o acesso ao bucket do Amazon S3 a um perfil do IAM específico

AWSSupport-TroubleshootIAMAccessDeniedEvents

Tópicos
Security, Identity, & Compliance
Tags
AWS Identity and Access Management
Idioma
Português
AWS OFICIALAtualizada há 6 meses
Sem comentários

Conteúdo relevante