Seguridad en Microsoft Fabric: Roles, Workspaces y Permisos sin Agujeros
Administrar la seguridad en un entorno de Business Intelligence ha dejado de ser una tarea sencilla de «dar acceso al informe». Con la llegada de Microsoft Fabric, la complejidad ha escalado. Ya no solo gestionamos quién ve un dashboard, sino quién tiene capacidad de cómputo para ejecutar un Notebook, quién puede leer datos en bruto desde OneLake y quién tiene permisos para modificar la infraestructura de datos. Si vienes de Power BI, es probable que pienses que los roles de Workspace funcionan igual, pero en Fabric, un error de configuración puede exponer no solo tus métricas, sino toda tu arquitectura de datos.
En mi trabajo diario como consultor, me encuentro constantemente con implementaciones donde se otorga el rol de Contributor a analistas que solo necesitan consultar tablas. Este es el primer gran error. En Fabric, los roles tienen implicaciones directas sobre el consumo de capacidad y la integridad del dato. Antes de entrar en la configuración técnica, debemos entender que Fabric es una solución SaaS que unifica capas de ingeniería, ciencia y visualización de datos bajo un mismo paraguas de seguridad.
Para entender el ecosistema, es fundamental que primero tengas claro 1. ¿Qué es exactamente Microsoft Fabric?, ya que la seguridad se hereda y se fragmenta según el tipo de ítem que estemos utilizando en el servicio.
El modelo de roles en Workspaces de Fabric
El primer nivel de defensa es el Workspace. A diferencia de las versiones antiguas de Power BI, en Fabric los roles determinan qué herramientas de la plataforma puede usar el usuario. No se trata solo de visualización. Los cuatro roles principales (Admin, Member, Contributor y Viewer) actúan como filtros de capacidad y acción.
El rol de Admin tiene control total. Puede borrar el workspace, añadir personas y cambiar la configuración de la capacidad. El Member puede hacer casi todo lo que hace el Admin, excepto borrar el workspace o modificar sus administradores, pero su gran diferencia es que puede compartir ítems individualmente. El Contributor es el rol del desarrollador: puede crear, editar y borrar contenido (informes, pipelines, lakehouses), pero no puede compartir contenido con terceros. Por último, el Viewer es el consumidor final, que en teoría solo debería leer.
Sin embargo, aquí es donde empiezan los problemas. Un Viewer en un workspace de Fabric no siempre puede ver los datos si estos residen en un Lakehouse y no se han configurado correctamente los permisos de OneLake o del SQL Endpoint. Para que un flujo de trabajo sea coherente, recomiendo siempre seguir esta matriz de decisión:
| Acción | Admin | Member | Contributor | Viewer |
|---|---|---|---|---|
| Borrar Workspace | Sí | No | No | No |
| Añadir usuarios | Sí | Sí | No | No |
| Crear/Editar Notebooks | Sí | Sí | Sí | No |
| Publicar Informes PBI | Sí | Sí | Sí | No |
| Ver datos (ReadData) | Sí | Sí | Sí | Solo con permiso adicional |
Seguridad a nivel de ítem: El Lakehouse y el SQL Endpoint
Uno de los mayores cambios respecto al Power BI tradicional es cómo manejamos el acceso al origen. Cuando creas un Lakehouse, se generan automáticamente tres elementos: el Lakehouse propiamente dicho, el SQL Analytics Endpoint y el Modelo Semántico predeterminado. Cada uno tiene su propia capa de seguridad, aunque heredan la del Workspace.
Si quieres profundizar en cómo montar esta estructura, te recomiendo revisar nuestra Guía Práctica: Creando un Lakehouse en Microsoft Fabric. El problema real surge cuando queremos que un usuario externo al equipo de datos consulte el SQL Endpoint pero no queremos que vea el Lakehouse en el explorador de archivos de OneLake. Esto se soluciona mediante el Item-level sharing.
En lugar de añadir al usuario al Workspace, compartimos el SQL Endpoint otorgando el permiso de ReadData. Esto permite que el usuario use herramientas como SQL Server Management Studio (SSMS) o DBeaver para consultar las tablas usando T-SQL, sin tener permisos para modificar la estructura Delta ni para ver archivos en la carpeta /Files del Lakehouse.
-- Ejemplo de concesión de permisos granulares en el SQL Endpoint
-- Esto se ejecuta desde el editor de consultas SQL de Fabric
GRANT SELECT ON SCHEMA::Ventas TO [usuario@empresa.com];
-- Solo permitimos lectura en el esquema de Ventas
GRANT SELECT ON OBJECT::Catalog.Producto TO [analista@empresa.com];
-- Permitimos lectura a una tabla específica de dimensionesEl error crítico: Contributor vs. Viewer en proyectos reales
He visto proyectos de retail donde, para agilizar, se le daba el rol de Contributor a todos los analistas de negocio. ¿El resultado? Notebooks de prueba llenando el workspace, tablas temporales creadas en el Lakehouse de producción y, lo peor, ejecuciones de Spark innecesarias que dispararon los CU (Capacity Units) de la empresa. El rol Contributor en Fabric permite ejecutar computación. Si un analista lanza un Notebook mal optimizado, está consumiendo dinero real de la capacidad.
La estrategia correcta es usar el rol Viewer y complementar con permisos de Build sobre el modelo semántico. Si el usuario necesita explorar datos de forma libre, se le habilita el acceso al SQL Endpoint con permisos de lectura. Nunca, bajo ninguna circunstancia, debemos dar permisos de edición en el workspace a alguien cuyo trabajo no sea el mantenimiento de los activos de datos.
Además, al gestionar modelos grandes, es vital considerar la Optimización de Modelos Semánticos en Power BI: VertiPaq & Storage Engine, ya que un modelo mal optimizado, sumado a una mala gestión de roles, puede hacer que las consultas de los usuarios bloqueen la capacidad asignada al workspace.
Herencia desde grupos y mejores prácticas de Entra ID
Nunca gestiones usuarios de forma individual. Es un suicidio administrativo. En proyectos para el sector público o gran industria, la rotación de personal es alta. La mejor práctica es utilizar grupos de seguridad de Microsoft Entra ID (antes Azure AD).
- Fabric_Admins_Data: Grupo con rol de Admin en el workspace.
- Fabric_Devs_Engineers: Grupo con rol de Contributor.
- Fabric_Business_Analysts: Grupo con rol de Viewer, pero con permisos de ReadData en el SQL Endpoint de la capa Gold.
- Fabric_Report_Consumers: Grupo con acceso solo a la App del workspace.
Al usar grupos, si un consultor abandona el proyecto, solo tienes que eliminarlo del grupo en Entra ID y automáticamente pierde el acceso a todos los activos de Fabric. Esto es especialmente crítico cuando trabajamos con datos sensibles donde el cumplimiento normativo es estricto.
Seguridad OneLake y Data Access Roles
Recientemente, Fabric ha introducido los OneLake Data Access Roles (en vista previa). Esta es la respuesta a la necesidad de seguridad a nivel de carpeta dentro de un Lakehouse. Antes, si tenías acceso al Lakehouse, lo veías todo. Ahora, podemos definir roles que permitan ver la carpeta Ventas/2023 pero no la carpeta Recursos_Humanos/Nominas.
Esto cambia las reglas del juego para arquitecturas de tipo Medallón. Podemos tener un único Lakehouse para la capa Bronze y restringir quién puede leer los datos crudos mediante estos roles de acceso a datos, evitando tener que crear múltiples workspaces para separar la información sensible.
// Ejemplo de cómo se vería una conexión segura desde Power Query
// apuntando a un Lakehouse con permisos restringidos
let
Source = MicrosoftAzureConsumptionInsights.Contents("Tu_ID_Capacidad"),
Navigation = Source{[Name="Ventas_Gold"]}[Data],
FilteredRows = Table.SelectRows(Navigation, each [Fecha] > #date(2023, 1, 1))
in
FilteredRowsEs importante recordar que, aunque aseguremos el acceso, el rendimiento sigue siendo clave. Si el usuario tiene permiso pero la consulta es ineficiente, el impacto en la capacidad será el mismo. Por ello, evita Las 50 Medidas y Patrones DAX que Destruyen el Rendimiento en DirectQuery (y cómo evitarlos) para asegurar que el acceso a los datos sea fluido y no penalice a otros usuarios del mismo workspace.
Checklist de seguridad para tu Workspace de Fabric
- Principio de privilegio mínimo: ¿Tiene el usuario el rol más bajo posible para realizar su tarea?
- Uso de Grupos: ¿He evitado añadir correos individuales al workspace?
- Separación de entornos: ¿Tengo workspaces separados para Desarrollo, Testing y Producción (usando Deployment Pipelines)?
- Auditoría de SQL Endpoint: ¿He revisado quién tiene permisos de
GRANT SELECTfuera de los roles estándar? - Capas de OneLake: ¿Están los datos sensibles en carpetas protegidas con OneLake Data Access Roles?
Preguntas frecuentes
¿Si doy acceso a un informe compartiéndolo, el usuario ve el Lakehouse?
No necesariamente. Si compartes solo el informe, el usuario tiene acceso al contenido visual. Sin embargo, para que los datos carguen, el usuario necesita permisos de lectura en el modelo semántico subyacente. Si el informe usa DirectLake, Fabric gestiona esto de forma transparente, pero no le da acceso al usuario para explorar el Lakehouse por su cuenta.
¿Puedo aplicar RLS (Seguridad a nivel de fila) en Fabric?
Sí, puedes aplicar RLS de dos formas: en el modelo semántico (como en Power BI tradicional) o en el SQL Endpoint mediante T-SQL. La recomendación es aplicarla lo más cerca del origen posible si vas a usar múltiples herramientas de consumo, pero ten en cuenta que DirectLake tiene consideraciones específicas con RLS que pueden degradar el rendimiento a DirectQuery.
¿Qué pasa con los permisos si muevo un Lakehouse entre workspaces?
Los permisos de nivel de workspace se pierden y se heredan los del nuevo workspace de destino. No obstante, los permisos compartidos a nivel de ítem (Sharing) suelen persistir, aunque es una práctica recomendada auditar los accesos tras cualquier movimiento de activos críticos.
¿Es necesario una licencia Pro para ver contenido en un workspace de Fabric?
Depende de la capacidad. Si el workspace está asignado a una capacidad de Fabric (F64 o superior) o Power BI Premium (P1 o superior), los usuarios con licencias gratuitas pueden consumir contenido si tienen el rol de Viewer. Para capacidades menores, todos los usuarios necesitan una licencia Pro o Premium Per User (PPU).
