Podría ser el momento de reemplazar su Autoridad de Certificación de Microsoft: 4 consideraciones clave

La PKI no es solo otro Software para su organización. Es infraestructura crítica. Es el fundamento de la confianza digital que proporciona una forma fiable de controlar el acceso y conectar de forma segura dispositivos, cargas de trabajo y personas a escala. 

Como resultado, la PKI requiere una inversión y un esfuerzo considerables para su construcción y mantenimiento. Y hoy, esa inversión se está poniendo a prueba más que nunca, ya que los nuevos casos de uso, las vulnerabilidades explotadas, el fin de vida útil del Software y los riesgos futuros que plantea la tecnología cuántica están obligando a las organizaciones a replantearse sus estrategias.

Específicamente, la Microsoft PKI, más conocida como Active Directory Certificate Services (ADCS), ha sido la solución PKI de facto para muchas organizaciones desde su introducción en el año 2000. Tiene sentido: está integrada en los servidores Windows, es relativamente fácil de configurar y está bastante bien integrada con el ecosistema de Microsoft. 

Pero ya estamos en 2024, y los tiempos han cambiado. El panorama de TI es casi irreconocible en comparación con hace 20 años; el número de casos de uso y el volumen de certificados han crecido significativamente. Esta situación ha llevado a muchas organizaciones a preguntarse si es hora de reemplazar su ADCS. ¿Cuál es la respuesta? No es sencilla, pero aquí hay áreas importantes a considerar mientras evalúa las necesidades de su organización que pueden ayudarle a responder esa pregunta de una vez por todas.

¿Recuerda el año 2000? Los teléfonos se plegaban, los CD saltaban y se tardaban 10 minutos en encender el ordenador. Estábamos recién salidos de la era de las puntocom, el iPod acababa de revolucionar la música y el internet por marcación estaba muriendo lentamente. También fue el año en que Microsoft introdujo oficialmente Certificate Services, como se llamaba originalmente.

Certificate Services se basaba en listas de usuarios estáticas y autenticación NTLM. En aquel entonces, la PKI seguía siendo una infraestructura monolítica muy costosa que las organizaciones gastaban mucho dinero en instalar y poner en marcha. Pero a medida que más empresas se conectaban a internet, la necesidad de certificados aumentó, sentando las bases para una iteración muy rápida de la tecnología, en particular de la PKI.

Durante la siguiente década, los smartphones explotaron, y también lo hizo la gestión de dispositivos móviles, ya que las empresas necesitaban métodos de autenticación para asegurar que estos dispositivos pudieran ser confiables y conectarse de forma segura a la red. También tuvimos nuestro primer contacto con la computación en la nube, con la llegada al mercado de AWS, Google App Engine y Microsoft Azure.

En ese contexto, Microsoft realizó avances modestos en Certificate Services tanto en 2003 como en 2008.

En 2003, Certificate Services se integró en Active Directory y se convirtió oficialmente en ADCS. En este punto, se parecía más a una PKI que su iteración anterior y cumplía bastante bien su propósito para los casos de uso que la mayoría de las organizaciones necesitaban en ese momento. Estos eran casos de uso como añadir un certificado en este dispositivo móvil o para esa red Wi-Fi, o habilitar una buena autenticación en estaciones de trabajo gestionadas remotamente. Es importante recordar que esto fue antes de trasladar las cargas de trabajo a la nube. En aquel entonces, la nube era un mecanismo de almacenamiento más que cualquier otra cosa, ya que aún no se realizaba ningún trabajo significativo allí. 

