Compartir a través de

Configuración de Administración extensible de claves de TDE de SQL Server mediante Azure Key Vault

  • Artículo

Se aplica a: SQL Server

En este artículo, instalará y configurará el conector de SQL Server para Azure Key Vault.

Nota:

Microsoft Entra ID era conocido anteriormente como Azure Active Directory (Azure AD).

La administración extensible de claves con Azure Key Vault (AKV) está disponible para entornos de SQL Server en Linux, a partir de SQL Server 2022 (16.x) Actualización acumulativa 12. Sigue las mismas instrucciones, pero omite los pasos 3 y 4.

Requisitos previos

Antes de empezar a usar Azure Key Vault con la instancia de SQL Server, asegúrese de que cumple los requisitos previos siguientes:

Nota:

En SQL Server 2022 (16.x) CU 14 y versiones posteriores, SQL Server en Linux admite la administración extensible de claves de TDE con Azure Key Vault. Los pasos 3 y 4 de esta guía no son necesarios para SQL Server en Linux.

Paso 1: Configuración de una aplicación y una entidad de servicio de Microsoft Entra

Para conceder permisos de acceso a la instancia de SQL Server al almacén de claves de Azure, necesitas una cuenta de entidad de servicio en Microsoft Entra ID.

  1. Inicie sesión en Azure Portal de cualquiera de estas maneras:

    • Selecciona el botón Microsoft Entra ID.

      Captura de pantalla del panel

    • Selecciona Más servicios y, a continuación, en el panel Todos los servicios, escribe Microsoft Entra ID.

  2. Lleva a cabo los siguientes pasos para registras una aplicación con Microsoft Entra ID. Para obtener instrucciones detalladas paso a paso, consulta la sección Obtención de una identidad para la aplicación de la entrada de blog de Azure Key Vault, Azure Key Vaul: Paso a paso.

    1. En la sección Administración de tu recurso de Microsoft Entra ID, selecciona Registros de aplicaciones.

      Captura de pantalla de la página de información general de Microsoft Entra ID en Azure Portal.

    2. En la página Registros de aplicaciones, seleccione Nuevo registro.

      Captura de pantalla del panel de registros de aplicaciones en Azure Portal.

    3. En el panel Registrar una aplicación, escriba el nombre para el usuario de la aplicación y, después, seleccione Registrar.

      Captura de pantalla del panel

    4. En el panel izquierdo, selecciona Certificados y secretos > Secretos de cliente > Nuevo secreto de cliente.

      Captura de pantalla del panel Certificados y Secretos de la aplicación en Azure Portal.

    5. En Agregar un secreto de cliente, escriba una descripción y una expiración adecuada y, después, seleccione Agregar. No puede elegir un período de expiración superior a 24 meses. Para obtener más información, consulte Incorporación de un secreto de cliente.

      Captura de pantalla de la sección Agregar un secreto de cliente para la aplicación en Azure Portal.

    6. En el panel Certificados y secretos, en Valor, seleccione el botón Copiar situado junto al valor del secreto de cliente que se va a usar para crear una clave asimétrica en SQL Server.

      Captura de pantalla en la que se muestra el valor del secreto en Azure Portal.

    7. En el panel de la izquierda, seleccione Información general y, después en el cuadro Id. de aplicación (cliente), copie el valor que se va a usar para crear una clave asimétrica en SQL Server.

      Captura de pantalla del valor

Paso 2: Crear un almacén de claves

Seleccione el método que quiera usar para crear un almacén de claves.

Creación de un almacén de claves mediante Azure Portal

