¿Cuáles son las mejores prácticas de seguridad de NDES?

Las mejores prácticas de seguridad de NDES son los controles de configuración y operativos que protegen la función del Servicio de inscripción de dispositivos de red (NDES) en los Servicios de certificados de Active Directory, abarcando la comunicación cifrada, el endurecimiento de las cuentas de servicio, la protección de la clave privada y el ciclo de vida de las plantillas de certificados, de modo que un servidor NDES comprometido no pueda utilizarse para solicitar certificados arbitrarios.

El Servicio de Inscripción de Dispositivos de Red (NDES) permite que el software de los dispositivos de red, como enrutadores, firewalls y conmutadores, obtenga certificados digitales sin necesidad de ejecutar credenciales de dominio. NDES es uno de los servicios de rol de los Servicios de Certificados de Active Directory (AD CS) e implementa el Protocolo Simple de Inscripción de Certificados (SCEP) , que define la comunicación entre la Autoridad de Registro (RA) y los dispositivos de red durante la inscripción. Dado que NDES se sitúa en el límite entre los dispositivos no confiables y una CA confiable, todos los controles de esta página están diseñados para evitar que dicho límite se convierta en un punto débil de la infraestructura de clave pública (PKI).

Esta guía abarca qué hace realmente NDES, los pasos específicos de refuerzo que recomiendan Microsoft y EC, cómo decidir qué controles priorizar, una visión de las ventajas y desventajas de las decisiones de mayor impacto, un árbol de decisiones y una matriz de decisiones para su entorno, y cómo el refuerzo de NDES se integra en un programa más amplio de gestión del ciclo de vida de los certificados.

Puntos Clave

• NDES conecta dispositivos de red no confiables con una CA confiable, por lo que existen todos los controles de seguridad necesarios para evitar que un servidor NDES comprometido se convierta en una vía para la emisión arbitraria de certificados.
• La protección de la clave privada es el control de máxima prioridad: un HSM mantiene las claves NDES fuera de la memoria del sistema operativo y fuera de las instantáneas o copias de seguridad de máquinas virtuales no cifradas.
• La separación de roles y la elección de la cuenta de servicio (Servicio de red, gMSA o una cuenta de dominio reforzada) determinan la cantidad de gestión manual de contraseñas y permisos que requiere la implementación de NDES a largo plazo.
• NDES debe ejecutarse en su propio servidor, nunca ubicado junto con la CA excepto detrás de una regla de firewall específica, y debe estar detrás de un proxy inverso siempre que sea accesible desde Internet.
• Según la encuesta Trust Pulse de DigiCert, publicada el 2 de julio de 2025, las empresas que dependen de un endurecimiento manual y no documentado del servicio PKI informaron de tiempos de inactividad relacionados con certificados en el 45 % de los casos durante el último año, y el 37.5 % de esas interrupciones fueron causadas específicamente por un certificado caducado. Un servidor NDES no reforzado o no supervisado se encuentra directamente en esa categoría de riesgo.

¿A quién debería importarle las mejores prácticas de seguridad de NDES?

El endurecimiento de NDES va más allá de quien creó el rol. Esto es lo que cada equipo debería hacer al respecto.

• Administradores de PKI Gestionar la compilación de NDES, la configuración de la cuenta de servicio y el ciclo de vida de la plantilla de certificado. Acción: confirmar que las plantillas de cifrado CEP y del agente de inscripción de Exchange no se hayan asignado desde la CA fuera de los periodos de configuración inicial y renovación.
• Arquitectos de seguridad Decidir cómo se almacenan las claves privadas de NDES y cómo se aísla el servidor. Acción: exigir el almacenamiento de claves con HSM para cualquier implementación de NDES que emita certificados a gran escala, no solo para la propia CA.
• Equipos de plataforma e identidad Administre el proxy inverso, las reglas del firewall y la configuración TLS delante de NDES. Acción: verifique que el proxy inverso y la aplicación de TLS 1.2+ estén implementados antes de que se active cualquier inscripción SCEP con acceso a Internet (como Intune).
• Cumplimiento y GRC Realizar un seguimiento para comprobar si existen pruebas de endurecimiento de NDES para las auditorías. Acción: añadir las comprobaciones de la cuenta de servicio de NDES, la asignación de plantillas y el almacenamiento de claves a la revisión periódica de los controles de PKI, y no solo los controles de la propia CA.
• CISO Asumir el riesgo de que un servidor NDES comprometido se convierta en una vía de emisión de certificados para un atacante. Acción: tratar NDES como un activo adyacente al Nivel 0, dada su relación de confianza con la CA, y no como un dispositivo de red de baja prioridad.

