Noust y el Esquema Nacional de Seguridad (categoría MEDIA)

English summary

This document is for organisations subject to Spain's Esquema Nacional de Seguridad (ENS, Real Decreto 311/2022), category MEDIUM, that use Noust to run their servers. It is written in Spanish because its readers are Spanish auditors and security officers.

• Noust is a component, not a certified system. An ENS certificate is issued to the organisation's information system; Noust is not in the CCN's CPSTIC catalogue. What Noust does is enforce what a component can enforce and produce the evidence an auditor asks for.
• Compliance is chosen, never the default (4.0). Every control is a switch of its own and frameworks are presets over them: ENS BÁSICA, MEDIA and ALTA are three, beside ISO/IEC 27001, NIS2, CIS Controls v8, SOC 2 and GDPR art. 32, and several can be on together (each control takes the strictest value any asks). Nothing is on until it is chosen: noust compliance enable ens-media. COMPLIANCE.md is generated from the one table that says which control each framework turns on and the clause it serves, and lists what stays organisational.
• security.profile: ens-medium (and any spelling of it) keeps working and means ENS MEDIA is enabled. It fixes, in one place every area reads (noust.core.compliance), the values category MEDIUM expects: 15-minute idle lock and 8-hour sessions, lockout after 5 failures, 14-character passwords, 90-day API tokens, a 365-day audit retention, four-eyes approvals, a --reason for every CLI change, the master token restricted to account recovery, backups encrypted before they leave, an operator TLS certificate for the console, and the roles split: an admin does not govern accounts, security settings or the audit trail (outside it, one admin does everything, so one person needs one account). Turn it on with noust compliance enable ens-media or noust config set security.profile ens-medium.
• noust ens check compares the server with the profile, check by check, each mapped to its RD 311/2022 measure, and exits 0/1/2 like a monitoring check. noust ens report writes the evidence bundle (JSON and Markdown, hashed). The console shows both under Settings > ENS report (GET /api/ens/check, GET /api/ens/report).
• Evidence commands: noust audit verify|review|export, noust ens access-review, noust ens inventory, noust backup verify, noust central backup, noust incident freeze.
• What stays the organisation's (policy, roles and their appointment, risk analysis, personnel, facilities, providers, the SIEM, the incident process) is listed in section 7.

0. Alcance y límites

Este documento responde, medida a medida del Anexo II del RD 311/2022, a tres preguntas del auditor: qué hace Noust, qué tiene que hacer la organización y con qué evidencia se demuestra.

• Noust es un componente de administración con capacidad de root sobre los servidores que gestiona: despliega código (desplegar es ejecutar código), escribe unidades de systemd y configuración de nginx o Apache, gestiona certificados, bases de datos y copias. Quien controla Noust controla esos servidores. El sistema de información que se certifica es el de la organización; Noust es una pieza dentro de él.
• Noust no figura en el CPSTIC ni está certificado (op.pl.5). La organización debe justificarlo en su análisis de riesgos como componente de administración y no como producto de la arquitectura de seguridad; si el auditor lo cataloga como tal, la Declaración de Aplicabilidad recoge la medida compensatoria (art. 28.3): este documento, el SBOM de cada versión, el código abierto (AGPL-3.0), las pruebas publicadas en CI y SECURITY.md.
• Los números no los fija el RD: los fija la política de la organización (op.acc.6.4, mp.eq.2.1 "tiempo prudencial", op.exp.8.r3.1). Los valores del perfil son valores por defecto razonables; la organización puede endurecerlos, nunca relajarlos con el perfil activo.
• La numeración es la del RD 311/2022; la concordancia con la del RD 3/2010 (y la CCN-STIC 804 de 2017) está en el Anexo A. Las referencias a guías CCN-STIC marcadas [verificar] deben contrastarse con la edición vigente antes de citarse en un informe (ver sección 8).

1. Responsabilidad compartida

2. El marco ENS MEDIA (ens-medium)

