AWS KMS frente a Azure Key Vault frente a GCP KMS

AWS KMS, Azure Key Vault y GCP Cloud KMS son los tres principales servicios gestionados de los proveedores de nube para generar, almacenar y usar claves de cifrado. La elección es crucial, ya que cada uno implementa un modelo de seguridad y acceso diferente internamente, y cambiar posteriormente implica rediseñar la estrategia de cifrado. La acción recomendada: seleccione el servicio que mejor se adapte a su nube principal para cargas de trabajo nativas y defina explícitamente su modelo de control de claves (nativo, BYOK o HYOK) antes de escalar a más de unas pocas claves.

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

Si solo utilizas AWS y Azure, sin planes de añadir GCP, nuestra comparación más específica entre AWS y Azure KMS profundiza en esa decisión concreta sobre la elección entre dos nubes. Este artículo abarca los tres proveedores para equipos que evalúan todas las opciones disponibles.

¿Qué son AWS KMS, Azure Key Vault y GCP Cloud KMS?

AWS Key Management Service (KMS), Azure Key Vault y Google Cloud Key Management Service (Cloud KMS) son servicios gestionados por cada proveedor de nube para crear, almacenar y usar claves criptográficas sin necesidad de operar módulos de seguridad de hardware (HSM) propios. Los tres siguen el mismo patrón conceptual: una clave de cifrado de claves (KEK) custodiada por el servicio protege las claves de cifrado de datos (DEK), que a su vez protegen sus datos reales, y la KEK nunca se le devuelve sin cifrar. Las diferencias radican en la terminología de gestión de claves , la integración con IAM, la configuración predeterminada de rotación y el grado de control que puede ejercer sobre el material de clave fuera del proveedor.

AWS cambió el nombre de su terminología original "Customer Master Key (CMK)" a clave KMS hace años; la documentación actual de AWS distingue entre claves administradas por el cliente , claves administradas por AWS y claves propiedad de AWS . Azure Key Vault emite claves de un nivel Estándar (protegido por software, multiusuario) o Premium (grupo HSM compartido), además de un producto HSM administrado independiente para hardware dedicado de un solo usuario. GCP Cloud KMS valora las claves SOFTWARE , HSM y EXTERNAS como tres niveles de protección distintos dentro de un mismo servicio.

¿Cómo se comparan los modelos de almacenamiento de claves nativas?

Cada proveedor establece por defecto un nivel de validación de hardware y un tipo de llave compatible diferente, lo que determina lo que puedes hacer sin necesidad de pasar a un plan premium.

Elemento	AWS KMS	Azure Key Vault	GCP Cloud KMS
Protección de clave predeterminada	Módulo de seguridad de hardware (HSM) validado según FIPS 140-2 (todas las claves)	Software (Estándar) o grupo HSM compartido (Premium)	Software, HSM o externo, elegido por clave
Opción HSM dedicada para un solo inquilino	Mediante la integración de CloudHSM	HSM gestionado (FIPS 140-3 Nivel 3, Marvell LiquidSecurity)	HSM en la nube para un solo inquilino
Tipos de teclas compatibles	Simétrico, asimétrico (RSA, ECC), HMAC	RSA y curva elíptica (asimétrica); no hay un tipo de clave simétrica nativa.	Simétrico (AES-256) y asimétrico (RSA, ECC)
Portabilidad clave	Nunca abandona la región de AWS en la que fue creada.	Nunca abandona los límites de la bóveda; Microsoft afirma que no puede ver el material clave.	Nunca se separa de la ubicación del llavero.

¿Deberías usar claves nativas, BYOK o HYOK en estas nubes?

Utilice las claves nativas de cada proveedor por defecto, pase a BYOK cuando necesite demostrar el origen de una clave y reserve HYOK para las claves específicas que, según un organismo regulador o un contrato, nunca deben acceder a la infraestructura del proveedor de la nube. Las tres nubes admiten los tres modelos, pero la mecánica de HYOK difiere lo suficiente como para modificar su arquitectura.

