Versions des clés dans Clusters Big Data SQL Server

S’applique à : SQL Server 2019 (15.x)

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 l’utilisation des versions des clés pour la gestion des clés dans Clusters Big Data SQL Server, et pour la rotation des clés pour les clés HDFS et SQL Server. L’article contient des détails sur la façon dont les versions peuvent incorporer des clés des clients.

Pour obtenir des informations générales sur la sécurisation de Clusters Big Data SQL Server, consultez Concepts de la sécurité pour Clusters Big Data SQL Server.

Pour plus d’informations sur la configuration et l’utilisation de la fonctionnalité de 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 des Clusters Big Data SQL Server

Clés HDFS

Pour utiliser le chiffrement au repos dans HDFS, les concepts suivants sont impliqués :

• Zones de chiffrement : la zone de chiffrement est un dossier dans HDFS qui est associé à une clé. Tous les fichiers de ce dossier sont chiffrés. La zone de chiffrement provisionnée par défaut dans Clusters Big Data SQL Server est appelée « securelake ».
• Clés de zone de chiffrement : Une clé symétrique nommée. La clé gérée par le système provisionnée par défaut dans Clusters Big Data SQL Server est « securelakekey ». Les clés de zone de chiffrement sont gérées avec KMS Hadoop qui s’exécute dans les pods de nœud nommés de Clusters Big Data SQL Server. Les clés de zone de chiffrement sont plus protégées par une clé de chiffrement principale stockée dans controldb (décrite dans les sections ci-dessous). Les clés de zone de chiffrement sont chiffrées dans KMS Hadoop en extrayant la partie publique de la clé de chiffrement principale, et les demandes de déchiffrement sont envoyées au plan de contrôle.
• Clé de chiffrement des données chiffrées : chaque fichier de la zone de chiffrement est chiffré par une clé de chiffrement de données (DEK) générée pour le fichier. Une fois la clé de chiffrement de données créée, elle est conservée avec les données. Pour rendre la clé de chiffrement de données persistante, elle est d’abord chiffrée par la clé de zone de chiffrement, puis elle est conservée avec les données. La clé de chiffrement de données est généré de façon aléatoire par fichier et la force de la clé de chiffrement de données symétrique est identique à la force de la clé de zone de chiffrement.

Le graphique ci-dessous explique comment les fichiers sont protégés par la clé de chiffrement de données et comment celle-ci est protégée par la securelakekey de la clé de chiffrement de données.

Clés SQL Server

La clé de chiffrement principale gérée par le système et les clés de zone de chiffrement HDFS sont stockées dans controldb, dont le nom est controldb-<#>, par exemple, controldb-0. Pour plus d’informations, consultez Ressources déployées avec Cluster Big Data.

Les bases de données SQL Server sont chiffrées par une clé symétrique, également appelée « clé de chiffrement de base de données » (DEK). La clé DEK est conservée avec la base de données à un format chiffré. Le protecteur de la clé DEK peut être un certificat ou une clé asymétrique. Pour changer de protecteur de la clé DEK, utilisez l’instruction ALTER DATABSE ENCRYPTION KEY. La clé asymétrique dans SQL Server a des métadonnées contenant un lien URL vers la clé au sein du plan de contrôle. Ainsi, toutes les opérations de chiffrement et de déchiffrement de la clé de chiffrement de base de données (DEK) sont effectuées à l’intérieur du contrôleur. SQL Server stocke la clé publique, mais seulement pour identifier la clé asymétrique, et il n’effectue pas de chiffrement en utilisant la clé publique.

Clé de chiffrement principale de Clusters Big Data SQL Server

Dans le plan de contrôle de Clusters Big Data SQL Server, pour protéger les clés de zone de chiffrement et pour provisionner des clés asymétriques dans SQL Server, il existe le concept de clé de chiffrement principale. Il y a deux clés de chiffrement principales : une pour SQL Server et une pour HDFS. Ce concept permet aussi au plan de contrôle de Clusters Big Data SQL Server d’autoriser la clé de chiffrement principale à se trouver à l’extérieur du cluster. Les propriétés de la clé de chiffrement principale sont les suivantes :