¿Cuáles son las mejores prácticas de seguridad de NDES?

Las mejores prácticas de seguridad de NDES son el conjunto de controles recomendados por Microsoft y la industria que reducen la superficie de ataque del Servicio de Inscripción de Dispositivos de Red (NDES): cifrar el tráfico administrativo, limitar el tiempo de ejecución del servicio, separar las funciones operativas, proteger las claves privadas utilizadas para firmar y cifrar las solicitudes de inscripción y definir correctamente el alcance de las plantillas de certificado que NDES puede usar. Ninguno de estos controles funciona de forma aislada; una cuenta de servicio reforzada con una clave privada desprotegida sigue siendo una vulnerabilidad crítica, y una clave respaldada por un HSM sin separación de funciones deja el servidor expuesto a un uso indebido por parte de cualquier persona con acceso.

Funciones de NDES

NDES realiza tres funciones en el flujo de inscripción de certificados, y cada una de ellas es un punto donde se aplica un control de endurecimiento que se describe a continuación:

1. Genera y proporciona contraseñas de registro de un solo uso a los administradores.
2. Envía solicitudes de inscripción a la Autoridad de certificación (CA).
3. Recupera los certificados registrados de la CA y los envía al dispositivo de red que los solicita.

Las directrices de Microsoft sobre estos controles constituyen una referencia secundaria útil: consulte la publicación "NDES Security Best Practices" en el Centro de la Comunidad de Microsoft.

Mejores prácticas de seguridad para NDES

Aplique estos controles en conjunto, en lugar de hacerlo de forma aislada. Cada uno corrige una vulnerabilidad diferente, y la mayoría de las vulnerabilidades reales en el ámbito de los sistemas de detección de peligros no destructivos (NDES) se deben a que se omitieron dos o tres de ellos a la vez, no solo uno.

Habilitar SSL/TLS para el sitio de administración de NDES

La protección SSL/TLS en el sitio MSCEP_Admin garantiza que la contraseña de desafío de inscripción esté protegida contra ataques de inspección cuando un administrador o un dispositivo de red se conecta a él. Sin ella, la contraseña de un solo uso que genera NDES queda expuesta en texto plano a cualquiera que pueda interceptar la conexión.

Utilice certificados de dispositivo de validez extendida cuando corresponda.

La plantilla de certificado IPsec (Solicitud sin conexión) predeterminada tiene una validez de solo un año. Si define plantillas de certificado personalizadas para firma, cifrado o uso general en sus dispositivos, considere una plantilla de versión 2 con una validez de dos años para reducir la complejidad de la gestión de solicitudes de certificados. Tenga en cuenta la tendencia general del sector hacia certificados con una duración más corta para todo lo que esté expuesto a internet; una validez más prolongada es apropiada para certificados internos de dispositivos, no para aquellos que interactúen con el ecosistema TLS público.

Desactive el servicio NDES cuando no esté en uso.

Detener el servicio NDES cuando no se necesita activamente garantiza que no se emitan certificados no autorizados durante ese período y elimina las contraseñas de inscripción no utilizadas de la caché del servicio. Este control prioriza la reducción de riesgos sobre la comodidad y funciona mejor en entornos con inscripción de dispositivos programada y por lotes, en lugar de inscripción continua y bajo demanda.

Proteja el servidor con el Asistente de configuración de seguridad

El Asistente para la configuración de seguridad de Windows analiza los roles y servicios que se ejecutan en el servidor NDES y recomienda restringir el acceso a IIS y a todo lo demás instalado junto a él. Ejecútelo después de finalizar la configuración de NDES y vuelva a ejecutarlo tras cualquier cambio en los roles instalados en ese servidor.

Implementar la separación de roles

En la instalación, configuración y funcionamiento de NDES intervienen varias cuentas distintas, y ninguna de ellas debería solaparse en su alcance:

• Cuenta de configuración, utilizada únicamente durante la instalación inicial y la renovación de la plantilla.
• Administradores de dispositivos, quienes gestionan el registro de dispositivos día a día.
• La propia cuenta de servicio NDES, que puede ser un servicio de red, una cuenta de servicio administrada de grupo (gMSA) o una cuenta de usuario de dominio reforzada, según el entorno.

Seleccione y refuerce la cuenta de servicio de NDES

Independientemente del tipo de cuenta que elija, aplique estos controles de forma coherente:

• Se requiere el cifrado AES para las cuentas de usuario gMSA o de dominio.
• Configure restricciones de inicio de sesión y una contraseña larga y no reutilizada para las cuentas de usuario del dominio.
• No reutilice una cuenta gMSA o de usuario de dominio en ningún otro ordenador ni para ningún otro fin.
• Habilite la casilla de verificación "La cuenta es confidencial y no se puede delegar" para las cuentas de usuario del dominio.
• Configure manualmente los permisos de las claves privadas de los certificados NDES cuando utilice una plantilla de certificado gMSA o personalizada, ya que estos permisos no siempre se configuran automáticamente.

Reforzar el sistema subyacente

Reduzca el grupo de administradores locales en el servidor NDES para que incluya únicamente a los administradores de PKI. Solo los miembros de este grupo deben tener permisos de inicio de sesión en el servidor, ya sea interactivo, interactivo remoto, como trabajo por lotes o como servicio. Todas las demás cuentas deben tener permisos de inicio de sesión nulos en el servidor NDES.

Proteja las claves privadas con un HSM.

La protección de claves es el control de mayor impacto de esta lista, ya que una clave privada NDES comprometida permite a un atacante solicitar un certificado válido para iniciar sesión en Active Directory como cualquier usuario.

• Use un Módulo de seguridad de hardware (HSM) Para generar, almacenar y gestionar el acceso a las claves NDES, un HSM garantiza que las claves NDES nunca residan en la memoria del sistema operativo, añade controles operativos y limita la exposición al material de la clave.
• Si NDES está virtualizado, utilice un HSM para almacenar sus claves privadas, ya que, de lo contrario, los administradores del host de virtualización con acceso a la máquina virtual, el disco o la memoria podrían recuperar las claves sin cifrar.
• Si no se utiliza un HSM, cifre las copias de seguridad y restrinja estrictamente el acceso a ellas, ya que las instantáneas, los puntos de control y otros tipos de copias de seguridad suelen contener las claves privadas NDES sin cifrar.

Aísle NDES dentro de su infraestructura

• Al permitir el acceso a internet a NDES, por ejemplo, para inscribir certificados en dispositivos móviles administrados por Intune, protéjalo con un proxy inverso como Azure AD Application Proxy o Web Application Proxy (WAP). Nunca exponga NDES directamente a internet.
• Instale NDES en un equipo distinto al que aloja la CA y no ejecute ningún otro servicio en el propio servidor NDES.
• Si NDES debe estar ubicado en un equipo de CA, configure la regla del firewall del Protocolo de inscripción y administración de la autoridad de certificación (CERTSVC-RPC-TCP-IN) para que solo la dirección IP de NDES (y OCSP) pueda llegar a la CA para la inscripción.

Gestione correctamente las plantillas de CA y certificados.

NDES se basa en un pequeño conjunto de plantillas de certificados, cada una con un propósito específico y concreto, y cada una necesita su propio permiso y disciplina de ciclo de vida.

Plantillas de agente de inscripción de Exchange y cifrado CEP

Cifrado CEP: durante la configuración del servicio, se emite un certificado basado en esta plantilla al equipo NDES, el cual aplica el cifrado específico de SCEP a la comunicación con el cliente solicitante. Agente de inscripción de Exchange (solicitud sin conexión): durante la configuración, también se emite un certificado basado en esta plantilla, y NDES lo utiliza para volver a firmar digitalmente la solicitud de inscripción recibida del dispositivo o MDM antes de enviarla a la CA emisora. Ambas plantillas solo son necesarias durante la instalación inicial de NDES y al renovar el certificado antes de su vencimiento; desactívelas de la CA durante el funcionamiento normal y otorgue permisos de inscripción de cuenta de configuración en estas plantillas únicamente durante el período de configuración.

