Always Encrypted con enclaves seguros

Se aplica a: SQL Server 2019 (15.x) - Solo Windows Azure SQL Database

Always Encrypted con enclaves seguros amplía las funciones de computación confidenciales de Always Encrypted mediante la habilitación del cifrado en contexto y consultas confidenciales más enriquecidas. Always Encrypted con enclaves seguros está disponible en SQL Server 2019 (15.x) y Azure SQL Database.

Presentado en Azure SQL Database en 2015 y en SQL Server 2016 (13.x), Always Encrypted protege la confidencialidad de los datos confidenciales frente a malware y usuarios no autorizados con privilegios elevados: administradores de bases de datos (DBA), administradores de equipos, administradores de la nube o cualquiera que tenga acceso legítimo a instancias de servidor, hardware, etc., pero que no deba tener acceso a algunos o todos los datos reales.

Sin las mejoras que se describen en este artículo, Always Encrypted protege los datos mediante su cifrado en el lado cliente y nunca permite que los datos ni las claves criptográficas correspondientes aparezcan en texto no cifrado dentro de Motor de base de datos. Como resultado, la funcionalidad en columnas cifradas dentro de la base de datos está muy restringida. Las únicas operaciones que Motor de base de datos puede realizar con datos cifrados son las comparaciones de igualdad (solo están disponibles con cifrado determinista). Todas las demás operaciones, incluidas las criptográficas (el cifrado inicial de los datos o la rotación de claves) y las consultas más completas (por ejemplo, la coincidencia de patrones) no se admiten dentro de la base de datos. Los usuarios tienen que sacar sus datos de la base de datos para llevar a cabo estas operaciones en el cliente.

Always Encrypted con enclaves seguros aborda estas limitaciones al permitir realizar algunos cálculos en datos de texto no cifrado dentro de un enclave seguro en el lado servidor. Un enclave seguro es una región de memoria protegida dentro del proceso del Motor de base de datos. El enclave seguro aparece como una caja opaca para el resto del Motor de base de datos y los otros procesos en el equipo de host. No hay ninguna manera de ver los datos ni el código que se encuentran dentro del enclave desde el exterior, incluso si se cuenta con un depurador. Estas propiedades hacen que el enclave seguro sea un entorno de ejecución de confianza que puede acceder de forma segura a claves criptográficas y datos confidenciales en texto no cifrado sin poner en peligro la confidencialidad de los datos.

Always Encrypted usa enclaves seguros, tal como se muestra en el siguiente diagrama:

Al analizar una instrucción de Transact-SQL enviada por una aplicación, el Motor de base de datos determina si la instrucción contiene alguna operación realizada en datos cifrados para la que es necesario usar el enclave seguro. Para este tipo de instrucciones:

• El controlador cliente envía las claves de cifrado de columna necesarias para las operaciones al enclave seguro (a través de un canal seguro) y remite la instrucción para que se ejecute.

• Al procesar la instrucción, el Motor de base de datos delega en el enclave seguro los cálculos o las operaciones criptográficas sobre columnas cifradas. Si es necesario, el enclave descifra los datos y realiza cálculos en texto no cifrado.

Durante el procesamiento de instrucciones, las claves de cifrado de columna y los datos no se exponen en texto no cifrado en el Motor de base de datos fuera del enclave seguro.

Tecnologías de enclave admitidas

En SQL Server 2019 (15.x), Always Encrypted con enclaves seguros usa enclaves seguros de memoria de Seguridad basada en virtualización (VBS) (también conocidos como enclaves de Modo seguro virtual, VSM) en Windows.

En Azure SQL Database, Always Encrypted con enclaves seguros usa enclaves de Software Guard Extensions de Intel (Intel SGX). Intel SGX es una tecnología de entorno de ejecución de confianza basada en hardware que se admite en las bases de datos que usan la configuración de hardware de la serie DC.

Atestación de enclaves seguros

