CSPM en AWS: Configuración Segura con CIS

Conectaste tu cuenta de AWS a una herramienta CSPM y el dashboard te devolvió 150 hallazgos. Security Groups abiertos, usuarios sin MFA, buckets sin cifrar, CloudTrail parcialmente configurado. La lista es larga y todo parece urgente.

No lo es. De esos 150 hallazgos, probablemente 30 son realmente críticos, 50 son importantes y el resto son mejoras incrementales que pueden esperar. El problema es saber cuáles son cuáles.

Para eso existen los CIS Benchmarks. Y en esta guía te vamos a dar los 15 controles que, basándonos en lo que vemos en auditorías reales de cuentas AWS, cubren la inmensa mayoría del riesgo. Con el comando AWS CLI para verificar cada uno y las instrucciones para arreglarlo.

---

Que son los CIS Benchmarks para AWS

CIS (Center for Internet Security) es una organización sin animo de lucro que publica guias de hardening para practicamente cualquier tecnologia: sistemas operativos, bases de datos, plataformas cloud. Su benchmark para AWS (actualmente en la version 3.0) contiene mas de 60 recomendaciones de configuracion segura organizadas por servicio.

Lo relevante es que estos benchmarks no son teoria. Son el estandar de facto que utilizan auditores, reguladores y herramientas de seguridad para evaluar la postura de seguridad de una cuenta AWS. Si tu empresa necesita cumplir con ISO 27001, NIS2 o ENS, los controles CIS mapean directamente a esos frameworks.

Pero no todos los controles tienen el mismo peso. De las 60+ recomendaciones, hay 15 que aparecen violados de forma consistente en la mayoria de cuentas AWS que analizamos. Son los que generan el 80% del riesgo real. Vamos a ellos.

---

Los 15 controles CIS mas criticos para AWS

IAM (Identity and Access Management)

IAM es donde empieza y donde termina la seguridad en AWS. Una mala configuracion de identidades y permisos invalida cualquier otro control que tengas implementado.

1. Cuenta root sin MFA (CIS 1.5)

La cuenta root de AWS tiene acceso ilimitado a todos los recursos y servicios. No se puede restringir con policies ni con SCPs de Organizations. Si un atacante obtiene las credenciales de root, tiene control total: puede borrar backups, desactivar CloudTrail, crear usuarios nuevos y exfiltrar datos sin restriccion.

Sin MFA, lo unico que separa a un atacante de tu cuenta completa es una contrasena.

Como verificar:

aws iam get-account-summary --query 'SummaryMap.AccountMFAEnabled'

Si devuelve 0, la cuenta root no tiene MFA activado.

Como arreglar: Accede a la consola de AWS como root, ve a IAM > Security credentials y activa MFA. Usa una llave de seguridad fisica (YubiKey) o, como minimo, una app TOTP como Google Authenticator. Nunca uses MFA por SMS para la cuenta root.

---

2. Usuarios IAM sin MFA habilitado (CIS 1.10)

Cada usuario IAM con acceso a la consola y sin MFA es un vector de ataque. Basta con que reutilice una contrasena filtrada en otro servicio para que un atacante entre directamente.

Como verificar:

aws iam generate-credential-report
aws iam get-credential-report --query 'Content' --output text | base64 -d | cut -d',' -f1,4,8

Esto te da un CSV con cada usuario, si tiene MFA habilitado y si tiene contrasena activa. Cualquier usuario con contrasena activa y sin MFA es un hallazgo critico.

Como arreglar: Implementa una IAM policy que exija MFA para todas las operaciones excepto la configuracion del propio MFA. Documenta el procedimiento y establece un plazo de 48 horas para que todos los usuarios activen MFA. Los que no lo hagan, desactiva su acceso a la consola.

---

3. Access keys con mas de 90 dias (CIS 1.14)

Las access keys son credenciales programaticas que no caducan por defecto. Con el tiempo, se copian en repositorios, se comparten en mensajes, se almacenan en texto plano en servidores. Cuanto mas tiempo llevan activas, mayor es la probabilidad de que esten comprometidas.

Como verificar:

aws iam get-credential-report --query 'Content' --output text | base64 -d | cut -d',' -f1,9,11,14,16

Las columnas relevantes son access_key_1_last_rotated y access_key_2_last_rotated. Cualquier key con mas de 90 dias necesita rotacion.

