Diferencia entre varias Infraestructuras de Clave Pública (PKI)

Introducción

Microsoft PKI, AWS Certificate Manager, AWS ACM Private CA y Google Cloud Certificate Authority Service resuelven el mismo problema fundamental: la emisión y gestión de certificados digitales de confianza, pero lo hacen de maneras muy diferentes. Elegir la solución incorrecta o utilizarlas todas sin un proceso de decisión documentado puede llevar a que las organizaciones terminen con jerarquías de CA duplicadas, protección de claves inconsistente e interrupciones de certificados inesperadas. Este artículo explica en qué consiste una PKI, cómo la implementa cada una de estas cuatro plataformas, ofrece una comparación exhaustiva en once categorías y proporciona una matriz de decisión práctica y una lista de verificación para elegir (o auditar) la solución adecuada para cada caso de uso.

Respuesta rápida: ¿Cuál es la diferencia entre estas plataformas PKI?

Los proveedores de infraestructura de clave pública (PKI) se diferencian principalmente en dónde residen las claves de CA y quién administra la jerarquía: Microsoft PKI (ADCS) se ejecuta en las instalaciones con una CA raíz sin conexión, AWS Certificate Manager automatiza los certificados TLS públicos, y AWS ACM Private CA y Google Cloud CAS ejecutan jerarquías de CA privadas de forma nativa en la nube con claves respaldadas por HSM y registro de auditoría integrado.

Puntos Clave

• Microsoft PKI, AWS Certificate Manager, AWS ACM Private CA y Google Cloud CAS resuelven diferentes problemas: control de CA local, TLS público automatizado, jerarquías de CA privadas nativas de la nube y grupos de CA integrados en GCP, respectivamente.
• Las cuatro plataformas convergen en las mismas prácticas de seguridad básicas: autoridades de certificación raíz (RA) sin conexión o protegidas, claves privadas respaldadas por módulos de seguridad de hardware (HSM), funciones hash SHA-256 o superiores y registro de auditoría.
• AWS ha actualizado la protección HSM de ACM Private CA al nivel 3 de FIPS 140-3. El NIST dejará de aplicar las validaciones FIPS 140-2 y las clasificará como históricas el 21 de septiembre de 2026, por lo que cualquier implementación de Microsoft PKI o local que aún utilice la norma 140-2 necesita un plan de actualización.
• La reducción de la validez de los certificados TLS públicos, que se limitará a 47 días para 2029 según la propuesta SC-081v3 del Foro CA/Browser, hace que las plataformas compatibles con la automatización, como ACM y los sistemas CAS nativos de la nube, sean cada vez más importantes incluso para las organizaciones que comenzaron con la infraestructura de clave pública (PKI) de Microsoft.
• La opción correcta rara vez es una sola plataforma. La mayoría de las empresas utilizan una combinación híbrida y necesitan una matriz de decisión documentada, no una selección improvisada, para evitar jerarquías de CA duplicadas y una protección de claves inconsistente.

Por qué esto importa ahora

La encuesta Trust Pulse de DigiCert, publicada el 2 de julio de 2025, reveló que casi la mitad de las empresas sufrieron una interrupción relacionada con certificados durante el último año. El 37.5 % de los incidentes estuvieron vinculados específicamente a certificados caducados, y el 18.5 % de las organizaciones afectadas reportaron pérdidas superiores a 250 000 dólares. La coexistencia de jerarquías de PKI de Microsoft, AWS y Google Cloud CA sin un proceso consistente de monitoreo y renovación es precisamente el tipo de inconsistencia que genera estas interrupciones.

El margen de error manual también se está reduciendo rápidamente. Según la propuesta SC-081v3 del Foro CA/Browser , aprobada el 11 de abril de 2025, la validez de los certificados TLS de confianza pública se reduce de 398 a 200 días a partir del 15 de marzo de 2026, luego a 100 días desde el 15 de marzo de 2027 y a 47 días desde el 15 de marzo de 2029 en adelante. Una plataforma que dependa de la emisión manual, común en implementaciones antiguas de PKI de Microsoft, no podrá seguir el ritmo de este calendario como lo hacen la automatización de AWS Certificate Manager o Google Cloud CAS.

A largo plazo, el NIST finalizó sus estándares de criptografía post-cuántica, FIPS 203, 204 y 205, el 13 de agosto de 2024. Todas las plataformas comparadas en esta publicación siguen firmando certificados con RSA o ECDSA, por lo que, independientemente del proveedor que una organización utilice actualmente, un plan de criptoagilidad para la eventual transición a la criptografía post-cuántica debe incluirse en la hoja de ruta, sin importar la jerarquía de CA que esté vigente.