El enclave seguro dentro del Motor de base de datos puede acceder a datos confidenciales y a las claves de cifrado de columna en texto no cifrado. Por tanto, antes de enviar al Motor de base de datos una instrucción que implique cálculos de enclave, el controlador cliente dentro de la aplicación debe comprobar que el enclave seguro es un enclave de VBS o SGX legítimo, y que el código que se ejecuta dentro del enclave seguro es la biblioteca de Always Encrypted original que implementa algoritmos criptográficos de Always Encrypted para el cifrado en contexto y las operaciones que se admiten en consultas confidenciales.

El proceso de comprobación del enclave se denomina atestación del enclave e implica que un controlador cliente dentro de la aplicación y Motor de base de datos se deben poner en contacto con un servicio de atestación externo. Los detalles específicos del proceso de atestación dependen del tipo de enclave (VBS o SGX) y del servicio de atestación.

El proceso de atestación para enclaves seguros de VBS en SQL Server 2019 (15.x) es la atestación en tiempo de ejecución Protección del sistema de Windows Defender, para la que se necesita el Servicio de protección de host (HGS) como servicio de atestación.

Para la atestación de enclaves de Intel SGX en Azure SQL Database se necesita Microsoft Azure Attestation.

Controladores cliente admitidos

Para usar Always Encrypted con enclaves seguros, una aplicación debe usar un controlador cliente que admita la característica. Configure la aplicación y el controlador cliente para habilitar los cálculos y la atestación de enclaves. Para obtener más información, incluida la lista de controladores cliente admitidos, consulte Desarrollo de aplicaciones con Always Encrypted.

Terminología

Claves habilitadas para el enclave

Always Encrypted con enclaves seguros presenta el concepto de las claves habilitadas para el enclave:

• Clave maestra de columna habilitada para el enclave: clave maestra de columna con la propiedad ENCLAVE_COMPUTATIONS especificada en el objeto de metadatos de clave maestra de columna dentro de la base de datos. El objeto de metadatos de clave maestra de columna también debe contener una signatura válida de las propiedades de los metadatos. Para obtener más información, vea CREATE COLUMN MASTER KEY (Transact-SQL).
• Clave de cifrado de columna habilitada para el enclave: una clave de cifrado de columna cifrada con una clave maestra de columna habilitada para el enclave. Para los cálculos dentro del enclave seguro, solo se pueden usar claves de cifrado de columna habilitadas para el enclave.

Para obtener más información, consulte Administración de claves para Always Encrypted con enclaves seguros.

Columnas habilitadas para el enclave

Una columna habilitada para el enclave es una columna de base de datos cifrada con una clave de cifrado de columna habilitada para el enclave.

Funciones de computación confidencial para las columnas habilitadas para el enclave

Las dos ventajas principales de Always Encrypted con enclaves seguros son el cifrado en contexto y las consultas confidenciales enriquecidas.

Cifrado en contexto

El cifrado en contexto permite operaciones criptográficas en las columnas de base de datos dentro del enclave seguro, sin mover los datos fuera de la base de datos. El cifrado en contexto mejora el rendimiento y la confiabilidad del cifrado. Puede realizar el cifrado en contexto mediante la instrucción ALTER TABLE (Transact-SQL).

Las operaciones criptográficas que se admiten en contexto son las siguientes:

• Cifrado de una columna en texto no cifrado con una clave de cifrado de columna habilitada para el enclave.
• Nuevo cifrado de una columna cifrada habilitada para el enclave a fin de:
  • Rotar una clave de cifrado de columna: vuelva a cifrar la columna con una nueva clave de cifrado de columna habilitada para el enclave.
  • Cambiar el tipo de cifrado de una columna habilitada para el enclave, por ejemplo, de determinista a aleatorio.
• Descifrado de los datos almacenados en una columna habilitada para el enclave (conversión de la columna en una columna de texto no cifrado).

