Ansible Security Hardening: Automatiza CIS y DISA STIG 2025

Ansible Security Hardening es la práctica de automatizar la configuración segura de sistemas mediante benchmarks como CIS y DISA STIG usando Ansible. Esta guía completa te enseña a implementar hardening automatizado en tus servidores Linux y Windows, reduciendo vulnerabilidades y cumpliendo con estándares de compliance como PCI-DSS, HIPAA e ISO 27001.

Qué es Ansible Security Hardening

Ansible Security Hardening transforma la gestión manual de seguridad en un proceso automatizado y repetible. En lugar de configurar manualmente firewalls, permisos y servicios en cada servidor, utilizas playbooks de Ansible que aplican configuraciones de seguridad basadas en estándares reconocidos internacionalmente.

Los benchmarks más utilizados son los CIS Benchmarks (Center for Internet Security) y DISA STIG (Security Technical Implementation Guides). Estos estándares definen configuraciones específicas como desactivar servicios innecesarios, configurar políticas de contraseñas robustas, habilitar logs de auditoría y endurecer permisos del sistema de archivos.

El proyecto Ansible Lockdown proporciona roles de código abierto que implementan estos benchmarks para RHEL, Ubuntu, Debian, Windows Server y otras plataformas. Cada rol incluye variables configurables que te permiten adaptar el nivel de hardening a tus necesidades sin modificar el código.

Por Qué Necesitas Ansible Security Hardening en 2025

La superficie de ataque en infraestructuras modernas crece exponencialmente con cada servidor desplegado. Configurar manualmente la seguridad es propenso a errores humanos y no escala cuando gestionas docenas o cientos de sistemas.

Ansible Security Hardening resuelve tres problemas críticos: primero, garantiza configuraciones consistentes en todos tus entornos (desarrollo, staging, producción). Segundo, documenta automáticamente qué controles de seguridad están activos mediante código versionado en Git. Tercero, acelera la respuesta ante nuevas vulnerabilidades aplicando parches de configuración simultáneamente en toda tu infraestructura.

Las regulaciones de compliance como PCI-DSS para procesamiento de pagos o HIPAA para datos médicos requieren evidencia documentada de controles de seguridad. Los playbooks de Ansible Security Hardening generan esta evidencia automáticamente y permiten auditorías repetibles con herramientas como GOSS, que verifica el cumplimiento de benchmarks en segundos.

Además, el stack de monitorización con Ansible Elasticsearch te permite centralizar logs de auditoría de todos tus servidores hardened, facilitando la detección de anomalías y cumplimiento normativo.

Componentes Clave de Ansible Security Hardening

CIS Benchmarks vs DISA STIG

Los CIS Benchmarks son guías consensuadas por la comunidad de seguridad que cubren sistemas operativos, aplicaciones cloud y software empresarial. Están organizados en dos niveles: Level 1 (controles básicos sin impacto en usabilidad) y Level 2 (controles avanzados que pueden afectar funcionalidad). Por ejemplo, CIS Level 1 para RHEL 8 incluye 217 controles automatizables.

Los DISA STIG son estándares del Departamento de Defensa de EE.UU., más estrictos que CIS y diseñados para entornos gubernamentales de alta seguridad. Incluyen configuraciones como desactivar módulos de kernel innecesarios, forzar cifrado FIPS y configurar timeouts de sesión agresivos.

Elige CIS Benchmarks si necesitas un equilibrio entre seguridad y operatividad en entornos empresariales. Usa DISA STIG si trabajas en sectores regulados como defensa, finanzas o salud donde la seguridad máxima es prioritaria. Ambos frameworks son compatibles con Ansible Security Hardening.

Ansible Lockdown: Roles Oficiales

El ecosistema Ansible Lockdown mantiene roles para múltiples plataformas: RHEL8-CIS, RHEL9-CIS, UBUNTU22-CIS, UBUNTU24-CIS, Windows-2019-CIS, Windows-2022-CIS entre otros. Cada rol se actualiza cuando se publican nuevas versiones de benchmarks.

