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

PKI is not just another software for your organization. It’s critical infrastructure. It’s the foundation of digital trust that provides a reliable way to control access and securely connect devices, workloads, and people at scale. 

As a result, PKI requires serious investment and effort to build and maintain. And today, that investment is being tested more than ever as new use cases, vulnerability exploits, software end-of-life, and future risks posed by quantum technology are forcing organizations to rethink their strategies.

Specifically, Microsoft PKI, which is better known as Active Directory Certificate Services (ADCS), has been the de facto PKI solution for many organizations since it was first introduced in 2000. It makes sense: It’s baked into Windows Servers, it’s relatively easy to set up, and it’s pretty well integrated with the Microsoft ecosystem. 

But it’s 2024 now, and times have changed. The IT landscape is almost unrecognizable from 20 years ago; the number of use cases and the sheer volume of certificates has grown significantly. This situation has led many organizations to ask if it’s time to replace their ADCS. So what’s the answer? It’s not cut and dry, but here are important areas to consider as you evaluate your organization’s needs that can help you answer that question once and for all.

Cómo ha evolucionado el papel de la PKI desde el lanzamiento de ADCS

¿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í. 

In 2008, ADCS matured again, with the addition of NDEs server, which is really just Simple Certificate Enrollment Protocol (SCEP) that had actually been around since 2000. SCEP was originally developed for getting certificates on Cisco routers, and as it was extended to a larger set of use cases, it pushed the boundaries of security.  The purpose of this change was to meet the needs of mobile phones, and it became the standard for getting certificates on phones and vulnerabilities in SCEP started to surface (VU#971035 – Simple Certificate Enrollment Protocol (SCEP) does not strongly authenticate certificate requests)

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. 

This is really when we started to expand outside of corporate networks and data centers, progressing into the cloud as a new way of working. And that shift required authentication. We needed encryption, and that’s how protocols like EST and ACME came about – to help facilitate cloud deployments. This is an area with which Microsoft did not keep up. The Microsoft CA has been woefully underdeveloped to meet these new use cases. Instead, we saw iterative server additions and minor feature releases but no major uptick to stay current with what teams needed to be successful with PKI.

As a result, security teams have either had to face management challenges with certificates living in multiple different places, or they’ve had to make do with manual solutions that don’t work well at scale. The cloud era in which we now operate is all about scale. And while there are add-on products you can plug into various ADCS environments, teams are still very much constrained by the fact that ADCS was never designed to work in cloud environments.

Fortunately, better options now exist. We’ve seen the emergence of new CA technologies better suited for the cloud era – ones that were not only designed intentionally from the start for our modern environments, but that are also continually developed in that direction. All of this is especially important in the 2020s era of remote and hybrid workforces and the widespread use of IoT devices. For example, we’re seeing new standards like Matter, which is setting the pace for PKI usage to secure IoT devices and provide unique identities for them through efforts like firmware signing.

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.

Now, we have more change on the horizon: the migration to post-quantum algorithms. There’s a new set of algorithms that are soon to be standardized, and organizations are already looking at what that means for them and starting to prepare to adopt them. Unfortunately, there has been no acknowledgment from an ADCS standpoint of what they are going to support against what timelines for these new algorithms.

4 escenarios comunes que llevan a la PKI a su punto de quiebre

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:

1) Caducidad de la raíz o fin de vida útil

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.

So that starts to drive truncated certificates, which creates panic in the organization, and it is very disruptive to have to turn around and rebuild PKI under a very specific time constraint because that’s when mistakes tend to happen.

2) Rotación de empleados y brechas de habilidades

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.

While some organizations have a dedicated team behind PKI operations, in many cases it’s a part-time job for a full-time employee. Generally, we see big skills gaps around PKI: you can’t go to school for PKI, and there aren’t any really great books that address how to care for your infrastructure daily. As a result, a lot of organizations work on legacy knowledge to know how their PKI is run. But in those cases, when people leave organizations and things aren’t documented properly, problems ensue. And every time you do something, you chip away at the foundation of security, which leaves your organization in a bad place. It’s not anyone’s intention to degrade the security, but that’s what happens when you keep applying band-aids and adding new use cases on top of a failing foundation.

3) Problemas de crecimiento

As the volume and velocity of certificate issuance grows, teams need more protocols, integrations, and infrastructure to support that. And in many cases – especially recently among teams relying on ADCS – the PKI simply can’t support those use cases.

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.

4) Riesgo (conocido y desconocido)

All it takes is one vulnerability for it all to fall apart. According to a recent report from the NSA and CISA, one of the top ten cybersecurity misconfigurations is insecure ADCS deployments. 

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.

¿Es hora de reemplazar su PKI?

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 que puede ser muy probable si su base se basa 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 puede ser muy bien sí.

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