Plantilla de certificado IPSec (solicitud sin conexión)/SCEP

Esta plantilla, también conocida como «Plantilla de dispositivo» o «Plantilla de certificado SCEP», se utiliza para registrar certificados de dispositivos o usuarios y se asigna automáticamente a la CA durante la configuración de NDES. La mayoría de las implementaciones la reemplazan con una plantilla personalizada que se ajusta mejor a sus necesidades. Otorgue permisos de registro en esta plantilla al rol de Administrador de dispositivos y a la cuenta de servicio de NDES, y a nadie más.

Implementar el cifrado de datos en tránsito (TLS 1.2+)

TLS debe cifrar todas las comunicaciones entre NDES y el MDM o dispositivo que solicita el certificado. Esto incluye garantizar el uso de TLS deshabilitando por completo el oyente HTTP de IIS y confirmando el cumplimiento de TLS 1.2 en toda la infraestructura, no solo en el sitio web de NDES.

Criterios de selección: ¿Qué prácticas priorizar primero?

No todos los entornos pueden implementar los once controles el primer día. Priorícelos en este orden cuando el tiempo o los recursos sean limitados:

1. La protección de la clave privada (almacenamiento respaldado por HSM) es primordial, ya que este es el control con el mayor impacto si se omite.
2. El cifrado de datos en tránsito (TLS 1.2+) es la segunda mejor opción, ya que requiere poco esfuerzo y elimina de inmediato el riesgo de interceptación pasiva.
3. El aislamiento de la infraestructura (servidor separado, proxy inverso si está expuesto a Internet) es el tercer paso, ya que limita lo que un atacante puede alcanzar incluso si falla otro control.
4. En cuarto lugar, la separación de roles y el endurecimiento de las cuentas de servicio, ya que las cuentas mal configuradas son la forma más común en que se eluden los demás controles.
5. El ciclo de vida de las plantillas de certificados y el endurecimiento del sistema se realizan al final, ya que reducen el riesgo residual una vez que los controles de mayor impacto ya están implementados.

Ventajas y desventajas de los principales controles de seguridad de NDES

Control	Ventajas	Desventajas
Almacenamiento de claves privadas respaldado por HSM	Las claves nunca salen del perímetro de confianza del hardware; cumple con la mayoría de los requisitos de cumplimiento para la protección de claves.	Costo adicional y complejidad operativa; requiere experiencia en integración de HSM.
cuenta de servicio gMSA	No requiere rotación manual de contraseñas; admite AES; reduce la superficie de robo de credenciales en comparación con una cuenta de usuario de dominio.	Requiere compatibilidad con esquemas y versiones de AD; aún necesita un gMSA con ámbito por servidor NDES.
Proxy inverso para NDES con acceso a internet	Mantiene a NDES fuera de la internet pública; centraliza la autenticación y la terminación TLS.	Agrega infraestructura que a su vez necesita parches, monitoreo y su propio endurecimiento.
Colocación conjunta de NDES con CA	Menos servidores que construir, parchear y monitorizar.	Amplía la superficie de ataque de la CA; Microsoft lo desaconseja excepto detrás de una regla de firewall con ámbito definido.
Desactivación de NDES cuando está inactivo	Reduce el período de exposición; borra las contraseñas almacenadas en caché que no se utilicen.	Rompe los escenarios de inscripción permanente, como la emisión continua de SCEP de Intune.

Árbol de decisiones: ¿Qué controles de seguridad NDES se aplican a su entorno?

Utilice este diagrama de árbol para determinar qué controles son innegociables para su implementación específica:

• ¿Se puede acceder a NDES desde Internet (por ejemplo, para la inscripción en Intune SCEP)?
  • Sí: implemente un proxy inverso (Azure AD Application Proxy o WAP) delante de NDES y confirme que se aplica TLS 1.2+ de extremo a extremo antes de habilitar el acceso.
  • No: confirmo que NDES sigue aislado en su propio segmento interno; "solo interno" no significa "sin restricciones".
• ¿Su organización ya utiliza un HSM para la CA emisora?
  • Sí: extender el mismo HSM para proteger las claves privadas NDES en lugar de dejar las claves NDES en el software.
  • No: priorizar la adopción de HSM para NDES antes de ampliar el volumen de inscripciones de SCEP, ya que el volumen aumenta el valor de las claves como objetivo.
