Partager via

Guide de configuration et de concepts du chiffrement au repos

  • Article

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.

À compter de Clusters Big Data Microsoft SQL Server 2019 CU8, la fonctionnalité de chiffrement au repos est disponible pour fournir le chiffrement au niveau de l’application à toutes les données stockées dans la plateforme. Ce guide décrit les concepts, l’architecture et la configuration de l’ensemble de fonctionnalités de chiffrement au repos pour Clusters Big Data.

Les Clusters Big Data SQL Server stockent les données dans les emplacements suivants :

  • Instance maître SQL Server.
  • HDFS. Utilisé par le pool de stockage et Spark.

Il existe deux approches pour chiffrer de manière transparente les données dans des Clusters Big Data SQL Server :

  • Chiffrement de volume. La plateforme Kubernetes prend en charge cette approche. Il est recommandé pour les déploiements Clusters Big Data. Cet article ne traite pas du chiffrement de volume. Consultez la documentation de votre plateforme ou de votre appliance Kubernetes pour savoir comment chiffrer correctement des volumes utilisés pour les Clusters Big Data SQL Server.
  • Chiffrement au niveau de l’application. Cette architecture fait référence au chiffrement des données par l’application qui gère les données avant qu’elles ne soient écrites sur le disque. Si les volumes sont exposés, un attaquant ne pourra pas restaurer les artefacts de données ailleurs, sauf si le système de destination a également été configuré avec les mêmes clés de chiffrement.

L’ensemble de fonctionnalités de chiffrement au repos des Clusters Big Data SQL Server prend en charge le scénario de base du chiffrement au niveau de l’application pour les composants SQL Server et HDFS.

La fonctionnalité offre les caractéristiques suivantes :

  • Chiffrement au repos managé par le système. Cette possibilité est disponible dans CU8+.
  • Le chiffrement géré par l’utilisateur au repos, également connu sous le nom de BYOK (Bring Your Own Key). Les intégrations managées par le service ont été introduites dans SQL Server 2019 CU8. Les intégrations de fournisseurs de clés externes ont été introduites dans SQL Server 2019 CU11+.

Pour plus d’informations, consultez Versions des clés dans Clusters Big Data SQL Server.

Définitions des clés

  • Service de gestion de clés des Clusters Big Data SQL Server (KMS)

    Service hébergé par un contrôleur chargé de gérer les clés et les certificats pour la fonctionnalité de chiffrement au repos définie pour Clusters Big Data SQL Server. Le service prend en charge les fonctionnalités suivantes :

    • Gestion et stockage sécurisés des clés et certificats utilisés pour le chiffrement au repos.
    • Compatibilité KMS Hadoop. KMS agit en tant que service de gestion des clés pour le composant HDFS sur Clusters Big Data.
    • Gestion des certificats SQL Server Transparent Data Encryption (TDE).

  • Clés managées par le système

    Le service KMS Clusters Big Data gère l’ensemble des clés et certificats pour SQL Server et HDFS

  • Clés définies par l’utilisateur

    Clés définies par l’utilisateur à gérer par KMS Clusters Big Data, communément appelées BYOK (Bring Your Own Key). Clusters Big Data SQL Server prend en charge la définition personnalisée des clés à utiliser pour le chiffrement sur les composants SQL Server et HDFS. Le KMS Clusters Big Data gère ces clés.

    Attention

    L’instance maître SQL Server hérite de la fonctionnalité de chiffrement transparent des données (TDE) de SQL Server. Cependant, le chargement manuel de clés personnalisées depuis des fichiers sur les pods, leur inscription sur SQL Server et leur utilisation pour TDE n’est pas un scénario pris en charge. Le KMS Clusters Big Data ne gère pas ces clés. Cette situation peut rendre vos bases de données illisibles. Pour utiliser correctement des clés fournies en externe, utilisez la fonctionnalité « Fournisseurs externes » comme décrit dans cet article.

  • Fournisseurs externes

    Les solutions de clé externe compatibles avec KMS Clusters Big Data sont prises en charge pour la délégation des opérations de chiffrement. Cette fonctionnalité est prise en charge sur SQL Server 2019 CU11+. Quand cette fonctionnalité est activée, la clé racine du chiffrement est hébergée en dehors du contrôleur Clusters Big Data.

Chiffrement au repos sur des clusters Big Data SQL Server

