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

Artículo
03/20/2023

Importante

El complemento Clústeres de macrodatos de Microsoft SQL Server 2019 se va a retirar. La compatibilidad con Clústeres de macrodatos de SQL Server 2019 finalizará el 28 de febrero de 2025. Todos los usuarios existentes de SQL Server 2019 con Software Assurance serán totalmente compatibles con la plataforma, y el software se seguirá conservando a través de actualizaciones acumulativas de SQL Server hasta ese momento. Para más información, consulte la entrada de blog sobre el anuncio y Opciones de macrodatos en la plataforma Microsoft SQL Server.

A partir de los Clústeres de macrodatos de Microsoft SQL Server 2019 CU8, hay disponible una característica de cifrado en reposo para proporcionar cifrado de nivel de aplicación a todos los datos almacenados en la plataforma. En esta guía describe los conceptos, la arquitectura y la configuración del conjunto de características de cifrado en reposo para Clústeres de macrodatos.

La plataforma Clústeres de macrodatos de SQL Server almacena datos en estas ubicaciones:

Instancia maestra de SQL Server.
HDFS. Usado por bloque de almacenamiento y Spark.

Hay dos enfoques para poder cifrar datos de manera transparente en Clústeres de macrodatos de SQL Server:

Cifrado de volumen. La plataforma kubernetes admite este enfoque. Es un procedimiento recomendado para Clústeres de macrodatos implementaciones. En este artículo no se trata el cifrado de volúmenes. Consulte la documentación de su plataforma o dispositivo Kubernetes para saber 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 que se escriban en el disco. En caso de que se expongan los volúmenes, un atacante no podrá restaurar los artefactos de datos en ningún 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 ofrece las siguientes funcionalidades:

Cifrado de reposo administrado por el sistema. 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, consulte Versiones de clave en Clústeres de macrodatos de SQL Server.

Definiciones clave

Servicios de administración de claves (KMS) de Clústeres de macrodatos de SQL Server

Un servicio hospedado de controlador responsable de administrar claves y certificados para el conjunto de características de cifrado en reposo para Clústeres de macrodatos de SQL Server. El servicio admite las siguientes características:
- Administración y almacenamiento seguros de claves y certificados usados para el cifrado en reposo.
- Compatibilidad con KMS de Hadoop. KMS actúa como servicio de administración de claves para el componente HDFS en los Clústeres de macrodatos.
- Administración de certificados de cifrado de datos transparente (TDE) de SQL Server.
Claves administradas por el sistema

El servicio KMS de Clústeres de macrodatos administrará todas las claves y certificados para SQL Server y HDFS.
Claves definidas por el usuario

Claves definidas por el usuario que se administrarán mediante KMS de Clústeres de macrodatos, lo que comúnmente se conoce 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 macrodatos gestiona esas claves.

Precaución

La instancia maestra de SQL Server hereda la característica de TDE de SQL Server. Aun así, no se permite cargar manualmente claves personalizadas de archivos en pods, registrarlas en SQL Server ni usarlas para TDE. El KMS de Clústeres de macrodatos no administrará esas claves. La situación puede llevar a que sus bases de datos sean ilegibles. Para usar de forma correcta las claves proporcionadas externamente, use la característica "Proveedores externos" como se describe en este artículo.
Proveedores externos

Se admite el uso de soluciones de claves externas compatibles con KMS de Clústeres de macrodatos para la delegación de operaciones de cifrado. Esta característica es compatible con 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 de 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 en SQL Server y HDFS.

Esas claves y certificados son 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 brindar claves y certificados administrados por el sistema para el cifrado de datos en reposo tanto en SQL Server como en HDFS. Esas claves y certificados son 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 Cifrado de dados transparente (TDE).
HDFS usa KMS de Hadoop nativo dentro de cada pod para interactuar con KMS de Clústeres de macrodatos en el controlador. Este enfoque habilita las zonas de cifrado de HDFS, las que proporcionan rutas de acceso seguras en HDFS.

Instancias de SQL Server

Se instala un certificado generado por el sistema en los pods de SQL Server que se van a usar con los comandos de TDE. El estándar de nomenclatura de los certificados administrados por el sistema es TDECertificate + timestamp. Por ejemplo, TDECertificate2020_09_15_22_46_27.
Las bases de datos de usuario y las bases de datos aprovisionadas por Clústeres de macrodatos de la instancia maestra no se cifrarán de manera automática. Los administradores de bases de datos pueden usar el certificado instalado para cifrar cualquier base de datos.
El grupo de proceso y el bloque de almacenamiento se cifran automáticamente mediante el certificado generado por el sistema.
Aunque es técnicamente posible con el comando EXECUTE AT de T-SQL, no se recomienda el cifrado de grupo de datos, ni tampoco 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 efectivo y es posible que el cifrado no se realice en el estado deseado. El enfoque también crea una ruta de actualización incompatible con respecto a las versiones siguientes.
La rotación de claves de SQL Server se consigue mediante los comandos administrativos estándar de T-SQL. Para obtener más información, consulte Guía de uso del Cifrado de datos transparente (TDE) en reposo de Clústeres de macrodatos de SQL Server.
La supervisión del cifrado se produce a través de las DMV de SQL Server estándar existentes para TDE.
Se admite la copia de seguridad y la restauración de una base de datos habilitada para TDE en el clúster.
Se admite la alta disponibilidad. Si una base de datos de la instancia principal de SQL Server está cifrada, también se cifra toda la réplica secundaria de la base de datos.

Zonas de cifrado HDFS

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

Administración del cifrado en reposo

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

La administración del cifrado de datos transparente (TDE) de SQL Server se realiza mediante los comandos estándar de T-SQL.
La administración de las zonas de cifrado de HDFS y de las claves de HDFS se realiza mediante los comandos de azdata.
Las siguientes características de administración se llevan a cabo mediante el uso de cuadernos operativos:
- Copia de seguridad y recuperación de claves de HDFS
- Eliminación de claves de HDFS

Guía de configuración

Durante las implementaciones nuevas de Clústeres de macrodatos de SQL Server, desde CU8 en adelante, el cifrado en reposo estará habilitado y configurado de manera predeterminada. Esto significa lo siguiente:

El componente KMS de Clústeres de macrodatos se implementa en el controlador y genera 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 se configura para interactuar con KMS de Clústeres de macrodatos para las operaciones de cifrado. Las zonas de cifrado de HDFS están configuradas y listas para usarse.

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

Si instala una nueva implementación de Clústeres de macrodatos de SQL Server de CU8 en adelante, o bien actualiza directamente a CU9, no es necesario que realice ningún otro paso.

Actualización de los escenarios

En los clústeres existentes, el proceso de actualización no aplicará nuevo cifrado ni volverá a cifrar los datos de usuario que no se hayan cifrado. Este es el comportamiento predeterminado y se deben tener en cuenta las cuestiones siguientes 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 de TDE instalados manualmente antes del proceso de actualización. También se recomienda almacenar esos artefactos fuera del clúster de macrodatos.
- Grupo de proceso y bloque de almacenamiento. Estas bases de datos están administradas por el sistema, son volátiles, se vuelven a crear y se cifran automáticamente en la actualización del clúster.
- Grupo de datos. La actualización no afecta las bases de datos de la parte de las instancias de SQL Server del grupo de datos.
HDFS

El proceso de actualización no tocará los archivos ni las 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

Precaución

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

No se configurarán zonas de cifrado. El componente KMS de Hadoop no se configurará para usar KMS de Clústeres de macrodatos. A fin de configurar y habilitar las zonas de cifrado de HDFS después de la actualización, siga las instrucciones de la siguiente sección.

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

Si actualizó el clúster a CU8 (azdata upgrade) y quiere habilitar zonas de cifrado de HDFS, tiene dos opciones:

Ejecutar el cuaderno operativo de Azure Data Studio denominado SOP0128: Habilitación de zonas de cifrado de HDFS en Clústeres de macrodatos para llevar a cabo la configuración.
Ejecute los scripts, como se describe a continuación.

Requisitos:

Clúster integrado en Active Directory.
CLI de datos de Azure (azdata) configurada y conectada en el clúster en el modo de AD.

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

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

Requisitos de ejecución de scripts:

Ambos scripts deben estar en el mismo directorio.
kubectlen 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 secciones anteriores, una implementación de Clústeres de macrodatos de SQL Server 2019 CU8+ habilita la funcionalidad de cifrado en reposo con claves administradas por el sistema de forma predeterminada. Para permitir que un proveedor de claves externo proteja las claves raíz del cifrado de SQL Server y HDFS, consulte: Proveedores de claves externos en Clústeres de macrodatos de SQL Server.

Pasos siguientes

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

Para obtener más información sobre cómo usar eficazmente el cifrado en reposo de Clústeres de macrodatos de SQL Server, consulte estos artículos:

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

Presentación de Clústeres de macrodatos de SQL Server 2019

Compartir a través de