Configurer Apportez votre propre clé (BYOK)

Effectué

Scénario

Un client de Key Vault souhaite transférer en toute sécurité une clé à partir de son HSM local vers l'HSM soutenant Azure Key Vault. Le processus d’importation d’une clé générée en dehors du coffre de clés est appelé BYOK (Bring Your Own Key).

Pourquoi BYOK est important pour la sécurité : de nombreuses organisations nécessitent un contrôle sur leurs clés de chiffrement pour la conformité, les exigences réglementaires ou les stratégies de sécurité. BYOK vous permet de contrôler l’ensemble du cycle de vie des clés, de la génération à la destruction, tout en utilisant l’infrastructure cloud d’Azure. En outre, BYOK s’aligne sur les principes de confiance zéro en conservant la séparation de chiffrement entre vos fournisseurs de clés et de cloud jusqu’à ce que vous autorisez explicitement le transfert.

Voici les conditions requises :

  • La clé à transférer n’existe jamais en dehors d’un HSM sous forme de texte brut : s’assurer que même pendant le processus de transfert, le matériel de clé reste protégé.
  • En dehors d'un module HSM, la clé à transférer est toujours protégée par une clé détenue dans le HSM Azure Key Vault - Fournissant une garantie cryptographique que seul Azure Key Vault peut dé-chiffrer la clé importée.

Terminologie

Nom de Clé Type de clé Origine Description
Clé d’échange de clés (KEK) RSA HSM Azure Key Vault Paire de clés RSA sauvegardée par HSM générée dans Azure Key Vault
Clé d’enveloppement AES Fournisseur HSM Clé AES éphémère générée par HSM local
Clé cible RSA, EC, AES (HSM managé uniquement) Fournisseur HSM La clé à transférer vers le Key Vault HSM d'Azure

Clé d’échange de clés (KEK) : clé générée par le client, clé sauvegardée par HSM dans le coffre de clés destiné à l’importation de la clé BYOK (Bring Your Own Key). La clé KEK doit avoir les propriétés suivantes :

  • Il doit s’agir d’une clé RSA-HSM, avec une taille de clé de 4 096 bits (recommandé), 3 072 bits ou 2 048 bits.
  • Ses opérations clés (key_ops) sont limitées à « importer », ce qui permet son utilisation exclusivement pendant le processus BYOK. Cette restriction réduit la surface d’attaque.
  • Il doit résider dans le même coffre que celui dans lequel la clé cible doit être importée, ce qui garantit l’isolation appropriée du coffre de clés.

Étapes de l’utilisateur

Pour effectuer un transfert de clé :

  1. Générer une clé KEK : créez une clé d’échange de clés dans Azure Key Vault.
  2. Récupérez la clé publique du KEK : téléchargez la partie publique à utiliser avec vos outils de fournisseur HSM.
  3. À l’aide de l’outil BYOK fourni par le fournisseur HSM, importez la clé KEK dans le HSM cible et exportez la clé cible protégée par la clé KEK.
  4. Importez la clé cible protégée dans Azure Key Vault : effectuez le transfert à l’aide d’Azure CLI ou de PowerShell.

Les clients utilisent l’outil BYOK et la documentation fournies par le fournisseur HSM pour terminer l’étape 3. Ce processus produit un objet blob de transfert de clés (fichier .byok) qui encapsule en toute sécurité le matériel de clé chiffrée.

Contraintes HSM

Le module HSM existant peut appliquer des contraintes sur les clés qu’ils gèrent, notamment :

  • Le module HSM doit être configuré pour autoriser l’exportation fondée sur l'encapsulation de clés.
  • La clé cible est marquée CKA_EXTRACTABLE (attribut Cryptoki) pour le HSM afin d’autoriser l’exportation contrôlée.
  • Dans certains cas, la clé KEK et la clé d’habillage sont marquées comme CKA_TRUSTED, ce qui leur permet d’être utilisées pour encapsuler les clés dans le HSM.

La configuration du HSM source est généralement en dehors de l’étendue de cette spécification. Microsoft s’attend à ce que le fournisseur HSM produise de la documentation qui accompagne son outil BYOK pour inclure toutes ces étapes de configuration.

Remarque

Ces étapes peuvent être effectuées à l’aide de plusieurs interfaces, notamment Azure CLI (illustré dans des exemples), Azure PowerShell et le portail Azure. Elles peuvent également être effectuées par programmation à l’aide du Kit de développement logiciel (SDK) Azure Key Vault pour les scénarios de déploiement automatisé.

Générer la KEK

Pour créer une clé KEK avec les opérations de clé définies sur import, utilisez la commande az keyvault key create. Notez l’identificateur de clé ('kid') retourné par cette commande, car vous en avez besoin pour les opérations suivantes.

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

Important

Différents services Azure prennent en charge des longueurs de KEK différentes. Par exemple, Azure SQL prend en charge les longueurs de clé de 2048 bits ou 3072 bits uniquement. Vérifiez toujours les exigences liées à la taille de clé pour votre service spécifique avant de générer la clé KEK.

Récupérer la clé publique du KEK

Téléchargez la partie clé publique du KEK et stockez-la sous forme de fichier PEM (Privacy-Enhanced Courrier). Ce fichier est utilisé avec l’outil BYOK de votre fournisseur HSM.

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




