Herramientas de cifrado de datos de Google Cloud Platform: KMS, HSM y PKI

Google Cloud Platform protege los datos mediante tres capas interconectadas: Cloud KMS para la gestión de claves, Cloud HSM/Cloud EKM para la custodia de claves y el Servicio de Autoridad de Certificación para la infraestructura de clave pública (PKI). Esto es importante porque elegir la capa incorrecta (por ejemplo, una clave de software cuando un requisito de cumplimiento exige la custodia del hardware) genera una brecha de auditoría posterior. Acción recomendada: usar Cloud KMS por defecto con claves respaldadas por software y recurrir a Cloud HSM o Cloud EKM solo cuando un requisito específico lo exija.

Publicado: noviembre de 2020. Actualizado: agosto de 2026. Revisado por el equipo de gestión de claves en la nube de Encryption Consulting.

Esta publicación ofrece una visión general de cómo se integran las herramientas de cifrado de GCP. Para conocer el funcionamiento interno específico de Cloud KMS (jerarquía de claves, llaveros de claves, niveles de protección), consulte nuestro análisis detallado de Google Cloud Security – Key Management Services . Para comparar el KMS de GCP con el de AWS y Azure, consulte AWS KMS vs. Azure Key Vault vs. GCP KMS.

¿Cómo funciona el cifrado de datos en Google Cloud?

Los datos en la nube existen en dos estados que requieren una protección distinta: datos en tránsito y datos en reposo. El cifrado de datos en tránsito utiliza TLS para encapsular los datos durante su transferencia entre sistemas, de modo que un paquete interceptado resulta ilegible incluso si se captura. El cifrado de datos en reposo protege los datos almacenados en disco o en almacenamiento de objetos, convirtiendo el texto plano en texto cifrado que carece de sentido sin la clave. GCP cifra ambos tipos de datos de forma predeterminada: AES-256 para los datos en reposo en Google Cloud Storage y TLS para los datos en tránsito, sin necesidad de configuración adicional para habilitar ninguna de las dos opciones.

El cifrado predeterminado utiliza cifrado de sobre: ​​una clave de cifrado de datos (DEK) cifra los datos en sí, y una clave de cifrado de clave (KEK) cifra la DEK para una mayor protección. Ambas se gestionan a través de la API del Servicio de administración de claves en la nube de Google (Cloud KMS) , que se integra con el resto de Google Cloud (Cloud Storage, Cloud Functions, BigQuery, Compute Engine) para que los servicios puedan solicitar operaciones de cifrado sin tener que gestionar directamente el material de clave sin procesar.

¿Cómo funciona el control de claves nativas frente al control de claves externas en GCP?

Cloud KMS ofrece cuatro formas distintas de obtener una clave, cada una con un modelo de custodia diferente:

Modelo de control de llaves	Cómo funciona	Mejor ajuste
Software KMS en la nube (nativo)	Claves simétricas o asimétricas generadas y utilizadas íntegramente dentro del módulo criptográfico de software de Google.	La opción predeterminada para la mayoría de las cargas de trabajo; el menor coste y sin dependencia de hardware.
HSM en la nube (nativo, con respaldo de hardware)	Las claves se generan y utilizan únicamente dentro de los módulos de seguridad de hardware validados según la norma FIPS 140-2 de nivel 3 que opera Google.	Cargas de trabajo con requisitos de cumplimiento de custodia de hardware (mandatos de PCI DSS HSM, algunos contratos gubernamentales).
BYOK (material clave importado)	Una organización genera material clave fuera de GCP y lo importa a Cloud KMS, que luego gestiona su ciclo de vida en adelante.	Organizaciones que necesitan demostrar la procedencia de las claves o que ya generan claves a través de un HSM local existente.
EKM en la nube (externo/equivalente a HYOK)	Cloud KMS hace referencia a una clave que reside físicamente en un gestor de claves externo (Thales, Fortanix y otros); Google nunca almacena material de clave utilizable.	Datos regulados en los que un contrato o un organismo regulador exige que Google nunca posea la clave.

Por defecto, utilice las claves respaldadas por software de Cloud KMS a menos que un requisito específico indique lo contrario. Tanto Cloud HSM como Cloud EKM aumentan el costo y la latencia, y solo merecen la pena cuando una obligación de cumplimiento o una cláusula contractual específica exige ese nivel de custodia.

¿Cómo gestiona IAM el acceso a los recursos de KMS, HSM y PKI?