Como arreglar: Para cada key antigua, crea una nueva key, actualiza todas las aplicaciones que la usan, verifica que funcionan, y desactiva la key antigua. No la borres inmediatamente: desactivala primero y espera 7 dias para confirmar que nada se rompe. Despues eliminala.

---

4. IAM policies asignadas directamente a usuarios (CIS 1.15)

Asignar policies directamente a usuarios en lugar de a grupos o roles hace imposible gestionar permisos a escala. Con 5 usuarios es manejable. Con 50, es un caos donde nadie sabe quien tiene acceso a que. Y cuando alguien deja la empresa, no puedes estar seguro de haber revocado todos sus permisos.

Como verificar:

aws iam list-users --query 'Users[*].UserName' --output text | tr '\t' '\n' | while read user; do
  policies=$(aws iam list-attached-user-policies --user-name "$user" --query 'AttachedPolicies' --output text)
  inline=$(aws iam list-user-policies --user-name "$user" --query 'PolicyNames' --output text)
  if [ -n "$policies" ] || [ -n "$inline" ]; then
    echo "HALLAZGO: $user tiene policies directas"
  fi
done

Como arreglar: Crea grupos IAM por funcion (developers, devops, readonly). Asigna las policies a los grupos. Anade los usuarios a los grupos correspondientes. Elimina las policies directas. Para servicios y aplicaciones, usa roles IAM con AssumeRole en vez de access keys de usuarios.

---

Logging y Monitoring

Sin logs, no tienes visibilidad. Sin visibilidad, no puedes detectar, investigar ni responder a incidentes. Asi de simple.

5. CloudTrail no habilitado en todas las regiones (CIS 3.1)

CloudTrail registra las llamadas API que se hacen en tu cuenta de AWS. Si solo tienes un trail en us-east-1, un atacante puede operar libremente desde eu-west-1, ap-southeast-1 o cualquier otra region sin dejar rastro. Y AWS tiene mas de 30 regiones activas.

Como verificar:

aws cloudtrail describe-trails --query 'trailList[*].{Name:Name,IsMultiRegion:IsMultiRegionTrail,IsLogging:HomeRegion}'

Si ningun trail tiene IsMultiRegionTrail: true, tienes un punto ciego enorme.

Como arreglar:

aws cloudtrail update-trail --name tu-trail --is-multi-region-trail

Un solo trail multi-region es suficiente. No necesitas un trail por region.

---

6. Validacion de log files de CloudTrail no habilitada (CIS 3.2)

Sin validacion de integridad, un atacante que comprometa tu cuenta puede modificar o borrar los logs de CloudTrail para cubrir sus huellas. Con la validacion habilitada, AWS genera un hash de cada archivo de log. Si alguien lo modifica, el hash no coincide y lo detectas.

Como verificar:

aws cloudtrail describe-trails --query 'trailList[*].{Name:Name,LogFileValidation:LogFileValidationEnabled}'

Si LogFileValidationEnabled es false, activa la validacion.

Como arreglar:

aws cloudtrail update-trail --name tu-trail --enable-log-file-validation

---

7. Bucket S3 de CloudTrail con acceso publico (CIS 3.3)

El bucket donde CloudTrail almacena los logs contiene un registro detallado de toda la actividad en tu cuenta: que usuarios hicieron que llamadas API, desde que IPs, a que horas. Si ese bucket es publico, un atacante puede descargar tu historial completo de actividad y usar esa informacion para planificar un ataque mas sofisticado.

Como verificar:

# Primero obtener el nombre del bucket de CloudTrail
BUCKET=$(aws cloudtrail describe-trails --query 'trailList[0].S3BucketName' --output text)

# Verificar Block Public Access
aws s3api get-public-access-block --bucket $BUCKET

# Verificar la ACL del bucket
aws s3api get-bucket-acl --bucket $BUCKET

Si BlockPublicAcls, IgnorePublicAcls, BlockPublicPolicy y RestrictPublicBuckets no estan todos en true, tienes un problema.

Como arreglar:

aws s3api put-public-access-block --bucket $BUCKET --public-access-block-configuration BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true

---

8. VPC Flow Logs no habilitados (CIS 3.9)