Modelo	AWS KMS	Azure Key Vault	GCP Cloud KMS
Nativo	Clave generada por KMS, no exportable.	Clave generada por Vault o Managed HSM	Clave generada por Cloud KMS
BUENO	Importe el material clave envuelto en RSA; AWS conserva una copia utilizable.	Importar material de clave protegido por HSM a Managed HSM desde un HSM local.	Importar material de clave (AES-256 encapsulado en RSA de 3072 bits)
HYOK	Almacén de claves externo (XKS): doble cifrado, la clave nunca sale de su gestor de claves externo.	Gestión de claves externas (versión preliminar): el encapsulado/desencapsulado se delega a un proxy EKM gestionado por el cliente; no está cubierto por el SLA de HSM gestionado.	Administrador de claves externas en la nube (EKM): cifrado de doble capa mediante Fortanix, Futurex o Thales; la solicitud falla si la clave externa no está disponible.

Todas las implementaciones de HYOK comparten la misma disyuntiva: se obtiene un control verificable sobre la clave, pero se asume el riesgo operativo del tiempo de actividad del gestor de claves externo. Google es explícito sobre la desventaja: en el caso específico de Cloud Spanner, una clave EKM inaccesible durante más de 30 días provoca la pérdida permanente de datos, ya que Google afirma que no puede recuperar los datos protegidos por una clave que nunca tuvo en su poder. Consulte nuestra explicación sobre sistemas de gestión de claves híbridos (HMS ) para obtener más información sobre la disyuntiva entre BYOK e HYOK, y la sección sobre HSM dedicados frente a compartidos para comprender cómo las decisiones de aislamiento de custodia de claves influyen en la adquisición de HSM.

¿En qué se diferencia el modelo IAM entre AWS, Azure y GCP?

Los tres utilizan el sistema de identidad de propósito general de su plataforma para el acceso a las claves, combinado con un modelo de permisos o políticas específico del KMS; ninguno de ellos inventó un sistema de identidad separado solo para las claves.

• AWS KMS combina políticas basadas en identidad de IAM con una política de clave obligatoria adjunta a cada clave KMS, además de concesiones temporales para acceso entre cuentas o servicios. La configuración de privilegios mínimos significa denegar kms:CreateGrant excepto cuando una condición de contexto de cifrado coincida con un ARN de clave aprobado.
• Azure Key Vault Admite tanto las directivas de acceso a la bóveda heredadas como el control de acceso basado en roles (RBAC) de Azure; Managed HSM utiliza un sistema RBAC local e independiente que los administradores de la suscripción de Azure no pueden anular, que es precisamente la idea: está diseñado para que ni siquiera el personal de soporte de Microsoft pueda otorgarse a sí mismo acceso a las claves.
• GCP Cloud KMS está regido completamente por roles de Cloud IAM, como roles/cloudkms.cryptoKeyEncrypterDecrypter para acceso de uso exclusivo y roles/cloudkms.admin En cuanto a la gestión, Google recomienda explícitamente la separación de funciones entre ambos.

Una configuración de privilegios mínimos que funcione en los tres sistemas sigue los mismos cinco pasos, independientemente del proveedor:

1. Separe las claves de producción y las que no lo son en cuentas, suscripciones o proyectos diferentes, de modo que una identidad de prueba comprometida nunca pueda acceder a una clave de producción.
2. Conceda permisos de cifrado/descifrado (uso) y permisos de administración de claves a diferentes roles, nunca al mismo rol.
3. Limita cada concesión a un recurso clave específico, nunca a un comodín, utilizando ARN de recursos (AWS), asignaciones RBAC con ámbito (Azure) o condiciones de IAM (GCP).
4. Se requiere autenticación multifactor (MFA) o un flujo de trabajo de acceso privilegiado para cualquier acción que pueda eliminar o programar la eliminación de una clave o bóveda.
5. Revise el acceso trimestralmente utilizando las herramientas nativas de cada proveedor: IAM Access Analyzer (AWS), revisiones de acceso de Azure AD (Azure) o IAM Recommender (GCP).

