PKI basada en la nube: GCP, AWS y Azure

La infraestructura de clave pública (PKI) basada en la nube ejecuta parte o la totalidad de la jerarquía de la autoridad de certificación (CA) en la infraestructura de AWS, Azure o GCP, en lugar de en hardware local. Esto es importante porque la vida útil de los certificados se está reduciendo rápidamente según el calendario de validez del CA/Browser Forum, y la PKI manual, basada en hardware, no puede seguir el ritmo. La acción recomendada es mantener la CA raíz (e idealmente la CA de políticas) sin conexión, independientemente de la nube que se utilice, y elegir la arquitectura híbrida que mejor se adapte al nivel de control que se necesita sobre la CA emisora.

Publicado: octubre de 2020. Actualizado: agosto de 2026. Revisado por el equipo asesor de PKI de Encryption Consulting.

Si prefiere no construir ni operar esta arquitectura usted mismo, nuestra guía de modelos de implementación de PKIaaS compara la alternativa totalmente administrada. Y si aún no se decide sobre la custodia de los HSM, el artículo " HSM dedicados frente a HSM compartidos en PKIaaS" profundiza en esta disyuntiva.

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

La infraestructura de clave pública (PKI) es el conjunto de hardware, software, políticas y procedimientos necesarios para crear, distribuir y revocar certificados digitales, que demuestran la identidad de una persona, dispositivo o servicio en una red. La función principal de una PKI es la autenticación y la confidencialidad: permite que dos partes confíen en la identidad de la otra y cifren lo que intercambian, y lo logra mediante tres propiedades conocidas como la tríada CIA : confidencialidad (solo el destinatario previsto puede leer los datos), integridad (los datos no se alteraron durante la transmisión) y disponibilidad (los sistemas que emiten y validan certificados están operativos cuando se necesitan).

La infraestructura de clave pública (PKI) basada en la nube simplemente significa que uno o más niveles de esa jerarquía de CA, generalmente la CA emisora, se ejecutan en la infraestructura de AWS, Azure o GCP en lugar de en hardware propio. Algunos términos se repiten a lo largo de esta comparación: una CA raíz es el ancla de confianza de la jerarquía y normalmente se mantiene fuera de línea; una CA emisora ​​(a veces llamada CA subordinada) es la CA que realmente firma los certificados de entidad final; una CA de políticas es un nivel intermedio opcional que restringe lo que una CA emisora ​​puede emitir; un HSM (módulo de seguridad de hardware) es el hardware a prueba de manipulaciones que genera y protege la clave privada de una CA; y CDP, AIA y OCSP son los servicios de revocación y encadenamiento de certificados (punto de distribución de CRL, acceso a información de autoridad y protocolo de estado de certificado en línea) que permiten a las partes confiables verificar si un certificado sigue siendo válido.

¿Por qué las organizaciones migran su infraestructura de clave pública (PKI) a la nube?

Las organizaciones migran sus CA emisoras a la nube para reemplazar la gestión manual y costosa del hardware por un servicio que se adapta a la demanda y elimina la mayor parte de la carga de mantenimiento. A diferencia de una implementación local, una CA emisora ​​en la nube no requiere que usted instale un HSM, actualice el sistema operativo ni planifique los ciclos de renovación del hardware. El proveedor de la nube se encarga de la disponibilidad, la escalabilidad y la infraestructura subyacente, mientras usted se concentra en la política y la emisión de certificados. Este cambio es especialmente importante para las organizaciones cuyo volumen de certificados crece de forma impredecible, ya que una CA emisora ​​en la nube puede absorber un aumento repentino en la inscripción (una nueva unidad de negocio, una flota de IoT, un clúster de Kubernetes que se expande) sin un ciclo de adquisición de hardware intermedio.

¿Cuáles son los desafíos comunes de la infraestructura de clave pública (PKI) basada en la nube?