La gestión de identidades y accesos (IAM) es la capa de permisos que se aplica a todas las operaciones clave en GCP. Cualquier servicio o usuario que intente utilizar una clave de cifrado de dominio (DEK) o clave de cifrado de clave (KEK) necesita primero un rol de IAM que le otorgue ese permiso específico. Los roles de IAM pueden definirse a nivel de llavero (que abarca todas las claves del grupo) o a nivel de clave individual para un control más preciso. Esto respalda directamente la buena práctica de separar a los administradores de claves de los administradores de datos: una persona que gestiona las claves de cifrado no necesita, ni debería tener, acceso directo a los datos que protegen dichas claves.

1. Grant cloudkms.admin Únicamente a las identidades responsables de la gestión del ciclo de vida de las claves, nunca a las cuentas de servicio de aplicaciones.
2. Grant cloudkms.cryptoKeyEncrypterDecrypter Limitado estrictamente a la cuenta de servicio específica que necesita cifrar/descifrar con esa clave.
3. Mantenga los recursos de Cloud KMS en un proyecto separado de los datos que protegen, de modo que una vulneración del proyecto de datos no otorgue automáticamente acceso a las claves.
4. Revise las vinculaciones de IAM en los llaveros con la misma frecuencia que las revisiones de acceso a producción, ya que una concesión de KMS obsoleta equivale a un acceso de descifrado permanente.

¿Cómo se debe gestionar la rotación de claves en GCP?

Cloud KMS admite la rotación automática según un cronograma definido, pero la rotación solo crea una nueva versión de clave activa; no vuelve a cifrar los datos existentes ni elimina la versión anterior. Los datos cifrados con una versión de clave anterior siguen dependiendo de esa versión hasta que se ejecute un proceso explícito de recifrado. Google no publica un mínimo ni un máximo técnico fijo para el período de rotación, pero un intervalo de 90 días para las claves simétricas es una referencia común que se ajusta a las recomendaciones generales del sector (incluida la guía general de criptoperiodo del NIST).

La rotación de certificados en la infraestructura de clave pública (PKI) es un asunto distinto a la rotación de claves: los certificados TLS emitidos a través del Servicio de Autoridad de Certificación (CA) tienen su propio período de validez, independiente de las claves de Cloud KMS que respaldan la clave privada de la CA emisora. Es importante realizar un seguimiento independiente de estos dos ciclos de rotación, en lugar de asumir que un único calendario los abarca a ambos.

¿Qué información debería registrar en KMS, HSM y PKI?

• Registros de auditoría en la nube para cada operación de KMS: Quién realizó la llamada a encriptar/desencriptar/firmar, con qué clave y desde qué proyecto, se registra automáticamente sin configuración adicional.
• Eventos clave del ciclo de vida: Creación, rotación, destrucción programada y cambios en la vinculación de IAM en llaveros y claves.
• Eventos de emisión y revocación de certificados del Servicio de Autoridad de Certificación, vinculado a la CA que emitió cada certificado.
• Llamadas de ida y vuelta de Cloud EKM, si está en uso, ya que un fallo al intentar acceder al administrador de claves externo es en sí mismo un evento de disponibilidad relevante para la seguridad, no solo un error de la aplicación.

¿Cuánto cuestan las herramientas de cifrado de GCP?

Las claves respaldadas por software de Cloud KMS se facturan por versión de clave activa al mes, más cargos por operación; las claves de Cloud HSM tienen una tarifa por versión de clave considerablemente mayor para cubrir la capacidad de hardware dedicada; Cloud EKM añade el coste del propio gestor de claves externo a los cargos de Cloud KMS. El Servicio de Autoridad de Certificación se factura por separado, según el nivel de CA (DevOps o Enterprise) y los certificados emitidos, independientemente de los precios de KMS. Confirme las tarifas unitarias actuales en las páginas de precios de Google antes de presupuestar una migración, ya que Cloud KMS, Cloud HSM y el Servicio de Autoridad de Certificación se facturan según tres calendarios distintos.

¿Cómo es la arquitectura de cifrado multi-nube en GCP, AWS y Azure?

Cada nube principal implementa las mismas capas conceptuales (KMS administrado, nivel HSM respaldado por hardware, opción de administrador de claves externo y un servicio PKI/certificado) con nombres y posturas FIPS diferentes. El nivel Cloud HSM de GCP actualmente cumple con FIPS 140-2 Nivel 3, mientras que AWS KMS y Azure Managed HSM han migrado sus niveles HSM a FIPS 140-3 Nivel 3, una brecha que conviene señalar en cualquier revisión de cumplimiento que incluya GCP y que requiera específicamente la validación de hardware FIPS 140-3. Una arquitectura multi-nube consistente estandariza el control de acceso y la política de rotación en los tres productos KMS nativos en lugar de intentar ejecutar un solo KMS en varias nubes, ya que ninguno de los tres administra de forma nativa las claves de los demás.

