Lecciones de un diseño PKI moderno y exitoso

Cuando una infraestructura de clave pública (PKI) ha permanecido sin cambios durante más de una década, la pregunta rara vez es si se necesitan mejoras, sino por dónde empezar. Esa era la situación de una de las mayores cadenas minoristas de productos para el estilo de vida rural en Estados Unidos, fundada en 1938 y que actualmente opera más de 2,000 tiendas en 49 estados. La empresa atiende a millones de clientes con productos cotidianos para el hogar, la tierra, las mascotas y el cuidado de los animales, y depende de una sólida infraestructura digital para mantener la confianza y la consistencia del servicio.

¿Qué es un diseño PKI moderno? Un diseño PKI moderno reemplaza una Autoridad de Certificación (CA) obsoleta con una jerarquía de CA raíz y emisora ​​respaldada por HSM, periodos de validez de certificados definidos, publicación consistente de CRL y OCSP, y gobernanza centralizada. Este caso práctico muestra cómo una cadena minorista estadounidense con 2,000 tiendas utilizó este enfoque para subsanar las deficiencias de almacenamiento, revocación y control de acceso de claves en una PKI con una década de antigüedad.

Resumen Ejecutivo

• Una cadena minorista estadounidense con 2,000 tiendas rediseñó una infraestructura de clave pública que había permanecido prácticamente sin cambios durante más de una década.
• El rediseño sustituyó las claves privadas no protegidas basadas en software por un almacenamiento respaldado por HSM para las CA raíz y emisoras.
• Se estandarizó la duración de los certificados y las listas de revocación de certificados (CRL), y se introdujeron por primera vez autoridades de certificación dedicadas a la recuperación ante desastres.
• La gobernanza se reconstruyó en torno a plantillas de certificados documentadas y derechos de emisión basados ​​en roles.
• El resultado es una infraestructura de clave pública (PKI) escalable y auditable, diseñada para respaldar la automatización y la agilidad criptográfica en el futuro.

Por qué esta empresa necesitaba un diseño PKI moderno

Como parte de una iniciativa más amplia para fortalecer su seguridad informática, la organización realizó una evaluación detallada de su infraestructura de clave pública (PKI) . La evaluación reveló rápidamente que la infraestructura existente presentaba varios riesgos, como periodos de validez de las autoridades de certificación (CA) sin control, intervalos de publicación de listas de revocación de certificados (CRL) irregulares y claves privadas almacenadas en máquinas basadas en software. Estos hallazgos evidenciaron la necesidad de un enfoque estructurado en lugar de una serie de soluciones puntuales.

En lugar de solucionar los problemas de forma reactiva, el equipo elaboró ​​una hoja de ruta personalizada para abordar los riesgos principales y reducir la superficie de ataque del entorno PKI existente. En vez de pasar directamente a la implementación, la organización optó por un enfoque más metódico: diseñar primero la PKI. Esto les permitió definir la arquitectura del nuevo entorno, determinar el papel de la PKI existente durante la transición, identificar el punto de partida adecuado y establecer un plan de migración estructurado. El objetivo era aportar claridad, simplificar la gestión y construir una PKI sostenible, equipada con tecnologías modernas y alineada con los estándares de seguridad actuales.

Al fin y al cabo, no se construye una bóveda bancaria sin planos, entonces, ¿por qué construir una infraestructura de clave pública (PKI) sin un diseño previo?

El diseño de la infraestructura de clave pública (PKI) se concretó mediante múltiples sesiones de trabajo exhaustivas y debates técnicos con las partes interesadas de toda la organización. Estas sesiones establecieron una jerarquía de confianza clara entre las autoridades de certificación raíz y emisoras, alinearon la arquitectura con el diseño del bosque de Active Directory y optimizaron la gestión del ciclo de vida de los certificados para los usuarios, dispositivos y escenarios de aplicación de la organización. La arquitectura resultante se personalizó para dar soporte a la estructura de dominios de Active Directory distribuidos de la empresa, de modo que los casos de uso y los flujos de trabajo operativos de cada dominio se reflejaran en el diseño final.