Le service du contrôleur KMS Clusters Big Data offre une prise en charge des clés managées par le système et des clés contrôlées par un fournisseur externe pour effectuer le chiffrement des données au repos sur SQL Server et sur HDFS.

Ces clés et certificats sont managés par le service. Cet article fournit des conseils opérationnels sur la façon d’interagir avec le service.

L’ensemble de fonctionnalités présente le service du contrôleur KMS Clusters Big Data pour fournir des clés et des certificats managés par le système pour le chiffrement des données au repos sur SQL Server et HDFS. Ces clés et certificats sont managés par le service. Cet article fournit des conseils opérationnels sur la façon d’interagir avec le service.

  • Les instances SQL utilisent la fonctionnalité Transparent Data Encryption (TDE) établie.
  • HDFS utilise le service KMS Hadoop natif dans chaque pod pour interagir avec le KMS Clusters Big Data sur le contrôleur. Cette approche active les zones de chiffrement HDFS, qui fournissent des chemins d’accès sécurisés sur HDFS.

Instances SQL

  • Un certificat généré par le système est installé sur des pods SQL Server à utiliser avec les commandes TDE. La norme de dénomination des certificats managés par le système est TDECertificate + timestamp. Par exemple : TDECertificate2020_09_15_22_46_27.
  • Les bases de données configurées par Clusters Big Data de l’instance maître et les bases de données utilisateur ne sont pas chiffrées automatiquement. Les administrateurs de base de données peuvent utiliser le certificat installé pour chiffrer n’importe quelle base de données.
  • Le pool de calcul et le pool de stockage sont automatiquement chiffrés à l’aide du certificat généré par le système.
  • Le chiffrement du pool de données, quoique techniquement possible à l’aide de commandes EXECUTE AT T-SQL, est déconseillé et n’est pas pris en charge pour l’instant. L’utilisation de cette technique pour chiffrer des bases de données du pool de données peut ne pas être efficace et le chiffrement peut ne pas se produire à l’état souhaité. L’approche crée également un chemin de mise à niveau incompatible vers les prochaines mises en production.
  • La rotation des clés SQL Server est obtenue à l’aide des commandes d’administration T-SQL standard. Pour plus d’informations, consultez Guide d’utilisation de TDE (Transparent Data Encryption) au repos de Clusters Big Data SQL Server.
  • L’analyse du chiffrement s’effectue par le biais des DMV SQL Server standard existantes pour TDE.
  • La sauvegarde et la restauration d’une base de données TDE activée dans le cluster sont prises en charge.
  • La haute disponibilité est prise en charge. Si une base de données sur l’instance principale de SQL Server est chiffrée, le réplica secondaire de la base de données est également chiffré.

Zones de chiffrement HDFS

  • L’intégration Active Directory est nécessaire pour activer la fonctionnalité de zones de chiffrement pour HDFS.
  • Une clé générée par le système sera configurée dans Hadoop KMS. Le nom de la clé est securelakekey. Sur CU8, la clé par défaut est 256 bits et le chiffrement AES 256 bits est pris en charge.
  • Une zone de chiffrement par défaut sera configurée à l’aide de la clé générée par le système ci-dessus sur un chemin d’accès nommé /securelake.
  • Les utilisateurs peuvent créer d’autres clés et zones de chiffrement à l’aide des instructions spécifiques fournies dans ce guide. Les utilisateurs peuvent choisir la taille de clé 128, 192 ou 256 pendant la création de la clé.
  • La rotation des clés des zones de chiffrement HDFS est effectuée avec azdata. Pour plus d’informations, consultez Guide d’utilisation des zones de chiffrement HDFS de Clusters Big Data SQL Server.
  • Le montage hiérarchisé HDFS au-dessus d’une zone de chiffrement n’est pas pris en charge.

Administration du chiffrement au repos

La liste suivante contient les fonctionnalités d’administration du chiffrement au repos :

Guide de configuration

Pendant de nouveaux déploiements de Clusters Big Data SQL Server, CU8 et versions ultérieures, le chiffrement au repos est activé et configuré par défaut. Cela signifie que :

  • Les composants KMS Clusters Big Data sont déployés dans le contrôleur et génèrent un ensemble de clés et de certificats par défaut .
  • SQL Server est déployé avec TDE activé et les certificats sont installés par le contrôleur.
  • Hadoop KMS pour HDFS est configuré pour interagir avec le KMS Clusters Big Data pour les opérations de chiffrement. Les zones de chiffrement HDFS sont configurées et prêtes à l’emploi.

