Power BI 治理：工作区架构和访问控制

不受监管的 Power BI 部署遵循可预测的轨迹。它始于热情：各部门有机地采用 Power BI，创建工作区、构建报告并连接到数据源。一年之内，该组织有 200 个命名不一致的工作区、500 个指标相互冲突的报告，而且没有人知道哪个仪表板具有“正确”的收入数字。数据素养提高，但数据信任度降低。

治理是解药。精心设计的治理框架不会减慢自助分析的速度，而是通过提供护栏、标准和信任信号来加速自助分析。用户可以更快地创建报告，因为他们知道哪些数据集经过认证。高管们信任这些数字，因为定义是标准化的。 IT 部门可以睡得更好，因为敏感数据经过分类并受到访问控制。

本指南提供了完整的治理框架，涵盖工作区架构、内容生命周期、访问控制、认可、敏感度标签、管理门户配置和使用情况监控。它基于ECOSIRE 已在拥有 50 到 5,000 个 Power BI 用户的组织中实施 的模式。

---

要点

• 工作空间命名约定（例如 DEPT-PURPOSE-ENV）是治理的基础 --- 它们使工作空间可大规模发现、可审计和可管理
• 具有部署管道的三工作区模式（开发、测试、生产）可防止未经测试的更改到达最终用户
• Power BI 应用程序是推荐给消费者的分发机制 --- 它们在不暴露工作空间的情况下提供精心策划的体验
• 内容认可（推广和认证）创建信任层次结构，帮助用户找到权威的数据集和报告
• Microsoft Purview 的敏感度标签对 Power BI 内容进行分类和保护，并自动向下游继承导出
• Power BI 管理门户具有 50 多个租户设置，可控制谁可以创建工作区、共享内容、导出数据、嵌入报告和使用 AI 功能
• 使用指标和活动日志提供对采用模式的可见性，从而实现有关治理调整的数据驱动决策

---

工作区架构

工作空间的目的

Power BI 工作区是数据集、报表、仪表板、数据流和分页报表的容器。它有三个目的：

1. 协作： 工作区成员协作构建和维护内容
2. 安全边界： 工作区角色（管理员、成员、贡献者、查看者）控制谁可以做什么
3. **部署单位：**工作区是部署管道和应用发布的单位

工作区命名约定

如果没有命名约定，工作区会积累“销售仪表板”、“销售报告 v2”、“约翰测试”和“第四季度收入最终最终结果”等名称。命名约定消除了歧义。

推荐的命名模式：

{Department}-{Subject}-{Environment}

示例：

命名规则：

• 使用大写字母表示部门缩写（最多 5 个字符）
• 主题使用 PascalCase（最多 20 个字符）
• 使用大写作为环境后缀
• 除连字符外没有特殊字符
• 没有个人姓名（工作空间属于团队，而不是个人）

每个数据集的工作空间与每个部门的工作空间

每个部门的工作空间 将部门的所有内容分组到一个工作空间中。这更易于管理，但当部门内的多个团队需要不同的访问级别时，会带来权限挑战。

每个数据集的工作空间 为每个主要数据集及其关联的报告创建一个单独的工作空间。这提供了精细的访问控制，但创建了更多的工作空间来管理。

推荐方法： 每个主题区域的工作空间。按业务主题（收入、管道、库存）而不是按部门对相关数据集和报告进行分组。这反映了数据的使用方式（跨职能），而不是数据的生成方式（部门内）。

三环境模式

切勿直接修改生产工作区。将三环境模式与 Power BI 部署管道结合使用：

开发工作区 - 分析师和开发人员在其中构建和迭代报告和数据集。只有 BI 团队有权访问。变化是频繁的和实验性的。

测试工作区 - 业务利益相关者审查和验证更改的地方。内容是通过部署管道从开发部部署的。利益相关者在批准之前验证数据准确性、视觉布局和业务逻辑。