Puede usar Azure Portal para crear el almacén de claves y, después, añadirle una entidad de seguridad de Microsoft Entra.

  1. Cree un grupo de recursos.

    Todos los recursos de Azure que se crean a través de Azure Portal deben estar incluidos en un grupo de recursos, que se crea para hospedar el almacén de claves. El nombre del recurso de este ejemplo es DocsSampleRG. Elija un grupo de recursos y un nombre del almacén de claves propios, ya que todos los nombres de almacén de claves deben ser únicos y globales.

    En el panel Crear un grupo de recursos, en Detalles del proyecto, escriba los valores y después seleccione Revisar y crear.

    Captura de pantalla del panel Crear un grupo de recursos en Azure Portal.

  2. En Azure Portal, busque o seleccione los servicios de Almacén de claves para crear un almacén de claves. Seleccione Crear.

    En el panel Crear un almacén de claves, seleccione la pestaña Aspectos básicos. Escriba los valores adecuados para la pestaña. También se recomienda habilitar la protección de purga.

    Captura de pantalla del panel Crear almacén de claves en Azure Portal.

  3. En la pestaña Configuración de acceso, tiene la opción de seleccionar el control de acceso basado en roles de Azure o la directiva de acceso del almacén. Se revisan ambas opciones, pero se recomienda la opción de control de acceso basado en roles de Azure. Para más información, consulte Introducción al modelo de acceso.

    Captura de pantalla del panel Crear almacén de claves y la pestaña Configuración de acceso en Azure Portal.

  4. Puede dejar la pestaña Redes como valor predeterminado o configurar las opciones de red para el almacén de claves. Al usar un firewall con el almacén de claves, debe habilitar la opción Permitir que los servicios de confianza de Microsoft omitan el firewall, a menos que use conexiones con puntos de conexión privados. Para más información, vea Configuración de firewalls y redes virtuales de Azure Key Vault.

  5. Seleccione el botón Revisar y crear y cree el almacén de claves.

Control de acceso basado en rol de Azure

El método recomendado es usar el control de acceso basado en roles (RBAC) de Azure para asignar permisos al almacén de claves. Este método le permite asignar permisos a usuarios, grupos y aplicaciones en un nivel más detallado. Puede asignar permisos al almacén de claves en el plano de administración (asignaciones de roles de Azure) y en el plano de datos (directivas de acceso del almacén de claves). Si solo puede utilizar la directiva de acceso, puede omitir esta sección e ir a la sección Directiva de acceso del almacén. Para obtener más información sobre los permisos de Azure Key Vault RBAC, consulte Roles integrados de Azure para operaciones del plano de datos del almacén de claves.

  1. Vaya al recurso del almacén de claves que creó y seleccione la configuración Access control (IAM).

  2. Seleccione Agregar>Agregar asignación de roles.

    Captura de pantalla del botón Agregar asignación de roles en el panel Access control (IAM) en Azure Portal.

  3. La aplicación EKM necesita el rol Usuario de cifrado del servicio criptográfico del almacén de claves para realizar operaciones de encapsulado y desencapsulado. Busque y seleccione Usuario de cifrado del servicio de criptográfico del almacén de claves y seleccione el rol. Seleccione Siguiente.

    Captura de pantalla de la página para agregar asignación de roles en Azure Portal.

  4. En la pestaña Miembros, seleccione la opción Seleccionar miembros y busque la aplicación Microsoft Entra que creó en el paso 1. Seleccione la aplicación y después el botón Seleccionar.

    Captura de pantalla del panel Seleccionar miembros para agregar una asignación de roles en Azure Portal.

  5. Seleccione Revisar y asignar dos veces para completar la asignación de roles.

  6. El usuario que crea la clave necesita el rol de Administración del almacén de claves. Busque Administrador del almacén de claves y seleccione el rol. Seleccione Siguiente.

  7. Al igual que los pasos anteriores, agregue el miembro que crea la clave y asigne el rol.

Directiva de acceso de Key Vault

Nota:

Si usa la opción de control de acceso basado en rol de Azure, puede omitir esta sección. Si va a cambiar el modelo de permisos, puede hacerlo si va al menú Configuración de acceso del almacén de claves. Asegúrese de que tiene los permisos correctos para administrar el almacén de claves. Para obtener más información, vea Habilitación de los permisos de Azure RBAC en Key Vault.

  1. Desde la pestaña Configuración de acceso, seleccione Directiva de acceso del almacén. Si usa un almacén de claves existente, puede seleccionar el menú Directivas de acceso en el recurso de Key Vault y seleccionar Crear.

  2. En el panel Crear una directiva de acceso, seleccione Obtener y Enumerar permisos en las opciones Operaciones de administración de claves. Seleccione Desencapsular clave y Encapsular permisos de clave en las opciones de operaciones criptográficas. Seleccione Siguiente.

    Captura de pantalla del vínculo

  3. En la pestaña Principal, seleccione la aplicación que se creó en el paso 1.

    Captura de pantalla del cuadro de búsqueda de aplicaciones del panel

  4. Seleccione Siguiente y, después, Crear.

