Marco operacional del ENS: planificación, accesos y monitorización

Si el marco organizativo del ENS define quién manda, el marco operacional define cómo se opera la seguridad cada día: cómo se planifica, quién accede a qué, cómo se explota el sistema, qué se exige a los proveedores, cómo se protege el cloud, qué pasa cuando todo falla y cómo se vigila que nada de lo anterior se degrade. Es el bloque más grande del Anexo II y donde el auditor de conformidad pasa más horas — porque es donde se ve si el sistema vive o solo está escrito. Operar esto a diario forma parte de nuestros servicios de seguridad informática.

Tercer capítulo de nuestra serie sobre el Esquema Nacional de Seguridad, tras el marco organizativo. Recorremos las siete familias op.* con la traducción práctica para un proveedor tecnológico: qué exige cada una, cómo se implementa en un stack moderno y qué evidencias piden en la auditoría.

1. El marco operacional en el mapa del ENS

De las 73 medidas del Anexo II del RD 311/2022, el marco operacional agrupa el bloque central en siete familias: planificación (op.pl), control de acceso (op.acc), explotación (op.exp), recursos externos (op.ext), servicios en la nube (op.nub), continuidad del servicio (op.cont) y monitorización (op.mon). La intensidad de cada medida depende de la categoría del sistema — básica, media o alta — que definiste al categorizar (lo vimos en la guía central). En categoría media, que es donde vive la mayoría de servicios al sector público, prácticamente todas las familias aplican con refuerzos.

Si vienes de la serie ISO 27001, reconocerás el terreno: este marco solapa en gran medida con los controles técnicos del Anexo A. La diferencia de estilo se mantiene: el ENS concreta más y deja menos margen — lo que para un equipo técnico suele ser una ventaja.

2. op.pl — Planificación: la seguridad se diseña

Cuatro ideas fuerza: análisis de riesgos proporcional a la categoría (en básica basta un análisis informal; en media, semiformal y documentado; en alta, formal con metodología reconocida — MAGERIT es la referencia natural, y todo lo que contamos en la guía de análisis de riesgos aplica directo), arquitectura de seguridad documentada (diagramas, perímetros, flujos — tu documentación de arquitectura de siempre, con capa de seguridad explícita), adquisición de nuevos componentes con requisitos de seguridad desde la compra, y dimensionamiento de capacidades para que el sistema aguante lo que el servicio promete.

Para un equipo que ya trabaja con diagramas versionados e infraestructura como código, esta familia es sobre todo un ejercicio de formalización: poner por escrito decisiones que ya tomas bien.

3. op.acc — Control de acceso: la familia más auditada

El corazón operativo del esquema, y donde más no conformidades caen. Sus medidas encadenadas:

• Identificación única: cada usuario, una identidad; nada de cuentas compartidas. Las cuentas de servicio, inventariadas y con dueño.
• Requisitos y gestión de derechos: mínimo privilegio y need-to-know; los permisos se conceden por proceso (con registro), se revisan periódicamente y se revocan al instante en las bajas — el enganche con el marco organizativo y sus procedimientos.
• Segregación de funciones: quien desarrolla no aprueba su propio paso a producción; quien opera no se audita a sí mismo. En equipos pequeños, compensaciones documentadas (revisión por pares, aprobaciones cruzadas).
• Mecanismo de autenticación: aquí el ENS aprieta por categoría. En media, el doble factor es exigible para accesos remotos y privilegiados; en alta, generalizado y con factores robustos. Passkeys/FIDO2 para roles críticos es la implementación 2026 sensata.
• Acceso local y remoto: el remoto siempre por canal cifrado (VPN o equivalente Zero Trust) y con registro.

Evidencias estrella en auditoría: la matriz de roles, las dos últimas revisiones de accesos con acta, la configuración MFA del proveedor de identidad y una baja reciente trazada de punta a punta. Preparar estas evidencias es el objetivo de un proyecto de cumplimiento del ENS e ISO 27001.