La mayoría de los problemas de PKI en la nube se deben a cinco deficiencias recurrentes: un diseño poco claro, ignorar los HSM, elegir la nube incorrecta para los requisitos, una integración deficiente con la infraestructura existente y la ausencia de un proceso real de ciclo de vida de los certificados.

• Fundamentos débiles de la infraestructura de clave pública (PKI). Los equipos que se saltan una fase de diseño propiamente dicha tienden a pasar por alto también los requisitos de cumplimiento, como la guía de gestión de claves criptográficas de la norma NIST SP 800-57, que debe aplicarse antes de la implementación, no descubrirse después.
• Considerar los HSM como opcionales. Si se omite el almacenamiento de claves respaldado por HSM para la clave privada de una CA, significa que la CA no cumple con el nivel 3 de FIPS 140, sin más; el almacenamiento de claves exclusivamente por software no puede afirmar eso, independientemente del proveedor de la nube.
• Elegir una nube por comodidad en lugar de por su idoneidad. AWS, Azure y GCP admiten servicios de CA y opciones de HSM significativamente diferentes; la elección correcta depende de dónde se encuentren ya sus cargas de trabajo y qué régimen de cumplimiento se aplique, no de qué consola conozca mejor su equipo.
• Escasa integración con la infraestructura de clave pública (PKI) existente. Una CA emisora ​​en la nube que no esté correctamente encadenada a sus CA raíz y de políticas existentes crea una segunda jerarquía desconectada en lugar de extender la que usted ya confía.
• No hay proceso de ciclo de vida del certificado. Elegir las herramientas adecuadas para el descubrimiento, la emisión, la renovación y la revocación es tan importante como la propia arquitectura de la CA; un ciclo de vida de certificados no gestionado provoca interrupciones independientemente de lo bien diseñada que esté la infraestructura de clave pública subyacente.

¿Cómo se comparan los modelos de control de claves nativos y externos para la infraestructura de clave pública en la nube?

Utilice la custodia nativa de HSM en la nube para la CA emisora ​​que necesita escalar e integrarse con los servicios en la nube, y mantenga la custodia externa local para la CA raíz (y normalmente la CA de políticas) cuya clave privada nunca debería ser accesible a través de una red.

Modelo	Dónde reside la clave privada	Uso típico
Nativo (custodia de HSM en la nube)	Generado y almacenado dentro de AWS CloudHSM (detrás de ACM Private CA), Azure Managed HSM o GCP Cloud HSM.	Autoridad de certificación emisora ​​que necesita escalar, integrarse con servicios nativos de la nube y emitir en grandes volúmenes.
Importado (equivalente a BYOK)	Material clave generado en su propio HSM, luego importado al HSM en la nube o a una CA instalada en una máquina virtual en la nube respaldada por un HSM local.	Migrar la identidad de una CA existente a la nube sin regenerar la confianza o sin cumplir con una política que requiere material de clave generado por el cliente.
Externo (equivalente a HYOK)	Nunca se importa a la nube; permanece en un HSM aislado de la red, en las instalaciones, utilizado únicamente durante las ceremonias de firma programadas.	CA raíz y, a menudo, CA de políticas, en todas las arquitecturas que se describen a continuación.

La disyuntiva refleja la gestión de claves en general: la custodia nativa en la nube ofrece escalabilidad elástica y una estrecha integración con IAM y registro en la nube, mientras que la custodia externa proporciona la mayor garantía (una cuenta en la nube comprometida no puede acceder a la clave de la CA raíz), a costa de un proceso manual y ceremonial cada vez que se necesite usar esa clave. Nuestra guía de ceremonias de CA raíz explica cómo se lleva a cabo este proceso en la práctica.

¿Cómo controla IAM el acceso a las claves privadas de PKI en la nube?

El diseño de IAM de una infraestructura de clave pública (PKI) en la nube debe separar a las personas que administran la propia CA de las personas y los sistemas que solo necesitan solicitar un certificado, utilizando el sistema de identidad que ya proporciona la nube subyacente.

