Cifrado de base de datos SQL Server por TDE

Publicado el 8 comentarios Etiquetas: , , , ,

caCatalà

En esta entrada veremos como cifrar una base de datos con SQL Server mediante el Transparent Data Encryption (TDE), ya sea por seguridad como para dar cumplimiento a alguna normativa que aplica, como por ejemplo el Reglamento General de Protección de Datos (RGPD o GDPR para los amigos) de la Unión Europea, aprobado el 27 de abril de 2016 y que será aplicable a partir del 25 de mayo de 2018. Con multas muy considerables en caso de incumplimiento del mismo que pueden ser hasta los 20 millones de euros o bien el 4% del volumen de negocio total anual global del ejercicio financiero anterior. Por lo tanto, no es una cosa que se tenga que obviar.

Casi todos los fabricantes de software que conozco van como locos para aplicar las nuevas medidas pedidas, que no son pocas y que en muchos casos afectan el núcleo de las aplicaciones que requerirán cambios profundos, pero también sé de muchas aplicaciones que no se volverán a diseñar, ya sea porque tienen sus años y sólo se encuentran en mantenimiento, porque el fabricante ha desaparecido o por los costes que esto supone.

Mediante el cifrado de base de datos minimizamos el impacto negativo que pueda haber en las aplicaciones que no podrán aplicar la pseudonimización de los datos, así como un complemento al que pide la nueva reglamentación en los artículos 6, 32 y 34.

Lo más recomendable hoy día es utilizar tecnologías de cifrado fuerte por defecto, sobre todo en entornos donde es más fácil acceder directamente a los datos o servidores.

Video del artículo en Youtube.

 

¿Qué es el cifrado de base de datos TDE?

El cifrado de base de datos SQL Server mediante el Transparent Data Encryption (TDE) se encuentra disponible en las versiones 2008, 2008 R2, 2012, 2014 y 2016, pero sólo en las ediciones ENTERPRISE (también Datacenter de 2008 R2 o Developers que no son para producción). Por lo tanto, la versión STANDARD no permite el cifrado de base de datos mediante Transparent Data Encryption (TDE).

Consiste en cifrar los datos dentro de los archivos físicos de la base de datos mediante un certificado y clave maestra. Si no se dispone de este certificado y clave maestra, aunque se roben los archivos, los datos no son accesibles.

Con Microsoft SQL Server 2016 Service Pack 1 aparece la característica Always Encrypted más ventajosa y soportada en todas las ediciones: Standard y Enterprise, esta será tratada en otra entrada específica.

Para tener claro donde se ubican las claves maestras y los certificados podéis echar un vistazo al siguiente gráfico que muestra la jerarquía que hay que seguir para generar las claves maestras y los certificados para poder cifrar la base de datos de usuario:

  • El sistema operativo cifra la clave maestra del servicio que se guarda a nivel de instancia de SQL Server.
  • La clave maestra del servicio cifra la clave maestra de la base de datos MASTER.
  • La clave maestra de la base de datos MASTER crea un certificado para la misma base de datos.
  • El certificado de la base de datos MASTER cifra la clave de cifrado de base de datos del usuario (donde tenemos los datos).
  • La base de datos del usuario se protege con la clave de cifrado mediante la tecnología Transparent Data Encryption (TDE).

 

Naturalmente, si se pierde la clave maestra o el certificado tendréis un buen problema. Haced siempre copia de seguridad de estos datos.

 

Implementación del cifrado de base de datos SQL Server

Antes de empezar, asegurar que tenemos una versión Microsoft SQL Server que está entre la 2008 y la 2016, y que la edición es la ENTERPRISE. En caso que no fuera correcta, aunque nos dejará hacer los procesos aquí descritos, al llegar al punto de activar el cifrado en la base de datos del usuario este se nos denegará.

Primer paso, crear la clave maestra en la base de datos Master. Desde la consola de SQL Server Management Studio o cualquier otra aplicación que permita ejecutar comandos en la base de datos SQL Server, creamos una nueva consulta y ejecutamos el siguiente comando con al contraseña maestra para la base de datos MASTER:

Use Master;
Go
Create Master Key Encryption by Password='HolaEstoEsLaClaveDeCifrado#17';
Go

Ejecutamos la consulta (pulsar la tecla F5, por ejemplo). En caso que la clave no cumpla los requisitos de complejidad establecidos en el sistema operativo se denegará la creación pidiendo una clave más fuerte. Pensad que es una clave que protegirà las bases de datos, es lo bastante importante para que no sea la típica 1234.

 

