Seguridad a nivel de objeto (OLS) en Power BI: guía paso a paso | Acadevor
·8 min de lectura
Cómo implementar la seguridad a nivel de objeto (OLS) paso a paso
Aprende a implementar la seguridad a nivel de objeto (OLS) en el modelo semántico de Power BI y Fabric, y a probar cada ruta de acceso antes de publicar.
La seguridad a nivel de objeto (OLS) oculta tablas y columnas completas dentro del modelo semántico según el rol de cada usuario. Se implementa definiendo roles, marcando qué objetos son inaccesibles para cada rol y asignando usuarios a esos roles. El paso que no se salta: probar los permisos antes de publicar, porque un dato puede consultarse por varias rutas y una restricción en el informe no protege todas.
Qué es OLS y en qué se diferencia de RLS
OLS (Object-Level Security) y RLS (Row-Level Security) protegen datos dentro del modelo semántico, pero actúan sobre planos distintos. RLS filtra filas: un vendedor ve solo las filas de su región. OLS oculta objetos enteros: una tabla de sueldos o una columna de margen desaparecen por completo para quien no tiene el rol adecuado. Cuando un objeto está protegido con OLS, el usuario no ve la columna, no puede escribir medidas sobre ella y las visualizaciones que la usaban dejan de resolver.
Ambas técnicas comparten un supuesto importante: protegen dentro del modelo, y son útiles cuando el consumo se canaliza por el modelo semántico. Si un usuario llega al dato por otra ruta (el endpoint SQL del lakehouse, el acceso directo a OneLake, una API o Excel conectado a la tabla), OLS no interviene. Por eso el diseño de seguridad se piensa por rutas de acceso, no solo por informe (escenario de seguridad de Fabric). Esta lógica es la misma con la que se decide cómo gobernar quién ve qué dato en la empresa: el control se define por la puerta de acceso, no por la pantalla.
Demo gratuita
Mira cómo construir tu sistema de datos e IA
Un recorrido práctico de principio a fin para unificar fuentes dispersas en un modelo semántico que alimenta Excel, Power BI, Copilot y tus agentes.
Por qué la seguridad se diseña por rutas de acceso
En Microsoft Fabric un mismo usuario puede interactuar con informes, modelos, lakehouses, endpoints SQL, Excel, APIs o agentes. Cada una de esas puertas valida el acceso de forma distinta, según el modelo de control de acceso a datos en OneLake. Controlar solo el informe deja abiertas las demás.
El control efectivo se piensa en cinco capas complementarias:
Workspace roles: definen capacidades de colaboración. No alcanzan por sí solos para todos los escenarios.
Item permissions: controlan el acceso a informes, modelos y artefactos concretos.
OneLake security: aplica seguridad granular en tablas, filas y columnas a través de motores.
RLS y OLS del modelo semántico: protegen dentro del modelo, cuando el consumo pasa por él.
SSO o identidad fija: la identidad efectiva cambia cómo se valida el acceso en Direct Lake.
OLS vive en la cuarta capa. Es potente para el consumo vía modelo semántico, pero forma parte de un diseño más amplio. Antes de confiar en OLS conviene mapear todas las rutas por las que ese dato puede consultarse.
Cómo se compara OLS con las otras capas
Capa
Qué protege
Cuándo conviene
Workspace roles
Colaboración sobre el workspace
Definir quién edita o solo ve contenido
Item permissions
Informes y modelos concretos
Compartir un artefacto puntual
OneLake security
Tablas, filas y columnas entre motores
Proteger el dato en la fuente, para todas las rutas
RLS
Filas del modelo semántico
Cada usuario ve su subconjunto de filas
OLS
Tablas y columnas del modelo semántico
Ocultar objetos sensibles completos
Una lectura útil de la tabla: OneLake security actúa cerca del dato y cubre varias rutas; OLS actúa en el modelo y cubre el consumo que pasa por él. En datos muy sensibles suelen combinarse, no elegirse una sola.
Los pasos para implementar OLS
El flujo práctico, del diseño a la publicación:
Inventaria los objetos sensibles. Identifica qué tablas y columnas no deben verse por defecto: remuneraciones, márgenes, datos personales, costos internos.
Define los roles. Crea roles en el modelo semántico alineados con el negocio (por ejemplo, dirección, finanzas, comercial), no con nombres de personas.
Marca los objetos inaccesibles por rol. Para cada rol, establece qué tablas o columnas quedan ocultas. Un objeto oculto no aparece ni puede referenciarse en medidas o visualizaciones.
Revisa las dependencias. Si una medida usa una columna protegida, esa medida romperá para los roles sin acceso. Ajusta el modelo para que las vistas de cada rol resuelvan sin errores.
Asigna los usuarios o grupos a los roles. Prefiere grupos de seguridad a usuarios individuales; el mantenimiento escala mejor.
Gobierna el permiso Build. Quien puede crear contenido sobre un modelo también puede ver sus metadatos. Ese permiso debe gobernarse con el mismo criterio que el resto.
Prueba cada rol y cada ruta. Valida desde la perspectiva de cada rol y también desde las otras puertas de acceso.
Publica y vuelve a validar en el entorno real, porque la identidad efectiva puede cambiar el resultado.
Por qué probar antes de publicar no es opcional
La regla práctica es simple: los permisos se prueban antes de publicar. No conviene asumir que una restricción en el informe protege todos los caminos por los que pueden consultarse los datos.
Esto importa de forma especial en Direct Lake, donde la identidad efectiva (SSO o identidad fija) cambia cómo se valida el acceso. Un modelo que parece seguro con una identidad puede exponer datos con otra. La prueba no es un formalismo: es la única forma de comprobar que la capa que diseñaste realmente cierra la puerta que crees que cierra.
Una secuencia de validación mínima:
Ver el modelo como cada rol definido y confirmar que los objetos sensibles no aparecen.
Consultar el modelo desde Excel y desde el endpoint de análisis SQL para verificar que otras rutas no eluden la protección.
Confirmar que las medidas y visualizaciones no dependientes siguen resolviendo para todos los roles.
Revisar quién tiene permiso Build sobre el modelo.
Cómo encaja OLS en un modelo bien gobernado
OLS no sustituye al gobierno del modelo, lo complementa. Un modelo semántico bien gobernado sostiene la seguridad con cuatro prácticas: nombres con convenciones claras para workspaces, lakehouses, modelos, informes y medidas; linaje que documente qué fuente alimenta cada tabla, modelo e informe; calidad con controles de duplicados, nulos, rango y consistencia; y un proceso de cambio que defina quién pide, quién valida, cómo se prueba y cómo se publica cada modificación.
Sin linaje, cada cambio en un objeto protegido es un riesgo silencioso: no sabes qué informes dependen de esa columna que acabas de ocultar. El modelo semántico funciona como el acuerdo compartido sobre cómo se calculan las métricas del negocio, y la seguridad forma parte de ese acuerdo. Una seguridad mal probada no se corrige sola al escalar el uso del modelo; al contrario, cada nuevo consumidor multiplica la exposición. Consolidar estos criterios como rutina de equipo es justamente lo que reúnen las buenas prácticas para la seguridad a nivel de objeto (OLS) en Fabric.
Cómo llevarlo a tu organización
OLS es una pieza dentro de un diseño de seguridad por rutas de acceso. Conviene empezar por revisar cómo están hoy esas rutas en tu organización: qué objetos sensibles existen, quién puede llegar a ellos y por qué puertas. Si quieres ver cómo abordamos ese diseño de seguridad y gobierno sobre el modelo semántico, con ejemplos concretos de formación y consultoría según el punto de partida de cada equipo, mira la demo gratuita.
Preguntas relacionadas
¿Qué diferencia hay entre OLS y RLS en Power BI?
RLS (seguridad a nivel de fila) filtra filas según el usuario, por ejemplo mostrar solo su región. OLS (seguridad a nivel de objeto) oculta tablas o columnas completas, de modo que el objeto ni aparece ni puede referenciarse en medidas o visualizaciones para los roles sin acceso.
¿OLS protege los datos si el usuario consulta por el endpoint SQL o por Excel?
No necesariamente. OLS protege dentro del modelo semántico, cuando el consumo pasa por él. Si el usuario llega al dato por el endpoint SQL, OneLake o Excel conectado a la tabla, esa ruta se valida por otra capa. Por eso la seguridad se diseña por rutas de acceso y cada camino debe probarse.
¿Por qué hay que probar los permisos antes de publicar?
Porque una restricción en el informe no protege todos los caminos por los que se puede consultar el dato. Además, en Direct Lake la identidad efectiva (SSO o identidad fija) cambia cómo se valida el acceso, así que un modelo que parece seguro con una identidad puede exponer datos con otra.
¿Qué pasa con las medidas que usan una columna protegida con OLS?
Si una medida depende de una columna oculta por OLS, esa medida romperá para los roles que no tienen acceso. Antes de publicar conviene revisar las dependencias y ajustar el modelo para que las vistas de cada rol resuelvan sin errores.
¿Por qué hay que gobernar el permiso Build junto con OLS?
Porque quien puede crear contenido sobre un modelo también puede ver sus metadatos. Aunque OLS oculte objetos en el consumo, un permiso Build mal asignado abre visibilidad sobre la estructura del modelo, así que debe gobernarse con el mismo criterio que el resto de las capas.