¿Qué es la infraestructura de clave pública (PKI)?

PKI, acrónimo de Infraestructura de Clave Pública , es un conjunto de roles, procedimientos y políticas necesarios para crear, distribuir, administrar, usar y revocar certificados digitales, así como para gestionar el cifrado de clave pública. PKI confirma la identidad de un usuario verificando la propiedad de una clave privada, actuando como un servicio de confianza que verifica que el remitente o receptor de datos sea quien dice ser.

¿Cuáles son los componentes principales de una infraestructura de clave pública (PKI)?

La infraestructura de clave pública (PKI) se basa en componentes y procedimientos para la gestión de pares de claves (par de claves públicas y privadas). Una PKI típica se compone de los siguientes elementos:

1. Autoridad de certificación (CA): Un confiable CA es la única entidad en PKI que puede emitir certificados digitales de confianza. La CA acepta solicitudes de certificados y verifica la información proporcionada por los solicitantes en función de gestión de certificados Luego, aplica la política y firma los certificados con su clave privada, emitiéndolos si la información es válida.
2. Autoridad de registro (RA): Una RA es responsable de recibir las solicitudes de firma de certificados para la inscripción inicial o la renovación de certificados de usuarios, servidores y otras aplicaciones. La RA verifica la identidad de la entidad final y reenvía la solicitud a una autoridad de certificación (CA).
3. Clave pública: Una clave pública puede distribuirse ampliamente y no requiere almacenamiento seguro. Su clave privada correspondiente puede descifrar los mensajes o datos cifrados con la clave pública.
4. Llave privada: Las claves privadas son utilizadas por el destinatario para descifrar el mensaje o los datos cifrados con su clave pública correspondiente. Esto establece la propiedad del par de claves, tanto privada como pública, garantizando que el mensaje solo sea leído por las partes autorizadas.
5. Autoridad de certificación raíz (CA raíz): Un certificado se considera válido cuando una CA raíz de confianza lo firma. Una CA raíz está autorizada a verificar la identidad de una persona y firma el certificado raíz que se distribuye al usuario.
6. Autoridad de Certificación Intermedia: Una CA intermedia también es una CA de confianza y se utiliza como eslabón entre la CA raíz y el certificado de cliente que el usuario solicita. Dado que la CA raíz ha firmado y confía en la CA intermedia, los certificados generados por esta también son de confianza.
7. Módulo de seguridad de hardware (HSM): A Módulo de seguridad de hardware No es un componente obligatorio de una PKI, pero mejora la seguridad cuando se implementa. Este dispositivo protege y gestiona las claves digitales y sirve como base para construir una infraestructura segura. PKI empresarial infraestructura, gestionando el ciclo de vida completo de las claves criptográficas, incluyendo la creación, rotación, eliminación, auditoría y soporte para API Para integrar con varias aplicaciones.

¿Cómo implementan estos componentes los principales proveedores de PKI?

Ahora que los componentes básicos de la infraestructura de clave pública (PKI) están claros, a continuación se explica cómo los implementan cuatro plataformas ampliamente utilizadas, junto con las mejores prácticas recomendadas para cada una.

PKI de Microsoft

A continuación, se presentan algunas de las mejores prácticas recomendadas para utilizar eficazmente la infraestructura de clave pública (PKI) de Microsoft (Servicios de certificados de Active Directory).