noust compliance enable ens-media              # muestra qué cambia y la medida de cada control
noust compliance check --framework ens-media   # control a control, con la medida de cada hallazgo
noust config set security.profile ens-medium   # el ajuste de siempre: significa «ENS MEDIA activo»
noust ens profile                               # qué fija el perfil y cuál está activo

Desde la 4.0 el cumplimiento es elegido, nunca el valor por defecto. Cada control (aprobación por cuatro ojos, un motivo por cambio, separación de funciones, límites de sesión, cifrado de copias...) tiene su propio ajuste, y un marco es un preajuste que activa los controles que ayudan con una norma y dice la cláusula que sirve cada uno. ENS MEDIA es exactamente lo que fue siempre el perfil ens-medium; ENS BÁSICA y ENS ALTA son los otros dos niveles, con las medidas del Anexo II que se aplican a cada categoría. Se pueden activar varios a la vez (ENS junto con ISO 27001 es habitual): cada control toma el valor más estricto que pida cualquiera, y se puede endurecer más, nunca relajar por debajo de un marco activo. La tabla que dice qué activa cada marco, y la lista de lo que sigue siendo organizativo, está en COMPLIANCE.md; un marco no hace que el sistema «cumpla»: activa controles técnicos.

El marco no es un interruptor de funciones: es un conjunto de valores y de rechazos definido en un único módulo (src/noust/core/compliance/frameworks.py) que leen el inicio de sesión, la CLI, las aprobaciones, la auditoría, las copias y noust ens check. Un nombre mal escrito en security.profile se interpreta como ens-medium (falla hacia lo estricto). Activarlo o desactivarlo queda en la auditoría (security.framework.change); desactivar un marco, o relajar un control, pide el modo sudo.

Lo que no es un control y es igual con cualquier perfil: el modo sudo mismo («Confirma que eres tú» antes de una acción destructiva), que nadie cambia ni se eleva su propia cuenta (cambiar el propio rol, desactivarse, borrarse, restablecer el propio segundo factor lo hace otra persona administradora o root), y el segundo factor que cada cuenta registra.

Ajustes de seguridad relacionados que no dependen del perfil:

• security.allowed_sources: orígenes de código permitidos (hosts, organizaciones o repositorios, y local, push, upload y recipes para directorios del servidor, git push, archivos subidos y recetas del catálogo). Vacío permite todo. Se comprueba donde se clasifica cualquier fuente antes de descargarla, así que afecta a despliegues, actualizaciones, previews y webhooks; un rechazo queda como apps.source.denied. Lo cambia el rol security.
• auth.notice.text: aviso de derechos y obligaciones que cada persona acepta tras entrar (op.acc.6.2, op.acc.6.9, mp.per.2.r1); cambiar el texto obliga a aceptarlo de nuevo.
• audit.syslog, audit.journald, audit.enterprise_id: destinos de la auditoría (RFC 5424 por UDP, TCP o TLS con certificado de cliente; journald).

3. Matriz de cumplimiento

Columnas: medida | requisito (con los refuerzos que aplican a MEDIA) | cómo lo cumple Noust | responsabilidad del operador | hueco residual. "N.A." indica que no aplica a MEDIA o a este tipo de componente.

3.1 Marco organizativo

3.2 Planificación (op.pl)

3.3 Control de acceso (op.acc)

3.4 Explotación (op.exp)

3.5 Servicios externos, nube y continuidad

3.6 Monitorización (op.mon)

3.7 Medidas de protección (mp)

4. Evidencias: qué pedir y cómo obtenerlo

4.1 noust ens check

noust ens check            # los fallos y avisos, con evidencia y qué hacer; código 0, 1 o 2
noust ens check --all      # también lo que pasa
noust ens check --json     # para un sistema de monitorización
noust ens report           # paquete de evidencias (JSON, Markdown y SHA256SUMS)

Un área que no se puede leer (por ejemplo, sin permisos de root) aparece como aviso con el error literal: nunca como aprobado.

4.2 Tabla de evidencias

5. Guía de bastionado