生产工作区 — 最终用户访问的唯一工作区（通过应用程序）。内容在利益相关者批准后从测试中部署。变更是受控且可审计的。

部署管道设置：

1. 在 Power BI 服务中，创建部署管道（“设置”，然后“部署管道”）
2. 将三个工作区分配给开发、测试和生产阶段
3. 配置部署规则（例如，在测试到生产部署期间将数据源从 DEV 数据库更改为 PROD 数据库）
4. 授予 BI 团队跨阶段部署的权限
5. 授予利益相关者批准测试到生产部署的权限

该模式确保：

• 最终用户永远不会看到损坏的或正在进行的报告
• 在投入生产之前对变更进行审查
• 部署历史记录提供审核跟踪
• 数据源连接在环境之间自动切换

---

内容分发：应用程序与直接访问

Power BI 应用程序

应用程序是向最终用户分发内容的推荐方式。应用程序是工作区内容的只读、精选视图。

应用程序的好处：

• 用户看到一个干净、有组织的界面（不是工作区的完整内容列表）
• 可以通过自定义导航将内容组织成多个部分
• 应用程序权限与工作区权限分开
• 应用程序可以分发给安全组、整个组织或特定用户
• 应用程序更新已明确发布——用户看不到正在进行的更改

配置应用程序

1.打开生产工作区 2. 单击“创建应用程序”或“更新应用程序” 3. 配置应用程序部分和导航顺序 4. 设置受众（特定用户、安全组或整个组织） 5.配置权限：

• 允许用户复制报告：是/否（受控环境为否）
• 允许用户使用数据集构建内容：是/否（自助服务是）
• 允许用户共享应用程序：是/否

6. 发布应用程序

何时使用直接工作区访问

直接工作区访问（不通过应用程序）适用于：

• 需要编辑内容的BI团队成员
• 高级用户可以根据共享数据集创建自己的报告
• 开发和测试工作区（不适用于最终用户）

对于所有其他用户，应用程序提供更好的体验和更多的控制。

---

角色和权限

工作区角色

重要说明： 查看者和贡献者受行级安全性 (RLS) 的约束。成员和管理员绕过 RLS 并查看所有数据。切勿将成员或管理员角色分配给应受到数据限制的用户。

权限矩阵

将组织角色映射到 Power BI 角色：

Microsoft 365 组

每个 Power BI 工作区均由 Microsoft 365 组提供支持。创建工作区时，会创建相应的 M365 组。您可以：

• 自动将M365群组成员添加到工作区
• 使用现有的 M365 组（安全组或通讯组列表）作为工作区成员资格
• 通过 Azure AD 组管理而不是 Power BI 管理工作区访问

最佳实践： 使用 Azure AD 安全组进行工作区访问。创建“PBI-FIN-收入贡献者”和“PBI-FIN-收入查看者”等群组。通过 IAM 流程而不是临时 Power BI 分配来管理成员资格。

---

内容认可：推广和认证

认可是 Power BI 的信任信号系统。它可以帮助用户区分权威内容和临时报告。

认可级别

设置认证

1. 在 Power BI 管理门户中，转到租户设置
2. 在“内容包和应用程序设置”下找到“认证” 3.启用认证
3. 指定谁可以验证内容（推荐：一小群 BI 领导和数据管理员）
4. 提供您的认证文档的链接（认证标准）

认证标准

创建一个认证清单，内容必须通过该清单才能获得认证徽章：

数据质量：

• 数据来源是经批准的企业来源（不是个人Excel文件）
• 刷新计划已配置并可靠成功
• 数据验证检查通过（行数、总协调）
• 历史数据完整（无间隙或重复）

模型质量：

• 星型模式设计（事实表+维度表）
• 日期表正确配置和标记
• 关系正确且有效
• 除非明确证明合理，否则不得使用双向交叉过滤器
• 措施有清晰的名称和格式

业务逻辑：