Desafíos comunes en entornos PKI heredados

Antes de analizar qué problemas solucionó el nuevo diseño, conviene comprender por qué era necesaria dicha solución. La infraestructura de clave pública (PKI) de la organización se ejecutaba en una infraestructura obsoleta, alojada principalmente en Windows Server 2012 R2. Una revisión exhaustiva de las políticas, los procedimientos y los estándares de PKI existentes reveló las siguientes deficiencias arquitectónicas y operativas.

Brechas en la cadena de confianza y la recuperación ante desastres

• La cadena de confianza PKI se construyó alrededor de una única raíz Autoridad de certificación (CA) y varias CA emisoras, pero no existía una estrategia formal de respaldo o recuperación ante desastres para ninguna de ellas. Un fallo de la CA o una interrupción del centro de datos habría dejado a la organización sin una vía fiable para restablecer la emisión de certificados.

Riesgos relacionados con el almacenamiento de claves privadas y la vida útil de los certificados

• Las claves privadas de la CA raíz y de la CA emisora ​​se almacenaron sin la protección de un Módulo de seguridad de hardware (HSM)Como lo expresó un ingeniero de seguridad sénior del proyecto: “Eso es como guardar las joyas de la corona bajo llave en un archivador.” La ausencia de protección HSM aumentó significativamente el riesgo de robo o vulneración de claves.
• El certificado de CA raíz tenía un período de validez de más de 20 años, mucho más allá. Foro CA / B Recomendaciones. Los certificados con una vida útil tan larga amplían el radio de impacto potencial si una clave se ve comprometida y limitan la capacidad de la organización para adaptarse criptográficamente con el tiempo.

Brechas en la infraestructura, la lista de revocación de certificados (CRL) y la gestión de puntos finales.

• El bosque de Active Directory seguía ejecutando una versión antigua de Windows Server que había llegado al final de su ciclo de vida (EOL) y al final de su soporte (EOS), lo que impedía la integración con capacidades PKI más recientes, como la inscripción automática de certificados, las plantillas criptográficas modernas y los controles de emisión basados ​​en políticas.
• Los periodos de validez de las CRL se configuraron de forma inconsistente en las tres CA emisoras, superando los 7 días para las CRL base y las 24 horas para las CRL delta. Esta inconsistencia generó gastos operativos y aumentó el riesgo de que los errores relacionados con la revocación pasaran desapercibidos sin una supervisión manual constante.
• Se utilizaban varias plataformas de gestión de dispositivos móviles (MDM) para administrar diferentes tipos de dispositivos, con dispositivos Android, macOS e iOS distribuidos en sistemas separados. Esta configuración fragmentada de MDM añadía complejidad e ineficiencia innecesarias a la implementación de certificados y la confianza en los puntos finales.

Gobernanza, control de acceso y proliferación de plantillas

• En la configuración de seguridad de las tres autoridades de certificación emisoras, se habían otorgado derechos de emisión y administración de certificados a múltiples cuentas de usuario y grupos sin una asignación de roles clara ni una justificación adecuada, una laguna en la gobernanza que aumentaba el riesgo de uso indebido o mala configuración.
• El entorno PKI presentaba un marco de gobernanza deficiente en general. Las plantillas de certificados carecían de documentación, una propiedad definida y una asignación de propósito clara. Sin una supervisión centralizada, el entorno había acumulado plantillas redundantes, obsoletas e inactivas, lo que aumentaba la probabilidad de emitir certificados mal configurados.

Diseño y arquitectura de soluciones PKI modernas

