Como faço para solucionar problemas de mensagens de erro de negação explícitas 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 gerará um erro (AccessDenied) semelhante a este:

• IAM user or role experiencing the issue: arn:XXXXXXXX:iam::XXXXXXXX:role/TestReadOnly(Usuário ou perfil do IAM com o problema: arn:XXXXXXXX:iam::XXXXXXXX:role/TestReadOnly)

Error: An error occurred (AccessDenied) when calling the RunInstances operation: User: arn:aws:iam::XXXXXXXX:user/tester is not authorized to perform: ec2:RunInstances on resource: role TestReadOnly with an explicit deny (Erro: Ocorreu um erro (AccessDenied) ao chamar a operação RunInstances: User: 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 lidam especificamente com erros de negação explícitos e não erros de negação implícitos. Para obter mais informações sobre erros de negação implícitos, consulte 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 estas 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 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) está aplicada à sua política. Se a entidade do IAM for autenticada sem usar outro fator de autenticação quando a MFA for aplicada, a permissão será negada. Por exemplo, se sua entidade for autenticada usando a AWS CLI sem MFA, sua chamada de API será negada. Veja este exemplo de aplicação de 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"}
  }
}

Esta 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. Ao contrário das políticas baseadas em identidade do IAM, que são unificadas, as políticas baseadas em recursos são projetadas por 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 maneira:

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

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

1.    Verifique se há instruçõ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 negará acesso se o aws:userid do usuário atual não for igual ao definido na política. Veja este 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 anula nem substitui as políticas de usuário do IAM ou políticas específicas do serviço (como políticas de bucket do S3).

Há duas maneiras de controlar o acesso aos 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 de endpoint.
• Você pode controlar as VPCs ou os endpoints da VPC que têm acesso aos seus buckets usando políticas de bucket do Amazon S3.

Este exemplo abaixo corresponde a 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 o 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 permissões a entidades, o que pode resultar em mensagens de erro de negação explícitas.

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 solicita permissão para a referida ação. Para resolver esse erro, verifique se o limite de permissões e o IAM estão permitindo explicitamente essa ação.

Políticas de controle de serviço

Uma política de controle de serviços (SCP) permite que você gerencie permissões em sua organização. O exemplo a seguir mostra uma instrução de negação na SCP. Neste exemplo, a SCP é vinculada a uma conta de membro ou a uma Unidade Organizacional (OU) 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 destas ações:

• Desvincule a SCP da conta.
• Modifique a instrução de negação adicionando uma condição que exclua algum caso de uso. Por exemplo, a SCP neste exemplo NÃO negará ec2:RunInstances se a entidade principal do IAM usar a função 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

Políticas de sessão são políticas avançadas que você aprova como parâmetro ao criar programaticamente uma sessão temporária para um perfil ou usuário. Você pode criar uma sessão de função e aprovar 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á instruções de negação na política de sessão:

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

---

Informações relacionadas

Gerenciamento de acesso para recursos da AWS

How to use service control policies to set permission guardrails across accounts in your AWS Organization (Como usar políticas de controle de serviço para definir barreiras de proteção de permissão entre contas no AWS Organizations)

Limites de permissões para entidades do IAM

How to restrict Amazon S3 bucket access to a specific IAM role (Como restringir o acesso ao bucket do Amazon S3 a um perfil do IAM específico)

Controlar o acesso de endpoints da VPC com políticas de bucket