¿Cómo funciona la rotación de llaves en cada servicio?

La rotación es automática en los tres servicios para claves simétricas, pero el rango configurable y los límites estrictos difieren lo suficiente como para afectar a la documentación de cumplimiento.

• AWS KMSLa rotación automática de claves simétricas se puede configurar entre 90 y 2,560 días (aproximadamente siete años). Las claves asimétricas y HMAC no son compatibles y deben rotarse creando una nueva clave. El material de clave importado admite la rotación bajo demanda, hasta diez veces durante la vida útil de la clave. Las dos primeras rotaciones de una clave añaden 1 $/mes cada una a su coste; a partir de entonces, el precio se limita.
• HSM administrado de Azure Key VaultLas directivas de autorrotación se basan en la creación o la expiración, con un intervalo mínimo de 28 días; Microsoft recomienda rotar al menos cada dos años según NIST SP 800-57. Cada clave tiene un límite de 100 versiones, y las rotaciones se contabilizan para ese límite. Key Vault estándar y Premium (sin HSM administrado) no ofrecen autorrotación integrada de la misma manera y, por lo general, dependen de la rotación activada por Azure Automation o Event Grid.
• GCP Cloud KMSLa rotación automática de claves simétricas se puede configurar desde 1 día hasta 100 años; las claves de firma y cifrado asimétricas no son compatibles con la rotación automática. La rotación de una clave no desactiva ni vuelve a cifrar los datos protegidos por versiones anteriores; estas versiones deben desactivarse o destruirse manualmente una vez retiradas.

¿Qué información debería registrar y monitorizar en cada nube?

Habilite el registro de eventos antes de crear su primera clave en cualquiera de los tres servicios, no después de que un incidente obligue a plantearse la cuestión.

• AWSCloudTrail registra todas las llamadas de administración de KMS (crear, rotar, deshabilitar, editar políticas) y todas las llamadas criptográficas (cifrar, descifrar, generar clave de datos), incluyendo la identidad de la llamada y la IP de origen.
• Azure: Key Vault emite un AuditEvent Categoría de registro de diagnóstico a través de la configuración de diagnóstico de Azure Monitor, enrutable a Log Analytics, un Event Hub o almacenamiento para retención a largo plazo.
• GCP: Los registros de auditoría de la nube registran tanto la actividad del administrador (operaciones de administración, siempre activas, no se pueden desactivar) como los registros de acceso a datos (uso de claves, deben habilitarse explícitamente) para cada clave de Cloud KMS.

Independientemente de la nube que utilice como estándar, introduzca estos registros en un SIEM y configure alertas específicas para la eliminación de claves, los cambios de política y los eventos de exportación o desempaquetado/desempaquetado relacionados con las claves HYOK; estas son las acciones que convierten una operación rutinaria con claves en un incidente.

¿Cómo se comparan los costos de AWS KMS, Azure Key Vault y GCP Cloud KMS?

Ninguno de los tres modelos de precios coincide exactamente con los demás: AWS cobra por clave, GCP cobra por versión de clave por nivel de protección y Azure cobra por operación más un recargo adicional por clave HSM.

Proveedor	Coste de la llave base	Operaciones	HYOK / opción externa
AWS KMS	$1.00/llave/mes, tarifa fija independientemente del tipo de llave.	0.03 $/10,000 solicitudes (20,000 gratuitas al mes)	Almacén de claves externo: el mismo precio de 1 $/mes, más el coste de su propia infraestructura de gestión de claves.
Azure Key Vault	Claves de software: sin cargo adicional por almacenamiento; claves protegidas por HSM: aproximadamente entre 1 y 5 dólares por clave al mes, con precios que varían según el volumen.	Aproximadamente 0.03 $/10 000 operaciones (software), aproximadamente 0.15 $/10 000 para operaciones de clave avanzadas.	Gestión de claves externas: vista previa, aún no se ha publicado el precio por separado.
GCP Cloud KMS	$0.06/clave-versión/mes (software), $1.00/clave-versión/mes (HSM)	$0.03/10,000 operaciones ($0.15/10,000 para ciertas operaciones HSM)	EXTERNAL/EXTERNAL_VPC (EKM): $3.00/clave-versión/mes