Générer un blob de transfert de clés à l’aide de l’outil BYOK fourni par le fournisseur HSM

Utilisez l’outil BYOK fourni par le fournisseur HSM pour créer un objet blob de transfert de clé (stocké sous forme de fichier .byok). La clé publique KEK, au format Privacy-Enhanced Mail (.pem) est l’une des entrées de cet outil. Consultez la documentation spécifique de votre fournisseur HSM pour obtenir des instructions détaillées sur l’utilisation de son outil BYOK.

Objet blob de transfert de clé

À long terme, Microsoft souhaite utiliser le mécanisme de CKM_RSA_AES_KEY_WRAP PKCS#11 pour transférer la clé cible vers Azure Key Vault. Le mécanisme PKCS#11 produit un objet blob unique et, plus important encore, la clé AES intermédiaire est gérée par les deux modules HSM et son caractère éphémère est garanti.

Le texte en clair de la clé cible dépend du type de clé :

  • Pour une clé RSA, l’encodage DER ASN.1 de clé privée [RFC3447] enveloppé dans PKCS#8 [RFC5208]
  • Pour une clé EC, l’encodage DER ASN.1 de clé privée [RFC5915] enveloppé dans PKCS#8 [RFC5208]
  • Pour une clé d’octet, octets bruts de la clé

Les octets de la clé en texte clair sont ensuite transformés à l’aide du mécanisme de CKM_RSA_AES_KEY_WRAP :

  • Une clé AES éphémère est générée et chiffrée avec la clé RSA d'enveloppement en utilisant RSA-OAEP avec SHA1.
  • La clé en clair encodée est chiffrée à l'aide de la clé AES en utilisant AES Key Wrap avec remplissage.
  • La clé AES chiffrée et la clé en texte clair chiffrée sont concaténées pour produire l’objet blob de texte chiffré final.

Le format de l'objet blob de transfert utilise la sérialisation compacte JSON Web Encryption (RFC7516) principalement comme moyen de fournir les métadonnées requises au service pour un déchiffrement adéquat.

Meilleures pratiques pour l’implémentation de BYOK

Lors de l’implémentation de Bring Your Own Key Vault pour Azure Key Vault, tenez compte de ces recommandations de sécurité et opérationnelles :

  • Utilisez la plus grande taille de clé prise en charge : générez des clés KEK avec des tailles de clé 4096 bits dans la mesure du possible, car elles fournissent la protection de chiffrement la plus forte. Utilisez uniquement des tailles de clés plus petites quand elles sont requises par des contraintes de service spécifiques.

  • Limitez les opérations de clé KEK : limitez toujours les opérations KEK à « importer » uniquement. Vous réduisez la surface d’attaque et assurez-vous que la clé KEK ne peut pas être utilisée de manière incorrecte pour d’autres opérations de chiffrement.

  • Conservez les certifications de sécurité HSM : assurez-vous que votre HSM local répond aux normes de certification FIPS 140-2 de niveau 2 ou supérieures, correspondant ou dépassant le niveau de sécurité d’Azure Key Vault.

  • Sécurisez le processus de transfert : protégez le fichier .byok pendant le transfert vers Azure. Bien que le matériel de clé soit chiffré, le fichier doit toujours être traité comme sensible et transmis sur des canaux sécurisés.

  • Documentez votre implémentation BYOK : conservez une documentation détaillée sur les clés importées via BYOK, leurs objectifs et les configurations HSM utilisées. La documentation est essentielle pour les audits de conformité et la récupération d’urgence.

  • Testez le processus d’importation : avant d’importer des clés de production, testez l’intégralité du flux de travail BYOK avec des clés de test pour garantir la compatibilité entre les outils de votre fournisseur HSM et Azure Key Vault.

  • Planifier la rotation des clés : établissez des procédures de rotation des clés BYOK. Bien que vous ne puissiez pas exporter de clés à partir d’Azure Key Vault, vous pouvez importer de nouvelles versions et mettre à jour des services dépendants.

  • Utilisez le HSM managé pour les charges de travail sensibles : pour les environnements hautement réglementés nécessitant une isolation HSM monolocataire, envisagez Azure Key Vault Managed HSM, qui prend en charge BYOK et fournit un contrôle amélioré.

  • Implémenter des contrôles d’accès : utilisez le contrôle d’accès en fonction du rôle Azure (RBAC) pour restreindre les personnes pouvant effectuer des opérations BYOK. Séparez les autorisations permettant de créer des clés KEK à partir des autorisations qui peuvent importer des clés cibles.

  • Activer la journalisation d’audit : activez la journalisation et la surveillance Azure Key Vault pour suivre toutes les opérations BYOK, notamment la génération KEK, les téléchargements de clés et les importations de clés cibles. Intégrez des journaux à Azure Monitor ou à une solution SIEM.

  • Vérifiez la prise en charge du fournisseur : avant d’acheter ou d’implémenter une solution HSM, vérifiez que le fournisseur fournit un outil BYOK compatible avec les exigences actuelles d’Azure Key Vault.

  • Tenez compte des architectures hybrides soigneusement : BYOK est idéal lorsque vous devez gérer les clés locales initialement, puis migrer vers Azure, ou lorsque les exigences réglementaires imposent des procédures spécifiques de génération de clés.