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

La protección de datos es crítica para asegurar que su organización cumpla con los estándares de cumplimiento regulatorio como el GDPR y para satisfacer las expectativas de sus clientes y socios comerciales. No solo las violaciones de data breaches pueden resultar en grandes multas, sino que el daño a la reputación puede ser igual de grande. Para ayudar, Microsoft SQL Server soporta 5 tipos diferentes de cifrado para proteger los datos. Este artículo explica cada uno de ellos y dónde deben utilizarse.

Cifrado de transporte SSL

Al igual que los sitios web que aseguran el tráfico entre el navegador y el servidor, SQL Server puede configurarse para usar 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 a través de 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, necesitará instalar un certificado en el SQL Server. La mejor manera de hacerlo es solicitando un certificado de su propia autoridad de certificación empresarial (CA). Windows Server puede configurarse como una CA y puede configurar los clientes para que confíen en los certificados que emite. Alternativamente, es posible utilizar certificados autofirmados, aunque esto es más adecuado para entornos de prueba.

SQL Server Transparent Data Encryption (TDE)

Transparent Data Encryption (TDE) en SQL Server protege los datos en reposo cifrando los datos de la base de datos y los archivos de registro en disco. Funciona de manera transparente para las aplicaciones de clientes existentes, por lo que no necesitan ser modificadas cuando se habilita TDE. TDE utiliza cifrado en tiempo real a nivel de página. Las páginas se cifran antes de ser escritas en disco, sin aumentar el tamaño de tus archivos de datos y registros, y las páginas se descifran al ser leídas en 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.

La encriptación TDE tiene una estructura jerárquica, con la API de Protección de Datos de Windows (DPAPI) en la cima de la jerarquía y se utiliza para encriptar la clave maestra del servicio (SMK). Puedes usar la SMK para encriptar credenciales, contraseñas de servidores vinculados y las claves maestras de la base de datos (DMKs) que residen en diferentes bases de datos. Una DMK de SQL es una clave simétrica que protege las claves privadas de certificados y claves asimétricas almacenadas en bases de datos.

SQL Server puede generar certificados autofirmados para usar con TDE o puede solicitar un certificado de 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. Necesitará restaurar o adjuntar la base de datos en un SQL Server diferente. Si habilita TDE en cualquier otra base de datos de SQL Server, la base de datos del sistema tempdb también se cifra. Si deshabilita 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 la Gestión de Claves Extensible (EKM), como Microsoft Azure Key Vault. Los archivos de respaldo de las bases de datos habilitadas para TDE están cifrados utilizando la 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 usan una contraseña para cifrar datos (clave pública) y otra diferente para descifrar datos (clave privada). Puede usar el comando CREATE CERTIFICATE para crear certificados, y los comandos Transact-SQL CREATE SYMMETRIC KEY y CREATE ASYMMETRIC KEY para crear claves de cifrado de base de datos.

Cifrado de copias de seguridad

La encriptación de respaldo funciona como TDE pero encripta las copias de seguridad de SQL en lugar de los archivos de datos activos y de registro. La encriptación de respaldo está disponible en SQL Server 2014 y versiones posteriores. Puede especificar AES 128, AES 192, AES 256 o encriptación Triple DES, y usar ya sea un certificado o una clave asimétrica almacenada en EKM. Además, es posible habilitar TDE y la encriptación de respaldo simultáneamente, aunque debería usar diferentes certificados o claves.

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 certificado, el archivo de respaldo no se puede utilizar para restaurar datos. Las copias de seguridad también pueden cifrarse al usar SQL Server Managed Backup to Microsoft Azure.

Es importante destacar 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 los certificados o cambiarlos de cualquier manera puede hacer que la huella digital cambie.

Cifrado a nivel de columna/celda

Disponible en todas las ediciones de SQL Server, se puede habilitar el cifrado a nivel de celda en columnas que contienen datos sensibles. Los datos están cifrados en disco y permanecen cifrados en memoria hasta que se utiliza la función DECRYPTBYKEY para descifrarlos. Por lo tanto, aunque los datos de SQL están cifrados, no están seguros más allá de simplemente usar 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 trabajar con el cifrado a nivel de celda.

Gestión de Claves de Cifrado

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

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

Always Encrypted

Always Encrypted cifra datos sensibles en aplicaciones cliente sin revelar las claves de cifrado al motor de base de datos, proporcionando separación entre los propietarios de los datos y los gestores de los mismos. Por ejemplo, con Always Encrypted habilitado, puedes estar seguro de que tus administradores de base de datos no podrán leer datos sensibles. Como sugiere el nombre, los datos están cifrados en reposo y si se utilizan en un sistema de terceros, como Azure.

Always Encrypted puede configurarse para columnas individuales de la base de datos. Se utilizan dos tipos de claves: claves de cifrado de columna y claves maestras de columna. Las claves de cifrado de columna protegen los datos en una columna y las claves maestras de columna son ‘claves que protegen claves’ que cifran una o más claves de cifrado de columna. Las claves maestras de columna se almacenan en almacenes de claves externos y confiables, 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 es más adecuado para situaciones en las que la separación de los propietarios y administradores de datos es un requisito primordial.