Seguimos con la creación del certificado (le pongo el nombre Certificat_TDE) que protegerá la contraseña maestra de la base de datos MASTER:

Use Master;
Go
Create Certificate Certificat_TDE With Subject='Cifrado_bases_de_datos';
Go

Ejecutamos la consulta (pulsar la tecla F5, por ejemplo).

Comprobamos que se ha generado un nuevo certificado en el SQL Server con el siguiente comando:

Select * from sys.certificates

Tenemos la base de datos MASTER cifrada, vamos a crear la clave de cifrado para la base de datos de usuario (la que tiene los datos y que queremos cifrar) con el siguiente comando:

Use Nombre_Base_de_datos;
Go
Create Database Encryption Key With Algorithm=AES_256 Encryption by Server Certificate Certificat_TDE;
Go

Primero nos colocamos dentro de la base de datos donde se tiene que crear la clave (Use Nombre_Base_de_datos) y generamos una clave con un algoritmo de cifrado utilizando el certificado que hemos creado anteriormente en el servidor. Sobre los algoritmos de cifrado recordad que son tan buenos en cuanto cuesta aplicar fuerza bruta para obtener la clave. Los que tenéis disponibles son los AES_128, AES_192 y AES_256, el resto, como bien sabéis, ya no se deben utilizar porque son débiles. Mi recomendación, actualmente, es utilizar el AES_256.

Se crea el certificado con una advertencia:

¡¡¡¡Haz una copia de seguridad del CERTIFICADO!!!!

En caso contrario, no se podrá acceder a los datos desde otro servidor o el mismo en caso de desastre.

 

Copia de seguridad del certificado para el cifrado de base de datos

Consiste en copiar el certificado (en mi caso Certificat_TDE) y la clave privada del mismo en dos archivos (C:\Certificats\Certificat_TDE y C:\Certificats\Certificat_TDE.pri) protegidos por una contraseña fuerte. Aseguraros que la carpeta donde queréis guardar los certificados se puede escribir por parte de la cuenta de servicio del SQL Server

Use Master;
Go
Backup Certificate Certificat_TDE to File = 'C:\Certificats\Certificat_TDE'
    with Private Key (file='c:\Certificats\Certificat_TDE.pri', Encryption by Password='ContraseñaCopiaCertificado#17')

Explorando la carpeta donde se deben haber creado los archivos de copia de seguridad del certificado: el certificado y clave privada. Guardad estos dos archivos, con la contraseña de protección que habéis establecido para poder recuperarlos, en un lugar seguro y que no sea en el mismo servidor SQL Server, claro.

 

 

Cifrado de base de datos de usuario

Tenemos el servidor SQL Server y la base de datos de usuario preparados para cifrar bases de datos, pero todavía no se ha empezado a cifrar nada. Para hacerlo, hay que habilitar el proceso de cifrado con el siguiente comando o modificando las propiedades de la base de datos desde la consola gráfica (Propiedades  en la base de datos > Opciones > Estado > Cifrar base de datos)

Alter database Base_de_dades_X set encryption on;
Go

Ahora si ha empezado el proceso de cifrado de base de datos de usuario. Dependiendo de la cantidad de datos tardará más o menos. Se puede comprobar su estado haciendo la siguiente consulta:

Select * from sys.dm_database_encryption_keys

Hay que identificar la base de datos concreta, como que sólo tenemos una, aparece la MASTER y la del usuario. Tenéis que comprobar el campo encryption_state que según su valor indica:

  • 0 = No existe una clave de cifrado en la base de datos, no está cifrado
  • 1 = No cifrado
  • 2 = Se está cifrando la base de datos
  • 3 = Cifrado
  • 4 = Se está cambiando la clave de cifrado
  • 5 = Se está descifrando
  • 6 = Se está cambiando la protección. El certificado o la clave asimétrica que ha cifrado la clave de cifrado de base de datos se está modificando.

Felicidades, la foto indica un valor de 3 en las dos bases de datos, ¡¡¡esto quiere decir que su contenido está cifrado!!!

Sin embargo, no quiere decir que si tengo permisos no pueda acceder, al contrario, todo funciona con normalidad y se puede trabajar con su contenido en claro:

El cifrado de base de datos TDE protege de la copia de los archivos de la base de datos a otros equipos

 

Copia de seguridad de la base de datos cifrada

Con la base de datos cifrada, tenéis que aseguraros que las copias que se hacen también van cifradas, sino no tiene gracia. Sin embargo aunque lo hagáis sin cifrar, como la base de datos sí está cifrada, veréis el contenido de la copia, pero NO la recuperación de la base de datos sin las claves y certificados correspondientes.

