Share via

Guia de configuração e conceitos de criptografia em repouso

  • Artigo

Importante

O complemento Clusters de Big Data do Microsoft SQL Server 2019 será desativado. O suporte para Clusters de Big Data do SQL Server 2019 será encerrado em 28 de fevereiro de 2025. Todos os usuários existentes do SQL Server 2019 com Software Assurance terão suporte total na plataforma e o software continuará a ser mantido por meio de atualizações cumulativas do SQL Server até esse momento. Para obter mais informações, confira a postagem no blog de anúncio e as opções de Big Data na plataforma do Microsoft SQL Server.

Começando com os Clusters de Big Data do Microsoft SQL Server 2019 CU8, o recurso de criptografia em repouso está disponível para fornecer criptografia em nível de aplicativo a todos os dados armazenados na plataforma. Este guia descreve os conceitos, a arquitetura e a configuração do conjunto de recursos de criptografia em repouso para Clusters de Big Data.

Os Clusters de Big Data do SQL Server armazenam dados nos seguintes locais:

  • Instância mestra do SQL Server.
  • HDFS. Usado pelo pool de armazenamento e pelo Spark.

Há duas abordagens para poder criptografar dados de modo transparente em Clusters de Big Data do SQL Server:

  • Criptografia de volume. A plataforma Kubernetes dá suporte a essa abordagem. É uma melhor prática para implantações de Clusters de Big Data. Este artigo não abrange a criptografia de volume. Consulte a documentação da plataforma Kubernetes ou do dispositivo para saber como criptografar corretamente os volumes que são usados para Clusters de Big Data do SQL Server.
  • Criptografia no nível de aplicativo. Essa arquitetura refere-se à criptografia de dados pelo aplicativo que manipula os dados antes que eles sejam gravados no disco. Caso os volumes fossem expostos, um invasor não conseguiria restaurar os artefatos de dados em outro lugar, a menos que o sistema de destino também tenha sido configurados com as mesmas chaves de criptografia.

O conjunto de recursos de criptografia em repouso dos Clusters de Big Data do SQL Server dá suporte ao cenário principal de criptografia no nível do aplicativo dos componentes do SQL Server e do HDFS.

O recurso fornece as seguintes funcionalidades:

  • Criptografia em repouso gerenciada pelo sistema. Essa funcionalidade está disponível apenas no CU8+.
  • Criptografia gerenciada pelo usuário em repouso, também conhecido como BYOK (traga sua própria chave). As integrações gerenciadas pelo serviço foram introduzidas na CU8 do SQL Server 2019. As integrações de provedor de chaves externas foram introduzidas na CU11+ do SQL Server 2019.

Para obter mais informações, confira Versões de Chave em Clusters de Big Data do SQL Server.

Definições importantes

  • KMS (Serviço de Gerenciamento de Chaves) de Clusters de Big Data do SQL Server

    Um serviço hospedado pelo controlador responsável por gerenciar chaves e certificados para o conjunto de recursos de criptografia em repouso para Clusters de Big Data do SQL Server. O serviço dá suporte aos seguintes recursos:

    • Gerenciamento seguro e armazenamento de chaves e certificados usados para criptografia em repouso.
    • Compatibilidade de KMS do Hadoop. O KMS atua como o serviço de gerenciamento de chaves para o componente HDFS nos Clusters de Big Data.
    • Gerenciamento de certificados TDE (Transparent Data Encryption) do SQL Server.

  • Chaves gerenciadas pelo sistema

    O serviço KMS dos Clusters de Big Data gerenciará todas as chaves e certificados do SQL Server e do HDFS

  • Chaves definidas pelo usuário

    As chaves definidas pelo usuário que serão gerenciadas pelo KMS dos Clusters de Big Data, normalmente conhecido como traga sua própria chave. Os Clusters de Big Data do SQL Server dá suporte à definição personalizada de chaves a serem usadas para criptografia em componentes do SQL Server e do HDFS. O KMS dos Clusters de Big Data gerencia essas chaves.

    Cuidado

    A instância mestra do SQL Server herda o recurso TDE (Transparent Data Encryption) do SQL Server. No entanto, carregar manualmente chaves personalizadas de arquivos para pods, registrá-las no SQL Server e usá-las para TDE não é um cenário possível. O KMS dos Clusters de Big Data não gerenciará essas chaves. A situação pode fazer com que seus bancos de dados fiquem ilegíveis. Para usar corretamente as chaves externas fornecidas, use o recurso "Provedores externos", conforme descrito neste artigo.

  • Provedores externos

    Há suporte para soluções de chave externa compatíveis com o KMS dos Clusters de Big Data para delegação de operação de criptografia. Há suporte para esse recurso no SQL Server 2019 CU11+. Com esse recurso habilitado, a chave raiz da criptografia está hospedada fora do Controlador dos Clusters de Big Data.

