Categoría: Sin categorizar

por Fran Lens 2019-01-24

🔒 Protegiendo datos en Reposo, en Uso y en Tránsito – Serie GDPR (4/5)

En la anterior entrada de la serie aprendimos a administrar el acceso y el uso de los datos, pero para estar completamente seguros, no basta solo con asegurar el dato en uso, también tenemos que protegerlo en reposo y en tránsito.

¿Por qué esto es importante para el GDPR?

This relates to the GDPR obligation to take into account “risks that are presented by processing, in particular from accidental or unlawful destruction, loss, alteration, [or] unauthorized disclosure of” that data. In this case, the protection is at the level of the physical device—and prevents the risk of compromising the storage itself, for example via copying the physical data out to another server.

GDPR Article 32(2)—“Security of processing.”

Antes de comenzar con la parte técnica, voy a explicaros con un ejemplo rápido cada uno de los tres estados en los que se puede encontrar el dato:

• En reposo, a nivel físico, en nuestro caso podría ser el fichero .mdf, .ldf o los backups que se realizan de la base de datos.
• En uso, a nivel lógico, es decir, los datos que encontramos en las tablas de una base de datos.
• En tránsito, cuando nuestros datos viajan en forma de paquetes por la red.

Una vez que ya tenemos claros los tres estados, vamos a ver de que forma SQL Server nos puede ayudar a protegernos:

• Utiliza conexiones cifradas para evitar que los datos viajen (en tránsito) sin encriptar con Connection Encryption.
• Asegura los datos personales a través del cifrado en la capa física del almacenamiento (en reposo) usando Transparent Data Encryption.
• Evita que usuarios no autorizados o con alto nivel de privilegios accedan al dato en tránsito, en reposo y en uso con la característica Always Encrypted.
• Maximiza la disponibilidad del dato y evita caídas del servicio con Always On Availability Groups.
• En Azure SQL Database y Azure SQL Data Warehouse detecta actividades anómalas y riesgos potenciales de seguridad con SQL Database Threat Detection.

Cómo hacer una entrada que cubra todas estas funcionalidades sería un poco largo, vamos a centrarnos en dos de ellas, que además se pueden desplegar de una forma muy rápida, Connection Encryption y Transparent Data Encryption.

Connection Encryption

En este ejemplo voy a mostraros lo sencillo que es activar la encriptación de conexiones para que nuestros datos dejen de viajar en texto plano, ya que por defecto en SQL Server solo los usuarios y contraseñas viajan encriptados.

Antes de esto, podemos hacer una prueba rápida con Wireshark para entender como “alguien con malas intenciones” vería nuestros datos. Para esto necesitamos conocer la IP de nuestro servidor SQL Server, y el puerto que utilice SQL Server, por defecto es el 1433.

Abriremos Wireshark y pondremos como filtro la siguiente sentencia para ver todos los datos que están pasando por SQL Server:

ip.addr == YOUR_IP || tcp.port== YOUR_SQL_PORT

En cuanto lo activemos veremos como empieza a obtener datos:

Ahora vamos a lanzar una consulta contra nuestro servidor SQL Server, en nuestro caso vamos a utilizar la tabla [Person].[Person] de AdventureWorks2016.

SELECT TOP 10 [FirstName]
	,[LastName]
FROM [AdventureWorks2016].[Person].[Person]

Y el resultado que nos muestra es el siguiente:

Nos movemos a Wireshark y buscaremos entre los paquetes capturados, podemos filtrar por los paquetes que en la columna Protocol ponga TCP, también nos fijaremos en que la variable Len (Longitud) tenga un valor un poco alto.

Y una vez tengamos localizado el paquete, solo tendremos que ver su contenido para ver como todos los resultados de nuestra query se muestran sin encriptar:

Ahora que ya os he metido el miedo en el cuerpo, es hora de ver como solucionarlo.

En nuestro servidor SQL Server abrimos la aplicación SQL Server Configuration Manager, y nos dirigimos a las Propiedades de Protocols for MSSQLSERVER.

Y cambiamos la opción Force Encryption a Yes.

Ahora reiniciamos el servicio SQL Server y nuestras paquetes ya viajarán encriptados.

Para probar esto volvemos a ejecutar la query sobre [Person].[Person].

Y este es el resultado que nos aparecerá en Wireshark:

Todo bien encriptado y salvo que seas descendiente de Alan Turing no vas a poder desencriptar.

Por lo que la recomendación que os puedo dar es:

SIEMPRE ACTIVAR LA ENCRIPTACIÓN DE CONEXIONES (Probando previamente que vuestras aplicaciones lo soporten).

Transparent Data Encryption

Hemos visto lo rápido que es encriptar las conexiones y los datos en tránsito, y ahora vamos a ver la forma más rápida y sencilla que tenemos de encriptar los datos en reposo, que no es otra que utilizar TDE.

Lo primero que tenemos que saber es que Transparent Data Encryption solo está disponible con versión SQL Server Enterprise, por lo que si tenéis versión Standard no podréis hacer uso de esta funcionalidad.

Antes de habilitar Transparent Data Encryption tenemos que conocer sus dependencias y la jerarquía que se tiene que cumplir para habilitar esta encriptación:

1. La primera capa que tenemos a nivel de Sistema Operativo es la Windows OS Data Protection API.
2. La segunda capa es la Service Master Key que se crea junto a la instalación de SQL Server, que es encriptada por la Windows OS Data Protection API.
3. La tercera capa es la Master Database Key creada en la base de datos master que es encriptada por la Service Master Key.
4. La cuarta capa es el Certificado que se crea en master utilizando la Master Database Key.
5. La quinta y última capa es la Database Encryption Key a nivel de la base de datos de usuario y que utiliza el Certificado.

De la primera y segunda capa no nos tenemos que preocupar, y de las tres siguientes os voy a explicar ahora como crearlo y que cosas hay que tener en cuenta.

Empezamos por la Master Database Key, que tiene que ser creada en la base de datos master, elegiremos una contraseña fuerte y por supuesto GUÁRDALA EN UN LUGAR SEGURO.

-- Create Master Database Key
USE [master]
GO
CREATE MASTER KEY ENCRYPTION
BY PASSWORD='GDPRAlesonITC2019'
GO

Una vez que tenemos creada (y guardada) la Master Database Key, procedemos a crear el Certificado en master, el nombre del certificado es libre, en mi caso me gusta poner el nombre de la base de datos que se va a encriptar.

-- Create Certificate
USE [master]
GO
CREATE CERTIFICATE TDE_AdventureWorks2016_Cert
WITH 
SUBJECT='Database_AdventureWorks2016_Encryption';
GO

Ahora cambiamos a la base de datos que queramos encriptar para crear la Database Encryption Key, como veis utilizaremos el Certificado que acabamos de crear.

-- Create Database Encryption Key
USE [AdventureWorks2016]
GO
CREATE DATABASE ENCRYPTION KEY
WITH ALGORITHM = AES_256
ENCRYPTION BY SERVER CERTIFICATE TDE_AdventureWorks2016_Cert;
GO

Al momento de crearla, nos mostrará un mensaje de Alerta.

Warning: The certificate used for encrypting the database encryption key has not been backed up. You should immediately back up the certificate and the private key associated with the certificate. If the certificate ever becomes unavailable or if you must restore or attach the database on another server, you must have backups of both the certificate and the private key or you will not be able to open the database.

Es muy importante que realicéis un backup del certificado, ya que si necesitamos restaurar la base de datos en otro entorno necesitaremos previamente restaurar el certificado y recrear la Master Database Key (usando la misma contraseña). Por lo que, hacemos la copia de seguridad del certificado:

-- Backup Certificate
USE [master]
GO
BACKUP CERTIFICATE TDE_AdventureWorks2016_Cert
TO FILE = 'C:\Backup\TDE_AdventureWorks2016_Cert'
WITH PRIVATE KEY (file='C:\Backup\TDE_AdventureWorks2016_CertKey.pvk',
ENCRYPTION BY PASSWORD='GDPRAlesonITC2019')

Por último, ya solo nos queda habilitar la encriptación en la base de datos, en nuestro caso AdventureWorks2016:

-- Now Enable Encryption in AdventureWorks2016
ALTER DATABASE [AdventureWorks2016]
SET ENCRYPTION ON;
GO

Para verificar que todo el proceso se ha realizado correctamente, podemos ejecutar la siguiente consulta para ver todas las bases de datos encriptadas:

-- Verify Encryption and some details
SELECT D.name, K.*
FROM sys.dm_database_encryption_keys K
INNER JOIN sys.databases D ON D.database_id = K.database_id

Veréis que la base de datos tempdb también esta encriptada, esto ocurre porque automáticamente se encripta cuando detecta que otra base de datos de la instancia se ha encriptado, de este modo cuando utilicemos tempdb para tablas temporales, agregaciones… nuestro dato estará a salvo.

Para terminar, si quisiéramos deshabilitar la encriptación y borrar todos los componentes creados, podemos hacerlo con la siguiente sentencia:

-- Remove Encryption on AdventureWorks2016
USE [AdventureWorks2016]
GO
ALTER DATABASE [AdventureWorks2016] SET ENCRYPTION OFF;
GO
-- Wait 10 seconds
-- Drop Database Encryption Key
DROP DATABASE ENCRYPTION KEY; 
GO
USE [master]
GO
-- Drop Certificate
DROP CERTIFICATE TDE_AdventureWorks2016_Cert
GO
-- Drop Master Database Key
DROP MASTER KEY

Antes de acabar, quiero destacar que aunque sea un proceso relativamente fácil y rápido de aplicar, es muy importante que guardemos en un lugar seguro la Master Database Key y el Certificado, ya que incluso los backups diarios que hagamos estarán encriptados y necesitaremos de estos dos componentes si queremos restaurarlo.

En estas cuatro primeras entradas de la serie GDPR hemos descubierto como detectar, administrar y proteger nuestros datos, ya solo nos queda la última parte para saber como Monitorizar e Informar si ocurre alguna violación o incumplimiento del GDPR.

Serie completa de GDPR:

1. Cómo adaptar SQL Server al RGPD (GDPR)
2. Detectando y clasificando datos personales con SQL Server
3. Administrando los accesos y el uso de los datos con SQL Server
4. Protegiendo datos en Reposo, en Uso y en Tránsito
5. Monitorizar y Reportar accesos no autorizados a Datos Personales