• AWS: Las políticas de IAM controlan quién puede llamar a las API de ACM Private CA y CloudHSM, mientras que CloudHSM además impone sus propios roles de oficial criptográfico y usuario criptográfico dentro del HSM, por lo que un permiso de AWS IAM por sí solo no es suficiente para usar la clave.
• Azur: Azure RBAC controla quién puede administrar los recursos de soporte de la CA, mientras que Managed HSM impone un modelo RBAC local e independiente que, por diseño, ni siquiera los administradores de suscripción de Azure pueden anular.
• PCG: Los roles de Cloud IAM, con ámbito limitado a Cloud HSM y al Servicio de Autoridad de Certificación, controlan tanto las acciones administrativas (crear o deshabilitar una CA) como las acciones de emisión (solicitar un certificado), y Google recomienda mantener separados estos dos conjuntos de roles.

Una configuración práctica de privilegios mínimos sigue los mismos cinco pasos en cualquiera de las tres nubes:

1. Inventarie todas las identidades, humanas o de servicio, que actualmente tengan algún permiso para interactuar con la CA o su HSM.
2. Separe las funciones "puede administrar la CA" (crear, deshabilitar, rotar) y "puede solicitar un certificado" en roles distintos, y no asigne ninguna identidad a ninguno de ellos.
3. Limita cada subvención al recurso CA o HSM específico, nunca uses un comodín para todas las CA de la cuenta, suscripción o proyecto.
4. Se requiere un flujo de trabajo con acceso privilegiado, e idealmente la aprobación de múltiples partes, para cualquier acción que pueda deshabilitar o eliminar una CA.
5. Revise las asignaciones de IAM relacionadas con CA con una periodicidad trimestral fija, ya que cualquier desviación en el acceso en este ámbito puede conducir directamente a la emisión incorrecta de certificados.

¿Cuáles son los modelos de arquitectura PKI basados ​​en la nube?

La mayoría de las implementaciones de PKI en la nube se basan en cuatro arquitecturas, que se diferencian principalmente en la cantidad de niveles que existen y en la cantidad de la jerarquía que permanece en las instalaciones.

Modelo	Estructura	Mejor ajuste
Modelo simple	CA raíz local y sin conexión; una única CA emisora ​​en la nube, respaldada por un HSM en la nube.	Implementaciones a pequeña escala donde una CA emisora ​​puede atender todas las solicitudes de certificados.
Modelo híbrido de dos niveles	Entidad de certificación raíz local y sin conexión; dos entidades de certificación emisoras, una local y otra en la nube, ambas en línea.	Organizaciones que aún cuentan con una infraestructura local significativa (autenticación de estaciones de trabajo, certificados de dominio) junto con cargas de trabajo en la nube.
Modelo de tres niveles	CA raíz local y sin conexión; una CA de políticas (también sin conexión) restringe explícitamente lo que la CA emisora ​​en la nube puede emitir.	Equipos que necesitan un control estricto y auditable sobre la política de emisión, al tiempo que utilizan infraestructura en la nube para la CA emisora.
Modelo híbrido de tres niveles	CA raíz y CA de políticas en las instalaciones y fuera de línea; dos CA emisoras, una en las instalaciones y otra en la nube, cada una regida por la misma CA de políticas.	Organizaciones que necesitan control a nivel de políticas tanto en la emisión local como en la nube simultáneamente

Modelo simple:

Modelo híbrido de dos niveles:

Modelo de tres niveles:

Modelo híbrido de tres niveles:

Por ejemplo, una CA emisora ​​creada con AWS Certificate Manager Private CA almacena su clave privada en AWS CloudHSM de forma transparente; el modelo que elija determina si se trata de la única CA en la jerarquía (Simple) o de varias, cada una con un ámbito definido (las variantes híbrida y de tres niveles).

¿Cómo se debe gestionar la rotación de certificados y claves de CA en una infraestructura de clave pública en la nube (Cloud PKI)?

