Cinco cosas que debe saber sobre Microsoft PKI

La PKI de Microsoft, también conocida como Active Directory Certificate Services (ADCS), ha sido una herramienta fiable durante décadas. Pero es hora de decir adiós.

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.

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:

ADCS no es inherentemente inseguro, pero es engañosamente fácil de configurar incorrectamente. En los últimos años, los investigadores de seguridad han encontrado varias vulnerabilidades y exploits debido a estas configuraciones incorrectas generalizadas, hasta el punto de que fue incluido entre las 10 principales configuraciones erróneas de ciberseguridad en 2023 por la NSA y 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.

Según la encuesta State of Cloud 2023 de HashiCorp, el 76 % de las empresas tienen o planean implementar una estrategia multinube. En este contexto, Keyfactor y el Ponemon Institute descubrieron que la implementación flexible es la característica más importante para las organizaciones actuales al evaluar soluciones PKI.

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. 

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.

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.

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.

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: Una forma de cubrir las deficiencias de ADCS es combinarlo con otras soluciones para casos de uso específicos (como PKI integrada en herramientas de desarrollo o servicios en la nube como AWS Private CA y Google Cloud CA Service). Pero tener tantos emisores diferentes también puede generar complejidad, ya que se termina con herramientas fragmentadas que no ofrecen visibilidad ni control consistentes.

• Aumentar: Puede complementar su ADCS junto con esas otras soluciones PKI con la gestión de certificados, que ofrece una interfaz estandarizada y un lugar central para obtener visibilidad y control sobre todos sus diferentes emisores.

• Modernizar: Dando un paso más, puede simplificar y consolidar en una alternativa PKI moderna. Una solución moderna (como Keyfactor's EJBCA) puede soportar la diversidad de entornos actuales, incluyendo casos de uso, plataformas y servicios en la nube que se encuentran en las empresas hoy en día. Estas importantes capacidades permiten una migración sin problemas a un entorno multicloud y son compatibles con protocolos más modernos. Si está listo para obtener más información sobre la modernización, póngase en contacto con Keyfactor aquí.
• Migrar: Finalmente, puede descargar la infraestructura y el mantenimiento de la PKI migrando a un servicio PKI gestionado o basado en SaaS. Este enfoque no es para todos, pero puede ser una buena opción para los equipos que ya no disponen de los recursos o la capacidad para gestionar la PKI internamente.

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.

¿Listo para tomar el control de su PKI? Nuestro equipo está preparado para ayudar a su PKI a entrar en la era moderna. Conectemos.