Hardening Linux con Ansible en empresas: playbook CIS y automatización continua
Guía práctica para automatizar el hardening de servidores Linux con Ansible siguiendo los benchmarks CIS: estructura del playbook, roles reutilizables y control de desviaciones en producción.
El hardening manual de servidores Linux es lento, inconsistente y no escala. Cuando tienes 10 servidores puedes hacer las cosas a mano; cuando tienes 100 o gestionas infraestructura en la nube con autoscaling, necesitas automatización. Ansible combinado con los benchmarks CIS es el estándar de facto en empresas que quieren securizar su infraestructura Linux de forma reproducible, auditable y continua. Esta guía explica cómo estructurar un playbook de hardening, qué controles CIS priorizar y cómo integrar la detección de desviaciones en el ciclo de vida de la infraestructura.
Controles CIS por categoría y módulo Ansible correspondiente
El CIS Benchmark organiza los controles en secciones temáticas. Cada categoría tiene un conjunto de módulos Ansible especialmente adecuados para implementarla de forma idempotente.
| Categoría CIS | Ejemplos de controles | Módulo Ansible | Nivel CIS |
|---|---|---|---|
| Cuentas y acceso | Contraseña root bloqueada, sudo con requiretty, MFA | ansible.builtin.user, community.general.sudoers | L1 |
| Sistema de ficheros | noexec en /tmp, particiones separadas, permisos de archivos críticos | ansible.posix.mount, ansible.builtin.file | L1/L2 |
| Red y firewall | IP forwarding desactivado, TCP SYN cookies, UFW/firewalld activo | ansible.posix.sysctl, community.general.ufw | L1 |
| Servicios | Desactivar servicios innecesarios (telnet, rsh, NIS), SSH endurecido | ansible.builtin.service, ansible.builtin.lineinfile | L1 |
| Logging y auditoría | auditd configurado, logrotate, rsyslog, retención mínima 90 días | ansible.builtin.template, ansible.builtin.package | L2 |
Impacto del hardening automatizado con Ansible + CIS
Evolución típica del score de cumplimiento CIS en infraestructura Linux empresarial
Checklist de implementación: plan 30/60/90 días
Primeros 30 días — Auditoría de línea base
- Ejecutar una auditoría CIS sobre los servidores actuales con la herramienta
lyniso el script de auditoría de CIS-CAT - Documentar el score actual por categoría y los controles más críticos incumplidos
- Inventariar todos los servidores Linux gestionados y organizarlos en grupos de Ansible (producción, staging, desarrollo)
- Instalar Ansible y configurar el inventario dinámico si la infraestructura está en AWS, Azure o GCP
- Evaluar roles de Ansible Galaxy para CIS:
ansible-lockdown/UBUNTU22-CISoansible-lockdown/RHEL8-CIS
Días 31-60 — Crear la estructura del playbook
- Clonar el rol CIS de referencia y adaptarlo al entorno (versión de OS, excepciones del negocio)
- Definir variables de control por entorno: qué controles se aplican en producción vs. desarrollo
- Documentar cada excepción con su motivo en el fichero de variables del rol
- Ejecutar el playbook en un entorno de staging y validar que los servicios críticos siguen funcionando
- Configurar un pipeline CI que ejecute el playbook automáticamente al aprovisionar nuevos servidores
Días 61-90 — Integración continua y detección de drift
- Programar la ejecución periódica del playbook (semanal o diaria) en modo check para detectar desviaciones
- Configurar alertas cuando el playbook detecte cambios no autorizados respecto al estado deseado
- Integrar los informes de auditoría en el pipeline de CI/CD para bloquear despliegues si el score CIS cae por debajo del umbral
- Establecer una revisión trimestral del playbook para incorporar nuevas versiones del CIS Benchmark
- Documentar el proceso completo en el runbook de seguridad de la organización
Guías relacionadas
¿Quieres automatizar el hardening de tu infraestructura Linux?
En SysCu diseñamos e implementamos playbooks de hardening Ansible basados en CIS Benchmark, adaptados a tu stack y con detección continua de desviaciones. Tu infraestructura, segura y auditable desde el primer día.
Validación técnica y evidencia recomendada
Para que este enfoque sea defendible ante dirección y equipos técnicos, conviene acompañar la implementación con pruebas repetibles, métricas comparables y un registro claro de decisiones.
Pruebas técnicas mínimas
- Escaneo de IaC, dependencias y secretos en pipeline antes de deploy.
- Validación de controles de acceso (mínimo privilegio y rotación).
- Prueba de respuesta a incidente con runbook y tiempos medidos.
- Revisión de controles críticos contra benchmark (CIS/ISO/NIST).
Protocolo de validación reproducible
| Fase | Objetivo | Método | Criterio de aceptación |
|---|---|---|---|
| Baseline | Conocer exposición real y deuda de seguridad | Inventario de activos + matriz de criticidad | Cobertura completa en sistemas críticos |
| Hipótesis | Priorizar riesgos con impacto de negocio | Ranking por probabilidad, impacto y coste de remediación | Backlog con SLA de cierre por severidad |
| Validación | Reducir superficie de ataque medible | Aplicar controles y repetir escaneo/pentest | Sin críticos abiertos y reducción de altos |
| Escalado | Convertir seguridad en capacidad continua | Policy as code en pipeline y auditoría periódica | Controles automáticos antes de deploy |
Datos que debes conservar como evidencia
| Métrica | Herramienta | Cadencia | Objetivo |
|---|---|---|---|
| Vulnerabilidades críticas abiertas | SAST/DAST/SCA | Diario | 0 en producción |
| Cobertura de controles | Security Hub / auditoría | Semanal | >= 85% |
| Tiempo de remediación | Ticketing | Semanal | < SLA acordado |
| Excepciones vigentes | Risk register | Semanal | Con fecha de cierre |
Dashboard mínimo recomendado
| Panel | Fuente | Actualización | Umbral operativo |
|---|---|---|---|
| Estado de vulnerabilidades | SAST/DAST/SCA | Diario | 0 críticas abiertas en producción |
| Cobertura IAM | Cloud IAM analyzer | Semanal | Sin permisos admin sin justificación |
| Cumplimiento base | CIS/ISO/NIST checks | Semanal | >= 85% en controles prioritarios |
| Excepciones y deuda | Risk register | Semanal | Todas con fecha y owner |
Curva de madurez esperada (referencial)
Esta visualización sirve como referencia operativa para 90 días. Debe ajustarse con tus datos reales, complejidad técnica y contexto de negocio.
Superficie de ataque y activos críticos identificados.
Controles prioritarios y cierres de críticos.
Remediación consistente y menor deuda crítica.
Controles automatizados en pipeline y operación.
Riesgos que invalidan resultados
- Convertir controles en checklist sin conexión con riesgo real.
- Abrir excepciones sin vencimiento y acumular deuda invisible.
- Separar seguridad de despliegue y detectar tarde los defectos.
- No practicar respuesta a incidentes antes de un evento real.
Recomendaciones de implementación real
- Evitar excepciones permanentes: toda excepción debe caducar.
- Conectar riesgo técnico con impacto de negocio para priorizar mejor.
- Automatizar cumplimiento en despliegue, no solo en auditorías puntuales.
- Versionar políticas y registrar cambios para trazabilidad completa.
Preguntas frecuentes que suele hacer un equipo técnico
¿Por dónde empezar si hay mucha deuda de seguridad?
Por activos críticos y vectores de ataque más probables. Prioriza identidad, secretos, exposición pública y dependencias vulnerables.
¿Cómo equilibrar cumplimiento y velocidad de entrega?
Moviendo controles al pipeline con policy as code y aprobaciones basadas en riesgo, no en burocracia manual.
¿Cada cuánto revisar controles de seguridad?
Los controles críticos deben revisarse de forma continua (diaria/semanal) y formalizar una revisión de gobierno al menos mensual.
Preguntas frecuentes
¿Por qué usar Ansible para el hardening de Linux en lugar de scripts bash?
Ansible ofrece tres ventajas clave frente a scripts bash para el hardening: idempotencia (puedes ejecutar el playbook múltiples veces y el resultado siempre es el mismo, sin efectos secundarios), inventario dinámico (aplica el hardening a cientos de servidores en paralelo con un solo comando) y legibilidad declarativa (cualquier miembro del equipo puede leer el playbook y entender qué configuración está aplicando, sin descifrar lógica de shell). Además, el ecosistema de roles de Ansible Galaxy incluye implementaciones del CIS Benchmark mantenidas por la comunidad, lo que acelera enormemente el arranque.
¿Qué es el CIS Benchmark y por qué es el estándar de referencia?
El CIS (Center for Internet Security) Benchmark es un conjunto de recomendaciones de seguridad desarrolladas por consenso entre expertos de la industria, gobiernos y academia. Para Linux (Ubuntu, RHEL, Debian) define cientos de controles organizados en dos niveles: Level 1 (medidas básicas que no afectan significativamente a la funcionalidad) y Level 2 (medidas más restrictivas para entornos de alta seguridad). Es el estándar de referencia porque está respaldado por organismos como DISA, PCI DSS y SOC 2, lo que facilita las auditorías de cumplimiento normativo.
¿Qué significa idempotencia en el contexto del hardening con Ansible?
La idempotencia significa que ejecutar el mismo playbook una o cien veces produce exactamente el mismo estado final en el servidor, sin efectos secundarios acumulados. En hardening esto es crítico: si una configuración ya está aplicada correctamente, Ansible no la toca. Si ha sido modificada (por un administrador, una actualización del sistema o un atacante), Ansible la restaura al estado deseado. Esto convierte el playbook en un mecanismo de control de desviaciones (drift detection) además de un mecanismo de configuración inicial.
¿Cómo gestionar excepciones al CIS Benchmark en producción?
No todos los controles CIS son aplicables en todos los entornos. La forma correcta de gestionar excepciones es documentarlas explícitamente en el playbook mediante variables de control (por ejemplo, cis_rule_1_1_1_enabled: false) y comentarios que expliquen el motivo de la excepción (requisito de la aplicación, decisión del equipo de seguridad, etc.). Esto crea un registro auditable de las decisiones conscientes de no aplicar ciertos controles, muy valorado en auditorías de seguridad. Evita simplemente eliminar las tareas del playbook sin documentar el motivo.
Checklist FinOps AWS: 40 puntos para recortar tu factura
El mismo checklist que usamos en cada diagnóstico. Márcalo sobre tu cuenta AWS y sabrás dónde se te va el dinero.
- 40 puntos de revisión en 5 áreas
- Quick wins aplicables en 2–4 semanas
- El mismo checklist que usamos en los diagnósticos
¿Quieres aplicarlo con ayuda en Soporte de Infraestructura?
Si quieres priorizar quick wins y un plan ejecutable para tu equipo, podemos ayudarte con una sesión técnica de 30 minutos. Sin comerciales y sin compromiso.
¿Prefieres hacerlo por tu cuenta? Atlas Insight automatiza este análisis sobre tus cuentas AWS.