OneLake security: cómo proteger datos en Microsoft Fabric

OneLake security permite definir una sola vez quién puede ver qué datos en Microsoft Fabric (tablas, filas y columnas) y aplicarlo igual en Spark, SQL y Power BI. En este artículo verás cómo combinarlo con los roles de workspace, cómo configurarlo paso a paso y qué buenas prácticas evitan las fugas de acceso más habituales.

En resumen: OneLake security permite definir en un solo sitio qué tablas, filas y columnas puede ver cada usuario en Microsoft Fabric, y esa regla se respeta en Spark, en el SQL analytics endpoint y en Power BI con Direct Lake on OneLake. Solo se aplica a usuarios con rol Viewer o con permiso Read sobre el ítem: Admin, Member y Contributor siguen viendo todos los datos. Para que funcione, revisa el rol DefaultReader, asigna grupos de Microsoft Entra ID y activa el User’s identity access mode en el SQL endpoint.

¿Qué es OneLake y por qué importa su seguridad?

OneLake es el lago de datos único de Microsoft Fabric: un solo almacén lógico por organización donde se guardan los datos de todos los lakehouses, warehouses y bases de datos de Fabric. Se organiza de forma jerárquica, como un sistema de carpetas:

Como un mismo dato puede consultarse desde notebooks, SQL o informes de Power BI, el reto no es solo protegerlo, sino que la protección sea la misma por cualquier camino. Para eso existe OneLake security.

¿A quién va dirigido? A Data Engineers, arquitectos de datos, administradores de la plataforma Fabric y responsables de gobierno del dato que necesitan abrir los datos a más usuarios sin perder el control.

¿Cómo funciona OneLake security en Microsoft Fabric?

OneLake security decide qué datos puede ver cada usuario (Plano de datos – tablas, filas y columnas), mientras que los roles de workspace deciden qué puede hacer (Plano de control). Microsoft Fabric protege OneLake en estos dos planos, que no conviene mezclar:

Roles de workspace: quién construye y quién consume

Admin, Member y Contributor ya leen todos los datos del workspace, y OneLake security no les restringe. Las reglas de acceso al dato se aplican a usuarios con rol Viewer o con el ítem compartido con permiso Read.

Consulta el detalle de permisos en la documentación de roles de workspace en Microsoft Fabric.
 

Roles de OneLake security

Un rol de OneLake security (antes llamado data access role) se crea sobre un ítem, como un lakehouse, y define:

• Permiso: Read (leer) o ReadWrite (leer y escribir).
• Datos: todo el ítem o solo ciertos esquemas, tablas o carpetas.
• Miembros: usuarios, grupos de Microsoft Entra ID o identidades de servicio.

El modelo es de denegación por defecto (sin rol, no hay acceso) y solo admite roles de concesión: si una persona pertenece a varios roles, su acceso es la suma de todos ellos.

OLS, RLS y CLS: qué tablas, qué filas y qué columnas

Dentro de cada rol puedes afinar el acceso en tres niveles:

El rol de workspace decide primero: los roles con Write leen todo; para Viewers y usuarios con Read, los OneLake security roles determinan qué tablas, filas y columnas ven, y solo los motores compatibles pueden filtrarlas.

Cómo configurar la seguridad en OneLake

Configurar OneLake security requiere asignar roles de workspace a grupos, crear un rol de OneLake security con sus datos, reglas y miembros, y activar el modo de identidad de usuario en el SQL analytics endpoint.

Ejemplo paso a paso

Ponemos el ejemplo de un informe comercial. En este ejemplo, el equipo comercial de la zona «Norte» debe ver solo sus pedidos y sin la columna «margen» del lakehouse «LH_Ventas_Gold». Los nombres de los botones corresponden a la interfaz de Fabric en inglés; las capturas muestran la interfaz en español.

1. Asigna los roles de workspace a grupos. En el workspace, abre Manage access y añade el grupo de Microsoft Entra ID del equipo comercial con el rol Viewer. Reserva Contributor para quien construye los datos.

   

2. Abre la seguridad del lakehouse. Entra en LH_Ventas_Gold y selecciona Manage OneLake security en la cinta del lakehouse.

   

3. Revisa el rol DefaultReader. Este rol da acceso a todos los datos a cualquier usuario con permiso ReadAll. Edítalo o elimínalo si no todos deben verlo todo. Atención: si un usuario sigue en DefaultReader, conserva el acceso completo aunque lo añadas a un rol más restrictivo.

   

4. Crea un rol nuevo. En la pestaña de roles, selecciona New, ponle un nombre (por ejemplo, VentasNorte), deja el tipo Grant con el permiso Read y selecciona Next. No marques ReadWrite: un rol con escritura no admite reglas de filas ni de columnas.

   

