Fournisseurs de clés externes dans des clusters Big Data SQL Server

Cet article fournit des détails sur la configuration des fournisseurs de clés externes dans des clusters Big Data SQL Server pour la gestion des clés.

Pour en savoir plus sur l’utilisation des versions clés sur les clusters Big Data SQL Server, consultez : Versions clés dans les clusters Big Data SQL Server.

Pour plus d’informations sur la configuration et l’utilisation du chiffrement au repos, consultez les guides suivants :

• Guide des concepts et de la configuration du chiffrement au repos
• Guide d’utilisation des zones de chiffrement HDFS des Clusters Big Data SQL Server
• Guide d’utilisation du TDE (Transparent Data Encryption) au repos Clusters Big Data SQL Server

Prerequisites

• Notes de publication des clusters Big Data SQL Server 2019. CU11+ required.
• Outils Big Data y compris azdata 20.3.5+.
• Utilisateur de Clusters Big Data SQL Server avec des privilèges d’administration de Kubernetes, un membre du rôle clusterAdmins. Pour plus d’informations, consultez Gérer l’accès au cluster Big Data en mode Active Directory.
• Application de modèle de fournisseur externe. Consultez chiffrement des données au repos de BDC SQL Server.

Chiffrement de clé racine à l’aide de fournisseurs externes

Avec la possibilité d’apporter des clés externes dans des clusters Big Data SQL Server, la clé de chiffrement principale extrait la clé publique à l’aide de l’application que le client déploie. Lorsque les clés HDFS sont pivotées et utilisées, les appels pour déchiffrer les clés HDFS sont envoyés au plan de contrôle, puis redirigés vers l’application à l’aide de l’identificateur de clé fourni par le client. Pour SQL Server, les demandes de chiffrement sont envoyées et effectuées par le plan de contrôle, car il a la clé publique. Les demandes de déchiffrement de la clé de chiffrement des données (DEK) à partir de SQL Server sont également envoyées au plan de contrôle, puis sont redirigées vers l’application qui s’interface avec le fournisseur externe, comme un module de sécurité matériel (HSM).

Le diagramme suivant explique les interactions lors de la configuration de clés externes dans le plan de contrôle :

Une fois la clé installée, le chiffrement et le déchiffrement de différentes charges utiles sont protégés par la clé de chiffrement principale. Cette protection est similaire aux clés gérées par le système, sauf que les appels de déchiffrement routés vers le plan de contrôle sont ensuite routés vers l’application de plug-in KMS (Key Management Service). L’application de plug-in KMS achemine la requête vers un emplacement approprié, tel qu’un HSM, Hashicorp Vault ou un autre produit.

Configuration

L’application de modèle fournie est le plug-in utilisé pour interagir avec le fournisseur de clés externes. Cette application doit être personnalisée et déployée dans des clusters Big Data pour servir de point d’intégration au fournisseur de clés externe choisi.

Dans l’application modèle, il existe des exemples sur l’intégration à des implémentations de fournisseurs externes à l’aide du protocole PKCS11 standard à l’aide de SoftHSM. Il existe également des exemples utilisant Azure Key Vault et Hashicorp Vault. Les applications modèles sont fournies as-is comme implémentations de référence.

Les sections suivantes fournissent les étapes requises pour configurer un fournisseur de clés externe pour servir de clé racine de chiffrement pour les bases de données SQL Server et les zones de chiffrement HDFS.

Créer une clé RSA 2048 dans votre fournisseur de clés externes

Créez un fichier PEM avec une clé RSA 2048 bits et chargez-le dans le magasin de valeurs de clé dans votre fournisseur de clés externe.

Par exemple, le fichier de clé peut être ajouté au magasin KV dans Hashicorp Vault sur le chemin bdc-encryption-secret et le nom du secret peut être rsa2048.

Personnaliser et déployer l’application d’intégration sur des clusters Big Data

1. Dans votre ordinateur local, accédez au dossier qui contient kms_plugin_app, les applications de modèle AppDeploy de clusters Big Data.

2. Personnalisez l’application en choisissant l’un des modèles et en l’ajustant à votre scénario :

   • Le fichier custom_softhsm.py contient une implémentation de référence à l’aide de SoftHSM
   • Le custom_akv.py de fichiers contient un exemple Azure Key Vault
   • Le fichier custom_hcv.py contient un exemple HashiCorp Vault

   Caution

   Ne modifiez pas les contrats de fonction ou les signatures, qui sont les points d’intégration. Modifiez uniquement les implémentations de fonction, si nécessaire.

3. Nommez le fichier que vous créez à partir du modèle ci-dessus en conséquence. Par exemple, enregistrez custom_softhsm.py en tant que my_custom_integration_v1.py , puis effectuez vos personnalisations. Cette approche est importante pour l’étape suivante.

4. app.py est le point d’entrée qui charge l’application. Dans ce fichier, vous devez modifier la ligne 11 pour pointer vers le nom de fichier personnalisé sans l’extension .py de l’étape précédente. Dans l’exemple ci-dessus, modifiez :

   ...
   import utils
   from json_objects import EncryptDecryptRequest
   import custom_softhsm as custom
   
   def handler(operation, payload, pin, key_attributes, version):
   ...
   

   à la valeur suivante :

   ...
   import utils
   from json_objects import EncryptDecryptRequest
   import my_custom_integration_v1 as custom
   
   def handler(operation, payload, pin, key_attributes, version):
   ...
   

5. À partir du dossier qui contient le fichier spec.yaml, déployez l’application sur des clusters Big Data à l’aide de cette commande :

   azdata app create -s
   

6. Attendez que le déploiement de l’application se termine et que l’état prêt puisse être vérifié à l’aide de cette commande :

   azdata app list
   

Configurer des clusters Big Data pour utiliser le fournisseur de clés externes

1. Définissez la AZDATA_EXTERNAL_KEY_PIN variable d’environnement pour fournir le jeton qui autorise l’accès au fournisseur de clés externes :

   export AZDATA_EXTERNAL_KEY_PIN=<your PIN/token here>
   

   Note

   Le processus de déploiement d’application d’intégration utilise le jeton pour accéder à votre fournisseur de clés externes. Toutefois, la AZDATA_EXTERNAL_KEY_PIN variable est enregistrée chiffrée dans le plan de contrôle Des clusters Big Data afin qu’elle puisse être interprétée par l’application. Un autre mécanisme d’authentification peut également être utilisé, mais l’application doit être modifiée. Vérifiez l’application python personnalisée*.py pour connaître la logique d’intégration complète utilisée.

2. Configurez la clé dans les clusters Big Data à l’aide de la structure de commandes suivante azdata . Modifiez les paramètres requis pour les adapter à votre implémentation spécifique. L’exemple suivant utilise une structure HashiCorp Vault fournie par custom2.py.

   azdata bdc kms update --app-name <YOUR-APP-NAME> --app-version <YOUR-APP-VERSION> \
   --key-attributes keypath=<YOUR-KEY-PATH>,vaulturl=http://<YOUR-IP>:<YOUR-PORT>,keyname=<YOUR-KEY-NAME> \
   --provider External
   

   La --provider External valeur du paramètre configure le service KMS des clusters Big Data pour utiliser l’application d’intégration comme point de terminaison pour les opérations clés.

3. Vérifiez la clé de chiffrement racine en tant que clé gérée en externe à l’aide de la commande suivante.

   azdata bdc kms show
   

Chiffrer vos bases de données et zones de chiffrement avec les nouvelles clés

Après la configuration, les bases de données SQL Server et les zones de chiffrement HDFS sont toujours chiffrées par la hiérarchie de clés précédente. Vous devez chiffrer explicitement à l’aide des clés gérées en externe.

Dans SQL Server, une nouvelle clé asymétrique basée sur la clé gérée en externe est installée. Utilisez-la pour chiffrer vos bases de données.

La clé asymétrique peut être visualisée en utilisant la requête T-SQL suivante, avec la vue du catalogue système sys.asymmetric_keys.

USE master;
select * from sys.asymmetric_keys;

La clé asymétrique apparaît avec la convention de dénomination tde_asymmetric_key_<version>. L’administrateur SQL Server peut ensuite remplacer le protecteur de la clé DEK par la clé asymétrique en utilisant ALTER DATABASE ENCRYPTION KEY. Par exemple, utilisez la commande T-SQL suivante :

USE db1;
ALTER DATABASE ENCRYPTION KEY ENCRYPTION BY SERVER ASYMMETRIC KEY tde_asymmetric_key_0;

1. Exécutez la commande suivante pour vérifier la clé de chiffrement actuelle :

   azdata bdc hdfs key describe
   

2. Obtenez des informations sur la version de la clé protégeant la clé de zone de chiffrement :

   azdata bdc hdfs key describe --name <key name>
   

3. Faites passer votre clé à la nouvelle clé gérée externe :

   azdata bdc hdfs key roll --name <new key name>
   

4. Démarrez le chiffrement à l’aide de cette commande :

   azdata bdc hdfs encryption-zone reencrypt –-path <your EZ path> --action start
   

5. Vérifiez la hiérarchie de clés à l’aide des commandes suivantes :

   azdata bdc kms show
   azdata bdc hdfs key describe
   

Next steps

• Concepts de sécurité pour Clusters Big Data SQL Server
• Configurer un cluster Big Data SQL Server
• FAQ sur les clusters Big Data