Crear una clave

  1. En el panel Almacén de claves, seleccione Claves y después seleccione la opción Generar e importar. Se abrirá el panel Crear una clave. Escriba el nombre del almacén de claves. Seleccione la opción Generar y escriba un nombre único para la clave. El Conector de SQL Server requiere que en el nombre de clave solo se usen los caracteres "a-z", "A-Z", "0-9" y "-", con un límite de 26 caracteres.

  2. Use el tipo de clave RSA y el tamaño de clave RSA 2048. EKM actualmente solo admite una clave RSA. Establezca las fechas de activación y expiración según corresponda y configure ¿Habilitado? en Sí.

    Captura de pantalla del panel

procedimientos recomendados

Para garantizar una recuperación rápida de las claves y la capacidad de acceder a los datos fuera de Azure, se recomiendan los procedimientos recomendados siguientes:

  • Cree la clave de cifrado localmente en un dispositivo de módulo de seguridad de hardware (HSM) local. Asegúrese de usar una clave RSA 2048 o 3072 asimétrica, para que sea compatible con SQL Server.

  • Importe la clave de cifrado a Azure key vault. Este proceso se describe en las secciones siguientes.

  • Antes de usar la clave por primera vez en el almacén de claves de Azure, cree una copia de seguridad de la clave mediante el cmdlet Backup-AzureKeyVaultKey de PowerShell.

  • Siempre que realice cambios en la clave (por ejemplo, si agrega ACL, etiquetas o atributos de clave), asegúrese de realizar otra copia de seguridad de la clave del almacén de claves de Azure.

    Nota:

    Crear una copia de seguridad de una clave es una operación esencial de Azure Key Vault que devuelve un archivo que se puede guardar en cualquier lugar.

    El uso del conector de SQL Server para Azure Key Vault detrás de un firewall o servidor proxy puede afectar al rendimiento si el tráfico se retrasa o bloquea. Familiarícese con Access Azure Key Vault detrás de un firewall para asegurarse de que se han implementado las reglas correctas.

Opcional: Configuración de un HSM administrado (Módulo de seguridad de hardware) de Azure Key Vault

HSM administrado (Módulo de seguridad de hardware) de Azure Key Vault es compatible con SQL Server y SQL Server en Azure Virtual Machines (VM) al usar la última versión del Conector de SQL Server, así como Azure SQL. HSM administrado es un servicio HSM totalmente administrado, de alta disponibilidad y de un solo inquilino. HSM administrado proporciona una base segura para las operaciones criptográficas y el almacenamiento de claves. HSM administrado está diseñado para cumplir con los requisitos de seguridad y cumplimiento más estrictos.

En el paso 2, hemos descubierto cómo crear un almacén de claves y una clave en Azure Key Vault. Opcionalmente, puede usar un HSM administrado de Azure Key Vault para almacenar o crear una clave que se usará con el Conector de SQL Server. He aquí los pasos:

  1. Cree un HSM administrado de Azure Key Vault. Se puede hacer con Azure Portal mediante la búsqueda del servicio HSM administrado de Azure Key Vault y la creación del recurso, o bien mediante la CLI de Azure, PowerShell o una plantilla de ARM.

  2. Activar el HSM administrado. El HSM solo pueden activarlo los administradores designados que se asignaron durante la creación del HSM administrado. Para ello, seleccione el recurso HSM administrado en Azure Portal seleccionando Descargar dominio de seguridad en el menú Información general del recurso. Después, siga uno de los inicios rápidos para activar el HSM administrado.

  3. Conceda permisos para que la entidad de servicio de Microsoft Entra acceda al HSM administrado. El rol Administrador de HSM administrado no concede permisos para crear una clave. De forma similar al paso 2, la aplicación EKM necesita el rol Usuario criptográfico de HSM administrado o Usuario de cifrado de servicio criptográfico de HSM administrado para realizar operaciones de encapsulado y desencapsulado. Elija el tipo de aplicación empresarial al añadir la entidad de seguridad para la asignación de roles. A fin de obtener más información, vea Roles integrados de RBAC local para HSM administrado.

  4. En el menú Servicio de HSM administrado de Azure Key Vault, en Configuración, seleccione Claves. En la ventana Claves, seleccione Generar, importar o restaurar copia de seguridad para crear una clave o importar una existente.

    Nota:

    Al crear una credencial para acceder al HSM administrado, la identidad es <name of Managed HSM>.managedhsm.azure.net, que se puede encontrar en Información general de HSM administrado de Azure Key Vault como el URI de HSM en Azure Portal.

    HSM administrado de Azure Key Vault admite la rotación automática de claves. Para obtener más información, vea Configuración de la rotación automática de claves en HSM administrado.

    Se necesita la versión 15.0.2000.440 de Conector de SQL Server o una posterior para admitir HSM administrado de Azure Key Vault.

    HSM administrado admite las conexiones de punto de conexión privado. Para obtener más información, consulte Integración de HSM administrado con Azure Private Link. En esta configuración, la opción de omisión del servicio de confianza de Microsoft debe estar habilitada para la configuración de Redes de HSM administrado de Azure Key Vault.

