CIS Benchmarks para AWS y GCP: Guía de Implementación

Tu factura de AWS dice que tienes 200 recursos. Tu herramienta CSPM dice que 47 de ellos no cumplen CIS Benchmarks. Tu CTO pregunta: "¿cuáles importan?" Y ahí es donde la mayoría de equipos se bloquean. Porque una cosa es saber que tienes hallazgos y otra muy distinta es saber cuáles son ruido y cuáles representan un riesgo real para el negocio.

CIS Benchmarks te dan la respuesta. Son la referencia de facto de la industria para configuración segura en entornos cloud. No son opiniones de un consultor ni reglas inventadas por un fabricante de herramientas. Son guías de configuración desarrolladas por consenso entre profesionales de seguridad, proveedores cloud y organismos reguladores. Cuando un auditor de ISO 27001 pregunta "¿cómo verificáis la configuración segura de vuestros recursos cloud?", CIS Benchmarks es la respuesta que espera escuchar.

El problema es que un CIS Benchmark de AWS tiene más de 300 controles. El de GCP supera los 150. Si intentas cumplirlos todos a la vez sin una estrategia de priorización, vas a paralizar a tu equipo de infraestructura durante semanas sin resultados tangibles. Esta guía te da el orden correcto: qué controles importan más, por qué, y cómo implementarlos sin que el negocio se detenga.

---

Qué son los CIS Benchmarks

CIS (Center for Internet Security) es una organización sin ánimo de lucro que publica guías de configuración segura para prácticamente cualquier tecnología. Sus Benchmarks cubren AWS, GCP, Azure, Kubernetes, Docker, Linux, Windows Server, bases de datos, navegadores y decenas de sistemas más. No son un estándar regulatorio como ISO 27001 o NIS2, sino una referencia técnica que detalla exactamente cómo debe estar configurado cada recurso para minimizar la superficie de ataque.

Los Benchmarks se desarrollan mediante un proceso de consenso. Participan ingenieros de seguridad de empresas como Google, Amazon, Microsoft, CrowdStrike y organizaciones gubernamentales. Cada control se discute, se prueba y se valida antes de publicarse. Esto les da una credibilidad que las guías internas de la mayoría de empresas no tienen.

Cada Benchmark define dos niveles de controles:

Level 1 son los controles esenciales. Tienen bajo impacto en la funcionalidad del sistema y se consideran el mínimo que cualquier organización debería cumplir. Activar MFA para todos los usuarios IAM con acceso a consola, habilitar el cifrado en reposo en S3, cerrar puertos de gestión abiertos al mundo. Son cambios que raramente rompen nada y que eliminan los vectores de ataque más comunes.

Level 2 son controles de defensa en profundidad. Proporcionan mayor seguridad pero pueden afectar a la funcionalidad o requerir cambios más significativos en la operación. Por ejemplo, exigir claves de cifrado gestionadas por el cliente (CMK) en lugar de claves gestionadas por AWS, o habilitar VPC Flow Logs para todo el tráfico. Son importantes, pero implementarlos requiere planificación.

Los Benchmarks son gratuitos. Puedes descargarlos en PDF desde cisecurity.org sin coste. Lo que no es gratuito es el tiempo que lleva leerlos, entenderlos, priorizarlos e implementarlos. Ahí es donde una guía CSPM marca la diferencia: te explica la herramienta que automatiza la evaluación contra CIS y te dice exactamente qué falla y cómo arreglarlo.

---

Los controles CIS más críticos para AWS

Después de auditar entornos AWS de startups, PYMEs y empresas en crecimiento, estos son los fallos que aparecen una y otra vez. No son edge cases teóricos: son configuraciones que están mal en la mayoría de cuentas que revisamos.

IAM: la identidad es el perímetro