La validez de los certificados Leaf y la rotación de claves de la CA funcionan con relojes completamente diferentes, y tratarlos como si fueran el mismo problema es un error de planificación común.

• Validez del certificado de la hoja Está establecido por la ruta de transición publicada por el CA/Browser Forum: un máximo de 200 días en la actualidad, que se reduce a 100 días el 15 de marzo de 2027 y a 47 días el 15 de marzo de 2029. Con una validez de 47 días, la renovación manual no es viable a gran escala, por lo que la automatización basada en ACME es prácticamente obligatoria para cualquier CA emisora ​​que siga este calendario.
• rotación de claves CA Funciona con un ciclo mucho más largo, vinculado al período de validez de la CA raíz o emisora ​​(generalmente de 10 a 20 años para una raíz y de 3 a 5 años para una CA emisora) y al costo de ejecutar una nueva ceremonia de clave, no al calendario de certificados hoja del Foro CA/Navegador. Rotar una clave de CA implica generar un nuevo par de claves, emitir un nuevo certificado de CA y volver a encadenar todos los certificados dependientes, por lo que se planifica de forma deliberada en lugar de automatizarse como la renovación de certificados hoja.

¿Qué información se debe registrar y monitorizar en una infraestructura de clave pública (PKI) basada en la nube?

Cada capa de una infraestructura de clave pública (PKI) en la nube, la propia CA, el HSM que protege su clave y la plataforma en la nube que aloja ambos, necesita tener habilitado su propio registro de eventos antes de que se emita el primer certificado.

• Registros a nivel de CA: Cada emisión, revocación y cambio de política debe registrarse con la identidad solicitante, independientemente de la nube que aloje la CA.
• Registros a nivel de HSM: AWS CloudTrail registra las llamadas a la API de CloudHSM y ACM Private CA, Azure Monitor registra las operaciones de Managed HSM a través de su configuración de diagnóstico, y GCP Cloud Audit Logs registra la actividad de Cloud HSM y del servicio de autoridad de certificación; en los tres casos, esto debe enrutarse explícitamente a un SIEM, y no dejarse en el período de retención predeterminado.
• Controles de cara al público: Los registros de Transparencia de Certificados le proporcionan un registro independiente, de solo adición, de cada certificado de confianza pública emitido bajo sus dominios, lo cual vale la pena monitorear incluso para los certificados que no tenía intención de emitir.

Las alertas específicas sobre intentos de exportación de claves de CA, la emisión inesperada de certificados fuera de su flujo de trabajo de inscripción habitual y cualquier cambio en las restricciones de emisión de una CA de políticas son los eventos que convierten la operación rutinaria de PKI en un incidente.

¿Cómo se comparan los costos de AWS, Azure y GCP para la infraestructura de clave pública (PKI) basada en la nube?

La infraestructura de clave pública (PKI) basada en la nube reemplaza la mayor parte del elevado coste inicial de una implementación local con tarifas recurrentes de servicio de HSM y CA que se ajustan al uso en lugar de al número de empleados o a los ciclos de renovación del hardware.

Factor de costo	Modelo aproximado
AWS (ACM Private CA + CloudHSM)	ACM Private CA factura por CA al mes más las tarifas de emisión por certificado; CloudHSM factura por instancia de HSM por hora si necesita un control dedicado de HSM más allá de la opción administrada de ACM PCA.
Azure (HSM administrado)	Se factura por grupo HSM por hora en lugar de por clave, generalmente entre $3 y $3.20 por hora para el nivel estándar, independientemente del volumen de certificados.
GCP (HSM en la nube + Servicio de Autoridad de Certificación)	Un HSM en la nube para un solo inquilino cuesta aproximadamente 3,500 dólares al mes e incluye una gran cantidad de versiones de claves sin cargo adicional; el Servicio de Autoridad de Certificación añade sus propias tarifas por CA y por certificado.
Infraestructura de clave pública (PKI) local (para comparación)	Nuestra propia desglose de los costos internos de PKI Esto sitúa la diferencia total en aproximadamente 300,000 dólares más que un servicio gestionado comparable, una vez que se tienen en cuenta los HSM, el personal de ingeniería de PKI, las ceremonias raíz y las auditorías.