El cifrado en contexto se permite con el cifrado determinista y aleatorio, siempre que las claves de cifrado de columna implicadas en una operación criptográfica estén habilitadas para el enclave.

Consultas confidenciales

Las consultas confidenciales son consultas DML que implican operaciones en columnas habilitadas para el enclave realizadas dentro del enclave seguro.

Las operaciones admitidas dentro de los enclaves seguros son las siguientes:

Índices en columnas habilitadas para el enclave

Puede crear índices no agrupados en columnas habilitadas para el enclave mediante cifrado aleatorio con el fin de acelerar la ejecución de las consultas DML confidenciales que usen el enclave seguro.

Para asegurarse de que un índice en una columna cifrada mediante cifrado aleatorio no pierda datos confidenciales, los valores de clave de la estructura de datos de índice (árbol B) se cifran y se ordenan según sus valores de texto no cifrado. La ordenación por el valor de texto no cifrado también es útil para procesar consultas dentro del enclave. Cuando el ejecutor de consultas del Motor de base de datos utiliza un índice en una columna cifrada para realizar cálculos dentro del enclave, busca el índice para consultar valores específicos almacenados en la columna. Cada búsqueda puede suponer varias comparaciones. El ejecutor de consultas delega cada comparación en el enclave, que descifra un valor almacenado en la columna y el valor del índice cifrado que se va a comparar, realiza la comparación en texto sin cifrar y devuelve el resultado de la comparación al ejecutor.

Sigue sin admitirse la creación de índices en columnas que usan cifrado aleatorio y no están habilitadas para el enclave.

Un índice en una columna que usa cifrado determinista se ordena según el texto cifrado (no texto no cifrado), con independencia de que la columna esté o no habilitada para el enclave.

Para más información, vea Creación y uso de índices en columnas de Always Encrypted con enclaves seguros. Para obtener información general sobre el funcionamiento de la indexación en Motor de base de datos, vea Índices agrupados y no agrupados descritos.

Recuperación de base de datos

Si se produce un error en una instancia de SQL Server, sus bases de datos pueden quedar en un estado donde los archivos de datos pueden contener algunas modificaciones por transacciones incompletas. Cuando se inicia la instancia, se ejecuta un proceso denominado recuperación de bases de datos, que supone revertir las transacciones incompletas encontradas en el registro de transacciones para asegurarse de que se preserva la integridad de la base de datos. Si una transacción incompleta realizó algún cambio en un índice, puede que también sea necesario deshacer esos cambios. Por ejemplo, puede que haya que quitar o volver a insertar algunos valores de clave del índice.

Con el proceso de recuperación de base de datos tradicional (que sigue al modelo de recuperación ARIES), para deshacer un cambio en un índice, SQL Server debe esperar a que una aplicación proporcione la clave de cifrado de la columna al enclave, lo que puede tardar mucho tiempo. La Recuperación acelerada de la base de datos (ADR) reduce considerablemente el número de operaciones de deshacer que se deben aplazar porque una clave de cifrado de columna no está disponible en la caché dentro del enclave. Por lo tanto, aumenta considerablemente la disponibilidad de la base de datos, ya que reduce la posibilidad de que una nueva transacción se bloquee. Con ADR habilitado, es posible que SQL Server todavía necesite una clave de cifrado de columna para completar la limpieza de las versiones de datos antiguas, pero lo hace como una tarea en segundo plano que no afecta a la disponibilidad de la base de datos ni a las transacciones del usuario. Es posible que vea mensajes de error en el registro de errores, que indican operaciones de limpieza incorrectas debido a que falta una clave de cifrado de columna.

Consideraciones sobre la seguridad

Se aplican las siguientes consideraciones de seguridad a Always Encrypted con enclaves seguros.

