Cinco cosas que debe saber sobre Microsoft PKI

Microsoft PKI, aka Active Directory Certificate Services (ADCS), has been a reliable tool for decades. But it’s time to say goodbye.

Durante varios años después de su lanzamiento inicial a principios de la década de 2000, ADCS fue la 'opción segura' (o, en algunos casos, la única opción) para las organizaciones que buscaban implementar una PKI. Hoy, sin embargo, se ha convertido en una de las vulnerabilidades más significativas en la infraestructura de las organizaciones que la utilizan.

¿Por qué es tan arriesgado exactamente? Profundicemos en los cinco principales riesgos de seguridad y limitaciones de Microsoft ADCS, junto con diferentes opciones para avanzar.

Las 5 principales barreras de Microsoft ADCS para satisfacer las necesidades de TI de las empresas modernas

Lamentablemente, en el entorno actual, Microsoft ADCS conlleva riesgos de seguridad potenciales que pueden hacer que su PKI se perciba más como una vulnerabilidad que como un componente central de su infraestructura de seguridad. Teniendo esto en cuenta, a continuación se presentan los cinco principales riesgos y limitaciones que todo equipo que utilice ADCS debería conocer:

1) ADCS es propenso a la mala configuración

ADCS is not inherently insecure, but it is deceptively easy to misconfigure. Over the past few years, security researchers have found several exploits and vulnerabilities due to these widespread misconfigurations, to the point where it was actually listed as one of the top 10 cybersecurity misconfigurations in 2023 by the NSA and CISA.

Algunas de las configuraciones incorrectas más comunes incluyen:

• Permisos excesivos
• Plantillas de certificado mal configuradas
• Configuración de control de acceso insegura
• Vulnerabilidades en el sistema operativo Windows, NDES, etc.

Para ser claros, incluso fuera de ADCS, la PKI puede presentar configuraciones erróneas al emitir nuevos certificados. Dicho esto, la forma en que ADCS se configura y utiliza con frecuencia suele abrir la puerta a más oportunidades de errores de configuración. Esto se debe en gran parte a la dificultad de encontrar documentación sobre ADCS, lo que impide a los administradores con buenas intenciones hallar la orientación necesaria para evitar algunos de estos desafíos.

Por ejemplo, existen varias formas dentro de ADCS de permitir accidentalmente que los usuarios soliciten certificados con el contenido que deseen, lo que puede conducir a un ataque de escalada de privilegios, entre otros riesgos. Esto significa que los individuos pueden obtener un certificado que los autentique como otra persona. De manera similar, en el contexto de Microsoft NDES, hay productos de terceros que solicitan desactivar las contraseñas de desafío en su punto final NDES, lo que implica que cualquiera que conozca la ubicación de dicho punto final puede solicitar certificados con la información que desee, incluyendo identificadores de otras personas de la empresa, como su director financiero, su director ejecutivo o uno de sus administradores principales. Estos son solo dos ejemplos de las muchas situaciones que permiten contenido no verificado o insuficientemente verificado en los certificados.

2) ADCS no está listo para salir del nido

According to the 2023 State of Cloud survey by HashiCorp, 76% of companies have or plan to implement a multi-cloud strategy. Against this backdrop, Keyfactor and the Ponemon Institute found that flexible deployment is the most important feature for today’s organizations when evaluating PKI solutions.

Sin embargo, el problema radica en que más de la mitad de las organizaciones afirman que su PKI actual no es capaz de soportar las nuevas aplicaciones que requieren a medida que migran a la nube. Para muchas organizaciones, esta PKI existente es ADCS, la cual no funciona eficazmente en estos entornos de nube. 

Específicamente, dado que ADCS se ejecuta sobre Active Directory, esta conexión genera desafíos fundamentales al intentar operar en un entorno de nube. Estos desafíos incluyen:

• Dificultad para soportar la contenerización y la automatización
• Sin opciones de alta disponibilidad activo-activo (solo activo-pasivo con servidores de clúster de Microsoft)
• Incapacidad para abrir puertos DCOM/RDP y cumplir otros requisitos de red, ya que las comunicaciones en la nube exigen una variedad de puertos mucho más amplia que en entornos locales. 

3) ADCS no se adapta a la TI moderna

La PKI soporta, en promedio, entre 10 y 20 aplicaciones diferentes en toda la empresa en entornos modernos. Esto abarca desde máquinas IIS y Linux hasta balanceadores de carga y cargas de trabajo en la nube. Y al enfrentarse a estos casos de uso modernos, ADCS comienza a mostrar su antigüedad y a presentar serios desafíos. 

Los casos de uso modernos donde ADCS presenta los mayores problemas incluyen el trabajo con:

• Entornos multinube y multi-SO
• Dispositivos no Windows
• Protocolos modernos como ACME, EST y CMPv2
• API REST

