Como soluciono mensagens de erro de negação explícita ao solicitar chamadas de API usando perfis ou usuários do IAM?

Breve descrição

Para que uma entidade do IAM (perfil ou usuário) 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.
• A permissão não é negada por nenhuma instrução em todas as políticas aplicáveis ao contexto da solicitação.

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

• “Usuário ou perfil do IAM enfrentando o problema: arn:XXXXXXXX:iam::XXXXXXXX:role/TestReadOnly”
• “Erro: Ocorreu um erro (AccessDenied) ao chamar a operação RunInstances: Usuário: arn:aws:iam::XXXXXXXX:user/tester não está autorizado a executar: ec2:RunInstances no recurso: perfil testReadOnly com uma negação explícita”

Observação: as etapas de solução de problemas neste artigo tratam especificamente de erros de negação explícita e 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 implícitas e explícitas.

Resolução

Erros de negação explícita ocorrem devido a problemas em uma ou mais das seguintes políticas:

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

Políticas baseadas em identidade

A política baseada em identidade controla a ação permitida/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 um acesso privilegiado acidental.

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

{
  "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 usar outro fator de autenticação quando a MFA for aplicada, a permissão será negada. Por exemplo, se sua entidade se autenticar usando a AWS CLI sem MFA, sua chamada de API será negada. Veja este exemplo de aplicação da MFA:

{
  "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.

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, as condições serão avaliadas usando a lógica AND. Cada chave RequestTag deve ser usada em instruçõ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:

{
  "Sid": "AllowRunInstancesWithRestrictions2",
  "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 a condição anterior foi atendida.

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, as políticas baseadas em recursos são projetadas pelos serviços. 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:

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

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

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

{
  "Effect": "deny",
  "Principal": {
    "AWS": "arn:aws:iam::111111111111:role/ROLENAME"
  },
  "Action": "s3:ListBucket",
  "Resource": "arn:aws:s3:::MyExampleBucket"
}

2.    Verifique se os ARNs descritos 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:::MyExampleBucket",
        "arn:aws:s3:::MyExampleBucket/*"
      ],
      "Condition": {
        "StringNotLike": {
          "aws:userId": [
            "AROAEXAMPLEID:*",
            "AIDAEXAMPLEID",
            "111111111111"
          ]
        }
      }
    }
  ]
}

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:

• Você pode 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.
• Você pode 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 examplebucket, do endpoint da VPC com o ID vpce-11111. A política nega todo acesso ao bucket se o endpoint especificado não for usado. A condição aws:SourceVpce é usada para especificar o endpoint.

{
   "Version": "2012-10-17",
   "Id": "Policy123456789”,
   "Statement": [
     {
       "Sid": "AccessSpecificVPCEOnly",
       "Principal": "*",
       "Action": "s3:*",
       "Effect": "Deny",
       "Resource": ["arn:aws:s3:::examplebucket",
                    "arn:aws:s3:::examplebucket/*"],
       "Condition": {
         "StringNotEqualsIfExists": {
           "aws:SourceVpce": "vpce-11111”
         }
       }
     }
   ]
}

Sempre verifique se o endpoint da VPC não está negando 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 é permitida na política do IAM, mas é explicitamente negada no limite de permissões. 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 o IAM estejam permitindo explicitamente essa ação.

Políticas de controle de serviço

Uma política de controle de serviço (SCP) permite que você gerencie as permissões em sua organização. O exemplo a seguir mostra uma instrução de negação na SCP. Neste exemplo, a SCP é anexada a uma conta-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, execute uma das seguintes ações:

• Separe a SCP da conta.
• Modifique a instrução de negação adicionando uma condição que exclua alguns casos de uso. Por exemplo, essa SCP neste exemplo NÃO nega ec2:RunInstances se a entidade principal do IAM usar o perfil CloudOps:

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

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. Você pode criar uma sessão de perfil e passar políticas de sessão usando 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

Gerenciamento de acesso para recursos da AWS

Como usar políticas de controle de serviço para definir barreiras de proteção em todas as contas em sua organização da AWS

Limites de permissões para entidades do IAM

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

Controlar o acesso a partir de endpoints de VPC com políticas de bucket