Todo lo que necesita saber sobre PKI como servicio (PKIaaS)

El 21 de julio de 2024, un certificado caducado en la infraestructura del Banco de Inglaterra dejó fuera de servicio sus sistemas CHAPS y de liquidación minorista durante 91 minutos, según el propio Banco. No se trata de un simple fallo informático, sino de un recordatorio de que los certificados caducados o mal gestionados pueden paralizar por completo un sistema de pagos. La infraestructura de clave pública como servicio ( PKI-as-a-service) existe precisamente para evitar este tipo de situaciones, trasladando todo el ciclo de vida de los certificados, desde la configuración de una Autoridad de Certificación (CA) hasta la emisión, renovación y revocación de certificados de entidades finales, a una plataforma en la nube gestionada.

En lugar de comprar hardware, instalar software y contratar personal especializado en PKI, usted obtiene la misma infraestructura de confianza como un servicio, con procedimientos automatizados y menores costos operativos que gestionan el ciclo de vida de los certificados por usted.

Resumen Ejecutivo

La infraestructura de clave pública como servicio (PKIaaS) aloja las autoridades de certificación raíz y emisora ​​de una organización en la nube y automatiza la emisión, renovación y revocación de certificados. Esto es lo más importante para un equipo de seguridad o de infraestructura de clave pública que la esté evaluando:

• PKIaaS aloja sus CA raíz y emisoras en la nube y gestiona el ciclo de vida completo de los certificados en su nombre.
• Utiliza los mismos componentes básicos de PKI que una implementación local: pares de claves públicas/privadas, certificados digitales y una cadena de confianza con raíz en una CA.
• La propuesta SC-081v3 del Foro CA/Browser redujo la duración máxima de los certificados TLS públicos a 200 días a partir del 15 de marzo de 2026, y a 47 días en marzo de 2029, lo que hace que la gestión manual de certificados sea cada vez menos práctica.
• Los protocolos de inscripción automatizada (ACME, SCEP, EST, WSTEP) son los que permiten a PKIaaS emitir y renovar certificados sin que un humano tenga que hacer clic en "renovar" cada vez.
• PKIaaS sustituye los costes iniciales de hardware y personal por un modelo de suscripción, al tiempo que permite controlar la política de certificados y, en el modelo de Encryption Consulting, las propias claves privadas.

Ahora que ya sabes qué es PKIaaS a grandes rasgos, veamos cómo se relaciona con la infraestructura de clave pública (PKI), ya que PKIaaS no reemplaza los conceptos de PKI, sino que simplemente cambia quién los gestiona.

Cómo se relaciona PKI-as-a-Service con la infraestructura de clave pública (PKI)

La infraestructura de clave pública (PKI) emite certificados digitales (como certificados SSL/TLS) para autenticar la comunicación de datos mediante cifrado asimétrico, generando certificados X.509 a partir de pares de claves públicas y privadas. Tanto si se gestiona internamente como si se adquiere como PKIaaS, la cadena de confianza se compone de los mismos cuatro elementos.

Claves públicas y privadas

Las claves públicas y privadas realizan el cifrado asimétrico. Cuando un cliente necesita recibir información confidencial, comparte su clave pública con el remitente para cifrar los datos. Solo quien posea la clave privada correspondiente puede descifrarlos y leerlos.

Certificados digitales

La clave privada de la CA firma el certificado digital . Esta firma confirma tanto la identidad del titular del certificado como la propiedad de la clave pública asociada.

Autoridad de certificación: CA raíz y CA emisora

La Autoridad de Certificación firma y emite el certificado digital con su propia clave privada. Hay dos niveles:

• CA raíz: la autoridad de nivel superior que establece la base de confianza en la jerarquía PKI. Emite y firma certificados para las CA intermedias y, por lo general, se mantiene fuera de línea en un entorno altamente seguro para proteger la confianza a largo plazo.
• Emisión de CAProcesa y firma las solicitudes de certificados de entidades finales (por ejemplo, certificados SSL/TLS), ya sea que lleguen a través de un proxy de CA de Microsoft o por otra vía de inscripción. Funciona en línea y gestiona la emisión, renovación y revocación diarias.