VPC Flow Logs registran el trafico de red que entra y sale de tus VPCs. Sin ellos, no tienes visibilidad sobre quien se esta conectando a tus recursos, que puertos estan recibiendo trafico y si hay comunicaciones sospechosas. Son esenciales para investigar incidentes de seguridad.

Como verificar:

# Listar todas las VPCs
aws ec2 describe-vpcs --query 'Vpcs[*].VpcId' --output text | tr '\t' '\n' | while read vpc; do
  logs=$(aws ec2 describe-flow-logs --filter "Name=resource-id,Values=$vpc" --query 'FlowLogs[*].FlowLogId' --output text)
  if [ -z "$logs" ]; then
    echo "SIN FLOW LOGS: $vpc"
  fi
done

Como arreglar:

aws ec2 create-flow-log --resource-type VPC --resource-ids vpc-xxxxxxxx --traffic-type ALL --log-destination-type cloud-watch-logs --log-group-name /aws/vpc/flowlogs --deliver-logs-permission-arn arn:aws:iam::ACCOUNT_ID:role/flowlogsRole

Habilita Flow Logs para todas las VPCs. El coste de almacenamiento es minimo comparado con el coste de no tener visibilidad durante un incidente.

---

Networking

Los errores de red son los mas faciles de explotar. Un Security Group mal configurado convierte tu instancia en un objetivo accesible para cualquier bot de escaneo del mundo.

9. Security Groups permitiendo SSH (22) desde 0.0.0.0/0 (CIS 5.2)

Si tu Security Group permite trafico entrante en el puerto 22 desde cualquier IP, literalmente cualquier persona en internet puede intentar conectarse por SSH a tu instancia. Los bots de escaneo prueban credenciales por fuerza bruta continuamente. Es cuestion de tiempo, no de si ocurrira.

Como verificar:

aws ec2 describe-security-groups --filters "Name=ip-permission.from-port,Values=22" "Name=ip-permission.to-port,Values=22" "Name=ip-permission.cidr,Values=0.0.0.0/0" --query 'SecurityGroups[*].{ID:GroupId,Name:GroupName}'

Como arreglar: Restringe el acceso SSH a las IPs de tu oficina o VPN. Mejor aun, elimina el acceso SSH directo y usa AWS Systems Manager Session Manager, que no requiere abrir ningun puerto.

---

10. Security Groups permitiendo RDP (3389) desde 0.0.0.0/0 (CIS 5.3)

El mismo problema que SSH, pero para instancias Windows. RDP expuesto al mundo es incluso mas peligroso porque el protocolo ha tenido vulnerabilidades criticas historicamente (BlueKeep, entre otras).

Como verificar:

aws ec2 describe-security-groups --filters "Name=ip-permission.from-port,Values=3389" "Name=ip-permission.to-port,Values=3389" "Name=ip-permission.cidr,Values=0.0.0.0/0" --query 'SecurityGroups[*].{ID:GroupId,Name:GroupName}'

Como arreglar: Misma logica que SSH. Restringe a IPs conocidas o, preferiblemente, usa Session Manager o una solucion de acceso remoto que no exponga puertos al exterior.

---

11. Security Group por defecto permite trafico (CIS 5.4)

Cada VPC en AWS viene con un Security Group por defecto. Muchas cuentas dejan este SG con reglas que permiten trafico entrante y saliente. El problema es que los recursos que no tienen un SG explicitamente asignado usan el default. Si alguien lanza una instancia sin especificar SG, hereda estas reglas permisivas.

Como verificar:

aws ec2 describe-security-groups --filters "Name=group-name,Values=default" --query 'SecurityGroups[*].{VPC:VpcId,Ingress:IpPermissions,Egress:IpPermissionsEgress}'

Si las reglas de ingreso o egreso no estan vacias, el SG default esta demasiado abierto.

Como arreglar: Elimina todas las reglas de entrada y salida del Security Group por defecto en cada VPC. No puedes borrar el SG, pero si puedes dejarlo sin reglas para que actue como un deny-all efectivo.

---

Storage y cifrado

Los datos son lo que los atacantes realmente quieren. Las misconfiguraciones de almacenamiento son las que generan titulares de brechas.

12. Buckets S3 sin cifrado del lado del servidor (CIS 2.1.1)