• La seguridad de los datos en el enclave depende de un protocolo de atestación y un servicio de atestación. Por lo tanto, debe asegurarse de que el servicio de atestación y las directivas de atestación, que impone el servicio, sean administrados por un administrador de confianza. Además, los servicios de atestación suelen admitir distintas directivas y protocolos de atestación, algunos de los cuales realizan la comprobación mínima del enclave y su entorno, y están diseñados para desarrollo y pruebas. Siga atentamente las instrucciones específicas para el servicio de atestación a fin de asegurarse de que usa las directivas y configuraciones recomendadas para las implementaciones en producción.
• El cifrado de una columna mediante cifrado aleatorio con una clave de cifrado de columna habilitada para el enclave puede dar lugar a una pérdida del orden de los datos almacenados en la columna, ya que ese tipo de columnas admiten comparaciones de rangos. Por ejemplo, si una columna cifrada, que contiene los salarios de los empleados, tiene un índice, un administrador de base de datos malintencionado podría examinar el índice para buscar el valor cifrado de salario máximo e identificar a una persona con el salario máximo (siempre que el nombre de la persona no esté cifrado).
• Si usa Always Encrypted para proteger los datos confidenciales del acceso no autorizado por los administradores de base de datos, no comparta las claves maestras de columna ni las claves de cifrado de columna con ellos. Un administrador de base de datos puede administrar índices en columnas cifradas sin tener acceso directo a las claves, y usar la caché de claves de cifrado de columna dentro del enclave.

Consideraciones sobre continuidad empresarial, recuperación ante desastres y migración de datos

Al configurar una solución de alta disponibilidad o de recuperación ante desastres para una base de datos mediante Always Encrypted con enclaves seguros, asegúrese de que todas las réplicas de base de datos pueden usar un enclave seguro. Si hay un enclave disponible para la réplica principal, pero no para la secundaria, se producirá un error en cualquier instrucción que intente usar la funcionalidad de Always Encrypted con enclaves seguros después de la conmutación por error.

Al copiar o migrar una base de datos mediante Always Encrypted con enclaves seguros, asegúrese de que el entorno de destino siempre admite los enclaves. De lo contrario, las instrucciones que usen enclaves no funcionarán en la copia ni en la base de datos migrada.

Estas son las consideraciones específicas que se deben tener en cuenta:

• SQL Server

  • Al configurar un grupo de disponibilidad Always On, asegúrese de que todas las instancias de SQL Server en las que se hospeda una base de datos del grupo de disponibilidad admitan Always Encrypted con enclaves seguros y tengan un enclave y la atestación configurados.
  • Al restaurar desde un archivo de copia de seguridad de una base de datos que usa la funcionalidad de Always Encrypted con enclaves seguros en una instancia de SQL Server que no tiene el enclave configurado, la operación de restauración se realizará correctamente y estará disponible toda la funcionalidad que no se base en el enclave. Pero se producirá un error en las instrucciones posteriores que usen la funcionalidad de enclave, y los índices de las columnas habilitadas para el enclave que usen el cifrado aleatorio dejarán de ser válidos. Lo mismo se aplica al adjuntar una base de datos que usa Always Encrypted con enclaves seguros en la instancia que no tiene configurado el enclave.
  • Si la base de datos contiene índices en columnas habilitadas para el enclave mediante cifrado aleatorio, asegúrese de habilitar Recuperación de la base de datos acelerada (ADR) en la base de datos antes de crear una copia de seguridad de base de datos. ADR garantizará que la base de datos, incluidos los índices, está disponible inmediatamente después de restaurarla. Para más información, consulte Recuperación de la base de datos.

• Azure SQL Database

  • Al configurar la replicación geográfica activa, asegúrese de que una base de datos secundaria admita los enclaves seguros, si la principal lo hace.

En SQL Server y Azure SQL Database, cuando migre su base de datos mediante un archivo bacpac, debe asegurarse de quitar todos los índices de las columnas habilitadas para el enclave con cifrado aleatorio antes de crear el archivo bacpac.