• ¿Está NDES instalado actualmente en el mismo servidor que la CA?
  • Sí: migre NDES a su propio servidor si es posible; si no es posible a corto plazo, configure inmediatamente la regla de firewall CERTSVC-RPC-TCP-IN.
  • No: confirme que no se estén ejecutando otros servicios no relacionados en el propio servidor NDES.
• ¿La inscripción se produce de forma continua (como las solicitudes SCEP automatizadas impulsadas por MDM) o en lotes programados?
  • Continuo: omita el control "desactivar cuando no esté en uso" y, en su lugar, confíe en los demás controles, además de la monitorización activa.
  • Procesamiento por lotes: desactive el servicio NDES entre los periodos de inscripción para reducir la superficie de exposición.

Matriz de decisión: Caso de uso, impacto en la seguridad, esfuerzo operativo, adecuación de la automatización y propietario.

Utilice esta matriz para dirigir cada decisión de endurecimiento del NDES al propietario adecuado, con una idea realista del esfuerzo que implica.

Caso de uso	Impacto en la seguridad	Esfuerzo Operacional	Ajuste de automatización	Propietario recomendado
Sistema NDES público/accesible por internet para la inscripción en MDM	Alto	Media	Las políticas de alto nivel, proxy inverso y TLS se pueden automatizar.	Equipo de Plataforma/Identidad
NDES se ubica junto con CA	Alto	Bajo	Bajo, principalmente una regla de firewall y una decisión de migración que se aplica una sola vez.	Administrador de la infraestructura de clave pública (KPI)
Almacenamiento de claves privadas (HSM frente a software)	Critical	Media	Alto, las API de HSM admiten operaciones de clave mediante scripts.	Arquitecto de seguridad
Selección de cuenta de servicio (gMSA frente a usuario de dominio)	Media	Bajo	Alto, gMSA elimina por completo la rotación manual de contraseñas.	Administrador de la infraestructura de clave pública (KPI)
Ciclo de vida de la plantilla de certificado (desasignación de CEP/EEA)	Media	Bajo	Medio, se puede programar pero necesita una ventana de cambio	Administrador de la infraestructura de clave pública (KPI)
Aplicación de las normas de seguridad para datos en tránsito (TLS 1.2+)	Alto	Bajo	Alto, aplicable mediante IIS y la línea base de directivas de grupo.	Arquitecto de seguridad

Cómo se conecta NDES Security con la gestión del ciclo de vida de los certificados.

Cada certificado que NDES emite para un dispositivo de red aún necesita ser descubierto, rastreado y renovado durante el resto de su vida útil, y un servidor NDES reforzado que emite certificados a una población no rastreada sigue generando el mismo riesgo de interrupción. La encuesta Trust Pulse de DigiCert, publicada el 2 de julio de 2025, reveló que el 45 % de las empresas experimentaron tiempo de inactividad relacionado con certificados en el último año, y que el 37.5 % de esos incidentes fueron causados ​​específicamente por un certificado caducado. Los certificados de dispositivos emitidos a través de NDES son precisamente el tipo de población de alto volumen y fácil de rastrear que impulsa esa cifra.

Las plataformas de gestión del ciclo de vida de los certificados, como CertSecure Manager, amplían la visibilidad a todos los certificados que emite NDES, no solo a los que un administrador recuerda controlar, cerrando así la brecha entre "NDES está reforzado" y "se contabilizan todos los certificados que ha emitido". Si está modernizando las operaciones de PKI de forma más general, vea cómo la modernización de PKI y la gestión del ciclo de vida de los certificados (CLM) funcionan conjuntamente y cómo una hoja de ruta combinada de PKI y CLM contempla la automatización de certificados de dispositivos, no solo de certificados de servidor o de usuario.

Seguridad NDES en entornos PKI en la nube, híbridos y con múltiples autoridades de certificación

