Introducción

Con la entrada en vigor el año pasado del nuevo Reglamento de Protección de datos a nivel europeo, todos los administradores de bases de datos nos enfrentamos a la tarea de cumplir las obligaciones que este nos impone y entre ellas esta poner todos los mecanismos a nuestro alcance para que los datos estén asegurados, y uno de los mecanismos que nos ofrece Microsoft SQL desde la versión 2008 era el cifrado transparente de datos (TDE). Pues con la nueva versión de SQL 2019 esta opción ha sido mejorada para que tengamos un mejor control a la hora de implementarla en bases de datos muy grandes.

Historia

El Cifrado transparente de datos (TDE) se introdujo originalmente en SQL Server 2008 (Enterprise Edition) con el objetivo de proteger los datos de SQL Server en reposo. En otras palabras, los datos físicos y los archivos de registro, junto con la copia de seguridad de la base de datos que se encuentra en el sistema de archivos, están protegidos (encriptados). No es la única opción que existe por parte de Microsoft SQL para la seguridad de los datos pero es la base para poder complementarla con otras opciones que tenemos disponibles como: seguridad a nivel de línea, TLS, Always Encripted, data masking, …

Hasta SQL 2019 si lanzabamos el proceso de encriptación de TDE y se daban cualquiera de estas dos situaciones: o la base de datos era muy grande o los recursos disponibles del servidor no eran suficiente, podía pasar que el proceso que estabamos lanzando en una ventana de mantenimiento para no interferir con la venta de producción, se fuera de tiempo y entrara en la ventana de producción con las consecuencias que eso conllevaba:

• SQL se recorre todas las paginas de la base de datos para ir encriptandolas, por lo que utiliza recursos de E/S y CPU.
• Durante el tiempo que dura el proceso de encriptación pueden producirse bloqueos por parte del “Encription_Scan” proceso.
• Durante el tiempo que dura el proceso de encriptación el transaction log no se puede truncar, por lo que si aparte del proceso de encriptación también lanzamos tareas de modificación masiva de datos puede que este fichero crezca más del espacio reservado en el disco fisico, por lo que hay que estar monitorizandolo.
• Aparte de una serie de operaciones que no se pueden realizar mientras se esta encriptando la base de datos, que están documentadas en los libros de ayuda de Microsoft: https://docs.microsoft.com/en-us/sql/relational-databases/security/encryption/transparent-data-encryption?view=sql-server-2017#restrictions

Por lo que en versiones anteriores a SQL 2019 , podía existir la tentación de querer parar el proceso cuando veiamos que se nos había ido de tiempo o que estaba perjudicando el rendimiento o que no no nos dejaba realizar las operaciones descritas arriba, lanzando el siguiente comando: ALTER DATABASE DB_Name SET ENCRYPTION OFF. Lo primero que tenemos que saber es que una vez empezado el proceso de encriptación este ya no se puede parar, por tanto este comando solo se ejecutara una vez el proceso de encriptado ha acabado, pero hay no acaba el tema, sino que este comando lo que hace es desencriptar todo lo que se ha encriptado , por lo que al final incluso podemos agravar más la situación.

Para evitar el problema anterior teniamos oculto en las versiones anteriores a SQL 2019 un trace flag 5004 que activamos como siempre utilizando el siguiente comando :

DBCC TRACEON(5004,-1),

este comando  lo que hace es pausar el proceso de encriptación y dejar la base datos encriptada hasta el punto donde se lanzo el comando. Si queremos volver a reanudar el proceso de encriptado debemos de lanzar el comando que deshabilita el trace flag y volver a lanzar el comando de encriptación de la bbdd:

Que es lo nuevo en SQL 2019

Hasta ahora cuando nosotros iniciabamos el proceso de encriptación de la base de datos, solo teníamos la opción de iniciarlo y esperar lo que tardara el proceso hasta que finalizara, y al ser un proceso en segundo plano, la única forma de conecer que este había acabado era realizando una conulta a la DMV  “sys.dm_database_encryption_keys” que contiene una columna que indica el estado de la encriptación “encryption_state”. Los diferentes estados de la encriptación son:

Una de las  mejoras incluidas en esta DMV en SQL 2019 es la incorporación de nuevos campos, uno de ellos es encryption_state_desc que evita tener que hacer una query como esta (hasta sql 2017) para poder tener el mismo dato:

Vamos a ver ahora como podemos utilizar la nueva funcionalidad de “PAUSADO” del proeceso de TDE con SQL 2019:

1.  Lo primero es configurar como seimpre el entorno para poder encriptar la base de datos, una vez creada la clave privada con la que encriptar, lanzamos el proceso de encriptado con el comando  ALTER DATABASE  bbdd SET ENCRYPTION ON.

USE master;  
GO  
CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<UseStrongPasswordHere>';  
go  
CREATE CERTIFICATE MyServerCert WITH SUBJECT = 'My DEK Certificate';  
go  
USE AdventureWorks2017;  
GO  
CREATE DATABASE ENCRYPTION KEY  
WITH ALGORITHM = AES_128  
ENCRYPTION BY SERVER CERTIFICATE MyServerCert;  
GO  
ALTER DATABASE AdventureWorks2017  
SET ENCRYPTION ON;  
GO

Podemos observar si consultamos la vista “sys.dm_database_encryption_keys” como en los campos encriptyion_state_desc tenemos el texto: “ENCRYPTION_IN_PROGRESS” y en el campo encryption_scan_state_desc : “RUNNING”

select * from sys.dm_database_encryption_keys

Si nos vamos al errorlog de SQL podemos observar como se han añadido una linea indicando que el proceso ha empezado

2. Si ahora lanzamos el comando ALTER DATABASE  bbdd SET ENCRYPTION SUSPENDED, para pausar la encriptación y volvemos a consultar la vista “sys.dm_database_encryption_keys” vemos como en los campos encriptyion_state_desc tenemos el texto: “ENCRYPTION_IN_PROGRESS” y en el campo encryption_scan_state_desc : “SUSPENDED”:

ALTER DATABASE AdventureWorks2017  
SET ENCRYPTION SUSPEND;  
GO

select * from sys.dm_database_encryption_keys

En este estado nosotros podríamos por ejemplo truncar el transaction log. Y hay que tener en cuenta que solo estaría encriptado los datos que hasta ese momento se han podido encriptar; aparte de que cualquier dato que durante este estado actualizemos o insertemos en la base de datos se encriptaria. Como podemos observar cuando la encriptración está en modo suspendido el campo porcentaje se pone a 0. Y en el errorlog aparece la siguiente linea:

3. Si ahora lanzamos el comando ALTER DATABASE  bbdd SET ENCRYPTION RESUME, lo que hacemos es reanudar el encriptado desde el punto donde quedo el proceso anteriormente.

ALTER DATABASE AdventureWorks2017  
SET ENCRYPTION RESUME;  
GO

select * from sys.dm_database_encryption_keys

Como podemos observar se vuelve a poner en estado “RUNNING”.

Y como vemos en el errorlog añade otra línea más indicando que vuelve a empezar a encriptar, aquí si que creo que Microsoft no ha elegido la mejor forma de expresar la acción, ya que el texto que inserta es el mismo que cuando lanzas por primera vez la encriptación, por tanto no es de mucha ayuda a la hora de querer encontrar en el errorlog cuando una encriptación se ha reanudado.

CONCLUSION

Con SQL 2019 ahora tenemos la posibilidad de poder pausar la encriptación de una base de datos y poder encajar este proceso dentro de nuestros horarios de mantenimiento de tal manera que nos afecte lo menos posible en horario de producción, ya que habilitar TDE no es algo instantáneo y se debe monitorizar el progreso para evitar posibles problemas. Tenga en cuenta que la base de datos no está totalmente encriptada hasta que el proceso de escaneado y encriptación se haya completado y el estado de encriptación haya cambiado a “ENCRYPTED” y recuerde que no hay reversión para TDE, básicamente, una vez comenzado, para deshabilitar el cifrado en una base de datos, debe permitir que el proceso del escáner de cifrado finalice primero.