Criptografia em repouso em Clusters de Big Data do SQL Server

O serviço de controlador do KMS dos Clusters de Big Data dá suporte a chaves gerenciadas pelo sistema e chaves controladas por provedor externo para obter criptografia de dados em repouso no SQL Server e no HDFS.

Essas chaves e certificados são gerenciados por serviço. Este artigo fornece diretrizes operacionais sobre como interagir com o serviço.

O conjunto de recursos apresenta o serviço controlador de KMS dos Clusters de Big Data para fornecer chaves gerenciadas pelo sistema e certificados para criptografia de dados em repouso no SQL Server e no HDFS. Essas chaves e certificados são gerenciados por serviço. Este artigo fornece diretrizes operacionais sobre como interagir com o serviço.

  • As instâncias do SQL Server usam a funcionalidade de TDE (Transparent Data Encryption) estabelecida.
  • O HDFS usa o KMS nativo do Hadoop em cada pod para interagir com o KMS dos Clusters de Big Data no controlador. Essa abordagem habilita as zonas de criptografia do HDFS, que fornecem caminhos seguros no HDFS.

Instâncias do SQL Server

  • Um certificado gerado pelo sistema é instalado em pods do SQL Server para ser usado com comandos de TDE. O padrão de nomenclatura de certificado gerenciado pelo sistema é TDECertificate + timestamp. Por exemplo, TDECertificate2020_09_15_22_46_27.
  • Bancos de dados provisionados pelos Clusters de Big Data da instância mestra e bancos de dados do usuário não serão criptografados automaticamente. Os administradores de banco de dados podem usar o certificado instalado para criptografar qualquer banco de dados.
  • O pool de computação e o pool de armazenamento são criptografados automaticamente usando o certificado gerado pelo sistema.
  • A criptografia do pool de dados, embora tecnicamente possível usando comandos EXECUTE AT de T-SQL, é desencorajada e não é compatível no momento. O uso dessa técnica para criptografar os bancos de dados do pool pode não ser eficaz e a criptografia pode não estar ocorrendo no estado desejado. Essa abordagem também cria um caminho de atualização incompatível para as próximas versões.
  • A rotação de chaves do SQL Server é obtida usando comandos administrativos T-SQL padrão. Para obter mais informações, confira o Guia de uso da TDE (Transparent Data Encryption) em repouso de Clusters de Big Data do SQL Server.
  • O monitoramento de criptografia ocorre por meio de DMVs de SQL Server padrão existentes para TDE.
  • O backup e a restauração de um banco de dados habilitado para TDE no cluster são suportados.
  • Há suporte para alta disponibilidade. Se um banco de dados na instância primária do SQL Server for criptografado, todas as réplicas secundárias do banco de dados também são criptografadas.

Zonas de criptografia de HDFS

  • A integração do Active Directory é necessária para habilitar as zonas de criptografia no HDFS.
  • Uma chave gerada pelo sistema é provisionada no KMS do Hadoop. O nome da chave é securelakekey. No CU8, a chave padrão é de 256 bits e damos suporte à criptografia AES de 256 bits.
  • Uma zona de criptografia padrão é provisionada usando a chave gerada pelo sistema acima em um caminho chamado /securelake.
  • Os usuários podem criar outras chaves e zonas de criptografia usando as instruções específicas fornecidas neste guia. Durante a criação da chave, os usuários podem escolher o tamanho de 128, 192 ou 256 para ela.
  • A rotação de chaves de Zonas de Criptografia do HDFS é obtida usando o azdata. Para obter mais informações, confira o Guia de uso de zonas de criptografia do HDFS de Clusters de Big Data do SQL Server.
  • Executar a montagem de camadas do HDFS na parte superior de uma zona de criptografia não é suportada.

Administração da criptografia em repouso

A lista a seguir contém as funcionalidades de administração para criptografia em repouso:

  • O gerenciamento de TDE do SQL Server é executado usando comandos T-SQL padrão.
  • As Zonas de criptografia do HDFS e o gerenciamento de chaves do HDFS são executados usando comandos azdata.
  • Os seguintes recursos de administração são executados usando os Notebooks Operacionais:
    • Backup e recuperação de chaves do HDFS
    • Exclusão de chave do HDFS