Autoridad de Registro

La Autoridad de Registro actúa como intermediaria entre los usuarios y la CA. Verifica la identidad de cualquier persona que solicite un certificado y, a continuación, remite las solicitudes validadas a la CA para su emisión.

PKI como servicio frente a PKI autogestionada (tradicional): ¿Cuál es la opción adecuada para usted?

Los componentes mencionados anteriormente son los mismos, ya sea que implemente la infraestructura de clave pública (PKI) localmente (autogestionada) o la adquiera como PKIaaS. Lo que cambia es quién la opera, y esa diferencia influye en el costo, la velocidad y la escalabilidad.

Factor	PKI como servicio	PKI autogestionada (tradicional)
Despliegue	Configuración rápida y gestionada con una infraestructura mínima requerida por su organización.	Se requiere una cantidad considerable de tiempo, conocimientos especializados y recursos para la configuración de hardware, software y red.
Gestión	La emisión, renovación y revocación de certificados son gestionadas por el proveedor de servicios, lo que reduce los gastos operativos.	Se gestiona internamente, lo que requiere personal especializado para las tareas de certificación y el mantenimiento continuos.
Escalabilidad organizacional	La infraestructura en la nube se ajusta automáticamente a medida que el volumen de certificados aumenta o fluctúa.	La ampliación de escala requiere hardware adicional, licencias de software y cambios de configuración.
Costo	El modelo de suscripción elimina los costes de hardware, software y mantenimiento continuo, reduciendo la inversión inicial.	Requiere una elevada inversión inicial en hardware, instalación de software y gestión continua.
Frecuencia de renovación con validez de 47 días	Los protocolos de emisión automatizados (ACME, SCEP, EST) absorben la frecuencia de renovación sin necesidad de aumentar la plantilla.	Los procesos de renovación manual fallan mucho antes de que los certificados alcancen los 100 días de vigencia, y mucho menos los 47 días.

La infraestructura de clave pública como servicio (PKI-as-a-Service) es la opción más adecuada para las organizaciones que priorizan la facilidad de uso, el ahorro de costes y una implementación más rápida, especialmente a medida que la vigencia de los certificados se reduce. Las organizaciones con requisitos estrictos de residencia de datos o configuraciones de CA altamente especializadas aún pueden tener razones válidas para mantener la PKI autogestionada, pero esta lista se está reduciendo a medida que maduran los protocolos de automatización.

Tabla de decisión del comprador: ¿Qué modelo de implementación de PKI se adapta mejor a su organización?

Utilice esta tabla para relacionar las limitaciones de su organización con un modelo de implementación antes de evaluar a los proveedores.

Criterio	PKI local	PKI SaaS	PKIaaS
Personal especializado en PKI disponible	Obligatorio	Reducido, pero aún necesario para la política.	No se requiere
Crecimiento del volumen de certificados	La escalabilidad requiere nuevo hardware.	Escala dentro de su inquilino de la nube	Se ajusta automáticamente, gestionado por el proveedor.
Tiempo para obtener el primer certificado	Semanas a meses	Días a semanas	Días
Modelo de presupuesto	Alta inversión de capital inicial	Consumo en la nube más tiempo del personal interno	Suscripción, costo inicial mínimo
Control de clave privada	Completo, en sus propios HSM	Completo, en su propio inquilino de la nube.	Completo, en HSM alojados por el proveedor (en el modelo de Encryption Consulting)
mejor ajuste para	Residencia estricta de datos o configuraciones de CA altamente especializadas.	Organizaciones que ya han estandarizado una plataforma en la nube	Organizaciones que priorizan la velocidad, la automatización y la reducción de gastos generales.

Cómo funciona PKI como servicio: El flujo de trabajo de solicitud de certificados

Desde el momento en que un dispositivo envía una solicitud de firma de certificado hasta el momento en que recibe un certificado firmado, una plataforma PKIaaS hace pasar la solicitud a través de cinco pasos:

1. Inicio de la solicitud de certificado. Un cliente solicita un certificado utilizando un protocolo como ACME, SCEP o AfinadoLa solicitud se envía al Certificate Enrollment Gateway (CEG), que establece una conexión segura con el Certificate Authority Gateway (CAGW) utilizando su propio certificado de cliente.
2. Procesamiento de la solicitud. El CAGW, alojado en un sistema en contenedores, recibe la solicitud y la reenvía a la CA gestionada correspondiente a través de un proxy seguro.
3. Conexión con la CA emisora. El proxy actúa como puente entre el CAGW y la CA emisora ​​designada, y la conexión está protegida por certificados mutuos de cliente y servidor.
4. Emisión de certificados. La CA emisora ​​emite el certificado de entidad final, a menudo a través de Servicios de certificados de Active Directory (AD CS).
5. Entrega del certificado. El certificado firmado regresa a través del proxy al CAGW, que lo envía al CEG para su entrega al cliente solicitante.

Cada paso de esta cadena está protegido por la autenticación mutua de certificados, por lo que todo el proceso, desde la solicitud hasta la entrega, se realiza sin que una persona apruebe manualmente cada certificado.

Características clave de PKI-as-a-Service

PKI-as-a-Service proporciona un conjunto completo de funcionalidades para la gestión de certificados digitales y pares de claves. Las características principales se dividen en cuatro grupos:

• Gestión de infraestructura PKIConfiguración centralizada de PKI gestionada, incluyendo la separación opcional de la CA raíz, con el ciclo de vida completo de la CA siguiendo las mejores prácticas del sector, como los HSM de nivel 3 de FIPS 140-3 para proteger las claves privadas de la CA con alta disponibilidad. El NIST retira los certificados de validación FIPS 140-2 y los coloca en estado histórico el 21 de septiembre de 2026, por lo que las nuevas implementaciones de HSM deben especificar FIPS 140-3.
• Seguridad de la autoridad de certificaciónLas claves de la CA raíz se generan de forma segura y transparente, con protocolos de inscripción automática como SCEP, EST y ACME, además de API REST que automatizan la emisión y la renovación.
• Gestión de políticas y cumplimientoLos perfiles de certificado, los períodos de validez y las restricciones de uso de claves se definen para cumplir con los requisitos de seguridad de su organización, al tiempo que se adhieren a estándares como NIST, FIPS y GDPR.
• Integración y automatización.Las API RESTful conectan los servicios PKI con otras aplicaciones y sistemas, y los scripts y herramientas automatizan la emisión y la gestión de principio a fin.

Casos de uso y protocolos compatibles con PKI como servicio

PKIaaS obtiene su valor a través de la automatización, y la automatización se basa en protocolos de inscripción estandarizados. A continuación, se explica qué hace cada uno y dónde encaja.

Entorno de gestión de certificados automatizado (ACME)

• Automatiza la comunicación entre las autoridades de certificación y los clientes que solicitan certificados de servidor para un dominio, según se define en la RFC 8555.
• Valida la propiedad del dominio mediante los desafíos HTTP-01 (colocando un archivo en el servidor web) o DNS-01 (creando un registro DNS).
• Se comunica a través de HTTPS, lo que mantiene el proceso de gestión de certificados seguro y a prueba de manipulaciones.
• Es el protocolo que el programa Chrome Root exige a los solicitantes de CA que admitan desde febrero de 2024, y el que el Foro CA/Browser recompensa más directamente con la reducción de la duración de los certificados, ya que está diseñado para una automatización completa sin necesidad de renovación manual.

Protocolo simple de inscripción de certificados (SCEP)

• Automatiza la inscripción de certificados para dispositivos como enrutadores y conmutadores, lo que reduce el esfuerzo manual en entornos con gran cantidad de dispositivos.
• Utiliza PKCS#10 (Estándares de criptografía de clave pública) para solicitudes de certificados, estandarizado en RFC 8894 (2020) después de décadas como un estándar de facto.
• Antes de emitir un certificado, verifica la identidad del dispositivo o usuario solicitante mediante una contraseña de desafío compartida.
• Sigue utilizándose ampliamente en la gestión de dispositivos móviles (MDM) y en hardware de red heredado, aunque EST es su sucesor moderno y más seguro.

Inscripción a través de transporte seguro (EST)

