Ya Fabric sigue demostrando su gran experiencia de usuario en distintos enfoques. Uno de los más atractivos que hemos mencionado varias veces es su entorno SQL. Fabric con sus almacenamientos de lakehouse y warehouse en una gran interacción SQL.
Si conocen de SQL Server seguramente será de gran utilidad. En este artículo, veremos como establecer seguridad de datos granulares como si estuvieramos dentro de un SQL Server. Sin embargo, estamos dentro de un lakehouse almacenado en delta parquet.
La seguridad en Fabric evoluciona en tres niveles tal como explicamos en este artículo anterior de Seguridad en Fabric. El máximo nivel de rigurosidad es llegar a la granularidad. Esto significa que podemos permitir o restringir acceso a datos dentro de un elemento. Por ejemplo, si hablamos de un modelo semántico estaríamos refiriéndonos a OLS o RLS.
En caso de almacenamientos entorno a tablas en formatos delta en onelake, tenemos la posibilidad de la experiencia SQL gracias al SQL Endpoint que generan al crearse. En ese espacio podremos nutrirnos de tradicional SQL para realizar acciones como permitir, rechazar, cancelar acceso a tablas o inclusive más profundo como por ejemplo column level security, row level security e inclusive Dynamic data Masking.
Antes de comenzar a escribir SQL debemos pensar en el punto de acceso del usuario. Si el usuario ingresaría a Fabric a utilizar herramientas y navegar el lake, entonces probablemente demos acceso por OneLake Security. Si queremos que su experiencia sea 100% SQL, entonces lo haremos por código. Estos permisos son granular de un ítem. Entonces el usuario no debe tener permisos al área de trabajo, sino que dimos click a "Compartir" sobre Lakehouse y pusimos la mínima cantidad de permisos.
OneLake Security
Para configurar por este camino, lo primero es delimitar que tablas tendrá acceso un usuario. Podemos crear un rol que tiene acceso a especificas carpetas o tablas usando "Onelake Security"
Parados en lakehouse veremos un nuevo botón:
Una vez desplegado el menú podrán dar un nombre al rol y configurar los dos nros que ven en la imagen. Primero cambiar a selected data o clickear en botón "Add Data" para elegir que podrá ver el rol y segundo Agregar miembros y verlos en la pestaña "Members".
Un ejemplo de selección de datos sería:
De este modo cuando el usuario, ingrese al Lakehouse propiamente configurado. Solo vería esas cuatro tablas indicadas.
Configuración SQL
La configuración anterior solo daría acceso a la vista de lake, sin embargo estaría vacía frente a SQL Endpoint. Si quisiéramos que los ETL o la experiencia de consulta pase con scripts, procedimientos y toda la magia de lenguaje SQL este dada por experiencia SQL (dentro del sql endpoint o por algún DBMS); podríamos configurarlo por código en lugar de por UI. Con el SQL Analytics endpoint, se pueden aplicar permisos de T-SQL a objetos (esquemas, tablas, vistas, funciones, etc) mediante comandos DCL (data control language). Los comandos son GRANT, DENY, REVOKE
Veamos un ejemplo
Ejecutando esa consulta, el usuario listado podría ingresar al SQL Endpoint y ver esas tablas para ejecutar consultas select independiente de su asignación en onelake security. Vería lo siguiente.
De la misma manera funcionan las peticiones de las otras sentencias de control. Dejo material por si quieren verlas en profundidad o revisar otros ejemplos.
- GRANT: https://learn.microsoft.com/en-us/sql/t-sql/statements/grant-transact-sql?view=sql-server-ver16
- DENY: https://learn.microsoft.com/en-us/sql/t-sql/statements/deny-transact-sql?view=sql-server-ver16
- REVOKE: https://learn.microsoft.com/en-us/sql/t-sql/statements/revoke-database-permissions-transact-sql?view=sql-server-ver16
Aún más profundidad
Si quisiéramos viajar incluso más lejos. Podríamos delimitar seguridad por columna, filas o enmascarar datos. Veamos un ejemplo por columna.
Simplemente agregando las columnas cerca de la tabla, el usuario tendría la restricción aplicada. La experiencia para las columnas no es la más grata de este modo porque el usuario ve todas las columnas pero el motor le impide ver datos de las columnas mostrando un mensaje así:
Para el caso de seguridad por filas, se requiere más profundidad en conocimientos de T-SQL (crear una función y una security policy). Si no conocen, les recomiendo mantenerlo en Warehouse o Modelo semántico que puede ser configurado por UI. En caso de enmascarar datos creo que es un tema para un artículo dedicado.
Finalmente, si quisiéramos validar los permisos de una tabla, podríamos usar el procedimiento de SQL Server sp_table_privileges o bien el siguiente script para validar todas las tablas que hubieran sido afectadas por GRANT o DENY:
Todas las aplicaciones mencionadas de SQL son aplicables en data warehouse de Fabric. Espero que este artículo haya dado más luz a lo que podríamos configurar de seguridad más fina en nuestros almacenamientos de Fabric.