Gobernar quién ve qué dato exige diseñar la seguridad por rutas de acceso, no solo por informe. Un mismo usuario puede llegar al dato desde un informe, un modelo semántico, un lakehouse, un endpoint SQL, Excel, una API o un agente de IA. Por eso el control se define por identidad, rol, elemento, dato y experiencia, y cada ruta se prueba antes de publicar.
¿Por qué restringir el informe no alcanza?
Es un error común pensar que si un informe oculta ciertas cifras, esas cifras quedan protegidas. En una plataforma moderna como Microsoft Fabric, el informe es solo una de las muchas puertas hacia el mismo dato. La misma persona puede interactuar con informes, modelos semánticos, lakehouses, endpoints SQL, Excel, APIs o agentes de IA.
Si una regla vive únicamente en la capa del informe, cualquier otra ruta queda abierta. Alguien con permiso para conectarse al modelo desde Excel, o para consultar el endpoint SQL, puede recuperar lo que el informe escondía. La seguridad seria se piensa extremo a extremo: por identidad, rol, elemento, dato y experiencia de consumo, como plantea el escenario de seguridad de Microsoft Fabric.
¿Cuáles son las capas de control disponibles?
En Fabric conviven varias capas de seguridad, y cada una resuelve un problema distinto. No son intercambiables: se combinan según por dónde consuma el usuario.
- Workspace roles. Definen las capacidades de colaboración dentro de un área de trabajo. Son necesarios, pero no suficientes por sí solos para todos los escenarios.
- Item permissions. Controlan el acceso a artefactos concretos: informes, modelos y otros elementos.
- OneLake security. Permite aplicar seguridad granular a nivel de tablas, filas y columnas, y esa restricción viaja a través de los distintos motores que leen el dato, según el modelo de control de acceso a datos en OneLake.
- Semantic RLS y OLS. La seguridad a nivel de fila (RLS) y a nivel de objeto (OLS) protege dentro del modelo semántico. Es útil cuando el consumo se canaliza siempre por el modelo, y conviene seguir buenas prácticas para la seguridad a nivel de objeto (OLS) en Fabric para que no se filtre estructura ni datos sensibles.
- SSO o identidad fija. En Direct Lake, la identidad efectiva con la que se valida el acceso cambia según se use inicio de sesión único (SSO) o una identidad fija. Ese detalle altera qué ve realmente cada persona.
¿Cómo se relacionan estas capas entre sí?
La pregunta correcta no es cuál capa usar, sino por cuáles rutas llega el dato al usuario y qué capa cubre cada una. Esta tabla resume el criterio.
| Capa de control | Qué protege | Cuándo aplicarla |
|---|---|---|
| Workspace roles | Colaboración dentro del área de trabajo | Siempre, como base de quién edita o ve |
| Item permissions | Artefactos concretos (informe, modelo) | Cuando el acceso se otorga pieza por pieza |
| OneLake security | Tablas, filas y columnas en el lago | Cuando el dato se consume por varios motores |
| Semantic RLS y OLS | Filas y objetos dentro del modelo | Cuando todo el consumo pasa por el modelo semántico |
| SSO o identidad fija | Identidad efectiva en Direct Lake | Al definir cómo se valida el acceso en Direct Lake |
Un dato consumido solo por el modelo semántico se protege bien con RLS y OLS. El mismo dato expuesto también por el endpoint SQL o por Excel necesita, además, seguridad en OneLake para que la restricción viaje por cada motor.
¿Qué es el permiso de build y por qué gobernarlo?
Hay un permiso que suele pasar inadvertido: el de build sobre un modelo semántico. Quien puede crear contenido nuevo sobre un modelo también puede ver sus metadatos. Es decir, la estructura del modelo, sus tablas, medidas y relaciones, quedan a la vista de quien tenga ese permiso.
Por eso el permiso de build no se reparte por costumbre. Se gobierna igual que cualquier otro acceso al dato, porque abre una ventana a información que quizás quisieras reservar. Concederlo con criterio evita filtraciones silenciosas de estructura y lógica de negocio.
¿Cómo se prueba que los permisos realmente funcionan?
La regla práctica es simple: los permisos se prueban antes de publicar. No se asume que una restricción en el informe protege todos los caminos por los que pueden consultarse los datos. Este es el punto donde se decide cómo dar acceso a datos sin comprometer la seguridad: abrir cada ruta de consumo solo a quien corresponde y verificarlo.
Probar significa recorrer cada ruta con la identidad de un usuario real y confirmar qué ve y qué no:
- Identifica todas las rutas de consumo del dato: informe, modelo, endpoint SQL, Excel, API, agente.
- Define qué debería ver cada rol en cada ruta.
- Suplanta o valida con un usuario de prueba de ese rol.
- Recorre cada ruta y compara lo observado contra lo esperado.
- Corrige la capa que corresponda y vuelve a probar antes de publicar.
Este recorrido convierte la seguridad de una suposición en una verificación. Es el mismo criterio que sostiene el linaje, la calidad y la gestión de cambios: saber qué fuente alimenta cada tabla, modelo e informe, y quién pide, valida, prueba y publica cada modificación.
¿Dónde encaja esto en una fuente de datos confiable?
Gobernar el acceso no es un obstáculo para tener una sola fuente de datos confiable, es parte de ella. El modelo semántico funciona como la referencia compartida de las métricas del negocio, y esa referencia incluye quién puede ver qué. Cuando la seguridad se diseña por rutas, dirección y equipo pueden compartir los mismos números sin exponer lo que cada rol no debe ver.
Un agente o Copilot que consulta un modelo con permisos mal diseñados expone por conversación lo que un informe ocultaba por pantalla. Ordenar primero las rutas de acceso es lo que hace segura la capa de IA que viene después, y encaja con el marco de gobierno y cumplimiento de Fabric.
¿Cómo ver este diseño aplicado?
Si quieres ver cómo se diseña esta seguridad por rutas sobre un caso real, con modelo semántico, permisos y verificación incluidos, mira la demo gratuita. Es la forma más directa de evaluar si este enfoque encaja con la situación actual de tu empresa.
Preguntas relacionadas
¿Restringir un informe protege el dato en toda la empresa?
No. El informe es solo una de las rutas hacia el dato. La misma persona puede llegar desde el modelo semántico, el endpoint SQL, Excel, una API o un agente de IA. Si la regla vive solo en el informe, las demás rutas quedan abiertas. La seguridad se diseña por identidad, rol, elemento, dato y experiencia.
¿Qué diferencia hay entre RLS del modelo y OneLake security?
La seguridad a nivel de fila (RLS) y de objeto (OLS) protege dentro del modelo semántico, útil cuando todo el consumo pasa por el modelo. OneLake security aplica seguridad a tablas, filas y columnas en el lago, y esa restricción viaja a través de los distintos motores, incluso cuando el dato se consulta fuera del modelo.
¿Por qué hay que gobernar el permiso de build?
Porque quien puede crear contenido sobre un modelo semántico también puede ver sus metadatos: tablas, medidas y relaciones. Ese permiso abre una ventana a la estructura y la lógica de negocio, así que debe concederse con criterio y no por costumbre.
¿Cómo pruebo que los permisos funcionan antes de publicar?
Recorre cada ruta de consumo (informe, modelo, endpoint SQL, Excel, API, agente) con la identidad de un usuario real de cada rol, compara lo que ve contra lo esperado, corrige la capa que corresponda y vuelve a probar. Nunca asumas que una restricción en el informe cubre todos los caminos.
¿Cómo cambia la identidad efectiva en Direct Lake?
En Direct Lake, usar inicio de sesión único (SSO) o una identidad fija cambia con qué identidad se valida el acceso. Eso altera qué ve realmente cada persona, por lo que cada configuración debe probarse por separado antes de publicar.