Cuenta root sin MFA. La cuenta root de AWS tiene permisos absolutos sobre todo. No se puede limitar con políticas IAM convencionales. En la cuenta de gestión de AWS Organizations, tampoco se puede restringir con SCPs (Service Control Policies) — en cuentas miembro los SCPs sí aplican al root, pero la cuenta de gestión queda fuera. Si alguien compromete la cuenta root, tiene acceso total: puede borrar todos los recursos, cambiar la facturación, cerrar la cuenta. Y en muchas organizaciones, esta cuenta no tiene MFA activado. Peor aún, algunas tienen access keys activas en la cuenta root, lo que significa que una filtración de credenciales en un repositorio da acceso ilimitado.

Usuarios IAM sin MFA. No solo la cuenta root. Cada usuario IAM con acceso a la consola de AWS necesita MFA. Sin MFA, un atacante que obtenga las credenciales (phishing, credential stuffing, filtración en otro servicio) puede acceder directamente. El CIS Benchmark es claro: MFA debe estar habilitado para todos los usuarios con acceso a consola, sin excepciones.

Políticas con permisos excesivos. El patrón "Effect": "Allow", "Action": "*", "Resource": "*" aparece en más cuentas de las que debería. A veces en políticas inline de usuarios, a veces en roles que se crearon "temporalmente" hace dos años. El principio de mínimo privilegio no es una recomendación: es el control más efectivo que existe contra la escalada de privilegios. IAM Access Analyzer te muestra qué permisos se usan realmente y cuáles puedes eliminar.

Access keys antiguas sin rotar. CIS recomienda rotar las access keys cada 90 días. En la práctica, encontramos keys que llevan activas más de un año. Una access key antigua es un vector de ataque silencioso: si se filtró en algún momento (un commit accidental, un log mal configurado, un backup sin cifrar), el atacante puede estar usándola sin que nadie lo sepa.

S3: datos expuestos por configuración

Buckets con acceso público. El benchmark verifica que no existan buckets con ACLs públicas ni bucket policies que permitan acceso a Principal: "*". Cada mes salen noticias de filtraciones masivas de datos por buckets S3 públicos. AWS ha ido añadiendo protecciones (S3 Block Public Access a nivel de cuenta), pero muchas cuentas creadas antes de estas protecciones no las tienen activadas retroactivamente.

Sin cifrado por defecto. Desde 2023 AWS cifra todos los objetos nuevos en S3 con SSE-S3 por defecto. Desde enero de 2023, AWS cifra todos los objetos — incluidos los que ya existían — con SSE-S3 por defecto. El problema ya no es que haya objetos sin cifrar, sino que en entornos regulados el cifrado con claves gestionadas por AWS puede no ser suficiente: necesitas SSE-KMS con claves gestionadas por el cliente (CMK) para controlar la rotación y el acceso, especialmente para cumplir requisitos de ISO 27001 o PCI-DSS.

Sin versionado en buckets críticos. El versionado en S3 protege contra borrados accidentales y contra ransomware. Si un atacante compromete credenciales y borra datos de un bucket sin versionado, esos datos se pierden para siempre. Activar el versionado no tiene coste adicional (solo el almacenamiento de las versiones anteriores) y es un control básico de resiliencia.

CloudTrail: sin logs no hay detección

No habilitado en todas las regiones. CloudTrail registra las llamadas API en tu cuenta de AWS. Si solo está habilitado en eu-west-1 pero un atacante crea recursos en us-east-1, no tendrás registro de esa actividad. CIS exige un trail multi-región que capture eventos en todas las regiones, incluidas las que no usas.

Sin validación de integridad de logs. CloudTrail puede firmar cada archivo de log para que puedas verificar que no ha sido manipulado. Sin esta validación, un atacante con acceso suficiente podría modificar o borrar los logs para cubrir sus huellas. Activar la validación de integridad es un checkbox en la configuración del trail.

