权限模型
Microsoft Fabric 采用灵活权限模型，让你能够控制对组织中数据的访问权限。 本文介绍 Fabric 中不同类型的权限，以及如何协同工作来控制对组织中数据的访问权限。
工作区是在 Fabric 中进行项分组的逻辑实体。 工作区角色定义了工作区的访问权限。 尽管项存储在工作区中，但也可以与 Fabric 中的其他用户共享。 共享 Fabric 项时，可以决定向与之共享该项的用户授予哪些权限。 某些项（如 Power BI 报表）支持对数据进行更精细的控制。 可以对报表进行设置，从而确保查看报表的用户只能根据其权限看到他们持有的部分数据。
工作区角色
工作区角色用于控制对工作区及其内容的访问权限。 Fabric 管理员可以将工作区角色分配给单独的用户或组。 工作区角色仅适用于特定的工作区，而不适用于其他工作区、工作区中的容量或租户。
共有四种工作区角色，并且这些角色适用于工作区中的所有项。 没有这些角色的用户将无法访问工作区。 这些角色为：
查看者 - 可以查看工作区中的所有内容，但无法对其进行修改。
参与者 - 可以查看和修改工作区中的所有内容。
成员 - 可以查看、修改和共享工作区中的所有内容。
管理员 - 可以查看、修改、共享和管理工作区中的所有内容，包括管理权限。
下表显示了每种角色所具有的一小部分权限。 有关完整和更详细权限的列表，请参阅 Microsoft Fabric 工作区角色。
| 功能 | 管理员 | 成员 | 参与者 | 查看器 |
|---|---|---|---|---|
| 删除工作区 | ✅ | ❌ | ❌ | ❌ |
| 添加管理员 | ✅ | ❌ | ❌ | ❌ |
| 添加成员 | ✅ | ✅ | ❌ | ❌ |
| 写入数据 | ✅ | ✅ | ✅ | ❌ |
| 创建项 | ✅ | ✅ | ✅ | ❌ |
| 读取数据 | ✅ | ✅ | ✅ | ✅ |
项权限
项权限用于控制对工作区中单独 Fabric 项的访问权限。 项权限仅适用于特定的项，不适用于其他项。 使用项权限可以控制谁有权查看、修改和管理工作区中的单个项。 通过使用项权限，你可以授权用户访问其没有访问权限的工作区中的单个项。
你可以通过配置项权限来与用户或组共享该项。 如果共享某个项，默认情况下会向用户授予对该项的读取权限。 授予读取权限后，用户将能够看到该项目的元数据，此外还可以查看与之关联的任何报表。 但是，读取权限并不允许用户访问 SQL 或 OneLake 中的底层数据。
不同的 Fabric 项具有不同的权限。 要详细了解每个项的权限，请参阅：
计算权限
还可以在 Fabric 中的特定计算引擎中设置权限，尤其是通过 SQL 分析终结点或在语义模型中。 借助计算引擎权限可以实现现更精细的数据访问控制，例如实现表和行级别安全性。
SQL 分析终结点 - SQL 分析终结点会提供对 OneLake 中表的直接 SQL 访问权限，以及通过 SQL 命令原生配置安全性的权限。 这些权限仅适用于通过 SQL 进行的查询。
语义模型 - 借助语义模型可以 DAX 来定义安全性。 使用 DAX 定义的限制适用于通过语义模型或基于语义模型生成的 Power BI 报表进行查询的用户。
有关更多详细信息，请参阅以下文章：
OneLake 权限（数据访问角色）
OneLake 拥有自己的权限，可以通过 OneLake 数据访问角色管理对 OneLake 中文件和文件夹的访问。OneLake 数据访问角色允许用户在湖屋中创建自定义角色，并在访问 OneLake 时仅授予针对指定文件夹的读取权限。 对于每个 OneLake 角色，用户可以分配用户、安全组或根据工作区角色授予自动分配。
详细了解 OneLake 数据访问控制模型，并查看操作指南。
运算顺序
Fabric 具有三种不同的安全级别。 用户必须具有每个级别的访问权限才能访问数据。 每个级别按顺序进行评估，以确定用户是否具有访问权限。 安全规则（如 Microsoft 信息保护策略）在给定级别进行评估，以允许或禁止访问。 评估 Fabric 安全性时的操作顺序如下：
- Entra 身份验证：检查用户是否能够向 Microsoft Entra 租户进行身份验证。
- Fabric 访问：检查用户是否可以访问 Microsoft Fabric。
- 数据安全性：检查用户是否能够对表或文件执行请求的操作。
示例
本节提供了两个示例，说明如何在 Fabric 中设置权限。
示例 1：设置团队权限
Wingtip Toys 为整个组织设置了一个租户，并拥有三个容量。 每个容量表示不同的区域。 Wingtip Toys 在美国、欧洲和亚洲运营。 每个容量为组织中的每个部门提供了一个工作区，包括销售部门。
销售部门设有经理、销售组长和销售组员等角色。 Wingtip Toys 还为整个组织聘请了一名分析师。
下表显示了销售部门中每个角色的要求以及如何设置权限以启用这些角色。
| 角色 | 要求 | 安装 |
|---|---|---|
| 经理 | 查看和修改整个组织中销售部门的所有内容 | 组织中所有销售工作区的“组员”角色 |
| 团队主管 | 查看和修改特定区域中销售部门的所有内容 | 区域中销售工作区的“组员”角色 |
| 销售团队成员 | ||
| 分析师 | 查看整个组织中销售部门的所有内容 | 组织中所有销售工作区的“查看者”角色 |
Wingtip 还有一份季度报表，其中列出了其每个销售组员的销售收入。 该报表存储在财务工作区中。 使用行级别安全性设置该报表，以便每个销售组员只能查看自己的销售数据。 组长可以查看其区域中所有销售组员的销售数据，销售经理可以查看组织中所有销售组员的销售数据。
示例 2：工作区和项权限
共享项或更改其权限时，工作区角色不会更改。 本节中的示例说明了工作区和项权限的交互方式。
Veronica 和 Marta 一起工作。 Veronica 是她想与 Marta 共享的一份报表的所有者。 如果 Veronica 与 Marta 共享该报表，那么无论 Marta 拥有哪种工作区角色，她都可以访问该报表。
假设 Marta 在存储该报表的工作区中具有查看者角色。 如果 Veronica 决定从该报表中移除 Marta 的项权限，则 Marta 仍然可以在该工作区中查看该报表。 Marta 还可以从该工作区打开该报表并查看其内容。 这是因为 Marta 拥有该工作区的查看权限。
如果 Veronica 不希望 Marta 查看该报表，则仅从报表中移除 Marta 的项权限是不够的。 Veronica 还需要从该工作区中移除 Marta 的查看者权限。 如果没有工作区的查看者权限，Marta 将无法看到该报表的存在，因为她无法访问该工作区。 Marta 也无法使用该报表的链接，因为她无权访问该报表。
由于 Marta 没有工作区查看者角色，如果 Veronica 决定重新与她共享该报表，Marta 将能够使用 Veronica 与她共享的链接查看该报表，而无需访问该工作区。
示例 3：Power BI 应用权限
在共享 Power BI 报表时，你通常希望收件人只能访问报表，而不能访问工作区中的项。 为此，可以使用 Power BI 应用或直接与用户共享报表。
此外，可以使用行级安全性 (RLS) 限制查看者对数据的访问，使用 RLS，可以创建有权访问数据某些部分的角色，并限制仅返回用户标识可以访问的内容的结果。
当使用导入模型时，此方法可正常工作，因为数据是在语义模型中导入的，并且收件人可以作为应用的一部分访问它。 利用 DirectLake，报表直接从 Lakehouse 读取数据，并且报表接收者需要有权访问 Lake 中的这些文件。 可以通过多种方式来执行此操作：
- 直接授予
ReadData对 Lakehouse 的权限。 - 将数据源凭证从单一登录 (SSO) 切换到有权访问湖中文件的固定标识。
由于 RLS 是在语义模型中定义的，因此将首先读取数据，然后筛选行。
如果在生成报表的 SQL 分析终结点中定义了任何安全性，则查询将自动回退到 DirectQuery 模式。 如果不想要这种默认回退行为，可以使用原始 Lakehouse 中表的快捷方式创建新的 Lakehouse，而不在新 Lakehouse 上的 SQL 中定义 RLS 或 OLS。