5. Elige los datos. Marca Selected data y pulsa Edit. En la ventana Edit data for role, selecciona la tabla «ventas.pedidos».
6. Aplica RLS. En la misma ventana, con la tabla seleccionada, abre la pestaña Data access → Row security y escribe la regla (sintaxis de RLS en OneLake):
   SQL

   SELECT * FROM ventas.pedidos WHERE zona =
   ‘Norte’

   

7. Aplica CLS en el mismo rol. Pasa a Column security, cambia el permiso de la columna «margen» a Hide y confirma con Add data. Buena práctica: las reglas de filas y columnas que deban aplicarse juntas van siempre en el mismo rol.

   

8. Añade los miembros y crea el rol. Selecciona Next, escribe el nombre del grupo de Entra ID (mejor que usuarios uno a uno) y selecciona Create.

   

9. Activa la seguridad en SQL. Abre el SQL analytics endpoint del lakehouse, entra en Settings → Data access mode, elige User’s identity access mode (la opción que usa OneLake security para las tablas) y pulsa Apply. Desde ese momento, las tablas se protegen con OneLake security y las vistas, procedimientos y funciones siguen con la seguridad de SQL (OneLake security en el SQL analytics endpoint). Atención: el cambio elimina los permisos de seguridad que ya hubiera en el endpoint SQL, deja momentáneamente sin servicio los endpoints SQL del workspace y cancela las consultas en curso. Hazlo fuera del horario laboral.

   