• 指标定义与组织的数据字典相匹配
• 计算结果由业务利益相关者审核
• 处理边缘情况（除以零、空值、未来日期）

安全：

• 在需要时实施行级安全性
• 应用敏感度标签
• Power Query 步骤中没有硬编码凭据或敏感数据

文件：

• 报告包括文档页面或工具提示描述
• 模型中填充了测量描述
• 维护变更日志

认证工作流程

1. 内容创作者推广内容（自助） 2.创建者通过通知BI治理团队请求认证
2. 治理团队根据认证清单进行审查
3. 如果获得批准，指定的认证机构将对内容进行认证
4. 每季度（或部署重大变更时）审核认证

---

敏感度标签

Microsoft Purview（以前称为 Microsoft 信息保护）的敏感度标签对 Power BI 内容进行分类和保护。它们在导出过程中持续存在 --- 导出到 Excel 的“机密”报告在 Excel 文件中带有“机密”标签。

标签分类

定义与您的数据分类策略一致的敏感度标签：

应用标签

标签可以应用于数据集、报表和仪表板级别：

1. 打开数据集或报告设置
2. 在“灵敏度标签”下，选择适当的标签
3. 标签在整个内容生命周期中持续存在

自动贴标

在 Power BI 管理门户中配置默认敏感度标签：

• 新内容的默认标签： 设置为“常规”，以便所有新工作区都以基线分类开始
• 强制标签： 要求用户在发布前应用标签
• 下游继承： 当数据集有标签时，基于其构建的报表会自动继承该标签

基于标签的保护

对于“机密”和“高度机密”标签，配置保护操作：

• 限制谁可以导出数据（阻止 CSV/Excel 导出以实现高度机密）
• 限制谁可以打印报告
• 限制外部共享
• 将 Azure 信息保护加密应用于导出的文件
• 审核标签降级（例如，从机密更改为一般需要理由）

---

管理门户配置

Power BI 管理门户包含 50 多个管理组织行为的租户设置。以下是最有影响力的治理设置。

工作区设置

导出和共享设置

开发者设置

AI 和副驾驶设置

审计与合规

---

使用指标和采用监控

内置使用指标

Power BI 为每个工作区提供使用指标报告。这些报告显示：

• 每份报告的浏览次数（每日、每周、每月）
• 每个报告的唯一查看者
• 最受欢迎的报告
• 报告性能（平均加载时间）
• 分发方法（直接访问、应用程序、嵌入）
• 平台（网络、桌面、移动）

通过单击工作区中任何报告上的“使用情况指标”来访问使用情况指标。

Power BI 活动日志

活动日志记录 Power BI 服务中执行的每个操作。它可以通过以下方式获得：

• Microsoft 365审核日志（合规中心）
• Power BI REST API（Get-PowerBIActivityEvent cmdlet）
• Azure Log Analytics（如果已配置）

要监控的关键事件：

采用仪表板

使用活动日志数据构建内部采用仪表板。关键指标：

Monthly Active Users =
DISTINCTCOUNT(ActivityLog[UserEmail])

Adoption Rate =
DIVIDE(
    [Monthly Active Users],
    [Total Licensed Users]
)

Reports Per User =
DIVIDE(
    COUNTROWS(FILTER(ActivityLog, ActivityLog[Activity] = "ViewReport")),
    [Monthly Active Users]
)

Self-Service Ratio =
DIVIDE(
    CALCULATE(COUNTROWS(ActivityLog), ActivityLog[Activity] = "CreateReport"),
    CALCULATE(COUNTROWS(ActivityLog), ActivityLog[Activity] = "ViewReport")
)

采用仪表板可帮助治理团队：

• 确定采用率低的部门（需要培训）
• 查找应经过认证的大量使用的报告
• 检测从未查看过的报告（退休候选者）
• 跟踪一段时间内的治理 KPI（认证内容 %、标记内容 %）