• Haga un plan detallado de su infraestructura PKI antes de la implementación.
• Evite instalar ADCS en un controlador de dominio.
• La CA raíz debe ser independiente y sin conexión.
• No emita certificados a entidades finales desde una CA raíz.
• Habilitar eventos de auditoría tanto para la CA raíz como para la CA emisora.
• Proteja la clave privada con un HSM (FIPS 140-3 Nivel 3Las validaciones FIPS 140-2 pasarán a tener estado histórico el 21 de septiembre de 2026.
• Instale Enterprise CA únicamente si su CA emite certificados para dispositivos o usuarios.
• No se recomienda utilizar plantillas de certificado predeterminadas.
• El punto de distribución de CRL debe tener una alta disponibilidad.
• Publique la CRL de la CA raíz en Active Directory.
• El algoritmo hash debería ser al menos SHA-2 (SHA-256 o superior).
• El período de validez del certificado de la entidad final debe ser de un máximo de dos años.

Administrador de certificados de AWS

Estas son las mejores prácticas para AWS Certificate Manager (ACM):

• Verificación de caducidad de certificados ACM: asegúrese de eliminar los certificados caducados. Certificados SSL/TLS Gestionado por ACM. Esto elimina el riesgo de implementar un certificado no válido en los recursos que dan al usuario final, lo que también puede perjudicar la credibilidad de la empresa.
• Verificación de validez del certificado ACM: asegúrese de que las solicitudes que lleguen durante el proceso de emisión o renovación del certificado SSL/TLS se validen periódicamente.
• Uso de la Autoridad de Certificación Raíz (CA): siempre es recomendable minimizar el uso de la CA raíz. AWS recomienda crear una cuenta independiente para la CA raíz.
• La protección de la capa de transporte es vital para la seguridad. Utilice únicamente TLS versión 1.2 o superior; SSL ya no es seguro.
• Al importar certificados en lugar de utilizar certificados emitidos por ACM, asegúrese de que las claves utilizadas para generar claves privadas SSL/TLS tengan una alta seguridad para evitar una filtración de datos.
• Evite los certificados de dominio comodín. En su lugar, emita un certificado ACM de dominio único para cada dominio y subdominio con su propia clave privada.
• Permita la importación de certificados únicamente de socios autenticados y de confianza de su organización. Los certificados comodín importados a ACM aumentan el riesgo de seguridad, ya que un usuario podría tener una copia sin cifrar de la clave privada del certificado.
• Utilice siempre un nombre de dominio completamente cualificado (FQDN) en los certificados SSL/TLS de ACM.
• Para evitar el uso indebido de los certificados generados, realice auditorías frecuentes del entorno de AWS para verificar que existan certificados de confianza y valide los informes de auditoría.
• Active las alarmas de AWS CloudTrail y CloudWatch: CloudTrail realiza un seguimiento del historial de llamadas a la API de AWS y supervisa las implementaciones de AWS, y puede integrarse con aplicaciones para el registro automatizado. Las alarmas de CloudWatch le notifican cuando las métricas configuradas superan los umbrales establecidos.

CA privada de AWS ACM (ACM PCA)

A continuación, se recomiendan algunas prácticas recomendadas que pueden ayudarle a utilizar AWS ACM Private CA de forma más eficaz.

• AWS recomienda documentar todas las políticas y prácticas para el funcionamiento de su CA, incluyendo la jerarquía de la CA, el diagrama de arquitectura y las políticas del período de validación de la CA. Esto se puede plasmar en una Política de Certificado (CP) y una Declaración de Práctica de Certificado (CPS); consulte la RFC 3647 para obtener un marco de trabajo sobre cómo recopilar esta información.
• En general, la CA raíz solo debe utilizarse para emitir certificados para las CA intermedias.
• Crear una CA raíz y una CA subordinada en dos cuentas de AWS diferentes es una práctica recomendada.
• El rol de administrador de CA debe ser independiente de los usuarios que necesitan acceso solo para emitir certificados de entidad final.
• Active el registro de CloudTrail antes de crear y comenzar a operar una CA privada, para que pueda recuperar un historial de las llamadas a la API de AWS y supervisar sus implementaciones.
• Actualice periódicamente la clave privada de su CA privada, ya sea importando un nuevo certificado de CA o reemplazando la CA privada por una nueva.
• Elimine permanentemente cualquier CA privada no utilizada.
• Utilice la función Bloquear acceso público (BPA) de Amazon S3 en los buckets que contienen listas de revocación de certificados (CRL) para evitar exponer innecesariamente los detalles de su infraestructura de clave pública (PKI) privada. BPA es una práctica recomendada de S3 y está habilitada de forma predeterminada en los buckets nuevos.

Servicio de Autoridad de Certificación de Google Cloud

Esta sección describe algunas de las mejores prácticas que le ayudarán a utilizar el Servicio de Autoridad de Certificación (CAS) de Google Cloud de forma más eficaz.

• Control de roles y acceso: a una misma persona no se le debe asignar más de un rol a la vez, y todos los que desempeñen un rol deben estar debidamente informados sobre sus responsabilidades. Para asignar un conjunto diverso de permisos, cree un rol personalizado mediante IAM.
• En la mayoría de los casos, utilice el nivel Enterprise para crear un grupo de CA que emita certificados a otras CA y entidades finales.
• Al crear un grupo de CA, tenga en cuenta cuidadosamente la capa de DevOps, ya que no admite la revocación de certificados.
• Proteja las claves de firma de CA aprovechando Cloud HSM.
• Habilite los registros de auditoría en la nube para supervisar el acceso y el uso de las claves de firma de Cloud HSM.
• Evite importar una CA externa existente con certificados ya emitidos al servicio de CA.
• Para una CA raíz y una CA subordinada, utilice el tamaño de clave más grande disponible para esa familia de algoritmos: para RSA, el tamaño de clave más grande admitido es de 4096 bits; para ECDSA, el tamaño de clave más grande admitido es de 384 bits. Las CA subordinadas con una vida útil más corta pueden usar tamaños de clave más pequeños, como 2048 bits para RSA o 256 bits para ECDSATenga en cuenta que las claves de firma Ed25519 no son compatibles con el servicio CA, y que, a la fecha de este documento, no se admite ningún algoritmo de firma post-cuántica para las claves CA.
• Otorgue el rol de usuario del Servicio de CA únicamente a los miembros de la organización que necesiten utilizar una plantilla de certificado determinada.

Comparativa de proveedores de un vistazo

La tabla que aparece a continuación compara las cuatro plataformas en once categorías que son las más importantes a la hora de elegir o auditar un proveedor de PKI.

#	Categoría	PKI de Microsoft	Administrador de certificados de AWS (ACM)	CA privada de AWS ACM (ACM PCA)	Servicio de Autoridad de Certificación (CAS) de Google Cloud
1	CA raíz	La CA raíz se implementa en las instalaciones del cliente y se mantiene sin conexión.	AWS Certificate Manager es un servicio para el aprovisionamiento, la gestión y la implementación de certificados SSL/TLS públicos/privados para los servicios de AWS y los recursos conectados.	La CA raíz puede implementarse en la nube de AWS, o bien la CSR de la CA emisora ​​puede ser firmada por una CA raíz externa.	La CA raíz puede implementarse en Google Cloud CAS, o bien la CSR de la CA emisora ​​puede ser firmada por una CA raíz externa.
2	Plantilla de certificado	No se recomienda utilizar las plantillas de certificado predeterminadas; las plantillas se pueden configurar.	Utilice plantillas de AWS CloudFormation para emitir certificados privados mediante ACM.	ACM Private CA admite cuatro variedades de plantillas de certificados: Base, CSRPassthrough, APIPassthrough y APICSRPassthrough.	En Google Cloud CAS se puede crear una nueva plantilla de certificado para cada proyecto y ubicación.
3	Algoritmo de clave y tamaño de clave	Admite tamaños de clave según NIST SP 800-57. El tamaño mínimo de clave es de 2048 bits; para las CA con una fecha de vencimiento de certificado superior a 15 años, RSA debe ser de 4096 bits o superior, o las claves ECC deben utilizar la curva P-384 o P-521.	Admite RSA de 2048 bits, RSA de 3072 bits, RSA de 4096 bits y ECDSA P-256 y P-384.	Admite los estándares RSA 2048, RSA 4096, ECDSA P-256 y ECDSA P-384 para certificados emitidos directamente por ACM Private CA.	Admite RSA de 2048 bits, RSA de 3072 bits, RSA de 4096 bits, ECDSA P-256 y ECDSA P-384. Para CA raíz o subordinadas de larga duración, Google recomienda el tamaño de clave más grande disponible para la familia de algoritmos seleccionada. Actualmente no se admiten las claves de firma de CA post-cuánticas ni Ed25519.
4	Algoritmo hash	Se recomienda SHA-256 o superior para nuevas implementaciones y PKI existentes.	Los certificados gestionados por ACM utilizan claves RSA con un módulo de 2048 bits y SHA-256; actualmente, ACM no gestiona certificados ECDSA.	Admite SHA256WITHECDSA, SHA384WITHECDSA, SHA512WITHECDSA, SHA256WITHRSA, SHA384WITHRSA y SHA512WITHRSA para certificados emitidos directamente por ACM Private CA.	Admite SHA-256 y SHA-384.
5	Cumplimiento de RFC	Los certificados de CA deben ser X.509 v3 y cumplir con la RFC 5280 (que sigue siendo el perfil base actual de certificados X.509/PKIX) y los requisitos básicos actuales del Foro CA/Navegador.	AWS protege la infraestructura que ejecuta ACM en la nube de AWS; su eficacia es probada por auditores externos en el marco de los Programas de Cumplimiento de AWS.	Aplica restricciones específicas según la RFC 5280, aunque no todas las restricciones definidas en la RFC 5280 se aplican.	Utiliza la herramienta ZLint para validar los certificados X.509 conforme a la RFC 5280, aunque no aplica todos los requisitos de la RFC 5280.
6	Punto de distribución de CRL	La infraestructura de clave pública (PKI) de Microsoft deposita la lista de revocación de certificados (CRL) mediante LDAP y HTTP.	La revocación de certificados para ACM se gestiona a través del soporte de AWS; es necesario abrir un caso de soporte.	ACM Private CA deposita automáticamente la CRL en un bucket de Amazon S3 designado.	La publicación de CRL debe habilitarse explícitamente en un grupo de CA, lo cual puede hacerse al crear el grupo.
7	Almacenamiento de claves privadas	Se recomienda almacenar las claves privadas en un HSM compatible con FIPS 140-3 Nivel 3 (las validaciones FIPS 140-2 pasarán a estado histórico el 21 de septiembre de 2026).	ACM almacena el certificado y su clave privada correspondiente, utilizando el Servicio de administración de claves de AWS (KMS) para ayudar a proteger la clave privada.	Por defecto, las claves privadas de las CA privadas se almacenan en HSM gestionados por AWS que cumplen con los requisitos de seguridad de nivel 3 de FIPS PUB 140-3 para módulos criptográficos.	Las claves de CA se almacenan en Cloud HSM, con validación FIPS 140-2 Nivel 3, y están disponibles en América, Europa y Asia Pacífico.
8	Los informes de auditoría	Se puede habilitar la auditoría en una CA en Windows Server para proporcionar un registro de auditoría de todas las tareas de administración de servicios de certificados.	ACM está integrado con AWS CloudTrail, que registra las acciones realizadas por un usuario, rol o servicio de AWS y está habilitado de forma predeterminada.	Los informes de auditoría enumeran todos los certificados que ACM Private CA ha emitido o revocado, guardados en un bucket de S3 nuevo o existente.	Los registros de auditoría en la nube abarcan la actividad del administrador, el acceso a los datos, los eventos del sistema y los registros de auditoría de denegación de políticas para cada proyecto, carpeta y organización.
9	Mejores prácticas (nivel general)	Planifique antes de la implementación, mantenga la CA raíz fuera de línea, evite emitir certificados de entidad final desde la CA raíz, habilite la auditoría y proteja las claves con un HSM FIPS 140-3 de nivel 3.	Compruebe periódicamente la caducidad y la validez de los certificados, minimice el uso de la CA raíz e implemente TLS 1.2 o superior.	Documente la estructura y las políticas de la CA, minimice el uso de la CA raíz, separe las funciones de administrador y emisor, habilite CloudTrail y rote periódicamente las claves privadas de la CA.	Aplique la asignación de roles con privilegios mínimos, utilice el nivel Enterprise para grupos de múltiples CA, proteja las claves de firma con Cloud HSM y habilite el registro de auditoría.
10	Jerarquía de CA	Las implementaciones de PKI jerárquicas suelen utilizar jerarquías de uno, dos o tres niveles.	ACM proporciona, gestiona e implementa certificados para los servicios de AWS y los recursos conectados, en lugar de operar su propia jerarquía de CA.	Permite diseñar una jerarquía de autoridades de certificación de hasta cinco niveles.	Cuando una CA subordinada se encadena a una CA raíz externa, las propiedades de la CSR generada por la CAS deben conservarse en el certificado de la CA firmada, incluida cualquier restricción de longitud de ruta.
11	Redundancia y recuperación ante desastres	Los planes de redundancia y recuperación ante desastres deben integrarse en la fase de diseño y planificación de la implementación de un despliegue de PKI.	ACM no cuenta con un acuerdo de nivel de servicio (SLA) específico, aunque el servicio gestionado de la Autoridad de Certificación Privada de ACM sí lo tiene.	Disponible en varias regiones de AWS para CA redundantes, operando bajo un objetivo de SLA del 99.9 % de disponibilidad.	Disponible en varias regiones de Google Cloud para mayor redundancia, operando bajo un objetivo de SLA del 99.9 % de disponibilidad.

Ventajas y desventajas por plataforma

Infraestructura de clave pública de Microsoft (ADCS)

Ventajas: control total sobre la jerarquía y la política de la CA, estrecha integración con Active Directory, sin tarifas recurrentes de servicio en la nube para la propia CA, bien comprendida por la mayoría de los administradores de Windows empresariales.

Desventajas: requiere la adquisición interna de HSM y ceremonias de CA raíz fuera de línea, procesos manuales del ciclo de vida de los certificados a menos que se agregue automatización por separado, y la carga operativa recae completamente en el personal interno.

Administrador de certificados de AWS (ACM)

Ventajas: certificados TLS públicos gratuitos para usar con servicios integrados de AWS, renovación automática, gastos operativos mínimos, integración total con CloudTrail para una mayor visibilidad de las auditorías.

Desventajas: limitado a recursos integrados con AWS y certificados públicos/importados, sin jerarquía de CA privada nativa propia y sin un SLA dedicado en el servicio gratuito de certificados públicos.

AWS ACM Private CA

Ventajas: jerarquía de CA privada totalmente gestionada de hasta cinco niveles de profundidad, claves respaldadas por HSM FIPS 140-3 Nivel 3 por defecto, auditoría nativa de CloudTrail, SLA del 99.9 %.

Desventajas: costes continuos por CA y por certificado, centrado en AWS y no aplica automáticamente todas las restricciones de RFC 5280.

Servicio de Autoridad de Certificación de Google Cloud

Ventajas: niveles flexibles para Enterprise y DevOps, claves de firma respaldadas por Cloud HSM, asignación de roles granular basada en IAM, gran compatibilidad con infraestructuras centradas en GCP.

Desventajas: la capa DevOps no admite la revocación de certificados, la publicación de CRL debe habilitarse explícitamente y no aplica todos los requisitos de RFC 5280.

Cómo elegir la infraestructura de clave pública (PKI) adecuada: Matriz de decisión

Caso de uso	Impacto en la seguridad	Esfuerzo Operacional	Ajuste de automatización	Propietario recomendado
Certificados TLS para sitios web/aplicaciones de acceso público en la infraestructura de AWS	Medio: cadena de confianza pública, ventanas de validez cortas.	Bajo, una vez configurado	Alto: AWS Certificate Manager se renueva automáticamente.	Equipos de plataforma/DevOps
CA raíz interna totalmente fuera de línea y aislada de la red para requisitos regulatorios o de alta seguridad.	Alto: raíz de confianza para toda la infraestructura de clave pública interna (PKI).	Alto — ceremonias manuales, gestión HSM	Bajo consumo de recursos por diseño (intencionadamente sin conexión)	Administradores de PKI, arquitectos de seguridad
Jerarquía de CA privada totalmente alojada en AWS para servicios internos e identidad de dispositivos.	Alto: protege la confianza entre servicios internos.	Medio: HSM gestionado, pero aún se requiere diseño de políticas y jerarquía.	Alto: Automatización de CA privada de AWS ACM y CloudTrail	Administradores de PKI, Equipos de plataforma
Infraestructura multi-nube o centrada en GCP que requiere grupos de CA por proyecto	Alto: rige la confianza en todos los proyectos de GCP.	Medio: Diseño de roles de IAM y estratificación de grupos de CA.	Alto: Google Cloud CAS con Cloud HSM	Equipos de plataforma, arquitectos de seguridad
Infraestructura híbrida local más infraestructura de clave pública (PKI) multi-nube que requiere una única capa de gobernanza.	Alto: abarca todas las plataformas superiores	Medio, cuando se utiliza una capa gestionada; alto si se realiza una autointegración.	Alto nivel con una capa de gestión del ciclo de vida de certificados y PKI gestionada.	CISO, arquitectos de seguridad, cumplimiento normativo

Lista de verificación práctica: Auditoría de una infraestructura de clave pública (PKI) de múltiples proveedores.

Problema	Impacto en el negocio	Acción sugerida	Propietario
No existe un proceso de decisión documentado sobre qué plataforma emite qué certificados.	Jerarquías de CA duplicadas, protección de claves inconsistente entre equipos.	Adopte una matriz de decisión documentada (caso de uso, impacto en la seguridad, esfuerzo, idoneidad para la automatización, responsable) antes de aprovisionar una nueva CA.	Arquitectos de seguridad, CISO
Cualquier jerarquía de CA que aún dependa de HSM validados según FIPS 140-2	Las validaciones pasarán a estado histórico el 21 de septiembre de 2026.	Planifique una migración a HSM validados según FIPS 140-3 Nivel 3 donde la plataforma lo admita.	Administradores de PKI, Cumplimiento
Emisión o renovación manual de certificados en cualquier plataforma.	No puedo seguir el ritmo del calendario de validez cada vez más reducido del Foro CA/Navegador.	Migrar a la automatización nativa de la plataforma (ACM, ACM Private CA o Google Cloud CAS) o a una capa PKI/CLM administrada.	Equipos de plataforma, administradores de PKI
No existe un registro de auditoría consistente en las CA de Microsoft PKI, AWS y Google Cloud.	Las deficiencias en el cumplimiento normativo solo salen a la luz durante un incidente o una auditoría externa.	Habilite y centralice CloudTrail, los registros de auditoría de la nube y la auditoría de Windows Server en una única vista de supervisión.	Arquitectos de cumplimiento y seguridad
No existe un plan de criptoagilidad para la eventual transición a PQC.	Las cuatro plataformas siguen firmando contratos con RSA o ECDSA en la actualidad.	Agregar la evaluación de preparación de PQC y la planificación de criptoagilidad a la hoja de ruta de PKI.	Arquitectos de seguridad, CISO

¿A quién debería importarle esto?

Elegir entre plataformas PKI no es solo una decisión de arquitectura. Esto es lo que cada parte interesada debería tener en cuenta.

Administradores de PKI

Gestionar el funcionamiento diario de la plataforma (o plataformas) que utilice la organización. Acción: confirmar que cada jerarquía de CA en uso, ya sea Microsoft PKI, AWS o Google Cloud, esté en una hoja de ruta de HSM de nivel 3 FIPS 140-3 y tenga renovación automatizada donde la plataforma lo permita.

Arquitectos de seguridad

Gestiona la matriz de decisiones y el diseño de la jerarquía en todas las plataformas. Acción: documenta por qué cada jerarquía de CA existente se encuentra donde se encuentra e identifica cualquier jerarquía que exista solo por inercia histórica en lugar de por una adecuación deliberada a un caso de uso.

Equipos de plataforma

Gestiona la capa de automatización que elimina los procesos manuales de emisión y renovación de certificados. Acción: identifica cuáles de tus certificados PKI de AWS, Google Cloud o Microsoft aún requieren la intervención humana a través de una consola en lugar de un protocolo automatizado.

Equipos de cumplimiento

Existen registros de auditoría propios y documentación CP/CPS para cada jerarquía de CA en uso. Acción: verificar que el estado de validación FIPS (140-2 frente a 140-3) se registre por HSM y por plataforma, y ​​que no se dé por sentado.

CISO

Tomar la decisión de desarrollar internamente, comprar o implementar soluciones multi-nube para la infraestructura de clave pública (PKI). Acción: evaluar el costo operativo de gestionar de forma independiente la PKI de Microsoft, AWS y las autoridades de certificación de Google Cloud frente a consolidarlas bajo una capa de gestión de PKI como servicio y de administración del ciclo de vida de los certificados.

Nuestra opinión: Cómo la consultoría en cifrado ayuda a seleccionar proveedores de PKI.

En Encryption Consulting , nos especializamos en el diseño y la migración de infraestructuras PKI que se adaptan a las necesidades de seguridad específicas de cada organización, independientemente de la plataforma o combinación de plataformas más adecuada. Ofrecemos servicios integrales de diseño e implementación de PKI, tanto para infraestructuras existentes como para nuevas. Nuestras soluciones locales incluyen Microsoft PKI, mientras que nuestras soluciones en la nube funcionan con los principales proveedores de servicios en la nube, como AWS Certificate Manager, AWS ACM Private CA, Azure PKI y Google Cloud Certificate Authority Service.

Para las organizaciones que prefieren no gestionar esta decisión, o la jerarquía resultante, internamente, nuestra plataforma PKI-as-a-Service ofrece una PKI totalmente gestionada en la nube con claves respaldadas por HSM FIPS 140-3 desde el primer día, por lo que la comparación de plataformas anterior se convierte en tarea de nuestro equipo en lugar de la suya. Nuestra capa CertSecure Manager gestiona el ciclo de vida de los certificados y el descubrimiento automatizado en cualquier combinación de PKI de Microsoft, AWS y CA de Google Cloud que la organización ya utilice, eliminando la brecha de emisión manual mencionada en la lista de verificación anterior. En cuanto a la cuestión de la criptoagilidad planteada anteriormente, nuestro Centro de Excelencia PQC y la Evaluación de Preparación PQC ayudan a los equipos a planificar la migración final desde RSA y ECDSA, y nuestra plataforma de inventario y descubrimiento criptográfico CBOM Secure proporciona a los arquitectos de seguridad el inventario de identidades de máquinas necesario para saber exactamente qué se ejecuta en cada jerarquía de CA actualmente. Para obtener más información sobre la automatización de la gestión del ciclo de vida de los certificados una vez elegida la plataforma, consulte nuestra publicación relacionada sobre cómo CLM ayuda a mitigar los ataques SSL/TLS comunes.

OTRAS LECTURAS

Guía del usuario de AWS ACM Private CA

Servicio de Autoridad de Certificación de Google Cloud

Política de certificados de los servicios PKI de Microsoft

Conclusión

La infraestructura de clave pública (PKI) desempeña un papel fundamental para garantizar la seguridad de las comunicaciones mediante certificados digitales. Las autoridades de certificación y las autoridades de registro colaboran para autenticar entidades y gestionar el ciclo de vida de los certificados. Diversos proveedores ofrecen soluciones PKI personalizadas, cada una con ventajas específicas para distintos casos de uso: Microsoft PKI promueve la gestión segura de claves en las instalaciones con CA raíz y HSM sin conexión; AWS Certificate Manager y ACM Private CA ofrecen gestión de certificados automatizada y nativa de la nube con protección HSM FIPS 140-3 Nivel 3; y el servicio de autoridad de certificación de Google Cloud se centra en el control de acceso basado en roles y las claves de firma respaldadas por HSM en la nube. La solución ideal rara vez reside en una sola plataforma; se trata de una decisión documentada, adaptada al caso de uso, el impacto en la seguridad, el esfuerzo operativo y la propiedad, y actualizada a medida que se reducen los periodos de validez y el sector avanza hacia la preparación para la era post-cuántica.

Preguntas frecuentes

¿Cuál es la principal conclusión que se puede extraer al comparar estas plataformas PKI?

Microsoft PKI, AWS Certificate Manager, AWS ACM Private CA y Google Cloud CAS emiten y administran certificados digitales de confianza, pero difieren en la ubicación de las claves de CA, el grado de automatización de la emisión y la responsabilidad operativa. La elección correcta depende del caso de uso, no de una única plataforma considerada la mejor.

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

Los equipos de PKI empresariales gestionan cada vez más más de una de estas plataformas simultáneamente. Sin un proceso de decisión documentado, esta combinación genera jerarquías de CA duplicadas, niveles de protección de claves inconsistentes y lagunas en el registro de auditoría que solo salen a la luz durante un incidente.

¿Qué riesgos aumentan si la selección del proveedor de PKI se realiza sin un proceso documentado?

La selección ad hoc de proveedores aumenta el riesgo de que se emitan certificados con niveles de protección HSM inconsistentes, jerarquías de CA que nadie puede controlar y procesos de renovación manuales que no pueden seguir el ritmo del calendario de validez cada vez más ajustado del CA/Browser Forum.

¿Qué equipos deberían ser responsables de la decisión sobre la selección del proveedor de PKI?

Los arquitectos de seguridad suelen ser responsables de la matriz de decisiones y el diseño de la jerarquía, los administradores de PKI son responsables del funcionamiento diario de las plataformas elegidas, los equipos de plataforma son responsables de la capa de automatización, el departamento de cumplimiento verifica la documentación y el estado FIPS, y el CISO es responsable de la decisión final sobre si desarrollar internamente, comprar o adoptar múltiples soluciones en la nube.

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

Todas las plataformas incluidas en esta comparación requieren procesos de emisión, renovación y revocación fiables. Las herramientas de gestión del ciclo de vida de los certificados, que abarcan Microsoft PKI, AWS y Google Cloud, son las que garantizan esta fiabilidad, independientemente de la plataforma que haya emitido el certificado.

¿Cómo deberían las organizaciones medir si la elección de su proveedor de infraestructura de clave pública (PKI) está dando buenos resultados?

Realizar un seguimiento de las interrupciones relacionadas con los certificados y los incidentes de certificados caducados, determinar si la emisión y la renovación están automatizadas en lugar de manuales, si el registro de auditoría está centralizado en todas las plataformas y si el nivel de protección HSM de cada jerarquía de CA está actualizado.

¿Qué aspectos deben auditarse o supervisarse periódicamente en una infraestructura de clave pública (PKI) de múltiples proveedores?

Revise periódicamente la documentación de la jerarquía de CA (CP/CPS), el estado de validación FIPS por HSM, la caducidad de los certificados en todas las plataformas en uso y si CloudTrail, los registros de auditoría en la nube y la auditoría de Windows Server están realmente habilitados y supervisados.

¿Cómo afecta la elección del proveedor de PKI a los entornos en la nube, híbridos o con múltiples autoridades de certificación?

Los entornos híbridos y multinube suelen ejecutar la infraestructura de clave pública (PKI) de Microsoft en las instalaciones, junto con las autoridades de certificación (CA) de AWS y Google Cloud, cada una con su propia consola, modelo de automatización y registro de auditoría. Una única capa de gobernanza o una plataforma PKI/CLM gestionada suele ser lo que mantiene la coherencia de esta combinación, evitando su fragmentación.

¿Qué errores comunes deben evitar los equipos al elegir entre estas plataformas?

Entre los errores comunes se incluyen elegir una plataforma en función de la nube en la que se ejecuta el resto de la carga de trabajo, en lugar de basarse en el caso de uso real; dejar sin comprobar durante años el estado de validación FIPS de una CA raíz; y ejecutar jerarquías de CA paralelas en diferentes plataformas sin una razón documentada para cada una.

¿Qué se debe actualizar trimestralmente en una infraestructura de clave pública (PKI) de múltiples proveedores?

Revise los paneles de control de vencimiento de certificados, confirme el progreso de la migración a FIPS 140-3 para cualquier HSM que aún esté en 140-2, revise la matriz de decisiones para cualquier nuevo caso de uso agregado desde la última revisión y confirme que los cambios en el período de validez de CA/Browser Forum se reflejen en la automatización de la renovación.