El error más común es asumir que una restricción configurada en el informe protege todos los caminos por los que se pueden consultar los datos. La seguridad se diseña por rutas de acceso, no por informe. En Microsoft Fabric un mismo dato se puede leer desde el informe, el modelo semántico, el lakehouse, el endpoint SQL, Excel, una API o un agente de IA, y cada ruta se valida distinto. Por eso la regla práctica es probar los permisos antes de publicar, no confiar en una sola capa.
La seguridad por roles suena simple: defines quién ve qué y publicas. En la práctica, la mayoría de las brechas no aparecen porque alguien rompió la regla, sino porque la regla solo cubría uno de los muchos caminos hacia el mismo dato. Este artículo recorre los errores más frecuentes que vemos en equipos de negocio que trabajan sobre el ecosistema Microsoft, y cómo pensarlos con criterio antes que herramienta.
¿Por qué la seguridad no se diseña por informe?
El primer error conceptual es tratar el informe como la frontera de seguridad. Un informe es solo una de las salidas del sistema. En Fabric, un mismo usuario puede interactuar con informes, modelos semánticos, lakehouses, endpoints SQL, Excel, APIs o agentes de IA. Si limitas lo que se ve en el informe pero el usuario tiene acceso al modelo o al lakehouse por debajo, puede consultar los datos por otra puerta.
Por eso el control debe pensarse en cinco dimensiones al mismo tiempo:
- Identidad: quién es el usuario y cómo se autentica.
- Rol: qué capacidades de colaboración tiene en el área de trabajo.
- Elemento: a qué artefactos concretos accede (informes, modelos, lakehouses).
- Dato: qué filas y columnas puede leer dentro de cada elemento.
- Experiencia: por qué herramienta llega (Power BI, Excel, una API, un agente).
Cuando falta una de estas dimensiones, aparece la filtración. El escenario de seguridad de Fabric organiza la identidad y la protección de extremo a extremo justamente para no dejar rutas sin cubrir.
¿Cuáles son los errores más comunes al configurar roles?
Estos son los tropiezos que se repiten en equipos que recién ordenan su gobierno de datos:
- Confundir roles de área de trabajo con permisos de dato. Los roles de área de trabajo (workspace roles) definen capacidades de colaboración, como editar o publicar. No son suficientes por sí solos para controlar qué filas ve cada persona. Son una capa, no toda la seguridad.
- Aplicar RLS solo en el modelo y olvidar el lakehouse. La seguridad semántica de filas (RLS) y la seguridad a nivel de objeto (OLS) protegen dentro del modelo semántico, y son útiles cuando el consumo se canaliza por ese modelo. Pero si el usuario llega al lakehouse o al endpoint SQL por fuera, el RLS del modelo no lo alcanza.
- Ignorar el permiso Build. Quien puede crear contenido sobre un modelo (permiso Build) también puede ver sus metadatos. Ese permiso debe gobernarse de forma explícita, no dejarse por defecto.
- No considerar la identidad efectiva en Direct Lake. El modo de identidad, single sign-on o identidad fija, cambia cómo se valida el acceso. En Direct Lake la identidad efectiva determina qué datos se resuelven, y una mala configuración expone o bloquea de forma inesperada.
- Asumir que el informe protege todo. El error raíz: creer que restringir el informe cierra todas las rutas. No las cierra.
¿Qué protege cada capa de seguridad?
Cada mecanismo cubre un tramo distinto del recorrido del dato. Verlos juntos ayuda a decidir cuáles combinar:
| Capa | Qué controla | Cuándo es suficiente |
|---|---|---|
| Workspace roles | Capacidades de colaboración (editar, publicar) | Nunca por sí sola para datos sensibles |
| Item permissions | Acceso a informes, modelos y artefactos concretos | Cuando el consumo es solo por esos elementos |
| OneLake security | Seguridad granular en tablas, filas y columnas entre motores | Cuando hay acceso directo al almacenamiento |
| Semantic RLS y OLS | Filas y columnas dentro del modelo semántico | Cuando todo el consumo pasa por el modelo |
| Identidad (SSO o fija) | Cómo se valida el acceso en Direct Lake | Base transversal, siempre relevante |
Conviene además revisar cómo se declaran los permisos de datos en las aplicaciones de Fabric, porque ese contrato define qué puede leer cada consumidor fuera del informe; la referencia de permisos de datos detalla ese comportamiento. La lección de la tabla es que ninguna fila protege sola. La seguridad real surge de combinar capas según por dónde puede llegar el usuario. El modelo de control de acceso a datos de OneLake muestra cómo aplicar seguridad granular cuando el acceso al almacenamiento existe por debajo del informe.
¿Cómo influye la identidad en Direct Lake?
Direct Lake merece atención propia porque su seguridad depende de la identidad efectiva. Según se configure el modelo con single sign-on o con una identidad fija, la validación del acceso cambia: en un caso se evalúa contra la identidad del usuario que consulta, en el otro contra una identidad de servicio. Un equipo que copia una configuración de otro modelo sin revisar este punto puede terminar mostrando datos que debían quedar ocultos, o bloqueando a usuarios legítimos.
La recomendación de Microsoft es entender cómo se integra la seguridad de Direct Lake con las capas del modelo antes de publicar. La integración de seguridad de Direct Lake detalla cómo la identidad efectiva se combina con RLS y con la seguridad de OneLake para resolver qué se ve.
¿Cómo probar los permisos antes de publicar?
La regla práctica de Acadevor es simple de enunciar y disciplinada de cumplir: 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. En concreto, antes de dar acceso conviene:
- Listar todas las rutas de consumo del dato: informe, modelo, lakehouse, endpoint SQL, Excel, API y agentes.
- Probar cada ruta con un usuario de prueba que tenga el rol real que tendrá en producción, no con la cuenta de administrador.
- Verificar que el permiso Build esté gobernado y no abierto por defecto.
- Confirmar el modo de identidad en modelos Direct Lake antes de exponerlos.
- Reconciliar lo que ve el usuario de prueba con lo que la política de negocio dice que debería ver.
Este hábito conecta con el resto del gobierno de datos, porque para gobernar quién ve cada dato en la empresa hacen falta convenciones de nombres claras, linaje que documente qué fuente alimenta cada tabla y modelo, controles de calidad y un proceso de cambio donde quede claro quién pide, quién valida, cómo se prueba y cómo se publica una modificación. Sin linaje, cada cambio de permisos es un riesgo a ciegas.
¿Por dónde empezar a ordenar la seguridad?
Si tu equipo recién está mapeando quién ve qué, el punto de partida no es una herramienta sino el criterio: pensar la seguridad por rutas de acceso y probar cada una antes de publicar. Ese cambio de mirada evita la mayoría de las filtraciones, porque deja de confiar en una sola capa.
Si quieres ver cómo se aplica esta disciplina de seguridad por rutas sobre Power BI y Fabric en un caso real, del modelo semántico hasta la publicación segura, mira la demo gratuita.
Preguntas relacionadas
¿Restringir un informe es suficiente para proteger los datos?
No. Un informe es solo una de las salidas del sistema. El mismo dato se puede consultar desde el modelo semántico, el lakehouse, el endpoint SQL, Excel, una API o un agente. Si esas rutas no están protegidas, el usuario accede por otra puerta aunque el informe esté restringido.
¿Qué diferencia hay entre los roles de área de trabajo y el RLS?
Los roles de área de trabajo definen capacidades de colaboración, como editar o publicar contenido. El RLS (seguridad de filas) controla qué filas ve cada usuario dentro del modelo semántico. Son capas distintas: los roles de área de trabajo no bastan por sí solos para proteger datos sensibles.
¿Por qué importa el permiso Build en la seguridad?
Porque quien tiene permiso Build sobre un modelo también puede ver sus metadatos y crear contenido nuevo sobre él. Si ese permiso queda abierto por defecto, se convierte en una ruta de acceso no controlada. Debe gobernarse de forma explícita.
¿Cómo afecta la identidad al acceso en Direct Lake?
En Direct Lake la identidad efectiva determina cómo se valida el acceso. Según se use single sign-on o una identidad fija, la consulta se evalúa contra el usuario o contra una identidad de servicio. Copiar una configuración sin revisar este punto puede exponer o bloquear datos de forma inesperada.
¿Cuál es la regla práctica para no dejar rutas sin proteger?
Probar los permisos antes de publicar. Se listan todas las rutas de consumo del dato, se prueba cada una con un usuario que tenga el rol real de producción y se reconcilia lo que ve con lo que la política de negocio permite. No se asume que una sola capa protege todos los caminos.