PKI no es sólo otro software para su organización. Es una infraestructura crítica. Es la base 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.
En consecuencia, la creación y el mantenimiento de PKI requieren una inversión y un esfuerzo considerables. Y hoy en día, esa inversión se está poniendo a prueba más que nunca a medida que surgen nuevos casos de uso, explotaciones de vulnerabilidades, el fin de la vida útil de software y los futuros riesgos que plantea la tecnología cuántica. tecnología cuántica obligan a las organizaciones a replantearse sus estrategias.
Específicamente, Microsoft PKI, más conocido como Active Directory Certificate Services (ADCS), ha sido la solución PKI de facto para muchas organizaciones desde que se introdujo por primera vez en el año 2000. Tiene sentido: está integrada en los servidores Windows, es relativamente fácil de configurar y está bastante bien integrada en el ecosistema de Microsoft.
Pero estamos en 2024 y los tiempos han cambiado. El panorama informático es casi irreconocible al de hace 20 años; el número de casos de uso y el mero volumen de certificados han crecido significativamente. Esta situación ha llevado a muchas organizaciones a preguntarse si ha llegado el momento de sustituir su ADCS. ¿Cuál es la respuesta? No es fácil, pero hay aspectos importantes que debe tener en cuenta a la hora de evaluar las necesidades de su empresa y que pueden ayudarle a responder a esa pregunta de una vez por todas.
Cómo ha evolucionado el papel de la PKI desde el lanzamiento de ADCS
¿Recuerdas el año 2000? Los teléfonos saltaban, los CD saltaban y el ordenador tardaba 10 minutos en arrancar. Estábamos en plena era de las puntocom, el iPod acababa de revolucionar la música e Internet por línea telefónica estaba muriendo lentamente. También fue el año en que Microsoft presentó oficialmente Certificate Services, como se llamaba originalmente.
Certificate Services se basaba en listas de usuarios estáticas y autenticación NTLM. En aquella época, la PKI seguía siendo una infraestructura monolítica muy cara que las organizaciones gastaban mucho dinero en instalar y poner en funcionamiento. Pero a medida que más empresas se conectaban a Internet, aumentaba la necesidad de certificados, lo que sentó las bases para una iteración muy rápida de la tecnología, en particular de PKI.
Durante la década siguiente, los smartphones se dispararon, y también lo hizo la gestión de dispositivos móviles, ya que las empresas necesitaban métodos de autenticación para garantizar que estos dispositivos fueran de confianza y se conectaran de forma segura a la red. También conocimos la computación en la nube, con la llegada al mercado de AWS, Google App Engine y Microsoft Azure.
En este contexto, Microsoft introdujo modestos avances en los servicios de certificación tanto en 2003 como en 2008.
En 2003, Certificate Services se integró en Active Directory y se convirtió oficialmente en ADCS. En ese momento, se parecía más a una PKI que su iteración anterior y servía bastante bien para los casos de uso que la mayoría de las organizaciones necesitaban en ese momento. Se trataba de 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 de forma remota. Es importante recordar que esto era antes de trasladar las cargas de trabajo a la nube. Por aquel entonces, la nube era más un mecanismo de almacenamiento que otra cosa, ya que aún no se realizaba ningún trabajo significativo en ella.
En 2008, ADCS maduró de nuevo, con la adición del servidor NDEs, que en realidad no es más que Simple Certificate Enrollment Protocol (SCEP) que en realidad existía desde el año 2000. SCEP se desarrolló originalmente para obtener certificados en los routers Cisco y, al extenderse a un conjunto más amplio de casos de uso, amplió los límites de la seguridad. El propósito de este cambio era satisfacer las necesidades de los teléfonos móviles, y se convirtió en el estándar para obtener certificados en los teléfonos y las vulnerabilidades en SCEP comenzaron a surgir (VU#971035 - Simple Certificate Enrollment Protocol (SCEP) does not strongly authenticate certificate requests)
En la década de 2010, la nube híbrida y múltiple entró en escena y DevOps comenzó a afianzarse. Entramos en la era de la automatización y la contenedorización, lo que supuso la repentina necesidad de certificados para autenticar todo tipo de dispositivos y servicios y proteger las comunicaciones entre máquinas.
Pronto se creó una plétora de herramientas DevOps en torno a este ecosistema, incluido 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 ha hecho que el panorama de los certificados sea mucho más complejo.
Fue entonces cuando empezamos 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 requería autenticación. Necesitábamos cifrado, y así es como surgieron protocolos como EST y ACME, para ayudar a facilitar las implantaciones en la nube. Este es un campo en el que Microsoft no ha estado a la altura. El sitio Microsoft CA ha estado lamentablemente subdesarrollado para satisfacer estos nuevos casos de uso. En su lugar, vimos adiciones iterativas de servidores y lanzamientos de características menores, pero ningún aumento importante para mantenerse al día con lo que los equipos necesitaban para tener éxito con PKI. tener éxito con PKI.
Como resultado, los equipos de seguridad han tenido que enfrentarse a retos de gestión con certificados que viven en varios lugares diferentes, o han tenido que conformarse con soluciones manuales que no funcionan bien a escala. En la era de la nube en la que nos movemos, todo gira en torno a la escala. Y aunque hay productos complementarios que se pueden conectar a varios entornos ADCS, los equipos siguen muy limitados por el hecho de que ADCS nunca se diseñó para funcionar en entornos de nube.
Afortunadamente, ahora existen mejores opciones. Hemos asistido a la aparición de nuevas tecnologías de CA mejor adaptadas a la era de la nube, que no sólo se diseñaron intencionadamente desde el principio para nuestros entornos modernos, sino que además se desarrollan continuamente en esa dirección. Todo esto es especialmente importante en la era 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 del uso de PKI para proteger los dispositivos IoT y proporcionarles identidades únicas mediante iniciativas como la firma de firmware.
Pero en lo que respecta a Microsoft PKI, no ha ocurrido gran cosa en la última versión de 2022. Sin embargo, Microsoft ha anunciado recientemente el próximo lanzamiento de Microsoft Cloud PKI, pero sigue estando muy centrado en las instalaciones. Dicho esto, no tenemos la imagen completa, 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 se estandarizarán, y las organizaciones ya están estudiando lo que eso significa para ellas y empezando a prepararse para adoptarlos. Desgraciadamente, no se ha reconocido desde el punto de vista de ADCS lo que van a soportar y en qué plazos para estos nuevos algoritmos.
4 Escenarios comunes que llevan a la PKI a su punto de ruptura
A través de todos estos cambios, han surgido escenarios comunes que realmente llevan a PKI a su punto de ruptura y obligan a las empresas a plantearse un cambio:
1) Expiración de la raíz o fin de la vida útil
La caducidad de la raíz es simplemente inevitable, y puede tomar muchas formas. Además de la caducidad de su CA raíz, su CA emisora podría caducar, o los servidores o HSM de su PKI podrían estar llegando al final de su vida útil. Sea cual sea la situación, en la mayoría de los casos requiere una reconstrucción completa de la PKI desde cero.
Para muchas organizaciones, este escenario se parece a esto: La CA emisora empieza a emitir nuevos certificados que sólo son viables durante 13 meses cuando la plantilla dice que deberían ser válidos durante 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 PKI es que no se puede emitir un certificado que sea válido durante más tiempo que la vida útil de la cadena.
Así que eso empieza a conducir certificados truncados, lo que crea pánico en la organización, y es muy perjudicial tener que dar la vuelta y reconstruir PKI bajo una ...bajo una restricción de tiempo muy específica... porque es cuando los errores tienden a suceder.
2) Rotación de empleados y falta de competencias
PKI no es sólo software, es una infraestructura crítica con una vida útil predeterminada. A menudo, esa vida útil supera el mandato del empleado que la creó en primer lugar. Cuando eso ocurre, la PKI suele ser arrojada como una patata caliente al regazo de otra persona, y así continúa a partir de ahí.
Aunque algunas organizaciones cuentan con un equipo dedicado a las operaciones de PKI, en muchos casos se trata de un trabajo a tiempo parcial para un empleado a tiempo completo. En general, vemos grandes lagunas de competencias en torno a la PKINo se puede ir a la escuela para aprender PKI, y no hay grandes libros que traten sobre cómo cuidar de la infraestructura a diario. Como resultado, muchas organizaciones trabajan con conocimientos heredados para saber cómo funciona su PKI. Pero en esos casos, cuando la gente deja las organizaciones y las cosas no se documentan adecuadamente, surgen los problemas. Y cada vez que se hace algo, se astillan los cimientos de la seguridad, lo que deja a la organización en mal lugar. No es la intención de nadie degradar la seguridad, pero eso es lo que pasa cuando sigues aplicando tiritas y añadiendo nuevos casos de uso sobre unos cimientos que fallan.
3) Problemas de crecimiento
A medida que crecen 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 recientemente entre los equipos que confían en ADCS- la PKI simplemente no puede soportar esos casos de uso.
Esto ha llevado a las organizaciones a implantar soluciones puntuales según las necesidades, lo que nos ha llevado al punto en el que los equipos tienen ahora una media de nueve soluciones PKI/CA. Si todo se gestiona adecuadamente, este número puede estar bien, pero en la mayoría de las organizaciones existen puntos de emisión de certificados dispares que surgieron para necesidades muy específicas. Cuando no existe una solución integral en toda una organización, los dolores de crecimiento se vuelven muy comunes, y es difícil entender de dónde vienen las cosas y por qué están tomando ciertas acciones.
Lo ideal sería que las organizaciones contaran con dos fuentes de emisión de certificados: una para todos los recursos internos y otra para los que necesitan estar arraigados públicamente, como SSL/TLS. Si se puede consolidar esa infraestructura en la medida de lo posible, se reduce el riesgo, el coste y el mantenimiento de tener que mantener la PKI.
4) Riesgo (tanto conocido como desconocido)
Basta una vulnerabilidad para que todo se venga abajo. Según un informe reciente de la NSA y CISAuno de los diez principales errores de ciberseguridad son los despliegues inseguros de ADCS.
Por desgracia, hay muchos puntos conocidos de configuración errónea que pueden hacer que ADCS sea inseguro. Por lo general, es muy fácil cometer errores, ya sea debido a otras distracciones o errores inocentes como la configuración de la auto-inscripción para un determinado tipo de certificado que accidentalmente da 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.
¿Ha llegado el momento de sustituir su PKI?
Si ha llegado o no el momento de sustituir su PKI es algo que cada organización tiene que responder por sí misma, pero es algo que idealmente puede determinar antes de llegar a un punto de ruptura 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 utilizar Microsoft PKI en la actualidad y cómo las organizaciones están migrando a alternativas modernas.
