Fournisseurs de clés externes dans Clusters Big Data SQL Server

Article
03/21/2023

Important

Le module complémentaire Clusters Big Data Microsoft SQL Server 2019 sera mis hors service. La prise en charge de la plateforme Clusters Big Data Microsoft SQL Server 2019 se terminera le 28 février 2025. Tous les utilisateurs existants de SQL Server 2019 avec Software Assurance seront entièrement pris en charge sur la plateforme, et le logiciel continuera à être maintenu par les mises à jour cumulatives SQL Server jusqu’à ce moment-là. Pour plus d’informations, consultez le billet de blog d’annonce et les Options Big Data sur la plateforme Microsoft SQL Server.

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

Pour plus d’informations sur la façon dont les versions des clés sont utilisées sur Clusters Big Data SQL Server, consultez Versions des clés dans Clusters Big Data SQL Server.

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

Prérequis

Notes de publication de Clusters Big Data SQL Server 2019. CU11+ est obligatoire.
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 au repos BDC SQL Server.

Chiffrement de clé racine en utilisant des fournisseurs externes

Avec la possibilité d’amener des clés externes dans Clusters Big Data SQL Server, la clé de chiffrement principale extrait la clé publique en utilisant l’application déployée par le client. Quand des clés HDFS font l’objet d’une rotation et sont 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 en utilisant 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) de SQL Server sont également envoyées au plan de contrôle, puis sont redirigées vers l’application qui interagit avec le fournisseur externe, comme un module de sécurité matériel (HSM).

Le diagramme représente la situation après l’installation de la clé client.

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 des 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, à la différence que les appels de déchiffrement acheminés vers le plan de contrôle sont ensuite acheminés vers l’application de plug-in du service de gestion des clés (KMS). L’application de plug-in KMS achemine la demande vers l’emplacement approprié, par exemple un module de sécurité matériel, HashiCorp Vault ou un autre produit.

Configuration

Le modèle d’application fourni est le plug-in utilisé pour s’interfacer avec le fournisseur de clé externe. Cette application doit être personnalisée et déployée dans Clusters Big Data pour servir de point d’intégration avec le fournisseur de clé externe choisi.

Le modèle d’application contient des exemples de la façon de s’intégrer à des implémentations de fournisseur externe avec le protocole PKCS11 standard en utilisant SoftHSM. Il existe également des exemples utilisant Azure Key Vault et HashiCorp Vault. Les modèles d’applications sont fournis tels quels et constituent des implémentations de référence.

Les sections suivantes fournissent les étapes nécessaires à la configuration d’un fournisseur de clé externe pour servir de clé racine de chiffrement pour des bases de données SQL Server et des zones de chiffrement HDFS.

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

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

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

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

Dans votre ordinateur local, accédez au dossier qui contient kms_plugin_app, les applications de modèles AppDeploy Clusters Big Data.
Personnalisez l’application en choisissant un des modèles et en l’ajustant à votre scénario :
- Le fichier custom_softhsm.py contient une implémentation de référence utilisant SoftHSM
- Le fichier custom_akv.py contient un exemple d’Azure Key Vault
- Le fichier custom_hcv.py contient un exemple HashiCorp Vault
Attention

Ne modifiez pas les contrats ni les signatures des fonctions, car il s’agit de points d’intégration. Modifiez seulement les implémentations de fonctions, si nécessaire.
Nommez le fichier que vous créez à partir du modèle ci-dessus en conséquence. Par exemple, enregistrez custom_softhsm.py sous my_custom_integration_v1.py puis procédez à vos personnalisations. Cette approche est importante pour l’étape suivante.

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

...
import utils
from json_objects import EncryptDecryptRequest
import custom_softhsm as custom

def handler(operation, payload, pin, key_attributes, version):
...

par 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):
...

À partir du dossier qui contient la spec.yaml, déployez l’application sur Clusters Big Data à l’aide de cette commande :
```
azdata app create -s
```
Attendez que le déploiement de l’application soit terminé et que l’état « Prêt » puisse être vérifié en utilisant cette commande :
```
azdata app list
```

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

Définissez la variable d’environnement AZDATA_EXTERNAL_KEY_PIN pour fournir le jeton qui autorise l’accès au fournisseur de clés externes :
```
export AZDATA_EXTERNAL_KEY_PIN=<your PIN/token here>
```
Notes

Le processus de déploiement d’applications d’intégration utilise le jeton pour accéder à votre fournisseur de clés externes. Toutefois, la variable AZDATA_EXTERNAL_KEY_PIN est enregistrée chiffrée dans la plan de contrôle Clusters Big Data, afin qu’elle puisse être interprétée par l’application. Un mécanisme d’authentification différent peut aussi être utilisé, mais l’application doit être alors modifiée. Regardez l’application Python custom*.py pour voir la logique d’intégration complète qui est utilisée.
Configurez la clé dans Clusters Big Data à l’aide de la structure de commandes suivante azdata. Remplacez les paramètres requis par votre implémentation spécifique. L’exemple suivant utilise une structure HashiCorp Vault telle qu’elle est 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 valeur du paramètre --provider External configure KMS Clusters Big Data pour utiliser l’application d’intégration comme point de terminaison pour les opérations de clé.
Vérifiez que la clé de chiffrement racine est gérée en externe en utilisant la commande suivante.
```
azdata bdc kms show
```

Chiffrer vos bases de données et vos 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 des clés précédentes. Vous devez chiffrer explicitement en utilisant les clés gérées en externe.

Dans SQL Server, une nouvelle clé asymétrique basée sur la clé managée en externe est installée. Utilisez celle-ci 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 s’affiche avec la convention nommée 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;

Exécutez la commande suivante pour vérifier la clé de chiffrement actuelle :
```
azdata bdc hdfs key describe
```
Obtenez des informations sur la version de la clé protégeant la clé de la zone de chiffrement :
```
azdata bdc hdfs key describe --name <key name>
```
Remplacez votre clé par la nouvelle clé gérée externe :
```
azdata bdc hdfs key roll --name <new key name>
```

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

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

Vérifiez la hiérarchie de clés en utilisant les commandes suivantes :
```
azdata bdc kms show
azdata bdc hdfs key describe
```

Partager via