Desde enero de 2023, AWS cifra todos los objetos nuevos en S3 con SSE-S3 por defecto. Pero las cuentas antiguas pueden tener buckets creados antes de esa fecha sin cifrado configurado. Y algunos equipos desactivan explicitamente el cifrado por defecto.

Como verificar:

for bucket in $(aws s3api list-buckets --query 'Buckets[*].Name' --output text); do
  echo -n "$bucket: "
  aws s3api get-bucket-encryption --bucket $bucket 2>&1 | grep -q "ServerSideEncryptionConfiguration" && echo "CIFRADO" || echo "SIN CIFRAR"
done

Como arreglar:

aws s3api put-bucket-encryption --bucket nombre-del-bucket --server-side-encryption-configuration '{"Rules":[{"ApplyServerSideEncryptionByDefault":{"SSEAlgorithm":"aws:kms"}}]}'

Usa KMS en lugar de SSE-S3 si necesitas control sobre las claves de cifrado y auditoria de su uso.

---

13. Buckets S3 con acceso publico (CIS 2.1.2)

Este es el hallazgo que genera titulares. Un bucket S3 publico con datos sensibles es probablemente la causa mas frecuente de brechas de datos en cloud. Y no hace falta que un atacante sofisticado lo encuentre: hay herramientas automatizadas que escanean nombres de buckets predecibles.

Como verificar:

for bucket in $(aws s3api list-buckets --query 'Buckets[*].Name' --output text); do
  echo -n "$bucket: "
  aws s3api get-public-access-block --bucket $bucket 2>&1 | grep -q "true" && echo "BLOQUEADO" || echo "POSIBLEMENTE PUBLICO"
done

Como arreglar: Habilita Block Public Access a nivel de cuenta (no solo por bucket). Esto sobreescribe cualquier policy o ACL que intente hacer un bucket publico.

aws s3control put-public-access-block --account-id TU_ACCOUNT_ID --public-access-block-configuration BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true

Si necesitas servir contenido publico, usa CloudFront con un Origin Access Identity en vez de hacer el bucket publico directamente.

---

14. Volumenes EBS sin cifrado (CIS 2.2.1)

Si un volumen EBS no esta cifrado y alguien obtiene acceso a un snapshot (por compartirlo accidentalmente o por comprometer una cuenta), puede montar ese volumen y leer todos los datos en claro. Tambien aplica en escenarios de decomisionamiento de hardware en los data centers de AWS, aunque Amazon gestiona ese proceso.

Como verificar:

aws ec2 describe-volumes --query 'Volumes[?Encrypted==`false`].{ID:VolumeId,Size:Size,State:State}' --output table

Como arreglar: No puedes cifrar un volumen existente in-place. El proceso es: crear un snapshot, copiar el snapshot con cifrado, crear un nuevo volumen desde el snapshot cifrado, y reemplazar el volumen original. Para evitar esto en el futuro, activa el cifrado por defecto para la region:

aws ec2 enable-ebs-encryption-by-default

---

15. Instancias RDS sin cifrado en reposo (CIS 2.3.1)

Una base de datos RDS sin cifrado at-rest significa que los datos, backups automaticos y snapshots estan en claro. Si alguien obtiene acceso a un snapshot compartido o a la infraestructura subyacente, puede leer toda la informacion.

Como verificar:

aws rds describe-db-instances --query 'DBInstances[?StorageEncrypted==`false`].{ID:DBInstanceIdentifier,Engine:Engine,Class:DBInstanceClass}' --output table

Como arreglar: Al igual que con EBS, no puedes activar el cifrado en una instancia RDS existente directamente. El proceso es: crear un snapshot, copiar el snapshot con cifrado habilitado, restaurar una nueva instancia desde el snapshot cifrado, y migrar el trafico a la nueva instancia. Planifica una ventana de mantenimiento porque implica tiempo de inactividad.

---

Checklist rapido

---

Como automatizar la verificacion

Ejecutar estos 15 comandos manualmente una vez tiene sentido. Hacerlo cada semana no. La infraestructura cambia continuamente: alguien crea un Security Group nuevo, otro lanza una instancia RDS sin cifrado, otro comparte un snapshot. Necesitas verificacion continua.

