Compliance-as-Code: Automatizar el Cumplimiento Normativo con Código

Las auditorías manuales no escalan

Cada vez que un equipo de seguridad prepara una auditoría ENS Alto o una revisión NIS2, el proceso se repite: recopilar evidencias de configuración, capturar pantallazos, verificar que los controles siguen aplicados, documentar excepciones. Se invierten semanas de trabajo que, en muchos casos, reflejan el estado del sistema en un momento puntual. Al día siguiente del informe, un cambio en producción puede invalidar la mitad de las evidencias.

Este modelo tiene tres problemas estructurales. Primero, no escala: cuando gestionas decenas de servicios en cloud, cientos de servidores y miles de configuraciones, la verificación manual es inviable. Segundo, el drift normativo (la divergencia entre la política declarada y el estado real) crece entre auditorías sin que nadie lo detecte. Tercero, el factor humano introduce errores: un check que se omite, una excepción que no se documenta, una configuración que se interpreta de forma distinta por dos auditores.

Compliance-as-Code propone una alternativa: tratar las políticas de cumplimiento como código ejecutable que se evalúa de forma continua y automatizada contra la infraestructura real.

Qué es Compliance-as-Code

Compliance-as-Code (CaC) consiste en codificar los requisitos normativos en ficheros que pueden ser ejecutados, versionados, testeados y desplegados como cualquier otro artefacto de software. En lugar de un documento PDF que dice "todos los puertos no esenciales deben estar cerrados", se escribe una regla que verifica automáticamente qué puertos están abiertos en cada servidor y alerta (o bloquea) si hay desviaciones.

El concepto se apoya en tres pilares:

1. Policy-as-Code: las políticas de seguridad y cumplimiento se expresan en un lenguaje declarativo o imperativo que las herramientas pueden interpretar.
2. Infraestructura como código (IaC): la infraestructura se define en ficheros (Terraform, CloudFormation, Ansible), lo que permite evaluar las políticas antes del despliegue.
3. Monitorización continua: los checks se ejecutan periódicamente contra el estado real de producción, no solo en el momento del despliegue.

La ventaja principal no es solo la velocidad: es la trazabilidad. Cada política tiene un historial de cambios en Git, cada ejecución genera un registro de resultados, cada excepción queda documentada en código. Cuando llega el auditor, las evidencias se generan automáticamente.

Herramientas de Policy-as-Code

OPA (Open Policy Agent) y Rego

OPA es el estándar de facto para políticas genéricas. Desarrollado por Styra y donado a la CNCF, OPA evalúa políticas escritas en Rego (un lenguaje declarativo) contra datos estructurados en JSON. Se integra con Kubernetes (como admission controller), Terraform, APIs HTTP, pipelines CI/CD y prácticamente cualquier sistema que produzca datos JSON.

# Política: todo bucket S3 debe tener cifrado habilitado
package aws.s3

deny[msg] {
    bucket := input.resource.aws_s3_bucket[name]
    not bucket.server_side_encryption_configuration
    msg := sprintf("Bucket %v sin cifrado en reposo", [name])
}

# Política: no permitir puertos abiertos a 0.0.0.0/0
deny[msg] {
    sg := input.resource.aws_security_group[name]
    rule := sg.ingress[_]
    rule.cidr_blocks[_] == "0.0.0.0/0"
    msg := sprintf("Security group %v con ingress abierto a Internet", [name])
}

OPA funciona como un servidor (daemon) o como librería embebida. La arquitectura desacopla la decisión (OPA) de la aplicación (enforcement point), lo que permite reutilizar las mismas políticas en diferentes contextos.

HashiCorp Sentinel

Sentinel es el motor de políticas de HashiCorp, integrado nativamente con Terraform Enterprise/Cloud, Vault y Consul. A diferencia de OPA, Sentinel es propietario. Su lenguaje es más legible que Rego para quienes vienen de programación imperativa.

# Sentinel: verificar que todas las instancias usan tipos permitidos
import "tfplan/v2" as tfplan

allowed_types = ["t3.medium", "t3.large", "m5.large"]

