Microsoft PKI, también conocido como Active Directory Certificate Services (ADCS), ha sido una herramienta fiable durante décadas. Pero ha llegado el momento 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 querían implantar PKI. Hoy, sin embargo, se ha convertido en una de las vulnerabilidades más importantes en la infraestructura de las organizaciones que lo utilizan.
¿Por qué es tan arriesgado? Analicemos los cinco principales riesgos de seguridad y limitaciones de Microsoft ADCS, junto con diferentes opciones para seguir adelante.
Los 5 principales obstáculos de Microsoft ADCS para satisfacer las necesidades informáticas de las empresas modernas
Desafortunadamente, en el entorno actual, Microsoft ADCS conlleva riesgos de seguridad potenciales que pueden hacer que su PKI parezca más un lastre que un componente central de su infraestructura de seguridad. Teniendo esto en cuenta, he aquí los cinco principales riesgos y limitaciones que todo equipo que utilice ADCS debería conocer:
1) ADCS tiene un don para la mala configuración
ADCS no es intrínsecamente inseguro, pero es engañosamente fácil de desconfigurar. En los últimos años, los investigadores de seguridad han encontrado varios exploits y vulnerabilidades debido a estas desconfiguraciones generalizadas, hasta el punto de que, de hecho, fue catalogado como uno de los 10 principales errores de ciberseguridad en 2023 por la NSA y CISA..
Algunos de los errores de configuración más comunes son:
- Permisos excesivos
- Plantillas de certificado mal configuradas
- Configuración insegura del control de acceso
- Vulnerabilidades en el sistema operativo Windows, NDES, etc.
Para ser claros, incluso fuera de ADCS, es posible una mala configuración con PKI cuando se emiten nuevos certificados. Dicho esto, la forma en que ADCS se configura y utiliza a menudo abre la puerta a más oportunidades de configuración errónea. Esto se debe en gran parte a que es muy difícil encontrar documentación sobre ADCS, por lo que los administradores bienintencionados que intentan encontrar orientación para evitar algunos de estos problemas a menudo no pueden hacerlo.
Por ejemplo, existen varias formas dentro de ADCS de permitir accidentalmente que las personas soliciten certificados con el contenido que deseen, lo que puede dar lugar a un ataque de escalada de privilegios, entre otros riesgos. Por ejemplo, esto significa que las personas pueden obtener un certificado que las autentique como otra persona. Del mismo modo, si nos fijamos en Microsoft NDES, hay productos de terceros que le piden que desactive las contraseñas de desafío en su punto final NDES, lo que significa que cualquiera que sepa dónde está ese punto final puede solicitar certificados con la información que desee, incluidos los identificadores de otras personas de la empresa, como su director financiero, su director general o uno de sus administradores principales. Estos son sólo dos ejemplos de los muchos que permiten contenido no verificado o insuficientemente verificado en los certificados.
2) La ADCS no está preparada para abandonar el nido
Según la encuesta sobre el estado de la nube 2023 de HashiCorpel 76% de las empresas han implantado o tienen previsto implantar una estrategia multicloud. En este contexto, Keyfactor el Ponemon Institute descubrió que el despliegue flexible es la característica más importante para las organizaciones actuales a la hora de evaluar soluciones PKI.
Pero el problema es que más de la mitad de las organizaciones afirman que su PKI existente no es capaz de soportar las nuevas aplicaciones que necesitan a medida que migran a la nube. Para muchas organizaciones, esta PKI existente es ADCS, que no funciona bien en estos entornos de nube.
En concreto, dado que ADCS se ejecuta en Active Directory, esa conexión crea retos clave cuando se intenta operar en un entorno de nube. Estos retos incluyen:
- Dificultad para soportar la contenedorización y la automatización
- Sin opciones de alta disponibilidad activo-activo (sólo activo-pasivo con servidores Microsoft Cluster).
- Imposibilidad de abrirse a puertos DCOM/RDP y otros requisitos de la red, ya que las comunicaciones en la nube requieren una variedad de puertos mucho más amplia que las locales.
3) La ADCS no habla informática moderna
PKI soporta entre 10 y 20 aplicaciones diferentes en toda la empresa de media en entornos modernos. Esto incluye desde IIS y máquinas Linux hasta equilibradores de carga y cargas de trabajo en la nube. Y cuando se compara con estos casos de uso modernos, ADCS empieza a mostrar su edad y a presentar serios desafíos.
Los casos de uso modernos en los que ADCS presenta los mayores problemas incluyen el trabajo con:
- Entornos multi-nube, multi-OS
- Dispositivos no Windows
- Protocolos modernos como ACME, EST y CMPv2
- API REST
Esto es preocupante, ya que cosas como EST y ACME son extremadamente utilizadas en los entornos basados en web de hoy en día. Las API REST también son muy comunes, y aunque Microsoft introdujo algunas API basadas en web a partir de Server 2012, no cubren todo lo que las organizaciones necesitan y son más engorrosas en escenarios multiplataforma. En general, la incapacidad de poner algo detrás de un equilibrador de carga basado en web para gestionar las solicitudes de certificados, que ofrece un enfoque más moderno para llamar a los servicios y funciones basados en la nube, es uno de los mayores obstáculos para el uso de ADCS en un entorno multi-nube 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 saldrán y encontrarán algo más que pueda hacerlo.
4) La ADCS puede ser compleja (y costosa)
ADCS puede resultar muy complejo y costoso a gran escala, principalmente porque Microsoft CA no es multiusuario. Una vez alcanzada cierta escala, se necesitan múltiples servidores y bases de datos, en algunos casos hasta 70 u 80 servidores que soporten 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 supone otra licencia de Windows Server y otro sistema del que tendrá que hacer copias de seguridad, parches y actualizaciones. Se trata de una limitación que no existe en la mayoría de las otras opciones de servicios de certificados, que ofrecen muchas formas de crear CA adicionales que no son tan costosas desde el punto de vista de la huella de TI.
Todo esto lleva a otro reto, ya que los equipos empiezan a mantener un montón de soluciones para que ADCS funcione, pero el coste de dar soporte a esas soluciones y mantenerlas a lo largo del tiempo aumenta a medida que el resto del ecosistema deja de ser compatible con ADCS. Además, se convierte en una especie de "homebrew" empresarial conocido por un puñado muy reducido de informáticos. Y a medida que la gente se va, el conocimiento sobre estas soluciones se degrada hasta un punto en el que mantenerlas en funcionamiento se convierte en un riesgo potencial.
5) La ADCS no ha cambiado mucho
La conclusión es que ADCS simplemente no ha cambiado mucho a lo largo de los años. De hecho, no ha visto ninguna actualización importante 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 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 los despliegues en las instalaciones, la emisión de certificados a cosas como SCCM o SCOM, y el apoyo a la autenticación Wi-Fi y VPN. Y sigue resolviendo muy bien esos casos de uso. Pero como no es estratégico para Microsoft, nunca ha recibido actualizaciones del mismo modo que Office, Windows OS y Azure.
Microsoft tiene actualmente una capacidad de emisión de certificados basada en la nube como parte de Intune, pero por el momento, es estrictamente para la emisión de certificados a Intune, por lo que no es un reemplazo para ADCS. Y como Microsoft sigue invirtiendo en Azure, es menos probable que veamos inversiones en todas las cosas en las instalaciones, como ADCS.
La única excepción podría ser la de los algoritmos post-cuánticos, ya que todo el sector tendrá que soportarlos una vez que las normas del NIST estén consolidadas. En la actualidad, sin embargo, ADCS no es compatible con algunos de los protocolos y formatos de certificado más recientes, como Matter, SSH y V2X.
¿Adónde vamos ahora?
ADCS era ideal para los casos de uso tradicionales en las instalaciones, pero en nuestro mundo moderno de nubes múltiples presenta serias limitaciones. Así pues, ¿cuál es el camino a seguir para las organizaciones que utilizan ADCS? Existen varias opciones:
- Situación actual: Una forma de llenar las lagunas de ADCS es emparejarla con otras soluciones para casos de uso específicos (como PKI integrada en herramientas para desarrolladores o servicios en la nube como AWS Private CA y Google Cloud CA Service). Pero tener tantos emisores diferentes también puede crear complejidad, ya que se acaba con herramientas fragmentadas que no ofrecen una visibilidad o un control coherentes.
- Aumentar: Puede aumentar 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 de todos sus diferentes emisores.
- 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.
- Migrar: Por último, puede descargar la infraestructura y el mantenimiento de PKI migrando a un servicio PKI gestionado o basado en SaaS. Este enfoque no es para todo el mundo, pero puede ser una buena opción para los equipos que ya no tienen los recursos o el ancho de banda para gestionar la PKI internamente.
En general, independientemente del enfoque que adopten los equipos, estamos asistiendo a un enorme movimiento hacia la PKI en la nube. Para realizar este cambio con éxito es necesario que los equipos adopten un enfoque más moderno de la PKI y, afortunadamente, existen muchas opciones.
¿Listo para tomar las riendas de su PKI? Nuestro equipo está listo para ayudar a su PKI a entrar en la era moderna. Conectemos.
