Concetti sulla crittografia dei dati inattivi e guida alla configurazione

A partire dai cluster Big Data di Microsoft SQL Server 2019 CU8 è disponibile la funzionalità di crittografia dei dati inattivi che consente di usare la crittografia a livello di applicazione a tutti i dati archiviati nella piattaforma. Questa guida illustra i concetti, l'architettura e la configurazione del set di funzionalità di crittografia dei dati inattivi per i cluster Big Data di SQL Server.

Nei cluster Big Data di SQL Server i dati vengono archiviati nelle due posizioni seguenti:

• Istanza master di SQL Server.
• HDFS. Usato dal pool di archiviazione e Spark.

Per crittografare in modo trasparente i dati in cluster Big Data di SQL Server, è possibile adottare due approcci:

• Crittografia dei volumi. La piattaforma Kubernetes supporta questo approccio. È una procedura consigliata per le distribuzioni di cluster Big Data. Questo articolo non riguarda la crittografia dei volumi. Per informazioni su come crittografare correttamente i volumi usati per i cluster Big Data di SQL Server, leggere la documentazione relativa all'appliance o alla piattaforma Kubernetes.
• Crittografia a livello di applicazione. Questa architettura si riferisce alla crittografia dei dati da parte dell'applicazione che gestisce i dati prima che vengano scritti su disco. Nel caso in cui i volumi siano esposti, per un utente malintenzionato sarebbe impossibile ripristinare gli elementi dati in un'altra posizione, a meno che il sistema di destinazione non sia stato configurato con le stesse chiavi di crittografia.

Il set di funzionalità di crittografia dei dati inattivi nei cluster Big Data di SQL Server supporta lo scenario principale della crittografia a livello di applicazione per i componenti SQL Server e HDFS.

La funzionalità offre le seguenti capacità:

• Crittografia dei dati inattivi gestita dal sistema. Questa funzionalità è disponibile in CU8+.
• Crittografia gestita dall'utente inattiva, nota anche come bring your own key (BYOK). Le integrazioni gestite dal servizio sono state introdotte in SQL Server 2019 CU8. Le integrazioni del provider di chiavi esterne sono state introdotte in SQL Server 2019 CU11+.

Per altre informazioni, vedere Versioni delle chiavi nei cluster Big Data di SQL Server.

Definizioni chiave

• Servizio di gestione delle chiavi di cluster Big Data di SQL Server

  Si tratta di un servizio ospitato nel controller, responsabile della gestione delle chiavi e dei certificati per il set di funzionalità di crittografia dei dati inattivi per i cluster Big Data di SQL Server. Il servizio supporta le funzionalità seguenti:

  • Gestione e archiviazione sicure di chiavi e certificati usati per la crittografia dei dati inattivi.
  • Compatibilità del servizio di gestione delle chiavi Hadoop. Il servizio di gestione delle chiavi viene usato come servizio di gestione delle chiavi per il componente HDFS nei cluster Big Data.
  • Gestione dei certificati Transparent Data Encryption (TDE) di SQL Server.

• Chiavi gestite dal sistema

  Il servizio di gestione delle chiavi dei cluster Big Data gestisce tutte le chiavi e i certificati per SQL Server e HDFS.

• Chiavi definite dall'utente

  Il servizio di gestione delle chiavi dei cluster Big Data gestisce le chiavi definite dall'utente, noto anche come bring your own key (BYOK). I cluster Big Data di SQL Server supportano la definizione personalizzata delle chiavi da usare per la crittografia nei componenti SQL Server e HDFS. Il servizio di gestione delle chiavi dei cluster Big Data gestisce tali chiavi.

  Attenzione

  L'istanza master di SQL Server eredita la funzionalità TDE di SQL Server. Tuttavia, il caricamento manuale delle chiavi personalizzate dai file nei pod, la registrazione in SQL Server e l'uso di tali chiavi per TDE non è uno scenario supportato. Il servizio di gestione delle chiavi dei cluster Big Data non gestirà tali chiavi. La situazione può comportare l'impossibilità di lettura dei database. Per usare correttamente le chiavi fornite esterne, usare la funzionalità "Provider esterni" come descritto in questo articolo.

• Provider esterni

  Le soluzioni delle chiavi esterne compatibili con il servizio di gestione delle chiavi dei cluster Big Data sono supportate per la delega dell'operazione di crittografia. Questa funzionalità è supportata in SQL Server 2019 CU11+. Con questa funzionalità abilitata, la chiave radice della crittografia è ospitata all'esterno del controller dei cluster Big Data.

Crittografia dei dati inattivi in cluster Big Data di SQL Server