5.1 Arquitectura de referencia

             zona de gestión de la organización (VLAN/VPN)
  ┌─────────────────────────────────────────────────────────────┐
  │  personas (navegador) ──TLS──> CENTRAL (consola 8443)        │
  │                                  │   │    │                  │
  │           SIEM <──syslog TLS─────┘   │    └── NTP autenticado │
  │   destino de copias <──rclone crypt──┘                        │
  └──────────────────────────────────│──────────────────────────┘
                                     │ SSH saliente (túnel, cuenta noust-tunnel)
                ┌────────────────────┼────────────────────┐
             NODO 1               NODO 2               NODO n
       (consola en loopback)  (consola en loopback)  (consola en loopback)

Flujos autorizados (mp.com.1.2, op.ext.4.2):

Riesgos propios de Noust para el análisis de riesgos (op.pl.1): robo del acceso a la central (controla la flota); un repositorio hostil (desplegar es ejecutar código: por eso el sandbox y los orígenes permitidos); un administrador malicioso (por eso los cuatro ojos y el envío de la auditoría fuera); pérdida de la passphrase de sellado o del respaldo de la central (no hay recuperación).

5.2 La central de una empresa vive en la infraestructura de la empresa

La central guarda las claves de toda la flota y, con ellas, un atacante despliega código en todos los servidores. Por eso las medidas de instalaciones (mp.if.1 a mp.if.7), continuidad (op.cont.1), copias (mp.info.6) y reloj (op.exp.8.r2) se aplican al equipo que la aloja. Un NAS doméstico o el portátil de un administrador incumplen mp.if.1 a mp.if.7. Requisitos mínimos:

• CPD o sala de la organización con control de acceso y registro de entradas, o un proveedor con certificado ENS de categoría MEDIA o superior (op.nub.1).
• SAI, reloj sincronizado con NTP (NTS si está disponible) y red de gestión separada.
• Certificado TLS de la PKI de la organización (NOUST_TLS_CERT, NOUST_TLS_KEY), no el autofirmado; NOUST_ALLOW_IP limitado a la red de gestión.
• Secretos sellados (noust central seal) con la passphrase custodiada por el responsable de seguridad, fuera del equipo.
• Copia cifrada diaria o semanal (noust central backup) guardada fuera de sitio, con su passphrase custodiada aparte, y verificada mensualmente (--verify).
• Una central de preproducción para probar cada actualización de Noust antes de la de producción.
• El perfil ens-medium activo en la propia central cuando gestiona nodos que lo tienen. El modo sudo se confirma en la central: esta pregunta a su operador y responde de ello al nodo (X-Noust-Elevated), y el nodo lo acepta sin aplicar a esa llamada su propia política de modo sudo, tampoco la del perfil (contraseña y código, 10 min tras la última acción, 30 como máximo). La política que rige lo que se hace desde la central es, por tanto, la de la central.

5.3 Puesta en marcha (día 0)

1. Instalar desde el repositorio firmado de OBS o PyPI; anotar la versión y su SBOM.
2. noust web enable --tls-cert <fullchain> --tls-key <clave> --allow-ip <red de gestión> (en una central: NOUST_TLS_CERT, NOUST_TLS_KEY, NOUST_ALLOW_IP).
3. Crear la primera cuenta security y la primera admin (noust user create, o invitaciones con noust user invite); cada persona enrola su segundo factor al entrar.
4. noust config set security.profile ens-medium.
5. noust config set auth.notice.text '<aviso de derechos y obligaciones>'.
6. Configurar el envío de la auditoría: audit.syslog hacia el SIEM (TLS) y audit.enterprise_id con el PEN de la organización.
7. noust config set security.allowed_sources '[github.com/<organización>]'.
8. Destinos de copia cifrados (noust backup destination add ... --encrypt) y calendarios con destino (noust backup schedule create <dominio> --schedule daily --destination <nombre>); guardar las claves con show-key fuera del servidor.
9. Sandbox en cada aplicación (noust app sandbox test, enable) y bastionado (noust server security checks: corregir o aceptar el riesgo con motivo y fecha).
10. En una central: noust central seal; nodos con la cuenta de túnel y el techo adecuado.
11. Inventario: noust ens inventory set <dominio> --owner ... --criticality ... --classification ....
12. noust ens check en verde (o con avisos justificados) y noust ens report como línea base.