4. op.exp — Explotación: la disciplina diaria

La familia más extensa: es la operación del sistema. Sus piezas, en versión proveedor tecnológico:

• Inventario de activos: qué hay, de quién es y qué categoría tiene. Vivo, no un Excel de 2023.
• Configuración de seguridad: línea base endurecida (hardening) y gestión de la configuración — si usas Terraform/Ansible/Docker, ya la tienes versionada; documenta la línea base y las excepciones.
• Mantenimiento y parcheo: plazos por severidad, registro de aplicación y excepciones justificadas. La medida que más protege contra lo que vemos a diario en incidentes de ransomware.
• Gestión de cambios: tu flujo PR → revisión → despliegue ES la medida; asegura rastro también para cambios de emergencia.
• Protección frente a código dañino: EDR/antimalware en endpoints y servidores donde aplique, más las protecciones de la plataforma.
• Gestión de incidentes: procedimiento, registro y —clave en el ENS— notificación: los incidentes significativos se comunican (el sector público al CCN-CERT; tú a tu cliente según contrato, con la guía CCN-STIC 817 como referencia de clasificación).
• Registro de actividad (trazas): qué se registra, cuánto se retiene y —medida propia con nombre— la protección de los registros: los logs no los edita ni borra quien opera. Recuerda que la trazabilidad es dimensión de primera clase en el ENS.
• Protección de claves criptográficas: ciclo de vida de claves y secretos — gestor de secretos, rotación, custodia.

5. op.ext — Recursos externos: la cadena de suministro

Si subcontratas parte del servicio (hosting, un SOC, desarrollo externo), esta familia te obliga a que la seguridad viaje por el contrato: requisitos de seguridad en la contratación, gestión y seguimiento diario del proveedor (SLAs, incidentes, revisiones) y condiciones para la interconexión de sistemas. Como proveedor del sector público eres, a la vez, el eslabón vigilado y el que debe vigilar a los suyos — la matriz de responsabilidades que recomendamos en el capítulo organizativo se convierte aquí en tu mejor herramienta.

6. op.nub — Cloud: el recién llegado que ya manda

Novedad de peso del RD 311/2022: condiciones específicas para servicios en la nube. La lógica es de responsabilidad compartida: el proveedor cloud acredita su parte (los grandes hyperscalers disponen de certificaciones ENS para muchos de sus servicios — pídelas y archívalas como evidencia) y tú documentas y proteges la tuya: configuración segura, cifrado, gestión de identidades, trazabilidad sobre esa infraestructura. El error a evitar: «está en AWS/Azure, ya es seguro». La herencia de controles hay que documentarla, no invocarla.

7. op.cont — Continuidad: planes que se ensayan

Tres escalones según categoría: análisis de impacto (qué servicios soportan qué y cuánto tiempo pueden estar caídos — RTO/RPO firmados con el cliente), plan de continuidad (cómo se recupera: backups, redundancia, procedimientos) y pruebas periódicas del plan. El ENS no acepta continuidad de papel: sin evidencia de ensayo (restauraciones probadas, simulacros con acta), la medida no está implantada. La regla del backup probado que repetimos en toda la serie, aquí es literalmente obligatoria.

8. op.mon — Monitorización: vigilancia continua

Cierra el marco la familia que materializa el principio de vigilancia continua: detección de intrusiones (IDS/WAF/EDR según superficie), sistema de métricas (indicadores de seguridad recogidos de forma sistemática: incidentes, parcheo, disponibilidad — los mismos que alimentarán el informe INES de tu cliente) y vigilancia propiamente dicha: alguien —o algo con alertas bien afinadas— mira lo que pasa y reacciona. Para una plataforma web típica: logs centralizados, alertas accionables sobre eventos que importan y revisión periódica pautada. Sin teatro: tres alertas útiles valen más que un dashboard de cuarenta paneles que nadie abre.

