Explicación del cifrado de SQL Server: TDE, cifrado a nivel de columna y más

La protección de datos es fundamental para garantizar que su organización cumpla con los estándares normativos como el GDPR y para satisfacer las expectativas de sus clientes y socios comerciales. Las filtraciones de datos no sólo pueden dar lugar a grandes multas, sino que el daño a la reputación puede ser igual de grande. Para ayudar, Microsoft SQL Server admite 5 tipos diferentes de cifrado para proteger los datos. Este artículo explica cada uno de ellos y dónde deben usarse.

Cifrado de transporte SSL

Al igual que los sitios web que protegen el tráfico entre el navegador y el servidor, SQL Server se puede configurar para utilizar Secure Sockets Layer (SSL) para cifrar el tráfico mientras viaja entre la instancia del servidor y la aplicación cliente. Además, el cliente puede validar la identidad del servidor utilizando el certificado del servidor. SSL solo protege los datos mientras viajan por la red, pero, a diferencia de la mayoría de las otras formas de cifrado de SQL Server, SSL está disponible en todas las versiones compatibles de SQL Server y en todas las ediciones.

Antes de habilitar SSL, deberá instalar un certificado en SQL Server. La mejor manera de hacerlo es solicitando un certificado de su propia autoridad de certificación empresarial (CA). Windows Server se puede configurar como CA y usted puede configurar clientes para que confíen en los certificados que emite. Alternativamente, es posible utilizar certificados autofirmados, aunque es más adecuado para entornos de prueba.

Cifrado de datos transparente de SQL Server (TDE)

El cifrado de datos transparente (TDE) en SQL Server protege los datos en reposo cifrando los datos de la base de datos y los archivos de registro en el disco. Funciona de forma transparente para las aplicaciones cliente existentes, por lo que no es necesario cambiarlas cuando TDE está habilitado. TDE utiliza cifrado en tiempo real a nivel de página. Las páginas se cifran antes de escribirse en el disco, sin aumentar el tamaño de sus datos y archivos de registro, y las páginas se descifran cuando se leen en la memoria. TDE está disponible solo en las ediciones Enterprise de SQL Server. También funciona para Azure SQL Database, Azure SQL Data Warehouse y Parallel Data Warehouse.

El cifrado TDE tiene una estructura jerárquica, con la API de protección de datos de Windows (DPAPI) en la parte superior de la jerarquía y se utiliza para cifrar la clave maestra del servicio (SMK). Puede utilizar SMK para cifrar credenciales, contraseñas de servidores vinculados y claves maestras de bases de datos (DMK) que residen en diferentes bases de datos. Una SQL DMK es una clave simétrica que protege las claves privadas de los certificados y las claves asimétricas almacenadas en bases de datos.

SQL Server puede generar certificados autofirmados para usar con TDE o puede solicitar un certificado a una CA (que es el enfoque más común). Si decide habilitar TDE, debe hacer una copia de seguridad del certificado y de la clave privada asociada con el certificado. Deberá restaurar o adjuntar la base de datos en un servidor SQL diferente. Si habilita TDE en cualquier otra base de datos de SQL Server, la base de datos del sistema tempdb también está cifrada. Si desactiva TDE, debe conservar el certificado y la clave privada porque partes del registro de transacciones podrían permanecer cifradas hasta que realice una copia de seguridad completa.

TDE también requiere una clave de cifrado de base de datos (DEK), que es una clave simétrica protegida mediante un certificado almacenado en la base de datos maestra, o una clave asimétrica protegida por un servicio que utiliza administración de claves extensible (EKM), como Bóveda de claves de Microsoft Azure. Los archivos de respaldo de las bases de datos habilitadas para TDE se cifran mediante DEK, por lo que durante las operaciones de restauración, el certificado que protege la DEK debe estar disponible.

Las claves simétricas utilizan la misma contraseña para cifrar y descifrar datos. Las claves asimétricas utilizan una contraseña para cifrar datos (clave pública) y una contraseña diferente para descifrar datos (clave privada). Puede utilizar el comando CREATE CERTIFICATE para crear certificados y los comandos CREATE SYMMETRIC KEY y CREATE ASYMMETRIC KEY de Transact-SQL para crear claves de cifrado de bases de datos.