• Definido en la RFC 7030 como el reemplazo moderno de SCEP, que se ejecuta sobre HTTPS con autenticación TLS mutua.
• Tanto el cliente como el servidor se autentican mutuamente, cerrando así una brecha de confianza que el modelo de contraseña compartida de SCEP deja abierta.
• Se adapta a las implementaciones de PKI empresarial e IoT que ya utilizan infraestructura TLS y necesitan una autenticación mutua más sólida que la que proporciona SCEP.

WSTEP (Inscripción en Windows)

• Permite que un cliente de inscripción de Windows se conecte a un controlador de dominio a través del servicio web de directivas de inscripción de certificados y solicite certificados a varias CA.
• Restringe el acceso a los certificados a los dispositivos autorizados, mejorando así la seguridad general de la red.
• Protege inscripción de certificado Datos en tránsito mediante canales seguros y cifrado.

Integración con Microsoft Intune

• La puerta de enlace de inscripción de certificados puede recibir solicitudes SCEP con una CSR de clientes Windows y reenviarlas a Intune para su validación, lo que agiliza la administración de dispositivos en dispositivos móviles, equipos de escritorio y puntos finales virtuales.
• Las políticas y los algoritmos criptográficos se mantienen alineados con los requisitos normativos y de cumplimiento.
• La revocación automática en Intune acelera la invalidación de certificados, lo que contribuye a un plan de recuperación ante desastres más sólido.

Autenticación de punto final (UEM/MDM)

• Verifica que los certificados se emitan con configuraciones de seguridad robustas, lo que permite visualizar el uso y la validez de los certificados.
• Requiere que los clientes de administración de dispositivos móviles (MDM) se autentiquen en la puerta de enlace de inscripción de certificados con credenciales de inicio de sesión válidas, con al menos un par de nombre de usuario/contraseña definido por cliente.
• Garantiza un control de acceso granular y permisos basados ​​en roles, un requisito de cumplimiento según NIST y FIPS 140-3, de modo que solo el personal autorizado gestione las funciones confidenciales de los certificados.
• Emite certificados únicamente tras evaluar tanto la integridad de los datos como los niveles de parches de seguridad del dispositivo solicitante.

S / MIME

• Proporciona cifrado de extremo a extremo para los mensajes de correo electrónico.
• Separa las funciones de firma y cifrado, lo que permite que los certificados S/MIME ofrezcan no repudio junto con confidencialidad.
• Utiliza la gestión del historial de claves y la copia de seguridad automatizada para mantener las claves criptográficas disponibles sin interrupciones.
• Funciona en Windows, macOS, iOS y Android.

PKI administrada

• Garantiza la seguridad de la infraestructura de la CA raíz conforme a las normas ISO/IEC 27001, protegiendo así los activos criptográficos.
• Te permite mantener el control total de tus claves privadas, con una supervisión completa de los certificados y las operaciones criptográficas.
• Almacena claves privadas con certificación FIPS 140-3 Nivel 3 Módulos de seguridad de hardware (HSM) para evitar el acceso no autorizado o la manipulación.
• Verifica la validez y el estado del certificado a través de la CRL (Lista de revocación de certificados) y OCSP (Protocolo de estado de certificado en línea) servicios.

Lista de verificación de SLA y controles de seguridad para evaluar un proveedor de PKIaaS

Antes de firmar un contrato PKIaaS, confirme que el proveedor cumple con estos estándares de SLA y controles de seguridad:

• Acuerdo de nivel de servicio (SLA) publicado sobre el tiempo de actividad (99.9 % o superior) para los puntos finales de emisión, renovación y revocación, con tiempos de respuesta a incidentes documentados.
• Las claves privadas de la CA raíz y de la CA emisora ​​se generan y almacenan en módulos de seguridad de hardware (HSM) validados según la norma FIPS 140-3 de nivel 3, no en servidores de propósito general.
• Compromisos de disponibilidad de CRL y OCSP para respondedores, publicados por separado del SLA de emisión principal.
• Documentación de los procedimientos clave de la ceremonia y los derechos de auditoría para la generación de claves de la CA raíz.
• Plazo establecido para la revocación de certificados tras una posible vulneración de claves.
• Control de acceso basado en roles y autorización para múltiples usuarios en operaciones de CA sensibles.
• Divulgación clara de dónde se almacenan los metadatos de los certificados y los registros de auditoría, para confirmar la residencia de los datos.
• Arquitectura documentada de recuperación ante desastres y conmutación por error en la capa de la CA emisora.
• Certificaciones de cumplimiento vigentes (ISO/IEC 27001, SOC 2, PCI-DSS, HIPAA, GDPR) con fechas de auditoría recientes.
• Condiciones contractuales que confirman la propiedad de la clave privada y su portabilidad en caso de que cambie de proveedor posteriormente.