5.4 Identidad y acceso

Roles y correspondencia con el ENS (una cuenta, un rol; op.acc.1.2):

Incompatibles para una misma persona: admin/operator con security; auditor con cualquier otro. Con un único responsable de seguridad (instalaciones pequeñas), la excepción se documenta con motivo y caducidad (noust user exception add) y aparece en el informe (art. 13.3).

Alta: invitación de un solo uso con caducidad (noust user invite); la persona fija su contraseña, enrola el segundo factor y acepta el aviso. Nadie recibe contraseñas por correo.

Baja: noust user disable <usuario> --reason ... revoca de inmediato sesiones y tokens; la cuenta se conserva durante la retención de la auditoría (op.acc.1.4).

Revisión trimestral (op.acc.4.4): noust ens access-review list, comprobar cada cuenta contra la lista de personas autorizadas, corregir y noust ens access-review attest --notes '...'.

Reactivación de una cuenta bloqueada (op.acc.6.8 exige describirla): tras 5 fallos consecutivos la cuenta queda bloqueada. El responsable de seguridad (1) comprueba en la auditoría el origen de los fallos (noust audit list --action auth.login --result failure), (2) contacta con la persona por un canal distinto, (3) si hay sospecha de compromiso, restablece el segundo factor (noust user reset-mfa) y abre un incidente, y (4) desbloquea con noust user unlock <usuario> --reason "<ticket>", que queda auditado.

Token maestro (break-glass): con cuentas creadas y el perfil activo solo sirve para recuperar el acceso de una persona. Se guarda en sobre cerrado o caja fuerte bajo custodia del responsable de seguridad; cada uso genera auth.break_glass (crítico) y una notificación; tras usarlo se rota (noust web token --regenerate) y se documenta el motivo. noust ens check (ENS-ACC-03) avisa de cualquier uso en 30 días.

Tokens de API: siempre con dueño y caducidad (noust token create <nombre> --owner <cuenta> --expires-hours 2160); nunca con más permisos que su dueño.

5.5 Registro de la actividad

• Catálogo de eventos auditados (op.exp.8.r3.1): noust audit events --markdown genera la tabla completa con categoría y severidad syslog.
• Formato: JSON por línea con actor (persona, rol, canal), fecha UTC, objeto, acción, resultado e id de correlación; cadena HMAC-SHA256 con clave propia (audit-key, 0600).
• Integridad: noust audit verify comprueba la cadena. Límite: root en la máquina puede recalcularla con la clave local; la garantía es el envío en tiempo real a un SIEM, donde una reescritura local se ve como discontinuidad frente a los audit.checkpoint recibidos.
• Retención: 365 días como mínimo en el perfil; nada se purga sin haberse enviado.
• Revisión semanal (op.exp.8.r1): noust audit review --from ... --to ... --notes '...' deja el evento audit.review con la verificación de la cadena.
• Reloj (op.exp.8.r2): ENS-LOG-04; los mensajes syslog llevan timeQuality.
• Casos de uso para el SIEM: fuerza bruta (auth.login fallidos por IP), auth.lockout, auth.break_glass, user.role_change, config.change en secciones de seguridad, security.profile.change, fleet.node.add, fleet.tunnel.hostkey_changed, borrados masivos (apps.delete, db.drop), host.exec fuera de horario, audit.gap, audit.degraded, audit.sink.degraded, apps.source.denied, incident.freeze, incident.lockdown.

5.6 Criptografía y claves

La pérdida de la passphrase de sellado o de la del respaldo de la central no tiene recuperación: custodia por el responsable de seguridad en dos lugares distintos.