Una serie de sesiones de lluvia de ideas y talleres técnicos con las partes interesadas clave dieron como resultado una nueva arquitectura PKI diseñada para abordar los desafíos principales mencionados anteriormente y establecer una base más sólida para la seguridad, la escalabilidad y la eficiencia operativa. Las decisiones que se presentan a continuación reflejan los resultados de dichas sesiones y, en conjunto, conforman la estrategia de modernización de PKI de la organización.

Estructura de infraestructura y autoridad de certificación

• Para dejar atrás la infraestructura obsoleta, el equipo optó por Windows Server 2022 o superior para poner a prueba la nueva configuración de PKI, lo que permitió evaluar la compatibilidad con las funciones de seguridad modernas y validar la arquitectura en un entorno controlado antes de su implementación a gran escala.
• Se planificaron dos autoridades de certificación emisoras dedicadas, cada una alineada con un caso de uso específico, para el centro de datos. Esta estructura proporcionó una segmentación lógica y permitió la implementación de políticas de emisión de certificados personalizadas.
• También se planificaron autoridades de certificación emisoras correspondientes para un entorno de recuperación ante desastres (DR) con el fin de garantizar una alta disponibilidad. Estas autoridades de certificación de DR se diseñaron para escenarios de conmutación por error, no se utilizaban para emitir certificados durante las operaciones normales y se sometían a pruebas periódicas, manteniéndose sincronizadas mediante la replicación manual de la configuración.

Validez del certificado, CRL y configuración OCSP

• La validez del certificado de la CA raíz se redujo a 10 años, y a las CA emisoras se les asignó una validez de 5 años. Los certificados de las entidades finales se configuraron de acuerdo con las mejores prácticas del sector.
• Las mejores prácticas de la industria dieron forma a la configuración de Lista de revocación de certificados (CRL) publicación y comprobación del estado del certificado. Se configuró a las CA subordinadas para publicar CRL base cada 7 días y CRL delta cada 24 horas, con un período de solapamiento de 2 días para limitar las interrupciones relacionadas con la revocación durante las interrupciones. Las extensiones CRL y AIA se distribuyeron a través de HTTP como ruta principal, LDAP como vía secundaria, y OCSP, para que las comprobaciones del estado de los certificados sean rápidas y fiables.

Gobernanza, plantillas e integración de PKI en la nube

• Una revisión completa de las plantillas de certificados eliminó la redundancia, asignó una propiedad clara y vinculó cada plantilla con su uso previsto, lo que permitió políticas de emisión más estrictas y redujo la ambigüedad operativa. El acceso a las CA emisoras se reestructuró para que solo los roles autorizados pudieran emitir o gestionar certificados. certificados, subsanando las deficiencias causadas por permisos de usuario y de grupo no documentados o excesivos.
• Para abordar la fragmentación y simplificar la gestión del ciclo de vida de los certificados, se recomienda el diseño PKI en la nube de MicrosoftEsto permitió una integración perfecta con las plataformas MDM existentes, al tiempo que redujo la dependencia de la infraestructura local, brindando a la organización un modelo de confianza unificado y escalable, basado en una única fuente de información fidedigna.

La tabla que aparece a continuación resume cómo el rediseño modificó cada área de la infraestructura de clave pública (PKI).

Área	PKI heredada	Diseño de PKI modernizado
Almacenamiento de claves de la CA raíz y emisora	Basado en software, sin HSM	Almacenamiento de claves respaldado por HSM
Validez del certificado de CA raíz	+20 años	10 años (5 años para las CA emisoras)
Horario de CRL y delta CRL	Inconsistencia entre las 3 autoridades de certificación emisoras	Estandarizado: CRL base de 7 días, delta CRL de 24 horas, solapamiento de 2 días.
Recuperación de desastres	No existe una estrategia formal de recuperación ante desastres ni de respaldo.	Autoridades de certificación emisoras de DR dedicadas, sometidas a pruebas periódicas.
Plantillas de certificados y acceso	Permisos no documentados, redundantes y amplios.	Propiedad documentada, casos de uso mapeados, acceso basado en roles
Gestión de dispositivos	Fragmentado en múltiples plataformas MDM	Unificado mediante la integración de Microsoft Cloud PKI.