HSM y requisitos de cumplimiento para PKI-as-a-Service

La fiabilidad de una plataforma PKIaaS depende directamente del hardware que protege sus claves privadas de CA y del marco de cumplimiento que rige su funcionamiento.

• HSM de nivel 3 FIPS 140-3Las claves privadas de la CA raíz y emisora ​​deben generarse y almacenarse en módulos de seguridad de hardware (HSM) validados según FIPS 140-3 Nivel 3. El NIST retirará los certificados de validación FIPS 140-2 y los clasificará como históricos el 21 de septiembre de 2026, por lo que debe confirmar que cualquier HSM que utilice su proveedor esté validado según FIPS 140-3 y no dependa de un certificado FIPS 140-2 que está por caducar.
• ISO / IEC 27001: El sistema de gestión de seguridad de la información del proveedor debe contar con la certificación ISO/IEC 27001 vigente que cubra los sistemas que alojan su infraestructura de CA.
• HIPAA, PCI-DSS y GDPRSi sus certificados protegen información de salud protegida (PHI), datos de titulares de tarjetas o datos personales de la UE, confirme que el entorno PKIaaS del proveedor esté explícitamente incluido en su programa de cumplimiento HIPAA, PCI-DSS o GDPR, y no solo en la postura general de cumplimiento de la empresa matriz.
• Modelo de custodia de llavesAclare de antemano si su organización o el proveedor tiene el control final de la clave privada de la CA raíz. El modelo PKIaaS de Encryption Consulting mantiene ese control en manos del cliente, algo que no todos los proveedores ofrecen.

Por qué la automatización de certificados es importante ahora: el plazo de 47 días

He aquí la parte que la mayoría de los que explican la infraestructura de clave pública (PKI) pasan por alto: los argumentos a favor de PKIaaS se fortalecieron mucho en 2026, y ya no se trata solo de comodidad.

En abril de 2025, el Foro CA/Browser aprobó la propuesta SC-081v3, que establece una reducción gradual del período máximo de validez de los certificados TLS públicos: 200 días a partir del 15 de marzo de 2026 (ya en vigor), 100 días a partir del 15 de marzo de 2027 y 47 días a partir del 15 de marzo de 2029. Esto supone una reducción del antiguo estándar de 398 días a renovaciones cada 47 días, aproximadamente ocho veces al año, en un plazo de tres años.

Los cálculos operativos no funcionan con la renovación manual a esa frecuencia, y los datos de la industria lo confirman. El informe de CyberArk de 2025 sobre el estado de la seguridad de la identidad de las máquinas, basado en una encuesta a más de 1,200 líderes de seguridad, reveló que el 72 % de las organizaciones experimentaron al menos una interrupción relacionada con certificados en el último año, y el 50 % reportó un incidente de seguridad o una brecha vinculada a identidades de máquinas comprometidas. La automatización también se ha convertido en un requisito para las CA públicas: el programa Chrome Root exige a los solicitantes de CA que admitan al menos una solución automatizada de emisión y renovación para cada política de certificados que emitan desde febrero de 2024, y a partir del 15 de junio de 2026, además, exige que los certificados TLS de confianza pública solo incluyan la EKU de autenticación del servidor, lo que obliga a cualquier organización que aún utilice certificados públicos para la autenticación de clientes o mTLS a recurrir a una CA privada.