En 2008, ADCS maduró de nuevo, con la adición del servidor NDEs, que en realidad es solo el Protocolo Simple de Inscripción de Certificados (SCEP) que ya existía desde el año 2000. SCEP fue desarrollado originalmente para obtener certificados en routers Cisco, y a medida que se extendió a un conjunto más amplio de casos de uso, amplió los límites de la seguridad.  El propósito de este cambio fue satisfacer las necesidades de los teléfonos móviles, y se convirtió en el estándar para obtener certificados en teléfonos, y comenzaron a surgir vulnerabilidades en SCEP (VU#971035 – Simple Certificate Enrollment Protocol (SCEP) no autentica fuertemente las solicitudes de certificados)

Avanzando rápidamente a la década de 2010, la nube híbrida y multi-nube irrumpieron en escena, y DevOps comenzó a afianzarse. Entramos en una era de automatización y contenerización, y eso significó que de repente se necesitaron certificados para autenticar todo tipo de dispositivos, servicios y proteger las comunicaciones máquina a máquina.

Pronto, una plétora de herramientas DevOps se construyeron alrededor de este ecosistema — incluyendo el auge de Hashicorp, Terraform y Vault, así como emisores de certificados nativos de la nube, como AWS Private CA, JetStack manager y Google CA service. Todo este crecimiento hizo que el panorama de los certificados fuera mucho más complejo. 

Aquí es realmente cuando comenzamos a expandirnos fuera de las redes corporativas y los centros de datos, avanzando hacia la nube como una nueva forma de trabajar. Y ese cambio requirió autenticación. Necesitábamos cifrado, y así surgieron protocolos como EST y ACME – para ayudar a facilitar las implementaciones en la nube. Esta es un área en la que Microsoft no se mantuvo al día. La Microsoft CA ha estado lamentablemente subdesarrollada para satisfacer estos nuevos casos de uso. En cambio, vimos adiciones iterativas de servidores y lanzamientos de características menores, pero ningún avance significativo para mantenerse al día con lo que los equipos necesitaban para tener éxito con la PKI.

Como resultado, los equipos de seguridad han tenido que enfrentarse a desafíos de gestión con certificados alojados en múltiples lugares diferentes, o han tenido que conformarse con soluciones manuales que no funcionan bien a escala. La era de la nube en la que operamos ahora se trata de la escala. Y aunque existen productos complementarios que se pueden integrar en varios entornos ADCS, los equipos siguen muy limitados por el hecho de que ADCS nunca fue diseñado para funcionar en entornos de nube.

Afortunadamente, ahora existen mejores opciones. Hemos visto la aparición de nuevas tecnologías de CA más adecuadas para la era de la nube – aquellas que no solo fueron diseñadas intencionalmente desde el principio para nuestros entornos modernos, sino que también se desarrollan continuamente en esa dirección. Todo esto es especialmente importante en la era de 2020 de fuerzas de trabajo remotas e híbridas y el uso generalizado de dispositivos IoT. Por ejemplo, estamos viendo nuevos estándares como Matter, que está marcando el ritmo para el uso de PKI para asegurar dispositivos IoT y proporcionarles identidades únicas a través de esfuerzos como la firma de firmware.

Pero en lo que respecta a la Microsoft PKI, no hubo grandes novedades en la última versión de 2022. Microsoft, sin embargo, anunció recientemente el próximo lanzamiento de Microsoft Cloud PKI, pero esta parece seguir muy centrada en las instalaciones locales. Dicho esto, no tenemos el panorama completo, ya que aún no se ha lanzado.

Ahora, tenemos más cambios en el horizonte: la migración a algoritmos post-cuánticos. Hay un nuevo conjunto de algoritmos que pronto serán estandarizados, y las organizaciones ya están analizando lo que eso significa para ellas y comenzando a prepararse para adoptarlos. Desafortunadamente, no ha habido ningún reconocimiento desde el punto de vista de ADCS sobre qué van a soportar y en qué plazos para estos nuevos algoritmos.

A través de todos estos cambios, han surgido escenarios comunes que realmente llevan a la PKI a su punto de quiebre y obligan a las empresas a considerar un cambio:

La caducidad de la raíz es simplemente inevitable y puede adoptar muchas formas. Más allá de la caducidad de su CA raíz, su CA emisora podría caducar, o sus servidores o HSMs detrás de su PKI podrían estar llegando al fin de su vida útil. Cualquiera que sea la situación, en la mayoría de los casos, requiere una reconstrucción completa de su PKI desde cero. 

Para muchas organizaciones, este escenario se presenta de la siguiente manera: La CA emisora comienza a emitir nuevos certificados que solo son válidos por 13 meses, cuando la plantilla indica que deberían ser válidos por dos años. Tras una inspección más profunda, resulta que algo en la cadena caduca en 13 meses, y una de las reglas de la PKI es que no se puede emitir un certificado que sea válido por más tiempo que la vida útil de la cadena.

Esto empieza a generar certificados truncados, lo que crea pánico en la organización y es muy disruptivo tener que dar marcha atrás y reconstruir la PKI bajo una restricción de tiempo muy específica, ya que es entonces cuando suelen ocurrir los errores.

La PKI no es solo Software, es una infraestructura crítica con una vida útil predeterminada. A menudo, esa vida útil supera la permanencia del empleado que la creó en primer lugar. Cuando esto ocurre, la PKI a menudo se transfiere a otra persona como una patata caliente, y así continúa indefinidamente.

Aunque algunas organizaciones cuentan con un equipo dedicado a las operaciones de PKI, en muchos casos es una tarea a tiempo parcial para un empleado a tiempo completo. Generalmente, observamos grandes brechas de habilidades en torno a la PKI: no se puede estudiar PKI, y no hay libros realmente buenos que aborden cómo mantener la infraestructura a diario. Como resultado, muchas organizaciones se basan en conocimientos heredados para saber cómo funciona su PKI. Pero en esos casos, cuando las personas abandonan las organizaciones y las cosas no están debidamente documentadas, surgen problemas. Y cada vez que se hace algo, se socava los cimientos de la seguridad, lo que deja a su organización en una situación vulnerable. No es la intención de nadie degradar la seguridad, pero eso es lo que ocurre cuando se siguen aplicando soluciones temporales y añadiendo nuevos casos de uso sobre una base deficiente.

A medida que crece el volumen y la velocidad de emisión de certificados, los equipos necesitan más protocolos, integraciones e infraestructura para soportarlo. Y en muchos casos —especialmente en los últimos tiempos entre los equipos que dependen de ADCS— la PKI simplemente no puede soportar esos casos de uso.

Esto ha llevado a las organizaciones a implementar soluciones puntuales según sea necesario, lo que nos ha traído al punto en que los equipos tienen ahora un promedio de nueve soluciones PKI/CA. Si todo se gestiona correctamente, este número puede ser aceptable, pero en la mayoría de las organizaciones, existen puntos de emisión dispares para certificados que surgieron para necesidades muy específicas. Cuando no hay una solución integral en toda la organización, los problemas de crecimiento se vuelven muy comunes, y es difícil entender el origen de las cosas y por qué se están tomando ciertas medidas.

Idealmente, las organizaciones deberían tener dos fuentes de emisión de certificados: una para todos los recursos internos y otra para aquellos que necesitan ser arraigados públicamente, como SSL/TLS. Si se puede consolidar esa infraestructura tanto como sea posible, se reduce el riesgo, el coste y el mantenimiento de tener que mantener su PKI.

Basta una sola vulnerabilidad para que todo se desmorone. Según un informe reciente de la NSA y CISA, una de las diez principales configuraciones erróneas de ciberseguridad son las implementaciones de ADCS inseguras. 

Desafortunadamente, existen muchos puntos de configuración errónea conocidos que pueden hacer que ADCS sea inseguro. En general, es muy fácil cometer errores, ya sea debido a otras distracciones o a errores inocentes como configurar la inscripción automática para un determinado tipo de certificado que otorga accidentalmente a todos en la organización un certificado de firma de código. 

Estos casos ocurren con demasiada frecuencia y crean graves vulnerabilidades en la infraestructura, obligando a las organizaciones a replantearse toda su configuración.

Si es el momento o no de reemplazar su PKI es algo que cada organización debe responder por sí misma, pero es algo que idealmente se puede determinar antes de llegar a un punto de inflexión que le obligue a actuar.

Como resultado, si ve que su organización se dirige hacia uno de los escenarios comunes anteriores —lo cual puede ser muy probable si su base se asienta en ADCS, que no fue diseñado para la escala, la velocidad o los casos de uso basados en la nube que exige el entorno actual— la respuesta bien podría ser sí.

¿Listo para tomar el control de su PKI? Marque en su calendario la serie de seminarios web de Keyfactor, que explora los riesgos y limitaciones del uso de la PKI de Microsoft en la actualidad y cómo las organizaciones están migrando a alternativas modernas.