Conceptos y guía de configuración de cifrado en reposo

Important

Los clústeres de macrodatos de Microsoft SQL Server 2019 se retiran. La compatibilidad con clústeres de macrodatos de SQL Server 2019 finalizó a partir del 28 de febrero de 2025. Para obtener más información, consulte la entrada de blog del anuncio y las opciones de macrodatos en la plataforma de Microsoft SQL Server.

A partir de Microsoft SQL Server 2019 CU8 Big Data Clusters, la característica de cifrado en reposo está disponible para proporcionar cifrado a nivel de aplicación a todos los datos almacenados en la plataforma. En esta guía se describen los conceptos, la arquitectura y la configuración del conjunto de características de cifrado en reposo para clústeres de macrodatos.

Los clústeres de macrodatos de SQL Server almacenan datos en las siguientes ubicaciones:

  • Instancia maestra de SQL Server.
  • HDFS. Usado por el grupo de almacenamiento y Spark.

Hay dos enfoques para cifrar datos de forma transparente en clústeres de macrodatos de SQL Server:

  • Volume encryption. La plataforma de Kubernetes admite este enfoque. Es un procedimiento recomendado para las implementaciones de clústeres de macrodatos. En este artículo no se aborda el cifrado de volumen. Consulte la documentación de la plataforma o dispositivo de Kubernetes para obtener información sobre cómo cifrar correctamente los volúmenes que se usan para clústeres de macrodatos de SQL Server.
  • Cifrado de nivel de aplicación. Esta arquitectura hace referencia al cifrado de datos por parte de la aplicación que controla los datos antes de escribirlos en el disco. En caso de que los volúmenes se expongan, un atacante no podría restaurar artefactos de datos en otro lugar, a menos que el sistema de destino también se haya configurado con las mismas claves de cifrado.

El conjunto de características de cifrado en reposo de clústeres de macrodatos de SQL Server admite el escenario principal de cifrado de nivel de aplicación para los componentes de SQL Server y HDFS.

La característica proporciona las siguientes funcionalidades:

  • Cifrado administrado por el sistema en reposo. Esta funcionalidad está disponible en CU8+.
  • Cifrado administrado por el usuario en reposo, también conocido como bring your own key (BYOK). Las integraciones administradas por servicios se introdujeron en SQL Server 2019 CU8. Las integraciones de proveedores de claves externas se introdujeron en SQL Server 2019 CU11+.

Para obtener más información, vea Versiones clave en clústeres de macrodatos de SQL Server.

Key definitions

  • Servicio de administración de claves de clústeres de macrodatos de SQL Server (KMS)

    Un servicio hospedado por el controlador responsable de administrar claves y certificados para el cifrado en reposo establecido para los clústeres de macrodatos de SQL Server. El servicio admite las siguientes características:

    • Administración segura y almacenamiento de claves y certificados usados para el cifrado en reposo.
    • Compatibilidad con KMS de Hadoop. KMS actúa como el servicio de administración de claves para el componente HDFS en clústeres de macrodatos.
    • Administración de certificados de Cifrado de datos transparente (TDE) de SQL Server.

  • System-managed keys

    El servicio KMS de clústeres de macrodatos administra todas las claves y certificados para SQL Server y HDFS.

  • User-defined keys

    Las claves definidas por el usuario que se van a administrar mediante el KMS de clústeres de macrodatos, comúnmente conocidas como "bring your own key". Los clústeres de macrodatos de SQL Server admiten la definición personalizada de claves que se usarán para el cifrado en componentes de SQL Server y HDFS. El KMS de Clústeres de Big Data administra esas claves.

    Caution

    La instancia maestra de SQL Server hereda la característica TDE de SQL Server. Sin embargo, cargar manualmente claves personalizadas desde archivos en pods, registrarlas en SQL Server y usarlas para TDE no es un escenario admitido. El KMS de clústeres de macrodatos no administrará esas claves. La situación puede provocar que las bases de datos sean ilegibles. Para usar las claves proporcionadas externamente correctamente, use la característica "Proveedores externos" como se describe en este artículo.

  • External providers

    Las soluciones de clave externa compatibles con KMS de clústeres de macrodatos se admiten para la delegación de operaciones de cifrado. Esta característica se admite en SQL Server 2019 CU11+. Con esta característica habilitada, la clave raíz del cifrado se hospeda fuera del controlador de clústeres de macrodatos.