AWS Config Rules. El servicio nativo de AWS para evaluacion continua de configuraciones. Puedes activar reglas predefinidas que mapean a controles CIS (por ejemplo, iam-root-account-mfa-enabled, cloud-trail-enabled, s3-bucket-public-read-prohibited). Evalua en tiempo real y genera hallazgos cuando un recurso no cumple. El problema: solo cubre AWS y la configuracion inicial de las reglas requiere trabajo.

AWS Security Hub. Agrega hallazgos de Config, GuardDuty, Inspector, Macie y Firewall Manager en un solo panel. Tiene un estandar CIS AWS Foundations Benchmark integrado que puedes activar con un click. Util si toda tu infraestructura esta en AWS.

Prowler (open source). Herramienta CLI que ejecuta mas de 300 checks contra tu cuenta de AWS, incluyendo todos los controles CIS. Genera reportes en CSV, JSON y HTML. Ideal para auditorias puntuales y para integrar en pipelines de CI/CD.

CSPM multi-cloud (Vulnerabbit). Si tienes recursos en AWS, GCP, Firebase u otros proveedores, necesitas visibilidad unificada. Vulnerabbit CSPM conecta todas tus cuentas cloud, evalua contra CIS Benchmarks, ISO 27001 y NIS2, y prioriza hallazgos por contexto de riesgo real, no solo por severidad teorica. Un bucket S3 publico con datos de prueba no tiene la misma prioridad que uno con datos de clientes.

La diferencia clave: las herramientas nativas de AWS solo ven AWS. Si tu infraestructura esta distribuida entre varios proveedores, tienes puntos ciegos que solo un CSPM multi-cloud puede cubrir. Y si ademas de configuraciones quieres verificar vulnerabilidades activas en tus servicios expuestos, combina el CSPM con un escaneo de vulnerabilidades en la nube.

---

De 150 hallazgos a un plan de accion

Tienes los hallazgos. Ahora necesitas priorizarlos. No puedes arreglar todo a la vez, y no todo tiene la misma urgencia. Esta es la clasificacion que recomendamos basandonos en impacto real y facilidad de explotacion:

Critico (arreglar hoy). Buckets S3 publicos con datos sensibles. Cuenta root sin MFA. CloudTrail desactivado o sin cobertura multi-region. Bucket de logs de CloudTrail accesible publicamente. Estos son hallazgos que un atacante puede explotar en minutos y que te dejan sin capacidad de deteccion o respuesta.

Alto (arreglar esta semana). SSH y RDP abiertos al mundo. Usuarios IAM sin MFA. S3, EBS y RDS sin cifrado. VPC Flow Logs no habilitados. Son vectores de ataque activos que requieren algo mas de esfuerzo para explotar, pero que siguen siendo objetivos prioritarios para atacantes automatizados.

Medio (arreglar este mes). Access keys sin rotar. Policies asignadas directamente a usuarios. Flow Logs faltantes en VPCs secundarias. Son problemas de higiene que incrementan el riesgo de forma acumulativa y que complican la respuesta a incidentes.

Bajo (planificar para el proximo trimestre). Reglas en Security Groups por defecto. Validacion de log files no habilitada. Son mejoras de defensa en profundidad que reducen la superficie de ataque pero que rara vez son el vector de entrada inicial.

No intentes pasar de 150 hallazgos a 0 en una semana. Resuelve los criticos hoy, programa los altos para esta semana, y crea tickets para el resto. Lo importante es que el numero baje de forma constante, no que llegue a cero de golpe.

---

Conclusion

Estos 15 controles CIS cubren la gran mayoria de los vectores de ataque reales en cuentas AWS. No son todos los controles del benchmark, pero son los que vemos violados con mas frecuencia y los que tienen mayor impacto cuando se explotan.

Arreglarlos no requiere herramientas caras ni meses de trabajo. La mayoria son cambios de configuracion que se aplican en minutos. Lo que requieren es disciplina para verificarlos continuamente, porque la infraestructura cloud cambia cada dia y una configuracion segura hoy puede estar expuesta manana.

Para verificacion continua, conecta tus cuentas AWS a un CSPM que evalue contra estos controles de forma automatica y te alerte cuando algo cambie. Si quieres un primer diagnostico rapido de tu superficie de ataque externa, empieza con nuestro escaner gratuito. En minutos tienes una foto de lo que un atacante ve desde fuera.

Los atacantes buscan el camino mas facil. Estos 15 controles eliminan los mas faciles.