Configuración de Bring Your Own Key (BYOK)

Completado

Escenario

Un cliente de Key Vault desea transferir de forma segura una clave desde su módulo de seguridad de hardware (HSM) local fuera de Azure, en el HSM que respalda Azure Key Vault. El proceso de importación de una clave generada fuera de Key Vault se conoce como Bring Your Own Key (BYOK).

Por qué BYOK es importante para la seguridad: muchas organizaciones requieren control sobre sus claves de cifrado para el cumplimiento, los requisitos normativos o las directivas de seguridad. BYOK le permite mantener el control sobre todo el ciclo de vida de las claves, desde la generación hasta la destrucción, mientras usa la infraestructura en la nube de Azure. Además, BYOK se alinea con los principios de confianza cero al mantener la separación criptográfica entre el material clave y los proveedores de nube hasta que autorice explícitamente la transferencia.

A continuación se muestran los requisitos:

  • La clave que se va a transferir nunca existe fuera de un HSM en texto claro - garantizando que incluso durante el proceso de transferencia, el material de la clave permanece protegido.
  • Fuera de un HSM, la clave que se va a transferir siempre está protegida por una clave que se mantiene en el HSM de Azure Key Vault , lo que proporciona garantía criptográfica que solo Azure Key Vault puede desencapsular la clave importada.

Terminología

Nombre de clave Tipo de clave Origen Descripción
Clave de intercambio de claves (KEK) RSA HSM de Azure Key Vault Un par de claves RSA respaldadas por HSM generado en Azure Key Vault.
Clave de ajuste AES HSM del proveedor Una clave AES efímera generada por HSM local
Clave de destino RSA, EC, AES (solo HSM administrado) HSM del proveedor Clave que se va a transferir al HSM de Azure Key Vault

Clave de intercambio de claves (KEK): una clave con respaldo HSM generada por el cliente dentro del almacén de claves destinada a la importación de la clave BYOK (Bring Your Own Key). La KEK debe tener las siguientes propiedades:

  • Debe ser una clave RSA-HSM, con un tamaño de clave de 4096 bits (recomendado), 3072 bits o 2048 bits.
  • Sus operaciones clave (key_ops) se limitan a "importar", lo que permite su uso exclusivamente durante el proceso BYOK. Esta restricción minimiza la superficie expuesta a ataques.
  • Debe residir en el mismo almacén donde se va a importar la Clave Objetivo; garantizando así el aislamiento adecuado del almacén de claves.

Pasos del usuario

Para realizar una transferencia de claves:

  1. Generación de KEK : cree una clave de intercambio de claves en Azure Key Vault.
  2. Recuperar la clave pública de KEK : descargue la parte pública para su uso con las herramientas del proveedor de HSM.
  3. Con la herramienta BYOK proporcionada por el proveedor de HSM, importe la KEK en el HSM de destino y exporte la clave de destino protegida por la KEK.
  4. Importación de la clave de destino protegida en Azure Key Vault : complete la transferencia mediante la CLI de Azure o PowerShell.

Los clientes usan la herramienta BYOK y la documentación proporcionadas por el proveedor de HSM para completar el paso 3. Este proceso genera un blob de transferencia de claves (un archivo ".byok") que encapsula de forma segura el material de clave cifrada.

Restricciones de HSM

El HSM existente puede aplicar restricciones en las claves que administran, entre las que se incluyen:

  • El HSM debe configurarse para permitir la exportación basada en encapsulado de claves.
  • La clave de destino está marcada como CKA_EXTRACTABLE (atributo Cryptoki) para el HSM para permitir la exportación controlada.
  • En algunos casos, la KEK y la clave de encapsulado se marcan como CKA_TRUSTED, lo que permite usarlas para encapsular las claves en el HSM.

La configuración del HSM de origen es, por lo general, fuera del ámbito de esta especificación. Microsoft espera que el proveedor de HSM genere documentación que acompaña a su herramienta BYOK para incluir estos pasos de configuración.

Nota

Estos pasos se pueden realizar mediante varias interfaces, como la CLI de Azure (que se muestra en ejemplos), Azure PowerShell y Azure Portal. También se pueden realizar mediante programación mediante el SDK de Azure Key Vault para escenarios de implementación automatizada.

Generar la KEK

Use el comando az keyvault key create para crear KEK con las operaciones de clave establecidas para importar. Tenga en cuenta el identificador de clave ("kid") devuelto desde este comando, ya que lo necesita para las operaciones posteriores.

az keyvault key create --kty RSA-HSM --size 4096 --name KEKforBYOK --ops import --vault-name ContosoKeyVaultHSM

Importante

Los diferentes servicios de Azure admiten diferentes longitudes de KEK. Por ejemplo, Azure SQL solo admite longitudes de clave de 2048 bits o 3072 bits. Compruebe siempre los requisitos de tamaño de clave para su servicio específico antes de generar la KEK.

Recuperar la clave pública de la KEK

Descargue la parte de clave pública de la KEK y almacénela como un archivo PEM (Privacy-Enhanced Mail). Este archivo se usa con la herramienta BYOK del proveedor de HSM.