Todos los roles incluyen una versión de auditoría complementaria (ejemplo: RHEL8-CIS-Audit) que utiliza GOSS para escanear sistemas y reportar el estado de cumplimiento sin modificar configuraciones. Esto permite verificar el compliance antes y después de aplicar remediaciones.

Las variables de configuración están estandarizadas: rhel8cis_level_1 activa controles Level 1, rhel8cis_level_2 añade controles Level 2, y cada control individual puede desactivarse con flags específicos si impacta tus aplicaciones. Por ejemplo, rhel8cis_rule_1_1_1_1 controla el montaje de sistemas de archivos cramfs.

Auditoría con GOSS

GOSS es un binario escrito en Go que valida el estado de sistemas operativos mediante tests declarativos. Los roles de Ansible Security Hardening lo integran para verificar más de 200 controles en segundos.

Un ejemplo de test GOSS verifica que el servicio Avahi esté desactivado: service: avahi-daemon: enabled: false running: false. Ansible ejecuta GOSS antes (pre-remediation) y después (post-remediation) de aplicar cambios, generando reportes JSON con el delta de compliance.

Puedes integrar estos reportes con dashboards de Grafana para visualizar tendencias de compliance en tiempo real, alertando cuando servidores salen de los estándares configurados.

Cómo Implementar Ansible Security Hardening Paso a Paso

Paso 1: Instalación de Roles de Ansible Lockdown

Primero, instala Ansible 2.11 o superior y Python 3.8+. Luego descarga el rol correspondiente a tu sistema operativo desde GitHub Ansible Lockdown:

# Para RHEL 8 / Rocky Linux / AlmaLinux
ansible-galaxy install ansible-lockdown.rhel8-cis

# Para Ubuntu 22.04
ansible-galaxy install ansible-lockdown.ubuntu22-cis

# Para Windows Server 2019
ansible-galaxy install ansible-lockdown.windows-2019-cis

Los roles se instalan en ~/.ansible/roles/ por defecto. Verifica la instalación listando el contenido del rol: ls -la ~/.ansible/roles/ansible-lockdown.rhel8-cis/.

Paso 2: Configuración de Variables de Hardening

Crea un archivo de variables group_vars/hardened_servers.yml con la configuración de Ansible Security Hardening:

---
# Activa auditoría pre y post remediación
rhel8cis_run_audit: true

# Selecciona nivel de benchmark (Level 1 más Level 2)
rhel8cis_level_1: true
rhel8cis_level_2: true

# Configura tipo de servidor
rhel8cis_server_type: server  # opciones: server, workstation

# Desactiva controles específicos si impactan tus apps
rhel8cis_rule_1_5_2: false  # Deshabilitar bootloader password
rhel8cis_rule_3_4_1: false  # Deshabilitar DCCP (si usas streaming)

# Configuración de auditoría
rhel8cis_audit_format: json
rhel8cis_audit_outpath: /var/log/cis-audit/

Revisa el archivo defaults/main.yml del rol para ver todas las variables disponibles. Cada control CIS tiene una variable booleana que permite activarlo o desactivarlo granularmente.

Paso 3: Crear Playbook de Hardening

Crea el playbook principal harden-servers.yml que aplica Ansible Security Hardening:

---
- name: Aplicar CIS Benchmark Hardening a servidores RHEL
  hosts: hardened_servers
  become: true
  vars_files:
    - group_vars/hardened_servers.yml

  pre_tasks:
    - name: Verificar versión de RHEL soportada
      ansible.builtin.assert:
        that:
          - ansible_distribution == "RedHat" or ansible_distribution == "Rocky" or ansible_distribution == "AlmaLinux"
          - ansible_distribution_major_version == "8"
        fail_msg: "Este playbook requiere RHEL/Rocky/AlmaLinux 8"

    - name: Crear backup de configuraciones críticas
      ansible.builtin.copy:
        src: "{{ item }}"
        dest: "{{ item }}.backup-{{ ansible_date_time.epoch }}"
        remote_src: true
      loop:
        - /etc/ssh/sshd_config
        - /etc/security/limits.conf
        - /etc/sysctl.conf
      ignore_errors: true

  roles:
    - role: ansible-lockdown.rhel8-cis
      tags: ['hardening', 'cis']

  post_tasks:
    - name: Reiniciar servicios modificados
      ansible.builtin.systemd:
        name: "{{ item }}"
        state: restarted
      loop:
        - sshd
        - auditd
      when: ansible_facts.services[item] is defined

    - name: Recopilar reporte de auditoría
      ansible.builtin.fetch:
        src: /var/log/cis-audit/audit_report.json
        dest: "./audit-reports/{{ inventory_hostname }}-{{ ansible_date_time.date }}.json"
        flat: true

Este playbook incluye pre-tasks para validar requisitos y crear backups de configuraciones críticas antes de aplicar cambios. Los post-tasks reinician servicios modificados y recopilan reportes de auditoría centralizados.

Paso 4: Ejecución en Modo Check (Dry-Run)

Antes de modificar producción, ejecuta el playbook en modo check para ver qué cambiaría:

# Ejecutar solo auditoría sin cambios
ansible-playbook harden-servers.yml --tags audit --check

# Ver cambios específicos de Level 1
ansible-playbook harden-servers.yml --tags level1_server --check --diff

Analiza el output cuidadosamente. Busca tareas que fallen por incompatibilidades con tu infraestructura (ejemplo: controles de particione si usas LVM no estándar). Desactiva esos controles específicos en las variables antes de ejecutar en producción.

Paso 5: Aplicar Hardening en Producción

Una vez validado en staging, aplica Ansible Security Hardening en producción de forma controlada:

# Aplicar hardening a un servidor de prueba primero
ansible-playbook harden-servers.yml --limit test-server-01

# Verificar que el servidor funciona correctamente (15-30 minutos)

# Aplicar al resto con paralelismo limitado (rolling update)
ansible-playbook harden-servers.yml --forks 5

# Aplicar solo controles de red sin reiniciar
ansible-playbook harden-servers.yml --tags network --skip-tags reboot

Monitorea logs de aplicaciones y servicios críticos durante y después de la ejecución. Algunos controles CIS Level 2 pueden requerir ajustes en aplicaciones que usan configuraciones de kernel específicas.

Controles Críticos de Ansible Security Hardening

Hardening del Sistema de Archivos

Los benchmarks CIS requieren opciones de montaje específicas para prevenir ejecución de código malicioso. Ansible Security Hardening configura automáticamente:

• nodev en /tmp, /var/tmp, /home: previene creación de dispositivos especiales
• nosuid en particiones de usuario: deshabilita bit SUID en ejecutables
• noexec en /tmp: impide ejecución de binarios desde temporal
• Permisos 0600 en /boot/grub2/grub.cfg: protege configuración de bootloader

Adicionalmente, configura sticky bit en directorios world-writable (chmod +t) para que solo owners puedan eliminar sus archivos, previniendo DoS por llenado de disco.

Configuración de SSH Segura

El protocolo SSH es vector de ataque común. Ansible Security Hardening endurece /etc/ssh/sshd_config con:

Protocol 2
PermitRootLogin no
PubkeyAuthentication yes
PasswordAuthentication no
PermitEmptyPasswords no
X11Forwarding no
MaxAuthTries 3
ClientAliveInterval 300
ClientAliveCountMax 0
AllowUsers ansible-user admin-user
Ciphers [email protected],[email protected]
MACs [email protected],[email protected]

Esta configuración deshabilita autenticación por password (solo claves SSH), limita intentos de login, cierra sesiones idle y usa solo ciphers modernos resistentes a ataques conocidos.

Auditoría con auditd

El daemon auditd registra eventos de seguridad a nivel de kernel. Los roles de Ansible Security Hardening configuran reglas para monitorear:

• Modificaciones en archivos críticos: /etc/passwd, /etc/shadow, /etc/sudoers
• Cambios en configuración de red: /etc/sysconfig/network-scripts/
• Llamadas de sistema privilegiadas: setuid, setgid, execve
• Intentos de acceso denegado: EACCES, EPERM
• Montaje y desmontaje de sistemas de archivos

Los logs generados pueden enviarse a un cluster centralizado de Elasticsearch para análisis forense y detección de amenazas con Sigma rules.

Hardening de Kernel con sysctl

Los parámetros de kernel controlan comportamientos de red y sistema que impactan seguridad. Ansible Security Hardening configura /etc/sysctl.conf con:

# Deshabilitar IP forwarding (excepto routers)
net.ipv4.ip_forward = 0
net.ipv6.conf.all.forwarding = 0

# Protección contra IP spoofing
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1

# Ignorar ICMP redirects (previene ataques MITM)
net.ipv4.conf.all.accept_redirects = 0
net.ipv6.conf.all.accept_redirects = 0

# Deshabilitar source routing
net.ipv4.conf.all.accept_source_route = 0

# Activar SYN cookies (protección DDoS)
net.ipv4.tcp_syncookies = 1

# Logging de paquetes sospechosos
net.ipv4.conf.all.log_martians = 1

Estos parámetros se aplican inmediatamente con sysctl -p y persisten en reinicios. Son especialmente críticos en servidores expuestos a internet.

Gestión de Secretos en Ansible Security Hardening

Los playbooks de hardening a menudo contienen datos sensibles como passwords de GRUB, certificados SSL o claves API para integración con SIEM. Nunca almacenes secretos en texto plano en repositorios Git.

Utiliza Ansible Vault para cifrar archivos de variables sensibles:

# Crear archivo cifrado para secretos
ansible-vault create group_vars/hardened_servers/vault.yml

# Contenido ejemplo (se editará con tu editor por defecto):
---
rhel8cis_bootloader_password: "P@ssw0rd_Gr00b!Secur3"
rhel8cis_aide_db_key: "{{ lookup('password', '/dev/null length=32 chars=ascii_letters,digits') }}"

# Ejecutar playbook con vault password
ansible-playbook harden-servers.yml --ask-vault-pass

# O usando archivo de password
ansible-playbook harden-servers.yml --vault-password-file ~/.vault_pass.txt

Para entornos enterprise, integra con HashiCorp Vault o AWS Secrets Manager usando el módulo community.hashi_vault.vault_read. Esto permite rotación automática de secretos sin modificar playbooks.

Además, el External Secrets Operator para Kubernetes sincroniza secretos desde Vault a tus clusters donde despliegas aplicaciones configuradas con Ansible.

Integración de Ansible Security Hardening con CI/CD

El hardening debe ser parte de tu pipeline de infrastructure as code. Automatiza la validación de compliance en cada cambio de infraestructura.

Ejemplo de integración con GitLab CI:

stages:
  - validate
  - audit
  - harden
  - verify

validate-playbook:
  stage: validate
  script:
    - ansible-playbook harden-servers.yml --syntax-check
    - ansible-lint harden-servers.yml

audit-compliance:
  stage: audit
  script:
    - ansible-playbook harden-servers.yml --tags audit --check
  artifacts:
    paths:
      - audit-reports/
    expire_in: 30 days

apply-hardening:
  stage: harden
  script:
    - ansible-playbook harden-servers.yml --limit staging
  only:
    - main
  when: manual

verify-compliance:
  stage: verify
  script:
    - ansible-playbook harden-servers.yml --tags audit
    - python3 scripts/validate_cis_score.py audit-reports/
  dependencies:
    - apply-hardening

Este pipeline valida sintaxis, ejecuta auditorías automáticas en cada commit, aplica hardening manualmente a staging y verifica que el score CIS sea ≥85% post-remediación.

