Seguridad granular en OneLake: Implementación de Data Access Roles en Fabric

Durante años, la seguridad en Power BI y los entornos de datos de Microsoft se ha gestionado de forma fragmentada. Teníamos RLS (Row-Level Security) en el modelo semántico, permisos de Azure Data Lake Storage (ADLS) basados en ACLs y roles específicos en SQL Server. Con la llegada de Microsoft Fabric, el concepto de OneLake promete un almacenamiento único, pero esto plantea un reto crítico: ¿cómo evitamos que un usuario con acceso al Lakehouse vea absolutamente todo el contenido? Los roles de workspace tradicionales (Admin, Member, Contributor, Viewer) son demasiado gruesos para implementaciones empresariales serias.

En este artículo abordamos los Data Access Roles (DAR) en OneLake, la solución nativa para definir qué carpetas y tablas puede ver un usuario o grupo sin necesidad de crear múltiples Lakehouses o duplicar datos. Si vienes de gestionar la Seguridad en Microsoft Fabric: Roles, Workspaces y Permisos sin Agujeros, sabrás que el rol de ‘Viewer’ es un todo o nada. Los Data Access Roles rompen esa limitación, permitiendo que la seguridad se defina en el origen del dato y se respete en todos los motores analíticos de la plataforma.

Como consultor, he visto demasiados proyectos donde se recurre a la fragmentación de workspaces para segregar datos sensibles (como salarios en una tabla de empleados o márgenes brutos en retail). Esto no solo ensucia el linaje de datos, sino que multiplica el coste de mantenimiento. La seguridad a nivel de objeto (OLS) en OneLake permite mantener una arquitectura limpia, un único punto de verdad y un control de acceso riguroso.

El problema del acceso ‘Todo o Nada’ en los Workspaces

Hasta la introducción de los Data Access Roles, si dabas acceso a un analista a un Lakehouse mediante el rol de ‘Viewer’ del workspace, este podía consultar cualquier tabla Delta o archivo en la sección Files. En proyectos de Gobierno de datos para IA generativa en Microsoft Fabric: Calidad y Trazabilidad, este enfoque es inaceptable. Necesitamos que el motor de Spark, el endpoint de SQL y el motor de Power BI respeten las mismas restricciones.

El principal problema no es solo la visibilidad, sino la herencia. Un usuario con permisos de lectura en el workspace puede realizar un ‘discovery’ completo de la estructura de carpetas de OneLake. Si estamos trabajando en la Preparación de datos para aprendizaje automático en el Lakehouse de Microsoft Fabric, es probable que tengamos tablas de staging con datos sin anonimizar que solo el ingeniero de datos debe tocar, mientras que el científico de datos solo debe acceder a las tablas refinadas.

Limitaciones de los roles estándar

• Contributor: Puede leer, escribir y borrar cualquier objeto. No permite restricciones granulares.
• Viewer: Puede leer todo. Si el usuario tiene acceso al SQL Endpoint, puede consultar cualquier tabla mediante T-SQL a menos que se apliquen denegaciones explícitas en el motor SQL, lo cual duplica la gestión de seguridad.
• Compartir (Share): Permite dar acceso al ítem, pero por defecto otorga ‘Read all’.

Arquitectura de Data Access Roles en OneLake

Los Data Access Roles funcionan bajo un modelo de ‘Default Deny’. Una vez que activas la vista previa de seguridad granular en un Lakehouse, el acceso se vuelve restrictivo por defecto para aquellos que no tienen roles administrativos en el workspace. Esto significa que debemos definir explícitamente qué carpetas de Files y qué tablas de Tables son accesibles.

Es importante entender que OneLake separa la metadata de los datos físicos. Cuando asignamos un permiso sobre una tabla Delta (por ejemplo, Ventas_Detalle), el sistema otorga permisos sobre la carpeta de la tabla y los archivos Parquet subyacentes, pero también gestiona la visibilidad en el catálogo de metadatos.

Configuración paso a paso

Para implementar esta seguridad, navegamos a la configuración del Lakehouse y seleccionamos ‘Data Access Roles’. Aquí creamos un nuevo rol, por ejemplo, Analistas_Ventas_Junior. En la interfaz de selección, marcaremos únicamente las tablas Ventas, Producto y Calendario. La tabla Margen_Beneficio quedará fuera de su alcance.

-- Ejemplo de consulta que fallaría para un usuario en el rol 'Analistas_Ventas_Junior'
-- si intenta acceder a una tabla no autorizada en el SQL Endpoint
SELECT TOP 10 * 
FROM [Lakehouse_Produccion].[dbo].[Margen_Beneficio];

-- El error devuelto será un 'Access Denied' originado en OneLake,
-- no una falta de permisos en el motor SQL per se.

Impacto en Spark y Notebooks

Uno de los mayores beneficios de este modelo es que se propaga al entorno de computación distribuida. Cuando un usuario ejecuta un Notebook, el contexto de seguridad se pasa al driver de Spark. Si el código intenta leer una ruta de OneLake para la cual el usuario no tiene permiso mediante un DAR, la operación fallará a nivel de sistema de archivos.

Esto es vital cuando trabajamos con Consumo de bases de datos espejadas en Fabric con Notebooks y SQL. Si hemos espejado una base de datos de recursos humanos, queremos que ciertos Notebooks de procesamiento de nóminas solo sean ejecutables por perfiles autorizados, incluso si el código del Notebook es visible para otros.

# Intento de lectura de una carpeta protegida en OneLake desde un Notebook
# Si el usuario no tiene el Data Access Role correspondiente, Spark lanzará una Py4JJavaError

df = spark.read.format("delta").load("abfss://workspace@onelake.dfs.fabric.microsoft.com/Lakehouse.Lakehouse/Tables/Salarios_Privados")
df.show()

# Error esperado: Operation failed: "This endpoint does not support the operation with this authentication.", 403

Comparativa: Roles de Workspace vs Data Access Roles

En la siguiente tabla desglosamos cuándo aplicar cada capa de seguridad. Un error común es intentar solucionar con Data Access Roles lo que debería ser una estructura de Workspaces bien definida.

Integración con Power BI y Direct Lake

El modo Direct Lake es una de las joyas de Fabric, permitiendo que Power BI lea directamente archivos Delta de OneLake sin importar los datos a memoria (Import) ni consultar via SQL (DirectQuery). Sin embargo, esto planteaba un agujero de seguridad: ¿cómo restringir datos si no hay un motor SQL de por medio para aplicar RLS?

Los Data Access Roles resuelven esto. Cuando un informe de Power BI en modo Direct Lake es accedido por un usuario, el servicio de Power BI solicita los datos a OneLake utilizando la identidad del usuario (o una identidad delegada). Si el usuario no tiene permiso sobre la tabla Costes_Industriales en OneLake, el visual simplemente no mostrará datos, lanzando un error de permisos a nivel de origen.

Es importante notar que esto es distinto a la integración de datos de Eventhouse a OneLake, donde la seguridad puede residir en KQL. En el caso de OneLake puro, los DAR actúan como la última frontera antes del bit físico.

Errores frecuentes en la implementación de permisos granulares

En mis auditorías de arquitectura en Fabric, detecto patrones que comprometen tanto la seguridad como el rendimiento:

1. Ignorar el SQL Endpoint: Muchos administradores configuran DAR pero olvidan que los permisos de SQL (GRANT/DENY) pueden entrar en conflicto. Si un usuario tiene db_datareader en el SQL Endpoint, podría saltarse algunas restricciones si el motor SQL tiene una identidad gestionada con permisos superiores.
2. Asignación individual de usuarios: Nunca asignes roles a correos electrónicos individuales. Usa siempre grupos de seguridad de Entra ID (Azure AD). Si un consultor deja el proyecto, solo tienes que tocar el grupo, no revisar cada Lakehouse.
3. Exceso de granularidad: Crear un rol para cada tabla es inmanejable. Agrupa las tablas por dominios de datos (ej. Ventas_Lectura_Basica, Finanzas_Lectura_Completa).
4. No probar con identidades no administrativas: Como los administradores de workspace siempre ven todo (bypass), a menudo olvidan probar el DAR con una cuenta de prueba que solo sea ‘Viewer’.

Checklist para una configuración segura

• Verificar que el Lakehouse tiene activada la opción de ‘Preview’ para Data Access Roles.
• Definir grupos de Entra ID alineados con los roles de negocio (Analistas, Managers, Auditores).
• Identificar carpetas sensibles en Files (especialmente logs de procesos o archivos raw).
• Validar que los informes de Power BI en Direct Lake funcionan correctamente para usuarios con roles restringidos.
• Documentar la matriz de accesos en el linaje de datos de la organización.

Preguntas frecuentes

¿Sustituyen los Data Access Roles a la RLS de Power BI?

No necesariamente. DAR controla la visibilidad de objetos completos (tablas o carpetas). Si necesitas que un comercial solo vea las filas de su región dentro de una misma tabla, deberás seguir usando Row-Level Security (RLS) en el modelo semántico.

¿Qué ocurre si un usuario tiene acceso por Workspace y por Data Access Role?

Los roles administrativos del workspace (Admin, Member, Contributor) siempre tienen prioridad y pueden ver todos los datos en OneLake, ignorando cualquier restricción impuesta por los Data Access Roles. Los DAR solo afectan a los usuarios con rol de ‘Viewer’ o aquellos que acceden mediante aplicaciones compartidas.

¿Puedo aplicar Data Access Roles a nivel de columna?

Actualmente, OneLake Data Access Roles se aplican a nivel de objeto (tabla o carpeta). Para seguridad a nivel de columna (CLS), la recomendación actual es gestionarlo a través del SQL Analytics Endpoint mediante vistas o permisos específicos de T-SQL, o bien en el modelo semántico de Power BI.

¿Cómo afecta esto al rendimiento de las consultas?

El impacto es despreciable. La validación de permisos en OneLake está integrada en el flujo de apertura de archivos (ABFSS). No hay una sobrecarga medible como la que podrías encontrar en reglas complejas de RLS con filtros dinámicos en DAX.