Logs sin cifrado. Los logs de CloudTrail contienen información sensible: qué usuarios hacen qué operaciones, desde qué IPs, con qué credenciales. Si los logs se almacenan en S3 sin cifrado KMS, cualquiera con acceso al bucket puede leerlos. Y esos logs son exactamente lo que un atacante querría para planificar su siguiente movimiento.

Security Groups: la puerta abierta más común

SSH y RDP abiertos a 0.0.0.0/0. Si un Security Group permite tráfico entrante en el puerto 22 (SSH) o 3389 (RDP) desde cualquier IP de internet, cualquier bot de escaneo del mundo puede intentar acceder. No es una cuestión de "si" alguien lo intentará, sino de cuántas veces por minuto. Los escaneos de puertos de gestión abiertos son continuos y automatizados.

Reglas de egreso demasiado permisivas. El Security Group por defecto permite todo el tráfico saliente. Esto significa que si un atacante compromete una instancia, puede exfiltrar datos sin restricción. Limitar el egreso a los puertos y destinos necesarios es un control que muchos equipos ignoran por comodidad, pero que reduce drásticamente el impacto de una brecha.

RDS: bases de datos expuestas

Acceso público habilitado. Crear una instancia RDS con Publicly Accessible: true la expone a internet. Combinado con credenciales débiles o una vulnerabilidad en el motor de base de datos, es un camino directo a una filtración de datos. Las bases de datos deben estar en subnets privadas, accesibles solo desde las instancias de aplicación.

Sin cifrado en reposo. Una instancia RDS sin cifrado at-rest significa que los datos están en claro en el almacenamiento subyacente. Si alguien obtiene acceso a los snapshots o a los volúmenes EBS, puede leer toda la información. Activar el cifrado es sencillo al crear la instancia, pero no se puede activar retroactivamente sobre una instancia existente: hay que migrar los datos a una nueva instancia cifrada.

Sin backups automáticos. CIS recomienda que todas las instancias RDS tengan retención de backups automáticos configurada. Sin backups, un incidente de ransomware o un borrado accidental puede significar una pérdida total de datos. La retención mínima recomendada es de 7 días.

---

Los controles CIS más críticos para GCP

GCP tiene su propio CIS Benchmark con controles específicos para sus servicios. Aunque los principios son los mismos que en AWS (identidad, datos, red, logging), la implementación difiere significativamente.

IAM: service accounts y permisos

Service accounts con rol de Owner. En GCP, el rol de Owner otorga control total sobre un proyecto: puede crear, modificar y borrar cualquier recurso, cambiar permisos IAM y acceder a todos los datos. Cuando un service account tiene este rol, y su clave JSON se filtra (algo que ocurre con frecuencia en repositorios de código), el atacante tiene acceso absoluto. CIS exige que ningún service account tenga roles primitivos (Owner, Editor). Deben tener roles predefinidos o personalizados con los permisos mínimos necesarios.

Claves de service accounts sin rotar. Las claves de service accounts gestionadas por el usuario no tienen fecha de expiración por defecto. Una clave creada hace dos años sigue siendo válida. CIS recomienda rotar estas claves cada 90 días. En la práctica, la mejor solución es evitar las claves gestionadas por el usuario siempre que sea posible y usar Workload Identity Federation para autenticación sin claves estáticas.

Sin restricciones de Organization Policy. GCP ofrece Organization Policy Constraints que permiten definir reglas a nivel de organización: impedir la creación de recursos en regiones no autorizadas, bloquear la creación de service accounts con claves externas, o prohibir la asignación de IPs públicas. Sin estas restricciones, cada proyecto es un reino independiente donde cualquier desarrollador con permisos suficientes puede crear configuraciones inseguras.

Default service account usado en instancias. Cuando creas una instancia en Compute Engine sin especificar un service account, GCP asigna el default service account del proyecto, que normalmente tiene el rol de Editor. Esto significa que cualquier código que se ejecute en esa instancia hereda permisos amplios sobre todo el proyecto. CIS exige crear service accounts dedicados con permisos mínimos para cada workload.

