Aplicación de controles preventivos en entornos multicuenta

Cuando se opera en entornos multi-cloud, es importante establecer mecanismos de gobernanza centralizada para hacer cumplir las políticas de seguridad.

Hoy en día, es muy común en grandes organizaciones delegar la administración de recursos en la nube a los desarrolladores para acelerar la entrega de valor. Sin embargo, esta delegación requiere mecanismos que definan lo que un desarrollador puede y no puede hacer.

AWS Organizations y tipos de políticas

#

Para implementar gobernanza a gran escala, AWS Organizations proporciona diferentes tipos de políticas que ayudan a gestionar el acceso y la configuración a través de las cuentas de AWS. Estas políticas se dividen en dos categorías: políticas de autorización, que definen los controles de acceso, y políticas de gestión, que regulan las configuraciones de servicios AWS.

• Políticas de autorización: Gestionan el acceso para principals y recursos.

  • Service control policies (SCPs)
  • Resource control policies (RCPs)

• Políticas de gestión: Gestionan la configuración de los servicios de AWS.

  • Declarative policies
  • Backup policies
  • Tag policies
  • Chat application policies
  • AI services opt-out policies

Enfoquémonos en tres tipos clave de políticas de AWS Organizations que ayudan a hacer cumplir la gobernanza a gran escala: Service Control Policies (SCPs), Resource Control Policies (RCPs) y Declarative Policies.

SCPs

#

Service Control Policies (SCPs) ayudan a las organizaciones a hacer cumplir límites a nivel de cuenta de AWS mediante la definición de permisos para usuarios IAM, roles y grupos.

Las SCPs no otorgan permisos, sino que los restringen, asegurando que solo se puedan ejecutar acciones aprobadas a través de las cuentas.

En el siguiente ejemplo, podemos ver esto con más detalle.

Tenemos una cuenta de AWS con un usuario IAM que tiene privilegios de administrador completos. La cuenta tiene una SCP asociado que impide el lanzamiento de instancias EC2 de cualquier tipo que no sea t2.micro.

El contenido de la SCP es el siguiente:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "RequireMicroInstanceType",
      "Effect": "Deny",
      "Action": "ec2:RunInstances",
      "Resource": [
        "arn:aws:ec2:*:*:instance/*"
      ],
      "Condition": {
        "StringNotEquals": {
          "ec2:InstanceType": "t2.micro"
        }
      }
    }
  ]
}

Si el usuario intenta lanzar una instancia EC2 t2.micro, la operación tendrá éxito. Sin embargo, si el usuario intenta lanzar una instancia EC2 t3.micro, la operación fallará con un mensaje de error como este:

An error occurred (UnauthorizedOperation) when calling the RunInstances operation: You are not authorized to perform this operation. User: arn:aws:sts::440473545235:assumed-role/AWSReservedSSO_AdministratorAccess_06f46bi3895578b6/user is not authorized to perform: ec2:RunInstances on resource: arn:aws:ec2:eu-west-1:440473545235:instance/* with an explicit deny in a service control policy.

Una de las características clave de las SCPs es que solo afectan a los principals pertenecientes a la organización y no tienen efecto sobre los principals fuera de la organización.

Exploramos esto con más detalle mediante un ejemplo.

Un usuario de una cuenta de AWS dentro de la organización tiene asociada una política con permisos completos de administrador. Sin embargo, la cuenta de AWS también tiene aplicada una SCP, con este aspecto:

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

Si este usuario intenta acceder al bucket, recibirá un error de “Access Denied” como este:

% aws s3 ls terraform-20250330204504838800000001
An error occurred (AccessDenied) when calling the ListObjectsV2 operation: User: arn:aws:sts::440473545235:assumed-role/AWSReservedSSO_AdministratorAccess_06f46be2876578b6/user is not authorized to perform: s3:ListBucket on resource: "arn:aws:s3:::terraform-20250330204504838800000001" with an explicit deny in a service control policy

En este caso, la SCP afecta al principal que pertenece a la cuenta donde se ha adjuntado la SCP.

Sin embargo, si el principal pertenece a otra cuenta de AWS que no está afectada por esta SCP (o incluso una cuenta externa fuera de la organización de AWS), no se verá afectado por esta restricción.

Suponiendo que el bucket de S3 tiene una bucket policy que otorga acceso a este principal externo:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::964937560139:root"
            },
            "Action": "s3:*",
            "Resource": [
                "arn:aws:s3:::terraform-20250330204504838800000001/*",
                "arn:aws:s3:::terraform-20250330204504838800000001"
            ]
        }
    ]
}

Si intentamos la misma operación que antes, podemos ver que el usuario no está afectado por la SCP y puede recuperar el contenido del bucket.

% aws s3 ls terraform-20250330204504838800000001
2025-03-30 22:48:25      36844 scp-ec2.webp

Como podemos ver, las SCPs no son suficientes para hacer cumplir de manera centralizada los controles de acceso en este tipo de situaciones. Afortunadamente, para estos casos, podemos utilizar otro tipo de control gestionado centralmente: Resource Control Policies (RCPs).

RCPs

#

Resource Control Policies (RCPs) definen quién puede acceder a recursos específicos de AWS y bajo qué condiciones. A diferencia de las SCPs, que se aplican a nivel de principal, las RCPs hacen cumplir las políticas de seguridad directamente en los servicios y recursos de AWS.

Usando el ejemplo anterior como punto de partida, veamos cómo podríamos restringir el acceso a S3 de manera centralizada, incluso aunque el bucket tenga una política permisiva.

En este caso, en lugar de aplicar una SCP, aplicamos una RCP a la Cuenta del Bucket, que deniega todas las operaciones de S3.

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

Con esta política aplicada, repetimos nuestra operación. Primero, intentamos con el usuario dentro de la cuenta de la organización:

aws s3 ls terraform-20250330204504838800000001

An error occurred (AccessDenied) when calling the ListObjectsV2 operation: User: arn:aws:sts::442042545235:assumed-role/AWSReservedSSO_AdministratorAccess_06f46be2876578b6/user is not authorized to perform: s3:ListBucket on resource: "arn:aws:s3:::terraform-20250330204504838800000001" with an explicit deny in a resource control policy

Como podemos ver, el resultado es el esperado error de Access Denied.

Ahora, intentamos la misma operación con nuestro usuario externo:

% aws s3 ls terraform-20250330204504838800000001

An error occurred (AccessDenied) when calling the ListObjectsV2 operation: Access Denied

Esta vez, con la RCP aplicada, el usuario ya no tiene acceso al bucket, a pesar de que la Bucket Policy otorga permiso.

Cabe destacar que, al acceder al bucket con usuarios externos, el mensaje de error es menos detallado en comparación con cuando el acceso se intenta con un usuario de la cuenta.

Hasta ahora, hemos visto cómo hacer cumplir de manera centralizada los controles de acceso a diferentes servicios de AWS, pero ninguno de estos controles ha alterado o condicionado la configuración de los servicios en sí. Además, hemos visto que el mensaje de error devuelto cuando el acceso es denegado no ofrece al usuario ninguna información sobre por qué ocurrió esto.

Veamos cómo podemos abordar estos problemas con el uso de un tercer tipo de control gestionado centralmente: Declarative Policies.

Declarative Policies

#

Las Declarative Policies permiten a las organizaciones definir las configuraciones deseadas para los servicios de AWS a gran escala. Estas políticas hacen cumplir las mejores prácticas sin necesidad de intervención manual, asegurando el cumplimiento con los estándares de seguridad y operación.

Las Declarative Policies se aplican en el plano de control del servicio. Así que, en lugar de determinar quién puede acceder o no acceder al servicio, persisten como un límite para algunas características del servicio. Veremos esto con más detalle más adelante con un ejemplo.

Este tipo de política, al igual que las SCPs y las RCPs, puede aplicarse a diferentes niveles de la organización: Root, OU o cuenta.

En el momento de escribir este artículo, las Declarative Policies solo son compatibles con el servicio EC2. Los atributos disponibles son los siguientes:

Mensajes de error personalizados

#

Otra diferencia clave con otros tipos de políticas es la posibilidad de definir mensajes de error personalizados para los usuarios. Esto podría ser útil para proporcionar URLs que apunten a la documentación, instruyendo al usuario sobre cómo configurar correctamente el servicio.

Declarative Policies y Service-Linked Roles

#

Otra limitación de las SCPs y las RCPs es que no affectan a ningún Service-Linked Role. Estos son los roles que están asociados directamente con algunos servicios de AWS y son completamente gestionados por AWS.

Con las Declarative Policies, los Service-Linked Roles también están sujetos a las políticas aplicadas al servicio, proporcionando una capa adicional de seguridad.

Ejemplo de Declarative Policies

#

Una vez que hemos definido qué son las Declarative Policies y sus características clave, veamos todo esto en acción con un ejemplo.

Hemos atachado la siguiente Declarative Policy a nuestra cuenta de AWS:

{
  "ec2_attributes": {
    "vpc_block_public_access": {
      "internet_gateway_block": {
        "mode": {
          "@@assign": "block_ingress"
        },
        "exclusions_allowed": {
          "@@assign": "disabled"
        }
      }
    },
    "exception_message": {
      "@@assign": "This is an example of a custom error message."
    }
  }
}

Con esta política, todo el tráfico entrante a través del Internet Gateway será bloqueado. Como resultado, la instancia EC2 en la subred pública no será accesible, incluso si tiene una ENI con una IP pública, un Security Group permisivo y un NACL abierto.

Si intentamos llegar al Nginx desplegado en esta instancia, veremos que la instancia no responde, y después de un tiempo, recibiremos el siguiente error.

% curl -I http://108.129.156.193
curl: (55) Send failure: Broken pipe

Si desactivamos temporalmente la Declarative Policy de la cuenta y repetimos la misma operación, observamos que se puede acceder a Nginx sin problema.

sergio@K243 ~ % curl -I http://108.129.156.193
HTTP/1.1 200 OK
Server: nginx/1.26.3
Date: Thu, 03 Apr 2025 16:46:19 GMT
Content-Type: text/html
Content-Length: 615
Last-Modified: Tue, 11 Feb 2025 02:00:47 GMT
Connection: keep-alive
ETag: "67aaaf4f-267"
Accept-Ranges: bytes

Por otro lado, dado que esta política solo bloquea el tráfico de entrada, la instancia EC2 en la subred privada aún podrá acceder a internet a través del NAT Gateway en la subred pública.

Desde nuestra instancia EC2 privada, realizamos una solicitud a cambelo.com y vemos que podemos acceder a ella sin problemas.

sh-5.2$ curl -I https://cambelo.com
HTTP/2 200
accept-ranges: bytes
alt-svc: h3=":443"; ma=2592000
cache-control: public, max-age=0, must-revalidate
content-type: text/html; charset=utf-8
etag: "d8q1r0f8k5cazq1"
last-modified: Wed, 26 Mar 2025 08:15:14 GMT
server: Caddy
vary: Accept-Encoding
x-content-type-options: nosniff
content-length: 46297
date: Thu, 03 Apr 2025 16:34:52 GMT

Conclusión

#

En este artículo, hemos visto tres tipos de políticas diferentes que podemos usar para hacer cumplir controles de gobernanza de manera centralizada en toda nuestra organización.

Las SCPs controlan qué permisos tienen los principals para acceder a recursos, las RCPs definen los permisos que puede tener un recurso determinado, y las Declarative Policies imponen límites directamente en el plano de control del servicio.

Aquí tienes una tabla resumen para comparar las características clave de cada tipo de política:

¿Te ha gustado este artículo? ¡Suscríbete al boletín y sé el primero en saber cuándo se publica uno nuevo!

Referencias

#

• Managing organization policies with AWS Organizations
• Service control policies (SCPs)
• Resource control policies (RCPs)
• Declarative policies
• Declarative policy syntax and examples