Cómo aplicar este enfoque de diseño de PKI: Guía paso a paso

Los equipos de PKI empresariales que se enfrentan a un entorno similarmente obsoleto pueden adaptar la misma secuencia utilizada en este caso práctico. Los pasos que se describen a continuación generalizan ese proceso en un manual repetible, junto con las comprobaciones, los errores comunes y las opciones de reversión que un equipo debe prever.

Requisitos previos

• Una evaluación completa del estado de la infraestructura de clave pública (PKI) que identifica los riesgos de la autoridad de certificación raíz (Raíz CA) y de la autoridad de certificación emisora ​​(Issemition CA).
• Consenso entre la dirección y las partes interesadas en cuanto al alcance, el presupuesto y el cronograma.
• Un entorno de laboratorio o piloto que ejecute Windows Server 2022 o posterior.
• Acceso a HSM, ya sea mediante hardware local o HSM como servicio.
• Un bosque de Active Directory que ejecuta una versión de Windows Server compatible actualmente.
• Una copia de seguridad completa de la base de datos de CA existente, las claves privadas y el archivo CAPolicy.inf.
• Un inventario documentado de las plantillas de certificados actuales y sus usuarios.
• Un periodo de mantenimiento definido y un plan de comunicación para los titulares de certificados.

Procedimiento de implementación paso a paso

1. Evaluar el entorno PKI existente. Antes de realizar cualquier cambio, revise los períodos de validez de la CA, la configuración de CRL y OCSP, el almacenamiento de claves privadas y las plantillas de certificados según las mejores prácticas actuales.
2. Diseñar la jerarquía de confianza. Defina la estructura de la CA raíz y la CA emisora, alinéela con el diseño del bosque de Active Directory y documente cómo se asignan los casos de uso de cada dominio a la nueva jerarquía.
3. Poner a prueba la nueva infraestructura de CA. Configure las CA raíz y emisora ​​en un sistema operativo actual y compatible, como Windows Server 2022 o posterior, en un entorno de laboratorio aislado antes de implementarlas en producción. Ejemplo de comando para confirmar el tipo de CA en un servidor piloto: certutil -getreg CA\CAType
4. Configure el almacenamiento de claves respaldado por HSM. Genere y almacene las claves privadas de la CA raíz y de la CA emisora ​​dentro de un módulo de seguridad de hardware utilizando el proveedor de almacenamiento de claves del fabricante, siguiendo el procedimiento de ceremonia de claves del fabricante.
5. Establecer periodos de validez de los certificados. Configure la CA raíz, la CA emisora ​​y la validez de la entidad final para que coincidan con la política, por ejemplo: certutil -setreg CA\ValidityPeriod "Years" y certutil -setreg CA\ValidityPeriodUnits 5
6. Configure la CRL, la CRL delta y la publicación OCSP. Establezca programaciones de CRL base y delta consistentes con un período de superposición, luego publique la información de CRL y AIA a través de HTTP, LDAP y OCSP, por ejemplo: certutil -setreg CA\CRLPeriod "Days", certutil -setreg CA\CRLPeriodUnits 7, certutil -setreg CA\CRLDeltaPeriod "Hours", certutil -setreg CA\CRLDeltaPeriodUnits 24, certutil -setreg CA\CRLOverlapPeriodUnits 2Luego, reinicie el servicio CA y vuelva a publicar: net stop certsvc && net start certsvc seguido por certutil -crl
7. Reconstruir las plantillas de certificados y los controles de acceso. Elimine las plantillas redundantes, documente el propietario y el propósito de cada plantilla restante, y restrinja los derechos de emisión y administración a roles específicos en lugar de a grupos amplios.
8. Establecer centros de certificación para la recuperación ante desastres. Configure las CA emisoras en un entorno de recuperación ante desastres, replique la configuración según un cronograma definido y pruebe la conmutación por error sin emitir certificados de producción desde las CA de recuperación ante desastres durante las operaciones normales.
9. Integre la infraestructura de clave pública en la nube (PKI) donde reduzca la fragmentación. Cuando varias plataformas MDM administran diferentes tipos de dispositivos, evalúe una CA administrada en la nube, como Microsoft Cloud PKI, para unificar la emisión y reducir la dependencia de las infraestructuras locales.
10. Migrar los puntos finales y desactivar la relación de confianza heredada. Implemente la nueva cadena mediante Directiva de grupo o MDM, confirme la confianza y la inscripción del cliente y, a continuación, retire la jerarquía de CA heredada solo después de que todos los consumidores se hayan migrado a la nueva PKI.