---

沿袭和影响分析

数据沿袭视图

Power BI 的沿袭视图显示从数据源到数据集再到报告到仪表板的依赖关系链。从工作区菜单访问它（三个点，然后是沿袭视图）。

谱系视图的答案是：

• “哪些报告使用此数据集？” （数据集更改的影响分析）
• “这个报告的数据从哪里来？” （来源可追溯）
• “是否存在没有报告的孤立数据集？” （清理候选人）
• “哪些数据集连接到网关？” （网关依赖关系映射）

影响分析

在更改数据集（修改表、重命名列、更改关系）之前，使用影响分析来了解下游影响：

1. 在沿袭视图中，选择数据集
2. 点击“影响分析”
3. Power BI 显示依赖于数据集的所有报表、仪表板和应用程序
4. 在进行重大更改之前查看列表并通知报告所有者

这可以防止出现以下常见情况：善意的架构更改会破坏 3 个部门的 15 份报告。

数据目录集成

对于拥有 Microsoft Purview（以前称为 Azure 数据目录）的组织，可以在数据目录中注册 Power BI 数据集。这提供了：

• 跨平台数据发现（查找 Power BI 数据集以及 SQL 表、Synapse 视图等）
• 业务术语表集成（将 Power BI 度量链接到标准业务定义）
• 数据管理（在目录中分配数据所有者和管理员）
• 合规性跟踪（查看所有数据资产的敏感度标签和分类）

---

治理政策文件

每个组织都应该维护一份 Power BI 治理文档。下面是一个模板结构。

第 1 部分：范围和目标

• 定义“治理”对您的组织意味着什么（不是官僚机构，而是支持）
• 陈述目标：数据信任、法规遵从、成本控制、加速采用
• 定义治理框架适用于谁（所有 Power BI 用户、特定部门等）

第 2 部分：角色和责任

第 3 部分：标准

• 工作区命名约定（如上所述）
• 数据集命名约定（例如 DS_Revenue_Sales、DS_Headcount_HR）
• 衡量命名约定（例如，“Revenue YTD”而不是“RevYTD”或“ytd_revenue”）
• 报告命名约定（例如 RPT_Executive_Sales_Monthly）
• 调色板标准（与企业品牌一致）
• 可视化指南（哪种图表类型对应哪种数据类型）

第 4 部分：流程

• 内容生命周期：创建、推广、认证、退役
• 变更管理：如何请求对认证内容进行变更
• 访问请求流程：用户如何请求工作区或应用程序访问权限
• 事件响应：检测到数据泄露或治理违规时该怎么办
• 审核节奏：季度认证审核、年度政策更新

第 5 节：合规性

• 数据分类要求（敏感度标签是强制性的）
• 监管要求（GDPR、HIPAA、SOC 2、行业特定）
• 数据保留策略（历史数据在数据集中保留多长时间）
• 导出限制（谁可以导出什么数据类型）

第 6 部分：培训

• 针对新 Power BI 用户的入职培训（自助服务，2 小时）
• 报告作者高级培训（讲师指导，1 天）
• 数据管理员和管理员的治理培训（讲师指导，半天）
• 为所有用户提供年度复习培训（自助服务，1 小时）

对于从头开始实施治理的组织，ECOSIRE 的 Power BI 实施服务 包括一个治理研讨会，该研讨会可根据组织的规模和行业生成定制的治理文档、工作区架构和认证流程。

---

扩展治理

小型组织（100 名用户以下）

保持治理轻量化：

• 5-10 个具有清晰命名的工作空间
• 每个部门一两个经过认证的“黄金”数据集
• 可选的敏感度标签（从简单的工作区访问控制开始）
• 季度治理审查会议
• 一名 Power BI 管理员兼任数据管理员

中型组织（100-1,000 个用户）

添加结构：

