ENS nivel alto: requisitos técnicos que tu proveedor debe cumplir

Si desarrollas software para la administración pública española — o tu cliente es un organismo público — necesitas entender el Esquema Nacional de Seguridad (ENS). No como una checklist burocrática, sino como un marco técnico real que define cómo deben protegerse los sistemas de información. Y el nivel alto no perdona atajos.

El Real Decreto 311/2022 actualizó el ENS original de 2010, endureciendo requisitos y alineándolos con el panorama actual de amenazas. Para sistemas de categoría ALTA, los requisitos son exigentes y específicos. Veamos qué implica técnicamente cada uno.

Marco de medidas: qué exige el nivel alto

El ENS organiza sus medidas de seguridad en tres marcos: organizativo (org), operacional (op) y de protección (mp). Para un desarrollador o proveedor tecnológico, las medidas operacionales y de protección son las que impactan directamente en el código.

mp.com — Protección de las comunicaciones

El nivel alto exige cifrado del canal de comunicaciones con algoritmos y longitudes de clave acreditados por el CCN. Esto significa TLS 1.2 como mínimo (recomendado TLS 1.3), certificados de al menos 2048 bits RSA o equivalente en curva elíptica, y cipher suites que proporcionen forward secrecy.

Pero el ENS va más allá del transporte. La medida mp.com.3 exige protección de la información en tránsito y en reposo. No basta con HTTPS: los datos sensibles deben cifrarse a nivel de aplicación antes de almacenarse o transmitirse. Aquí es donde el cifrado de transporte (TLS) se queda corto y necesitas cifrado a nivel de dato.

<?php
// mp.com.3 — Cifrado a nivel de dato (no solo transporte)
require_once 'cuantica.php';

// Antes de almacenar en base de datos
$dni_cifrado = cuantica_cifrar($dni_paciente, $clave_maestra);
$stmt = $pdo->prepare('INSERT INTO pacientes (dni_cifrado) VALUES (?)');
$stmt->execute([$dni_cifrado]);

// Al recuperar
$stmt = $pdo->query('SELECT dni_cifrado FROM pacientes WHERE id = 1');
$dni = cuantica_descifrar($stmt->fetchColumn(), $clave_maestra);

mp.si — Protección de los soportes de información

Los soportes que contengan información del nivel alto deben estar cifrados con algoritmos acreditados. Esto incluye backups, logs, exports de bases de datos y cualquier archivo que salga del perímetro seguro. La medida mp.si.4 especifica que el borrado de soportes debe ser seguro, imposibilitando la recuperación.

En la práctica, esto significa que tus backups no pueden ser un simple mysqldump comprimido con gzip. Deben estar cifrados con algoritmos que el CCN considere adecuados, con gestión de claves documentada y trazabilidad de acceso.

op.acc — Control de acceso

El nivel alto requiere autenticación de doble factor (2FA) para todos los usuarios con acceso a información clasificada como alta. No vale solo usuario y contraseña. La medida op.acc.5 exige mecanismo de autenticación que combine al menos dos factores: algo que sabes (contraseña), algo que tienes (token TOTP, tarjeta) o algo que eres (biometría).

• op.acc.1 — Identificación: cada usuario debe tener un identificador único e intransferible
• op.acc.2 — Requisitos de acceso: control basado en roles con principio de mínimo privilegio
• op.acc.5 — Mecanismo de autenticación nivel alto: doble factor obligatorio
• op.acc.6 — Acceso local: registro de todos los accesos con marca temporal
• op.acc.7 — Acceso remoto: VPN o canal cifrado equivalente obligatorio

<?php
// op.acc.5 — Autenticación 2FA con TOTP (RFC 6238)
require_once 'umbral.php';

// Generar secreto TOTP para el usuario (una vez, al activar 2FA)
$secreto = umbral_totp_generar_secreto();
// Guardar $secreto cifrado en BD

// En cada login, verificar el código del usuario
$codigo_valido = umbral_totp_verificar($secreto, $_POST['codigo_totp']);
if (!$codigo_valido) {
    umbral_registrar_intento_fallido($usuario_id);
    die('Código 2FA inválido');
}