Para Kubernetes, combina Ansible Security Hardening con Crossplane para provisionar clusters ya hardened desde el primer despliegue.

Monitorización Continua de Compliance

El hardening no es un evento único sino un proceso continuo. Los sistemas derivan de configuraciones seguras por actualizaciones de paquetes, cambios manuales o errores de configuración.

Implementa auditorías programadas con cron:

---
- name: Programar auditoría CIS diaria
  hosts: hardened_servers
  become: true
  tasks:
    - name: Crear script de auditoría
      ansible.builtin.copy:
        dest: /usr/local/bin/cis-audit.sh
        mode: '0755'
        content: |
          #!/bin/bash
          cd /opt/ansible-lockdown
          ansible-playbook localhost.yml --tags audit
          curl -X POST https://monitoring.empresa.com/api/compliance \
            -H "Content-Type: application/json" \
            -d @/var/log/cis-audit/audit_report.json

    - name: Programar ejecución diaria a las 02:00
      ansible.builtin.cron:
        name: "CIS Compliance Audit"
        hour: "2"
        minute: "0"
        job: "/usr/local/bin/cis-audit.sh"
        user: root

Los reportes JSON se envían a tu plataforma de monitorización donde puedes configurar alertas si el score cae por debajo del umbral. Herramientas como Grafana visualizan tendencias de compliance por servidor, región o entorno.

Casos de Uso Reales de Ansible Security Hardening

Sector Financiero: PCI-DSS Compliance

Bancos y procesadores de pago deben cumplir PCI-DSS para manejar datos de tarjetas. Los requisitos 2.2 (hardening de sistemas) y 10.2 (auditoría de accesos) se implementan directamente con Ansible Security Hardening.

Un banco regional automatizó hardening de 500+ servidores RHEL con roles CIS Level 2, reduciendo el tiempo de preparación para auditorías de 3 semanas a 2 días. Los reportes GOSS generan evidencia automatizada que los auditores aceptan sin validación manual adicional.

Sector Salud: HIPAA y Datos Médicos

Proveedores de salud deben proteger PHI (Protected Health Information) según HIPAA. Los controles técnicos incluyen cifrado, auditoría de accesos y gestión de vulnerabilidades.

Un hospital implementó Ansible Security Hardening en servidores de historiales médicos electrónicos, combinado con Ansible PostgreSQL para hardening de bases de datos. El resultado: cifrado automático de datos en reposo, rotación de passwords cada 90 días y logs de auditoría centralizados que detectaron 3 intentos de acceso no autorizado en el primer mes.

Infraestructura Cloud Multi-Región

Empresas SaaS con despliegues en AWS, Azure y GCP enfrentan el desafío de mantener configuraciones consistentes entre proveedores cloud. Ansible Security Hardening con inventarios dinámicos aplica los mismos benchmarks CIS independientemente de dónde corran las VMs.

Una startup fintech usa Terraform para provisionar infraestructura y luego ejecuta playbooks de hardening automáticamente vía user-data. Resultado: cada instancia EC2 nueva nace ya hardened según CIS AWS Foundations y CIS RHEL, sin intervención manual.

Errores Comunes y Cómo Evitarlos

Aplicar Level 2 Sin Testing Previo

Los controles CIS Level 2 pueden romper aplicaciones legacy que dependen de configuraciones inseguras. Por ejemplo, aplicaciones que requieren SUID en binarios específicos fallarán si Ansible Security Hardening remueve esos permisos.

Solución: Implementa Level 1 primero, monitorea por 2-4 semanas, luego activa Level 2 gradualmente usando tags de Ansible para aplicar grupos de controles específicos. Usa --check --diff extensivamente antes de cada cambio en producción.

No Mantener Documentación de Excepciones

Cuando desactivas controles CIS específicos por incompatibilidad, esa decisión debe documentarse formalmente. Los auditores necesitan justificación de por qué ciertos controles no aplican.

