Arquitectura de permisos quirúrgicos en OneLake: Implementación de Data Access Roles
En proyectos de Microsoft Fabric, uno de los desafíos recurrentes es la gestión de la visibilidad de los datos. Históricamente, los roles de área de trabajo (Workspace Roles) han funcionado bajo una lógica de «todo o nada»: si un usuario es Viewer en un Lakehouse, tiene acceso de lectura a todas las tablas y carpetas de OneLake dentro de ese artefacto. Este enfoque es inviable en escenarios de sector público o industria, donde los datos de RRHH, costes marginales o estrategias de precios deben coexistir en el mismo Lakehouse pero estar restringidos a grupos específicos.
La introducción de los Data Access Roles (DAR) en OneLake cambia las reglas del juego. Ya no dependemos exclusivamente de la herencia del área de trabajo; ahora podemos definir permisos quirúrgicos que limitan qué carpetas del File System y qué tablas del Managed Section puede ver un usuario. Esto no es solo una capa de interfaz; es una restricción que se aplica a nivel de almacenamiento y afecta a todos los motores que consumen OneLake, desde Notebooks de Spark hasta el SQL Analytics Endpoint.
Antes de profundizar, es vital entender que esta seguridad granular es un complemento a la Seguridad en Microsoft Fabric: Roles, Workspaces y Permisos sin Agujeros. Si los roles de Workspace no están bien estructurados, los Data Access Roles pueden generar una falsa sensación de seguridad.
El cambio de paradigma: Del Workspace al Objeto
En el modelo tradicional de Power BI y Fabric, el acceso se concedía mediante membresías al Workspace (Admin, Member, Contributor, Viewer). Si dabas acceso a un Lakehouse, el usuario podía explorar toda la estructura delta. Con los Data Access Roles, OneLake permite interceptar la solicitud de datos y validar si el usuario tiene permiso explícito para esa ruta de carpeta o esa tabla Delta específica.
Este mecanismo resuelve el problema del over-sharing. En mis consultorías de retail, a menudo encontramos que los equipos de logística necesitan ver el inventario, pero no el margen neto de cada producto que reside en la misma tabla de hechos. Aunque el RLS y CLS en Microsoft Fabric pueden mitigar esto en el motor SQL, los Data Access Roles son la única forma de evitar que un usuario con conocimientos de Spark abra un Notebook y lea los archivos Parquet directamente desde OneLake.
| Característica | Workspace Roles | Data Access Roles (DAR) |
|---|---|---|
| Granularidad | Nivel de Artefacto (Lakehouse entero) | Nivel de Carpeta y Tabla |
| Ámbito de Aplicación | Interfaz de Fabric y APIs | OneLake Storage (Spark, SQL, Accesos externos) |
| Uso recomendado | Gestión de equipos de desarrollo | Gobierno de datos y segregación departamental |
| Complejidad de gestión | Baja | Alta (requiere auditoría de rutas) |
Configuración técnica de los Data Access Roles
Para implementar DAR, el primer paso es desactivar la herencia automática de permisos para los usuarios que no sean administradores. En la configuración del Lakehouse, dentro de la sección de OneLake Data Access, podemos crear roles específicos. Por ejemplo, un rol denominado «Ventas_Analistas_Junior» que solo tenga acceso a la carpeta /Tables/Ventas_Publicas y no a /Tables/Margenes_Directivos.
Es fundamental entender que para que un usuario se vea afectado por los Data Access Roles, no debe tener un rol de Member o Contributor en el Workspace. Los roles de administración y edición siempre saltan estas restricciones. El usuario objetivo debe ser, como máximo, Viewer o acceder mediante el permiso de «Read All OneLake Data» limitado por DAR.
Gestión de permisos en carpetas y tablas
Al definir un rol en OneLake, especificamos rutas. Esto es especialmente útil cuando usamos Shortcuts en OneLake: Virtualización de datos multicloud en Microsoft Fabric. Si un Lakehouse contiene atajos a un ADLS Gen2 externo, podemos aplicar DAR sobre la carpeta del atajo, asegurando que el acceso granular se mantenga incluso en datos virtualizados.
# Ejemplo de validación de acceso en un Notebook
# Si el Data Access Role está bien configurado, esta celda fallará
# para un usuario sin permisos sobre la carpeta 'Finanzas'
try:
df = spark.read.format("delta").load("Files/Finanzas/Presupuesto_2024")
display(df)
except Exception as e:
print("Acceso denegado: El usuario no tiene permisos en esta ruta de OneLake.")
# Mensaje esperado: PermissionDenied (403)Interacción entre motores analíticos
Una de las preguntas que más recibo como consultor es cómo afecta esto al SQL Analytics Endpoint. La respuesta corta es que el SQL Endpoint respeta los permisos de OneLake. Si un usuario intenta consultar una tabla mediante T-SQL pero su rol de acceso a datos en OneLake le prohíbe leer la carpeta Delta subyacente, la consulta fallará.
Sin embargo, hay un matiz importante: la seguridad en el SQL Endpoint también se puede gestionar mediante el comando GRANT de T-SQL. Para evitar conflictos, mi recomendación es siempre centralizar la seguridad de almacenamiento en OneLake (DAR) para perfiles técnicos que usan Spark, y usar seguridad a nivel de esquema o RLS para usuarios que solo consumen datos vía SQL o Power BI.
-- Aunque el usuario tenga GRANT SELECT en la tabla,
-- si el Data Access Role en OneLake bloquea la carpeta,
-- el motor SQL no podrá recuperar los archivos Parquet.
SELECT TOP 10 *
FROM [LH_Ventas].[dbo].[Fact_Margenes]
-- Resultado: Error de acceso a nivel de almacenamiento.Limitaciones y trade-offs del modelo granular
No todo es perfecto en la implementación de permisos granulares. Existe un coste de gestión. En despliegues con cientos de tablas, mantener Data Access Roles individuales se vuelve inmanejable. Aquí es donde entra en juego una buena estructura de Gestión de Workspaces en Fabric: Estructura de Entornos y Capacidades. En lugar de aplicar DAR tabla por tabla, es más eficiente organizar los datos en subcarpetas lógicas dentro de la sección Files del Lakehouse y aplicar permisos a nivel de carpeta superior.
- Rendimiento: La evaluación de permisos en OneLake añade una latencia mínima, casi imperceptible, pero existente. En consultas masivas de miles de archivos pequeños, el impacto es nulo frente al overhead del propio motor Spark.
- Herencia de Atajos: Los permisos DAR sobre un Shortcut no se propagan automáticamente al origen externo (por ejemplo, AWS S3). Solo controlan quién puede ver el atajo dentro del ecosistema Fabric.
- Exploración de catálogos: Los usuarios restringidos pueden seguir viendo el nombre de la tabla en el catálogo de objetos, pero no podrán leer su contenido ni ver su esquema detallado si el permiso es denegado.
Errores frecuentes en la implementación
A lo largo de varios proyectos de arquitectura de datos, he detectado patrones de error que comprometen la seguridad granular:
- Confundir roles de Workspace con DAR: Dar rol de «Contributor» a un usuario y luego intentar limitarlo con un Data Access Role. El rol de Contributor siempre tiene privilegios de superusuario sobre los datos del Workspace.
- No considerar el linaje: Bloquear una tabla en el Lakehouse pero permitir el acceso a un informe de Power BI con el modo «Direct Lake». Si el informe está en modo Direct Lake, el acceso se realiza bajo la identidad del usuario, y si DAR bloquea la tabla, el informe fallará.
- Descuidar la limpieza de versiones: A veces, los usuarios pueden acceder a metadatos de versiones antiguas si no se gestionan correctamente los procesos de mantenimiento. Recomiendo revisar la Limpieza de versiones antiguas con VACUUM en Delta Lake y Microsoft Fabric para asegurar que no queden restos de datos sensibles en archivos huérfanos.
Checklist de validación de seguridad en OneLake
- Confirmar que los usuarios finales solo tienen el rol de Viewer en el área de trabajo o acceso compartido al artefacto.
- Verificar que la opción «OneLake Data Access (preview)» está habilitada en la configuración del Lakehouse.
- Mapear cada Data Access Role a un grupo de seguridad de Microsoft Entra (antes Azure AD), nunca a usuarios individuales.
- Validar el acceso mediante un Notebook de prueba utilizando el comando
mssparkutils.fs.ls()sobre las rutas restringidas. - Documentar las excepciones de seguridad en el diccionario de datos para evitar que los ingenieros de datos muevan tablas sensibles a carpetas públicas por error.
Preguntas frecuentes
¿Los Data Access Roles reemplazan al RLS de SQL?
No, son complementarios. DAR controla el acceso a los archivos físicos (folders/tables) en OneLake. RLS controla el acceso a filas específicas dentro de una tabla. Si necesitas filtrar por «Región = Norte», usa RLS. Si necesitas que un usuario no pueda ni siquiera tocar la tabla de salarios, usa DAR.
¿Puedo aplicar permisos granulares a archivos CSV en la sección Files?
Sí, los Data Access Roles funcionan tanto para la sección de tablas (Delta) como para la sección de archivos (Files). Esto es ideal para restringir el acceso a archivos fuente de aterrizaje (landing) antes de que sean procesados por las ETL.
¿Qué ocurre si un usuario pertenece a dos roles con permisos contradictorios?
OneLake aplica el principio de unión de permisos. Si el Rol A permite el acceso a la Carpeta 1 y el Rol B permite el acceso a la Carpeta 2, el usuario tendrá acceso a ambas. No existe un permiso de «Deny» explícito que sobrescriba a un «Allow»; el acceso se basa en la suma de privilegios concedidos.