az keyvault key download --name KEKforBYOK --vault-name ContosoKeyVaultHSM --file KEKforBYOK.publickey.pem




Generación de blobs de transferencia de claves mediante la herramienta BYOK proporcionada por el proveedor de HSM

Use la herramienta BYOK proporcionada por el proveedor de HSM para crear un blob de transferencia de claves (almacenado como un archivo ".byok"). La clave pública KEK, en el formato Privacy-Enhanced Mail (.pem), es una de las entradas de esta herramienta. Consulte la documentación específica del proveedor de HSM para obtener instrucciones detalladas sobre cómo usar su herramienta BYOK.

Blob de transferencia de claves

A largo plazo, Microsoft quiere usar el mecanismo PKCS#11 CKM_RSA_AES_KEY_WRAP para transferir la clave de destino a Azure Key Vault. El mecanismo PKCS#11 genera un único blob y, lo que es más importante, la clave AES intermedia se controla mediante los dos HSM y se garantiza que es efímera.

El texto no cifrado de la clave de destino depende del tipo de clave:

  • Para una clave RSA, la codificación ASN.1 DER de la clave privada [RFC3447] encapsulada en PKCS#8 [RFC5208]
  • Para una clave EC, la codificación ASN.1 DER de la clave privada [RFC5915] encapsulada en PKCS#8 [RFC5208]
  • Para una clave de octeto, los bytes sin formato de la clave

Los bytes de la clave de texto no cifrado se transforman mediante el mecanismo CKM_RSA_AES_KEY_WRAP:

  • Se genera una clave AES efímera y se cifra con la clave RSA de envoltura mediante RSA-OAEP con SHA1.
  • La clave de texto no cifrado codificada se cifra con la clave AES mediante el encapsulado de claves AES con relleno.
  • La clave AES cifrada y la clave de texto no cifrado se concatenan para generar el blob de texto cifrado final.

El formato del blob de transferencia usa la serialización compacta de JSON Web Encryption (RFC7516) principalmente como un vehículo para entregar los metadatos necesarios al servicio para el descifrado correcto.

Procedimientos recomendados para implementar BYOK

Al implementar Bring Your Own Key para Azure Key Vault, tenga en cuenta estas recomendaciones operativas y de seguridad:

  • Use el tamaño de clave más grande admitido : genere KEK con tamaños de clave de 4096 bits siempre que sea posible, ya que proporcionan la protección criptográfica más segura. Use solo tamaños de clave más pequeños cuando sea necesario por restricciones de servicio específicas.

  • Limitar las operaciones de clave KEK: restrinja siempre las operaciones KEK solo a "importar". Minimiza la superficie expuesta a ataques y garantiza que la KEK no se puede usar incorrectamente para otras operaciones criptográficas.

  • Mantenimiento de las certificaciones de seguridad de HSM : asegúrese de que el HSM local cumple los estándares de certificación de nivel 2 de FIPS 140-2 o superior, que coincidan o superen el nivel de seguridad de Azure Key Vault.

  • Protección del proceso de transferencia : proteja el archivo .byok durante la transferencia a Azure. Aunque el material de clave está cifrado, el archivo todavía debe tratarse como confidencial y transmitido a través de canales seguros.

  • Documente la implementación de BYOK : mantenga documentación detallada de qué claves se importaron a través de BYOK, sus propósitos y las configuraciones de HSM usadas. La documentación es fundamental para las auditorías de cumplimiento y la recuperación ante desastres.

  • Pruebe el proceso de importación : antes de importar claves de producción, pruebe todo el flujo de trabajo de BYOK con claves de prueba para garantizar la compatibilidad entre las herramientas del proveedor de HSM y Azure Key Vault.

  • Planificación de la rotación de claves - Establezca procedimientos para la rotación de claves BYOK. Aunque no puede exportar claves desde Azure Key Vault, puede importar nuevas versiones y actualizar los servicios dependientes.

  • Uso de HSM administrado para cargas de trabajo confidenciales : para entornos altamente regulados que requieren aislamiento HSM de inquilino único, considere la posibilidad de usar HSM administrado de Azure Key Vault, que admite BYOK y proporciona un control mejorado.

  • Implementación de controles de acceso : use el control de acceso basado en rol (RBAC) de Azure para restringir quién puede realizar operaciones BYOK. Separe los permisos para crear KEK de los permisos que pueden importar claves de destino.

  • Habilitación del registro de auditoría : active el registro y la supervisión de Azure Key Vault para realizar un seguimiento de todas las operaciones BYOK, incluida la generación de KEK, las descargas de claves y las importaciones de claves de destino. Integración de registros con Azure Monitor o una solución SIEM.

  • Comprobar el soporte técnico del proveedor : antes de comprar o implementar una solución HSM, compruebe que el proveedor proporciona una herramienta BYOK compatible con los requisitos actuales de Azure Key Vault.

  • Considere detenidamente las arquitecturas híbridas : BYOK es ideal cuando necesite mantener las claves locales inicialmente y, a continuación, migrar a Azure o cuando los requisitos normativos exijan procedimientos específicos de generación de claves.