Una vez que hemos detectado y clasificado nuestros datos, entramos en el segundo paso en nuestro camino para cumplir con el GDPR, ahora es el turno de administrar los accesos a los datos y controlar el uso que se hace de ellos.

¿Por qué esto es importante para el GDPR?

The GDPR specifically addresses the need for mechanisms which limit access to data, requiring “measures [that] shall ensure that by default personal data are not made accessible without the individual’s intervention to an indefinite number of natural persons.”

GDPR Article 25(2)—“Data protection by design and by default.”

SQL Server dispone de varias herramientas para el control de acceso, pero es el administrador SQL Server el que hace uso de ellas, y en muchas ocasiones por comodidad se otorga permisos innecesarios a determinados usuarios, dando acceso a datos que este usuario no tendría que poder ver o a datos confidenciales.

Para ayudar con la administración de estos accesos y controlar los datos que se pueden ver, SQL Server ofrece lo siguiente:

  • Mecanismos de autenticación para asegurar que solo los usuarios con credenciales válidas puedan acceder al servidor de base de datos. SQL Server admite la autenticación SQL Server y la autenticación con seguridad integrada de Windows, y en entorno Azure, para Azure SQL Database y Azure SQL Data Warehouse, el control de acceso por roles de Active Directory de Azure.
  • Control de acceso basado en roles, otorgando a los usuarios distintos roles (niveles de acceso) dependiendo la función dentro del equipo.
  • Row-Level security para evitar el acceso a filas específicas de una tabla basado en características del usuario que intenta acceder al dato, por ejemplo que en la tabla de empleados solo puedas ver tus datos y no los de otros empleados.
  • Utilización de enmascaramiento de datos, por ejemplo para números de cuentas bancarias del tipo XXXX-XXXX-XXXX-1321, para ocultar datos a usuarios que no tengan permisos usando Dynamic Data Masking.
  • Verificar los cambios que ocurren en una tabla usando SQL Server Audit o para Azure SQL Database utilizando Azure SQL Server Auditing.

En esta entrada vamos a centrarnos en las características más nuevas, disponibles desde SQL Server 2016, como son Row-Level Security y Dynamic Data Masking.

Row-Level Security

Para nuestro ejemplo vamos a utilizar la base de datos AdventureWorks2016, y en concreto las tablas [Sales].[SalesTerritory] y [Sales].[Customer].

Al ejecutar las consultas se puede ver como cada Customer de la tabla [Sales].[Customer] pertenece a un Territory.

[Sales].[SalesTerritory]

[Sales].[Customer]

En nuestro ejemplo vamos a hacer uso de Row-Level Security para controlar que solo los usuarios que pertenezcan a un Territory puedan ver los Customer que les correspondan.

Procedemos a crear los usuarios:

Le otorgamos permisos a estos usuarios:

Y el siguiente paso ya sería crear el Row Level Security, en nuestro caso primero vamos a crear un schema para tenerlo más ordenado:

Lo siguiente es crear una función sobre [Sales].[SalesTerritory] que posteriormente utilizaremos para filtrar [Sales].[Customer].

Esta función es la encargada de validar si el usuario podrá ver o no una determinada fila basándose en el TerritoryId y posteriormente en el CountryRegionCode

Una vez tengamos la función creada, crearemos una Security Policy que utilizará esta función para filtrar la tabla [Sales].[Customer]

Ahora que ya lo tenemos todo creado, vamos a realizar una serie de pruebas para entender mejor el funcionamiento.

Usuario DBO

Primero, tratamos de ejecutarlo con el usuario con el que hayamos creado todo, en nuestro caso es un usuario con permisos dbo

No devuelve ningún resultado, y es correcto debido a que nuestro usuario no está contemplado dentro de la función.

Usuario USCountryManager

Ahora vamos a realizar la misma prueba pero utilizando el usuario USCountryManager que sí que está en la función, utilizaremos “EXECUTE AS USER” para ello:

Vemos que si que aparecen resultados, y que además aparecen varios TerritoryId, esto es normal ya que “US” tiene varios territorios:

Usuario GBCountryManager

La última prueba la realizaremos con el usuario GBCountryManager, que únicamente tiene un Territorio

Por último y si quisiéramos borrar todo y dejarlo como al inicio, solo tendríamos que ejecutar lo siguiente:

Una vez que ya hemos entendido como funciona Row-Level Security y como se filtran los datos, vamos a pasar a utilizar la funcionalidad Dynamic Data Masking para enmascarar datos.

Dynamic Data Masking

Lo primero que hay que saber sobre Dynamic Data Masking es que el enmascaramiento se realiza en tiempo de ejecución, es decir, el dato en la tabla no se encuentra enmascarado.

Para controlar si un usuario puede o no ver un dato enmascarado SQL Server hace uso del permiso “UNMASK”.

En este ejemplo vamos a mostrar los tipos de enmascaramiento DEFAULT, EMAIL y PARTIAL.

Vamos a hacer uso de dos usuarios, el usuario DBA que si que tendrá permisos UNMASK, y el usuario Developer que no tendrá permisos UNMASK

Empezamos creando los usuarios

Damos permisos a estos usuarios:

Y otorgamos al usuario DBA el permiso UNMASK

Ahora que ya tenemos los usuarios con los permisos adecuados, podemos ver los tipos de enmascaramiento y como aplican a los datos, para esto vamos a utilizar nuevamente la base de datos AdventureWorks2016

Enmascaramiento DEFAULT

Esta función reemplaza las columnas de tipo string por la cadena “XXXX” y las de tipo numérico por “0”.

Vamos a utilizarla sobre la columna PhoneNumber de la tabla Person.PersonPhone

Y vamos a ejecutar un TOP 10 sobre la tabla utilizando los usuarios DBA y Developer para ver la diferencia en la visualización

Usuario DBA (con permiso UNMASK)

Usuario Developer

Enmascaramiento EMAIL

Esta función reemplaza la parte antes de la @ con la primera letra y “XXXX” y pone “@XXXX.com” al final

Vamos a utilizarla sobre la columna EmailAddress de la tabla Person.EmailAddress

Y vamos a ejecutar un TOP 10 sobre la tabla utilizando los usuarios DBA y Developer para ver la diferencia en la visualización

Usuario DBA (con permiso UNMASK)

Usuario Developer

Enmascaramiento PARTIAL

Esta función define un número de caracteres al inicio y al final que se quedarán sin enmascarar, y en el medio utilizará el string que se elija.

Vamos a utilizarla sobre la columna LastName de la tabla Person.Person, dejaremos un caracter al inicio y dos al final sin enmascarar y en medio pondremos el texto “GDPR”.

Y vamos a ejecutar un TOP 10 sobre la tabla utilizando los usuarios DBA y Developer para ver la diferencia en la visualización

Usuario DBA (con permiso UNMASK)

Usuario Developer

Para finalizar vamos a ver como de una forma rápida podemos dar marchas atrás a todos los cambios realizados.

Le quitamos el permiso UNMASK al usuario DBA

Y borramos el enmascaramiento en las tres tablas que hemos utilizado

Ahora que ya sabemos como controlar los accesos y la visibilidad del dato, es hora de ir al siguiente punto del GDPR y ver como Proteger estos datos.

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

Si quieres que ayudemos a tu negocio o empresa a cumplir con el GDPR contacta con nosotros en info@aleson-itc.com o llámanos al +34 962 681 242

Recommended Posts

Leave a Comment

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