Nuestra opinión: si su equipo todavía renueva los certificados manualmente o los registra en una hoja de cálculo, el plazo de 100 días en marzo de 2027 es el punto en el que ese proceso se interrumpe, no el de 47 días en 2029. Considere el período 2026-2027 como el momento oportuno para migrar a la automatización basada en ACME, SCEP o EST, ya sea a través de una plataforma interna o un proveedor de PKIaaS, antes de que la frecuencia de renovación supere la capacidad de su equipo para gestionarla manualmente.

¿Por qué contratar servicios de consultoría en cifrado para PKI como servicio?

Implemente PKI como servicio en su entorno.

Encryption Consulting ofrece una solución PKIaaS flexible y de alta seguridad con soporte escalable que gestiona el ciclo de vida completo de los certificados digitales para su organización. Dos áreas destacan:

• Soluciones personalizables y escalables: un marco de trabajo adaptado a los requisitos de seguridad de su organización, con amplio soporte para autoridades de certificación y la capacidad de escalar el volumen de certificados y usuarios sin perjudicar el rendimiento.
• Apoyo constante: fuertes características de seguridad alineadas con HIPAA, PCI-DSS y GDPR, además de soporte operativo diario para mantener bajo control las políticas de certificados.

Modelos de implementación: local, PKI SaaS y PKIaaS

Encryption Consulting admite tres enfoques de implementación, para que pueda adaptar el modelo a su entorno:

• PKI local: PKI gestionada e implementada dentro de su propia infraestructura, con CA raíz y emisoras alojadas en sus propias instalaciones.
• PKI SaaS: Gestión del ciclo de vida de los certificados configurada dentro de la plataforma en la nube de su propia organización.
• PKIaaS: Gestión automatizada del ciclo de vida de los certificados y PKI gestionada a medida, alojada íntegramente en el entorno de nube de Encryption Consulting, adaptada a su dominio y requisitos de seguridad.

Conclusión

PKIaaS es la evolución en la nube del mismo modelo de confianza PKI en el que las organizaciones han confiado durante décadas, pero sin los costos adicionales de hardware, personal y renovación manual. Toda organización que maneje datos confidenciales, ya sea información de identificación personal (PII) o información de salud protegida (PHI), necesita la autenticación y el cifrado que proporciona una PKI. PKIaaS ofrece esto como un servicio gestionado en la nube, en lugar de un proyecto de infraestructura interna.

Con la reducción de la vida útil de los certificados que ya está en marcha en el CA/Browser Forum, la cuestión no es si automatizar la gestión de certificados, sino cuándo. Una plataforma PKIaaS basada en ACME, SCEP y EST ofrece esa automatización sin aumentar la plantilla, al tiempo que permite controlar la política de certificados y, según el proveedor, las claves privadas.

Preguntas frecuentes sobre PKI como servicio

¿Cuál es la principal conclusión de esta guía sobre PKI como servicio?

PKIaaS traslada las operaciones de la CA raíz y emisora, la gestión de HSM y el ciclo de vida completo del certificado a una plataforma en la nube gestionada, lo que permite a las empresas cambiar el coste de capital y la carga de personal de la PKI autogestionada por una suscripción que se escala automáticamente y se mantiene al ritmo de los períodos de validez de los certificados cada vez más cortos.

¿Por qué es importante la infraestructura de clave pública como servicio (PKI-as-a-Service) específicamente para los equipos de PKI empresariales?

Los equipos de infraestructura de clave pública (PKI) empresariales autentican cada servidor, dispositivo y servicio de la red. Dado que la validez de los certificados TLS públicos se reduce de 398 días a 47 días para 2029, la emisión y renovación manuales se vuelven insostenibles a escala empresarial. PKIaaS proporciona a estos equipos protocolos de inscripción automatizados (ACME, SCEP, EST) para que el volumen de certificados pueda crecer sin necesidad de aumentar la plantilla.

¿Qué riesgos aumentan si la infraestructura de clave pública (PKI) se gestiona manualmente en lugar de mediante PKIaaS?

La gestión manual de la infraestructura de clave pública (PKI) aumenta el riesgo de interrupciones por certificados caducados, como la caída de 91 minutos del servicio CHAPS del Banco de Inglaterra, renovaciones no realizadas que quedan ocultas en hojas de cálculo, protección inconsistente de las claves fuera de los módulos de seguridad de hardware (HSM) validados por FIPS y revocación tardía tras una vulneración de seguridad. La encuesta de CyberArk de 2025 reveló que riesgos como estos ya afectan a la mayoría de las empresas.