Las cifras exactas de Azure varían según la región y, al momento de redactar este texto, no se publican como tarifas globales fijas en la página de precios de Microsoft. Considere las cifras anteriores como orientativas y confirme los precios regionales vigentes antes de elaborar su presupuesto. Un HSM en la nube para un solo inquilino en GCP tiene un costo fijo aproximado de $3,500 al mes e incluye 15 000 versiones de claves sin costo adicional, lo que puede resultar más económico que el precio por versión de un HSM a gran escala.

¿Cómo es una arquitectura de gestión de claves multi-nube?

Si utilizas las tres nubes, o prevés hacerlo, el diseño más seguro trata el KMS de cada proveedor como un punto de control regional bajo una capa centralizada de gobernanza de claves y certificados, en lugar de tres fuentes de información independientes que se desvinculan con el tiempo. Esta capa realiza un seguimiento de qué claves existen y dónde, qué nivel de protección y política de rotación utiliza cada una, y a qué equipo pertenece; una función que ni AWS KMS, ni Azure Key Vault, ni GCP Cloud KMS realizan automáticamente entre los distintos proveedores.

Para consultar la arquitectura de referencia completa, vea nuestra Guía de arquitectura PKIaaS multi-nube para AWS, Azure y GCP . Para comprender la importancia de este tema incluso antes de implementar tres nubes, nuestro Centro de formación abarca la gestión de claves multi-nube y las características que comparten las soluciones comerciales de gestión de claves.

¿Cuáles son las limitaciones de cada servicio?

• AWS KMSUna clave nunca abandona la región en la que se creó, por lo que una estrategia multirregión requiere claves multirregión explícitas, no una predeterminada; KMS no puede usar una clave de datos para cifrar o descifrar en su nombre, por lo que las aplicaciones deben encargarse de ello por sí mismas.
• Azure Key VaultLa gestión de claves externas aún está en fase de vista previa, no está cubierta por el SLA de Managed HSM y solo admite el cifrado/descifrado; Managed HSM limita cada clave a 100 versiones, y la rotación frecuente cuenta para ese límite.
• GCP Cloud KMSActualmente, Cloud EKM solo admite tres socios externos de gestión de claves (Fortanix, Futurex y Thales); al rotar una clave, los datos en versiones anteriores nunca se vuelven a cifrar automáticamente, por lo que las versiones obsoletas deben limpiarse manualmente para controlar los costos y los riesgos.

Lista de verificación para la toma de decisiones: Cómo elegir entre AWS KMS, Azure Key Vault y GCP Cloud KMS.

1. Empiece por donde ya se encuentran sus cargas de trabajo. La integración nativa con sus servicios de computación, almacenamiento y bases de datos compensa las diferencias marginales en las características entre las tres ofertas de KMS.
2. Decida su modelo de control de claves según la clasificación de datos., no una sola vez para toda la organización: nativo para la mayoría de las cargas de trabajo, BYOK donde se debe documentar la procedencia clave, HYOK solo cuando un regulador o contrato lo exige.
3. Adapta tu política de rotación a las limitaciones reales de cada proveedor. — En particular, el período mínimo de 28 días y el límite de 100 versiones de Azure Managed HSM deben tenerse en cuenta desde el principio, no deben descubrirse durante una auditoría.
4. Coste del modelo en función de su clave real y volumen de operacionesNo se trata de la cifra principal por clave o por operación, sino que tanto el precio por nivel de protección de GCP como las tarifas escalonadas por clave HSM de Azure cambian significativamente a gran escala.
5. Si actualmente gestiona más de una nube, o prevé hacerlo en los próximos 18 meses.Evalúe una capa centralizada de administración de claves y certificados antes de tener que conciliar tres configuraciones KMS independientes y cambiantes.