Solución: Crea un archivo docs/cis-exceptions.md en tu repositorio listando cada control desactivado con: ID del control, razón técnica, riesgo aceptado, controles compensatorios implementados, y fecha de revisión. Ejemplo:

## Control CIS 1.5.2 - Bootloader Password
**Status:** Desactivado
**Razón:** Servidores cloud con acceso solo vía SSH, consola física no disponible
**Riesgo:** Bajo - acceso físico imposible en AWS
**Compensación:** MFA en acceso SSH + AWS IAM roles restrictivos
**Próxima revisión:** 2025-06-01

Ignorar Actualizaciones de Benchmarks

CIS publica nuevas versiones de benchmarks 1-2 veces al año incorporando nuevas amenazas. Usar roles de Ansible Security Hardening desactualizados deja gaps de seguridad.

Solución: Suscríbete a notificaciones del repositorio Ansible Lockdown en GitHub para recibir alertas de nuevas releases. Programa revisiones trimestrales donde actualizas roles, ejecutas auditorías y ajustas variables según nuevos controles.

FAQ sobre Ansible Security Hardening

¿Ansible Security Hardening funciona en contenedores Docker?

Los benchmarks CIS para contenedores son diferentes a sistemas operativos tradicionales. Usa el rol Docker-CIS de Ansible Lockdown específico para hardening de Docker daemon, runtime y imágenes. Para orquestadores, existe Kubernetes-CIS que hardena control plane, workers y configuraciones de pods.

¿Cuánto tiempo toma aplicar hardening completo?

En un servidor RHEL 8 estándar, ejecutar Ansible Security Hardening Level 1 + Level 2 toma 8-15 minutos dependiendo de configuración inicial. La auditoría GOSS pre y post remediación añade 2-3 minutos. En flotas grandes, paraleliza con --forks para procesar múltiples servidores simultáneamente.

¿Puedo revertir cambios si algo falla?

Los playbooks crean backups automáticos de archivos críticos (sshd_config, sysctl.conf, etc.) antes de modificarlos. Puedes restaurar manualmente esos backups. Para reversión completa, usa snapshots de VM/instancia cloud antes de ejecutar hardening. Herramientas como Ansible copy module con parámetro backup: yes facilitan rollback.

¿Cómo afecta el hardening al rendimiento del sistema?

La mayoría de controles CIS tienen impacto mínimo en performance. Excepciones: auditd con reglas extensivas puede añadir 2-5% overhead CPU en sistemas con I/O intensivo. Los parámetros sysctl como SYN cookies consumen memoria adicional bajo ataques DDoS pero no en operación normal. Haz benchmarking pre y post hardening con herramientas como sysbench para tu workload específico.

¿Necesito licencias para usar Ansible Lockdown?

No. Todos los roles de Ansible Security Hardening en el proyecto Ansible Lockdown usan licencia MIT de código abierto. Puedes usar, modificar y distribuir libremente. Los benchmarks CIS requieren registro gratuito en cisecurity.org para descargar PDFs oficiales, pero los roles implementan los controles sin necesidad de comprar licencias CIS.

Conclusión: Automatiza la Seguridad con Ansible Security Hardening

Ansible Security Hardening transforma la gestión de compliance de proceso manual propenso a errores en pipeline automatizado y auditable. Al implementar benchmarks CIS o DISA STIG mediante playbooks versionados, garantizas configuraciones consistentes en toda tu infraestructura y generas evidencia objetiva para auditorías.

Los beneficios son inmediatos: reducción de superficie de ataque, detección temprana de desviaciones de compliance y capacidad de aplicar parches de configuración a escala en minutos. Combina Ansible Security Hardening con Ansible Kubernetes para clusters seguros desde el despliegue, o con Ansible Docker Deployment para contenedores hardened.

Empieza con Level 1 en entornos de desarrollo, valida impacto, documenta excepciones y expande gradualmente a producción. La seguridad no es destino sino journey continuo, y Ansible Security Hardening es la herramienta que hace ese camino escalable y repetible.