Nombre del permiso
Microsoft Fabric tiene un modelo de permisos flexible que le permite controlar el acceso a los datos de su organización. En este artículo se explican los distintos tipos de permisos de Fabric y cómo funcionan de forma conjunta para controlar el acceso a los datos de su organización.
Un área de trabajo es una entidad lógica para agrupar elementos en Fabric. Los roles de un área de trabajo definen los permisos de acceso a dicha área de trabajo. Aunque los elementos se almacenan en un área de trabajo, se pueden compartir con otros usuarios en Fabric. Al compartir elementos de Fabric, puede decidir qué permisos conceder al usuario con el que comparte el elemento. Algunos elementos, como los informes de Power BI, permiten un control aún más granular de los datos. Los informes se pueden configurar para que, en función de sus permisos, los usuarios que los vean solo vean una parte de los datos que contienen.
Roles de área de trabajo
Los roles de área de trabajo se usan para controlar el acceso a las áreas de trabajo y a su contenido. Un administrador de Fabric puede asignar roles de área de trabajo a usuarios individuales o a grupos. Los roles de área de trabajo se limitan a un área de trabajo específica y no se aplican a otras áreas de trabajo, a la capacidad en la que se encuentra el área de trabajo o a su inquilino.
Hay cuatro roles de área de trabajo y se aplican a todos los elementos del área de trabajo. Los usuarios que no tienen ninguno de estos roles no pueden acceder al área de trabajo. Los roles son:
Espectador: puede ver todo el contenido del área de trabajo, pero no puede modificarlo.
Colaborador: puede ver y modificar todo el contenido del área de trabajo.
Miembro: puede ver, modificar y compartir todo el contenido del área de trabajo.
Administrador: puede ver, modificar, compartir y administrar todo el contenido del área de trabajo, incluida la gestión de permisos.
En esta tabla se muestra un pequeño conjunto de funcionalidades que tiene cada rol. Para obtener una lista completa y más detallada, consulte Roles de área de trabajo de Microsoft Fabric.
| Funcionalidad | Administrador | Miembro | Colaborador | Espectador |
|---|---|---|---|---|
| Eliminar el área de trabajo | ✅ | ❌ | ❌ | ❌ |
| Agregar administradores | ✅ | ❌ | ❌ | ❌ |
| Adición de miembros | ✅ | ✅ | ❌ | ❌ |
| Escritura de datos | ✅ | ✅ | ✅ | ❌ |
| Creación de elementos | ✅ | ✅ | ✅ | ❌ |
| Lectura de datos | ✅ | ✅ | ✅ | ✅ |
Permisos de elemento
Los permisos de elemento se usan para controlar el acceso a elementos individuales de Fabric dentro de un área de trabajo. Los permisos de elemento se limitan a un elemento específico y no se aplican a otros elementos. Use permisos de elemento para controlar quién puede ver, modificar y administrar elementos individuales en un área de trabajo. Puede usar permisos de elemento para conceder a un usuario acceso a un solo elemento de un área de trabajo a la que no tenga acceso.
Al compartir el elemento con un usuario o grupo, puede configurar permisos de elemento. Compartir un elemento concede al usuario permiso de lectura para dicho elemento de forma predeterminada. Los permisos de lectura permiten a los usuarios ver los metadatos del elemento y los informes asociados a él. Sin embargo, los permisos de lectura no permiten a los usuarios acceder a los datos subyacentes en SQL o OneLake.
Distintos elementos de Fabric tienen permisos diferentes. Para obtener más información sobre los permisos de cada elemento, consulte:
Permisos de proceso
Los permisos también se pueden definir dentro de un motor de proceso específico de Fabric, específicamente a través del punto de conexión de análisis de SQL o en un modelo semántico. Los permisos de motor de proceso permiten un control de acceso a datos más granular, como la seguridad a nivel de tabla y de fila.
Punto de conexión de análisis de SQL: el punto de conexión de análisis de SQL proporciona acceso directo de SQL a las tablas de OneLake y puede tener la seguridad configurada de forma nativa mediante comandos SQL. Estos permisos solo se aplican a las consultas realizadas a través de SQL.
Modelo semántico: los modelos semánticos permiten definir la seguridad mediante DAX. Las restricciones definidas mediante DAX se aplican a los usuarios que consultan a través del modelo semántico o los informes de Power BI basados en el modelo semántico.
Encontrará información más detallada en los siguientes artículos:
Permisos de OneLake (roles de acceso a datos)
OneLake tiene sus propios permisos para administrar el acceso a los archivos y carpetas de OneLake a través de los roles de acceso a datos de OneLake. Los roles de acceso a datos de OneLake permiten a los usuarios crear roles personalizados dentro de un almacén de lago y conceder permisos de lectura solo a las carpetas especificadas al acceder a OneLake. Para cada rol de OneLake, los usuarios pueden asignar usuarios, grupos de seguridad o conceder una asignación automática basada en el rol de área de trabajo.
Obtenga más información sobre el modelo de control de acceso a datos de OneLake y vea las guías paso a paso.
Protección de un almacén de lago para equipos de ciencia de datos
Protección de un almacén de lago para equipos de Almacenamiento de datos
Orden de las operaciones
Fabric tiene tres niveles de seguridad diferentes. Un usuario debe tener acceso en cada nivel para acceder a los datos. Cada nivel se evalúa secuencialmente para determinar si un usuario tiene acceso. Las reglas de seguridad, como las directivas de Microsoft Information Protection, se evalúan en un nivel determinado para permitir o denegar el acceso. El orden de funcionamiento al evaluar la seguridad de Fabric es:
- Autenticación Entra: comprueba si el usuario puede autenticarse en el inquilino de Microsoft Entra.
- Acceso a Fabric: comprueba si el usuario puede acceder a Microsoft Fabric.
- Seguridad de datos: comprueba si el usuario puede realizar la acción solicitada en una tabla o archivo.
Ejemplos
En esta sección se proporcionan dos ejemplos de cómo se pueden configurar los permisos en Fabric.
Ejemplo 1: Configuración de permisos de equipo
Wingtip Toys está configurado con un inquilino para toda la organización y tres capacidades. Cada capacidad representa una región diferente. Wingtip Toys opera en Estados Unidos, Europa y Asia. Cada capacidad tiene un área de trabajo para cada departamento de la organización, incluido el departamento de ventas.
El departamento de ventas tiene un responsable, un jefe del equipo de ventas y miembros del equipo de ventas. Wingtip Toys también emplea a un analista para toda la organización.
En la tabla siguiente se muestran los requisitos de cada rol en el departamento de ventas y cómo se configuran los permisos para habilitarlos.
| Rol | Requisito | Configurar |
|---|---|---|
| Responsable | Ver y modificar todo el contenido del departamento de ventas en toda la organización | Un rol de miembro para todas las áreas de trabajo de ventas de la organización |
| Jefe de equipo | Ver y modificar todo el contenido del departamento de ventas en una región específica | Un rol de miembro para el área de trabajo de ventas de la región |
| Miembro del equipo de ventas | ||
| Analista | Ver todo el contenido del departamento de ventas para toda la organización | Un rol de espectador para todas las áreas de trabajo de ventas de la organización |
Wingtip también tiene un informe trimestral que muestra sus ingresos por ventas desglosados por miembro de equipo de ventas. Este informe se almacena en un área de trabajo de finanzas. Con la seguridad de nivel de fila, el informe se configura para que cada miembro de ventas solo pueda ver sus propias cifras de ventas. Los jefes de equipo pueden ver las cifras de ventas de todos los miembros del equipo de ventas de su región y el administrador de ventas puede ver cifras de ventas de todos los miembros de equipos de ventas de la organización.
Ejemplo 2: Permisos de área de trabajo y elementos
Al compartir un elemento o cambiar sus permisos, los roles de área de trabajo no cambian. En el ejemplo de esta sección se muestra cómo interactúan los permisos de área de trabajo y elementos.
Verónica y Marta trabajan juntas. Verónica es la propietaria de un informe que quiere compartir con Marta. Si Veronica comparte el informe con Marta, Marta podrá acceder a él independientemente del rol de área de trabajo que tenga.
Supongamos que Marta tiene un rol de espectador en el área de trabajo donde se almacena el informe. Si Verónica decide eliminar los permisos de elemento de Marta del informe, Marta podrá seguir viendo el informe en el área de trabajo. Marta también podrá abrir el informe desde el área de trabajo y ver su contenido. Esto se debe a que Marta tiene permisos de visualización para el área de trabajo.
Si Verónica no quiere que Marta vea el informe, no es suficiente con eliminar los permisos de elemento de Marta del informe. Verónica también debe eliminar los permisos de espectador de Marta del área de trabajo. Sin los permisos de espectador del área de trabajo, Marta no podrá ver que el informe existe porque no podrá acceder al área de trabajo. Marta tampoco podrá usar el vínculo al informe, porque no tiene acceso al informe.
Ahora que Marta no tiene un rol de espectador del área de trabajo, si Verónica decide compartir el informe con ella de nuevo, Marta podrá verlo con el vínculo que Verónica ha compartido con ella, sin tener acceso al área de trabajo.
Ejemplo 3: Permisos de aplicación de Power BI
Al compartir informes de Power BI, a menudo desea que los destinatarios solo tengan acceso a los informes y no a los elementos del área de trabajo. Para ello, puede usar aplicaciones de Power BI o compartir informes directamente con los usuarios.
Además, puede limitar el acceso del visor a los datos mediante la seguridad de nivel de fila (RLS), con RLS puede crear roles que tengan acceso a determinadas partes de los datos y limitar los resultados que devuelvan solo a lo que puede acceder la identidad del usuario.
Esto funciona bien cuando se usan modelos de importación a medida que los datos se importan en el modelo semántico y los destinatarios tienen acceso a esto como parte de la aplicación. Con DirectLake, el informe lee los datos directamente desde Lakehouse y el destinatario del informe debe tener acceso a estos archivos en el lago. Existen varias maneras de verlo:
- Conceda a
ReadDatapermiso directo a Lakehouse. - Cambie la credencial del origen de datos de Inicio de sesión único (SSO) a una identidad fija que tenga acceso a los archivos del lago.
Dado que RLS se define en el modelo semántico, los datos se leerán primero y, a continuación, se filtrarán las filas.
Si se define alguna seguridad en el punto de conexión de análisis de SQL en el que se basa el informe, las consultas se revierten automáticamente al modo DirectQuery. Si no desea este comportamiento de reserva predeterminado, puede crear un nuevo Lakehouse mediante accesos directos a las tablas de Lakehouse original y no definir RLS ni OLS en SQL en el nuevo Lakehouse.