Esto es preocupante, ya que tecnologías como EST y ACME se utilizan de forma extremadamente extendida en los entornos web actuales. Las API REST también son muy comunes, y aunque Microsoft introdujo algunas API basadas en web a partir de Server 2012, estas no cubren todas las necesidades de las organizaciones y resultan más engorrosas en escenarios multiplataforma. En general, la incapacidad de colocar algo detrás de un balanceador de carga basado en web para gestionar las solicitudes de certificados, lo que ofrecería un enfoque más moderno para invocar servicios y funciones basados en la nube, es uno de los mayores obstáculos para utilizar ADCS en un entorno multinube o de nube híbrida. A su vez, aquí es donde se origina gran parte de la proliferación de PKI, porque si su PKI actual no puede soportar casos de uso clave, los equipos buscarán otras soluciones que sí puedan hacerlo.

4) ADCS puede volverse complejo (y costoso)

ADCS puede volverse muy complejo y costoso a escala, principalmente porque Microsoft CA no es multi-inquilino. Una vez que se alcanza una cierta escala, se necesitan múltiples servidores y bases de datos, en algunos casos hasta 70 u 80 servidores para soportar la PKI. 

Esto se debe a que ADCS le limita a una CA por máquina, lo que significa que si necesita instalar más CA —ya sea para gestionar la escala o para diferentes casos de uso, segmentos de red, límites de confianza o cualquier otra cosa—, necesitará al menos otra máquina virtual, lo que implica otra licencia de Windows Server y otro sistema que deberá respaldar, parchear y actualizar. Esta es una limitación que realmente no existe en la mayoría de las otras opciones para servicios de certificados, las cuales ofrecen muchas formas de implementar CA adicionales que no son tan costosas desde la perspectiva de la huella de TI.

Todo esto conduce a otro desafío, ya que los equipos comienzan a mantener una gran cantidad de soluciones alternativas para que ADCS funcione, pero el costo de soportar y mantener esas soluciones a lo largo del tiempo aumenta a medida que el resto del ecosistema evoluciona y pierde compatibilidad con ADCS. Además, se convierte en una especie de "solución casera" empresarial conocida por un puñado muy reducido de personal de TI. Y a medida que la gente se va, el conocimiento sobre estas soluciones alternativas se degrada hasta el punto de que mantenerlas en funcionamiento se convierte en un riesgo potencial.

5) ADCS no ha cambiado mucho

En resumen, ADCS simplemente no ha cambiado mucho a lo largo de los años. De hecho, no ha recibido actualizaciones importantes desde Server 2012. Esto significa que, a medida que surgen nuevos estándares y casos de uso, los usuarios de ADCS se quedan sin soporte y se ven obligados a buscar soluciones alternativas o a cambiar a otras opciones.

ADCS nunca ha sido una pieza estratégica de Software para Microsoft; más bien, ha sido un medio para un fin, para resolver ciertos casos de uso, como implementaciones locales, la emisión de certificados para elementos como SCCM o SCOM, y el soporte de autenticación Wi-Fi y VPN. Y sigue resolviendo esos casos de uso muy bien. Pero, dado que no es estratégico para Microsoft, nunca ha recibido actualizaciones de la misma manera que Office, Windows OS y Azure.

Actualmente, Microsoft cuenta con una capacidad de emisión de certificados basada en la nube como parte de Intune, pero por el momento, esta es estrictamente para emitir certificados a Intune, por lo que no es un reemplazo para ADCS. Y a medida que Microsoft continúa invirtiendo en Azure, es menos probable que veamos inversiones en todo lo que es local, como ADCS. 

La única excepción aquí podría ser para los algoritmos postcuánticos, ya que toda la industria necesitará soportar la criptografía postcuántica una vez que los estándares del NIST se consoliden. Sin embargo, actualmente, ADCS no soporta algunos de los protocolos y formatos de certificado más recientes como Matter, SSH y V2X.

¿Qué camino tomamos a partir de ahora?

ADCS fue una excelente opción para casos de uso tradicionales y locales, pero en nuestro mundo moderno y multinube, presenta serias limitaciones. Entonces, ¿cómo se presenta el camino a seguir para las organizaciones que utilizan ADCS? Hay varias opciones:

• Status quo: One way to fill the gaps of ADCS is to pair it with other solutions for specific use cases (such as PKI built into developer tools or cloud services like AWS Private CA and Google Cloud CA Service). But having so many different issuers can also create complexity, as you wind up with fragmented tools that don’t offer consistent visibility or control.
• Augment: You can augment your ADCS alongside those other PKI solutions with certificate management, which offers a standardized interface and central place to gain visibility and control across all your different issuers.

• Modernize: Taking it one step further, you can simplify and consolidate onto a modern PKI alternative. A modern solution (like Keyfactor’s EJBCA) can support the diversity of current environments, including use cases, platforms, and cloud services found in enterprises today. These important capabilities allow for a smooth migration to a multi-cloud environment and support more modern protocols. If you’re ready to learn more about modernizing, contact Keyfactor here.
• Migrate: Finally, you can offload the infrastructure and maintenance of PKI by migrating to a SaaS-based or managed PKI service. This approach isn’t for everyone, but it can be a good fit for teams who don’t have the resources or bandwidth to run PKI in-house anymore.

En general, independientemente del enfoque que adopten los equipos, estamos viendo un gran movimiento hacia la PKI en la nube. Realizar este cambio con éxito requiere que los equipos adopten un enfoque más moderno de la PKI y, afortunadamente, existen muchas opciones.

Ready to take charge of your PKI? Our team is ready to help your PKI enter the modern age. Let’s connect.