main = rule {
    all tfplan.resource_changes as _, rc {
        rc.type is "aws_instance" and
        rc.change.after.instance_type in allowed_types
    }
}

Sentinel es la opción natural si tu organización ya usa Terraform Cloud. Para entornos open-source, OPA con el plugin conftest ofrece funcionalidad equivalente sobre ficheros Terraform.

Chef InSpec

InSpec es un framework de testing de infraestructura que describe el estado deseado de los sistemas en un lenguaje legible. A diferencia de OPA (que evalúa datos JSON), InSpec se conecta directamente a los sistemas (SSH, WinRM, APIs cloud) y verifica su configuración real.

# InSpec: verificar hardening SSH
control 'ssh-01' do
  impact 1.0
  title 'SSH debe usar protocolo v2'
  desc 'El protocolo SSH v1 tiene vulnerabilidades conocidas'

  describe sshd_config do
    its('Protocol') { should eq '2' }
    its('PermitRootLogin') { should eq 'no' }
    its('PasswordAuthentication') { should eq 'no' }
    its('MaxAuthTries') { should cmp <= 3 }
  end
end

# InSpec: verificar cifrado de disco
control 'disk-encryption-01' do
  impact 0.9
  title 'Volúmenes deben estar cifrados'

  describe command('lsblk -o NAME,TYPE,FSTYPE,MOUNTPOINT') do
    its('stdout') { should_not match /ext4.*\/(?!boot)/ }
  end
end

InSpec destaca por sus perfiles predefinidos (CIS Benchmarks, DISA STIGs) que cubren decenas de sistemas operativos y servicios. La comunidad mantiene perfiles para CIS Ubuntu, CIS Windows Server, CIS Docker, CIS Kubernetes y muchos más.

Prowler y ScoutSuite

Para auditoría de entornos cloud, Prowler (AWS, Azure, GCP) y ScoutSuite (multi-cloud) son las herramientas de referencia open-source.

Prowler ejecuta cientos de checks predefinidos basados en CIS Benchmarks, PCI-DSS, HIPAA, GDPR, ENS y otros frameworks. Genera informes en múltiples formatos (HTML, CSV, JSON, OCSF) y se integra con AWS Security Hub.

# Prowler: auditar cuenta AWS contra CIS Benchmark
prowler aws --compliance cis_2.0_aws

# Prowler: solo checks de cifrado
prowler aws --category encryption

# Prowler: auditar contra ENS (checks mapeados)
prowler aws --compliance ens_rd2022_aws

ScoutSuite ofrece una vista multi-cloud unificada con un dashboard HTML interactivo que permite navegar por servicio, severidad y regla. Es especialmente útil para organizaciones con entornos hybrid o multi-cloud.

Compliance en infraestructura como código

Terraform + OPA (conftest)

La integración más potente se produce cuando las políticas se evalúan antes del despliegue, en la fase de plan. Con conftest (herramienta CLI que usa OPA internamente), se valida el plan de Terraform contra las políticas Rego:

# Generar el plan en formato JSON
terraform plan -out=tfplan.binary
terraform show -json tfplan.binary > tfplan.json

# Evaluar contra políticas
conftest test tfplan.json --policy policy/

Este enfoque es preventivo: los recursos que no cumplan las políticas nunca llegan a desplegarse. El pipeline de CI/CD falla con un mensaje claro indicando qué política se ha violado.

CloudFormation Guard

Para entornos AWS que usan CloudFormation en lugar de Terraform, cfn-guard es la herramienta nativa de AWS para validar plantillas contra reglas declarativas:

# cfn-guard: regla para S3
rule s3_bucket_encryption {
    AWS::S3::Bucket {
        BucketEncryption.ServerSideEncryptionConfiguration[*] {
            ServerSideEncryptionByDefault.SSEAlgorithm == "aws:kms"
        }
    }
}

Compliance nativo en cloud

Los tres grandes proveedores ofrecen servicios nativos de compliance continuo:

AWS Config Rules

