Compartir por

Always Encrypted con enclaves seguros

  • Artigo

Se aplica a: SQL Server 2019 (15.x) y versiones posteriores: 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 versiones posteriores, así como en 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 del 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 el 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:

Diagrama del flujo de datos para Always Encrypted.

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.

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 (vea la sección Atestación de enclaves seguros más adelante). Para obtener más información, incluida la lista de controladores cliente admitidos, consulte Desarrollo de aplicaciones con Always Encrypted.

Tecnologías de enclave admitidas

Always Encrypted admite las siguientes tecnologías de enclave (o tipos de enclave):

El tipo de enclave disponible para la base de datos depende del producto SQL que lo hospede (Azure SQL Database frente a SQL Server) y (en el caso de Azure SQL Database) la configuración de la base de datos.

  • En SQL Server 2019 (15.x) y versiones posteriores, Always Encrypted admite enclaves de VBS. (No se admiten enclaves de Intel SGX).

  • En Azure SQL Database, una base de datos puede usar un enclave de Intel SGX o un enclave de VBS, en función del hardware en el que se configure la base de datos para ejecutarse:

    • Las bases de datos que utilizan la configuración de hardware de la serie DC (disponible con el modelo de compra vCore) utilizan enclaves Intel SGX.
    • Las bases de datos que usan una configuración distinta de la serie DC con el modelo de compra vCore y las bases de datos que usan el modelo de compra de DTU se pueden configurar para usar enclaves de VBS.

    Nota:

    Los enclaves de VBS están actualmente disponibles en todas las regiones de Azure SQL Database, excepto: Jio India Central.

Consulte la sección Consideraciones de seguridad para obtener información importante sobre la protección de nivel que proporciona cada tipo de enclave.

Atestación de enclaves seguros

La atestación de enclave es un mecanismo de defensa en profundidad que puede ayudar a detectar ataques que implican alteraciones con el código de enclave o su entorno por parte de administradores malintencionados.

La atestación de enclave permite a una aplicación cliente establecer la confianza con el enclave seguro para la base de datos, la aplicación se conecta antes de que la aplicación use el enclave para procesar datos confidenciales. El flujo de trabajo de atestación comprueba que el enclave es un enclave de VBS o Intel SGX auténtico y el código que se ejecuta dentro de él es la biblioteca de enclave original firmada por Microsoft para Always Encrypted. Durante la atestación, tanto el controlador cliente dentro de la aplicación como el motor de base de datos se comunican con un servicio de atestación externo mediante un punto de conexión especificado por el cliente.

Always Encrypted puede usar uno de los dos servicios de atestación:

Para habilitar Always Encrypted con enclaves seguros para la aplicación, debe establecer un protocolo de atestación en la configuración del controlador cliente de la aplicación. Un valor de protocolo de atestación determina si 1) la aplicación cliente usará la atestación y, si es así, 2) especifica el tipo del servicio de atestación que usará. En la tabla siguiente se muestran los protocolos de atestación admitidos para las combinaciones válidas de tipo de enclave y producto SQL:

Producto que hospeda Tipo de enclave Protocolos de atestación admitidos
SQL Server 2019 (15.x) y posterior Enclaves de VBS HGS, sin atestación
Azure SQL Database Enclaves SGX (bases de datos de la serie DC) Microsoft Azure Attestation
Azure SQL Database Enclaves de VBS Sin atestación

Algunos aspectos importantes que se deben destacar:

  • La atestación de enclaves de VBS en SQL Server 2019 (15.x) y versiones posteriores requiere HGS. También puede usar enclaves de VBS sin atestación (se requieren los controladores de cliente más recientes).
  • Con enclaves de Intel SGX (en bases de datos de la serie DC) en Azure SQL Database, la atestación es obligatoria y requiere Microsoft Azure Attestation.
  • Los enclaves de VBS en Azure SQL Database no admiten la atestación.