Paso 3: Instalar el conector de SQL Server

Descargue el conector de SQL Server desde el Centro de descarga de Microsoft. La descarga la debe realizar el administrador del equipo de SQL Server.

Nota:

  • Las versiones 1.0.0.440 y anteriores del conector de SQL Server se han reemplazado y ya no se admiten en entornos de producción, y se siguen las instrucciones de la página Mantenimiento y solución de problemas del Conector de SQL Server en Actualización del conector de SQL Server.
  • A partir de la versión 1.0.3.0, el conector de SQL Server notifica los mensajes de error pertinentes a los registros de eventos de Windows para la solución de problemas.
  • A partir de la versión 1.0.4.0, hay compatibilidad con las nubes de Azure privadas, entre las que se incluyen Azure operado por 21Vianet, Azure Alemania y Azure Government.
  • Hay un cambio importante en la versión 1.0.5.0, relacionado con el algoritmo de huella digital. Puede experimentar un error de restauración de base de datos después de actualizar a la versión 1.0.5.0. Para obtener más información, vea el artículo de KB 447099.
  • A partir de la versión 1.0.5.0 (marca de tiempo: septiembre de 2020), el Conector de SQL Server admite el filtrado de mensajes y la lógica de reintento de solicitud de red.
  • A partir de la versión actualizada 1.0.5.0 (TimeStamp: noviembre de 2020), el conector de SQL Server admite claves RSA 2048, RSA 3072, RSA-HSM 2048 y RSA-HSM 3072.
  • A partir de la versión actualizada 1.0.5.0 (TimeStamp: noviembre de 2020), puede consultar una versión de clave específica en Azure Key Vault.

Captura de pantalla del asistente para instalación del Conector de SQL Server.

De forma predeterminada, el conector se instala en C:\Program Files\SQL Server Connector for Microsoft Azure Key Vault. Esta ubicación se puede cambiar durante la instalación. Si lo cambia, ajuste los scripts de la sección siguiente.

No hay ninguna interfaz para el conector, pero si se instala correctamente, se instala Microsoft.AzureKeyVaultService.EKM.dll en el equipo: Este ensamblado es la DLL del proveedor de servicios criptográficos EKM que se debe registrar con SQL Server mediante la instrucción CREATE CRYPTOGRAPHIC PROVIDER.

La instalación del conector de SQL Server también le permite descargar, si quiere, los scripts de muestra del cifrado de SQL Server.

Para ver las explicaciones de código de error, los valores de configuración o las tareas de mantenimiento para el conector de SQL Server, vea:

Paso 4: Agregar clave del Registro para admitir el proveedor EKM

Advertencia

