La protección de datos es fundamental para garantizar que su organización cumpla con los estándares de cumplimiento normativo, como el RGPD, y para satisfacer las expectativas de sus clientes y socios comerciales. Las filtraciones de datos no solo pueden resultar en 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 usar la capa de sockets seguros (SSL) para cifrar el tráfico a medida que viaja entre la instancia del servidor y la aplicación cliente. Además, el cliente puede validar la identidad del servidor mediante el certificado del servidor. SSL solo protege los datos a medida que 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, deberá instalar un certificado en SQL Server. La mejor manera de hacerlo es solicitando un certificado de su propia entidad de certificación empresarial (CA). Windows Server se puede configurar como una CA y puede configurar clientes para que confíen en los certificados que emite. Alternativamente, es posible usar certificados autofirmados, aunque esto es lo más adecuado para entornos de prueba.

Cifrado transparente de datos (TDE) de SQL Server

El cifrado transparente de datos (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 existentes del cliente, por lo que no es necesario cambiarlas cuando se habilita TDE. TDE utiliza cifrado en tiempo real a nivel de página. Las páginas se cifran antes de escribirlas 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 solo está disponible 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) situada en la parte superior de la jerarquía y utilizada para cifrar la clave maestra de servicio (SMK). Puede usar el SMK para cifrar credenciales, contraseñas de servidores vinculados y las claves maestras de la base de datos (DMK) que residen en diferentes bases de datos. Una DMK 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 al certificado. Necesitará 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 se cifra. Si deshabilita TDE, debe conservar el certificado y la clave privada, ya que 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 Microsoft Azure Key Vault. Los archivos de copia de seguridad de las bases de datos habilitadas para TDE se cifran mediante el DEK, por lo que durante las operaciones de restauración, el certificado que protege el 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 usar el comando CREATE CERTIFICATE para crear certificados, y los comandos CREATE SYMMETRIC KEY y CREATE ASYMMETRIC KEY Transact-SQL para crear claves de cifrado de base de datos.

Cifrado de copia de seguridad

El cifrado de copia de seguridad funciona como TDE, pero cifra las copias de seguridad SQL en lugar de los datos activos y los archivos de registro. El cifrado de copias de seguridad 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 el cifrado TDE y de copia de seguridad simultáneamente, aunque debe usar diferentes certificados o claves.

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

Vale la pena señalar que si está utilizando un certificado para cifrar copias de seguridad, debe tener el certificado original al restaurar datos. Esto 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, 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á del simple uso de 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.

Administración de claves de cifrado

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

• Puede usar 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 se pueden asociar a un usuario de base de datos.

Siempre cifrado

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

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

El proceso de cifrado es transparente para las aplicaciones cliente, pero requiere un controlador especial en los equipos cliente. Siempre cifrado 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 el más adecuado para situaciones en las que la separación de propietarios y administradores de datos es un requisito principal.

consultor y autor especializado en gestión y tecnologías de seguridad. Russell tiene más de 15 años de experiencia en TI, ha escrito un libro sobre seguridad de Windows y es coautor de un texto para la serie de Cursos Académicos Oficiales de Microsoft (MOAC).