Il servizio controller del servizio di gestione delle chiavi dei cluster Big Data offre supporto per le chiavi gestite dal sistema e chiavi controllate dal provider esterno per ottenere la crittografia dei dati inattivi sia in SQL Server che in HDFS.

Tali chiavi e certificati sono gestiti dal servizio. Questo articolo fornisce indicazioni operative su come interagire con il servizio.

Il set di funzionalità introduce il servizio controller del servizio di gestione delle chiavi dei cluster Big Data che offre chiavi e certificati gestiti dal sistema per la crittografia dei dati inattivi sia in SQL Server che in HDFS. Tali chiavi e certificati sono gestiti dal servizio. Questo articolo fornisce indicazioni operative su come interagire con il servizio.

• Le istanze di SQL Server usano la funzionalità Transparent Data Encryption (TDE) stabilita.
• HDFS usa il servizio di gestione delle chiavi Hadoop nativo all'interno di ogni pod per interagire con il servizio di gestione delle chiavi dei cluster Big Data nel controller. Questo approccio abilita zone di crittografia HDFS, che offrono percorsi sicuri in HDFS.

Istanze di SQL Server

• Nei pod di SQL Server viene installato un certificato generato dal sistema da usare con i comandi TDE. Lo standard di denominazione del certificato gestito dal sistema è TDECertificate + timestamp. Ad esempio, TDECertificate2020_09_15_22_46_27.
• I database con provisioning dei cluster Big Data dell'istanza master e i database utente non vengono crittografati automaticamente. Gli amministratori di database possono usare il certificato installato per crittografare qualsiasi database.
• Il pool di calcolo e il pool di archiviazione vengono crittografati automaticamente usando il certificato generato dal sistema.
• La crittografia del pool di dati, anche se tecnicamente possibile tramite i comandi EXECUTE AT di T-SQL, non è consigliata e non è attualmente supportata. Usare questa tecnica per crittografare i database dei pool di dati potrebbe non essere efficace e la crittografia potrebbe non essere eseguita allo stato desiderato. Questo approccio crea anche un percorso di aggiornamento incompatibile per le versioni successive.
• La rotazione delle chiavi di SQL Server viene ottenuta usando i comandi amministrativi T-SQL standard. Per altre informazioni, vedere Guida all'uso della funzione Transparent Data Encryption (TDE) di dati inattivi per i cluster Big Data di SQL Server.
• Il monitoraggio della crittografia avviene tramite le DMV standard di SQL Server per TDE.
• Backup e ripristino di un database abilitato per TDE nel cluster.
• La disponibilità elevata è supportata. Se un database nell'istanza primaria di SQL Server viene crittografato, verrà crittografata anche tutta la replica secondaria del database.

Zone di crittografia HDFS

• Per abilitare la funzionalità delle zone di crittografia per HDFS, è necessaria l'integrazione di Active Directory.
• Nel servizio di gestione delle chiavi Hadoop viene effettuato il provisioning di una chiave generata dal sistema. Il nome della chiave è securelakekey. In CU8 la chiave predefinita è di 256 bit. È supportata la crittografia AES a 256 bit.
• Viene eseguito il provisioning di una zona di crittografia predefinita usando la chiave generata dal sistema precedente in un percorso denominato /securelake.
• Gli utenti possono creare altre chiavi e zone di crittografia usando le istruzioni specifiche disponibili in questa guida. Gli utenti possono scegliere le dimensioni della chiave (128, 192 o 256) durante la creazione della chiave.
• La rotazione della chiave delle zone di crittografia HDFS si ottiene usando azdata. Per altre informazioni, vedere Guida all'uso delle zone di crittografia HDFS in cluster Big Data di SQL Server.
• Non è supportato il montaggio per la suddivisione in livelli HDFS su una zona di crittografia.

Amministrazione della crittografia dei dati inattivi

L'elenco seguente contiene le funzionalità di amministrazione per la crittografia dei dati inattivi:

• La gestione di TDE di SQL Server viene eseguita usando i comandi T-SQL standard.
• La gestione delle zone di crittografia HDFS e delle chiavi HDFS viene eseguita usando i comandi azdata.
• Le funzionalità di amministrazione seguenti vengono eseguite usando i notebook operativi:
  • Backup e ripristino delle chiavi HDFS
  • Eliminazione delle chiavi HDFS

Guida alla configurazione

Durante le nuove distribuzioni di cluster Big Data di SQL Server (CU8 e versioni successive), la crittografia dei dati inattivi verrà abilitata e configurata per impostazione predefinita. Ciò significa che:

• I componenti del servizio di gestione delle chiavi del cluster Big Data vengono distribuiti nel controller e generano un set predefinito di chiavi e certificati.
• SQL Server viene distribuito con TDE abilitato e i certificati vengono installati dal controller.
• Il servizio di gestione delle chiavi Hadoop (per HDFS) viene configurato per interagire con il servizio di gestione delle chiavi del cluster Big Data per le operazioni di crittografia. Le zone di crittografia HDFS sono configurate e pronte per l'uso.

Vengono applicati i requisiti e i comportamenti predefiniti descritti nella sezione precedente.

Se si esegue una nuova distribuzione dei cluster Big Data di SQL Server CU8 e versioni successive o si esegue l'aggiornamento direttamente a CU9, non sono necessari altri passaggi.

Scenari di aggiornamento

Nei cluster esistenti il processo di aggiornamento non applica la nuova crittografia o la ricrittografia nei dati utente che non sono stati già crittografati. Questo comportamento è dovuto alla progettazione ed è necessario considerare quanto segue per ogni componente:

• SQL Server

  • Istanza master di SQL Server. Il processo di aggiornamento non influisce sui database dell'istanza master e sui certificati TDE installati. È consigliabile eseguire il backup dei database e dei certificati TDE installati manualmente prima del processo di aggiornamento. È anche consigliabile archiviare tali elementi all'esterno del cluster Big Data.
  • Pool di calcolo e di archiviazione. Questi database sono gestiti dal sistema, sono volatili e vengono ricreati e crittografati automaticamente durante l'aggiornamento del cluster.
  • Pool di dati. L'aggiornamento non ha effetti sui database nella parte dei pool di dati nelle istanze di SQL Server.

• HDFS

  Il processo di aggiornamento non interessa i file e le cartelle HDFS al di fuori delle zone di crittografia.

Aggiornamento a CU9 da CU8 o versioni precedenti

Non sono necessari altri passaggi.

Aggiornamento a CU8 da CU6 o versioni precedenti

Le zone di crittografia non verranno configurate. Il componente del servizio di gestione delle chiavi Hadoop non viene configurato per usare il servizio di gestione delle chiavi dei cluster Big Data. Per configurare e abilitare le zone di crittografia HDFS dopo l'aggiornamento, seguire le istruzioni nella sezione successiva.

Abilitare le zone di crittografia HDFS dopo l'aggiornamento a CU8

Se il cluster è stato aggiornato a CU8 (azdata upgrade) e si vogliono abilitare le zone di crittografia HDFS, sono disponibili due opzioni:

• Esecuzione del notebook operativo di Azure Data Studio denominato SOP0128 - Abilitare le zone di crittografia HDFS in cluster Big Data per eseguire la configurazione.
• Eseguire gli script, come descritto di seguito.

Requisiti:

• Cluster integrato di Active Directory.
• Interfaccia della riga di comando di Azure Data (azdata) configurata e registrata nel cluster in modalità AD.

Per riconfigurare il cluster con il supporto delle zone di crittografia, seguire questa procedura.

1. Dopo aver eseguito l'aggiornamento con azdata, salvare gli script seguenti.

   Requisiti di esecuzione degli script:

   • Entrambi gli script devono trovarsi nella stessa directory.
   • kubectl nel file di configurazione PATH per Kubernetes nella cartella $HOME/.kube.

   Questo script deve essere denominato 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'
   

   Questo script deve essere denominato 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))
   

   Eseguire run-key-provider-patch.sh con i parametri appropriati.

Configurazione di provider esterni

Come accennato nelle sezioni precedenti, per impostazione predefinita, una distribuzione del cluster Big Data di SQL Server 2019 CU8+ consente la crittografia dei dati inattivi con chiavi gestite dal sistema. Per consentire a un provider di chiavi esterne di proteggere le chiavi radice della crittografia di SQL Server e HDFS, vedere Provider di chiavi esterne nei cluster Big Data di SQL Server.

Passaggi successivi

Per altre informazioni sul modo in cui vengono usate le versioni delle chiavi nei cluster Big Data di SQL Server, vedere Versioni delle chiavi nei cluster Big Data di SQL Server.

Per altre informazioni su come usare in modo efficace la crittografia dei dati inattivi in cluster Big Data di SQL Server, vedere gli articoli seguenti:

• Crittografia dei dati inattivi - TDE di SQL Server
• Crittografia dei dati inattivi - Zone di crittografia HDFS

Per altre informazioni sui cluster Big Data di SQL Server, vedere l'articolo di panoramica seguente:

• Introduzione ai cluster Big Data di SQL Server 2019