op.mon — Monitorización del sistema

El nivel alto exige monitorización continua con detección de intrusiones, registro de eventos de seguridad y alertas en tiempo real. La medida op.mon.1 requiere un sistema de detección de intrusiones (IDS) y la op.mon.2 un sistema de métricas que registre intentos de acceso, cambios de configuración y eventos anómalos.

Esto no significa instalar un SIEM de 50.000 euros. Un WAF bien configurado que registre y bloquee ataques, combinado con un sistema de logs estructurado, cumple con el espíritu de la norma. Lo importante es que los eventos se registren, se analicen y se actúe sobre ellos.

La cadena de suministro: tú eres responsable

El artículo 33 del ENS establece que la seguridad de los sistemas alcanza a toda la cadena de suministro. Si un organismo público de categoría alta contrata tu software, tú como proveedor heredas los requisitos. Y debes poder demostrarlo.

Esto tiene implicaciones directas: tu hosting debe estar en la UE (preferiblemente España), tu código debe implementar las medidas técnicas exigidas, y debes tener documentación de seguridad actualizada (política de seguridad, análisis de riesgos, procedimientos operativos).

Guías CCN-STIC relevantes

El Centro Criptológico Nacional publica guías técnicas que concretan los requisitos del ENS. Las más relevantes para un desarrollador web son:

• CCN-STIC-807: Criptografía de empleo en el ENS — algoritmos permitidos y longitudes de clave
• CCN-STIC-811: Interconexión en el ENS — requisitos para APIs y servicios web
• CCN-STIC-817: Gestión de ciberincidentes — procedimientos de respuesta
• CCN-STIC-221: Uso de productos criptográficos — requisitos específicos de implementación
• CCN-STIC-836: ENS en la nube — requisitos para servicios cloud

Solución práctica: stack ENS-ready

Cumplir el ENS nivel alto no requiere un equipo de 20 personas ni un presupuesto millonario. Requiere usar herramientas que ya implementen los controles técnicos exigidos. La suite PWR.es fue diseñada específicamente para este escenario:

• Cuántica: cifrado multicapa con PQC para mp.com.3 y mp.si — cifrado de datos en reposo y tránsito
• Escudo: WAF PHP nativo para op.mon y mp.com — detección y bloqueo de ataques web
• Umbral: autenticación 2FA TOTP para op.acc.5 — doble factor sin dependencias externas
• Refugio: backups cifrados para mp.si — copias de seguridad con cifrado multicapa
• Vigía: escáner de seguridad para op.mon — auditoría continua de vulnerabilidades
• Norma: cumplimiento RGPD para mp.info — gestión de datos personales conforme a la ley

Todo en PHP nativo, sin Composer, sin dependencias externas, sin servicios cloud americanos. Servidor en España, código auditable, y cada componente mapea directamente a una o varias medidas del ENS. Es el stack que usamos en nuestro propio servidor, certificado ENS nivel alto.

Errores comunes que invalidan tu cumplimiento

Hemos auditado decenas de proyectos que 'cumplen el ENS' sobre el papel. Estos son los fallos técnicos más frecuentes que encontramos:

• Usar md5() o sha1() para hash de contraseñas — el ENS exige bcrypt, scrypt o Argon2
• Backups sin cifrar en el mismo servidor — viola mp.si.3 y mp.si.4
• Logs que contienen datos personales en texto claro — viola mp.info y RGPD simultáneamente
• 2FA implementado solo con SMS — no se considera seguro desde 2023 (NIST SP 800-63B)
• Hosting en AWS/Azure sin contrato ENS específico — la responsabilidad recae en ti
• APIs sin rate limiting ni autenticación robusta — viola op.acc y op.mon

El ENS no es un sello que compras. Es un conjunto de medidas técnicas que debes implementar, mantener y poder demostrar. Si tu proveedor no puede explicarte exactamente cómo cumple cada medida, probablemente no las cumple.