5.7 Cambios y despliegues

• Repositorios protegidos (rama principal protegida, revisión obligatoria, commits firmados) en la forja de la organización; security.allowed_sources limitado a ellos.
• Cada orden de la CLI que cambia algo lleva --reason "<referencia de cambio>"; los despliegues desde la consola quedan con su actor, commit y disparador. Las que ejecutan las unidades, los temporizadores y los scripts de los paquetes (web start, monitor run, central run, backup run-schedule, preview sweep, config upgrade, monitor install...) no lo necesitan: quedan auditadas igual, con entry_point en el detalle y, bajo systemd, el actor system.
• Acciones equivalentes a root, altas y bajas de nodos y cambios de rol: aprobación de otra persona (noust approval list, approve).
• HealthGate como prueba de aceptación automática y vuelta atrás en segundos; previews para probar antes de producción.
• Actualizar Noust: desde el repositorio firmado; primero en la central de preproducción; revisar el changelog y UPGRADING-*.md; ventana de cambio; noust ens check después.

5.8 Copias y continuidad

• Copias de aplicación diarias con destino cifrado fuera del servidor; la verificación profunda semanal es automática y queda registrada (backups.verify); noust backup verify bajo demanda.
• Prueba de restauración completa (con la base de datos) al menos trimestral en un nodo de prueba, documentada.
• Central: noust central backup (fichero cifrado con manifiesto SHA-256); --verify mensual; restauración: noust central backup --decrypt <fichero> --to <archivo.tar.gz>, extraer sobre un directorio de datos vacío y arrancar la central. Definir RTO y RPO en el análisis de impacto.

5.9 Monitorización e incidentes

• noust monitor informa (no mata procesos); las comprobaciones de bastionado cubren SSH, cortafuegos, fail2ban, parches, reloj y fin de vida del SO; la organización aporta IDS/EDR y auditd.
• Procedimiento ante un incidente: (1) noust incident freeze --reason "<id del incidente>" (paquete de evidencias y bloqueo de la consola; --revoke-sessions si hay sesiones sospechosas); (2) copiar el paquete fuera del servidor y anotar el SHA-256 del manifiesto, que ya consta en la auditoría enviada; (3) si una central está comprometida, revocarla en cada nodo (noust fleet deauthorize); (4) notificar según el art. 33 (CCN-CERT, o INCIBE-CERT en el sector privado); (5) al cerrar, noust incident unfreeze --reason "..." y rotar credenciales.

5.10 Datos personales (mp.info.1)

Noust guarda nombre de usuario, nombre visible y referencia de persona (habitualmente el correo) de cada cuenta, y direcciones IP y acciones en la auditoría y las sesiones. Retención configurable (audit.retention_days, retention.sessions_days, retention.jobs_days, retention.deployments_days); las cuentas dadas de baja se conservan durante la retención de la auditoría. La base jurídica y los plazos son de la organización.

5.11 Calendario operativo

6. Qué entregar al auditor

• noust ens report (JSON y Markdown con su SHA256SUMS), y su hash en la auditoría.
• La salida de noust audit verify y la comparación de su cabeza con la del SIEM.
• Las atestaciones de revisión de accesos y de auditoría (noust audit list --action access.review, --action audit.review).
• El inventario (noust ens inventory list --format csv).
• El SBOM de la versión instalada.
• Los documentos de la organización: política (art. 12), normativa, procedimientos, análisis de riesgos, Declaración de Aplicabilidad (art. 28.2), plan de auditorías, informe de auditoría bienal (art. 31) y, en su caso, certificado de conformidad (art. 38).

7. Lo que sigue siendo de la organización