1. Les clés de chiffrement principales sont des clés RSA asymétriques.
2. Une clé de chiffrement principale est créée pour l’instance maître SQL Server et une autre pour HDFS.
3. La clé publique correspondant à la clé de chiffrement principale est toujours stockée dans la base de données du contrôleur, controldb. La clé privée est stockée dans la base de données du contrôleur pour la clé de chiffrement principale gérée par le système. Pour les clés de chiffrement provenant d’un module de sécurité matériel (HSM) ou de tout autre fournisseur externe, les clés privées ne sont pas stockées dans la base de données du contrôleur (sauf si l’application pour les clés externes y ajoute la clé privée). Cependant, la clé privée n’est pas nécessaire dans la base de données controldb et Clusters Big Data SQL Server ne nécessite pas les éléments de la clé privée.
4. Les opérations de chiffrement avec la clé publique de la clé de chiffrement principale peuvent être effectuées à l’intérieur du contrôleur lui-même, ou bien le contrôleur peut distribuer la clé publique à KMS Hadoop pour que celui-ci puisse effectuer le chiffrement localement. Les opérations de déchiffrement sont supposées être gérées par le fournisseur de clés externes, comme HSM. Cette conception nous permet de conserver la partie sensible de la clé asymétrique en dehors du cluster et sous la protection des clients. Ceci garantit que la racine du chiffrement pour déchiffrer toutes les données n’est jamais disponible dans l’écosystème Clusters Big Data SQL Server pour les clés configurées par les clients.

Protection du stockage des différentes clés

Les clés DEK pour les fichiers HDFS et pour SQL Server sont stockées avec les données protégées par ces clés. La clé DEK est protégée par la clé de zone de chiffrement HDFS et par la clé asymétrique dans SQL Server, respectivement.

Les clés asymétriques dans SQL Server ont des métadonnées incluant l’URL de la clé dans le plan de contrôle. SQL Server stocke seulement la clé publique de la clé asymétrique, permettant la corrélation avec la clé dans le plan de contrôle.

Le stockage des clés dans controldb est protégé par la clé de chiffrement de colonne dans controldb. La base de données controldb stocke des informations sensibles sur le cluster et toutes les informations sensibles sont protégées par une clé de chiffrement de colonne de SQL Server dans controldb, qui est en plus protégée par un mot de passe stocké dans les secrets Kubernetes. Pour plus d’informations, consultez la documentation sur les secrets dans Kubernetes.

La protection est récapitulée dans les diagrammes ci-dessous. Tout d’abord, la protection du stockage des clés de zone de chiffrement HDFS :

Protection du stockage de la clé de chiffrement principale :

Rotation des clés

Clés de zone de chiffrement HDFS

Quand Clusters Big Data SQL Server est déployé avec Active Directory, HDFS est provisionné avec une zone de chiffrement par défaut appelée securelake, protégée par une securelakekey. Nous allons utiliser les valeurs par défaut dans les exemples, mais de nouvelles zones et de nouvelles clés peuvent être provisionnées en utilisant azdata. La securelakekey est protégée par une clé de chiffrement principale pour HDFS, qui est stockée dans le plan de contrôle. À compter de SQL 2019 CU9, azdata peut être utilisé pour effectuer une rotation des clés de zone de chiffrement pour HDFS. La rotation des clés de zone de chiffrement provoque la génération de nouveaux éléments de clé, avec le même nom « securelakekey », mais avec une nouvelle version de la clé pointant vers les éléments de la clé. Pour les nouvelles opérations de chiffrement dans HDFS (par exemple des écritures de fichiers), la zone de chiffrement utilise toujours la version la plus récente de la clé associée à la zone. Pour les fichiers d’une zone de chiffrement, protégés par une version antérieure de clés, vous pouvez utiliser la commande azdata bdc hdfs encryption-zone reencrypt pour que tous les fichiers puissent être protégés par la dernière version de la clé de zone de chiffrement.

Prenons l’exemple d’un fichier appelé file2 placé dans /securelake. La chaîne de protection est représentée ci-dessous.

La securelakekey peut faire l’objet d’une rotation vers une nouvelle version en utilisant azdata bdc hdfs key roll -n securelakekey. La rotation n’entraîne pas le rechiffrement des clés DEK protégeant le fichier. La rotation de clé Hadoop provoque la génération de nouveaux éléments de clé et sa protection par la dernière version de la clé de chiffrement principale. Le diagramme suivant montre l’état du système après la rotation de securelakekey.

Pour garantir que les fichiers dans les zones de chiffrement sont protégés par la clé securelakekey obtenue après la rotation, utilisez azdata bdc hdfs encryption-zone -a start -p /securelake.

Le diagramme suivant montre l’état du système après le rechiffrement de la zone de chiffrement.

SQL Server

La clé protégeant la base de données SQL est la clé DEK, qui peut être regénérée. Le processus de regénération entraînerait le rechiffrement de toute la base de données.

