Las seguridad en Fabric se vuelve cada vez más prioritaria a medida que más es adoptado el ecosistema. Cierto es que la mayoría de los casos suelen pasar por como se regulan cuentas de acceso de desarrollo o tal vez permisos sobre recursos puntuales. Incluso cuando queremos afinarla un poco todo termina en una seguridad de la tabla por filas o columnas.

Gran parte de empresas se concentra en permitir o privar acceso a datos específicamente pero cierto es que muchas veces dejamos de lado otra forma de mantener la seguridad y poder trabajar con datos puntuales. Me refiero a enmascarar datos.

En este artículo veremos como enmascarar datos desde Fabric SQL Analytics Endpoint para que usuarios sepan que exista una columna pero su contenido este enmascarado.

Antes de comenzar vamos a ir directo a lo que nos gusta en LaDataWeb. Revisemos la definición de enmascaramiento dinámico de datos. Microsoft lo define de la siguiente manera:

El enmascaramiento de datos dinámico es una tecnología de protección de datos de vanguardia que ayuda a las organizaciones a proteger la información confidencial dentro de sus bases de datos. Permite definir reglas de enmascaramiento para columnas específicas, lo que garantiza que solo los usuarios autorizados vean los datos originales a la vez que se ocultan para otros usuarios. El enmascaramiento de datos dinámico proporciona una capa adicional de seguridad mediante la modificación dinámica de los datos presentados a los usuarios, en función de sus permisos de acceso.

Dicho sea de otro modo, podemos configurar nuestras tablas para que columnas no muestren datos sino textos inentendibles en lugar del dato real cuando son consultadas por específicas personas.

Esta modalidad existe en muchos motores. El que vamos mostrar funciona particularmente en SQL Server pero la prueba la vamos a construir dentro de Fabric en su experiencia SQL de un Warehouse

NOTA: de momento el SQL Analytics endpoint de un Lakehouse no admite sentencia CREATE. Por esta razón, usaremos Warehouse.

¿Por qué esconderíamos el dato de columnas a ciertos usuarios? Puede que nuestro conjunto de datos tenga información sensible que no queremos que sea visible por quien lo desarrolla. Tal vez estamos por revisar datos personales, valores salariales, etc. Dicho contenido es privado y no debería ser visible para quienes lo desarrollan.

¿Cómo se vería esto? Imaginemos a un Data Analyst conectandose por SQL Analytics endpoint o creando un report de Power Bi. Cuando uno de estos usuarios tiene aplicado el enmascaramiento, vería de la siguiente manera:

Desarrollo

El enmascarado de datos es un rasgo de una tabla. Por esta razón, se configura al momento de crear la tabla o modificando su estructura. Como la experiencia es 100%, comenzaremos abriendo el analytics endpoint de un Warehouse. Veamos como se aplicarían tres ejemplos al crear la tabla:

CREATE TABLE dbo.Cliente (
DNI INT
,Nombre VARCHAR(50) MASKED WITH (FUNCTION = 'partial(1,"-",2)') NULL
,Apellido VARCHAR(50) MASKED WITH (FUNCTION = 'default()') NULL
,TarjetaSSN CHAR(12) MASKED WITH (FUNCTION = 'partial(0,"XXX-XX-",4)') NULL
,Provincia VARCHAR(50)
,Localidad VARCHAR(50)
,Direccion VARCHAR(256)
,Email VARCHAR(100) NULL
);

La columna Nombre muestra solo el primero y últimos dos caracteres de la cadena, con - en el centro.
La columna Apellido muestra XXXX.
La columna TarjetaSSN muestra XXX-XX-, seguido de los cuatro últimos caracteres de la cadena.

A partir de ese momento lo que insertemos en esa tabla será enmascarado para usuarios de lectura. Compartiríamos el Warehouse de la siguiente manera:

Un desarrollador de tablero ya podría conectarse con Power Bi Desktop o desde la interfaz para consultar datos. Si este usuario consultara datos de Cliente. Vería lo siguiente. Presten atención a las columnas afectadas Nombre, Apellido y TarjetaSSN

Importando datos desde el Warehouse en Power Bi Desktop:

Una vez publicado el informe, tengamos presente que la credencial para la actualización será clave para la visibilidad. Por ejemplo, coloque credenciales de un usuario administrador del warehouse y en el informe podremos visualizar datos:

Así conseguimos que el tablero productivo muestre datos para quienes deben verlo y que desarrolladores no vean el contenido. Recuerden que el desarrollador no podría ser miembro del área de trabajo del Warehouse sino que le compartimos el recurso puntual.

Ya conocemos como comenzar un proyecto nuevo con estas características, pero que sucede con nuestros modelos que ya existen en este momento. Para trabajarlos, vamos a modificar la estructura de la tabla con ALTER. Dicha sentencia puede ejecutarse tanto en Lakehouse como Warehouse. Veamos como enmascarar el email que generamos en la misma tabla y siempre estuvo visible.

ALTER TABLE dbo.Cliente
ALTER COLUMN [Email] ADD MASKED WITH (FUNCTION = 'email()');

El resultado de dicha sentencia nos enmascararía la columna de correo dejando una visibilidad como indica la imagen:

Puede que en medio de estos desarrollos necesitemos que algunos de los usuarios tengan visibilidad sobre los datos. Para no cambiar los permisos sobre los recursos y seguir manteniendo su acceso de solo lectura, podemos dar permisos especiales sobre una tabla o columna como vimos en el post anterior usando GRANT. Veamos un ejemplo de como asignar esta excepción a un usuario para que vea Nombre y como quitársela. Quedaría así si lo viera:

GRANT UNMASK ON dbo.Cliente(Nombre) TO [TestRole@ladataweb.com.ar];
REVOKE UNMASK ON dbo.Cliente(Nombre) TO [TestRole@ladataweb.com.ar];

De esta manera podemos incluir una capa adicional de seguridad en nuestros procesos de desarrollo que no sean quitar la total visibilidad de una fila, columna, tabla, modelo, etc.

Para entrar en más detalle, pueden revisar en la documentación de microsoft que funciones podemos usar para el enmascarado dinámico en este enlace: https://learn.microsoft.com/es-es/sql/relational-databases/security/dynamic-data-masking?view=sql-server-ver17

Espero que les sea útil puesto que tiene mucha flexibilidad para su uso. Restaría sentarse a pensar bien como incluirlo en nuestro flujo laboral.