¿Cómo soluciono los mensajes de error de denegación explícita al solicitar llamadas a la API con usuarios o roles de IAM?

Descripción corta

Para que una entidad de IAM (rol o usuario) realice una llamada a la API de manera correcta, esta debe cumplir las siguientes condiciones:

• El rol o el usuario tiene los permisos correctos para solicitar una llamada a la API.
• El permiso no está denegado por ninguna declaración en todas las políticas aplicables al contexto de la solicitud.

Si la entidad de IAM no cumple con estas condiciones, la llamada a la API fallará y generará un error (AccessDenied) similar al siguiente:

• Usuario o rol de IAM que está experimentando el 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 (Error: Se produjo un error [AccessDenied] al llamar a la operación RunInstances: Usuario: arn:aws:iam::XXXXXXXX:user/tester no está autorizado para ejecutar: ec2:RunInstances en el recurso: rol TestReadOnly con una denegación explícita)

Nota: Los pasos de solución de problemas de este artículo tratan de forma específica sobre los errores de denegación explícita y no de los errores de denegación implícita. Para obtener más información sobre los errores de denegación implícita, consulte The difference between implicit and explicit denies (La diferencia entre denegaciones implícitas y explícitas).

Resolución

Los errores de denegación explícita se producen debido a problemas en una o más de las siguientes políticas:

• Políticas basadas en la identidad
• Políticas basadas en los recursos
• Límite de permisos
• Políticas de control de servicios
• Política de sesiones

Políticas basadas en la identidad

La política basada en la identidad controla la acción permitida o denegada de una entidad. Siga estos pasos de solución de problemas para identificar problemas con las políticas basadas en la identidad.

Nota: Es una práctica recomendada utilizar Deny (Denegar) con StringNotLike como condición para evitar el acceso con privilegios accidental.

1.    Compruebe que no haya ninguna declaración de denegación en la política basada en la identidad. Este ejemplo contiene una declaración de denegación:

{
  "Effect": "Deny",
  "Action": "iam:DeleteRole"
  "Resource": "*"
}

2.    Compruebe si la autenticación multifactor (MFA) se aplica a la política. Si la entidad de IAM se autentica sin utilizar otro factor de autenticación cuando se aplica la MFA, se deniega el permiso. Por ejemplo, si la entidad se autentica con AWS CLI sin la MFA, se deniega la llamada a la API. Consulte este ejemplo de aplicación de la 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 deniega de manera explícita todas las llamadas a la API, excepto las que se mencionan en el elemento de política NotAction.

3.    Asegúrese de que la política cumpla con todas las condiciones requeridas. Si la política tiene varios operadores de condición o varias claves, las condiciones se evalúan mediante la lógica AND. Cada clave RequestTag debe utilizarse en declaraciones individuales para obtener la misma lógica AND. Este es un ejemplo de un problema común que hace que la llamada a la API falle:

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

A fin de evitar un error explícito de denegación de acceso para estas llamadas a la API, asegúrese de que se cumpla la condición anterior.

Nota: La condición aws:TagKeys distingue entre mayúsculas y minúsculas.

Políticas basadas en los recursos

La política basada en los recursos permite o deniega el acceso a un recurso. A diferencia de las políticas basadas en la identidad de IAM que están unificadas, las políticas basadas en los recursos están diseñadas por los servicios. Los siguientes pasos de solución de problemas utilizan políticas basadas en los recursos de Amazon Simple Storage Service (Amazon S3) y una política de punto de conexión de VPC como ejemplos.

Evaluación de políticas de bucket de S3

La evaluación de políticas de bucket de Amazon S3 funciona de la siguiente manera:

Nota: Se supone que la ACL del bucket está configurada como predeterminada.

• Para acceder a un bucket en la misma cuenta, una entidad de IAM necesita permisos en la política de bucket OR basada en la identidad de IAM.
• Con la finalidad de acceder a un bucket en una cuenta diferente, una entidad de IAM necesita permisos en la política de bucket AND en la identidad de IAM para obtener acceso.

1.    Compruebe si hay declaraciones de denegación en la política basada en los recursos. En este ejemplo se muestra una declaración denegación en la política de bucket:

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

2.    Compruebe que los ARN descritos en la política sean correctos.

3.    La política de bucket deniega el acceso si el aws:userid del usuario actual no es igual al definido en la política. Consulte este ejemplo:

{
  "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"
          ]
        }
      }
    }
  ]
}

Punto de conexión de VPC

Una política de punto de conexión de VPC es una política de recursos de IAM que se adjunta a un punto de conexión. Esta política no anula ni reemplaza las políticas de usuario de IAM ni las políticas específicas de servicios (como las políticas de bucket de S3).

Hay dos formas de controlar el acceso a los datos de Amazon S3 cuando se utiliza un punto de conexión de interfaz para conectarse a Amazon S3:

• Puede controlar las entidades principales de AWS (cuentas de AWS, usuarios de IAM y roles de IAM) que pueden utilizar el punto de conexión de VPC para acceder al servicio de punto de conexión.
• Puede controlar las VPC o los puntos de conexión de VPC que tienen acceso a los buckets mediante las políticas de bucket de Amazon S3.

El siguiente ejemplo es una política de bucket de Amazon S3. La política restringe el acceso a un bucket específico, denominado examplebucket, desde el punto de conexión de VPC con el ID vpce-11111. La política deniega todo acceso al bucket si no se utiliza el punto de conexión especificado. La condición aws:SourceVpce se utiliza para especificar el punto de conexión.

{
   "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”
         }
       }
     }
   ]
}

Compruebe siempre que el punto de conexión de VPC no deniegue de forma explícita el acceso al recurso.

Límite de permisos

El límite de permisos es una política administrada que establece los permisos máximos que una política basada en identidad puede conceder a una entidad de IAM. Esta política administrada puede restringir los permisos a las entidades, lo que puede provocar mensajes de error de denegación explícitos.

En este ejemplo se muestra una acción que está permitida en la política de IAM, pero que se deniega de forma explícita en el límite de permisos. Consulte el límite de permisos a continuación:

{
  "Version": "2012-10-17",

  "Statement": [

    {
      "Effect": "Deny",
      "Action": "ec2:*"

      "Resource": "*"
    }
  ]
}

El usuario tiene los siguientes permisos:

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

Aunque el usuario tiene el permiso RunInstances, recibe un mensaje de denegación explícito cuando lo solicita. Para resolver este error, asegúrese de que el límite de permisos e IAM permitan de forma explícita esta acción.

Políticas de control de servicios

Una política de control de servicios (SCP) permite administrar los permisos en la organización. El siguiente ejemplo muestra una declaración de denegación en la SCP. En este ejemplo, la SCP se adjunta a una cuenta de miembro o a una unidad organizativa (OU) en particular. Deniega de forma explícita el acceso a la acción RunInstances:

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

      "Resource": "*"
    }
  ]
}

Para resolver los errores de denegación explícitos, realice una de las siguientes acciones:

• Desvincule la SCP de la cuenta.
• Modifique la declaración de denegación al agregar una condición que excluya algún caso de uso. Por ejemplo, esta SCP de este ejemplo NO niega ec2:RunInstances si la entidad principal de IAM utiliza el rol CloudOps:

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

Políticas de sesión

Las políticas de sesión son políticas avanzadas que se pasan como un parámetro cuando se crea mediante programación una sesión temporal para un rol o usuario. Puede crear una sesión de rol y aprobar políticas de sesión mediante las operaciones de la API AssumeRole, AssumeRoleWithSAML o AssumeRoleWithWebIdentity.

Por ejemplo, esta política genera un error de denegación explícita cuando el usuario intenta realizar una llamada a la API RunInstances. Compruebe siempre las declaraciones de denegación en la política de sesión:

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

---

Información relacionada

Administración de acceso a los recursos de AWS

Cómo utilizar las políticas de control de servicios para establecer barreras de protección de permisos entre cuentas de AWS Organizations

Límites de permisos para entidades de IAM

Cómo restringir el acceso al bucket de Amazon S3 a un rol de IAM específico

Control del acceso desde los puntos de conexión de VPC con políticas de bucket