Rotation de la clé de chiffrement principale

Notes

Avant SQL Server 2019 CU10, il n’existait aucun moyen d’effectuer une rotation de la clé de chiffrement principale. À compter de SQL Server 2019 CU10, la commande azdata est exposée pour permettre la rotation de la clé de chiffrement principale.

La clé de chiffrement principale est une clé RSA de 2 048 bits. La rotation de la clé de chiffrement principale va effectuer une des opérations suivantes, en fonction de la source de la clé :

1. Créer une clé en cas de demande de rotation de la clé principale avec une clé gérée par le système. Une clé gérée par le système est une clé asymétrique, générée et stockée dans le contrôleur.
2. Créer une référence à une clé fournie en externe, où la clé privée de la clé asymétrique sera gérée par l’application du client. L’application du client n’a pas besoin de la clé privée, mais elle doit savoir comment récupérer la clé privée en fonction de la configuration de l’application fournie.

La rotation de la clé principale ne rechiffre rien. Les clés SQL Server et HDFS doivent ensuite faire l’objet d’une rotation :

• Une fois la rotation de la clé principale effectuée, le protecteur de la clé DEK de la base de données SQL Server doit faire l’objet d’une rotation vers la nouvelle version de la clé principale créée.
• Des concepts similaires s’appliquent à HDFS. Une fois la rotation de la clé HDFS effectuée, le nouvel élément est chiffré en utilisant la dernière version de la clé principale. Les anciennes versions des clés de zone de chiffrement restent inchangées. Une fois la rotation de la clé de zone de chiffrement de HDFS effectuée, les zones de chiffrement associées à cette clé doivent être rechiffrées avec la dernière version de la clé de zone de chiffrement.

Rotation de la clé principale pour HDFS

Les diagrammes suivants illustrent le processus de rotation de la clé de chiffrement principale pour HDFS. Tout d’abord, l’état initial de HDFS :

La clé de chiffrement principale fera l’objet d’une rotation avec azdata bdc kms set –key-provider SystemManaged. (Notez que la commande provoque la rotation de la clé de chiffrement principale à la fois pour SQL et pour HDFS, même s’il s’agit de clés différentes dans le plan de contrôle.) Après l’utilisation de la commande azdata bdc kms :

Pour utiliser la nouvelle version de la clé de chiffrement principale de HDFS, la commande azdata bdc hdfs key roll peut être utilisée, qui met alors le système dans l’état suivant. Après rotation de la clé securelakekey :

La rotation de la clé securelakekey va entraîner la création d’une nouvelle version de la clé securelakekey et sa protection par la clé de chiffrement principale. Pour que les fichiers dans securelake soient chiffrés par securelakekey@2, la zone de chiffrement securelake doit être rechiffrée. Après le rechiffrement de la zone de chiffrement :

Rotation de la clé principale pour SQL Server

La clé de chiffrement principale de SQL Server est installée dans la base de données master de l’instance maître SQL Server.

Les diagrammes suivants illustrent le processus de rotation de la clé de chiffrement principale pour SQL Server.

Sur une nouvelle installation de Clusters Big Data SQL Server, aucune clé asymétrique n’est provisionnée dans SQL Server. Dans l’état initial de SQL Server, les bases de données peuvent être chiffrées en utilisant des certificats, mais l’administrateur de l’instance maître SQL Server contrôle cet aspect.

La clé de chiffrement principale fera l’objet d’une rotation avec azdata bdc kms set –key-provider SystemManaged. (Notez que la commande provoque la rotation [ou si elle n’existe pas, la création] de la clé de chiffrement principale à la fois pour SQL et pour HDFS, même s’il s’agit de clés différentes dans le plan de contrôle.)

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 de nommage « 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;

Maintenant, le protecteur de la clé DEK est modifié de façon à utiliser la clé asymétrique :

Si la commande azdata bdc kms set est réexécutée, les clés asymétriques dans SQL Server montrent une autre entrée dans sys.asymmetric_keys au format « tde_asymmetric_key_<version> ». Cette commande azdata peut être réutilisée pour modifier à nouveau le protecteur DEK d’une base de données SQL Server.

Clé fournie par un client

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é DEK de SQL sont également envoyées au plan de contrôle, puis sont redirigées vers l’application KMS.

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 routés vers le plan de contrôle sont ensuite routés vers l’application de plug-in KMS. L’application de plug-in KMS route la demande vers l’emplacement approprié, par exemple le module de sécurité matériel ou un autre produit.

Voir aussi

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