Considere las cifras de la nube anteriores como orientativas y confirme los precios regionales actuales antes de elaborar un presupuesto; la comparación más sólida es estructural: la infraestructura de clave pública (PKI) basada en la nube convierte la mayor parte del coste de la PKI en una tarifa predecible vinculada al uso, mientras que la PKI local concentra el coste en grandes eventos de capital poco frecuentes (compras de HSM, ceremonias de raíz, actualizaciones de hardware).

¿Cómo es una arquitectura PKI basada en la nube multi-nube?

La ejecución simultánea de PKI en GCP, AWS y Azure amplía el modelo híbrido de tres niveles en lugar de reemplazarlo: una CA raíz y una CA de políticas sin conexión siguen siendo el pilar de la jerarquía, y cada nube obtiene su propia CA emisora, limitada a las cargas de trabajo que realmente se ejecutan allí.

El modo de fallo que observamos con mayor frecuencia no es arquitectónico, sino de gobernanza: tres CA emisoras aprovisionadas independientemente por tres equipos de nube diferentes, cada una con sus propios perfiles de certificados, hábitos de rotación y configuración de registro, se desvían hasta que un auditor (o una interrupción del servicio) fuerza la reconciliación. Para obtener la arquitectura de referencia completa y cómo evitar esta desviación, consulte nuestra Guía de arquitectura PKIaaS multi-nube para AWS, Azure y GCP.

¿Cuáles son las limitaciones de la infraestructura de clave pública (PKI) basada en la nube?

• La seguridad de la CA raíz sigue dependiendo del proceso, no de la nube. Trasladar una CA emisora ​​a la nube no garantiza la seguridad de una CA raíz que aún se gestiona de forma negligente en las instalaciones; la disciplina basada en procedimientos y fuera de línea debe mantenerse independientemente de dónde se encuentre el resto de la jerarquía.
• La coherencia entre nubes no es automática. AWS, Azure y GCP exponen los servicios de CA y HSM de forma diferente, por lo que los perfiles de certificados, la política de rotación y el formato de registro deben estandarizarse deliberadamente en todas las nubes; nada lo impone automáticamente.
• Dependencia del proveedor en la capa HSM. El material clave de una CA generado dentro del HSM de una nube no es simplemente portable al HSM de otra nube; migrar posteriormente implica una nueva ceremonia de clave, no un simple traslado.
• El plazo de 47 días para la implementación es un requisito indispensable para la automatización, no una preferencia. Cualquier diseño de infraestructura de clave pública en la nube que presuponga la renovación manual de certificados fracasará una vez que entren en vigor los períodos de validez más cortos del Foro de Autoridades de Certificación/Navegadores.

Lista de verificación para la toma de decisiones: Elección de una arquitectura PKI basada en la nube

1. Confirme que su CA raíz (y su CA de políticas, si la tiene) permanezca en las instalaciones, sin conexión y controlada mediante ceremonia, independientemente del modelo que elija a continuación.
2. Si su infraestructura es completamente nativa de la nube, comience con el Modelo Simple; si aún cuenta con una infraestructura local significativa, utilice el Modelo Híbrido de Dos Niveles.
3. Agregue una CA de políticas (el modelo de tres niveles o el modelo híbrido de tres niveles) solo si necesita restricciones explícitas y auditables sobre lo que una CA emisora ​​puede emitir, no de forma predeterminada.
4. Adapta tu proceso de renovación de certificados al límite de validez actual del CA/Browser Forum y considera la automatización basada en ACME como un requisito, no como una mejora futura.
5. Si actualmente gestiona más de una nube, o prevé hacerlo, diseñe la capa de gobernanza multi-nube, los perfiles de certificados compartidos, la política de rotación coherente y el registro unificado, antes de que cada equipo de nube aprovisione su propia CA emisora ​​de forma independiente.

