La seguridad de datos en Fabric no vive en el informe: vive en cada ruta por la que alguien puede llegar al dato. Identidad, permisos del elemento, OneLake, y luego RLS y OLS dentro del modelo semantico. Ninguna de esas capas, por si sola, protege todo.
Cuando alguien pregunta "quien puede ver estas ventas?", la respuesta natural es abrir el informe y aplicar un filtro. Es la respuesta incompleta. En Microsoft Fabric un mismo usuario puede llegar a los mismos numeros por un informe, por el modelo semantico, por un endpoint SQL, por Excel, por una API o por un agente. Si la restriccion vive solo en el informe, todas las demas puertas quedan abiertas.
Gobernar quien ve que dato es una decision de arquitectura, no un ajuste de ultimo momento. Este articulo ordena las capas que hay que pensar y, sobre todo, la disciplina de probarlas antes de publicar.
La seguridad se disena por rutas de acceso, no por informe
El error mas comun es tratar la seguridad como una propiedad del reporte. En Fabric el control tiene que pensarse por identidad, rol, elemento, dato y experiencia. Cada una de esas dimensiones es una puerta distinta.
Microsoft organiza estas piezas en su escenario de seguridad de Fabric, que describe como la identidad y la proteccion se sostienen de extremo a extremo. La idea de fondo es simple de enunciar y facil de olvidar: proteger el informe no protege el lakehouse, el endpoint SQL ni el modelo.
Antes de escribir una sola regla conviene mapear que roles existen, por que experiencia consume cada rol y que datos puede tocar en cada una. Ese mapa es el que decide donde poner el control, no la herramienta.
Cuatro capas que hacen cosas distintas
Conviene no confundir mecanismos que se parecen pero resuelven problemas diferentes:
- Workspace roles. Definen capacidades de colaboracion (quien administra, edita o consume dentro de un area de trabajo). Son necesarios, pero no alcanzan por si solos para todos los escenarios de dato.
- Item permissions. Controlan el acceso a artefactos concretos: un informe, un modelo, un lakehouse. Resuelven "quien abre esto", no "que filas ve dentro".
- OneLake security. Permite aplicar seguridad granular sobre tablas, filas y columnas a traves de los distintos motores que leen OneLake. Es la capa que evita que una restriccion se pierda cuando el dato se consulta por fuera del modelo.
- RLS y OLS del modelo semantico. La seguridad a nivel de fila (RLS) y a nivel de objeto (OLS) protege dentro del modelo. Es util cuando el consumo se canaliza por el modelo semantico, y deja de proteger cuando alguien llega al dato por otra puerta.
El modelo de control de acceso a datos de OneLake detalla como se aplica esa seguridad granular por motor. La lectura que importa es esta: RLS en el modelo y seguridad en OneLake no son intercambiables. Resuelven la misma pregunta en capas distintas, y cual usar depende de por donde entra el consumidor.
RLS y OLS protegen dentro del modelo, no fuera
RLS filtra filas segun la identidad; OLS oculta tablas o columnas enteras. Ambos son potentes y ambos comparten un limite: solo actuan cuando la consulta pasa por el modelo semantico.
Si el mismo dato se expone por un endpoint SQL del lakehouse o se lee directo desde OneLake, la regla de RLS del modelo no viaja con el. Por eso la seguridad de fila en el modelo tiene que ir acompanada de la capa correspondiente en OneLake o en los permisos del elemento cuando existen esas otras rutas de consumo.
Hay un permiso que suele pasar desapercibido: Build. Quien puede crear contenido sobre un modelo tambien puede ver sus metadatos. Ese permiso gobierna mas de lo que parece y debe tratarse como parte del diseno de seguridad, no como un checkbox de colaboracion.
Direct Lake mueve el problema de la identidad
Direct Lake permite que Power BI consuma datos Delta desde OneLake sin duplicarlos como un import tradicional. Eso cambia como se piensan volumen, frescura y, muy en particular, permisos.
La clave es que la identidad efectiva con la que se valida el acceso puede cambiar el comportamiento de la consulta. La integracion de seguridad de Direct Lake explica cuando el acceso y la fuente alteran como se resuelve la consulta, incluido el momento en que Direct Lake puede recurrir a DirectQuery. Si la seguridad, las vistas o los limites no encajan, Direct Lake on OneLake puede incluso devolver un error en lugar de recurrir a otro modo.
De ahi una decision concreta: si vas a usar Direct Lake con seguridad de fila, la eleccion entre single sign-on e identidad fija no es un detalle de configuracion, es parte del diseno de acceso. Y no se valida leyendo la documentacion; se valida con una prueba real sobre volumen, permisos y tablas Delta.
La regla que sostiene todo: probar antes de publicar
Ninguna de estas capas se da por buena porque "deberia funcionar". La disciplina practica es probar los permisos con identidades reales antes de liberar a produccion, y probar cada ruta por separado.
Eso significa, como minimo:
- Validar el informe con un usuario que tenga el rol restringido, no con una cuenta de administrador.
- Repetir la prueba consultando el modelo por fuera del informe (por ejemplo desde Excel).
- Verificar el endpoint SQL o el acceso directo a OneLake si esos caminos estan abiertos.
- Confirmar que Build y otros permisos de elemento no filtran metadatos ni estructura que deban quedar ocultos.
No asumas que una restriccion en el informe protege todos los caminos por los que pueden consultarse los datos. Ese es el error que las pruebas por ruta estan disenadas para atrapar.
Esta forma de trabajar es parte de un gobierno mas amplio: nombres, responsables, linaje, sensibilidad y ciclo de vida. Si quieres ver como encaja la seguridad con el resto de los controles nativos, revisa como Purview y Fabric se integran para gobierno y linaje.
Como decidir sin universalizar
No existe una configuracion que sirva para todos los casos. Que capa usar depende de por donde consume cada rol, de si hay Direct Lake, del licenciamiento y de la capacidad. La pregunta correcta no es "que regla activo", sino "que rutas de acceso existen y como pruebo cada una".
Ese es exactamente el tipo de decision que conviene ordenar con un diagnostico antes de que se convierta en un incidente: mapear rutas de acceso, responsables y gobierno junto con las fuentes y los procesos, y priorizar los riesgos que aparezcan. No es una regla suelta: es el mapa que dice donde poner cada control.
Que hacer esta semana
Toma tu informe mas sensible y prueba a abrirlo con una identidad que tenga el rol mas restringido. Despues intenta llegar al mismo dato por Excel o por el endpoint SQL del lakehouse con esa misma identidad. Si en alguno de esos caminos ves mas de lo que deberias, ya tienes la primera brecha que la seguridad por rutas resuelve y el informe no.
Si quieres ver como abordamos este tipo de diagnostico y la seguridad por capas en un caso real, mira la demo gratuita.
Preguntas relacionadas
¿RLS del modelo semantico protege el endpoint SQL del lakehouse?
No por si solo. RLS y OLS actuan cuando la consulta pasa por el modelo semantico. Si el dato se expone por un endpoint SQL o se lee directo desde OneLake, hay que aplicar seguridad en OneLake o permisos de elemento en esa ruta, porque la regla del modelo no viaja con el dato.
¿Que diferencia hay entre item permissions y OneLake security?
Item permissions controlan quien abre un artefacto concreto (un informe, un modelo). OneLake security aplica seguridad granular sobre tablas, filas y columnas a traves de los motores que leen OneLake. El primero resuelve el acceso al objeto; el segundo, que dato se ve dentro cuando el consumo llega por fuera del modelo.
¿Por que el permiso Build importa para la seguridad?
Porque quien puede crear contenido sobre un modelo tambien puede ver sus metadatos. Build no es solo un permiso de colaboracion: expone estructura del modelo, asi que debe gobernarse como parte del diseno de seguridad y revisarse en las pruebas antes de publicar.
¿Como afecta Direct Lake a la seguridad de fila?
La identidad efectiva con la que se valida el acceso puede cambiar el comportamiento de la consulta, y Direct Lake puede recurrir a DirectQuery o devolver un error segun la seguridad, las vistas y los limites. La eleccion entre single sign-on e identidad fija es parte del diseno de acceso y debe validarse con una prueba de concepto sobre volumen y permisos reales.
¿Con que identidad conviene probar los permisos?
Nunca con una cuenta de administrador. Hay que usar una identidad que tenga el rol mas restringido y repetir la prueba por cada ruta de consumo: informe, modelo desde Excel, endpoint SQL y acceso directo a OneLake. Solo asi se atrapan las brechas que una restriccion en el informe no cubre.