La seguridad a nivel de objeto (OLS) restringe el acceso a tablas y columnas completas dentro de un modelo semántico, según el rol del usuario. Su buena práctica central es diseñarla por ruta de acceso, no solo por informe: se define en el modelo, se combina con seguridad a nivel de fila (RLS) cuando hace falta filtrar valores, y se prueba antes de publicar, porque un dato puede consultarse por varios caminos (informe, Excel, endpoint SQL, API o un agente).
¿Qué protege exactamente OLS y en qué se diferencia de RLS?
La seguridad a nivel de objeto y la seguridad a nivel de fila resuelven problemas distintos y muchos equipos las confunden. OLS oculta objetos completos: una tabla entera o una columna concreta desaparecen para quien no tiene permiso, como si no existieran en el modelo. RLS, en cambio, deja la tabla visible pero filtra qué filas puede ver cada usuario.
Un ejemplo de negocio deja claro el criterio. Si la columna Salario no debe verla el equipo comercial, eso es OLS: la columna se oculta. Si cada gerente solo debe ver las ventas de su propia región, eso es RLS: la tabla de ventas se ve, pero filtrada. En la práctica se combinan, porque el gobierno real de un modelo mezcla objetos sensibles con filtros por identidad.
| Aspecto | OLS (nivel de objeto) | RLS (nivel de fila) |
|---|---|---|
| Qué controla | Tablas y columnas completas | Filas dentro de una tabla |
| Efecto para el usuario | El objeto no existe | El objeto se ve, filtrado |
| Caso típico | Ocultar Salario, Margen, Costo | Ver solo tu región o tu cliente |
| Dónde vive | En el modelo semántico | En el modelo semántico |
Ambas viven dentro del modelo semántico, que concentra las definiciones de métricas que todo el negocio comparte. Por eso protegen bien cuando el consumo se canaliza por ese modelo, y hay que revisar qué pasa cuando no.
¿Por qué la seguridad se diseña por ruta de acceso y no solo por informe?
En Microsoft Fabric un mismo usuario puede llegar al dato por muchos caminos: un informe de Power BI, un modelo semántico consultado desde Excel, un lakehouse, un endpoint SQL, una API o un agente de datos. Restringir una visual en un informe no protege los demás caminos. El dato sigue ahí y puede consultarse por otra puerta.
De ahí la regla práctica: el control debe pensarse por identidad, rol, elemento, dato y experiencia, no solo por el informe final. En el fondo, este es el problema de gobernar quién ve qué dato en la empresa: decidir el acceso por identidad y por ruta, no por la pantalla que el usuario tiene delante. Cada capa de Fabric aporta un tipo de control distinto y conviene entender cuál resuelve qué.
- Roles de workspace: definen capacidades de colaboración. Son necesarios, pero por sí solos no cubren todos los escenarios de protección del dato.
- Permisos de elemento (item permissions): controlan el acceso a informes, modelos y artefactos concretos.
- [Seguridad de OneLake](https://learn.microsoft.com/en-us/fabric/onelake/security/data-access-control-model): aplica control granular sobre tablas, filas y columnas a través de los distintos motores que leen el lago.
- RLS y OLS del modelo semántico: protegen dentro del modelo, útiles cuando el consumo pasa por el modelo semántico.
- Identidad efectiva (SSO o identidad fija): cambia cómo se valida el acceso, algo especialmente relevante en Direct Lake.
El escenario de seguridad de Fabric organiza justamente esta protección de extremo a extremo, desde la identidad hasta el dato. Pensar la seguridad por rutas evita el error clásico de creer que una restricción visible protege todo.
¿Cómo diseñar OLS sin romper el modelo?
Ocultar un objeto tiene efectos secundarios que conviene anticipar. Si una medida o una relación dependen de una columna que OLS oculta para cierto rol, ese rol puede encontrarse con cálculos que fallan o informes que no cargan. Diseñar OLS es tanto decidir qué se oculta como cuidar de qué depende lo oculto. Si aún no la configuraste, conviene repasar cómo implementar la seguridad a nivel de objeto paso a paso antes de aplicar estas buenas prácticas.
Algunas buenas prácticas concretas para el diseño:
- Parte del catálogo de objetos sensibles. Antes de tocar el modelo, lista qué tablas y columnas son confidenciales y para qué roles. El diseño de seguridad empieza en el negocio, no en la herramienta.
- Define roles claros y pocos. Menos roles bien definidos son más fáciles de gobernar y probar que decenas de excepciones difíciles de rastrear.
- Revisa dependencias de las medidas. Comprueba que ninguna medida visible dependa en silencio de una columna que vas a ocultar, o ese rol verá errores.
- Cuida el linaje. Documenta qué fuente alimenta cada tabla, modelo e informe. Sin linaje, cada cambio de seguridad es un riesgo, porque no sabes a qué afecta.
- Aplica convenciones de nombres. Nombres consistentes para workspaces, lakehouses, modelos, informes y medidas hacen que las reglas de acceso sean legibles y auditables.
Este orden refleja el principio de criterio antes que herramienta: primero se ordenan las métricas y las decisiones, y solo después se configuran los controles. Las herramientas no compensan un diseño débil de seguridad; lo vuelven más evidente.
¿Qué papel juegan Direct Lake y el permiso Build?
Dos elementos se pasan por alto con frecuencia y ambos pueden abrir accesos no previstos.
El primero es la identidad efectiva en Direct Lake. Según se use inicio de sesión único (SSO) o una identidad fija, cambia con qué credenciales se valida el acceso al dato subyacente. La seguridad de Direct Lake muestra por qué cada ruta debe probarse: una configuración de identidad distinta puede exponer o restringir datos de forma diferente a la esperada, y no basta con asumir que el modelo protege siempre.
El segundo es el permiso Build. Quien puede crear contenido sobre un modelo también puede ver sus metadatos. Ese permiso da capacidad de construir encima del modelo, y por eso debe gobernarse de forma explícita: no es un detalle menor de colaboración, es una puerta al modelo que conviene controlar junto con OLS y RLS.
Ambos casos refuerzan la misma idea. La restricción que ves en la superficie no garantiza la protección en todas las capas por debajo. La seguridad de OneLake y la de Direct Lake existen precisamente porque cada motor y cada ruta pueden validar el acceso de manera distinta.
¿Por qué probar los permisos antes de publicar es innegociable?
La buena práctica que sostiene a todas las anteriores es sencilla de enunciar y fácil de saltarse: probamos los permisos antes de publicar. No asumimos que una restricción en el informe protege todos los caminos por los que pueden consultarse los datos.
Probar significa recorrer cada ruta de acceso con la identidad de cada rol y confirmar qué ve y qué no. Un checklist mínimo antes de publicar:
- Ver el modelo como cada rol y confirmar que los objetos sensibles están ocultos.
- Abrir el modelo desde Excel y desde el endpoint SQL, no solo desde el informe.
- Verificar que las medidas visibles funcionan para roles con columnas ocultas.
- Revisar quién tiene permiso Build sobre el modelo.
- Confirmar la identidad efectiva configurada en modelos Direct Lake.
El marco de gobierno y cumplimiento de Fabric ubica estas comprobaciones dentro de una práctica de gobierno más amplia. Esta disciplina forma parte del control de cambios: quién pide una modificación, quién la valida, cómo se prueba y cómo se publica. Un modelo semántico es un sistema vivo, y su seguridad se mantiene con pruebas repetibles, no con una configuración que se hizo una vez y nadie volvió a revisar.
Cómo encaja OLS en el gobierno del modelo
La seguridad a nivel de objeto es una pieza dentro de un diseño más amplio de gobierno de datos: linaje, calidad, nombres y control de cambios trabajando juntos sobre definiciones compartidas. Si quieres ver cómo se aplican estas prácticas sobre un modelo real, con roles, rutas de acceso y pruebas antes de publicar, mira la demo gratuita y evalúa cómo trasladarlas a tu propio entorno.
Preguntas relacionadas
¿Qué es la seguridad a nivel de objeto (OLS) en Power BI y Fabric?
Es un control que oculta tablas o columnas completas dentro de un modelo semántico según el rol del usuario. Para quien no tiene permiso, el objeto no existe. Se usa, por ejemplo, para ocultar columnas sensibles como salario o margen a ciertos roles.
¿En qué se diferencia OLS de la seguridad a nivel de fila (RLS)?
OLS oculta objetos completos (tablas y columnas), mientras que RLS deja la tabla visible pero filtra qué filas ve cada usuario. OLS sirve para esconder una columna como costo; RLS, para que cada gerente vea solo su región. Suelen combinarse en el mismo modelo.
¿Por qué no basta con restringir el informe?
Porque en Fabric el mismo dato puede consultarse por varias rutas: informe, Excel, endpoint SQL, lakehouse, API o un agente. Una restricción en una visual del informe no protege esos otros caminos. Por eso la seguridad se diseña por ruta de acceso, en el modelo y en OneLake, no solo en el informe.
¿Qué hay que revisar en Direct Lake y en el permiso Build?
En Direct Lake, la identidad efectiva (SSO o identidad fija) cambia cómo se valida el acceso al dato, así que cada ruta debe probarse. El permiso Build permite crear contenido sobre el modelo y ver sus metadatos, por lo que debe gobernarse de forma explícita junto con OLS y RLS.
¿Cómo se prueban los permisos antes de publicar?
Se recorre cada ruta con la identidad de cada rol: ver el modelo como ese rol, abrirlo desde Excel y desde el endpoint SQL, confirmar que los objetos sensibles están ocultos y que las medidas visibles siguen funcionando. También conviene revisar quién tiene permiso Build y la identidad efectiva en Direct Lake.