AWS Config monitoriza el estado de los recursos en tiempo real y evalúa reglas (managed o custom) contra la configuración actual. Las reglas managed cubren CIS, PCI-DSS y best practices de AWS. Las custom se implementan como funciones Lambda.

Ejemplo de regla managed: s3-bucket-server-side-encryption-enabled verifica automáticamente que todo bucket S3 tiene cifrado habilitado. Si un bucket se crea sin cifrado, Config lo detecta en minutos y puede ejecutar una remediación automática (SSM Automation) que habilite el cifrado.

Azure Policy

Azure Policy evalúa la conformidad de recursos contra definiciones de políticas en JSON. Soporta modos audit (solo informa), deny (bloquea la creación) y deployIfNotExists (remedia automáticamente).

Las iniciativas (conjuntos de políticas) predefinidas incluyen CIS Azure Benchmark, NIST SP 800-53, ISO 27001, ENS y la lista se amplia constantemente.

GCP Organization Policy

GCP Organization Policy opera a nivel de organización, carpeta o proyecto. Los constraints restringen qué recursos pueden crearse y con qué configuración. Combinado con Security Command Center, ofrece visibilidad continua del estado de compliance.

CIS Benchmarks: automatización práctica

Los CIS Benchmarks son la referencia de facto para hardening de sistemas. Cada benchmark define cientos de controles con niveles de perfil (Level 1 para servidores, Level 2 para estaciones de trabajo) y estado de automatización (Automated vs Manual).

La automatización de CIS Benchmarks sigue un patrón consistente:

1. Seleccionar perfil: Level 1 cubre el 80% de los controles con menor impacto operativo.
2. Elegir herramienta: InSpec para servidores, Prowler para cloud, OpenSCAP para entornos regulados (produce informes XCCDF/ARF para auditorías formales).
3. Ejecutar scan inicial: establecer la baseline de cumplimiento.
4. Remediar: aplicar los cambios (Ansible, Puppet, Chef, scripts) de forma controlada.
5. Monitorizar: programar scans periódicos y configurar alertas de drift.

# OpenSCAP: evaluar contra CIS Ubuntu 22.04 Level 1
oscap xccdf eval \
  --profile xccdf_org.ssgproject.content_profile_cis_level1_server \
  --results results.xml \
  --report report.html \
  /usr/share/xml/scap/ssg/content/ssg-ubuntu2204-ds.xml

El porcentaje de automatización varía: CIS AWS Foundations Benchmark tiene un 90% de controles automatizables. CIS Ubuntu Server Level 1 llega al 85%. Los controles manuales suelen ser organizativos (revisar políticas, verificar procesos de gestión de cambios).

Automatización del ENS: qué se puede y qué no

El Esquema Nacional de Seguridad (RD 311/2022) estructura sus medidas en tres marcos: organizativo, operacional y de protección. La automatizabilidad varía significativamente entre ellos.

Medidas altamente automatizables

Las medidas del marco de protección y parte del operacional son las más adecuadas para CaC:

Medida ENS	Código	Automatizable
Cifrado en tránsito (TLS)	mp.com.2	Sí: verificar certificados, versiones TLS, cipher suites
Cifrado en reposo	mp.info.4	Sí: verificar configuración de volúmenes, bases de datos
Control de acceso	op.acc.*	Parcial: verificar configuración IAM, MFA habilitado
Gestión de vulnerabilidades	op.mon.1	Sí: scans automáticos, verificar parches aplicados
Registro de actividad	op.mon.2	Sí: verificar que logging está activo y centralizado
Protección perimetral	mp.com.1	Sí: verificar reglas de firewall, security groups
Bastionado de sistemas	op.exp.2	Sí: InSpec/OpenSCAP contra CIS Benchmarks
Copias de seguridad	mp.info.6	Parcial: verificar que existen, testear restauración es manual

Medidas difíciles de automatizar

Los controles organizativos requieren evidencias que no son técnicas:

Medida ENS	Código	Por qué no se automatiza
Política de seguridad	org.1	Documento aprobado por dirección, revisión periódica
Normativa de seguridad	org.2	Procedimientos escritos, difusión al personal
Formación y concienciación	mp.per.3	Ejecución y registro de sesiones formativas
Seguridad física	mp.if.*	Controles de acceso físico, video, clima
Gestión de proveedores	op.ext.*	Contratos, auditorías a terceros, SLAs
Análisis de riesgos	op.pl.1	Metodología MAGERIT, decisiones de dirección
Gestión de incidentes (proceso)	op.mon.3	Procedimientos de escalado, comunicación a CCN-CERT

La estrategia realista: automatizar los controles técnicos (aproximadamente el 60-65% del total en categoría Alta) y gestionar el resto con workflows documentados que faciliten la generación de evidencias.

Monitorización continua de compliance

La monitorización continua cierra el ciclo: no basta con verificar el cumplimiento en el momento del despliegue. El estado real de la infraestructura cambia constantemente (despliegues, cambios manuales, actualizaciones, escalado).

Arquitectura de un sistema de compliance continuo

┌─────────────┐     ┌──────────────┐     ┌─────────────────┐
│ Fuentes     │     │ Motor de     │     │ Dashboard       │
│             │────→│ Políticas    │────→│ + Alertas       │
│ - IaC repos │     │              │     │                 │
│ - Cloud APIs│     │ - OPA/Rego   │     │ - Estado actual │
│ - Agentes   │     │ - InSpec     │     │ - Tendencia     │
│ - CMDB      │     │ - Prowler    │     │ - Drift alerts  │
└─────────────┘     └──────────────┘     └─────────────────┘
                           │
                    ┌──────┴──────┐
                    │ Resultados  │
                    │ - Pass/Fail │
                    │ - Evidencias│
                    │ - Timestamp │
                    └─────────────┘

Los componentes clave son:

Drift detection: comparar el estado actual con el estado deseado definido en código. Cuando hay divergencia, generar alerta con contexto (qué cambió, cuándo, quién lo hizo si el audit trail lo permite).

Dashboard de compliance: visualización del porcentaje de cumplimiento por framework (ENS, NIS2, CIS), por servicio, por entorno (producción, staging). Las tendencias temporales detectan degradación progresiva.

Alerting: notificaciones inmediatas para violaciones críticas (puerto SSH abierto a Internet, cifrado deshabilitado, root login permitido). Canales: Slack, email, PagerDuty, tickets automáticos.

Reporting: generación automática de informes para auditorías. Incluyen: fecha de evaluación, versión de la política, resultado por control, evidencia técnica, excepciones documentadas.

Integración en CI/CD: compliance gates

La integración en el pipeline de CI/CD convierte el compliance en una gate obligatoria antes del despliegue:

# Ejemplo: GitHub Actions con compliance gate
name: Deploy with Compliance
on: push

jobs:
  compliance-check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Terraform Plan
        run: |
          terraform init
          terraform plan -out=tfplan.binary
          terraform show -json tfplan.binary > tfplan.json

      - name: Policy Check (OPA)
        run: |
          conftest test tfplan.json \
            --policy policy/ \
            --output json > compliance-results.json

      - name: Cloud Audit (Prowler)
        run: |
          prowler aws \
            --compliance ens_rd2022_aws \
            --output-formats json \
            --status FAIL

      - name: Gate Decision
        run: |
          CRITICAL=$(jq '[.[] | select(.severity=="CRITICAL")] | length' compliance-results.json)
          if [ "$CRITICAL" -gt 0 ]; then
            echo "BLOQUEADO: $CRITICAL violaciones críticas"
            exit 1
          fi

  deploy:
    needs: compliance-check
    runs-on: ubuntu-latest
    steps:
      - name: Apply
        run: terraform apply -auto-approve tfplan.binary

Este patrón tiene dos modos de operación:

• Hard gate: el pipeline falla y el despliegue se bloquea. Adecuado para controles críticos (cifrado, acceso público).
• Soft gate: el pipeline genera warnings pero permite el despliegue. Adecuado para controles informativos o en periodo de adopción.

La transición de soft a hard gate debe ser gradual. Empezar en modo audit (solo informar), dar tiempo a los equipos para remediar, y activar el bloqueo cuando el porcentaje de cumplimiento sea alto.