• Aprobar la política de seguridad y designar RINF, RSERV, RSEG y RSIS (org.1, art. 13).
• Normativa de uso, procedimientos y su aplicación (org.2, org.3); formación y concienciación (mp.per).
• Análisis de riesgos, arquitectura, capacidad y adquisición (op.pl); justificar el uso de un componente no incluido en el CPSTIC (op.pl.5).
• Lista de personas autorizadas, altas, bajas y revisión (op.acc.1, op.acc.4.4); custodia del token maestro y de las passphrases.
• Bastionado del sistema operativo según la guía CCN-STIC aplicable, antimalware/EDR, IDS/IPS, auditd (op.exp.2, op.exp.6, op.mon.1).
• SIEM, correlación y revisión (op.mon.3, op.exp.8.r1); NTP autenticado.
• Gestión y notificación de incidentes (op.exp.7, art. 33).
• Instalaciones, equipos, soportes y proveedores (mp.if, mp.eq, mp.si.3-5, op.ext, op.nub).
• Pruebas de penetración de la consola y de las aplicaciones (mp.s.2.r1).
• Desarrollo seguro de sus aplicaciones y datos de prueba no reales (mp.sw.1).

8. Huecos residuales y verificaciones pendientes

• CPSTIC (op.pl.5): no cerrable en código.
• Algoritmos: el estado frente a CCN-STIC 807 y 221 de Ed25519, HMAC-SHA1 en OTP, scrypt, AES-CBC, rclone crypt y la construcción del cifrado de TOTP debe verificarse en las ediciones vigentes (no pudieron leerse al redactar este documento). Alternativas disponibles: passkeys en lugar de TOTP; certificados ECDSA P-384 o RSA de 3072 bits del operador.
• PEN de IANA: audit.enterprise_id usa por defecto 32473 (reservado para documentación); la organización debe poner el suyo.
• Sin firma propia de artefactos (sigstore/cosign) ni DAST en CI; sin campos de inventario por nodo; la verificación programada de copias no restaura la base de datos en un motor de prueba.
• La cadena de auditoría local la puede recalcular root: el envío a un SIEM es la garantía.

Guías del CCN a citar (verificar la edición vigente): CCN-STIC 801, 802, 803, 804, 807, 808, 809, 817, 823 y 221; perfiles de cumplimiento 890 y 892.

Anexo A. Concordancia de numeración (RD 3/2010 frente al RD 311/2022)

Anexo B. Procedimientos plantilla

Alta de una persona. Solicitud aprobada por el responsable del servicio → el responsable de seguridad invita (noust user invite <usuario> --role <rol>) → la persona activa la cuenta (contraseña, segundo factor, aviso) → se anota en la lista de personas autorizadas.

Baja. Comunicación de RR. HH. o del responsable → noust user disable <usuario> --reason "<ticket>" el mismo día → revisión de tokens de esa cuenta → anotación en la lista.

Reactivación de cuenta bloqueada. Ver 5.4.

Uso del token maestro. Dos personas presentes; apertura del sobre; motivo en el ticket; uso; rotación inmediata (noust web token --regenerate); nuevo sobre; revisión del evento auth.break_glass.

Restauración de la central. Ver 5.8; prueba anual documentada.

Rotación de claves de nodo. noust node rekey <nodo> y el código que imprime, ejecutado en el nodo; comprobación con noust node test <nodo>.

Incidente. Ver 5.9.

Anexo C. Lo que preguntará el auditor

• ¿Quién puede entrar en la consola y con qué rol? → noust ens access-review list.
• ¿Cuándo se revisaron los accesos por última vez y quién? → evento access.review.
• ¿Los registros son íntegros y salen de la máquina? → noust audit verify, noust audit status, SIEM.
• ¿Cuánto tiempo se guardan? → audit.retention_days (365).
• ¿Hay doble factor para todos? → ENS-ACC-02.
• ¿Cómo se autoriza un cambio y cómo se referencia? → --reason, aprobaciones, auditoría.
• ¿Se prueban las copias? → backups.verify semanales, prueba de restauración trimestral.
• ¿Dónde está la central y quién tiene acceso físico? → sección 5.2, documentos de la organización.
• ¿Qué hace el token maestro y dónde está? → sección 5.4.
• ¿Qué versión de Noust se usa y qué contiene? → noust --version, SBOM de la release.