Los entornos híbridos que gestionan la inscripción de dispositivos móviles mediante Intune u otra solución MDM en la nube añaden una capa de conectividad en la nube a lo que históricamente era un servicio completamente local. Por ello, el proxy inverso y los controles TLS mencionados anteriormente cobran mayor importancia en una implementación híbrida. Los entornos con múltiples CA complican aún más la cuestión de las plantillas de certificados: todas las CA a las que NDES puede acceder necesitan el mismo alcance de plantilla y la misma disciplina de permisos, no solo la CA emisora ​​principal.

Para las organizaciones que gestionan NDES y la emisión de certificados en múltiples entornos, un modelo PKI como servicio centraliza la base de protección, la protección de claves y la monitorización que, de otro modo, tendrían que replicarse y auditarse por separado en cada instancia de NDES.

Cómo medir el éxito y qué auditar periódicamente

Una implementación reforzada de NDES no es un proyecto que se realiza una sola vez. Es necesario auditar estos sistemas periódicamente, no solo durante la configuración inicial:

• Si las plantillas de cifrado CEP y agente de inscripción de Exchange aún no han sido asignadas por la CA fuera de las ventanas de configuración o renovación.
• Si los permisos y la política de contraseñas de la cuenta de servicio NDES siguen coincidiendo con la base de referencia de endurecimiento prevista.
• Si la aplicación de TLS 1.2+ y la desactivación del oyente HTTP siguen vigentes después de cualquier actualización de IIS o Windows.
• Si las claves privadas siguen estando respaldadas por HSM, especialmente después de cualquier migración de servidor o cambio de virtualización.
• Si el proxy inverso que se encuentra delante de cualquier instancia NDES con acceso a Internet está actualizado, parcheado y aún tiene el alcance correcto.

Un inventario de activos criptográficos como CBOM Secure amplía el inventario de identidad de máquinas y el descubrimiento de certificados a todos los certificados que emite NDES, proporcionando el registro de auditoría del que dependen estas comprobaciones recurrentes, en lugar de depender de la memoria institucional de lo que NDES estaba configurado para hacer en el momento de su implementación.

A largo plazo, la votación del CA/Browser Forum del 11 de abril de 2025 para acortar la validez máxima de los certificados TLS a 200 días, luego a 100 días y finalmente a 47 días para 2029 no rige directamente los certificados de dispositivos internos como rige los TLS públicos, pero indica hacia dónde se dirigen las expectativas del ciclo de vida de los certificados en toda la industria, incluyendo poblaciones de dispositivos como las que emite NDES. El NIST finalizó sus tres primeros estándares de criptografía post-cuántica, FIPS 203, FIPS 204 y FIPS 205, el 13 de agosto de 2024, y cualquier organización que planee la agilidad criptográfica en su PKI debería incluir los certificados de dispositivos emitidos por NDES en esa planificación, no solo los certificados de servidor y usuario. El Centro de Excelencia PQC de Encryption Consulting y una evaluación de preparación para PQC son el lugar adecuado para planificar esa transición.

La opinión de Encryption Consulting

El endurecimiento de NDES suele tratarse como una lista de verificación que se ejecuta una sola vez durante la configuración inicial, pero los controles más importantes (protección de claves privadas, mantenimiento de cuentas de servicio y ciclo de vida de las plantillas) se desfasan con el tiempo a medida que cambia el personal, se migra a los servidores y se añaden nuevos casos de uso de registro sin que nadie revise la configuración inicial de endurecimiento. Considere la matriz de decisiones y los criterios de selección anteriores como una revisión periódica, no como un punto de control de implementación único.

Conclusión

Garantizar la seguridad de NDES implica implementar todos los controles mencionados anteriormente, aplicar TLS, reforzar las cuentas de servicio, separar roles, controlar el ciclo de vida de las plantillas y, sobre todo, proteger la clave privada mediante HSM. Esto se debe a que un atacante con acceso a una clave privada de NDES puede solicitar un certificado válido para iniciar sesión en Active Directory como cualquier usuario. Utilice los criterios de selección, las ventajas y desventajas, el árbol de decisiones y la matriz de decisiones de esta guía para priorizar y asignar la responsabilidad de un entorno específico.

Si necesita ayuda para reforzar su implementación de NDES o su entorno PKI en general, no dude en enviarnos un correo electrónico a [email protected].

Preguntas frecuentes

¿Cuál es la principal conclusión de "¿Cuáles son las mejores prácticas de seguridad de NDES?"?

