Control de acceso NIS2 conforme al artículo 21(2)(i)+(j)
El artículo 21(2)(i) nombra las políticas de control de acceso. El artículo 21(2)(j) nombra la autenticación multifactor. El §11 del CIR las cubre juntas en siete subsecciones. Esta página recorre los deberes más amplios de política, de cuentas con privilegios y de identidad. La página dedicada a MFA cubre el §11.7.
La versión resumida
El control de acceso se sitúa en los puntos (i) y (j) del artículo 21(2). El punto (i) nombra 'seguridad de los recursos humanos, políticas de control de acceso y gestión de activos'. El punto (j) nombra 'la utilización de soluciones de autenticación multifactor o de autenticación continua, comunicaciones de voz, vídeo y texto seguras'. Ambos se aplican a toda entidad esencial e importante en toda la UE.
El CIR (UE) 2024/2690 §11 cubre ambas letras juntas, bajo el encabezado 'Control de acceso (artículo 21(2), puntos (i) y (j) de la Directiva (UE) 2022/2555)'. Divide el deber en siete subsecciones: la política en sí, la gestión de derechos, las cuentas con privilegios, los sistemas de administración de sistemas, la identificación, la autenticación y la autenticación multifactor. Esta página recorre del §11.1 al §11.6. Para el §11.7 en concreto, véase la página dedicada a MFA.
Alemania incorpora el deber de política al §30(2)(9) BSIG y el deber de MFA al §30(2)(10) BSIG. La base alemana para la implementación es IT-Grundschutz ORP.4 'Identitäts- und Berechtigungsmanagement'.
info.accessControl.legalAnchor.directiveI.label
info.accessControl.legalAnchor.directiveI.quote
info.accessControl.legalAnchor.directiveI.context
info.accessControl.legalAnchor.directiveJ.label
info.accessControl.legalAnchor.directiveJ.quote
info.accessControl.legalAnchor.directiveJ.context
CIR (UE) 2024/2690, anexo §11
Control de acceso (artículo 21(2), puntos (i) y (j) de la Directiva (UE) 2022/2555).
El §11 del CIR tiene siete subsecciones: §11.1 política de control de acceso, §11.2 gestión de derechos de acceso, §11.3 cuentas con privilegios y cuentas de administración de sistemas, §11.4 sistemas de administración de sistemas, §11.5 identificación, §11.6 autenticación, §11.7 autenticación multifactor. Este reglamento vincula directamente a los proveedores de DNS, la nube, los centros de datos, los proveedores de servicios gestionados y los demás sectores nombrados en el anexo.
§30(2)(9) y (10) BSIG (Alemania)
Konzepte für die Zugriffskontrolle und für das Management von Anlagen. […] Verwendung von Lösungen zur Multi-Faktor-Authentifizierung oder kontinuierlichen Authentifizierung.
Alemania divide el punto (i)+(j) de la UE en dos números del BSIG. El §30(2)(9) lleva el control de acceso y la gestión de activos. El §30(2)(10) lleva MFA y las comunicaciones seguras. El fondo es la misma norma de la UE.
Política y gestión de derechos
Documente cómo funciona el acceso (lógico y físico) para el personal, los visitantes, los proveedores y los prestadores de servicios. Conceda, modifique y revoque derechos en función de la necesidad de negocio: necesidad de conocer, necesidad de usar, separación de funciones. Cada derecho se asigna a una persona nombrada. La revocación se ejecuta ante un cambio de empleo, no en un ciclo semanal. El acceso de terceros (visitantes, proveedores) se rastrea.
Cuentas con privilegios y de administración
Las cuentas de administración reciben una identificación, autenticación y autorización fuertes. Solo cuentas de administración dedicadas, utilizadas únicamente para la instalación, configuración, gestión y mantenimiento. Los derechos de administración se adaptan individualmente y se restringen. Los sistemas de administración de sistemas se sitúan en su propia red lógica, separados de las redes de aplicaciones, a los que se accede mediante autenticación y cifrado.
Identidad y autenticación
Ciclo de vida de la identidad: IDs únicos, cada ID vinculado a una persona, supervisión y registro a lo largo del ciclo de vida. Los procedimientos de autenticación se ajustan a la política de control de acceso: fortaleza de la contraseña escalada a la clasificación del activo, procedimientos de cambio, bloqueo ante intentos fallidos, tiempos de espera de sesión, credenciales separadas para las cuentas con privilegios.
Necesidad de conocer, necesidad de usar, separación de funciones
El §11.2 del CIR nombra las tres. Necesidad de conocer: solo las personas que necesitan los datos obtienen los datos. Necesidad de usar: los derechos se ajustan a la tarea, no al cargo. Separación de funciones: ninguna persona individual debería poder conceder, usar y auditar el mismo derecho. Si sus grupos de AD son 'TI' y 'todos los demás', no ha implementado ninguna de las tres.
Con privilegios no es solo normal con más derechos
El §11.3 y el §11.4 del CIR elevan el listón específicamente para las cuentas de administración. Identificación fuerte. MFA nombrada en el propio §11.3, no solo en el §11.7. Cuentas dedicadas usadas solo para el trabajo de administración. Sistemas de administración de sistemas en su propia red. La cuestión: una cuenta de administración comprometida compromete todo, así que las cuentas de administración reciben su propio régimen.
BSI / IT-Grundschutz ORP.4
La base alemana es el módulo ORP.4 'Identitäts- und Berechtigungsmanagement' de IT-Grundschutz. ORP.4 cubre el ciclo de vida de la identidad, los derechos basados en roles, la separación de cuentas con privilegios, las reglas de contraseñas y la cadencia de revisión. Conforme al §44(2) BSIG, implementar Grundschutz se reconoce expresamente como cumplimiento de las obligaciones de NIS2 en Alemania.
Guía Técnica de Implementación de ENISA
La Guía Técnica de Implementación de ENISA para el CIR (UE) 2024/2690 recorre cada subsección del §11 en lenguaje operativo y la correlaciona con ISO/IEC 27001:2022 (A.5.15 a A.5.18, A.8.2 a A.8.5) y NIST CSF 2.0 (PR.AA). Una implementación de control de acceso de ISO 27001 ya existente cubre la mayor parte del §11.
Leyes nacionales de transposición
Cada Estado miembro transpone el artículo 21(2)(i) y (j) a su propia ley (Países Bajos: Cyberbeveiligingswet, Austria: NISG, Bélgica: NIS2-Wet). Las obligaciones son idénticas porque la directiva fija un único criterio para toda la UE. Lo que difiere: a qué norma de base apunta la autoridad reguladora nacional.
Tenemos grupos de AD, así que tenemos control de acceso.
Un comienzo, no el final. El §11.2 del CIR quiere una política de derechos de acceso documentada, derechos asignados a personas nombradas, un procedimiento de revocación vinculado al cambio de empleo y un registro de auditoría de concesiones y revocaciones. Los grupos de AD le dan el mecanismo. No le dan la política, el registro de personas nombradas ni el procedimiento de altas-cambios-bajas que un auditor pedirá.
Nuestros administradores usan su cuenta normal para el trabajo de administración, con sudo o 'ejecutar como administrador'.
No bajo el §11.3.2 del CIR. El texto exige 'cuentas de administración dedicadas' usadas solo para la instalación, configuración, gestión y mantenimiento. La cuenta normal de un administrador es para el correo, el calendario y Excel. Una cuenta de administración separada, con su propia MFA, es para el trabajo con privilegios. Mezclar las dos significa que un correo de phishing puede comprometer el rol de administración.
Sincronizamos los derechos de acceso cada lunes por la mañana.
Cerca, pero no es lo que pide el §11.2. El deber de revocación se dispara ante un cambio de empleo, no en un ciclo de calendario. Quien se fue el martes no debería tener acceso el miércoles. Para los cambios de rol dentro de la empresa, especialmente los que tienen privilegios, el cambio debería ser inmediato. Una cadencia semanal está bien para la revisión de auditoría, no para la revocación en sí.
Configuración típica del Mittelstand de 50-250 personas: Active Directory o Entra ID para las identidades, grupos de AD para el acceso a aplicaciones, un sistema de RR. HH. que emite tickets de onboarding a TI. El mecanismo está mayormente ahí. Las brechas del §11 residen en tres lugares.
Lo que vemos que los profesionales detectan primero: una política de derechos de acceso escrita (la mayoría tiene un borrador, pocos tienen una versión firmada y actualizada), cuentas de administración dedicadas (la mayoría de los administradores siguen usando sudo en su cuenta diaria) y que el procedimiento de altas-cambios-bajas sea solo de TI en lugar de impulsado por RR. HH. (de modo que la cuenta de un contratista persiste porque RR. HH. nunca avisó a TI de que se fue). Corregir esos tres cierra la mayor parte de la brecha del §11.
Nuestro módulo ACC cubre el §11.1 (sube o redacta la política de control de acceso y el órgano de dirección la aprueba), el §11.2 (un registro de derechos vinculado a usuarios nombrados), el §11.3 (inventario de cuentas con privilegios con evidencia de autenticación separada) y el §11.5 más el §11.6 (registro de la fuente de identidad vinculado a su IdP). La separación de los sistemas de administración de sistemas del §11.4 se documenta como una decisión de arquitectura con evidencia.
Para la pieza de MFA del §11.7 en concreto, véase la página dedicada a MFA y su flujo de evidencia. El registro de auditoría que la plataforma mantiene automáticamente (aprobaciones, estado de las tareas, registro de cambios) cubre lo que un auditor quiere ver para la cadencia de revisión y para la decisión de la dirección.
- Directiva (UE) 2022/2555 (NIS2), artículo 21(2)(i) y (j) — eur-lex.europa.eu/eli/dir/2022/2555/oj
- Reglamento de Ejecución (UE) 2024/2690 de la Comisión (CIR), anexo §11 — eur-lex.europa.eu/eli/reg_impl/2024/2690/oj
- Ley del BSI (BSIG), §30(2)(9) y §30(2)(10) en su versión modificada por la Ley de Implementación de NIS2 y de Refuerzo de la Ciberseguridad
- Compendio IT-Grundschutz, módulo ORP.4 'Identitäts- und Berechtigungsmanagement' — bsi.bund.de/grundschutz
- Guía Técnica de Implementación de ENISA para el CIR (UE) 2024/2690 (a fecha de mayo de 2026)