Servicios de Microsoft Azure - Azure Key Vault

Azure Key Vault es el servicio en la nube de Microsoft para almacenar y controlar el acceso a claves criptográficas, secretos y certificados. Es importante porque cada credencial que necesita una aplicación (claves de cifrado, cadenas de conexión, certificados TLS) se convierte en un punto único de vulnerabilidad si se deja en el código o en archivos de configuración en lugar de en un almacén administrado. Acción recomendada: utilice Key Vault con Azure RBAC e identidades administradas de forma predeterminada, y reserve Managed HSM para cargas de trabajo con un requisito documentado de hardware dedicado.

Puntos Clave

Azure Key Vault gestiona tres tipos de recursos distintos (secretos, claves y certificados) bajo un único servicio con control de acceso, cada uno con sus propias operaciones y registro de auditoría.
Las claves de nivel estándar cuentan con la validación FIPS 140-2 Nivel 1 (protección por software); las claves de nivel premium ahora se ejecutan en la plataforma HSM 2, con validación FIPS 140-3 Nivel 3; el HSM administrado es un grupo dedicado de un solo inquilino, también con validación FIPS 140-3 Nivel 3.
Azure RBAC ha sustituido al modelo de directiva de acceso de almacén tradicional como sistema de permisos recomendado por Microsoft, y las identidades administradas son la forma recomendada para que las aplicaciones se autentiquen, reemplazando los secretos de entidad de servicio.
BYOK permite a una organización importar material de claves generado externamente a Key Vault o Managed HSM; Azure Dedicated HSM es la opción más parecida a HYOK, ya que el cliente administra ese hardware directamente en lugar de Microsoft.
La rotación de claves, el registro de diagnóstico y el coste varían significativamente según el nivel, y ninguno de los tres se configura automáticamente cuando se crea una bóveda por primera vez.

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

Para saber cómo Azure Key Vault se integra en un programa de cumplimiento más amplio, consulte ¿ Cómo puede lograr que las organizaciones cumplan mejor con Microsoft Azure? Para saber cómo se compara Key Vault con los servicios de administración de claves de AWS y GCP, consulte AWS KMS frente a Azure Key Vault frente a GCP KMS . Para obtener información general sobre las opciones de HSM en la nube, consulte Comparación entre HSM basado en la nube y HSM local , y para la identidad basada en certificados en diferentes nubes, consulte ¿Qué es la arquitectura PKI basada en la nube?

¿Qué es Azure Key Vault?

Azure Key Vault es un servicio en la nube que actúa como un almacén centralizado y con control de acceso para el material confidencial de una organización, organizado en tres tipos de recursos: secretos (cadenas de conexión, contraseñas, claves de API, de hasta 10 KB cada uno), claves (claves criptográficas utilizadas para el cifrado, la firma y el encapsulado de claves, que nunca salen del perímetro seguro del almacén en un formato utilizable) y certificados (certificados SSL/TLS X.509 que Key Vault puede aprovisionar, renovar e implementar en los servicios integrados de Azure). Por diseño, ni siquiera Microsoft puede extraer ni ver el material de clave del cliente; cada operación se realiza dentro del perímetro del almacén o del HSM y se registra para fines de auditoría.

¿Cómo funciona el control de claves nativas frente al control de claves externas en Azure Key Vault?

Azure Key Vault y sus servicios relacionados ofrecen varios niveles de custodia de claves, con un equilibrio entre coste, aislamiento y quién controla en última instancia el material de clave:

Nivel de control de claves	Nivel de protección	Mejor ajuste
Nivel estándar (nativo, software)	Módulo criptográfico de software FIPS 140-2 Nivel 1.	Valor predeterminado para la mayoría de secretos, claves y certificados.
Nivel Premium (nativo, con soporte HSM)	FIPS 140-3 Nivel 3 en la plataforma HSM actual, hardware 2, grupo compartido multiusuario.	Cargas de trabajo que requieren claves respaldadas por hardware sin el costo de un HSM dedicado.
HSM gestionado (nativo, dedicado)	FIPS 140-3 Nivel 3, grupo de HSM dedicado para un solo inquilino; cada clave está protegida por HSM, sin opción de clave de software.	Cargas de trabajo reguladas que requieren un control administrativo total sobre un HSM dedicado.
HSM dedicado de Azure (controlado por el cliente)	Dispositivo HSM físico administrado por el cliente; Microsoft no lo opera.	Una cláusula de cumplimiento que exige que el proveedor de la nube nunca administre el HSM por sí mismo.
BYOK (material clave importado)	Material clave generado fuera de Azure, a menudo en un HSM local, importado a Key Vault o a un HSM administrado.	Organizaciones que necesitan demostrar la procedencia de las claves o que ya generan claves en sus propias instalaciones.

Por defecto, utilice la opción Estándar o Premium, a menos que un requisito específico exija el grupo dedicado de Managed HSM o el hardware administrado por el cliente de Dedicated HSM; ambos cuestan considerablemente más y solo merecen la pena cuando un mandato específico exige ese nivel de aislamiento.

¿Cuáles son los conceptos básicos de Azure Key Vault que necesitas conocer?

Secreto: Un pequeño fragmento de datos (de hasta 10 KB), como una clave de autenticación, una contraseña, un token o un archivo .pfx, que recupera un usuario autorizado en lugar de estar integrado en el código de la aplicación.
Llave: Una clave criptográfica utilizada para operaciones de cifrado/descifrado, envoltura/desenvoltura o firma/verificación; a diferencia de los secretos, el material de la clave nunca sale del perímetro seguro de la bóveda.
Propietario de la bóveda de llaves: el administrador que crea la bóveda y autoriza a los usuarios y aplicaciones para operaciones específicas.
Director del servicio: La identidad que utiliza una aplicación para autenticarse en Azure Active Directory (Microsoft Entra ID) y, a su vez, en Key Vault.
Política de acceso frente a asignación de roles: El modelo de permisos tradicional, con ámbito de bóveda, frente al modelo de permisos basado en roles de Azure RBAC, que se describe a continuación.

¿Cómo debería estructurarse la gestión de identidades y accesos (IAM) para Azure Key Vault?

Azure RBAC es el modelo de permisos recomendado por Microsoft para Key Vault, que reemplaza el antiguo sistema de directivas de acceso a nivel de bóveda con las mismas asignaciones de roles granulares y auditables que se utilizan en el resto de Azure.

Migre los almacenes que aún utilizan el modelo de directiva de acceso heredado a Azure RBAC, ya que RBAC se integra con el acceso condicional y genera un registro de auditoría coherente en todos los servicios.
Separar el Oficial de Criptografía de Key Vault rol (ciclo de vida clave: crear, rotar, eliminar) de Usuario de criptografía de Key Vault (cifrar/descifrar/firmar únicamente), otorgando cada uno a identidades diferentes.
Otorgar acceso a secretos y certificados a través del equivalente Usuario de secretos de Key Vault y Oficial de Certificados de la Bóveda de Llaves funciones específicas en lugar de una única concesión general de administrador de Key Vault.
Defina el alcance de las asignaciones de roles a nivel de bóveda, o a nivel de clave/secreto/certificado individual para un control más preciso, en lugar de a nivel de suscripción.
Revise las asignaciones de roles con la misma frecuencia que otras revisiones de acceso a producción, ya que una concesión de usuario de criptografía obsoleta equivale a un acceso de descifrado permanente.

¿Cómo se autentica una aplicación en Azure Key Vault?

La recomendación actual de Microsoft es autenticar las aplicaciones con una identidad administrada en lugar de un secreto de cliente de entidad de servicio, ya que una identidad administrada elimina la necesidad de almacenar cualquier credencial:

Habilite una identidad administrada asignada por el sistema o por el usuario en el recurso de Azure de la aplicación (Servicio de aplicaciones, máquina virtual, función o similar).
Asigne a esa identidad administrada el rol RBAC apropiado (Usuario de Criptografía, Usuario de Secretos o Responsable de Certificados) en la bóveda de destino.
La aplicación solicita un token a Azure Active Directory utilizando su identidad administrada, sin que intervenga ningún secreto de cliente.
La aplicación presenta ese token a Key Vault, que lo valida y devuelve el secreto solicitado, el resultado de la operación de clave o el certificado.
Para las aplicaciones que no pueden usar una identidad administrada (aplicaciones en múltiples nubes o en las instalaciones), recurra a una entidad de servicio con una credencial de certificado en lugar de un secreto de cliente, y rote esa credencial según un calendario definido.

¿Cómo se debe gestionar la rotación de claves en Azure Key Vault?

Key Vault admite políticas de rotación automática integradas, lo que permite a una organización definir un período de rotación y una ventana de notificación opcional antes de la expiración. Al igual que con cualquier servicio de administración de claves en la nube, la rotación solo crea una nueva versión de la clave para operaciones futuras; no vuelve a cifrar los datos ya protegidos por una versión anterior ni elimina automáticamente dicha versión. Un plan de rotación completo requiere un paso de recifrado independiente y un cronograma explícito para la retirada de las versiones antiguas de la clave una vez que ya no dependan de ellas. Los certificados siguen su propio calendario de renovación, independiente de la rotación de claves, y Key Vault puede solicitar automáticamente la renovación a una autoridad de certificación integrada antes de su expiración.

¿Qué información debería registrar para Azure Key Vault?

Registros de diagnóstico de Key Vault, Se envía a Azure Monitor o Log Analytics, y abarca todas las operaciones con secretos, claves y certificados, la identidad del emisor y la versión específica del objeto utilizado.
Cambios en la asignación de roles en la bóveda, ya que una nueva concesión de RBAC es en sí misma un evento relevante para la seguridad.
Eventos de renovación y vencimiento de certificados, De esta forma, se detecta un fallo en la renovación automática antes de que el certificado caduque realmente.
Cambios en el firewall y las reglas de red en la bóveda, ya que Key Vault también admite la restricción del acceso a redes virtuales específicas o puntos finales privados.

¿Cuánto cuesta Azure Key Vault?

El nivel estándar se factura por operación en secretos, claves y certificados a una tarifa baja por cada 10 000 operaciones. El nivel premium añade un cargo por operación de clave protegida por HSM, además de la misma tarifa base, para cubrir el grupo de HSM compartido. El HSM administrado factura una tarifa horaria fija por grupo de HSM, más cargos por versión de clave y por operación, considerablemente superiores a los de los niveles estándar o premium, para cubrir el hardware dedicado de un solo inquilino. El HSM dedicado de Azure factura por hora por dispositivo físico, independientemente del uso. Confirme las tarifas unitarias actuales en las páginas de precios de Microsoft antes de presupuestar una migración a HSM administrado o dedicado, ya que la diferencia de costes entre los niveles es sustancial.

¿Cómo es la gestión de claves en múltiples nubes en Azure, AWS y GCP?

Cada nube principal implementa los mismos niveles conceptuales: un nivel predeterminado de bajo costo protegido por software, un nivel compartido respaldado por HSM y una opción HSM dedicada para un solo inquilino, aunque con nombres diferentes y distintos historiales de validación FIPS. Una arquitectura multinube coherente estandariza el control de acceso y la política de rotación en el almacén de claves nativo de cada nube, en lugar de intentar ejecutar un único servicio de gestión de claves en las tres, ya que ninguna de ellas gestiona de forma nativa las claves de las 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 costes específicos.

¿Cuáles son las limitaciones de Azure Key Vault?