La modificación del Registro deben realizarla usuarios que sepan exactamente lo que están haciendo. Pueden producirse problemas graves si modifica el Registro de manera incorrecta. Para la protección añadida, realice una copia de seguridad del Registro antes de modificarlo. Puedes restaurar el Registro si se produce un problema.

  1. Asegúrate de que SQL Server está instalado y en ejecución.

  2. Ejecuta regedit para abrir el editor del Registro.

  3. Cree una clave del Registro SQL Server Cryptographic Provider en HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft. La ruta de acceso completa es HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SQL Server Cryptographic Provider.

  4. Haz clic con el botón derecho en la clave del Registro SQL Server Cryptographic Provider y selecciona Permisos.

  5. Delega permisos de control completo en la clave de Registro SQL Server Cryptographic Provider en la cuenta de usuario que ejecuta el servicio de motor de base de datos de SQL Server.

    Captura de pantalla de la clave del Registro EKM en el Editor del Registro.

  6. Seleccione Apply (Aplicar) y, después, OK (Aceptar).

  7. Cierra el Editor del Registro y reinicia el servicio SQL Server.

    Nota:

    Si usa TDE con EKM o Azure Key Vault en una instancia de clúster de conmutación por error, debe completar un paso adicional para agregar HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SQL Server Cryptographic Provider a la rutina punto de comprobación del Registro del clúster para que el registro se pueda sincronizar entre los nodos. La sincronización facilita la recuperación de la base de datos después de la conmutación por error y la rotación de claves.

    Para agregar la clave del Registro a la rutina de punto de comprobación del Registro del clúster, en PowerShell, ejecute el siguiente comando:

    Add-ClusterCheckpoint -RegistryCheckpoint "SOFTWARE\Microsoft\SQL Server Cryptographic Provider" -Resourcename "SQL Server"

Paso 5: Configuración de SQL Server

Para obtener una nota sobre los niveles de permisos mínimos necesarios para cada acción de esta sección, vea B. Preguntas más frecuentes.

Configuración de la base de datos master

  1. Ejecute sqlcmd o abra SQL Server Management Studio.

  2. Ejecute el script Transact-SQL siguiente para configurar SQL Server con el fin de usar EKM:

    -- Enable advanced options.
USE master;
GO

EXEC sp_configure 'show advanced options', 1;
GO
RECONFIGURE;
GO

-- Enable EKM provider
EXEC sp_configure 'EKM provider enabled', 1;
GO
RECONFIGURE;

  3. Registre el Conector de SQL Server como proveedor EKM con SQL Server.

    Cree un proveedor de servicios criptográficos mediante el Conector de SQL Server, que es un proveedor EKM para Azure Key Vault. En este ejemplo, el nombre del proveedor es AzureKeyVault_EKM.

    CREATE CRYPTOGRAPHIC PROVIDER AzureKeyVault_EKM
FROM FILE = 'C:\Program Files\SQL Server Connector for Microsoft Azure Key Vault\Microsoft.AzureKeyVaultService.EKM.dll';
GO

    Nota:

    La ruta de acceso al archivo no puede tener una longitud superior a 256 caracteres.

  4. Configure una credencial de SQL Server para un inicio de sesión de SQL Server a fin de usar el almacén de claves.

    Debe agregar una credencial a cada inicio de sesión que va a realizar el cifrado con una clave del almacén de claves. Estas pueden incluir:

    • Un inicio de sesión de administrador de SQL Server que use el almacén de claves para configurar y administrar los escenarios de cifrado de SQL Server.

    • Otros inicios de sesión de SQL Server que podrían habilitar TDE u otras características de cifrado de SQL Server.

    Hay una asignación de uno a uno entre credenciales e inicios de sesión. Es decir, cada inicio de sesión debe tener una credencial única.

    Modifique este script de Transact-SQL como se indica a continuación:

    • Edite el argumento IDENTITY (DocsSampleEKMKeyVault) para dirigirlo a Azure Key Vault.

    • Reemplaza la primera parte del argumento SECRET por el identificador de cliente de Microsoft Entra del Paso 1: Configuración de una entidad de servicio de Microsoft Entra. En este ejemplo, el id. de cliente es d956f6b9xxxxxxx.

      Importante

      Asegúrese de quitar los guiones del id. de aplicación (cliente).

    • Completa la segunda parte del argumento SECRET con el secreto de cliente de cliente del Paso 1: Configuración de una entidad de servicio de Microsoft Entra. En este ejemplo, el secreto de cliente es yrA8X~PldtMCvUZPxxxxxxxx. La cadena final del argumento SECRET será una larga secuencia de letras y números, sin guiones (excepto para la sección Secreto de cliente, en caso de que el secreto de cliente contenga guiones).

      USE master;