NDES se sitúa en la frontera entre los dispositivos de red no confiables y una CA confiable, por lo que reforzar su seguridad implica proteger las claves privadas, cifrar todas las comunicaciones, separar las funciones operativas y definir con precisión el alcance de las plantillas de certificados. Ningún control por sí solo es suficiente; el control de máxima prioridad es la protección de claves privadas mediante HSM.

¿Por qué es importante esto para los equipos de PKI empresariales?

Un servidor NDES comprometido puede utilizarse para solicitar un certificado válido para iniciar sesión en Active Directory como cualquier usuario, lo que convierte a NDES en un objetivo de alto valor, aunque a menudo se le trata como un dispositivo de red de baja prioridad en lugar de un activo adyacente al nivel 0.

¿Qué riesgos aumentan si este tema se aborda manualmente?

El endurecimiento manual y no documentado de NDES implica que los permisos de las cuentas de servicio y la configuración de TLS varían después de las actualizaciones, las plantillas de certificados no asignadas se vuelven a habilitar y se olvidan, y la protección de la clave privada nunca se verifica después de una migración de servidor hasta que un incidente obliga a una revisión.

¿Qué equipos deberían asumir la responsabilidad de este cambio?

Los administradores de PKI son responsables del ciclo de vida de la configuración, la cuenta de servicio y la plantilla de NDES. Los arquitectos de seguridad deciden sobre el almacenamiento de claves privadas y el aislamiento de servidores. Los equipos de plataforma e identidad gestionan la configuración del proxy inverso y TLS. Los responsables de cumplimiento y los CISO supervisan el fortalecimiento de NDES como parte del programa general de gestión de riesgos de PKI.

¿Cómo se relaciona esto con la gestión del ciclo de vida de los certificados?

Cada certificado que NDES emite para un dispositivo de red requiere un seguimiento de detección, renovación y vencimiento durante toda su vida útil. Las herramientas de gestión del ciclo de vida de los certificados, como CertSecure Manager, extienden este seguimiento a los certificados de dispositivo emitidos por NDES, en lugar de limitarse a los certificados de servidor y de usuario.

¿Cómo deberían las organizaciones medir el éxito?

El éxito se manifiesta en un almacenamiento de claves verificado y respaldado por HSM, una cuenta de servicio que aún coincide con la línea base de seguridad prevista, la aplicación de TLS 1.2+ confirmada después de cada actualización, plantillas de certificados correctamente desasignadas fuera de las ventanas de configuración y un proxy inverso actual para cualquier instancia con acceso a Internet.

¿Qué se debe auditar o supervisar periódicamente?

Auditoría de la asignación de plantillas de certificados, permisos de cuentas de servicio y política de contraseñas, configuración de escucha TLS y HTTP, ubicación de almacenamiento de claves privadas y estado de parches y configuración de cualquier proxy inverso ubicado delante de NDES.

¿Cómo afecta este tema a las infraestructuras de clave pública (PKI) en la nube, híbridas o con múltiples autoridades de certificación (CA)?

Las implementaciones híbridas que canalizan la inscripción a través de una solución MDM en la nube añaden un borde orientado a la nube que hace que el proxy inverso y los controles TLS sean más importantes, no menos. Los entornos con múltiples CA requieren que se aplique la misma disciplina de permisos y alcance de plantillas de certificados a todas las CA a las que NDES pueda acceder, no solo a la CA emisora ​​principal.

¿Qué errores comunes deben evitar los equipos?

Evite dejar las plantillas de agente de cifrado CEP y de inscripción de intercambio asignadas a la CA fuera de la configuración, ubicar NDES junto con la CA sin una regla de firewall con ámbito definido, almacenar claves privadas en software cuando se dispone de un HSM, exponer NDES directamente a Internet sin un proxy inverso y reutilizar una cuenta de servicio en otros sistemas.

¿Qué se debe renovar trimestralmente?

Esta guía es una explicación estable y siempre actualizada, por lo que la actualización completa del contenido se realiza cada seis meses en lugar de trimestralmente. Entre actualizaciones, el intervalo trimestral sigue siendo el adecuado para verificar los detalles operativos que cambian con frecuencia: permisos de la cuenta de servicio, asignación de plantillas de certificados, configuración de TLS y estado de los parches del proxy inverso.