• 20-50 个强制执行命名约定的工作区
• 所有生产内容的部署管道
• 数据集上的强制性敏感度标签
• 带有正式清单的内容认证
• 每月治理审查会议
• 具有管理员和管理员角色的专门 BI 团队（2-5 人）

大型组织（1,000+ 用户）

完整的治理计划：

• 由中央管理团队管理的 100 多个工作区
• 卓越中心 (CoE) 提供标准、培训和支持
• 自动化治理监控（Power BI REST API + 自定义仪表板）
• 与 Microsoft Purview 集成企业数据目录
• 专门的合规官审查审核日志
• 季度业务回顾及治理 KPI
• 正式变更咨询委员会，负责对认证内容进行重大变更

卓越中心模型

Power BI 卓越中心 (CoE) 是一个跨职能团队，拥有治理、标准、培训和支持。 CoE 并不为每个部门构建报告——它使各部门能够在治理护栏内构建自己的报告。

CoE 职责：

1. 定义和维护治理政策
2. 构建并验证共享数据集（“黄金”数据层）
3. 管理数据网关和基础设施 4、为自助用户提供培训和办公时间 5.审查和认证部门内容
4. 监控采用和使用指标
5. 评估新的 Power BI 特性和功能
6. 与 IT 部门协调安全、合规性和许可事宜

CoE 尺寸：

---

常见问题解答

我的组织应该有多少个工作区？

没有通用的答案，但一个有用的指南是每个主要主题领域（收入、管道、库存、劳动力等）都有一个生产工作区，加上每个工作区的开发和测试工作区。一个 500 人的组织通常有 15-30 个工作空间。关键指标不是工作区的数量，而是每个工作区是否有明确的所有者、用途和命名约定。没有明确所有权的孤立工作空间是一种治理风险。

我们应该限制谁可以创建工作区吗？

是的。不受限制的工作空间创建会导致无序扩张。在管理门户中，将工作区创建限制为 BI 团队或指定的高级用户。其他用户可以通过简单的表格或票务流程来请求工作空间。该请求应包括：工作区名称（遵循命名约定）、用途、所有者、预期受众和数据源。这会增加一些摩擦，防止工作空间激增，同时确保每个工作空间都有责任。

工作区和应用程序有什么区别？

工作区是 BI 开发人员构建和维护内容（数据集、报告、仪表板）的协作环境。应用程序是分发给最终用户的内容的只读、精选包。将工作区视为厨房，将应用程序视为餐​​厅菜单。食客（最终用户）查看菜单（应用程序）并选择要吃的东西。厨师（BI 开发人员）在厨房（工作区）工作，准备和迭代产品。这种分离确保用户始终看到经过精心设计、经过验证的内容。

我们如何处理 Power BI 中的敏感数据？

分层保护：(1) 使用行级安全性来限制每个用户可以看到的行。 (2) 使用对象级安全性对未经授权的角色隐藏敏感列（例如工资）。 (3) 应用敏感度标签对内容进行分类并控制出口。 (4) 在管理门户中限制高度机密内容的导出权限。 (5) 使用 Azure AD 条件访问要求托管设备和 MFA 来访问 Power BI。 (6) 监视活动日志是否存在异常数据访问模式。单一措施是不够的——纵深防御至关重要。

我们如何衡量治理计划的成功？

每月跟踪这些治理 KPI：(1) 经过认证的生产数据集的百分比（目标：80%+）。 (2) 应用敏感度标签的内容百分比（目标：100%）。 (3) 90 天内没有活动的孤立工作空间数量（目标：零）。 (4) 认证新内容的平均时间（目标：5 个工作日以内）。 (5) 用户采用率（月活跃用户除以授权用户，目标：70%+）。 (6) 审计日志中发现的治理违规数量（目标：下降趋势）。 (7) 自助服务比例（业务用户创建的报告与IT构建的报告，目标：提高）。构建内部治理仪表板来跟踪这些指标并在每月的治理会议中对其进行审查。