Comprobaciones de validación

• Confirme que la cadena de certificados se construye correctamente hasta la nueva CA raíz utilizando certutil -verify o una verificación de cadena del lado del cliente.
• Confirme que los puntos finales CRL y OCSP devuelven datos de revocación vigentes y no caducados desde una ruta de red externa.
• Emita un certificado de prueba a partir de cada plantilla reconstruida y confirme que el período de validez, el uso de la clave y los campos del asunto sean correctos.
• Confirme que la firma respaldada por HSM se realiza correctamente y que los registros de auditoría muestran al HSM como el almacén de claves principal.
• Confirme que la CA de recuperación ante desastres puede procesar una solicitud de conmutación por error y que las plantillas se replican correctamente.

Errores comunes y solución de problemas

Error o síntoma	Causa probable	Solución recomendada
0x80070005 (ACCESO DENEGADO) en certutil -setreg	Comando ejecutado sin derechos de administrador de CA ni solicitud de permisos elevados.	Ejecute certutil desde una consola con privilegios de administrador como miembro del grupo Administradores de la CA y, a continuación, reinicie los Servicios de certificados.
Los clientes no superan las comprobaciones de revocación con el código 0x80092013.	La ubicación HTTP de CDP o AIA es inaccesible, o el respondedor OCSP no está disponible.	Confirme que las URL de CDP y AIA se resuelven externamente y que el servicio de respuesta OCSP está en funcionamiento.
La nueva CRL no es visible para los clientes después de un cambio.	La CRL no se volvió a publicar después del reinicio del servicio de CA.	Ejecute certutil -crl y confirme que el archivo se haya publicado en todas las ubicaciones de CDP antes de habilitar la nueva programación.
Las operaciones de HSM fallan con el código 0x800706BA (servidor RPC no disponible).	La ruta de red a un HSM en red está bloqueada o el servicio cliente del HSM no está en ejecución.	Verifique las reglas del firewall y confirme que el cliente HSM o el servicio del proveedor PKCS#11 esté activo en el host de la CA.
Solicitud de certificado denegada, error del módulo de políticas 0x80094800	La plantilla fue retirada, renombrada o el solicitante carece de permiso de inscripción.	Confirme que la plantilla esté publicada en la CA emisora ​​y que el grupo de seguridad del solicitante tenga derechos de inscripción.

Pasos de retroceso

• Revertir los valores del registro modificados con certutil -setreg Utilice la configuración registrada previamente y, a continuación, reinicie los Servicios de certificados.
• Restaure la base de datos de CA y la clave privada desde la copia de seguridad anterior al cambio utilizando certutil -restoredb y certutil -restorekey si ya se había aplicado un cambio de validez o de clave.
• Vuelva a publicar la CRL anterior con certutil -crl De esta forma, las partes que confían en la información vuelven a ver los datos de revocación válidos de inmediato.
• Rechazar la inscripción en la CA emisora ​​anterior mediante la Directiva de grupo hasta que la nueva CA supere todas las comprobaciones de validación.
• Deje intacta la CA de recuperación ante desastres durante las pruebas de reversión para que siga estando disponible una ruta de respaldo validada.