9. Caso aterrizado: el marco operacional de un SaaS en cloud

Cómo se ve todo lo anterior implementado en un proveedor tipo (SaaS de 20 personas, categoría media, plataforma en un hyperscaler):

• op.pl: análisis de riesgos semiformal (matriz 5×5, 32 riesgos) revisado al año; diagramas de arquitectura en el repositorio con capa de seguridad; checklist de seguridad en la plantilla de compra de servicios.
• op.acc: SSO corporativo con MFA obligatorio (passkeys en roles privilegiados), acceso a producción por roles temporales con aprobación, revisión trimestral de accesos como issue recurrente con acta.
• op.exp: inventario en el propio IaC + CMDB ligera; hardening como código; parcheo con SLA interno (crítico 72h); cambios por PR con excepción de emergencia trazada; EDR en endpoints; incidentes por playbook con plantilla de notificación al cliente; logs a un bucket con retención inmutable de 12 meses y acceso segregado; secretos en gestor con rotación.
• op.ext: tres subcontratas relevantes con anexo de seguridad firmado y revisión semestral documentada.
• op.nub: carpeta de evidencias con las certificaciones ENS/ISO del hyperscaler + revisión trimestral de configuración (herramienta CSPM del propio cloud).
• op.cont: BIA de una página firmado con el cliente (RTO 8h / RPO 24h), backups 3-2-1 con copia inmutable y restauración de prueba trimestral cronometrada.
• op.mon: logs centralizados, 7 alertas accionables (logins anómalos, picos de error, cambios de configuración, caídas), guardia informal en horario extendido y revisión semanal de métricas de 20 minutos.

Nada exótico: herramientas que ya usaban, con formalización y rastro. Ese es el listón real del marco operacional en categoría media.

10. Mini-FAQ del marco operacional

¿Necesito un SOC 24/7 para cumplir op.mon en categoría media?

No. Necesitas vigilancia proporcional: alertas bien definidas que alguien atiende con tiempos razonables, y capacidad de reacción documentada. Un SOC externo puede ser la respuesta si tu servicio exige respuesta nocturna garantizada — entonces entra por op.ext con su contrato.

¿El doble factor es obligatorio sí o sí?

Depende de categoría y tipo de acceso: en media es exigible para accesos remotos y cuentas privilegiadas; en alta se generaliza. En la práctica de 2026, poner MFA universal cuesta tan poco que la pregunta correcta es por qué no.

¿Cuánta retención de logs pide el ENS?

No fija un número universal: pide definirla según la categoría y necesidades de investigación, protegerla y cumplirla. La práctica común en categoría media ronda 6-12 meses para trazas de seguridad — y lo que definas, cúmplelo: una retención declarada de 12 meses con logs de 3 es no conformidad.

¿Puedo apoyarme en las herramientas del CCN?

Las guías CCN-STIC 800 son oro y públicas. Las herramientas (PILAR, CLARA, LUCIA) están orientadas al sector público; como proveedor privado puedes usar PILAR con licencia y CLARA para revisar configuraciones Windows, pero tu stack habitual (CSPM del cloud, escáneres, SIEM ligero) cumple igual si genera evidencia.

11. La auditoría del marco operacional: qué muestrea

• «Enséñame el análisis de riesgos vigente y quién lo aprobó» — op.pl, con fecha y firma.
• «Un acceso privilegiado concedido este trimestre: proceso completo» — op.acc, del ticket a la revocación.
• «La última vulnerabilidad crítica: cuándo se conoció, cuándo se parcheó» — op.exp, contra tus propios plazos.
• «El último incidente notificado a vuestro cliente público» — op.exp, con tiempos y contenido de la notificación.
• «El contrato con vuestro hosting: cláusulas de seguridad» — op.ext.
• «Certificación ENS/ISO de vuestro proveedor cloud y vuestra configuración» — op.nub, herencia documentada.
• «Acta de la última prueba de restauración y tiempo obtenido» — op.cont.
• «¿Quién miró ayer las alertas? Enséñame una gestionada» — op.mon.