Cifrado en reposo en clústeres de macrodatos de SQL Server

El servicio de controlador kmS de clústeres de macrodatos proporciona compatibilidad con claves administradas por el sistema y claves externas controladas por el proveedor para lograr el cifrado de datos en reposo tanto en SQL Server como en HDFS.

Esas claves y certificados están administradas por el servicio. En este artículo se proporcionan instrucciones operativas sobre cómo interactuar con el servicio.

El conjunto de características presenta el servicio de controlador kmS de clústeres de macrodatos para proporcionar claves administradas por el sistema y certificados para el cifrado de datos en reposo tanto en SQL Server como en HDFS. Esas claves y certificados están administradas por el servicio. En este artículo se proporcionan instrucciones operativas sobre cómo interactuar con el servicio.

  • Las instancias de SQL Server usan la funcionalidad establecida de cifrado de datos transparente (TDE).
  • HDFS utiliza el KMS nativo de Hadoop dentro de cada pod para interactuar con el KMS de Clústeres de Datos Masivos en el controlador. Este enfoque habilita las zonas de cifrado de HDFS, que proporcionan rutas de acceso seguras en HDFS.

Instancias de SQL Server

  • Se instala un certificado generado por el sistema en pods de SQL Server que se usarán con comandos TDE. El estándar de nomenclatura de certificados administrados por el sistema es TDECertificate + timestamp. Por ejemplo: TDECertificate2020_09_15_22_46_27.
  • Los clústeres de macrodatos de instancia maestra aprovisionados y las bases de datos de usuario no se cifrarán automáticamente. Los administradores de bases de datos pueden usar el certificado instalado para cifrar cualquier base de datos.
  • El grupo de proceso y el grupo de almacenamiento se cifran automáticamente mediante el certificado generado por el sistema.
  • El cifrado del grupo de datos, aunque técnicamente es posible mediante comandos T-SQL EXECUTE AT , no se recomienda y no se admite en este momento. El uso de esta técnica para cifrar las bases de datos del grupo de datos podría no ser eficaz y es posible que el cifrado no se produzca en el estado deseado. El enfoque también crea una ruta de actualización incompatible para las próximas versiones.
  • La rotación de claves de SQL Server se logra mediante comandos administrativos de T-SQL estándar. Para obtener más información, consulte Clústeres de Big Data de SQL Server - Guía de uso de Cifrado Transparente de Datos (TDE) en reposo.
  • La supervisión del cifrado se realiza a través de las DMV de SQL Server estándar existentes para TDE.
  • Se admite la copia de seguridad y restauración de una base de datos habilitada para TDE en el clúster.
  • Se admite la alta disponibilidad. Si se cifra una base de datos en la instancia principal de SQL Server, también se cifrará toda la réplica secundaria de la base de datos.

Zonas de cifrado HDFS

  • La integración de Active Directory es necesaria para habilitar zonas de cifrado para HDFS.
  • Se aprovisiona una clave generada por el sistema en KMS de Hadoop. El nombre de clave es securelakekey. En CU8, la clave predeterminada es de 256 bits y se admite el cifrado AES de 256 bits.
  • Se aprovisiona una zona de cifrado predeterminada mediante la clave generada por el sistema anterior en una ruta de acceso denominada /securelake.
  • Los usuarios pueden crear otras claves y zonas de cifrado mediante instrucciones específicas proporcionadas en esta guía. Los usuarios pueden elegir el tamaño de clave de 128, 192 o 256 durante la creación de claves.
  • La rotación de claves de zonas de cifrado de HDFS se logra mediante azdata. Para más información, consulte Guía de uso de zonas de cifrado de HDFS para clústeres de macrodatos de SQL Server.
  • No se admite la jerarquización de HDFS montándose sobre una zona de cifrado.

Administración de cifrado en reposo

La lista siguiente contiene las funcionalidades de administración para el cifrado en reposo:

  • La administración de TDE de SQL Server se realiza mediante comandos T-SQL estándar.
  • Las zonas de cifrado de HDFS y la administración de claves de HDFS se realizan mediante azdata comandos.
  • Las siguientes características de administración se realizan mediante Cuadernos operativos:
    • Copia de seguridad y recuperación de claves de HDFS
    • Eliminación de claves HDFS