Consulte nuestra comparativa de AWS KMS, Azure Key Vault y GCP KMS para obtener un análisis completo de las diferencias entre estos tres sistemas en cuanto a rotación, IAM y coste.

¿Cuáles son las limitaciones de las herramientas de cifrado nativas de GCP?

• La validación FIPS 140-2 Nivel 3 actual de Cloud HSM está un paso por detrás de los niveles de hardware FIPS 140-3 Nivel 3 de AWS y Azure, lo cual es importante para un mandato de cumplimiento que menciona específicamente la norma 140-3.
• La rotación no vuelve a cifrar los datos automáticamente; el recifrado y la limpieza de versiones antiguas son responsabilidad del cliente.
• Cloud EKM añade latencia y una dependencia externa a cada operación criptográfica, lo que supone una verdadera desventaja en términos de disponibilidad, no solo una ventaja en materia de seguridad.
• Los servicios KMS, HSM y de Autoridad de Certificación se facturan y administran por separado, por lo que para obtener una visión unificada del "gasto en cifrado" es necesario extraer datos de varias partidas de facturación de GCP.

Lista de verificación para la toma de decisiones: Elección de las herramientas de cifrado de GCP

1. Por defecto, utilice claves respaldadas por software de Cloud KMS; recurra a Cloud HSM solo para requisitos específicos de custodia de hardware.
2. Reserva Cloud EKM para los casos en que un regulador o un contrato exija que Google nunca conserve material clave utilizable.
3. Defina el alcance de los roles de IAM a nivel de llavero o clave, separando a los administradores de claves de los administradores de datos.
4. Defina un manual de procedimientos para la rotación y el recifrado, no solo un cronograma de rotación.
5. Antes de una migración a gran escala, presupueste por separado los costos de Cloud KMS, Cloud HSM y el Servicio de Autoridad de Certificación.

¿Qué recomendaría Encryption Consulting?

La mayoría de los clientes de GCP con los que trabajamos utilizan por defecto claves Cloud KMS con respaldo de software sin revisar si un requisito de cumplimiento exige realmente un HSM o custodia externa, y luego descubren la deficiencia durante una auditoría. Los servicios de Cloud Key Management de Encryption Consulting asignan sus obligaciones de cumplimiento reales al nivel de control de claves de GCP adecuado, diseñan el modelo de IAM y separación de funciones, y nuestra oferta de HSM como servicio le proporciona custodia con respaldo de hardware sin necesidad de operar HSM directamente.

Preguntas frecuentes

¿Cuál es la diferencia entre Cloud KMS y Cloud HSM?

Cloud KMS es la API y la capa de gestión para claves criptográficas en general; Cloud HSM es un nivel de protección específico dentro de Cloud KMS donde las claves se generan y utilizan únicamente dentro de hardware validado según FIPS 140-2 Nivel 3, en lugar del módulo criptográfico de software de Google.

¿GCP admite BYOK y HYOK?

Sí a ambas preguntas. BYOK es compatible mediante la importación de material de clave generado por el cliente a Cloud KMS. La custodia equivalente a HYOK es compatible a través de Cloud External Key Manager (Cloud EKM), que permite que un administrador de claves externo conserve el material de clave real mientras Cloud KMS lo referencia.

¿El HSM en la nube de GCP cuenta con la validación FIPS 140-3?

Aún no alcanza el nivel de protección de hardware; Cloud HSM cuenta actualmente con la validación FIPS 140-2 Nivel 3. El nivel de protección de software de GCP utiliza primitivas criptográficas validadas según FIPS 140-3 Nivel 1 (BoringCrypto), lo cual difiere de la validación 140-3 a nivel de hardware.

¿El cambio de una clave de Cloud KMS protege automáticamente los datos antiguos con la nueva clave?

No. La rotación solo crea una nueva versión de clave activa para operaciones futuras; los datos ya cifrados con la versión anterior siguen dependiendo de ella hasta que se ejecute un proceso de recifrado explícito.

¿Qué relación guarda la infraestructura de clave pública (PKI) de GCP con Cloud KMS?

El servicio de autoridad de certificación puede utilizar Cloud KMS o Cloud HSM para proteger la clave de firma privada de una CA, pero la emisión de certificados, los períodos de validez y la revocación se gestionan independientemente del programa de rotación de claves de Cloud KMS.

¿Necesita ayuda para asignar sus requisitos de cumplimiento al nivel de control de claves de GCP adecuado? Hable con el equipo de Cloud Key Management de Encryption Consulting.