Dar acceso a datos sin comprometer la seguridad significa diseñar la protección por cada ruta de acceso, no solo por informe. En Microsoft Fabric un mismo dato se consulta desde informes, modelos, lakehouses, endpoints SQL, Excel, APIs y agentes, así que el control se piensa por identidad, rol, elemento, dato y experiencia. La regla base: probar los permisos antes de publicar, porque restringir el informe no protege todos los caminos.
Por qué la seguridad se diseña por ruta y no por informe
El error más común es pensar que ocultar una visualización o filtrar un informe ya protege el dato. No es así. En una plataforma moderna como Microsoft Fabric, un mismo conjunto de datos puede consultarse por muchos caminos distintos: un informe de Power BI, el modelo semántico que lo alimenta, el lakehouse donde vive la tabla, un endpoint SQL, una conexión desde Excel, una API o incluso un agente de IA.
Cada uno de esos caminos es una ruta de acceso. Si aseguras el informe pero dejas abierto el endpoint SQL o la conexión a Excel, el dato sigue expuesto. Por eso el control debe pensarse en cinco dimensiones: identidad (quién es el usuario), rol (qué puede hacer al colaborar), elemento (a qué artefacto llega), dato (qué filas y columnas ve) y experiencia (por dónde consume).
Las capas de control en Microsoft Fabric
Fabric ofrece varias capas que se combinan. Ninguna resuelve todo por sí sola; se apilan según el escenario.
- Workspace roles. Definen las capacidades de colaboración dentro de un área de trabajo. Son la base, pero no bastan por sí solos para todos los escenarios de consumo.
- Item permissions. Controlan el acceso a artefactos concretos: informes, modelos y otros elementos. Sirven para dar acceso puntual sin abrir todo el workspace.
- OneLake security. Permite aplicar seguridad granular sobre tablas, filas y columnas, y esa protección se respeta a través de los distintos motores que leen el dato, según el modelo de control de acceso de OneLake.
- RLS y OLS del modelo semántico. La seguridad a nivel de fila (RLS) y a nivel de objeto (OLS) protege dentro del modelo. Es útil cuando el consumo se canaliza a través del modelo semántico, y conviene seguir buenas prácticas de seguridad a nivel de objeto (OLS) para no dejar columnas expuestas al ocultarlas.
- 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 o una identidad fija. Ese detalle decide qué permisos se evalúan realmente.
Cómo elegir la capa correcta según la ruta
La capa que protege depende de por dónde consume el usuario. Esta tabla resume cuándo aplica cada control.
| Capa de control | Qué protege | Cuándo usarla |
|---|---|---|
| Workspace roles | Colaboración en el área de trabajo | Definir quién crea, edita o solo ve dentro del workspace |
| Item permissions | Artefactos concretos | Compartir un informe o modelo sin abrir todo el workspace |
| OneLake security | Tablas, filas y columnas en el lago | Proteger el dato aunque se lea por SQL, Spark u otro motor |
| RLS y OLS | Filas y objetos dentro del modelo | Cuando el consumo pasa siempre por el modelo semántico |
| SSO o identidad fija | Identidad efectiva en Direct Lake | Definir con qué identidad se valida el acceso al leer |
La clave: si un dato se consulta por más de una ruta, necesitas más de una capa. Filtrar solo en el modelo no protege a quien entra por el endpoint SQL del lakehouse.
El permiso Build: un riesgo silencioso
Hay un permiso que suele pasar desapercibido y conviene gobernar con cuidado: Build permission. Quien puede crear contenido sobre un modelo también puede ver sus metadatos. Es decir, otorgar la capacidad de construir informes o consultas sobre un modelo abre la puerta a inspeccionar cómo está estructurado.
Eso no es malo en sí mismo, pero debe ser una decisión consciente. Otorgar Build sin criterio equivale a exponer la anatomía del modelo a más gente de la necesaria. Gobierna ese permiso igual que gobiernas el acceso al dato: con nombre, con justificación y con revisión.
La regla práctica: probar antes de publicar
El principio operativo que sostiene todo lo anterior es simple de enunciar y fácil de saltarse: prueba los permisos antes de publicar. No asumas que una restricción en el informe protege todos los caminos por los que puede consultarse el dato.
Una prueba de acceso mínima debería recorrer estos pasos:
- Identificar todas las rutas por las que el dato es consultable (informe, modelo, endpoint SQL, Excel, API, agente).
- Iniciar sesión con la identidad de cada perfil de usuario real, no con la del administrador.
- Intentar acceder al dato sensible por cada ruta, no solo por el informe.
- Verificar que RLS, OLS y OneLake security devuelven exactamente lo que ese perfil debe ver.
- Confirmar cómo se resuelve la identidad efectiva en Direct Lake (SSO o identidad fija).
Si una sola de esas rutas devuelve más de lo debido, el acceso no está listo para publicarse.
Seguridad y gobierno son la misma conversación
Dar acceso seguro no vive aislado del resto del gobierno de datos, que en el fondo consiste en gobernar quién ve qué dato en la empresa. Se apoya en cuatro prácticas que lo mantienen operativo a lo largo del tiempo:
- Nombres. Convenciones claras para workspaces, lakehouses, pipelines, modelos, informes y medidas. Sin nombres consistentes, nadie sabe qué está protegiendo.
- Linaje. Saber qué fuente alimenta cada tabla, modelo e informe. Sin linaje, cada cambio de permisos es un riesgo a ciegas.
- Calidad. Controles de duplicados, nulos, rango, consistencia temporal y reconciliación. Un dato mal validado se filtra mal.
- Cambio. Un proceso definido de quién pide, quién valida, cómo se prueba y cómo se publica cada modificación de acceso.
La documentación de gobierno y cumplimiento de Fabric organiza estos controles en un mismo marco. Estas prácticas convierten la seguridad en algo mantenible en el tiempo, no en un candado que alguien puso una vez y nadie volvió a revisar.
Cómo avanzar desde aquí
Diseñar el acceso por rutas exige criterio antes que herramienta: entender el negocio, el modelo semántico que define cómo se calculan las métricas y las capas que Fabric pone a disposición. Ese criterio se construye con formación del equipo o con una mirada externa que evalúe cómo están hoy tus fuentes, tu integración y tu seguridad. Si quieres ver cómo abordamos ambos caminos y decidir cuál encaja con tu organización, mira la demo gratuita.
Preguntas relacionadas
¿Restringir un informe protege todo el acceso al dato?
No. Un mismo dato se consulta por muchas rutas: modelo, lakehouse, endpoint SQL, Excel, API o agente. Filtrar el informe no cierra esos otros caminos. La seguridad se diseña por ruta de acceso, no solo por informe.
¿Qué capas de seguridad ofrece Microsoft Fabric?
Workspace roles para colaboración, item permissions para artefactos concretos, OneLake security para tablas, filas y columnas, y RLS y OLS dentro del modelo semántico. Se combinan según por dónde consuma el usuario; ninguna basta por sí sola.
¿Por qué importa el permiso Build?
Porque quien puede crear contenido sobre un modelo también puede ver sus metadatos. Otorgar Build sin criterio expone la estructura del modelo a más personas de las necesarias, así que debe gobernarse con nombre, justificación y revisión.
¿Cómo afecta la identidad en Direct Lake al acceso?
En Direct Lake la identidad efectiva con la que se valida el acceso cambia según se use inicio de sesión único o una identidad fija. Ese detalle define qué permisos se evalúan al leer, así que debe probarse antes de publicar.
¿Qué significa probar los permisos antes de publicar?
Significa iniciar sesión con la identidad de cada perfil real e intentar llegar al dato sensible por cada ruta posible, no solo por el informe, verificando que RLS, OLS y OneLake security devuelven exactamente lo que ese perfil debe ver.