Guia de configuração

Durante novas implantações de Clusters de Big Data do SQL Server, do CU8 em diante, a criptografia em repouso será habilitada e configurada por padrão. Isso significa que:

  • Os componentes KMS dos Clusters de Big Data são implantados no controlador e geram um conjunto padrão de chaves e certificados.
  • O SQL Server é implantado com o TDE ativado e os certificados são instalados pelo controlador.
  • O KMS do Hadoop para HDFS é configurado para interagir com o KMS dos Clusters de Big Data nas operações de criptografia. As zonas de criptografia do HDFS estão configuradas e prontas para uso.

Os requisitos e os comportamentos padrão descritos na seção anterior se aplicam.

Se estiver executando uma nova implantação dos Clusters de Big Data do SQL Server versão CU8 ou posterior ou estiver atualizando diretamente para a CU9, nenhuma outra etapa será necessária.

Cenários de atualização

Em clusters existentes, o processo de atualização não impõe uma nova criptografia ou criptografa os dados do usuário que ainda não foram criptografados. Esse comportamento é adotado por design e os seguintes problemas precisam ser considerado por componente:

  • SQL Server

    • Instância mestra do SQL Server. O processo de atualização não afetará nenhum banco de dados da instância mestra e os certificados TDE instalados. Recomendamos que você faça backup dos bancos de dados e dos certificados TDE instalados manualmente antes do processo de atualização. Também recomendamos que você armazene esses artefatos fora do cluster de Big Data.
    • Computação e pool de armazenamento. Esses bancos de dados são gerenciados pelo sistema, voláteis e são recriados e criptografados automaticamente na atualização do cluster.
    • Pool de dados. A atualização não afeta os bancos de dados na parte de instâncias do SQL Server do pool de dados.

  • HDFS

    O processo de atualização não tocará arquivos e pastas do HDFS fora das zonas de criptografia.

Como atualizar da versão CU8 ou anterior para a CU9

Não são necessárias outras etapas.

Como atualizar da versão CU6 ou anterior para a CU8

Cuidado

Antes de atualizar para os Clusters de Big Data do SQL Server CU8, execute um backup completo dos seus dados.

As zonas de criptografia não serão configuradas. O componente KMS do Hadoop não será configurado para usar o KMS dos Clusters de Big Data. Para configurar e habilitar as zonas de criptografia do HDFS após a atualização, siga as instruções na próxima seção.

Habilitar zonas de criptografia do HDFS após a atualização para a CU8

Se você atualizou o cluster para CU8 (azdata upgrade) e deseja habilitar as zonas de criptografia do HDFS, há duas opções:

  • Execução do Notebook Operacional do Azure Data Studio chamado SOP0128 – Habilitar zonas de criptografia do HDFS em clusters de Big Data para executar a configuração.
  • Execute os scripts, conforme descrito abaixo.

Requisitos:

  • Um cluster integrado ao Active Directory.
  • CLI de Dados do Azure (azdata) configurado e conectado ao cluster no modo AD.

Siga este procedimento para reconfigurar o cluster com suporte a zonas de criptografia.

  1. Depois de executar a atualização com azdata, salve os scripts a seguir.

    Requisitos de execução de scripts:

    • Ambos os scripts devem estar localizados no mesmo diretório.
    • kubectl no arquivo de configuração PATH para Kubernetes na pasta $HOME/.kube.

    Este script deve ser nomeado 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'

    Este script deve ser nomeado 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))

    Execute run-key-provider-patch.sh com os parâmetros apropriados.

Configuração de provedores externos

Conforme mencionado nas seções anteriores, uma implantação do Cluster de Big Data do SQL Server 2019 CU8+ habilita a funcionalidade de criptografia em repouso com chaves gerenciadas pelo sistema por padrão. Para habilitar um provedor de chaves externas para proteger as chaves raiz de criptografia do SQL Server e do HDFS, confira Provedores de Chaves Externas nos Clusters de Big Data do SQL Server.

Próximas etapas

Para saber mais sobre como as principais versões são usadas em Clusters de Big Data do SQL Server, confira Versões principais em Clusters de Big Data do SQL Server.

Para saber mais sobre como usar efetivamente a criptografia em repouso Clusters de Big Data do SQL Server, confira os seguintes artigos:

Para saber mais sobre o Clusters de Big Data do SQL Server, confira a visão geral a seguir: