Versiones de clave en Clústeres de macrodatos de SQL Server
Se aplica a:
SQL Server 2019 (15.x)
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.
En este artículo se proporciona información sobre cómo se usan las versiones de clave en Clústeres de macrodatos de SQL Server para la administración y la rotación de claves de HDFS y SQL Server. El artículo incluye detalles sobre la manera en que las versiones pueden incorporar claves del cliente.
Para obtener información general sobre cómo proteger Clústeres de macrodatos de SQL Server, vea Conceptos de seguridad para Clústeres de macrodatos de SQL Server.
Para obtener información sobre cómo configurar y usar la característica de cifrado en reposo, consulte las guías siguientes:
- Conceptos y guía de configuración del cifrado en reposo
- Guía de uso de las zonas de cifrado de HDFS de Clústeres de macrodatos de SQL Server
- Guía de uso del cifrado de datos transparente (TDE) en reposo de Clústeres de macrodatos de SQL Server
Claves de HDFS
Para usar el cifrado en reposo en HDFS, deben conocer los conceptos siguientes:
- Zonas de cifrado (EZ): la zona de cifrado es una carpeta de HDFS que está asociada a una clave. Todos los archivos de esta carpeta están cifrados. El valor predeterminado de EZ que está aprovisionado en Clústeres de macrodatos de SQL Server se denomina "securelake".
- Claves de zona de cifrado (clave de EZ): clave simétrica con nombre. El valor predeterminado administrado por el sistema que está aprovisionado en Clústeres de macrodatos de SQL Server es "securelakekey". Las claves de zona de cifrado se administran mediante KMS (servidor de administración de claves) de Hadoop, que se ejecuta dentro de los pods de nodo de nombre de Clústeres de macrodatos de SQL Server. Las claves de EZ se protegen aún más mediante una clave de cifrado principal que se almacena en controldb (más información en secciones posteriores). Las claves de EZ se cifran en KMS de Hadoop mediante la captura de la parte pública de la clave de cifrado principal y las solicitudes de descifrado se envían al plano de control.
- Clave de cifrado de datos cifrada: todos los archivos de la zona de cifrado se cifran mediante una clave de cifrado de datos (DEK) generada para el archivo. Una vez que se ha creado la DEK, se conserva con los datos. Para conservar la DEK, primero se cifra mediante la clave de zona de cifrado y, luego, se guarda con los datos. La DEK se genera aleatoriamente por archivo y la intensidad de la DEK simétrica es la misma que la de la clave de EZ.
En el gráfico siguiente se explica cómo se protegen los archivos con la DEK y cómo se protege la DEK con la clave de EZ securelakekey.
Claves de SQL Server
La clave de cifrado principal administrada por el sistema y las claves de EZ de HDFS se almacenan en controldb, que se denominará controldb-<#> (por ejemplo, controldb-0). Para obtener más información, consulte Recursos implementados con el clúster de macrodatos.
Las bases de datos de SQL Server se cifran con una clave simétrica, también denominada clave de cifrado de base de datos (DEK). La DEK se conserva con la base de datos en un formato cifrado. El protector de DEK puede ser un certificado o una clave asimétrica. Para cambiar el protector de DEK, use la instrucción ALTER DATABSE ENCRYPTION KEY. La clave asimétrica de SQL Server tiene metadatos que contienen un vínculo de dirección URL a la clave dentro del plano de control. Por lo tanto, todas las operaciones de cifrado y descifrado de la clave de cifrado de base de datos (DEK) se realizan dentro del controlador. SQL Server almacena la clave pública, pero solo para identificar la clave asimétrica y no realiza cifrado con la clave pública.
Clave de cifrado principal de Clústeres de macrodatos de SQL Server
En el plano de control de Clústeres de macrodatos de SQL Server, para proteger las claves de zona de cifrado y aprovisionar claves asimétricas en SQL Server, existe el de "clave de cifrado principal". Hay dos claves de cifrado principales: una para SQL Server y otra para HDFS. Gracias a este concepto, el plano de control de Clústeres de macrodatos de SQL Server permite que la clave de cifrado principal resida también fuera del clúster. Estas son las propiedades de la clave de cifrado principal:
- Las claves de cifrado principales son claves RSA asimétricas.
- Se crea una clave de cifrado principal para la instancia maestra de SQL Server y otra para HDFS.
- La clave pública correspondiente a la clave de cifrado principal siempre se almacena en la base de datos del controlador o controldb. La clave privada se almacena en la base de datos del controlador para la clave de cifrado principal administrada por el sistema. En el caso de las claves de cifrado de un módulo de seguridad de hardware (HSM) o de cualquier otro proveedor externo, las claves privadas no se almacenan dentro de la base de datos del controlador (a menos que la aplicación de claves externas incluya una clave privada). Aun así, la clave privada no es necesaria en controldb y Clústeres de macrodatos de SQL Server no requerirá el material de clave privada.
- Las operaciones de cifrado que usan la clave pública de la clave de cifrado principal se pueden realizar dentro del propio controlador, o bien el controlador puede distribuir la clave pública a KMS de Hadoop para que este pueda realizar el cifrado localmente. Se espera que el proveedor de claves externo (como HSM) se ocupe de las operaciones de descifrado. Este diseño permite mantener la parte confidencial de la clave asimétrica fuera del clúster y bajo la protección del cliente. Esto garantiza que la raíz del cifrado para descifrar todos los datos nunca esté disponible en el ecosistema de Clústeres de macrodatos de SQL Server para las claves configuradas por el cliente.
Protección del almacenamiento de diferentes claves
La DEK para archivos de HDFS y para SQL Server se almacena junto con los datos que protege la DEK. La DEK está protegida con la clave de EZ de HDFS o la clave asimétrica en SQL Server, respectivamente.
Las claves asimétricas de SQL Server tienen metadatos que incluyen la dirección URL de la clave en el plano de control. SQL Server solo almacena la clave pública de la clave asimétrica, para la correlación con la clave en el plano de control.
El almacenamiento de claves en controldb está protegido con la clave de cifrado de columna en controldb. En controldb se almacena información confidencial sobre el clúster. Toda la información confidencial está protegida con una clave de cifrado de columna de SQL Server en controldb, que a su vez está protegida con una contraseña almacenada en secretos de Kubernetes. Para obtener más información, consulte la documentación de secretos de Kubernetes.
En los diagramas siguientes se resume la protección. En primer lugar, la protección del almacenamiento de claves de EZ de HDFS:
Protección del almacenamiento de la clave de cifrado principal:
Rotación de claves
Claves de zona de cifrado de HDFS
Cuando se implementa Clústeres de macrodatos de SQL Server con Active Directory, HDFS se aprovisiona con una zona de cifrado predeterminada denominada securelake, que está protegida con securelakekey. En los ejemplos usaremos los valores predeterminados, pero se pueden aprovisionar nuevas zonas y claves mediante azdata. securelakekey se protege con una clave de cifrado principal para HDFS, que se almacena en el plano de control. A partir de SQL 2019 CU9, se puede usar azdata para girar las claves de EZ para HDFS. Al girar las claves de EZ, se genera nuevo material de clave con el mismo nombre que "securelakekey", pero con una nueva versión de la clave que apunta al material de clave. Para cualquier nueva operación de cifrado en HDFS (por ejemplo, escrituras de archivos), EZ siempre usa la versión más reciente de la clave asociada a EZ. Si los archivos de una EZ están protegidos con versiones anteriores de las claves, se puede usar el comando azdata bdc hdfs encryption-zone reencrypt para proteger todos los archivos con la versión más reciente de la clave de EZ.
Considere un archivo denominado file2 que se encuentra en /securelake. A continuación se muestra la cadena de protección.
Es posible girar securelakekey a una nueva versión mediante azdata bdc hdfs key roll -n securelakekey. La rotación no hace que se vuelvan a cifrar las DEK que protegen el archivo. Al girar las claves de Hadoop, se genera nuevo material de clave que está protegido con la versión más reciente de main-encryption-key. En el diagrama siguiente se muestra el estado del sistema tras la rotación de securelakekey.
Para asegurarse de que los archivos de las zonas de cifrado están protegidos con la clave securelakekey girada, use azdata bdc hdfs encryption-zone -a start -p /securelake.
En el diagrama siguiente se muestra el estado del sistema después de volver a cifrar la zona de cifrado.
SQL Server
La clave que protege la base de datos SQL es la DEK, que se puede regenerar. El proceso de regeneración provoca que toda la base de datos se vuelva a cifrar.
Rotación de claves de cifrado principales
Nota
Antes de SQL Server 2019 CU10 no existía ninguna manera de girar la clave de cifrado principal. A partir de SQL Server 2019 CU10, se puede exponer el comando azdata para permitir la rotación de la clave de cifrado principal.
La clave de cifrado principal es una clave RSA de 2048 bits. Al girar la clave de cifrado principal, se produce una de las siguientes acciones, en función del origen de la clave:
- Se crea una clave en caso de que se haya realizado la solicitud para girar la clave principal a una clave administrada por el sistema. Una clave administrada por el sistema es una clave asimétrica que se genera y se almacena en el controlador.
- Se crea una referencia a una clave proporcionada externamente, donde la clave privada de la clave asimétrica se administra mediante la aplicación cliente. La aplicación cliente no necesita tener la clave privada, pero debe saber cómo recuperarla según la configuración de la aplicación proporcionada.
La rotación de la clave principal no vuelve a cifrar nada. Después, es necesario girar las claves de SQL Server y de HDFS:
- Una vez que se ha girado la clave principal, el protector de la DEK de la base de datos de SQL Server debe girarse a la nueva versión de la clave principal que se ha creado.
- Se aplican conceptos similares a HDFS. Cuando se gira la clave de HDFS, la versión más reciente de la clave principal cifra el nuevo material. Las versiones anteriores de las claves de EZ permanecerán intactas. Una vez que se ha girado la clave de EZ de HDFS, las zonas de cifrado asociadas a la clave de EZ deben volver a cifrarse para que estén cifradas con la versión más reciente de la clave de EZ.
Rotación de la clave principal para HDFS
En los diagramas siguientes se ilustra el proceso de rotación de la clave de cifrado principal para HDFS. En primer lugar, se muestra el estado inicial de HDFS:
La clave de cifrado principal se girará mediante azdata bdc kms set –key-provider SystemManaged. (Tenga en cuenta que el comando provoca la rotación de la clave de cifrado principal para SQL y HDFS, aunque sean claves diferentes dentro del plano de control). Después de usar el comando azdata bdc kms:
Para usar la nueva versión de la clave de cifrado principal de HDFS, se puede usar el comando azdata bdc hdfs key roll, lo que lleva el sistema al siguiente estado. Después de girar securelakekey:
La rotación de securelakekey hace que se cree una nueva versión de securelakekey y que se proteja con la clave de cifrado principal. Para asegurarse de que los archivos de securelake se cifren con securelakekey@2, es necesario volver a cifrar la zona de cifrado de securelake. Después de volver a cifrar la zona de cifrado:
Rotación de la clave principal para SQL Server
La clave de cifrado principal de SQL Server se instala en la base de datos maestra de la instancia maestra de SQL Server.
En los diagramas siguientes se ilustra el proceso de rotación de la clave de cifrado principal para SQL Server.
En una instalación nueva de Clústeres de macrodatos de SQL Server, no habrá ninguna clave asimétrica aprovisionada en SQL Server. En el estado inicial de SQL Server, las bases de datos se pueden cifrar con certificados, pero el administrador de la instancia maestra de SQL Server es quien controla este aspecto.
La clave de cifrado principal se girará mediante azdata bdc kms set –key-provider SystemManaged. (Tenga en cuenta que el comando provoca la rotación [o su creación, si no existe] de la clave de cifrado principal para SQL y HDFS, aunque sean claves diferentes dentro del plano de control).
La clave asimétrica se puede ver mediante la siguiente consulta T-SQL, con la vista de catálogo del sistema sys.asymmetric_keys.
USE master;
select * from sys.asymmetric_keys;
La clave asimétrica aparecerá con la convención de nomenclatura "tde_asymmetric_key_<version>". Después, el administrador de SQL Server puede cambiar el protector de la clave de cifrado de datos (DEK) a la clave asimétrica mediante ALTER DATABASE ENCRYPTION KEY. Por ejemplo, use el siguiente comando T-SQL:
USE db1;
ALTER DATABASE ENCRYPTION KEY ENCRYPTION BY SERVER ASYMMETRIC KEY tde_asymmetric_key_0;
Ahora, se cambia el protector de la DEK para que use la clave asimétrica:
Si se vuelve a ejecutar el comando azdata bdc kms set, las claves asimétricas de SQL Server mostrarán otra entrada en sys.asymmetric_keys con el formato "tde_asymmetric_key_<version>". Este comando azdata se puede usar para cambiar de nuevo el protector de la DEK de una base de datos de SQL Server.
Clave proporcionada por el cliente
Gracias a la funcionalidad de incorporar claves externas en Clústeres de macrodatos de SQL Server, la clave de cifrado principal captura la clave pública mediante la aplicación que implementa el cliente. Cuando las claves de HDFS se rotan y se usan, las llamadas para descifrar las claves de HDFS se envían al plano de control y, luego, se redirigen a la aplicación mediante el identificador de clave que ha proporcionado el cliente. En el caso de SQL Server, el plano de control envía y satisface las solicitudes de cifrado, ya que tiene la clave pública. Las solicitudes para descifrar la DEK desde SQL también se envían al plano de control y, luego, se redirigen a la aplicación de KMS.
En el diagrama siguiente se explican las interacciones al configurar claves externas en el plano de control:
Una vez instalada la clave, el cifrado y el descifrado de las cargas están protegidos mediante la clave de cifrado principal. Esta protección es similar a la de las claves administradas por el sistema, con la diferencia de que las llamadas de descifrado enrutadas al plano de control se enrutan después a la aplicación de complemento de KMS. La aplicación de complemento de KMS enruta la solicitud a la ubicación adecuada, como el HSM u otro producto.
Vea también
Comentarios
Próximamente: A lo largo de 2024 iremos eliminando gradualmente las Cuestiones de GitHub como mecanismo de retroalimentación para el contenido y lo sustituiremos por un nuevo sistema de retroalimentación. Para más información, consulta: https://aka.ms/ContentUserFeedback.
Enviar y ver comentarios de