Les spécifications et les comportements par défaut décrits dans la section précédente s’appliquent.

Si vous effectuez un nouveau déploiement de Clusters Big Data SQL Server CU8 ou une mise à niveau directe vers CU9, aucune étape supplémentaire n’est nécessaire.

Scénarios de mise à niveau

Sur les clusters existants, le processus de mise à niveau n’appliquera pas de nouveaux chiffrements ni de rechiffrement sur les données utilisateur qui n’étaient pas déjà chiffrées. Ce comportement est dû à la conception et les éléments suivants doivent être pris en compte pour chaque composant :

  • SQL Server

    • Instance maître SQL Server. Le processus de mise à niveau n’affecte aucune base de données d’instance maître ni les certificats TDE installés. Nous vous recommandons de sauvegarder vos bases de données et vos certificats TDE installés manuellement avant le processus de mise à niveau. Nous vous recommandons également de stocker ces artefacts en dehors du cluster Big Data.
    • Pool de calcul et de stockage. Ces bases de données sont managées par le système, volatiles et seront recréées et automatiquement chiffrées lors de la mise à niveau du cluster.
    • Pool de données. La mise à niveau n’a pas d’impact sur les bases de données de la partie Instances SQL du pool de données.

  • HDFS

    Le processus de mise à niveau ne touche pas les fichiers et dossiers HDFS en dehors des zones de chiffrement.

Mise à niveau vers CU9 à partir de CU8 ou d’une version antérieure

Aucune étape supplémentaire n'est nécessaire.

Mise à niveau vers CU8 à partir de CU6 ou d’une version antérieure

Attention

Avant de procéder à la mise à niveau vers Clusters Big Data SQL Server CU8, effectuez une sauvegarde complète de vos données.

Les zones de chiffrement ne seront pas configurées. Le composant KMS Hadoop ne sera pas configuré pour utiliser le service KMS Clusters Big Data. Pour configurer et activer les zones de chiffrement HDFS après la mise à niveau, suivez les instructions de la section suivante.

Activer les zones de chiffrement HDFS après la mise à niveau vers CU8

Si vous avez mis à niveau votre cluster vers CU8 (azdata upgrade) et souhaitez activer des zones de chiffrement HDFS, deux possibilités s’offrent à vous :

  • Exécution du notebook opérationnel Azure Data Studio nommé SOP0128 - Activer des zones de chiffrement HDFS dans des clusters Big Data pour effectuer la configuration.
  • Exécutez les scripts, comme décrit ci-dessous.

Conditions requises :

  • Cluster Active Directory intégré.
  • Azure Data CLI (azdata) configuré et connecté au cluster en mode AD.

Suivez la procédure ci-dessous pour reconfigurer le cluster avec le support des zones de chiffrement.

  1. Après avoir effectué la mise à niveau avec azdata, enregistrez les scripts suivants.

    Exigences d’exécution des scripts :

    • Les deux scripts doivent se trouver dans le même répertoire.
    • kubectl sur le fichier de configuration PATH pour Kubernetes dans le dossier $HOME/.kube.

    Ce script sera appelé run-key-provider-patch.sh :

    #!/bin/bash

if [[ -z "${BDC_DOMAIN}" ]]; then
  echo "BDC_DOMAIN environment variable with the domain name of the cluster is not defined."
  exit 1
fi

if [[ -z "${BDC_CLUSTER_NS}" ]]; then
  echo "BDC_CLUSTER_NS environment variable with the cluster namespace is not defined."
  exit 1
fi

kubectl get configmaps -n test

diff <(kubectl get configmaps mssql-hadoop-storage-0-configmap -n $BDC_CLUSTER_NS -o json | ./updatekeyprovider.py) <(kubectl get configmaps mssql-hadoop-storage-0-configmap -n $BDC_CLUSTER_NS -o json | python -m json.tool)

diff <(kubectl get configmaps mssql-hadoop-sparkhead-configmap -n $BDC_CLUSTER_NS -o json | ./updatekeyprovider.py) <(kubectl get configmaps mssql-hadoop-sparkhead-configmap -n $BDC_CLUSTER_NS -o json | python -m json.tool)

