La seguridad a nivel de objeto (OLS) restringe columnas y tablas dentro del modelo semantico, pero solo protege el consumo que se canaliza por ese modelo. El error mas comun es asumir que una restriccion aplicada en un informe protege todos los caminos por los que se pueden consultar los datos. La regla practica es probar cada ruta de acceso (informe, Excel, endpoint SQL, OneLake, API o agente) antes de publicar.
Que es OLS y donde vive dentro del modelo
La seguridad a nivel de objeto (Object Level Security, OLS) forma parte de las protecciones que viven dentro del modelo semantico, junto con la seguridad a nivel de fila (Row Level Security, RLS). Mientras RLS filtra que filas ve un usuario, OLS controla si un usuario puede ver, o incluso saber que existen, ciertas columnas y tablas.
OLS es util cuando el consumo se canaliza por el modelo semantico. Ese es el punto que muchos equipos pasan por alto: OLS protege dentro del modelo, no fuera de el. En Fabric, un mismo usuario puede interactuar con informes, modelos, lakehouses, endpoints SQL, Excel, APIs o agentes. Cada uno de esos es una ruta de acceso distinta, y OLS solo cubre las que pasan por el modelo semantico.
Por eso la seguridad en Fabric se disena por rutas de acceso, no solo por informe. El control debe pensarse por identidad, rol, elemento, dato y experiencia.
Error 1: creer que una restriccion en el informe protege todos los caminos
Este es el error raiz del que derivan casi todos los demas. Ocultar una tarjeta o una columna en el informe es cosmetica, no seguridad. Si el dato existe en el modelo y el usuario tiene otra ruta para consultarlo, lo vera.
Ejemplos de rutas que evaden una restriccion puramente visual:
- Conectar el modelo desde Excel con Analizar en Excel y arrastrar la columna supuestamente oculta.
- Consultar el endpoint SQL del lakehouse o warehouse directamente.
- Leer las tablas subyacentes en OneLake con otro motor.
- Llamar a la API del modelo o preguntarle a un agente que se apoya en esos datos.
La regla es simple: nunca des por hecho que una restriccion en el informe cubre todos los caminos por los que pueden consultarse los datos. Se protege el dato en su origen o en la capa que todas las rutas comparten, no en la ultima pantalla.
Error 2: confundir las capas de seguridad de Fabric
Fabric ofrece varias capas de control y cada una resuelve un problema distinto. Mezclarlas, o esperar que una haga el trabajo de otra, deja huecos. Esta tabla resume para que sirve cada capa:
| Capa | Que controla | Cuando aplica |
|---|---|---|
| Roles de workspace | Capacidades de colaboracion (quien edita, publica, administra) | Colaboracion, no basta por si sola para todos los escenarios |
| Permisos de elemento | Acceso a informes, modelos y artefactos concretos | Compartir piezas especificas |
| Seguridad de OneLake | Granularidad en tablas, filas y columnas a traves de motores | Cuando el consumo cruza varios motores |
| RLS y OLS del modelo | Filas y objetos dentro del modelo semantico | Cuando el consumo se canaliza por el modelo |
OLS y RLS son potentes, pero solo dentro de su alcance. Si parte del consumo entra por OneLake o por el endpoint SQL sin pasar por el modelo, esas rutas necesitan su propia seguridad en OneLake. Pensar que OLS cubre todo Fabric es un error de alcance.
Error 3: ignorar el permiso Build
Quien puede crear contenido sobre un modelo tambien puede ver sus metadatos. El permiso Build habilita construir informes nuevos sobre un modelo, y con el, inspeccionar la estructura: nombres de tablas, columnas y medidas.
Esto importa para OLS porque la sola existencia de una columna sensible puede ser informacion. Si otorgas Build de forma amplia, expandes quien puede explorar el modelo y potencialmente inferir que datos existen. El permiso Build debe gobernarse, no repartirse por comodidad.
Error 4: no considerar la identidad efectiva en Direct Lake
En Direct Lake, como se resuelve la identidad cambia como se valida el acceso. La eleccion entre inicio de sesion unico (SSO) e identidad fija determina con que identidad se consultan los datos subyacentes, y por lo tanto que reglas de seguridad se aplican.
Si configuras el modelo con una identidad fija, todas las consultas pueden resolverse con los permisos de esa identidad y no con los del usuario final. Eso puede saltarse las expectativas de OLS y RLS si no se disena con cuidado. La identidad efectiva en Direct Lake es parte del diseno de seguridad, no un detalle de conexion.
Como probar OLS bien antes de publicar
El antidoto a todos estos errores es el mismo: probar los permisos antes de publicar. No se valida la teoria, se valida cada ruta real de consumo con la identidad real del usuario.
Una lista minima de verificacion:
- Prueba el informe con la identidad del usuario restringido, no con la tuya de administrador.
- Conecta el modelo desde Excel e intenta traer las columnas y tablas protegidas.
- Consulta el endpoint SQL directamente y confirma que la restriccion se sostiene.
- Revisa el acceso en OneLake para las rutas que no pasan por el modelo.
- Verifica quien tiene permiso Build y si eso expone metadatos sensibles.
- Comprueba la identidad efectiva del modelo en Direct Lake (SSO o identidad fija).
Esta disciplina se apoya en tres buenas practicas para la seguridad a nivel de objeto (OLS) que sostienen el gobierno en el tiempo: nombres con convenciones claras para workspaces, modelos e informes; linaje que muestra que fuente alimenta cada tabla y modelo; y un proceso de cambio que define quien pide, quien valida, como se prueba y como se publica cada modificacion. Sin linaje, cada cambio en el modelo es un riesgo de abrir un hueco de seguridad sin darse cuenta.
El principio de fondo
La seguridad se disena por rutas de acceso, no solo por informe. OLS es una herramienta valiosa dentro del modelo semantico, pero solo protege lo que pasa por el. La IA y las herramientas nuevas no arreglan un modelo mal asegurado, lo amplifican: un agente que consulta datos mal protegidos los expone mas rapido y a mas gente.
Proteger bien un modelo semantico y sus rutas de acceso es una de las decisiones de gobierno que mas evita sorpresas caras. Empieza por lo mas simple y mas olvidado: prueba cada ruta antes de publicar. Es gratis y evita casi todos los errores de esta lista.
Y si quieres ver como se disenan y auditan estas rutas de acceso sobre un caso real de Power BI y Fabric, mira la demo gratuita.
Preguntas relacionadas
¿La seguridad a nivel de objeto (OLS) protege los datos en Excel y en el endpoint SQL?
Solo si esas rutas de consumo pasan por el modelo semantico donde vive OLS. Si un usuario consulta el endpoint SQL del lakehouse o lee las tablas en OneLake sin pasar por el modelo, OLS no aplica; esas rutas necesitan seguridad de OneLake. Por eso se prueba cada ruta antes de publicar.
¿Cual es la diferencia entre RLS y OLS?
La seguridad a nivel de fila (RLS) filtra que filas ve un usuario dentro de una tabla. La seguridad a nivel de objeto (OLS) controla si el usuario puede ver, o siquiera saber que existen, ciertas columnas y tablas. Ambas viven dentro del modelo semantico y protegen el consumo que se canaliza por el.
¿Por que ocultar una columna en el informe no es suficiente?
Ocultar una columna en el informe es cosmetica, no seguridad. Si el dato existe en el modelo y el usuario tiene otra ruta (Excel, endpoint SQL, OneLake, API o un agente), la vera igual. La proteccion debe aplicarse en el modelo o en la capa que todas las rutas comparten, no en la ultima pantalla.
¿Como afecta el permiso Build a la seguridad del modelo?
Quien tiene permiso Build sobre un modelo puede crear contenido nuevo y ver sus metadatos: nombres de tablas, columnas y medidas. La sola existencia de una columna sensible puede ser informacion, asi que el permiso Build debe gobernarse y no repartirse de forma amplia.
¿Que tiene que ver la identidad efectiva en Direct Lake con OLS?
En Direct Lake, la eleccion entre inicio de sesion unico (SSO) e identidad fija determina con que identidad se consultan los datos subyacentes. Una identidad fija puede resolver las consultas con sus propios permisos en lugar de los del usuario final, lo que puede saltarse las expectativas de OLS y RLS si no se disena con cuidado.