Configuration guide

Durante las nuevas implementaciones de clústeres de macrodatos de SQL Server, CU8 en adelante, el cifrado en reposo se habilitará y configurará de forma predeterminada. That means:

  • Los componentes de KMS de clústeres de macrodatos se implementan en el controlador y generan un conjunto predeterminado de claves y certificados.
  • SQL Server se implementa con TDE activado y el controlador instala los certificados.
  • KMS de Hadoop para HDFS está configurado para interactuar con KMS de Big Data Clusters para operaciones de cifrado. Las zonas de cifrado de HDFS están configuradas y listas para usarse.

Se aplican los requisitos y los comportamientos predeterminados descritos en la sección anterior.

Si realiza una nueva implementación de clústeres de macrodatos de SQL Server CU8 en adelante o actualiza directamente a CU9, no se requieren otros pasos.

Upgrade scenarios

En los clústeres existentes, el proceso de actualización no impondrá el nuevo cifrado ni el recifrado en los datos de usuario que no estaban ya cifrados. Este comportamiento es por diseño y se deben tener en cuenta los siguientes problemas por componente:

  • SQL Server

    • Instancia maestra de SQL Server. El proceso de actualización no afectará a ninguna base de datos de instancia maestra ni a los certificados TDE instalados. Se recomienda realizar una copia de seguridad de las bases de datos y los certificados TDE instalados manualmente antes del proceso de actualización. También se recomienda almacenar esos artefactos fuera del clúster de macrodatos.
    • Grupo de cómputo y almacenamiento. Esas bases de datos son administradas por el sistema, volátiles y se vuelven a crear y cifran automáticamente en la actualización del clúster.
    • Data pool. La actualización no afecta a las bases de datos en las instancias de SQL Server del pool de datos.

  • HDFS

    El proceso de actualización no tocará archivos y carpetas de HDFS fuera de las zonas de cifrado.

Actualización a CU9 desde CU8 o versiones anteriores

No es necesario ningún paso más.

Actualización a CU8 desde CU6 o versiones anteriores

Caution

Antes de actualizar a clústeres de macrodatos de SQL Server CU8, realice una copia de seguridad completa de los datos.

Las zonas de cifrado no se configurarán. El componente KMS de Hadoop no se configurará para usar el KMS de clústeres de datos masivos. Para configurar y habilitar zonas de cifrado de HDFS después de la actualización, siga las instrucciones de la sección siguiente.

Habilitación de zonas de cifrado de HDFS después de la actualización a CU8

Si ha actualizado el clúster a CU8 (azdata upgrade) y quiere habilitar zonas de cifrado de HDFS, hay dos opciones:

  • Ejecución del cuaderno operativo de Azure Data Studio denominado SOP0128: habilite las zonas de cifrado de HDFS en clústeres de macrodatos para realizar la configuración.
  • Ejecute los scripts, como se describe a continuación.

Requirements:

Siga este procedimiento para volver a configurar el clúster con compatibilidad con zonas de cifrado.

  1. Después de realizar la actualización con azdata, guarde los siguientes scripts.

    Requisitos de ejecución de scripts:

    • Ambos scripts deben encontrarse en el mismo directorio.
    • kubectl en el archivo de configuración PATH para Kubernetes en la carpeta $HOME/.kube.

    Este script debe denominarse 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 debe denominarse 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))

    Ejecute run-key-provider-patch.sh con los parámetros adecuados.

Configuración de proveedores externos

Como se mencionó en las secciones anteriores, una implementación de clústeres de macrodatos de SQL Server 2019 CU8+ permite la funcionalidad de cifrado en reposo con claves administradas por el sistema de forma predeterminada. Para permitir que un proveedor de claves externas proteja las claves raíz del cifrado de SQL Server y HDFS, consulte Proveedores de claves externas en clústeres de macrodatos de SQL Server.

Next steps

Para obtener más información sobre cómo se usan las versiones clave en clústeres de macrodatos de SQL Server, consulte Versiones de claves en clústeres de macrodatos de SQL Server.

Para obtener más información sobre cómo usar de forma eficaz el cifrado en reposo en clústeres de macrodatos de SQL Server, consulte los artículos siguientes:

Para obtener más información sobre Clústeres de macrodatos de SQL Server, vea la siguiente introducción:

  • Last updated on