Saltar al contenido
Al usar AWS re:Post, aceptas las AWS re:Post Términos de uso
AWS re:Postre:Post
Acerca de re:Post

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

10 minutos de lectura
0

Quiero que solucionar un mensaje de error de denegación explícita cuando solicito una llamada a la API con un rol o un usuario de AWS Identity and Access Management (IAM).

Descripción corta

Para que un rol o usuario de IAM pueda realizar correctamente una llamada a la API, la entidad debe cumplir las siguientes condiciones:

  • El rol o el usuario tienen los permisos correctos para solicitar una llamada a la API.
  • Ninguna instrucción de las políticas que se aplican al contexto de la solicitud deniega el permiso.

Si la entidad de IAM no cumple estas condiciones, la llamada a la API falla y devuelve un error Access denied similar al siguiente:

  • "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"

Nota: Los pasos de solución de problemas de este artículo se refieren específicamente a los errores de denegación explícita y no a los errores de denegación implícita. Para obtener más información sobre los errores de denegación implícita, consulta 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 los siguientes tipos de políticas:

  • Políticas basadas en identidad
  • Políticas basadas en recursos
  • Límite de permisos
  • Políticas de control de servicios
  • Políticas de control de recursos
  • Políticas de sesión

Políticas basadas en identidad

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

Nota: Se recomienda utilizar Deny con StringNotLike en condiciones para evitar un acceso bloqueo accidental.

  1. Comprueba que no haya ninguna instrucción de denegación en tu política basada en identidad. Este ejemplo contiene una instrucción de denegación:

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

  2. Comprueba si la autenticación multifactor (MFA) está incluida en la política. Si tu entidad de IAM se autentica sin MFA y se le aplica una política de cumplimiento de MFA, se deniega el permiso. Consulta este ejemplo de aplicación de la 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"
                }
            }
        }
    ]
}

    Esta política deniega explícitamente todas las llamadas a la API, excepto las que se mencionan en el elemento de política NotAction si la entidad de IAM no está autenticada con MFA.

  3. Asegúrate de que la política cumpla con todas las condiciones requeridas. Si tu política tiene varios operadores de condiciones o varias claves, AWS evalúa las condiciones con la lógica AND. Cada clave de contexto de condición debe usarse en instrucciones independientes para obtener la misma lógica AND. Este es un ejemplo de un problema común que provoca un error en la llamada a la API:

    {
    "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 un error de denegación de acceso explícito en estas llamadas a la API, asegúrate de cumplir la condición.
    Nota: La condición aws:TagKeys distingue entre mayúsculas y minúsculas.

Políticas basadas en recursos

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

Evaluación de la política de bucket de S3

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

  • Para acceder a un bucket de la misma cuenta, una entidad de IAM necesita permisos en la política basada en identidad de IAM O en la política de bucket.
  • Para acceder a un bucket en otra cuenta, una entidad de IAM necesita permisos en la política de bucket Y la política basada en identidad de IAM para poder acceder.

Nota: Esto supone que la ACL del bucket está configurada de forma predeterminada.

  1. Comprueba si hay instrucciones de denegación en la política basada en recursos. En este ejemplo se muestra una instrucción de denegación en la 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. Comprueba que los ARN de tu política sean correctos.

  3. La política de bucket deniega el acceso si el aws:userid del usuario actual no coincide con lo que defines en la política. Consulta este ejemplo:

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

Punto de enlace de VPC

Una política de punto de enlace de VPC es una política de recursos de IAM que se adjunta a un punto de enlace. Esta política no anula ni reemplaza las políticas de usuario de IAM ni las políticas específicas del servicio, como las políticas de bucket de S3.

Hay dos maneras de controlar el acceso a los datos de Amazon S3 cuando se utiliza un punto de enlace de interfaz para conectarse a Amazon S3:

  • Puedes controlar las entidades principales de AWS (cuentas de AWS, usuarios de IAM y roles de IAM) que pueden usar el punto de enlace de VPC para acceder al servicio de punto de enlace.
  • Puedes controlar las VPC o los puntos de enlace 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 example-bucket, desde el punto de enlace de VPC con el ID vpce-1a2b3c4d. La política deniega todo acceso al bucket si no utilizas el punto de enlace especificado. La condición aws:SourceVpce especifica el punto de enlace.

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

Comprueba siempre que el punto de enlace de VPC no deniegue explícitamente 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 generar mensajes de error de denegación explícita.

En este ejemplo se muestra una acción que la política de IAM permite pero que el límite de permisos deniega explícitamente. Consulta 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ícita cuando lo solicita. Para resolver este error, asegúrate de que tanto el límite de permisos como la política de IAM permiten esta acción de forma explícita.

Políticas de control de servicios

Una política de control de servicio (SCP) te permite administrar los permisos en tu organización. En el siguiente ejemplo se muestra una instrucción de denegación en el SCP. En este ejemplo, el SCP se adjunta a una cuenta de miembro o a una unidad organizativa (UO) en particular. Deniega explícitamente 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ícita, desconecta las políticas de control de servicio (SCP) de la cuenta. O bien, agrega una condición a la instrucción de denegación para excluir algún caso de uso.

Por ejemplo, la SCP de este ejemplo no deniega ec2:RunInstances si la entidad principal de IAM usa el rol 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 control de recursos

Las políticas de control de recursos (RCP) te permiten controlar de forma centralizada el máximo de permisos disponibles para los recursos de tu organización. Los RCP son compatibles con los siguientes tipos de recursos:

  • Amazon S3
  • AWS Security Token Service
  • AWS Key Management Service
  • Amazon SQS
  •  AWS Secrets Manager
  •  Amazon Elastic Container Registry
  • Amazon OpenSearch sin servidor

En este ejemplo, se adjunta la RCP a una unidad organizativa (UO) o a una cuenta de miembro. Deniega explícitamente la acción DeleteObject en todos los buckets de S3:

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

Para resolver los errores de denegación explícita, desconecta las políticas de control de recursos (RCP) de la cuenta. O bien, agrega una condición a la instrucción de denegación para excluir algún caso de uso.

Por ejemplo, la RCP de este ejemplo no deniega ec2:RunInstances si la entidad principal de IAM usa el rol 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 sesión

Las políticas de sesión son políticas avanzadas que se aprueban como parámetro al crear una sesión temporal para un rol o un usuario de forma programática. Puedes crear una sesión de rol y aprobar políticas de sesión con las operaciones de 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. Comprueba siempre las instrucciones de denegación en la política de sesión:

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

Información relacionada

How to use service control policies to set permission guardrails across accounts in your AWS Organization (Cómo utilizar las políticas de control de servicio para establecer barreras de protección de permisos en las cuentas de tu organización de AWS)

Límites de permisos para las entidades de IAM

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

AWSSupport-TroubleshootIAMAccessDeniedEvents

Sin comentarios

Contenido relevante