Limitaciones conocidas

Always Encrypted con enclaves seguros soluciona algunas limitaciones de Always Encrypted al admitir el cifrado en contexto y las consultas confidenciales más enriquecidas con índices, como se explica en Funciones de computación confidencial para las columnas habilitadas para el enclave.

El resto de limitaciones de Always Encrypted enumeradas en Detalles de la característica también se aplican a Always Encrypted con enclaves seguros.

Las siguientes limitaciones son específicas de Always Encrypted con enclaves seguros:

• No se pueden crear índices agrupados en columnas habilitadas para enclave que usan cifrado aleatorio.
• Las columnas habilitadas para enclave que usan cifrado aleatorio no pueden ser columnas de clave principales y no se puede hacer referencia a ellas con restricciones de clave externa o restricciones de clave única.
• En SQL Server 2019 (15.x) (esta limitación no se aplica a Azure SQL Database) solo se admiten las combinaciones de bucle anidadas (con índices, si están disponibles) en las columnas habilitadas para el enclave mediante el cifrado aleatorio. Para obtener información sobre otras diferencias entre los distintos productos, vea Consultas confidenciales.
• Las operaciones criptográficas en contexto no se pueden combinar con ningún otro cambio de metadatos de columna, excepto los cambios de intercalación dentro de la misma página de código y nulabilidad. Por ejemplo, no puede cifrar, volver a cifrar ni descifrar una columna y cambiar un tipo de datos de la columna en una sola instrucción ALTER TABLE/ALTER COLUMN de Transact-SQL. Use dos instrucciones independientes.
• No se admite el uso de claves habilitadas para enclave en columnas de tablas en memoria.
• Las expresiones que definen columnas calculadas no pueden realizar cálculos en columnas habilitadas para el enclave mediante el cifrado aleatorio (aunque los cálculos se encuentren ente las operaciones admitidas que se enumeran en Consultas confidenciales).
• Los caracteres de escape no se admiten en los parámetros del operador LIKE en las columnas habilitadas para enclave mediante el cifrado aleatorio.
• Las consultas con el operador LIKE o un operador de comparación que tiene un parámetro de consulta que usa uno de los siguientes tipos de datos (que se convierten en objetos grandes después del cifrado) pasan por alto los índices y realizan recorridos de tabla.
  • nchar[n] y nvarchar[n], si "n" es mayor que 3967.
  • char[n], varchar[n], binary[n] y varbinary[n], si "n" es mayor que 7935.
• Limitaciones de las herramientas:
  • Los únicos almacenes de claves que se admiten para almacenar claves maestras de columna habilitadas para el enclave son Almacén de certificados de Windows y Azure Key Vault.
  • No se admite la importación o exportación de bases de datos que contienen claves habilitadas para el enclave.
  • Para desencadenar una operación criptográfica en contexto a través de ALTER TABLE/ALTER COLUMN, debe emitir la instrucción mediante una ventana de consulta en SSMS, o bien puede escribir su propio programa que emita la instrucción. Actualmente, el cmdlet Set-SqlColumnEncryption del módulo SqlServer de PowerShell y el asistente para Always Encrypted en SQL Server Management Studio no admiten el cifrado en contexto, sino que sacan los datos de la base de datos para realizar operaciones criptográficas, incluso si las claves de cifrado de columna que se usan en estas operaciones están habilitadas para el enclave.

Pasos siguientes

• Tutorial: Introducción a Always Encrypted con enclaves seguros en SQL Server
• Tutorial: Introducción a Always Encrypted con enclaves seguros en Azure SQL Database
• Configuración y uso de Always Encrypted con enclaves seguros
• Ejecución de Always Encrypted con ejemplos y demostraciones de enclaves seguros en el repositorio de GitHub Ejemplos de SQL Server
• Más información acerca de la computación confidencial de Azure

Consulte también

• Administración de claves para Always Encrypted con enclaves seguros