¿Qué equipos deberían ser responsables de la adopción y las operaciones continuas de PKI como servicio?

Los equipos de arquitectura de seguridad e identidad/PKI deben ser responsables del diseño de la jerarquía de CA y las decisiones de políticas, mientras que los equipos de operaciones de TI o ingeniería de plataformas suelen encargarse de la integración diaria de la inscripción en Intune, las canalizaciones de DevOps y los dispositivos de red. Los equipos de cumplimiento necesitan visibilidad del registro de auditoría y los términos de custodia de claves, ya que los requisitos normativos y de HSM recaen en última instancia sobre ellos.

¿Cómo se conecta PKIaaS con la gestión del ciclo de vida de los certificados (CLM)?

PKIaaS es la capa de infraestructura, que incluye las CA raíz y emisoras, mientras que la gestión del ciclo de vida de los certificados (CLM) es la capa operativa que realiza el seguimiento de la emisión, renovación, revocación y caducidad de cada certificado emitido por la CA. Combinar una implementación de PKIaaS con una plataforma CLM como CertSecure Manager proporciona una visibilidad completa, desde la CA hasta los certificados individuales, algo que el seguimiento manual no puede lograr a gran escala.

¿Cómo deberían las organizaciones medir el éxito de una implementación de PKIaaS?

Se realiza un seguimiento del número de interrupciones relacionadas con certificados (objetivo: cero), el tiempo promedio desde la presentación de la solicitud de firma de certificado (CSR) hasta la emisión del certificado, el porcentaje de certificados emitidos mediante protocolos automatizados frente a solicitudes manuales, los hallazgos de auditoría de HSM y CA por ciclo, y el cumplimiento de los períodos de validez cada vez más cortos del Foro de CA/Navegadores sin intervención manual. Una disminución en los incidentes de renovación no planificada es la señal de éxito más clara.

¿Qué aspectos deben auditarse o supervisarse periódicamente en un entorno PKIaaS?

Audite los registros de custodia de claves privadas de la CA y de acceso al HSM, los registros de emisión y revocación de certificados, el tiempo de actividad del respondedor CRL/OCSP, los eventos de autenticación del protocolo de inscripción (validación de desafío ACME, secretos compartidos SCEP, TLS mutuo EST) y la alineación de cumplimiento con ISO/IEC 27001, HIPAA, PCI-DSS o GDPR, según corresponda a su organización.

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

PKIaaS está diseñado para operar en entornos de nube, híbridos y con múltiples CA. La puerta de enlace de la autoridad de certificación (CPA) enruta las solicitudes a la CA administrada correspondiente a través de un proxy seguro, de modo que una organización que ejecuta varias CA, por ejemplo, CA separadas para dispositivos internos y TLS de cara al público, obtiene una única capa de inscripción automatizada en lugar de administrar el proceso de renovación de cada CA de forma independiente.

¿Qué errores comunes deben evitar los equipos al adoptar PKI-as-a-Service?

Los errores más comunes son tratar PKIaaS como una simple transferencia de procesos manuales existentes en lugar de rediseñarlos en torno a la automatización, no confirmar exactamente dónde genera y almacena el proveedor las claves privadas antes de firmar un contrato, omitir los requisitos de validación FIPS 140-3 para HSM y no probar la conmutación por error a una CA emisora ​​redundante antes de que sea necesaria durante una interrupción.

¿Qué elementos deben actualizarse trimestralmente en un programa de infraestructura de clave pública como servicio (PKI-as-a-Service)?

Revise los perfiles de certificados de CA y los períodos de validez según el calendario actual del Foro CA/Navegador, vuelva a validar el estado de la certificación FIPS de HSM, especialmente teniendo en cuenta que los certificados FIPS 140-2 pasarán a estado histórico el 21 de septiembre de 2026, actualice el inventario de protocolos de inscripción en uso por tipo de dispositivo y reconfirme los compromisos de SLA y control de seguridad con su proveedor de PKIaaS.