Para más información, vea:

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 de columna master con la propiedad ENCLAVE_COMPUTATIONS especificada en el objeto de metadatos de clave de columna master dentro de la base de datos. El objeto de metadatos de clave maestra de columna master 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 de columna master 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 de las operaciones de 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

Nota:

SQL Server 2022 (16.x) agrega compatibilidad adicional para consultas confidenciales con operaciones JOIN, GROUP BY y ORDER BY en columnas cifradas.

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:

Operación Azure SQL Database SQL Server 2022 (16.x) SQL Server 2019 (15.x)
Operadores de comparación Compatible Admitido Compatible
BETWEEN (Transact-SQL) Compatible Admitido Compatible
IN (Transact-SQL) Compatible Admitido Compatible
LIKE (Transact-SQL) Compatible Admitido Compatible
DISTINCT Compatible Admitido Compatible
Combinaciones Compatible Compatible Solo se admiten combinaciones de bucle anidadas
SELECT: Cláusula ORDER BY (Transact-SQL) Compatible Admitido No compatible
SELECT: GROUP BY (Transact-SQL) Compatible Admitido No compatible

Nota:

Las operaciones anteriores dentro de enclaves seguros requieren cifrado aleatorio. No se admite el cifrado determinista. La comparación de igualdad sigue siendo la operación disponible para las columnas mediante cifrado determinista.

El nivel de compatibilidad de la base de datos debe estar establecido en SQL Server 2022 (160) o superior.

En Azure SQL Database y en SQL Server 2022 (16.x), en las consultas confidenciales que utilizan enclaves en una columna de cadena de caracteres (char, nchar) es necesario que la columna use una intercalación de punto de código binario (_BIN2) o una intercalación UTF-8. En SQL Server 2019 (15.x), se requiere una intercalación_BIN2.

Para obtener más información, vea Ejecución de instrucciones Transact-SQL con enclaves seguros.

Í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 el Motor de base de datos, vea el artículo Í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.

Importante

Microsoft recomienda encarecidamente habilitar la recuperación de base de datos acelerada (ADR) para la base de datos antes de crear el primer índice en una columna habilitada para enclave que se ha cifrado con cifrado aleatorio. ADR está habilitada de forma predeterminada en Azure SQL Database, pero no en SQL Server 2019 (15.x) y versiones posteriores.

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.

  • Los enclaves de VBS ayudan a proteger los datos frente a ataques dentro de la máquina virtual. Además, independientemente de la atestación, los enclaves de VBS no proporcionan protección frente a ataques mediante cuentas de sistema con privilegios que se originan en el host. Los enclaves de Intel SGX protegen los datos frente a ataques que se originan en el sistema operativo invitado y en el sistema operativo host.
  • Se recomienda usar la atestación de enclave si está disponible para su entorno y si le preocupa proteger los datos frente a ataques por parte de los usuarios con acceso de administrador de nivel de sistema operativo a la máquina que hospeda la base de datos. Si usa la atestación, debe asegurarse de que un administrador de confianza administra el servicio de atestación y su configuración. Además, ambos servicios de atestación ofrecen distintas directivas y modos 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 usas Always Encrypted para proteger los datos confidenciales del acceso no autorizado por los administradores de base de datos, no compartas las claves de columna master 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

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.

Restricciones 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 Limitaciones 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 o SQL Server 2022 (16.x)) solo se admiten combinaciones de bucle anidadas (con índices, si están disponibles) en las columnas habilitadas para 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 master habilitadas para el enclave son Almacén de certificados de Windows y Azure Key Vault.
    • 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 Azure Data Studio, 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 de Always Encrypted en SQL Server Management Studio no admiten el cifrado local. Mueva los datos de la base de datos para las operaciones de cifrado, incluso si las claves de cifrado de columna usadas para las operaciones están habilitadas para el enclave.
  • Al restaurar una base de datos habilitada para un enclave de VBS, es esencial volver a reconfigurar el enclave de VBS.

Contenido relacionado