CREATE CREDENTIAL sysadmin_ekm_cred
    WITH IDENTITY = 'DocsSampleEKMKeyVault',                            -- for public Azure
    -- WITH IDENTITY = 'DocsSampleEKMKeyVault.vault.usgovcloudapi.net', -- for Azure Government
    -- WITH IDENTITY = 'DocsSampleEKMKeyVault.vault.azure.cn',          -- for Microsoft Azure operated by 21Vianet
    -- WITH IDENTITY = 'DocsSampleEKMKeyVault.vault.microsoftazure.de', -- for Azure Germany
    -- WITH IDENTITY = '<name of Managed HSM>.managedhsm.azure.net',    -- for Managed HSM (HSM URI in the Azure portal resource)
           --<----Application (Client) ID ---><--Microsoft Entra app (Client) ID secret-->
    SECRET = 'd956f6b9xxxxxxxyrA8X~PldtMCvUZPxxxxxxxx'
FOR CRYPTOGRAPHIC PROVIDER AzureKeyVault_EKM;

-- Add the credential to the SQL Server administrator's domain login
ALTER LOGIN [<domain>\<login>]
ADD CREDENTIAL sysadmin_ekm_cred;

    Para obtener un ejemplo del uso de variables con el argumento CREATE CREDENTIAL y de cómo quitar mediante programación los guiones del Id. de cliente, vea CREATE CREDENTIAL.

  5. Abra la clave de su Azure Key Vault en la instancia de SQL Server.

    Tanto si ha creado una clave como si ha importado una clave asimétrica como se describe en el Paso 2: Creación de un almacén de claves, tendrá que abrir la clave. Para abrir la clave, proporcione su nombre en el script Transact-SQL siguiente.

    Importante

    Asegúrese de completar primero los requisitos previos del Registro para este paso.

    • Reemplace EKMSampleASYKey con el nombre que le gustaría tener en la clave de SQL Server.
    • Reemplace ContosoRSAKey0 por el nombre de la clave en su Azure Key Vault o HSM administrado. A continuación se muestra un ejemplo de una clave sin versión.
    CREATE ASYMMETRIC KEY EKMSampleASYKey
FROM PROVIDER [AzureKeyVault_EKM]
WITH PROVIDER_KEY_NAME = 'ContosoRSAKey0',
CREATION_DISPOSITION = OPEN_EXISTING;

    A partir de la versión actualizada 1.0.5.0 del conector de SQL Server, puede hacer referencia a una versión de clave específica en Azure Key Vault:

    CREATE ASYMMETRIC KEY EKMSampleASYKey
FROM PROVIDER [AzureKeyVault_EKM]
WITH PROVIDER_KEY_NAME = 'ContosoRSAKey0/1a4d3b9b393c4678831ccc60def75379',
CREATION_DISPOSITION = OPEN_EXISTING;

    En el script de ejemplo anterior, 1a4d3b9b393c4678831ccc60def75379 representa la versión específica de la clave que se usará. Si usa este script, no importa si actualiza la clave con una versión nueva. La versión de clave 1a4d3b9b393c4678831ccc60def75379 (por ejemplo) siempre se usará para las operaciones de base de datos.

  6. Cree un inicio de sesión con la clave asimétrica de SQL Server que ha creado en el paso anterior.

    --Create a Login that will associate the asymmetric key to this login
CREATE LOGIN TDE_Login
FROM ASYMMETRIC KEY EKMSampleASYKey;

  7. Cree un inicio de sesión a partir de la clave asimétrica en SQL Server. Quita la asignación de credenciales del Paso 5: Configuración de SQL Server, para que las credenciales se puedan asignar al nuevo inicio de sesión.

    --Now drop the credential mapping from the original association
ALTER LOGIN [<domain>\<login>]
DROP CREDENTIAL sysadmin_ekm_cred;

  8. Modifique el nuevo inicio de sesión y asígnele las credenciales EKM.

    --Now add the credential mapping to the new Login
ALTER LOGIN TDE_Login
ADD CREDENTIAL sysadmin_ekm_cred;

Configuración de la base de datos de usuario que se va a cifrar

  1. Cree una base de datos de prueba que se cifrará con la clave de Azure Key Vault.

    --Create a test database that will be encrypted with the Azure Key Vault key
CREATE DATABASE TestTDE;

  2. Cree una clave de cifrado de base de datos mediante ASYMMETRIC KEY (EKMSampleASYKey).

    USE <DB Name>;
--Create an ENCRYPTION KEY using the ASYMMETRIC KEY (EKMSampleASYKey)
CREATE DATABASE ENCRYPTION KEY
WITH ALGORITHM = AES_256
ENCRYPTION BY SERVER ASYMMETRIC KEY EKMSampleASYKey;

  3. Cifre la base de datos de prueba. Habilite TDE estableciendo ENCRYPTION ON.

    --Enable TDE by setting ENCRYPTION ON