# Replace the config maps.
#
kubectl replace -n $BDC_CLUSTER_NS -o json -f <(kubectl get configmaps mssql-hadoop-storage-0-configmap -n $BDC_CLUSTER_NS -o json | ./updatekeyprovider.py)

kubectl replace -n $BDC_CLUSTER_NS -o json -f <(kubectl get configmaps mssql-hadoop-sparkhead-configmap -n $BDC_CLUSTER_NS -o json | ./updatekeyprovider.py)

# Restart the pods which need to have the necessary changes with the core-site.xml
kubectl delete pods -n $BDC_CLUSTER_NS nmnode-0-0
kubectl delete pods -n $BDC_CLUSTER_NS storage-0-0
kubectl delete pods -n $BDC_CLUSTER_NS storage-0-1

# Wait for sometime for pods to restart
#
sleep 300

# Check for the KMS process status.
#
kubectl exec -n $BDC_CLUSTER_NS -c hadoop nmnode-0-0 -- bash -c 'ps aux | grep kms'
kubectl exec -n $BDC_CLUSTER_NS -c hadoop storage-0-0 -- bash -c 'ps aux | grep kms'
kubectl exec -n $BDC_CLUSTER_NS -c hadoop storage-0-1 -- bash -c 'ps aux | grep kms'

    Ce script sera appelé updatekeyprovider.py :

    #!/usr/bin/env python3

import json
import re
import sys
import xml.etree.ElementTree as ET
import os

class CommentedTreeBuilder(ET.TreeBuilder):
    def comment(self, data):
        self.start(ET.Comment, {})
        self.data(data)
        self.end(ET.Comment)

domain_name = os.environ['BDC_DOMAIN']

parser = ET.XMLParser(target=CommentedTreeBuilder())

core_site = 'core-site.xml'
j = json.load(sys.stdin)
cs = j['data'][core_site]
csxml = ET.fromstring(cs, parser=parser)
props = [prop.find('value').text for prop in csxml.findall(
    "./property/name/..[name='hadoop.security.key.provider.path']")]

kms_provider_path=''

for x in range(5):
    if len(kms_provider_path) != 0:
        kms_provider_path = kms_provider_path + ';'
    kms_provider_path = kms_provider_path + 'nmnode-0-0.' + domain_name

if len(props) == 0:
    prop = ET.SubElement(csxml, 'property')
    name = ET.SubElement(prop, 'name')
    name.text = 'hadoop.security.key.provider.path'
    value = ET.SubElement(prop, 'value')
    value.text = 'kms://https@' + kms_provider_path + ':9600/kms'
    cs = ET.tostring(csxml, encoding='utf-8').decode('utf-8')

j['data'][core_site] = cs

kms_site = 'kms-site.xml.tmpl'
ks = j['data'][kms_site]

kp_uri_regex = re.compile('(<name>hadoop.kms.key.provider.uri</name>\s*<value>\s*)(.*)(\s*</value>)', re.MULTILINE)

def replace_uri(match_obj):
    key_provider_uri = 'bdc://https@hdfsvault-svc.' + domain_name
    if match_obj.group(2) == 'jceks://file@/var/run/secrets/keystores/kms/kms.jceks' or match_obj.group(2) == key_provider_uri:
        return match_obj.group(1) + key_provider_uri + match_obj.group(3)
    return match_obj.group(0)

ks = kp_uri_regex.sub(replace_uri, ks)

j['data'][kms_site] = ks
print(json.dumps(j, indent=4, sort_keys=True))

    Exécutez run-key-provider-patch.sh avec les paramètres appropriés.

Configuration des fournisseurs externes

Comme mentionné dans les sections précédentes, un déploiement de Cluster Big Data CU8+ SQL Server 2019 va activer par défaut la fonctionnalité de chiffrement au repos avec des clés managées par le système. Pour permettre à un fournisseur de clés externes de sécuriser les clés racines du chiffrement de SQL Server et de HDFS, consultez Fournisseurs de clés externes dans Clusters Big Data SQL Server.

Étapes suivantes

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 l’utilisation efficace du chiffrement au repos de Clusters Big Data SQL Server, consultez les articles suivants :

Pour plus d’informations sur les Clusters Big Data SQL Server, consultez la vue d’ensemble suivante :