Cloud Storage: acceso y cifrado

Acceso uniforme a nivel de bucket no aplicado. GCP permite dos modos de control de acceso para buckets: ACLs por objeto y acceso uniforme a nivel de bucket. Las ACLs por objeto son más difíciles de auditar y más propensas a errores. CIS recomienda activar el acceso uniforme a nivel de bucket, que desactiva las ACLs y centraliza todo el control de acceso en políticas IAM.

Prevención de acceso público deshabilitada. Similar al S3 Block Public Access de AWS, GCP tiene un ajuste de prevención de acceso público a nivel de organización y proyecto. Si no está activado, cualquier persona con permisos suficientes puede hacer un bucket accesible desde internet, intencionada o accidentalmente. CIS exige que esta protección esté habilitada a nivel de organización.

Sin cifrado con claves gestionadas por el cliente (CMEK). GCP cifra todos los datos en reposo por defecto con claves de Google. Pero para cumplir requisitos regulatorios estrictos, necesitas Cloud KMS con claves gestionadas por tu organización. Esto te da control sobre la rotación, revocación y acceso a las claves, algo que con claves de Google no tienes.

Compute Engine: superficie de ataque

Puerto serie habilitado. El puerto serie de una instancia de Compute Engine permite acceso a la consola del sistema operativo. Si está habilitado, un atacante con credenciales IAM suficientes puede acceder a la instancia sin necesidad de SSH. CIS recomienda deshabilitarlo en todas las instancias que no lo necesiten explícitamente.

IPs públicas en instancias que no las necesitan. Cada IP pública es un punto de entrada potencial. Si una instancia solo necesita comunicarse con otros servicios dentro del mismo VPC, no necesita IP pública. Usa Cloud NAT para tráfico saliente y balanceadores de carga para tráfico entrante. CIS Benchmark verifica que las instancias no tengan IPs públicas innecesarias.

Disco de arranque sin cifrado CMEK. Al igual que con Cloud Storage, los discos de Compute Engine están cifrados por defecto con claves de Google. Para entornos regulados, CIS Level 2 recomienda cifrado con CMEK, que te permite controlar el ciclo de vida de las claves y cumplir requisitos de auditoría más estrictos.

Cloud SQL: bases de datos en GCP

IP pública habilitada. Una instancia de Cloud SQL con IP pública es accesible desde internet si las redes autorizadas lo permiten. La práctica correcta es usar solo IPs privadas y conectar mediante Cloud SQL Proxy o Private Service Connect. CIS exige que las instancias de Cloud SQL no tengan IPs públicas.

Sin aplicación de SSL. Cloud SQL permite conexiones sin cifrar si no se configura explícitamente la obligatoriedad de SSL. Esto significa que las credenciales de base de datos y los datos en tránsito viajan en claro. CIS requiere que require_ssl esté activado en todas las instancias.

Sin backups automáticos. Lo mismo que en RDS: sin backups automáticos, un incidente puede causar pérdida total de datos. Cloud SQL permite configurar backups diarios con retención configurable. No activarlos es un riesgo innecesario.

Logging: visibilidad sobre lo que ocurre

Audit logging no habilitado para todos los servicios. GCP tiene Cloud Audit Logs que registran quién hizo qué, dónde y cuándo. Pero los Data Access Logs (lecturas y escrituras de datos) están deshabilitados por defecto para la mayoría de servicios. Sin estos logs, no puedes saber quién accedió a qué datos. CIS requiere que los Admin Activity Logs y los Data Access Logs estén habilitados para todos los servicios relevantes.

Log sinks no configurados. Los logs en GCP se almacenan en Cloud Logging con una retención por defecto de 30 días para la mayoría de tipos de log. Para cumplir requisitos de auditoría y poder investigar incidentes que se descubren semanas después, necesitas configurar log sinks que exporten los logs a Cloud Storage o BigQuery con retención extendida. CIS recomienda que todos los logs de auditoría se exporten a un destino con retención adecuada.