¿Qué recomendaría Encryption Consulting?

Para la mayoría de las organizaciones, recomendamos comenzar con el modelo híbrido de tres niveles: una CA raíz y una CA de políticas fuera de línea que sirvan de base a la jerarquía, con CA emisoras basadas en la nube con alcance definido por carga de trabajo y por nube. El error más frecuente no radica en la elección de AWS, Azure o GCP, sino en omitir la CA de políticas y la disciplina de gobernanza que conlleva, que es precisamente lo que evita que una PKI multi-nube se divida en tres jerarquías desconectadas y gestionadas de forma inconsistente. Si está implementando esto usted mismo, nuestras soluciones de PKI como servicio y HSM como servicio pueden encargarse de los componentes que conllevan mayor riesgo operativo: la custodia del HSM, las ceremonias raíz y la gobernanza del perfil de certificado, mientras usted mantiene el control de la política de emisión.

Preguntas frecuentes

¿Puedo usar una única CA raíz en AWS, Azure y GCP?

Sí, y es el enfoque recomendado. Su CA raíz permanece en las instalaciones y sin conexión, independientemente de la nube; cada nube obtiene su propia CA emisora ​​que se conecta a esa misma raíz (a través de una CA de políticas, si utiliza una), por lo que la confianza se unifica aunque la emisión se realice en tres lugares distintos.

¿Necesito un HSM dedicado si ya estoy utilizando un servicio de CA administrado como AWS ACM Private CA?

No necesariamente. ACM Private CA ya almacena su clave privada en AWS CloudHSM de forma transparente, por lo que se obtiene la custodia respaldada por HSM sin necesidad de aprovisionar un clúster CloudHSM independiente. Un HSM dedicado resulta útil cuando se requiere control sobre el propio HSM, por ejemplo, debido a un mandato de cumplimiento específico, requisitos personalizados para la ceremonia de claves o cargas de trabajo externas a ACM Private CA que necesitan compartir el mismo HSM.

¿Con qué frecuencia debo rotar la clave privada de mi CA en comparación con mis certificados hoja?

Estos procesos se rigen por calendarios diferentes y no deben confundirse. Los certificados Leaf ahora siguen el calendario de validez reducida del CA/Browser Forum (actualmente 200 días, que se reducirá a 47 días en marzo de 2029) y requieren renovación automática. La clave de una CA suele rotar con mucha menos frecuencia, aproximadamente cada años, debido al período de validez de su certificado y al coste de la ceremonia de renovación.

¿La infraestructura de clave pública (PKI) basada en la nube cumple con la norma FIPS 140-3?

Es posible, pero el cumplimiento depende de la opción de HSM que elija, no del proveedor de la nube en general. Usar un almacén de claves solo de software en lugar de una CA respaldada por HSM significa que la CA no cumple con el nivel 3 de FIPS 140, independientemente de la nube que la aloje; confirme el nivel de validación específico del servicio HSM (CloudHSM, Managed HSM o Cloud HSM) que implemente.

¿Qué ocurre con mi infraestructura de clave pública (PKI) si posteriormente añado una cuarta nube o traslado una carga de trabajo de vuelta a las instalaciones?

Si su CA raíz (y de políticas) se mantuvo localmente y sin conexión desde el principio, agregar una nueva CA emisora ​​en cualquier lugar, ya sea en una cuarta nube o de nuevo localmente, implica encadenar una nueva CA subordinada a su CA raíz existente, no reconstruir la confianza desde cero. Esta es la razón principal por la que recomendamos mantener el punto de referencia de confianza fuera de cualquier nube.

¿Tiene alguna pregunta específica sobre arquitectura PKI en la nube o migración? Póngase en contacto con nuestro equipo en [email protected].