Las claves protegidas por software del nivel estándar solo cuentan con la validación FIPS 140-2 Nivel 1, lo que no cumple con el requisito de custodia de claves respaldada por hardware.
La migración de bóvedas del modelo de política de acceso anterior al control de acceso basado en roles (RBAC) requiere una planificación cuidadosa, ya que los dos modelos no se corresponden uno a uno y una migración apresurada puede otorgar permisos excesivos o bloquear el acceso legítimo.
Tanto el HSM gestionado como el HSM dedicado conllevan un coste sustancialmente superior al de los planes Estándar o Premium, que debe justificarse en función de un requisito de cumplimiento real.
La rotación no vuelve a cifrar automáticamente los datos existentes; el recifrado y la limpieza de versiones antiguas son responsabilidad del cliente.

Lista de verificación para la toma de decisiones: Elegir el nivel adecuado de Azure Key Vault

Utilice el nivel Estándar por defecto para secretos y claves protegidas por software; cambie a Premium solo cuando una carga de trabajo necesite claves respaldadas por HSM.
Reserve un HSM administrado o un HSM dedicado para un requisito específico de hardware dedicado para un solo inquilino.
Migre cualquier almacén que aún utilice el modelo de directiva de acceso heredado a Azure RBAC, separando la administración de claves del uso de claves.
Autentique las aplicaciones con identidades gestionadas, recurriendo a entidades de servicio basadas en certificados solo cuando sea necesario.
Habilite la rotación automática y documente el proceso de recifrado independiente para los datos existentes.

¿Qué recomendaría Encryption Consulting?

La mayoría de los entornos de Azure que analizamos aún utilizan aplicaciones que se autentican con un secreto de entidad de servicio de larga duración en lugar de una identidad administrada, y los almacenes siguen ejecutando el modelo de directiva de acceso heredado años después de que RBAC se convirtiera en el enfoque recomendado. Los servicios de administración de claves en la nube de Encryption Consulting diseñan la estructura de roles RBAC y la migración de identidad administrada para su entorno de Key Vault; nuestra oferta de HSM como servicio le proporciona custodia de claves respaldada por hardware sin operar HSM directamente; y nuestra PKI como servicio extiende esto a la administración completa del ciclo de vida de los certificados.

Preguntas frecuentes

¿Cuál es la diferencia entre Azure Key Vault Standard y Premium?

El nivel estándar protege las claves mediante software y cuenta con la validación FIPS 140-2 Nivel 1; el nivel premium protege las claves dentro de un grupo compartido de módulos de seguridad de hardware (HSM), y ahora cuenta con la validación FIPS 140-3 Nivel 3 en la plataforma HSM actual de Microsoft.

¿Es Managed HSM lo mismo que Key Vault Premium?

No. Premium es un grupo HSM compartido y multiusuario dentro de un Key Vault estándar; Managed HSM es un grupo HSM dedicado de un solo usuario con su propio modelo administrativo, y cada clave en él está protegida por HSM sin opción de clave de software.

¿Debería seguir utilizando directivas de acceso a la bóveda en lugar de Azure RBAC?

No. Azure RBAC es el modelo de permisos recomendado actualmente por Microsoft para Key Vault; las políticas de acceso son el enfoque anterior y los almacenes existentes deben migrarse.

¿Puede Azure Key Vault funcionar con un gestor de claves externo como Thales?

Key Vault admite la importación de material de claves generado externamente mediante BYOK. Para un escenario en el que el proveedor de la nube no deba almacenar material de claves utilizable, Azure Dedicated HSM, administrado directamente por el cliente, es la opción más cercana a un modelo HYOK.

¿La rotación de claves en Key Vault vuelve a cifrar los datos existentes?

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.

¿Necesita ayuda para estructurar los roles RBAC de Azure Key Vault y migrar desde las políticas de acceso heredadas? Hable con el equipo de Cloud Key Management de Encryption Consulting.