Seguridad de red NIS 2 conforme al artículo 21(2)(e)
NIS 2 establece que sus redes y sistemas de información deben ser seguros a lo largo de la adquisición, el desarrollo y el mantenimiento. El artículo 21(2)(e) es donde reside el deber, el CIR (UE) 2024/2690 §6.7 y §6.8 detallan las piezas específicas de red, y el §30(2)(5) BSIG es la transposición alemana.
La versión corta
El artículo 21(2)(e) es el quinto de la lista de diez deberes de ciberseguridad de NIS 2. Cubre el ciclo de vida completo de las redes y los sistemas de información: cómo los compra, cómo los construye y cómo los mantiene funcionando de forma segura. El CIR (UE) 2024/2690 §6 lo operacionaliza después en varias subsecciones. Las piezas específicas de red son el §6.7 (seguridad de red) y el §6.8 (segmentación de red).
El §6.7 es el más difícil de los dos de leer. Doce acciones concretas, desde documentar la arquitectura de red hasta ejecutar la higiene de DNS y asegurar el correo electrónico. El §6.8 es el más sencillo: divida su red en zonas según lo que cada zona necesite hacer, y mantenga separado el tráfico de producción, de pruebas y de administración.
Alemania lleva el mismo deber a la legislación nacional a través del §30(2)(5) BSIG. El BSI señala el IT-Grundschutz NET.1 (Netze und Kommunikation) y NET.3.2 (Firewall) como la vía práctica de implementación. Esta página recorre la directiva, el CIR y la capa alemana en ese orden.
Artículo 21(2)(e) Directiva NIS 2 (2022/2555)
Seguridad en la adquisición, el desarrollo y el mantenimiento de redes y sistemas de información, incluida la gestión y divulgación de vulnerabilidades.
Punto (e) de la lista del artículo 21(2). Cubre el ciclo de vida completo de sus redes y sistemas de TI, no solo el estado en funcionamiento. El CIR §6 lo desglosa después en múltiples subsecciones. El §6.7 y el §6.8 son los específicos de red.
CIR (UE) 2024/2690, Anexo §6.7 y §6.8
§6.7 Seguridad de red. Las entidades pertinentes tomarán las medidas adecuadas para proteger sus redes y sistemas de información frente a las ciberamenazas. §6.8 Segmentación de red. Las entidades pertinentes segmentarán sus sistemas […] en redes o zonas de acuerdo con los resultados de la evaluación de riesgos […]; también segmentarán sus propios sistemas y redes de los sistemas y redes de terceros.
Dado que se trata de un reglamento (no de una directiva), es legislación de la UE directamente vinculante. El §6.7 enumera doce acciones concretas, desde la arquitectura de red documentada hasta la higiene de DNS y correo electrónico. El §6.8 enumera ocho acciones de segmentación, incluida la DMZ, la separación de las redes de administración y la separación de la producción respecto del desarrollo y las pruebas.
§30(2)(5) BSIG (Alemania)
Medidas de seguridad en la adquisición, el desarrollo y el mantenimiento de sistemas, componentes y procesos de tecnología de la información, incluida la gestión y divulgación de vulnerabilidades.
Alemania copia el texto de la UE casi palabra por palabra. El BSI señala después el IT-Grundschutz NET.1 (Netze und Kommunikation) y NET.3.2 (Firewall) como la vía de implementación reconocida para el detalle del §6.7 y el §6.8.
Documente la red, controle el acceso interno
Mantenga un diagrama actual y claro de su arquitectura de red. Defina y aplique controles para proteger los dominios internos del acceso no autorizado. Bloquee las conexiones y servicios que no se necesiten. Defina controles separados para el acceso remoto, incluido el acceso remoto de proveedores. No permita que los sistemas de administración se usen para otra cosa. Desactive o prohíba explícitamente las conexiones y servicios que no use.
Higiene a nivel de dispositivos, protocolos, DNS y correo electrónico
Cuando proceda, restrinja el acceso únicamente a dispositivos aprobados. Permita las conexiones de proveedores solo tras una solicitud de aprobación y solo durante una ventana de tiempo definida (por ejemplo, mantenimiento). Ejecute la comunicación de sistema a sistema sobre canales de confianza, separados lógica, criptográfica o físicamente, con identificación segura de los extremos. Planifique y acelere la migración a protocolos modernos de capa de red. Adopte estándares de correo electrónico modernos e interoperables para cerrar las vulnerabilidades relacionadas con el correo. Aplique prácticas probadas de seguridad de DNS e higiene de enrutamiento para el tráfico entrante y saliente.
Segmente por riesgo, separe producción de pruebas y administración
Segmente sus sistemas en redes o zonas usando el resultado de la evaluación de riesgos del §2.1, no solo por comodidad. Considere los vínculos funcionales, lógicos, físicos y de ubicación entre los sistemas de confianza. Conceda el acceso a las zonas en función de los requisitos de seguridad de cada zona. Coloque los sistemas indispensables para las operaciones o la seguridad dentro de zonas protegidas. Ejecute una DMZ en las redes de comunicaciones. Restrinja el acceso a las zonas y dentro de ellas a lo que las operaciones necesiten. Ejecute una red de administración dedicada para los sistemas, separada de la red operativa. Mantenga los canales de administración de red separados de otro tráfico. Mantenga los sistemas de producción de los servicios en activo separados del desarrollo y las pruebas, incluidas sus copias de seguridad.
Segmente por riesgo, no por comodidad
El CIR §6.8.2 vincula la segmentación al §2.1: la evaluación de riesgos es lo que le dice qué zonas necesita y cuán estrictos tienen que ser los límites entre ellas. Una red plana con un solo cortafuegos no es segmentación. Zonas basadas en lo que cada parte del negocio realmente hace, y en el riesgo que conlleva, sí lo son. Si no puede señalar la línea de la evaluación de riesgos que justifica una zona, no tiene segmentación según la definición del estándar.
Documente la arquitectura, manténgala actualizada
El §6.7.2(a) es la primera acción de la lista por una razón. Todo lo demás en el §6.7 y el §6.8 depende de un diagrama de red documentado y actualizado. Los auditores miran el diagrama primero. Si no existe, o tiene dos años de antigüedad, todos los demás controles se vuelven más difíciles de verificar. Trate el diagrama como un documento vivo, no como un archivo Visio puntual.
BSI / §30(2)(5) BSIG / IT-Grundschutz
El BSI señala el IT-Grundschutz NET.1 (Netze und Kommunikation) para el diseño general de red y NET.3.2 (Firewall) para los controles de perímetro y segmentación. Ambos Bausteine se corresponden con las acciones del §6.7 y el §6.8 casi una a una. Si ya opera una red conforme a Grundschutz, puede usar la documentación existente como su base de evidencia.
ENISA Technical Implementation Guidance
La TIG de ENISA cubre el art. 21(2)(e) y las subsecciones del CIR §6, incluidas la seguridad de red y la segmentación. Mapea los requisitos sobre los controles de la ISO/IEC 27001:2022 (A.8.20 Seguridad de red, A.8.21 Seguridad de los servicios de red, A.8.22 Segregación de redes) y sobre NIST CSF 2.0 PR.IR (Resiliencia de la infraestructura tecnológica). Si ya opera uno de estos, puede reutilizar los controles.
Leyes nacionales de transposición
Otros Estados miembros transponen el art. 21(2)(e) a sus propias leyes (Países Bajos: Cyberbeveiligingswet, Austria: NISG, Bélgica: NIS2-Wet). El fondo es idéntico porque el detalle del CIR §6 vincula directamente a los sectores nombrados. Lo que difiere es con qué organismo habla y qué guía nacional de implementación lee junto al CIR.
Tenemos un cortafuegos, así que estamos cubiertos.
Un cortafuegos es bueno. No es todo el §6.7. El §6.7.2(a) exige una arquitectura de red documentada y actualizada. El §6.7.2(c) exige que las conexiones y servicios no utilizados se bloqueen por defecto. El §6.7.2(f) exige que los servicios no utilizados se prohíban explícitamente o se desactiven. El §6.8 exige segmentación por riesgo. Un cortafuegos sin esas cuatro piezas cumple una línea del §6.7, no la sección.
La producción y las pruebas están en la misma red porque es más fácil.
El §6.8.2(h) es explícito: los sistemas de producción de los servicios en activo deben estar separados del desarrollo y las pruebas, incluidas sus copias de seguridad. Esta es una de las lagunas más difíciles de corregir a posteriori y una de las más fáciles de detectar para un auditor. Una subred compartida para producción y pruebas no superará la revisión del §6.8.
Nuestros administradores acceden al cortafuegos desde sus estaciones de trabajo habituales.
El §6.8.2(f) exige una red de administración separada para los sistemas. El §6.8.2(g) exige que los canales de administración estén separados de otro tráfico de red. Acceder a un cortafuegos desde una estación de trabajo que también ejecuta correo electrónico y un navegador rompe ambos. Use un jump host dedicado o una estación de trabajo de acceso privilegiado, en una VLAN de gestión separada.
Una red Mittelstand típica de 60 a 250 personas ya tiene un cortafuegos y, a menudo, una DMZ. Las lagunas del §6.7 y el §6.8 que vemos suelen ser las mismas tres: ningún diagrama de red documentado, ninguna red de administración dedicada, y producción y pruebas en la misma subred. Cada una de ellas es barata de anotar una vez y dolorosa de corregir a posteriori.
El orden pragmático: dibuje la red actual en una página, segmente según lo que cada zona realmente hace (oficina, servidor, DMZ, OT o producción, administración), anote qué conexiones se permiten entre zonas y por qué, y traslade el acceso de administración a una VLAN de gestión separada con un jump host. Eso cubre el §6.7.2(a), el núcleo de segmentación del §6.8 y la separación de la red de administración del §6.8.2(f) y (g). El resto es higiene que se deriva de ahí.
El módulo PRO de la plataforma alberga el inventario de arquitectura de red, las reglas de segmentación y el registro de la red de administración. Usted registra cada zona, qué hace, con qué se conecta y qué línea de la evaluación de riesgos la justifica. El diagrama y la lógica de segmentación viven en un solo lugar, no repartidos entre un archivo Visio y una página de Confluence.
Los cambios en la red se registran a medida que ocurren, de modo que el §6.7.2(a) sigue siendo un documento vivo en lugar de una instantánea. El registro de auditoría captura quién cambió qué y cuándo, que es la evidencia que un auditor quiere ver cuando pregunta si la documentación refleja la realidad.
- Directiva (UE) 2022/2555 (NIS 2), artículo 21(2)(e) — eur-lex.europa.eu/eli/dir/2022/2555/oj
- Reglamento de Ejecución (UE) 2024/2690 de la Comisión (CIR), Anexo §6.7 y §6.8 — eur-lex.europa.eu/eli/reg_impl/2024/2690/oj
- Ley BSI (BSIG), §30(2)(5) en su versión modificada por la NIS2 Implementation and Cybersecurity Strengthening Act
- BSI IT-Grundschutz, Bausteine NET.1 (Netze und Kommunikation) y NET.3.2 (Firewall) — bsi.bund.de/grundschutz
- ENISA Technical Implementation Guidance para el CIR (UE) 2024/2690 (a fecha de mayo de 2026)