El patrón de siempre: evidencia o no existe. Y el muestreo es aleatorio — la consistencia general es lo único que sobrevive.

12. Errores típicos del marco operacional

• El MFA a medias: activado en el correo, ausente en el panel cloud o el SSH. El auditor va directo a los accesos que importan.
• Logs sin protección: registro exhaustivo que el propio administrador puede editar. La protección de trazas es medida con nombre propio; resolverla (retención inmutable, permisos separados) es barato y puntúa mucho.
• Continuidad sin ensayo: el plan existe, la prueba no. Directo a no conformidad.
• El proveedor invisible: subcontratas relevantes sin requisitos contractuales ni seguimiento. op.ext es de las familias que más crecen en hallazgos.
• Herencia cloud invocada, no documentada: «eso lo cubre AWS» sin papel que lo acredite ni configuración propia revisada.
• Métricas decorativas: un dashboard bonito sin revisión pautada ni decisiones derivadas. La vigilancia continua exige bucle: mirar → detectar → actuar → registrar.

13. Integrarlo sin fricción: el marco operacional en el flujo del equipo

El riesgo de este marco no es técnico, es de sostenibilidad: si las medidas viven fuera de las herramientas del equipo, se abandonan en tres meses. Las integraciones que funcionan:

• Las revisiones periódicas, como issues recurrentes en tu gestor (accesos trimestral, configuración cloud trimestral, restauración de backup, revisión de proveedores semestral). El cierre de la issue con su checklist ES el acta — evidencia sin esfuerzo extra.
• El parcheo, dentro del flujo de dependencias que ya tienes (renovate/dependabot + ventana mensual de sistema). El SLA por severidad se documenta una vez y el histórico del repositorio lo evidencia solo.
• Los cambios de emergencia, con etiqueta propia: mismo flujo de PR acelerado + revisión a posteriori registrada. Así el «hotfix del viernes noche» no rompe la gestión de cambios.
• Las alertas, pocas y con dueño: cada alerta de op.mon tiene un canal, un responsable de primera mirada y una pauta de escalado. Alerta sin dueño = ruido que acaba silenciado.
• La notificación de incidentes, con plantilla precargada: a quién, en qué plazo y con qué campos, acordado en frío con cada cliente público. El día del incidente no se improvisa redacción.
• Un tablero único de cumplimiento (una página interna basta) con enlaces vivos a cada evidencia: el mismo truco de la «carpeta de evidencias» que recomendamos para la auditoría ISO — la re-auditoría bienal del ENS se prepara en horas, no en semanas.

Regla de oro final: cada medida operacional debe tener un dueño con nombre y una frecuencia en el calendario. Lo que no tiene dueño ni fecha, en la práctica no existe — y el muestreo del auditor lo encontrará antes que tú.

Conclusión: donde el sistema demuestra que vive

El marco operacional es la prueba del algodón del ENS: la política puede escribirse en una tarde, pero los accesos revisados, los parches a tiempo, las restauraciones probadas y las alertas atendidas solo existen si la operación es real. La buena noticia para equipos técnicos disciplinados es la de toda la serie: casi todo lo que exige es buena ingeniería con rastro — y las evidencias, bien diseñadas, se generan solas.

Y hay un efecto secundario que ningún pliego menciona: un marco operacional bien montado mejora el servicio en sí. Menos incidentes, recuperaciones más rápidas, menos sorpresas en producción y un equipo que duerme mejor. El cumplimiento es la excusa; la operación sólida es el premio.

En el próximo capítulo cerramos el recorrido por el Anexo II con las medidas de protección (mp): instalaciones, personal, equipos, comunicaciones, aplicaciones, información y servicios. Y si llegas nuevo a la serie, el mapa completo está en la guía del ENS.