ALTER DATABASE TestTDE
SET ENCRYPTION ON;

Detalles de Registro

  1. Ejecuta la siguiente consulta de Transact-SQL en la base de datos master para mostrar la clave asimétrica usada.

    SELECT name, algorithm_desc, thumbprint FROM sys.asymmetric_keys;

    La instrucción devuelve:

    name            algorithm_desc    thumbprint
EKMSampleASYKey RSA_2048          <key thumbprint>

  2. Ejecuta la siguiente consulta de Transact-SQL en la base de datos de usuario (TestTDE) para mostrar la clave de cifrado usada.

    SELECT encryptor_type, encryption_state_desc, encryptor_thumbprint
FROM sys.dm_database_encryption_keys
WHERE database_id = DB_ID('TestTDE');

    La instrucción devuelve:

    encryptor_type encryption_state_desc encryptor_thumbprint
ASYMMETRIC KEY ENCRYPTED             <key thumbprint>

Limpiar

  1. Limpie los objetos de prueba. Elimine todos los objetos que se hayan creado en este script de prueba.

    -- CLEAN UP
USE master;
GO
ALTER DATABASE [TestTDE] SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
DROP DATABASE [TestTDE];
GO

ALTER LOGIN [TDE_Login] DROP CREDENTIAL [sysadmin_ekm_cred];
DROP LOGIN [TDE_Login];
GO

DROP CREDENTIAL [sysadmin_ekm_cred];
GO

USE master;
GO
DROP ASYMMETRIC KEY [EKMSampleASYKey];
DROP CRYPTOGRAPHIC PROVIDER [AzureKeyVault_EKM];
GO

    Para obtener scripts de ejemplo, vea el blog en Cifrado de datos transparente de SQL Server y administración extensible de claves con Azure Key Vault.

  2. La clave del Registro SQL Server Cryptographic Provider no se limpia automáticamente después de eliminar una clave o todas las claves EKM. Debe limpiarse manualmente. La limpieza de la clave del Registro debe realizarse con extrema precaución, ya que limpiar el registro prematuramente puede interrumpir la funcionalidad EKM. Para limpiar la clave del Registro, elimina la clave del Registro SQL Server Cryptographic Provider en HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft.

Solución de problemas

Si no se crea la clave del Registro HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SQL Server Cryptographic Provider o no se conceden los permisos necesarios, se producirá un error en la siguiente instrucción DDL:

CREATE ASYMMETRIC KEY EKMSampleASYKey
FROM PROVIDER [AzureKeyVault_EKM]
WITH PROVIDER_KEY_NAME = 'ContosoRSAKey0',
CREATION_DISPOSITION = OPEN_EXISTING;

Msg 33049, Level 16, State 2, Line 65
Key with name 'ContosoRSAKey0' does not exist in the provider or access is denied. Provider error code: 2058.  (Provider Error - No explanation is available, consult EKM Provider for details)

Secretos de cliente que están a punto de expirar

Si la credencial tiene un secreto de cliente que está a punto de expirar, se puede asignar un nuevo secreto a la credencial.

  1. Actualiza el secreto creado originalmente en el Paso 1: Configuración de una entidad de servicio de Microsoft Entra.

  2. Modifique la credencial con la misma identidad y el nuevo secreto con el código siguiente: Reemplace <New Secret> por el nuevo secreto:

    ALTER CREDENTIAL sysadmin_ekm_cred
WITH IDENTITY = 'DocsSampleEKMKeyVault',
SECRET = '<New Secret>';

  3. Reinicie el servicio SQL Server.

Nota:

Si usa EKM en un grupo de disponibilidad (AG), deberá modificar la credencial y reiniciar el servicio DE SQL Server en todos los nodos del grupo de disponibilidad.

Rotación de la clave asimétrica con una nueva clave de AKV o una nueva versión de clave de AKV