Cifrado de copia de seguridad

Backup Encryption funciona como TDE pero cifra las copias de seguridad de SQL en lugar de los datos activos y los archivos de registro. Backup Encryption está disponible en SQL Server 2014 y versiones posteriores. Puede especificar cifrado AES 128, AES 192, AES 256 o Triple DES y utilizar un certificado o una clave asimétrica almacenada en EKM. Además, es posible habilitar TDE y Backup Encryption simultáneamente, aunque debes usar certificados o claves diferentes.

Al igual que con TDE, si habilita Backup Encryption, también debe hacer una copia de seguridad del certificado o clave. Sin la clave o el certificado, el archivo de copia de seguridad no se puede utilizar para restaurar datos. Las copias de seguridad también se pueden cifrar cuando se utiliza la copia de seguridad administrada de SQL Server en Microsoft Azure.

Vale la pena señalar que si utiliza un certificado para cifrar las copias de seguridad, debe tener el certificado original al restaurar los datos. Eso significa que el certificado debe tener la misma huella digital que cuando se creó la copia de seguridad. Renovar certificados o cambiarlos de cualquier forma puede provocar que cambie la huella digital.

Cifrado a nivel de columna/celda

Disponible en todas las ediciones de SQL Server, el cifrado a nivel de celda se puede habilitar en columnas que contienen datos confidenciales. Los datos se cifran en el disco y permanecen cifrados en la memoria hasta que se utiliza la función DECRYPTBYKEY para descifrarlos. Por lo tanto, aunque los datos SQL están cifrados, no son seguros más allá de simplemente utilizar una función en el contexto del usuario para descifrarlos. Además, debido a que se necesita una función para descifrar los datos, las aplicaciones cliente deben modificarse para que funcionen con cifrado a nivel de celda.

Gestión de claves de cifrado

Al igual que con TDE, es necesario crear una clave maestra (DMK) antes de utilizar el cifrado a nivel de celda. Hay cuatro opciones para cifrar información mediante cifrado a nivel de celda:

Puede utilizar una frase de contraseña para cifrar y descifrar los datos, pero debe cifrar los procedimientos y funciones almacenados; de lo contrario, se puede acceder a la frase de contraseña en los metadatos.
Las claves asimétricas proporcionan una gran seguridad, pero pueden tener un impacto en el rendimiento.
Las claves simétricas suelen ser lo suficientemente fuertes y proporcionan un buen equilibrio entre seguridad y rendimiento.
Los certificados también proporcionan un buen equilibrio entre seguridad y rendimiento y pueden asociarse con un usuario de base de datos.

Siempre cifrado

Always Encrypted cifra datos confidenciales en aplicaciones cliente sin revelar las claves de cifrado al motor de la base de datos, lo que proporciona separación entre los propietarios y administradores de datos. Por ejemplo, con Always Encrypted habilitado, puede estar seguro de que los administradores de su base de datos no podrán leer datos confidenciales. Como sugiere el nombre, los datos se cifran en reposo y si se usan en un sistema de terceros, como Azure.

Always Encrypted se puede configurar para columnas de bases de datos individuales. Se utilizan dos tipos de claves: claves de cifrado de columnas y claves maestras de columnas. Las claves de cifrado de columnas protegen los datos de una columna y las claves maestras de columnas son "claves de protección de claves" que cifran una o más claves de cifrado de columnas. Las claves maestras de columnas se almacenan en almacenes de claves externos de confianza, como Azure Key Vault.

El proceso de cifrado es transparente para las aplicaciones cliente, pero requiere un controlador especial en las computadoras cliente. Always Encrypted está disponible en SQL Server 2016 y versiones posteriores, pero solo en las ediciones Enterprise. Debido a los requisitos adicionales del lado del cliente, Always Encrypted se adapta mejor a situaciones en las que la separación de propietarios y administradores de datos es un requisito principal.