¿Qué recomendaría Encryption Consulting?

Para una empresa que opera en una sola nube, utilice el KMS nativo de esa nube y no se complique demasiado: los tres son servicios maduros y validados por FIPS. La decisión se vuelve realmente difícil en el momento en que opera en dos o más nubes, porque ninguno de los KMS de AWS, Azure Key Vault o GCP Cloud KMS fue diseñado para brindarle una visión unificada de los demás. En nuestros proyectos, las organizaciones que tienen dificultades son aquellas que adoptaron el KMS de cada nube de forma independiente y luego intentaron agregar la gobernanza posteriormente. Recomendamos definir su modelo de custodia de claves (nativo, BYOK o HYOK) y sus estándares de rotación y registro una sola vez, de forma centralizada, a través de HSM-as-a-Service para una custodia validada por FIPS que abarque proveedores, antes de que los equipos individuales estandaricen el modelo predeterminado de su consola en la nube. Si necesita una evaluación externa del estado actual de su postura de claves en múltiples nubes, nuestra evaluación de Cloud Data Protection compara los entornos de AWS, Azure y GCP con los controles NIST y CIS.

Preguntas frecuentes

¿Qué es más seguro: AWS KMS, Azure Key Vault o GCP Cloud KMS?

Los tres son servicios gestionados con validación FIPS de proveedores con un historial de seguridad sólido, y ninguno es categóricamente menos seguro que los demás para el uso predeterminado con clave nativa. Las diferencias de seguridad significativas se manifiestan en los detalles: el nivel de validación de hardware por capa, si HYOK está disponible de forma general o aún en versión preliminar, y el grado de configuración de IAM y el registro, no en qué logotipo del proveedor aparece en el servicio.

¿Puedo usar la misma clave de cifrado en AWS, Azure y GCP?

No directamente. Por diseño, la clave nativa de cada proveedor nunca sale de su entorno. La forma más parecida a una clave compartida entre nubes es mediante HYOK: alojar el material de clave en un administrador de claves externo propio y que cada nube acceda a él (AWS External Key Store, Azure External Key Management o GCP Cloud EKM). Esto permite que una única fuente de material de clave sirva a varias nubes, pero a costa de convertir el administrador de claves externo en un punto único de fallo para todas ellas.

¿Azure Key Vault Managed HSM es lo mismo que HYOK?

No. Managed HSM es una opción de hardware dedicada para un solo inquilino que se ejecuta dentro de la infraestructura de Microsoft; es una opción de clave nativa más robusta, no externa. El equivalente real de HYOK en Azure es External Key Management, una función de vista previa independiente que delega las operaciones de cifrado y descifrado a un administrador de claves que se ejecuta fuera de Azure.

¿Por qué GCP cobra más por las claves externas (EKM) que por las claves HSM?

Google fija el precio de las versiones de clave EXTERNAL y EXTERNAL_VPC en 3.00 $/mes, tres veces la tarifa de 1.00 $/mes de HSM, porque cada operación criptográfica sobre una clave EKM requiere una comunicación de red directa con el gestor de claves externo en lugar de una llamada local al HSM. Esta latencia y dependencia adicionales son también la razón por la que Google advierte explícitamente que perder el acceso a una clave externa puede provocar una pérdida de datos permanente e irrecuperable.

¿Necesito una estrategia de gestión de claves multi-nube si actualmente solo utilizo una nube?

No de inmediato, pero conviene definir el modelo de control de claves, la política de rotación y el estándar de registro como si se fuera a añadir una segunda nube, ya que adaptar esas decisiones posteriormente resulta mucho más problemático que establecerlas de forma coherente desde el principio. Si una segunda nube ya está en su plan de desarrollo, comience a implementar esa capa de gobernanza ahora, en lugar de después de la migración.

Póngase en contacto con [email protected] si necesita ayuda para auditar o diseñar la gestión de claves en AWS, Azure y GCP.