10. Comprueba el resultado. En Manage OneLake security → Members, revisa qué rol tiene cada persona y a cuántos objetos de datos puede acceder.

    

    Selecciona un miembro y abre Granted data: solo debe aparecer el esquema ventas con la tabla «pedidos», concedidos por VentasNorte (la tabla «clientes» no aparece). Después, prueba con un usuario real del equipo.

    

    Los cambios en un rol tardan unos 5 minutos en aplicarse, y los cambios de pertenencia a un grupo, alrededor de una hora.

    ¿Para qué sirve OneLake security? Ventajas y casos de uso

    OneLake security sirve para abrir los datos a más usuarios sin perder el control: la regla se define una vez y se respeta en todos los motores compatibles.

    Ventajas para la empresa:

    • Una sola definición de seguridad: la regla se crea una vez en OneLake y se respeta en Spark, en SQL y en los informes de Power BI.
    • Menos copias de datos: cada área comparte sus datos con shortcuts en lugar de duplicarlos, y la seguridad del origen viaja con ellos.
    • Autoservicio controlado: los analistas crean sus propios informes sin acceder a filas o columnas que no les corresponden.
    • Gestión sencilla: al trabajar con grupos de Microsoft Entra ID, las altas, bajas y cambios de puesto se resuelven en el grupo, no en Fabric.
    • Cumplimiento: los datos sensibles (salarios, datos personales, márgenes) quedan acotados a quien realmente los necesita.

    Casos de uso habituales:

    Escenario	Problema	Cómo se resuelve
    Data lake corporativo con varios dominios	Ventas, Finanzas y Operaciones comparten un mismo OneLake	Cada dominio es dueño de su workspace y publica a los demás solo los esquemas que decide, mediante roles y shortcuts
    Perfiles distintos sobre los mismos datos	Data Engineers, analistas y usuarios de negocio necesitan niveles de acceso diferentes	Data Engineer como Contributor; analista como Viewer con un rol de OneLake security; usuario de negocio solo con acceso a informes
    Datos sensibles de RR. HH.	La tabla de empleados contiene DNI, IBAN y salario	Un rol general con CLS que oculta esas columnas, y un rol de nóminas con RLS por país
    Equipos comerciales por zona	Cada comercial debe ver solo su cartera	RLS por zona en la tabla de pedidos, asignado a un grupo de Entra ID por zona

    ¿Qué motores aplican OneLake security? Power BI, SQL, Spark y Entra ID

    OneLake security solo es eficaz si el motor que lee los datos la aplica. Estos son los que la respetan hoy:

    Motor o herramienta	¿Aplica RLS y CLS de OneLake?	Qué debes configurar
    Lakehouse y notebooks de Spark	Sí	Runtime 1.3 o superior
    SQL analytics endpoint	Sí	Modo User’s identity access mode (en el modo por defecto, delegated, solo cuentan los permisos SQL)
    Power BI: Direct Lake on OneLake	Sí	Crear el modelo semántico en modo Direct Lake on OneLake
    Power BI: Direct Lake on SQL	A través del endpoint SQL	Si una tabla tiene RLS en el endpoint, la consulta pasa a DirectQuery y pierde rendimiento
    Eventhouse	Solo RLS	En preview
    Motores de terceros autorizados	Sí, si el motor lo implementa	En preview

    Errores comunes y cómo evitarlos

    Error	Consecuencia	Solución
    Dar el rol Contributor a quien solo consume datos	Ve y modifica todos los datos; ninguna regla le restringe	Asignar Viewer y conceder datos con OneLake security
    Olvidar el rol DefaultReader	Cualquier usuario con ReadAll ve el lakehouse completo	Editar o eliminar DefaultReader
    Dejar el endpoint SQL en modo delegado	Las reglas de OneLake no se aplican al consultar con SQL	Cambiar a User’s identity access mode
    Proteger los datos solo en el modelo de Power BI	El usuario puede saltarse las reglas consultando el lakehouse	Definir RLS/CLS en OneLake security
    Repartir RLS y CLS de una tabla en roles distintos	Errores de consulta para el usuario	Unificar las reglas en un solo rol
    Renombrar tablas o columnas sin revisar los roles	Las reglas dejan de aplicarse o bloquean el acceso	Actualizar los roles tras cada cambio de esquema
    Asignar listas de distribución a los roles	El endpoint SQL no reconoce a sus miembros	Usar grupos de seguridad de Entra ID

    Preguntas frecuentes sobre la seguridad en OneLake

    ¿Qué diferencia hay entre los roles de workspace y los roles de OneLake security?

    
    
    
    

    Los roles de workspace deciden qué puede hacer alguien (crear, editar, compartir). Los roles de OneLake security deciden qué datos puede ver: tablas, filas y columnas.

    ¿OneLake security restringe a un usuario con rol Contributor?

    
    
    
    

    No. Admin, Member y Contributor ya tienen acceso de escritura a todo el workspace. OneLake security se aplica a usuarios con rol Viewer o con permiso Read sobre el ítem.

    ¿En qué ítems puedo crear roles de OneLake security?

    
    
    
    

    En lakehouses (permisos Read y ReadWrite) y en bases de datos y catálogos replicados (solo Read). Consulta la lista actualizada de ítems compatibles.

    ¿Las reglas de OneLake se aplican en mis informes de Power BI?

    
    
    
    

    Sí, si el modelo semántico usa Direct Lake on OneLake. Con Direct Lake on SQL, la seguridad depende del SQL analytics endpoint.

    ¿Puedo usar RLS dinámico, por ejemplo filtrar según el usuario conectado?

    
    
    
    

    No. Hoy RLS en OneLake security no admite reglas dinámicas ni multitabla: cada regla es un filtro fijo sobre una tabla, que se asigna al grupo correspondiente. Revisa las limitaciones conocidas de RLS, porque esta funcionalidad evoluciona.

    ¿OneLake security admite enmascaramiento dinámico de datos (DDM)?

    
    
    
    

    No. El enmascaramiento dinámico de datos no forma parte de OneLake security: se define en el SQL analytics endpoint con ALTER TABLE y la opción MASKED (más información).

    ¿La seguridad se mantiene al usar shortcuts?

    
    
    
    

    Sí. La política se aplica en el origen: cuando se consultan tablas a través de un shortcut, se respetan los roles, RLS y CLS de OneLake definidos en el lakehouse de origen.

    ¿A qué tipos de tabla se aplican RLS y CLS?

    
    
    
    

    A tablas Delta Parquet o tablas Iceberg virtualizadas. Si un rol aplica reglas de filas o columnas sobre otro tipo de tabla, los miembros del rol pierden el acceso a la tabla completa (más información).

    ¿Cuánto tardan en aplicarse los cambios?

    
    
    
    

    Unos 5 minutos para los cambios en un rol y alrededor de una hora para los cambios de pertenencia a un grupo de Entra ID.

     

    Conclusiones

    Asegurar OneLake no consiste en añadir reglas en cada herramienta, sino en ponerlas en el sitio correcto. Los roles de workspace deciden quién construye; OneLake security decide qué datos ve cada persona, y esa decisión se respeta en Spark, SQL y Power BI. Con grupos de Microsoft Entra ID, roles bien acotados y revisiones periódicas, puedes abrir los datos a toda la organización sin perder el control sobre la información sensible.

    Si quieres dominar la seguridad y el gobierno del dato en Fabric, descubre nuestro Programa Fabric BI o el Curso de Microsoft Fabric. Y si necesitas implantar OneLake security en tu organización, en Aglaia Consulting te acompañamos con nuestro servicio de Data & BI.