Limitaciones: lo que el código no puede resolver

Compliance-as-Code no es una solución completa. Hay dimensiones del cumplimiento que requieren intervención humana:

Gobernanza y dirección: la aprobación de políticas por la dirección, la asignación de responsables de seguridad, la revisión de riesgos aceptados. Estos procesos requieren juicio humano y responsabilidad organizativa.

Formación y concienciación: verificar que el personal ha recibido formación en seguridad, que conoce las políticas, que sabe cómo reportar incidentes. Se puede automatizar el registro de asistencia, pero no la comprensión.

Seguridad física: controles de acceso a CPDs, videovigilancia, protección contra incendios, climatización. Estos controles operan en el mundo físico.

Gestión de proveedores: evaluar la seguridad de terceros, verificar sus certificaciones, auditar sus prácticas. Los cuestionarios de seguridad y las visitas de auditoría no se automatizan con OPA.

Interpretación normativa: cuando una regulación es ambigua (y lo son con frecuencia), la interpretación requiere criterio legal y técnico. El código implementa una interpretación concreta, pero alguien tiene que decidir cuál es la correcta.

Excepciones: toda organización tiene excepciones legítimas a sus políticas. Gestionar excepciones (aprobar, documentar, revisar periódicamente, revocar) requiere un proceso humano con accountability.

La recomendación práctica: automatizar lo técnico (60-70% del total), documentar lo organizativo con workflows que faciliten la generación de evidencias, y no pretender que una herramienta sustituye al CISO.

Roadmap de implementación

Para organizaciones que parten de auditorías manuales, la adopción de CaC debe ser incremental:

Fase 1: Inventario y baseline (semanas 1-4)

• Catalogar todos los controles del framework objetivo (ENS, NIS2, CIS).
• Clasificar cada control como automatizable, parcialmente automatizable o manual.
• Ejecutar un primer scan con Prowler o InSpec para establecer la baseline actual.
• Documentar el gap: porcentaje de cumplimiento real vs objetivo.

Fase 2: Políticas críticas (semanas 5-8)

• Codificar los 10-15 controles más críticos (cifrado, acceso, logging, hardening).
• Integrar en CI/CD como soft gate (solo warnings).
• Configurar dashboard con estado de cumplimiento.
• Formar al equipo en la interpretación de resultados.

Fase 3: Expansión y hard gates (semanas 9-16)

• Ampliar la cobertura al 80% de los controles automatizables.
• Activar hard gates para controles críticos ya remediados.
• Implementar drift detection con alertas.
• Generar primer informe automatizado para auditoría interna.

Fase 4: Monitorización continua (semana 17 en adelante)

• Scans programados (diarios para cloud, semanales para sistemas).
• Integración con SIEM/SOAR para correlación con eventos de seguridad.
• Revisión trimestral de políticas (actualizar con nuevas versiones de benchmarks).
• Métricas: tiempo medio de detección de drift, tiempo medio de remediación.

Recursos y referencias

Herramientas open-source:

• Open Policy Agent (OPA) con documentación completa de Rego.
• Chef InSpec con perfiles CIS predefinidos.
• Prowler para auditoría cloud multi-framework.
• ScoutSuite para evaluación multi-cloud.
• OpenSCAP con contenido SCAP para entornos regulados.
• conftest para evaluar IaC con OPA.
• CloudFormation Guard para plantillas AWS.

Frameworks y benchmarks:

• CIS Benchmarks (registro gratuito para descarga).
• CCN-STIC Guías para implementación ENS.
• NIST SP 800-53 como referencia de controles.

Lecturas recomendadas:

• "Policy as Code" (Jimmy Ray, O'Reilly, 2024): guía práctica de OPA/Rego con ejemplos reales.
• "Compliance at Velocity" (DORA State of DevOps Reports): datos empíricos sobre el impacto de la automatización de compliance en la velocidad de entrega.
• Documentación ENS RD 311/2022 y guías CCN-STIC 800 series para el contexto normativo español.