Nota:

  • Al rotar manualmente una clave de AKV, SQL Server admite la clave sin versión de AKV o la clave con versiones y no es necesario utilizar una clave de AKV diferente.
  • La clave de AKV original se puede rotar creando una nueva versión que pueda reemplazar la clave anterior originada en SQL Server.
  • Para la rotación manual de claves, se debe crear una nueva clave asimétrica de SQL Server que haga referencia a la clave sin versión o a la clave con versiones rotadas en AKV. Para la nueva clave asimétrica de SQL Server, la clave de AKV sin versión se elegirá automáticamente mediante la versión de clave superior de AKV. Para la clave con versiones, debe indicar la versión superior de AKV mediante la sintaxis WITH PROVIDER_KEY_NAME = <key_name>/<version>. Después puede modificar la clave de cifrado de base de datos para volver a cifrar con la nueva clave asimétrica. El mismo nombre de clave (con versiones o sin versión) se puede usar con la directiva de rotación de AKV. Para la clave con versiones, se debe agregar la versión actual. Para la clave sin versión, utilice el mismo nombre de clave.

SQL Server no tiene un mecanismo para rotar automáticamente el certificado o la clave asimétrica que se utiliza para TDE. Los pasos para rotar una clave asimétrica manualmente son los siguientes.

  1. La credencial utilizaada en la configuración inicial (sysadmin_ekm_cred) también se puede reutilizar para la rotación de claves. Opcionalmente, cree una nueva credencial para la nueva clave asimétrica.

    CREATE CREDENTIAL <new_credential_name>
    WITH IDENTITY = <key vault>,
    SECRET = 'existing/new secret'
    FOR CRYPTOGRAPHIC PROVIDER AzureKeyVault_EKM;

  2. Agregue la credencial al principal:

    ALTER LOGIN [domain\userName];
ADD CREDENTIAL <new_credential_name>;

  3. Cree la nueva clave asimétrica basada en la nueva clave (después de rotar la clave). La nueva clave podría ser una clave sin versión (ContosoRSAKey0 en nuestro ejemplo) o una clave con versiones (ContosoRSAKey0/1a4d3b9b393c4678831ccc60def75379 donde 1a4d3b9b393c4678831ccc60def75379 es la versión de la clave actualizada en AKV):

    CREATE ASYMMETRIC KEY <new_ekm_key_name>
 FROM PROVIDER [AzureKeyVault_EKM]
 WITH PROVIDER_KEY_NAME = <new_key_from_key_vault>,
 CREATION_DISPOSITION = OPEN_EXISTING;

  4. Cree un inicio de sesión a partir de la clave asimétrica nueva:

    CREATE LOGIN <new_login_name>
FROM ASYMMETRIC KEY <new_ekm_key_name>;

  5. Quite la credencial del principal:

    ALTER LOGIN [domain\username]
DROP CREDENTIAL <new_credential_name>;

  6. Asigne las credenciales de AKV al nuevo inicio de sesión:

    ALTER LOGIN <new_login_name>;
ADD CREDENTIAL <new_credential_name>;

  7. Modifique la clave de cifrado de base de datos (DEK) para volver a cifrar con la nueva clave asimétrica:

    USE [databaseName];
GO
ALTER DATABASE ENCRYPTION KEY ENCRYPTION BY SERVER ASYMMETRIC KEY <new_ekm_key_name>;

  8. Puede verificar la nueva clave asimétrica y la clave de cifrado usada en la base de datos:

    SELECT encryptor_type, encryption_state_desc, encryptor_thumbprint
FROM sys.dm_database_encryption_keys
WHERE database_id = DB_ID('databaseName');

    Esta huella digital debe coincidir con la clave del registro en la ruta de acceso HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SQL Server Cryptographic Provider\Azure Key Vault\<key_vault_url>\<thumbprint> y proporcionarle la KeyUri para su clave girada.

Importante

La rotación del protector de TDE lógico para un servidor significa cambiar a una nueva clave asimétrica que protege las bases de datos en el servidor. La rotación de claves es una operación en línea y solo debería tardar unos segundos en completarse, ya que únicamente descifra y vuelve a cifrar la DEK y no toda la base de datos.

No elimine las versiones anteriores de la clave después de una rotación. Cuando las claves se rotan, algunos datos siguen cifrados con las claves anteriores como, por ejemplo, las copias de seguridad de base de datos más antiguas, las copias de seguridad de los archivos de registro, los archivos de registro virtuales (VLF) y los archivos de registro de transacciones. Es posible que las claves anteriores también sean necesarias para recuperar la base de datos o para restaurarla.

Contenido relacionado