Impacto y resultados empresariales

Al subsanar deficiencias arquitectónicas y de eficiencia operativa de larga data, la organización fortaleció su base de confianza digital y la alineó con los estándares de seguridad modernos. Los principales resultados comerciales incluyeron los siguientes:

• Con claves privadas ahora protegidas en módulos de seguridad de hardware (HSM)El riesgo de vulneración de seguridad disminuyó significativamente. El entorno se alejó de la infraestructura obsoleta y las dependencias heredadas, lo que permitió una integración más fluida con plataformas modernas y servicios nativos de la nube.
• La claridad operativa mejoró gracias a una gobernanza más rigurosa: se simplificaron las plantillas de certificados, se definieron correctamente los controles de acceso y los procesos de emisión se volvieron mucho más predecibles y auditables. Esto redujo la carga administrativa y la probabilidad de errores o configuraciones incorrectas.
• La continuidad del negocio mejoró con la introducción de las autoridades de certificación de recuperación ante desastres, lo que permitió que la emisión de certificados críticos continuara incluso durante las interrupciones del servicio. El modelo de confianza se volvió más escalable, resiliente y fácil de administrar, lo que permitió a los equipos de TI y seguridad centrarse en mejoras proactivas en lugar de solucionar problemas urgentes en una configuración fragmentada.
• Lo más importante es que la organización estableció un marco PKI preparado para el futuro, capaz de soportar un número creciente de usuarios, dispositivos y aplicaciones, al tiempo que cumple con sus requisitos de criptoagilidad y automatización en todos los casos de uso.

Recomendaciones de expertos para equipos de PKI empresariales

• Diseña antes de construir. Define la jerarquía de confianza, la propiedad y la política de ciclo de vida en papel antes de utilizar las CA de producción.
• Considere el almacenamiento de claves respaldado por HSM como un requisito básico para las CA raíz y emisoras, no como una actualización opcional.
• Ajustar los periodos de validez de los certificados y las autoridades de certificación a las mejores prácticas actuales, en lugar de mantener los valores predeterminados establecidos hace una década.
• Integre la recuperación ante desastres en el diseño desde el primer día, en lugar de agregarla después de que una interrupción ponga al descubierto la deficiencia.

Conclusión

Este proceso de modernización subraya una realidad simple: una infraestructura de clave pública (PKI) segura comienza con un diseño inteligente, no con soluciones reactivas. Al priorizar la arquitectura, aplicar controles de acceso, adoptar el almacenamiento de claves respaldado por módulos de seguridad de hardware (HSM) y optimizar la gobernanza de certificados, la organización construyó una base de confianza escalable y resiliente. Lo más importante es que se posicionó para respaldar el crecimiento futuro, la automatización y la criptoagilidad, demostrando que una PKI bien planificada no es solo una mejora de seguridad, sino un facilitador estratégico para la empresa digital.

Preguntas frecuentes

¿Cuál es la principal conclusión de las lecciones aprendidas de un diseño de PKI moderno y exitoso?

La principal conclusión es que una infraestructura de clave pública (PKI) segura y escalable comienza con un diseño minucioso, no con parches reactivos. Al diseñar una nueva jerarquía de confianza antes de implementarla en producción, este minorista solucionó las causas raíz, como claves privadas desprotegidas, periodos de CRL inconsistentes y derechos de emisión no asignados, en lugar de tratar cada una como un problema aislado.

¿Por qué es importante esto para los equipos de PKI empresariales?

Los equipos de PKI empresariales suelen heredar infraestructuras construidas años atrás por personas que ya no trabajan en la organización. Este caso es relevante porque demuestra una forma reproducible de evaluar, rediseñar y modernizar la infraestructura de confianza heredada sin interrumpir la emisión de certificados para los usuarios, dispositivos y aplicaciones que dependen de ella.