A la hora de configurar una copia de seguridad, por ejemplo, botón derecho sobre la base de datos, seleccionar TareasCopia de seguridad:

Hay que eliminar cualquier archivo de copias de seguridad anterior que se pueda haber configurado, seleccionándolo y haciendo clic en el botón de borrar.

Añadir un nuevo archivo, en la ruta que deseéis, donde guardar la copia de seguridad. Aseguraros que ponéis la extensión .bak para no tener después problemas con los filtros de las extensiones de archivos que hace el SQL Server Management Studio.

En el menú de la izquierda, hacer clic en Opciones del Medio. Seleccionar Hacer copia de seguridad en un conjunto de medios y borrar todos los conjuntos de copias existentes. Indicar un nombre descriptivo para el conjunto de copia de seguridad.

Seleccionar los checkbox de:

  • verificar la copia de seguridad cuando acabe. Es una buena práctica.
  • hacer un checksum antes de escribir en el dispositivo. Por si las moscas el que se guarda no es el mismo que el original.
  • No recomiendo marcar continuar en caso de error. Podría ser que se hiciese una copia de seguridad corrupta y a la hora de recuperar, poca cosa tendríamos, vaya que no nos serviría de nada.

Hacer clic en la opción Opciones de Copia de seguridad.

Seleccionar el método de compresión de la copia de seguridad. Marcar el checkbox de cifrar la copia de seguridad.

Seleccionar el algoritmo y el certificado o clave asimétrica. Se puede utilizar el mismo certificado que el que se ha utilizado para cifrar la base de datos.

Hacer clic en el botón OK para hacer la copia de seguridad.

Si todo está correcto, se acaba de hacer una copia de seguridad cifrada de la base de datos.

 

¿Qué pasa si intentamos recuperar esta copia de seguridad en otro servidor?

Sin embargo, la pregunta es si podemos llevarnos esta copia de seguridad a otro servidor, que no dispone de la clave maestra ni el certificado, y visualizar el contenido. Vamos a probar a hacerlo. En otro servidor, mediante la consola SQL Server Management Studio, botón derecho sobre la carpeta bases de datos y hacer clic en recuperar bases de datos.

En la opción General, marcar la opción de dispositivo, hacer clic en el botón para indicar el nombre del archivo, hacer clic en el botón Añadir archivo y seleccionar el archivo de la copia de seguridad que se ha hecho anteriormente:

Sorpresa, no se puede seleccionar ninguna base de datos que contenga este archivo.

Para comprobar que todo funciona según lo que esperamos que haga, repetimos el proceso con una copia de seguridad no cifrada, de la misma base de datos que si está cifrada. Esta vez sí se nos permite seleccionar la base de datos y el punto de recuperación que contiene la copia seguridad.

Pero ¿qué pasa al intentar restaurarla? Simplemente que, al no tener la clave maestra ni el certificado de cifrado, no se puede recuperar la base de datos.