Sin alertas sobre cambios críticos. Tener logs no sirve de nada si nadie los revisa. CIS requiere métricas de logs y alertas para cambios críticos: modificaciones en políticas IAM, cambios en configuración de red, desactivación de logging, creación de claves de service accounts. Sin estas alertas, un atacante puede operar durante días o semanas sin que nadie lo detecte.

---

CIS Benchmarks y compliance

CIS Benchmarks no son un marco regulatorio. No te "certificas" en CIS como te certificas en ISO 27001. Pero son la base técnica que los marcos regulatorios necesitan. Cuando un auditor evalúa tus controles técnicos, CIS es el lenguaje común.

Relación con ISO 27001

ISO 27001:2022 define controles tecnológicos en su Anexo A que se mapean directamente a controles CIS:

• A.8.8 (Gestión de vulnerabilidades técnicas): CIS Benchmarks son la herramienta para verificar que las configuraciones cloud no tienen vulnerabilidades conocidas. Pasar un escaneo CIS es evidencia directa de cumplimiento de este control.
• A.8.9 (Gestión de la configuración): CIS define exactamente cuál es la configuración segura de referencia para cada servicio cloud. Usarlos como baseline cumple el requisito de tener configuraciones controladas y documentadas.
• A.5.23 (Seguridad de la información en el uso de servicios cloud): CIS Benchmarks específicos para AWS y GCP cubren los controles de seguridad que debes implementar al usar infraestructura cloud.

Si estás preparando la certificación ISO 27001 y tu infraestructura está en la nube, cumplir CIS Level 1 te resuelve una parte significativa de los controles técnicos del Anexo A.

Relación con NIS2

La Directiva NIS2 exige que las entidades esenciales e importantes implementen "medidas técnicas y organizativas apropiadas y proporcionadas". No especifica exactamente qué medidas, pero CIS Benchmarks son una referencia reconocida para demostrar que tus medidas técnicas son apropiadas. Un entorno cloud que cumple CIS Level 1 tiene una postura de seguridad significativamente superior a la media, y eso es exactamente lo que NIS2 busca.

Relación con PCI-DSS

PCI-DSS v4.0 exige estándares de configuración de sistemas (requisito 2) y controles de seguridad de red (requisito 1). CIS Benchmarks para cloud son la referencia más utilizada por la industria para demostrar que tus configuraciones cumplen con estos requisitos. Los QSA (Qualified Security Assessors) aceptan reportes CIS como evidencia de configuración segura.

Lo que CIS no cubre

Cumplir CIS Level 1 no significa que estés seguro ni que cumplas automáticamente ningún marco regulatorio. CIS cubre configuración de infraestructura, pero no cubre la seguridad de tu aplicación, la formación de tus empleados, la gestión de incidentes, las políticas de acceso físico ni la continuidad de negocio. Es una pieza fundamental del puzzle, pero no es el puzzle completo.

---

Implementación práctica: por dónde empezar

Si nunca has evaluado tu entorno cloud contra CIS Benchmarks, la cantidad de controles puede resultar abrumadora. Aquí tienes una estrategia de priorización que funciona.

Paso 1: empieza por Level 1

Los controles Level 1 son el punto de partida correcto. Son los que tienen mayor impacto en seguridad con menor impacto en operaciones. No tocan la funcionalidad de tus aplicaciones y eliminan los vectores de ataque más comunes. Si solo puedes hacer una cosa, haz Level 1 completo antes de plantearte Level 2.

Paso 2: prioriza IAM

En la nube, la identidad es el perímetro. No hay un firewall perimetral que proteja tu infraestructura: el acceso se controla con credenciales y políticas IAM. Si un atacante obtiene credenciales con permisos excesivos, tiene acceso a todo. Por eso IAM debe ser tu primera prioridad:

• Activa MFA para todos los usuarios (consola y CLI)
• Elimina access keys de la cuenta root
• Revisa y reduce permisos excesivos
• Rota las access keys que lleven más de 90 días
• Elimina usuarios y roles que ya no se usan

Paso 3: protección de datos

Una vez que la identidad está controlada, asegura los datos:

• Activa el cifrado en reposo en todos los servicios de almacenamiento (S3, RDS, EBS, Cloud Storage, Cloud SQL)
• Habilita S3 Block Public Access y la prevención de acceso público en GCP a nivel de cuenta u organización
• Activa el versionado en buckets que contengan datos críticos
• Configura backups automáticos en todas las bases de datos

Paso 4: seguridad de red

Con la identidad y los datos protegidos, reduce la superficie de red:

• Cierra todos los Security Groups y reglas de firewall con puertos de gestión abiertos a 0.0.0.0/0
• Limita el tráfico de egreso a lo estrictamente necesario
• Elimina IPs públicas de instancias que no las necesiten
• Asegura que las bases de datos no sean accesibles desde internet

Paso 5: logging y detección

No puedes detectar lo que no registras. El logging es el último paso porque los anteriores reducen la probabilidad de incidente, y este te permite detectar y responder cuando algo pasa:

• Habilita CloudTrail en todas las regiones con validación de integridad
• Activa Cloud Audit Logs (Data Access) en todos los servicios de GCP
• Configura log sinks con retención extendida
• Crea alertas para cambios críticos en IAM, red y configuración de logging

Automatiza con CSPM en lugar de checklists manuales

Evaluar 300 controles CIS de forma manual no es viable. Ni siquiera es viable hacerlo una vez al trimestre. Las configuraciones cambian cada día: cada despliegue, cada nuevo recurso, cada cambio de permisos puede introducir un nuevo fallo. Necesitas una herramienta CSPM que evalúe continuamente y te avise cuando algo se desvía de la baseline.

---

Cómo Vulnerabbit implementa CIS Benchmarks

El módulo CSPM de Vulnerabbit audita tu infraestructura de AWS y GCP contra los CIS Benchmarks de forma continua. La conexión es de solo lectura: no toca ni modifica nada en tu entorno. En 5 minutos puedes conectar tus cuentas cloud y tener una visión completa de tu postura de seguridad.

Lo que diferencia a Vulnerabbit de descargar el PDF de CIS y revisar los controles manualmente:

• Evaluación continua, no puntual. Cada cambio en tu infraestructura se evalúa contra los controles CIS. No esperas a la siguiente auditoría trimestral para descubrir que alguien abrió un Security Group.
• Priorización por riesgo real. No todos los fallos CIS tienen el mismo impacto. Vulnerabbit prioriza los hallazgos según el contexto de tu entorno: un bucket S3 público con datos de producción no es lo mismo que uno con assets estáticos.
• Guías de remediación específicas. Para cada hallazgo, te damos los pasos exactos para corregirlo: comandos de CLI, cambios en Terraform, configuraciones en la consola. No te decimos solo que algo está mal; te decimos cómo arreglarlo.
• Mapeo a frameworks regulatorios. Cada control CIS se mapea a los controles de ISO 27001, NIS2 y PCI-DSS que cubre. Así puedes usar el mismo reporte para seguridad y para compliance.

Si tu equipo gestiona infraestructura en AWS o GCP y necesita cumplir CIS Benchmarks de forma continua, puedes empezar desde 49 €/mes. Sin agentes, sin cambios en tu infraestructura, sin acceso de escritura.

---

Los CIS Benchmarks son el punto de partida más sólido para la seguridad de tu infraestructura cloud. No necesitas cumplirlos todos el primer día. Necesitas un plan, visibilidad y un sistema que te avise cuando algo cambie. Puedes empezar evaluando tu perímetro externo con nuestro escáner gratuito.