¿Qué riesgos aumentan si este tema se aborda manualmente?

Si se deja en manos de una gestión manual y no documentada, el riesgo de la infraestructura de clave pública (PKI) aumenta en varios frentes: compromiso de claves debido a claves privadas desprotegidas, fallos de revocación por publicación inconsistente de listas de revocación de certificados (CRL), interrupciones sin un plan de recuperación ante desastres y certificados emitidos erróneamente debido a plantillas no documentadas y permisos de usuario excesivos.

¿Qué equipos deberían asumir la responsabilidad de este cambio?

La responsabilidad suele abarcar al equipo de gestión de identidades y accesos o al equipo de ingeniería de seguridad que gestiona los servicios de certificados, al equipo de Active Directory e infraestructura que mantiene el dominio subyacente, y a la dirección de seguridad informática que aprueba la jerarquía de confianza, la inversión en HSM y la política de gobernanza.

¿Cómo se relaciona esto con la gestión del ciclo de vida de los certificados?

El diseño de la infraestructura de clave pública (PKI) establece las reglas que rigen la gestión del ciclo de vida de los certificados: cuánto tiempo permanecen válidos los certificados y los certificados de autoridad de certificación (CA), qué plantillas los emiten, cómo se verifica la revocación y quién puede solicitar o aprobar su emisión. Corregir el diseño desde el principio permite que la gestión diaria del ciclo de vida sea predecible en lugar de improvisada.

¿Cómo deberían las organizaciones medir el éxito?

El éxito se manifiesta en una menor cantidad de interrupciones imprevistas en la emisión de certificados, solicitudes de emisión más rápidas y auditables, claves privadas protegidas de forma demostrable en un HSM, respuestas CRL y OCSP devueltas de manera confiable dentro de sus plazos establecidos, y una correspondencia documentada entre cada plantilla de certificado y su propietario comercial.

¿Qué se debe auditar o supervisar periódicamente?

Los equipos deben auditar periódicamente los períodos de validez de los certificados de CA y de las entidades finales, los tiempos de publicación de las CRL y las CRL delta, los registros de uso de claves de HSM, los permisos y la propiedad de las plantillas de certificados, y el estado de las CA de recuperación ante desastres para confirmar que permanecen sincronizadas y listas para la conmutación por error.

¿Cómo afecta este tema a las infraestructuras de clave pública (PKI) en la nube, híbridas o con múltiples autoridades de certificación (CA)?

En entornos híbridos y con múltiples autoridades de certificación (CA), la inconsistencia en los períodos de validez, los calendarios de revocación de certificados (CRL) y los controles de acceso se acumula rápidamente entre las distintas CA. Este caso práctico, que muestra la migración a Microsoft Cloud PKI, ilustra cómo la centralización de políticas en las CA locales y gestionadas en la nube reduce la fragmentación, al tiempo que permite el uso de múltiples plataformas MDM y tipos de dispositivos.

¿Qué requisitos previos son necesarios antes de la implementación?

Antes de la implementación, los equipos necesitan una evaluación completa de la infraestructura de clave pública (PKI), la alineación de la dirección ejecutiva y las partes interesadas, un entorno de laboratorio en un sistema operativo de servidor actual, acceso o adquisición de un módulo de seguridad de hardware (HSM), un bosque de Active Directory en una versión compatible, una copia de seguridad completa de la base de datos de la CA existente y las claves privadas, y un inventario documentado de las plantillas de certificados actuales.

¿Qué errores comunes deben tener en cuenta los administradores?

Los administradores deben estar atentos a los errores de acceso denegado al cambiar la configuración del registro de CA sin derechos de administrador de CA elevados, a los puntos finales de CRL y OCSP caducados o inaccesibles después de un cambio de configuración, a los fallos de conectividad de HSM a través de la red y a las solicitudes de certificados denegadas porque una plantilla se retiró o se renombró sin actualizar los permisos de inscripción.