¿Y, si en lugar de la recuperación de los datos mediante una copia de seguridad, se intenta hacer por el método de despegar y pegar (attach-desattach? Con la base de datos cifrada original, parar el servicio de SQL Server o despegarlas y copiar los DOS archivos (mdf y ldf) de la base de datos en otro servidor. Desde la carpeta de bases de datos del nuevo servidor, botón derecho y hacer clic en Adjuntar.

Seleccionar el archivo de base de datos con extensión .mdf.

Mala suerte, o no. No tenemos la clave maestra de cifrado, por lo tanto, tampoco podemos acceder a los datos de la base de datos por este método.

¿Repetimos el proceso en el servidor origen, el qué si tenía la clave de cifrado?

Esto es otra cosa, la base de datos cifrada se lee correctamente su contenido y, por lo tanto, se puede añadir como cualquier otro.

Una vez añadida al servidor de base de dades, se opera correctamente, como si nada hubiese pasado.

 

Eliminar certificado para el cifrado de bases de datos

En caso que no necesitemos más el certificado para el cifrado de base de datos de usuario es muy aconsejable eliminarlo del sistema. Si una cosa no la necesitas, no la guardes en un rincón para que un día se gire en tu contra. Para hacerlo, desde la consola de SQL Server Management Studio abrimos una nueva consulta con el siguiente comando:

 

Use master;
go
Select * from sys.certificates;
Drop certificate Certificat_TDE
Select * from sys.certificates;

Teniendo la base de datos cifrada original. La volvemos a adjuntar a la base, pero no hay el certificado que necesita para descifrarla, por lo tanto no se puede adjuntar de nuevo.

 

Recuperar el certificado para el cifrado de base de datos

Como buenos chicos tenemos una copia de seguridad del certificado de cifrado guardada en un sitio seguro. Desde la consola de SQL Server, ejecutamos el siguiente comando para crear la clave maestra:

Use Master;
go
Create master key encryption by password='HolaEstoEsLaClaveDeCifrado#17';
go

El siguiente paso es generar el nuevo certificado a partir de la copia de seguridad, indicando la ruta del certificado, la ruta del archivo con la clave privada y la contraseña que se puso cuando se hizo la copia de seguridad del certificado:

Use Master;
go
Create Certificate Certificat_TDE from file = 'c:\Certificat\Certificat_TDE' with Private key (File = 'c:\Certificat\Certificat_TDE.pri', Decryption By Password ='ContraseñaCopiaCertificado#17')

El servidor ha recuperado el certificado en la base de datos, lo comprobamos:

Select * from sys.certificates;

Ahora sí ya se puede adjuntar la base de datos cifrada. Botón derecho sobre bases de datos, hacer clic en adjuntar. Seleccionar el archivo .mdf con la base de datos y hacer clic en el botón OK.

¡Volvemos a tener la base de datos operativa!

 

NO Recuperar la base de datos cifrada en una edición estándar

¿Qué pasa cuando intentamos recuperar la base de datos en una edición estándar que no soporta el cifrado de bases de datos?

Aunque nos deja crear la clave, importar el certificado, cargar la copia de seguridad cifrada de la base de datos y incluso recuperar la base de datos, pero no ejecutarla.

La base de datos quedará restaurada pero no servirá para nada al quedar marcada como sospechosa.

¡Tened bien presente en las instalaciones!

 

Descifrar base de datos cifrada

Si os habéis cansado del cifrado de base de datos, o ha cambiado la naturaleza de la misma, se puede descifrar accediendo a las propiedades de la base de datos, Opciones > Estado > Cifrado activado; o bien con el siguiente comando:

Alter database Nom_Base_De_Dades
Set encryption off

Para comprobar que se ha descifrado correctamente, el campo encryption_state debe tener como valor el número 1:

Select * from sys.dm_database_encryption_keys

Finalmente, para no dejar rastro del cifrado, toca borrar la clave de cifrado de base de datos:

Drop database encryption key

Hechas estas operaciones, la base de datos ya vuelve a estar en un formato llano y accesible para cualquiera.

 

 

Para acabar esta entrada y como recomendación, os tengo que decir que no utilicéis el mismo certificado para cifrar todas las bases de datos del servidor o servidores, que nos conocemos.

¡Un certificado para cada base de datos, no un certificado que los gobierne a todos!

 

¿Te ha gustado el artículo? Lo puedes compartir en las redes sociales. También puedes dejar tu opinión, comentario o sugerencia. ¡Gracias!

 

Comentarios

  • Buenas,

    tengo una duda al respecto… según esto, en el mismo servidor pueden convivir bases encriptadas y no encriptadas? Mi duda viene al quedar la Master encriptada… no afectará a otra base del servidor que no lo esté?

    A ver si me puedes resolver la duda. Gracias.

     
    • No, siempre que tengas el certificado instalado en el servidor puedes abrir la base de datos correctamente y de forma transparente. Los datos de la MASTER no afectan los datos de las otras bases de datos.

       
  • Excelente articulo con gran aporte y muy didáctico, quería aplicarlo pero tengo SqlServer versión STANDARD, la pregunta es si conoces otro método de cifrado para esta versión.

     
  • Impresionante artículo Josep Maria, Muchas gracias por toda esta información.

    Quería preguntarle sobre que alternativas hay al TDE para cifrar bases de datos de tipo Standard o incluso Express.

    Muchas gracias.

     
    • Hola Alfonso,

      La otra opción de cifrado, que es un poco más agresiva és el Always On Encrypted, del que requiere modificación en el punto final, es decir, en el cliente que hace la conexión. Y no todas las aplicaciones lo permiten.

       
  • Muchas gracias por el tutorial, ha sido de mucha ayuda. No obstante tengo una duda:
    Entonces no se puede restaurar la base de datos en otro servidor? aún teniendo el certificado y la clave privada?
    Seria interesante poder hacer la restauración de una base de datos cifrada en otro servidor.
    Cualquier cosa me dices.

    Saludos.

     
    • Sí la puedes restaurar siempre que tengas las claves de cifrado. Antes debes cargarlas en el servidor. Lo tienes en el apartado del artículo recuperar el certificado para el cifrado de la base de datos.

       

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.