Cifrado de base de datos SQL Server por TDE
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 Tareas y Copia 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!
Similar Posts by The Author:
- Microsoft SQL Server con SMB3
- Microsoft SQL Server amb SMB3
- Containers en Linux
- Containers amb Linux
- Migrar el servidor de archivos a Windows Server 2019
- Migrar el servidor de fitxers a Windows Server 2019
- Puerta enlace a Azure en el Windows Admin Center
- Porta enllaç a Azure en el Windows Admin Center
- Hola mundo! WordPress 5 y Gutenberg
- Hola món! WordPress 5 i Gutenberg
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.
Gracias Josep Mº por el artículo,
Quería preguntarte si es posible hacer lo mismo es decir encriptar la base de datos pero en lugar de un certificado generado en sql con un certificado de una entidad de confianza ya generado. ¿Podrías decirme los pasos?
Gracias
Gracias por el aporte Pedro, en principio si se puede, tomo nota para un artículo al respecto.
Saludos,
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.
Si, tambien tienes el Always Data Encryption, a partir de SQL Server 2016 SP1. Tengo el artículo pendiente.
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.
Excelente explicación, por cierto, de gran ayuda.
Saludos.
Hola, y si quiero cifrar varias BD puedo utulizar los mismos certificados? afecta en algo? afecta a la hora de restaurar en otro servidor?
saludos.
Al restaurar en otro servidor debes tener copia del certificado y la clave, sino los datos que recuperes seran inservibles.
Saludos desde Ecuador,
Josep, necesito de tu experiencia,
Tengo 2 BBDD cifradas mediante TDE en nuestros servidores SQL 2012 Enterprise, y necesito migrar dichas bases a un servidor con SQL 2014 Standard (tengo contraseñas y certificados), La duda existe en qué tipo de cifrado puedo usar en mis bases cifradas en el SQL 2014 para poder cumplir PCI Compliance
Saludos
Sin duda AES-256, pero recuerda que debes aplicar otras medidas en las bases de datos para que sean PCI Compliance, no basta solo en cifrar la base de datos.
Hola Josep buen día, mira este caso hay una base de datos sql server cifrada, pero algo paso en el servidor que se apago inesperadamente y se quedo la base de dato corrupta (no se tiene acceso) tengo una herramienta externa que compre hace tiempo atrás que se llama Systool Recovery SQL esta me permite reparar y recuperar los datos, pero en el caso del cifrado de la base no me muestra nada, que debería hacer en este caso?
Recuperar la copia de seguridad que tienes a buen recaudo de la base de datos. Recuerda que cifrar una base de datos es para que no se pueda acceder a los datos en claro con ninguna herramienta. Si, como bien dices, la herramienta de recuperación te permitiese visualizar o recuperar los datos de la base de datos cifrada, mal iríamos.
Hola Josep buen día, mira que pasa si esta base de datos corresponde a una que termina siendo un cubo OLAP, ya sea una tabla de Hechos y/o sis dimensiones, desde el SASS se puede decencriptar para ser visualizada en el cubo.
Gracias por los tips.
Hola. Por favor podrías decirme cual es el impacto previsto de la encriptación en el rendimiento de la bbdd y si hay alguna configuración a nivel de SQL (o ampliación de recursos HW del servidor) que pueda minimizar ese impacto? Gracias y un saludo
Hola Paulo, pues no, no tengo estos datos en claro al depender de muchos factores. No he llegado a mesurar el antes y después en una base de datos. Es un muy buena prueba a realizar.
No obstante te puedo decir que en donde he aplicado estas opciones no ha habido problema alguno de acceso a los datos o latencias. Esta siendo siempre muy transparente.
Hola buenas, tengo una base encriptada con TDE y estoy configurando un mirror en otro servidor, realice todas las configuraciones y restaure la base y certificado en el servidor secundario (mirror) pero cuando hago la configuracion del mirror, me da un mensaje que no puede iniciar el mirror porque la base esta en medio de una restauracion. Lei un blog donde dice que se debe activar por TSQL con un comando «alter database database_name set partner=’TCP//fqdn:port_number'» Pero al hacerlo me da un mensaje de error «The server XXXXX can not be reached or does not exists. please check network or endpoints……..» debo realizar alguna configuracion adicional al tener las bases encriptadas?
Enhorabuena!! Muy buena explicación, muy didáctico. Gracias
Hola Josep,
Buen post. Muy bien explicado. Lo he podido aplicar siguiendo tus indicaciones rápidamente. Por ampliar la información que no sé si alguien en un comentario lo ha indicado, decir que SQL 2019 incluye en la versión estándar esta característica.
Gracias. Saludos,
Hola Josep:
Tengo un software que se comercializa por Internet, la duda es si envío al usuario la base de datos encriptada, el podrá tener problemas al tyrabajar con el software?.
Muchas gracias por la respuesta.
Gemma Campillo