Power BI 实施计划：租户级审核

备注

本文是 Power BI 实现规划系列文章中的一篇。 本系列着重介绍 Microsoft Fabric 中的 Power BI 体验。 有关该系列的介绍，请参阅 Power BI 实施规划。

这篇租户级审核计划文章主要面向：

• Power BI 管理员：负责监督组织的 Power BI 的管理员。 Power BI 管理员可能需要与 IT、安全、内部审核和其他相关团队协作。
• 卓越中心、IT 和 BI 团队：还负责监督 Power BI 的团队。 他们可能需要与 Power BI 管理员和其他相关团队协作。

重要

建议严格遵循 Power BI 发布计划，了解审核和监视功能的未来改进。

租户级审核解决方案的用途是捕获和分析部署到 Power BI 租户的所有用户、活动和解决方案的数据。 此租户级审核数据在很多方面都很有价值，可用于分析采用工作、了解使用模式、指导用户、支持用户、降低风险、提高合规性、管理许可证成本以及监视性能。

创建安全且可用于生产的端到端审核解决方案是一项需要时间来完成的重要项目。 你可以将其视为在商业智能上构建商业智能（BI on BI）。 有关审核数据为何如此有价值的信息，请参阅审核和监视概述。

有关面向报表创建者的报表级审核，请参阅报表级审核。

有关面向数据创建者的数据资产审核，请参阅数据级审核。

本文的其余部分重点介绍租户级审核。

提示

本文的主要重点是帮助你计划创建端到端审核解决方案。 由于本文中的内容整理为四个阶段，你需要的信息可能分布在多个阶段。 例如，你将在阶段 1 中找到有关计划使用服务主体的信息，在阶段 2 中找到有关先决条件和设置的信息。

因此，建议先阅读整篇文章，以便熟悉所涉及的内容。 然后，你应该做好充分准备，以迭代方式计划和构建审核解决方案。

计划构建租户级审核解决方案时，请计划将时间花在以下四个阶段。

• 阶段 1：计划和决策
  • 要求和优先级
  • 数据需求
  • 审核解决方案的类型
  • 权限和职责
  • 技术决策
  • 数据源决策
• 阶段 2：先决条件和设置
  • 创建存储帐户
  • 安装软件和设置服务
  • 注册 Microsoft Entra 应用程序
  • 设置 Power BI 租户设置
• 阶段 3：解决方案开发和分析
  • 提取和存储原始数据
  • 创建审编数据
  • 创建数据模型
  • 增强数据模型
  • 创建分析报表
  • 根据数据执行操作
• 阶段 4：维护、增强和监视
  • 实施和改进
  • 文档和支持
  • 启用警报
  • 持续管理

阶段 1：计划和决策

第一阶段侧重于计划和决策。 需要考虑许多要求和优先级，因此建议你花足够的时间来了解本节中介绍的主题。 目标是做出良好的前期决策，以便下游阶段顺利进行。

要求和优先级

初始阶段的目标是确定什么最重要。 专注于最重要的事项，以及如何衡量组织中的影响。 争取定义业务导向要求，而不是技术导向要求。

应该回答以下几个问题。

• 需要回答哪些关键问题？ 你有大量审核数据需要浏览。 进行审核最有效的方法是专注于回答特定问题。
• 采用目标和数据文化目标是什么？ 例如，你的目标也许是在组织中增加自助 BI 内容创建者的数量。 在这种情况下，需要衡量与创建、编辑和发布内容相关的用户活动。
• 存在哪些直接风险？ 例如，你可能知道过去发生过过度分享内容的情况。 此后加强了用户培训，而你现在想要持续审核安全设置和活动。
• 当前是否有关键绩效指标 (KPI) 或组织目标？ 例如，你可能有一个与数字化转型或成为数据驱动型组织相关的组织 KPI。 租户级审核数据可帮助你衡量 Power BI 实施是否符合这些目标。

提示

验证审核要求，并与执行发起人和卓越中心一起确定优先级。 提取审核数据并开始基于大量有趣的数据创建报表很有吸引力。 但是，如果不通过需要回答的问题和要执行的操作来推动构建审核解决方案，则不太可能从该解决方案中获得高价值。

有关审核数据使用方法的更多想法，请参阅审核和监视概述。

检查清单 - 确定需求和优先级时，关键决策和操作包括：

• 确定要求：收集并记录审核 Power BI 租户的关键业务要求。
• 确定要求的优先级：设置需求的优先级，将其分类为近期、短期、中期和长期（积压工作）。
• 为近期优先级制定计划：制定计划以开始收集数据，以便在需要时可以使用数据。
• 定期重新评估要求：创建定期重新评估要求的计划（例如每年两次）。 验证审核和监视解决方案是否满足所述要求。 根据需要更新计划中的操作项。

数据需求

定义要求和优先级（前面介绍）后，即可确定所需的数据。 本节介绍四类数据。

• 用户活动数据
• 租户清单
• 用户和组数据
• 安全数据

需要的大部分数据都来自管理员 API，这些 API 提供有关 Power BI 租户的大量元数据。 有关详细信息，请参阅本文后面的选择用户 API 或管理员 API。

用户活动数据

将获取有关用户活动的数据设置为第一优先级。 “用户活动”也称为“事件”或“操作”，可用于各种用途。

通常，此数据称为“活动日志”或“事件日志”。 从技术上讲，有多种方法可以获取用户活动数据（活动日志是其中一种方法）。 有关所涉及决策和活动的详细信息，请参阅本文后面的访问用户活动数据。

利用用户活动数据可以回答以下几个常见问题。

• 查找热门用户和热门内容
  • 哪些用户最常查看哪些内容？
  • 查看内容的每日、每周和每月趋势是什么？
  • 报表视图呈现上升趋势还是下降趋势？
  • 有多少活动用户？
• 理解用户行为
  • 最常使用哪种安全类型（应用、工作区或每项分享）？
  • 用户是否最常使用浏览器或移动应用？
  • 哪些内容创建者发布和更新内容最积极？
  • 哪些用户在何时发布或更新了哪些内容？
• 确定用户教育和培训机会
  • 谁在个人工作区中分享了过多内容？
  • 谁在进行大量导出？
  • 谁定期下载内容？
  • 谁正在发布许多新的语义模型？
  • 谁在大量使用订阅？
• 改进治理和合规性工作
  • 哪个 Power BI 管理员何时更改了租户设置？
  • 谁启动了 Power BI 试用？
  • 哪个外部用户何时如何访问了哪些内容？
  • 谁添加或更新了敏感度标签？
  • 有百分之多少的报表视图基于已认证的语义模型？
  • 有百分之多少的语义模型支持多个报表？
  • 哪个用户何时创建或更新了网关或数据源？

有关此数据使用方法的详细信息，请参阅了解使用模式。

重要

如果尚未提取和存储用户活动数据，请将其设为紧急优先级。 至少确保提取原始数据并将其存储在安全位置。 这样，当你准备好分析数据时，数据将可用。 历史记录可保留 30 天或 90 天，具体取决于所使用的源。

有关详细信息，请参阅本文后面的访问用户活动数据。

租户清单

通常，第二优先级是检索数据以创建“租户清单”。 有时，它称为“工作区清单”、“工作区元数据”或“租户元数据”。

租户清单是给定时间点的快照。 它描述了租户中发布的内容。 租户清单不包含实际数据或实际报表。 而是描述所有工作区及其项（例如语义模型和报表）的元数据。

利用租户清单可以回答以下几个常见问题。

• 了解你拥有的内容量以及位置
  • 哪些工作区的内容最多？
  • 每个工作区中发布什么类型的内容（尤其是在将报告工作区和数据工作区分开时）？
  • 项之间存在哪些依赖关系（例如支持许多语义模型的数据流或作为其他复合模型源的语义模型）？
  • 数据世系（Power BI 项之间的依赖关系，包括外部数据源）是什么？
  • 是否存在孤立报表（与其语义模型断开连接）？
• 了解语义模型与报表的比率
  • 发生多少语义模型重用？
  • 是否存在重复或高度相似的语义模型？
  • 是否有机会整合语义模型？
• 了解时间点之间的趋势
  • 报表数量是否随时间而增加？
  • 语义模型数量是否随时间而增加？
• 查找未使用的内容
  • 哪些报表未使用（或未充分利用）？
  • 哪些语义模型未使用（或未充分利用）？
  • 是否有机会停用内容？

租户清单可帮助你在分析历史活动时使用当前名称。 租户中项的快照包含该时间点所有项的名称。 使用当前项名称进行历史报告会很有帮助。 例如，如果报表在三个月前重命名，则当时的活动日志将记录旧报表名称。 使用正确定义的数据模型，可以使用最新的租户清单按项的当前名称（而不是以前的名称）查找项。 有关详细信息，请参阅本文后面的创建数据模型。

有关租户清单使用方法的详细信息，请参阅了解已发布的内容。

提示

你通常会将用户活动事件（上一节介绍）与租户清单结合使用来全面了解情况。 这样，就可以增强所有数据的价值。

由于租户清单是给定时间点的快照，因此需要确定提取和存储元数据的频率。 每周快照对于在两个时间点之间进行比较非常有用。 例如，如果要调查工作区的安全设置，则需要以前的租户清单快照、活动日志事件和当前租户清单快照。

构建租户清单有两种主要方法。 有关所涉及决策和活动的详细信息，请参阅本文后面的访问租户清单数据。

用户和组数据

随着分析需求的增长，你可能会确定要在端到端审核解决方案中包含有关用户和组的数据。 若要检索该数据，可以使用 Microsoft Graph，这是有关 Microsoft Entra ID 用户和组的信息的权威源。

从 Power BI REST API 检索的数据包括用于描述用户的电子邮件地址或安全组的名称。 此数据是给定时间点的快照。

利用 Microsoft Graph 可以回答以下几个常见问题。

• 确定用户和组
  • 来自其用户个人资料的完整用户名（除了电子邮件地址）、部门或位置是什么？
  • 谁是安全组的成员？
  • 安全组的所有者（职责是管理成员）是谁？
• 获取其他用户信息
  • 向用户分配了哪些许可证（Power BI Pro 或 Power BI Premium Per User (PPU)）？
  • 哪些用户登录频率最高？
  • 哪些用户最近未登录 Power BI 服务？

警告

一些用于访问用户和组数据的旧方法（在线上有广泛记录）已弃用，不应使用。 应尽可能使用 Microsoft Graph 作为用户和组数据的权威源。

有关如何从 Microsoft Graph 访问数据的详细信息和建议，请参阅本文后面的访问用户和组数据。

安全数据

你可能需要定期执行安全审核。

利用 Power BI REST API 可以回答以下几个常见问题。

• 确定人员和应用程序
  • 用户、组或服务主体有权访问哪些报表？
  • 哪些用户、组或服务主体是使用电子邮件订阅接收报表的订阅者？
• 了解内容权限
  • 向哪些用户和组分配了哪些工作区角色？
  • 向每个 Power BI 应用受众分配了哪些用户和组？
  • 对哪些用户分配了哪些报表的每项权限？
  • 对哪些用户分配了哪些语义模型的每项权限？
  • 哪些语义模型和数据市场定义了行级别安全性 (RLS)？
  • 向整个组织中的人员分享哪些项？
  • 哪些项在 Internet 上公开发布？
• 了解其他权限
  • 谁有权使用部署管道进行发布？
  • 谁有权管理网关和数据连接？
  • 谁有权管理高级容量？

重要

有时本文指的是 Power BI Premium 或其容量订阅 (P SKU)。 请注意，Microsoft 目前正在合并购买选项并停用 Power BI Premium Per Capacity SKU。 新客户和现有客户应考虑改为购买 Fabric 容量订阅 (F SKU)。

有关详细信息，请参阅 Power BI Premium 许可即将进行的重要更新和 Power BI Premium 常见问题解答。

提示

有关安全的更多注意事项，请参阅安全计划文章。

这些常见问题并非详尽无遗，有各种各样的 Power BI REST API 可用。 有关详细信息，请参阅使用 Power BI REST API。

有关使用管理员 API 与用户 API 的详细信息（包括它如何影响提取数据的用户所需的权限），请参阅本文后面的选择用户 API 或管理员 API。

检查清单 - 确定审核所需的数据时，关键决策和操作包括：

• 确定用户活动数据的特定数据需求：验证已收集的要求。 确定需要哪些审核数据来满足用户活动数据的每个要求。
• 确定租户清单数据的特定数据需求：验证已收集的要求。 确定需要哪些审核数据来编译租户清单。
• 确定用户和组数据的特定数据需求：验证已收集的要求。 确定需要哪些审核数据来满足用户和组数据的每个要求。
• 确定安全数据的特定数据需求：验证已收集的要求。 确定需要哪些审核数据来满足安全数据的每个要求。
• 验证优先级：验证优先级顺序，以便知道首先要开发什么。
• 确定捕获活动的频率：确定捕获活动事件的频率（例如每天一次）。
• 确定捕获快照的频率：确定捕获快照数据（例如租户清单或用户和组数据）的时间间隔。

审核解决方案的类型

租户级审核要么手动完成，要么通过自动过程完成。

大多数新的审核过程都是以手动过程开始的，尤其是在开发和测试期间。 手动审核过程可能会演变为自动过程。 但是，并非每个审核过程都需要完全自动。

手动审核过程

手动审核依赖于用户（通常是 Power BI 管理员）按需运行的脚本和过程。 如果需要，用户可以交互方式运行查询以检索审核数据。

手动审核最适合：

• 正在开发和测试的新脚本。
• 偶尔的一次性审核需求。
• 探索性审核需求。
• 不需要完全支持的非必需审核过程。

自动审核过程

定期审核所需的数据应自动执行。 它定期提取和处理，称为“自动过程”。 有时，它被称为“无人参与过程”。

自动过程的目标是减少手动工作、降低错误风险、提高一致性，并消除依赖单个用户来运行它。

自动审核最适合：

• 在生产中运行的审核过程。
• 定期运行的无人参与过程。
• 已经过全面测试的脚本。
• 具有依赖其作为数据源的其他报表（或其他过程）的基本审核过程。
• 记录和支持的审核过程。

过程类型（手动或自动）可能会影响身份验证的处理方式。 例如，Power BI 管理员可能会对手动审核过程使用用户身份验证，但对自动过程使用服务主体。 有关详细信息，请参阅本文后面的确定身份验证方法。

提示

如果需要定期获取当前手动处理的审核数据，请考虑投入时间将该过程自动化。 例如，如果 Power BI 管理员每天手动运行脚本以从 Power BI 活动日志中检索数据，那么此人生病或休假时，则存在数据丢失风险。

检查清单 - 考虑要开发的审核解决方案类型时，关键决策和操作包括：

• 确定每个新审核要求的主要用途：确定是针对每个新要求使用手动过程还是自动过程。 考虑该决策是暂时的还是永久的。
• 创建如何实现自动化的计划：当它适合特定的审核要求时，创建一个计划，说明如何、何时以及由谁来实现自动化。

权限和职责

此时，你应该清楚地了解要完成的任务以及最初需要的数据。 现在是确定用户权限以及角色和职责的好时机。

用户权限

在计划构建端到端审核解决方案时，请考虑需要访问数据的其他用户的用户权限。 具体而言，确定允许谁访问和查看审核数据。

需要考虑以下几个注意事项。

对审核数据的直接访问

应该确定谁可以直接访问审核数据。 可通过多方面来考虑。

• 谁应是 Power BI 管理员？ Power BI 管理员有权访问所有租户元数据，包括管理员 API。 有关确定谁应是 Power BI 管理员的详细信息，请参阅租户级安全计划。
• 谁可以使用现有服务主体？ 若要使用服务主体（而不是用户权限）来访问审核数据，必须向授权用户提供机密，以便他们可以执行基于密码的身份验证。 应严格控制对机密（和密钥）的访问。
• 是否需要严格控制访问？ 某些具有法规和合规性要求的行业必须比其他行业更严格地控制访问。
• 是否存在大型活动数据量？ 若要避免达到 API 限制，可能需要严格控制允许谁直接访问生成审核数据的 API。 在这种情况下，确保没有重复或重叠的工作会很有帮助。

对已提取原始数据的访问

应该确定谁可以查看已提取并写入存储位置的原始数据。 通常，对原始数据的访问仅限于管理员和审核员。 卓越中心 (COE) 可能也需要访问权限。 有关详细信息，请参阅本文后面的确定存储审核数据的位置。

对审编分析数据的访问

应该确定谁可以查看可供分析的审编和转换数据。 此数据应始终可供管理员和审核员使用。 有时，组织中的其他用户可以使用数据模型，尤其是在创建具有行级别安全性的 Power BI 语义模型时。 有关详细信息，请参阅本文后面的计划创建审编数据。

角色和职责

确定用户权限的工作方式后，就可以开始考虑角色和职责了。 建议尽早让合适的人员参与进来，尤其是在多个开发人员或团队参与构建端到端审核解决方案时。

确定哪些用户或团队将负责以下活动。

角色	职责类型	角色的通常执行者
与利益干系人沟通	通信活动和要求收集。	COE 与 IT 合作。 还可能包括来自关键业务部门的选定人员。
确定优先级，并根据要求提供指导	与端到端审核解决方案相关的决策活动，包括如何满足要求。	监督组织中 Power BI 的团队，例如 COE。 执行发起人或数据治理指导委员会可能会参与制定关键决策或上报问题。
提取和存储原始数据	创建用于访问和提取数据的脚本和过程。 还涉及将原始数据写入存储。	数据工程人员，通常在 IT 部门并与 COE 合作。
创建审编数据	数据清理、转换以及在星型架构设计中创建审编数据。	数据工程人员，通常在 IT 部门并与 COE 合作。
创建数据模型	基于审编数据创建分析数据模型。	Power BI 内容创建者，通常在 IT 部门或 COE。
创建分析报表	创建报表以分析审编数据。 根据新要求以及在有新的审核数据可用时对报表进行持续更改。	Power BI 报表创建者，通常在 IT 部门或 COE。
分析数据并根据结果执行操作	分析数据并根据审核数据执行操作。	监督组织中 Power BI 的团队，通常为 COE。 还可能包括其他团队，具体取决于审核结果和操作。 其他团队可能包括安全性、合规性、法律、风险管理或变更管理。
测试和验证	测试以确保满足审核要求并且提供的数据准确无误。	Power BI 内容创建者，与监督组织中 Power BI 的团队合作。
保护数据	设置和管理每个存储层的安全性，包括原始数据和审编数据。 管理对创建用于进行数据分析的语义模型的访问。	数据存储系统的系统管理员，与监督组织中 Power BI 的团队合作。
计划和自动化	使用所选工具实施解决方案并计划过程。	数据工程人员，通常在 IT 部门并与 COE 合作。
支持解决方案	监视审核解决方案，包括作业运行、错误和技术问题支持。	处理 Power BI 系统支持的团队，通常是 IT 或 COE。

如果上述许多角色和职责将由同一个团队或同一个人执行，则可以合并。 例如，Power BI 管理员可能会执行其中一些角色。

也可能是不同的人执行不同的角色，具体取决于环境。 操作将基于上下文，具体取决于审核数据和建议的操作。

考虑几个示例。

• 示例 1：审核数据显示，某些用户经常将数据导出到 Excel。 执行的操作：COE 与特定用户联系，了解他们的需求并教给他们更好的替代做法。
• 示例 2：审核数据显示，外部用户访问出现意外。 执行的操作：IT 系统管理员更新外部用户访问的相关 Microsoft Entra ID 设置。 Power BI 管理员更新与外部用户访问相关的租户设置。 COE 为管理安全性的内容创建者更新文档和培训。 有关详细信息，请参阅外部用户策略。
• 示例 3：审核数据显示，多个数据模型以不同的方式定义同一度量值（如果详细的元数据租户设置允许，可从元数据扫描 API 获得）。 执行的操作：数据治理委员启动一个项目来定义通用定义。 COE 为创建数据模型的内容创建者更新文档和培训。 COE 还与内容创建者合作，根据需要更新其模型。 有关检索详细元数据的详细信息，请参阅本文后面的访问租户清单数据。

注意

数据提取过程的设置通常是一次性工作，偶尔需要进行改进和故障排除。 分析数据并执行操作是一项持续的工作，需要反复不断的努力。

检查清单 - 考虑权限和职责时，关键决策和操作包括：

• 确定涉及的团队：确定哪些团队将参与审核解决方案的端到端创建和支持。
• 确定用户权限：确定如何设置访问审核数据的用户权限。 创建关键决策文档供以后参考。
• 确定角色和职责：确保明确对谁执行哪些工作的期望，尤其是在涉及多个团队时。 创建角色和职责文档，包括预期的操作。
• 分配角色和职责：将特定角色和职责分配给特定人员或团队。 适当时，请人力资源部更新个人职位描述。
• 创建培训计划：在人员需要新技能时制定培训计划。
• 创建交叉培训计划：确保为关键角色提供交叉培训和后补。

技术决策

计划租户级审核解决方案时，需要做出一些重要的技术决策。 为了提高一致性、避免返工和提高安全性，建议尽早做出这些决策。

第一个计划阶段涉及做出以下决策。

• 选择用于访问审核数据的技术
• 确定身份验证方法
• 选择用户 API 或管理员 API
• 选择 API 或 PowerShell cmdlet
• 确定存储审核数据的位置
• 计划创建审编数据

选择用于访问审核数据的技术

首先需要确定如何访问审核数据。

最简单的入门方法是使用管理员监视工作区中提供的预生成报表。

当需要直接访问数据并生成自己的解决方案时，将使用 API（应用程序程序接口）。 API 旨在通过 Internet 交换数据。 Power BI REST API 支持使用 HTTP 协议请求数据。 当任何语言或工具能够发送 HTTP 请求并接收 JSON 响应时，都可以调用 Power BI REST API。

提示

PowerShell cmdlet 使用 Power BI REST API 来访问审核数据。 有关详细信息，请参阅本文后面的选择 API 或 PowerShell cmdlet。

本节重点介绍技术选择。 有关访问特定类型审核数据的源的注意事项，请参阅本文后面的数据源决策。

平台选项

可通过多种不同的方式访问审核数据。 根据选择的技术，你可能会倾向于首选语言。 你可能还需要就如何计划脚本的运行做出具体决策。 技术在学习曲线和入门难易程度方面差异很大。

你可以借助以下几个技术来使用 Power BI REST API 检索数据。

技术	手动审核过程的不错选择	自动审核过程的不错选择
管理监视工作区
Try-it
PowerShell
Power BI Desktop
Power Automate
首选 Azure 服务
首选工具/语言
Microsoft Purview 审核日志搜索
Defender for Cloud Apps
Microsoft Sentinel

本节的其余部分简要介绍了表中显示的每个选项。

管理监视工作区

管理员监视工作区包含 Power BI 服务中预定义的报表和语义模型。 这是 Fabric 管理员查看近期审核数据的便捷方式，有助于其了解用户活动。

API 文档中的 Try-it

Try-it 是一种交互式工具，可让你直接在 Microsoft 文档中体验 Power BI REST API。 这是探索 API 的一种简单方法，因为它不需要计算机上的其他工具或任何设置。

你可以使用 Try-it 来：

• 手动向 API 发送请求，以确定它是否返回所需的信息。
• 了解如何在编写脚本之前构造 URL。
• 以非正式方式检查数据。

注意

必须是已获得许可且经过身份验证的 Power BI 用户才能使用 Try-it。 它遵循标准权限模型，这意味着用户 API 依赖于用户权限，管理员 API 需要 Power BI 管理员权限。 无法使用服务主体向 Try-it 进行身份验证。

由于它是交互式的，因此 Try-it 最适合学习、探索和新的手动审核过程。

PowerShell 和 Azure Cloud Shell

可以通过多种方式创建并运行 PowerShell 脚本。

几个常用选项如下。

• Visual Studio Code：新式轻量级源代码编辑器。 它是一个免费提供的开源工具，在多个平台上受支持，包括 Windows、macOS 和 Linux。 可以将 Visual Studio Code 与多种语言一起使用，包括 PowerShell（通过使用 PowerShell 扩展）。
• Azure Data Studio：用于创建脚本和笔记本的工具。 它基于 Visual Studio Code 构建。 Azure Data Studio 可独立提供，也可与 SQL Server Management Studio (SSMS) 一起提供。 有许多扩展，包括适用于 PowerShell 的扩展。
• Azure Cloud Shell：在本地使用 PowerShell 的替代选项。 可以从浏览器访问 Azure Cloud Shell。
• Azure Functions：在本地使用 PowerShell 的替代选项。 Azure Functions 是一项 Azure 服务，可用于在无服务器环境中编写和运行代码。 PowerShell 是它支持的其中一种语言。

重要

建议使用最新版本的 PowerShell (PowerShell Core) 来进行所有新的开发工作。 应停止使用 Windows PowerShell（不能运行 PowerShell Core），而是使用支持 PowerShell Core 的其中一种新式代码编辑器。 引用许多使用 Windows PowerShell（版本 5.1）的线上示例时要小心，因为它们可能不使用最新（和更好的）代码方法。

可以通过多种不同的方式来使用 PowerShell。 有关此技术决策的详细信息，请参阅本文后面的选择 API 或 PowerShell cmdlet。

可参考许多线上资源来使用 PowerShell，并且通常可以找到能创建和管理 PowerShell 解决方案的经验丰富的开发人员。 PowerShell 是创建手动和自动审核过程的不错选择。

Power BI Desktop

由于 Power BI Desktop 可以连接到 API，因此你可能会想使用它来构建审核解决方案。 但是，存在一些明显的缺点和复杂性。

• 累积历史记录：由于 Power BI 活动日志提供长达 30 天的数据，因此创建整个审核解决方案涉及随时间累积一组存储所有历史事件的文件。 使用其他工具可以更轻松地累积历史文件。
• 安全地处理凭据和密钥：从社区博主处找到的许多线上解决方案都不安全，因为它们在 Power Query 查询中以纯文本形式对凭据和密钥进行硬编码。 虽然这种方法很简单，但不建议这样做，因为获取 Power BI Desktop 文件的任何人都可以读取这些值。 无法在 Power BI Desktop 中安全地存储密码（使用用户身份验证时）或机密（使用服务主体时），除非：
  • 使用利用 Power Query SDK 开发的自定义连接器。 例如，自定义连接器可以从 Azure 密钥保管库或其他安全存储加密值的服务读取机密值。 全球 Power BI 社区还提供各种自定义连接器选项。
  • 使用 ApiKeyName 选项，该选项在 Power BI Desktop 中效果不错。 但是，无法将密钥值存储在 Power BI 服务中。
• 请求类型：在 Power BI Desktop 中可以运行的内容可能存在一些限制。 例如，Power Query 不支持每种类型的 API 请求。 例如，使用 Web.Contents 函数时，仅支持 GET 和 POST 请求。 对于审核，通常发送 GET 请求。
• 刷新功能：需要遵循特定的 Power Query 开发模式才能成功刷新 Power BI 服务中的语义模型。 例如，使用 Web.Contents 时必须存在 RelativePath 选项，以便 Power BI 可以正确验证数据源的位置，而不会在 Power BI 服务中生成错误。

大多数情况下，建议仅将 Power BI Desktop 用于两个用途。 应使用它来：

• 基于现有审编数据构建数据模型（而不是使用它来最初提取审核数据）。
• 基于数据模型创建分析报表。

Power Automate

可以通过多种方式将 Power Automate 与 Power BI 配合使用。 在审核方面，可以使用 Power Automate 向 Power BI REST API 发送请求，然后将提取的数据存储在所选位置。

提示

若要向 Power BI REST API 发送请求，可以使用 Power Automate 的自定义连接器安全地进行身份验证和提取审核数据。 或者，可以使用 Azure 密钥保管库来引用密码或机密。 这两个选项都优于在 Power Automate 流中以纯文本形式存储密码和机密。

有关 Power Automate 使用方法的其他想法，请在 Power Automate 模板中搜索 Power BI。

首选 Azure 服务

有多个 Azure 服务可以向 Power BI REST API 发送请求。 可以使用首选 Azure 服务，例如：

• Azure Functions
• Azure 自动化
• Azure 数据工厂
• Azure Synapse Analytics

大多数情况下，可以将处理数据提取逻辑的计算服务与存储原始数据（以及审编数据，如适用）的存储服务相结合。 做出技术体系结构决策的注意事项在本文后面介绍。

首选工具和/或语言

可以使用首选工具和首选语言来向 Power BI REST API 发送请求。 当你的团队具有特定工具或语言的专业知识时，这是一种很好的方法，例如：

• Python
• .NET Framework 上的 C#。 （可选）可以使用 Power BI .NET SDK，它充当 Power BI REST API 之上的包装器，以简化某些过程并提高工作效率。
• JavaScript

Microsoft Purview 审核搜索

Microsoft Purview 合规门户（以前称为 Microsoft 365 合规中心）包括一个用户界面，可用于查看和搜索审核日志。 统一审核日志包括 Power BI，以及支持 Microsoft 365 统一审核日志的所有其他服务。

统一审核日志中捕获的数据与 Power BI 活动日志中包含的数据完全相同。 在 Microsoft Purview 合规门户中执行审核日志搜索时，它会将请求添加到队列。 数据可能需要几分钟（或更长时间，具体取决于数据量）才能准备就绪。

可通过以下几种常用方法使用审核日志搜索工具。 方法：

• 选择 Power BI 工作负载以查看一系列日期的事件。
• 查找一个或多个特定活动，例如：
  • 已删除 Power BI 报表
  • 为管理员添加了对 Power BI 中个人工作区的访问权限
• 查看一个或多个用户的活动。

对于具有足够权限的管理员，Microsoft Purview 合规门户中的审核日志搜索工具是手动审核过程的一个不错选择。 有关详细信息，请参阅本文后面的 Microsoft Purview 合规门户。

Defender for Cloud Apps 用户界面

Microsoft Defender XDR（Microsoft 365 门户）中的管理员可使用 Defender for Cloud Apps。 它包含一个用户界面，用于查看和搜索各种云服务（包括 Power BI）的活动日志。 它显示源自 Microsoft Purview 合规性门户的相同日志事件，以及诸如来自 Microsoft Entra ID 的用户登录活动等其他事件。

Defender for Cloud Apps 中的审核日志界面是手动审核过程的一个不错选择。 有关详细信息，请参阅本文后面的 Defender for Cloud Apps。

Microsoft Sentinel 和 KQL

Microsoft Sentinel 是一项 Azure 服务，可用于收集、检测、调查和响应安全事件及威胁。 可以在 Microsoft Sentinel 中将 Power BI 设置为数据连接器，以便将审核日志从 Power BI 流式传输到 Microsoft Sentinel Azure Log Analytics（Azure Monitor 服务的一个组件）。 可以使用 Kusto 查询语言 (KQL) 来分析存储在 Azure Log Analytics 中的活动日志事件。

使用 KQL 在 Azure Monitor 中搜索数据是查看部分审核日志的一个不错选择。 对于手动审核过程，这也是一个不错的选择。 有关详细信息，请参阅本文后面的 Microsoft Sentinel。

平台注意事项

如何访问审核数据存在以下几个注意事项。

• 是在实施手动还是自动审核过程？ 某些工具与手动处理或自动处理密切相关。 例如，用户始终以交互方式运行 Try-it 功能，因此它仅适用于手动审核过程。
• 如何进行身份验证？ 并非所有选项都支持每个身份验证选项。 例如，Try-it 功能仅支持用户身份验证。
• 如何安全地存储凭据？ 不同的技术具有不同的凭据存储选项。 有关详细信息，请参阅本文后面的确定身份验证方法。
• 你的团队已经精通哪种技术？ 如果团队首选且习惯使用某种工具，请从该工具入手。
• 你的团队能够支持什么？ 如果其他团队将支持已部署的解决方案，请考虑该团队是否能够充分支持它。 另请注意，内部团队可能支持顾问完成的开发。
• 你已批准使用哪种工具？ 某些工具和技术可能需要批准。 这可能是由于成本。 也可能是由于 IT 安全策略。
• 你对计划有什么偏好？ 某些技术会为你做出决策。 其他时候，这将是你必须做出的另一个决策。 例如，如果选择编写 PowerShell 脚本，可以通过多种方式来计划它们的运行。 相反，如果使用云服务（如 Azure 数据工厂），则内置了计划。

建议在选择用于访问审核数据的技术之前，先查看本文的其余部分。

检查清单 - 在确定使用哪种技术来访问审核数据时，关键决策和操作包括：

• 与 IT 人员讨论：与 IT 团队沟通，了解某些工具是否获得批准或为首选。
• 通过小型概念证明 (POC) 探索选项：通过技术 POC 进行一些试验。 首先专注于学习。 然后专注于你确定今后使用什么。

确定身份验证方法

计划如何设置身份验证是一个关键决策。 开始审核和监视时，这通常是最困难的一个方面。 应仔细考虑可用选项，以便做出明智的决策。

重要

请就此问题咨询 IT 和安全团队。 请花点时间了解 Microsoft Entra ID 中安全性工作原理的基础知识。

并非 Internet 上的每个 API 都需要身份验证。 但是，所有 Power BI REST API 都需要身份验证。 访问租户级审核数据时，身份验证过程由 Microsoft 标识平台管理。 它由基于行业标准协议构建的 Microsoft Entra 标识服务演变而来。

提示

你可以通过 Microsoft 标识平台术语表这一资源熟悉基本概念。

在检索审核数据之前，必须先进行身份验证，这称为“登录”。 身份验证和授权的概念是分开的，但相互关联。 身份验证过程验证发出请求的人员的身份。 授权过程通过验证用户或服务主体有权执行的操作来授予（或拒绝）对系统或资源的访问权限。

当用户或服务主体进行身份验证时，会向资源服务器颁发 Microsoft Entra 访问令牌，例如 Power BI REST API 或 Microsoft Graph API。 访问令牌默认在 1 小时后过期。 如果需要，可以请求刷新令牌。

访问令牌有两种类型：

• 用户令牌：代表具有已知标识的用户颁发。
• 仅限应用的令牌：代表 Microsoft Entra 应用程序（服务主体）颁发。

有关详细信息，请参阅 Microsoft Entra ID 中的应用程序对象和服务主体对象。

注意

Microsoft Entra 应用程序是一种标识配置，用于自动化过程与 Microsoft Entra ID 集成。 在本文中，它称为“应用注册”。 本文中还经常使用术语“服务主体”。 这些术语将在本节后面部分更详细地介绍。

提示

最简单的身份验证方法是使用 Power BI 管理模块中的 Connect-PowerBIServiceAccount cmdlet。 你可能会在线上文章和博客文章中看到其他与身份验证相关的 cmdlet。 例如，Login-PowerBI 和 Login-PowerBIServiceAccount cmdlet，它们是 Connect-PowerBIServiceAccount cmdlet 的别名。 还有 Disconnect-PowerBIServiceAccount cmdlet，可用于在过程结束时显式注销。

下表介绍了两个身份验证选项。

身份验证的类型	说明	适用对象	手动审核过程的不错选择	自动审核过程的不错选择
用户身份验证	使用用户主体名称（电子邮件地址）和密码以用户登录。	偶尔、交互的使用
服务主体身份验证	使用分配给应用注册的机密（密钥）以服务主体登录。	持续、计划、无人参与的操作

每个身份验证选项将在下一节更详细地介绍。

用户身份验证

用户身份验证在以下情况下很有用。

• 手动审核过程：你想要使用用户权限运行脚本。 权限可以处于以下两个级别中的任意一个级别，具体取决于 API 请求的类型：
  • 管理员 API 的管理员权限：需要使用 Power BI 管理员权限将请求发送到管理员 API。
  • 用户 API 的用户权限：需要使用 Power BI 用户权限将请求发送到用户 API。 有关详细信息，请参阅选择用户 API 或管理员 API。
• 交互式登录：你想要以交互方式登录，这需要你输入电子邮件地址和密码。 例如，必须以交互方式登录才能使用 Try-it 体验，该体验可在 Microsoft API 文档中找到。
• 跟踪访问租户元数据的人员：当单个用户和管理员发送 API 请求时，你可能想要审核这些人是谁。 使用服务主体进行身份验证（下一节介绍）时，活动日志捕获的用户 ID 是应用程序 ID。 如果多个管理员使用同一服务主体进行身份验证，则可能很难知道哪个管理员访问了数据。
• 共享管理员帐户：某些 IT 团队使用共享管理员帐户。 根据实施和控制方式，它可能不是最佳做法。 应考虑使用 Microsoft Entra Privileged Identity Management (PIM)，而不是共享帐户，它可以为用户授予偶尔和临时 Power BI 管理员权限。
• 仅支持用户身份验证的 API：有时，可能需要使用不支持通过服务主体进行身份验证的 API。 在文档中，每个 API 都记录了服务主体是否可以调用它。

重要

建议尽可能对自动过程使用服务主体身份验证。

服务主体身份验证

大多数组织都有一个 Microsoft Entra 租户，因此术语“应用注册”和“服务主体”往往可互换使用。 注册 Microsoft Entra 应用时，有两个组成部分。

• 应用注册：应用注册是全局唯一的。 它是已注册的 Microsoft Entra 应用的全局定义，可供多个租户使用。 应用注册也称为“客户端应用程序”或“执行者”。 通常，术语“客户端应用程序”表示用户计算机。 但是，应用注册的情况不是这样。 在 Azure 门户中，可以在 Microsoft Entra ID 的“应用注册”页面上找到 Microsoft Entra 应用程序。
• 服务主体：服务主体是用于特定租户的应用注册的本地表示形式。 服务主体派生自已注册的 Microsoft Entra 应用。 对于具有多个 Microsoft Entra 租户的组织，多个服务主体可以引用同一应用注册。 在 Azure 门户中，可以在 Microsoft Entra ID 的“企业应用程序”页面上找到服务主体。

由于服务主体是本地表示形式，因此术语“服务主体身份验证”是指代登录的最常见方式。

提示

Microsoft Entra 管理员可以告诉你谁被允许在组织中创建和同意应用注册。

服务主体身份验证在以下情况下很有用。

• 自动审核过程：你想要按计划运行无人参与的过程。
• 无需登录到 Power BI 服务：只需连接和提取数据。 服务主体无法登录到 Power BI 服务。
• 对数据的共享访问权限：你（个人）不是 Power BI 管理员，但有权使用服务主体。 服务主体有权运行管理员 API 来检索租户级数据（或其他特定权限）。
• 由多个管理员使用：你希望允许多个管理员或用户使用同一服务主体。
• 技术阻碍因素：有一个技术阻碍因素阻止使用用户身份验证。 常见的技术阻碍因素包括：
  • 多重身份验证 (MFA)：启用多重身份验证时，自动审核过程（无人参与运行）无法使用用户帐户进行身份验证。
  • 密码哈希同步：Microsoft Entra ID 要求用户帐户进行密码哈希同步才能进行身份验证。 有时，IT 或网络安全团队可能会禁用此功能。

应用注册用途和命名约定

每个应用注册都应有一个明确的名称，用于描述其用途和目标受众（可以使用应用注册的用户）。

考虑实施如下命名约定：<工作负载> - <用途> - <目标受众> - <对象类型>

下面介绍命名约定的各个部分。

• 工作负载：通常等效于数据源（例如，Power BI 数据或 Microsoft Graph 数据）。
• 用途：类似于权限级别（例如读取与读写）。 如下所述，用途可帮助你在创建只能读取数据的单独应用注册时遵循最小特权原则。
• 目标受众：可选。 根据工作负载和用途，你可通过目标受众确定应用注册的预期用户。
• 对象类型：为了清楚起见，包括 EntraApp。

当你有多个租户或多个环境（如开发和生产）时，命名约定可以更具体。

下表显示了可用于提取租户级审核数据的应用注册示例：

应用注册名称	用途	目标读者
PowerBIData-Read-AdminAPIs-EntraApp	提取租户范围的元数据，以便审核和管理 Power BI。 管理员 API 始终是只读的，可能没有在 Microsoft Entra ID 中授予的权限（仅限 Power BI 租户设置）。	Power BI 管理员和卓越中心
PowerBIData-ReadWrite-PowerBIAdministrators-EntraApp	管理 Power BI 租户。 需要读/写权限才能创建或更新资源。	Power BI 管理员和卓越中心
GraphData-Read-PowerBIAdministrators-EntraApp	提取用户和组数据，以便审核和管理 Power BI。 需要读取权限。	Power BI 管理员和卓越中心

管理用于不同用途的多个应用注册的工作量更大。 但是，你可以从几个优点中获益。

• 了解应用注册的预期用途和原因：当你看到应用注册中的客户端 ID 出现在审核数据中时，你将知道它的用途和原因。 这是创建单独的应用注册（而不是仅将一个应用注册用于所有用途）的显著优势。
• 了解应用注册的预期使用者：当你看到应用注册中的客户端 ID 出现在审核数据中时，你将知道谁在使用它。
• 避免过度预配权限：可以遵循最小特权原则，即向具有不同需求的不同用户组提供单独的应用注册。 当不需要写入权限时，可以通过使用仅读取应用注册来避免过度预配权限。 例如，你可能有一些能力很强的自助用户想要收集有关其语义模型的数据，他们需要访问具有读取权限的服务主体。 卓越中心的卫星成员可能为以编程方式管理语义模型的财务团队工作，他们需要访问具有写入权限的服务主体。
• 了解谁应该拥有机密：每个应用注册的机密应仅与需要它的人共享。 轮换机密时（本节后面介绍），如果针对不同需求使用单独的应用注册，则影响较小。 当你因用户离开组织或更改角色而需要轮换机密时，这非常有用。

应用注册权限

应用注册可通过两种主要方式访问数据和资源。 它涉及权限和同意。

• 仅限应用权限：访问和授权由服务主体处理，而不是登录用户。 该身份验证方法对于自动场景很有帮助。 使用仅限应用权限时，务必要知道权限不是在 Microsoft Entra ID 中分配的。 而是通过以下两种方式中的任意一种分配权限：
  • 对于运行管理员 API：某些 Power BI 租户设置允许访问管理员 API 的终结点（返回租户范围的审核元数据）。 有关详细信息，请参阅本文后面的设置 Power BI 租户设置。
  • 对于运行用户 API：适用 Power BI 工作区和项权限。 标准 Power BI 权限控制在运行用户 API（根据调用 API 的用户或服务主体的权限返回审核数据）时可以向服务主体返回哪些数据。
• 委派权限：使用基于范围的权限。 服务主体代表当前登录的用户访问数据。 这意味着服务主体无法访问登录用户可以访问的内容以外的任何内容。 请注意，这与前面介绍的仅限用户身份验证的概念不同。 由于需要自定义应用程序才能正确处理用户和应用权限的组合，因此委派权限很少用于审核场景。 此概念通常被误解，导致许多应用注册过度预配权限。

重要

在本文中，仅重点介绍用户身份验证或仅限应用身份验证。 以编程方式嵌入 Power BI 内容时，委派权限（具有交互式用户和服务主体）可以发挥重要作用。 但是，强烈建议不要设置提取审核数据的委派权限。 每个 API 都会限制其运行频率（存在限制），因此让不同的用户直接访问原始审核数据很不切实际。 相反，建议提取一次原始审核数据（使用集中过程），然后将审编审核数据提供给下游的授权用户。

有关详细信息，请参阅本文后面的注册 Microsoft Entra 应用。

应用注册机密

应用注册通常分配有机密。 机密用作身份验证密钥，并且有到期日期。 因此，需要计划如何定期轮换密钥以及如何将新密钥传达给授权用户。

还需要注意安全存储机密的位置。 组织密码保管库（例如 Azure 密钥保管库）是一个很好的选择。

提示

作为使用机密的替代选项，可以使用托管标识。 使用托管标识无需管理凭据。 如果打算使用 Azure Functions 或 Azure 数据工厂等服务来提取数据，则最好使用托管标识进行调查。

安全管理凭据

无论是使用用户身份验证还是服务主体身份验证，其中一个最大的难题是如何安全地管理密码、机密和密钥。

注意

许多人都会违反的第一个原则是：密码和密钥绝不应在脚本中以纯文本形式出现。 为了简单起见，许多线上文章、博客和示例都是这样做的。 然而，这是一种不好的做法，应该避免。 获取脚本（或文件）的任何人都可能获得作者有权访问的相同数据的访问权限。

可通过以下几种安全方法来管理密码、机密和密钥。

• 尽可能与 Azure 密钥保管库或其他组织密码保管库系统集成。
• 在 PowerShell 脚本中使用凭据和安全字符串。 凭据同时适用于用户身份验证和服务主体身份验证。 但是，为用户帐户启用多重身份验证时，不能使用凭据。
• 在 PowerShell 脚本中提示输入密码，或通过浏览器使用交互式身份验证。
• 使用 Microsoft 发布的 PowerShell 机密管理模块。 它可以使用本地保管库来存储值。 它还可与远程 Azure 密钥保管库集成，这在组织中有多个管理员使用同一脚本时非常有用。
• 为 Power BI Desktop 创建自定义连接器，以便它可以安全地处理凭据。 一些自定义连接器可从社区成员处获得（通常在 GitHub 上）。

提示

建议咨询 IT 和安全团队，以帮助选择最佳方法，或验证解决方案是否以安全的方式管理凭据。

Microsoft 身份验证库

对 Azure AD 身份验证库 (ADAL) 的支持已于 2022 年 12 月结束。 今后，应使用 Microsoft 身份验证库 (MSAL)。 组织中的安全团队应熟悉这一重大更改。

虽然 Power BI 专业人员深入了解过渡到 MSAL 并不重要，但应遵循以下建议。

• 使用 Connect-PowerBIServiceAccount PowerShell cmdlet 进行身份验证时，请使用最新版本的 Power BI 管理模块。 它在版本 1.0.946（2021 年 2 月 26 日）中从 ADAL 切换到 MSAL。
• 直接在脚本中进行身份验证时，请使用 Microsoft Entra V2 终结点。 Microsoft Entra V2 终结点使用 MSAL，而 Microsoft Entra V1 终结点使用 ADAL。
• 请停止使用已弃用的 API 和模块。 有关详细信息，请参阅本文后面的已弃用的 API 和模块。
• 如果在线上找到社区解决方案，请确保它使用 MSAL 而不是 ADAL 进行身份验证。

检查清单 - 确定如何管理身份验证时，关键决策和操作包括：

• 确定要使用的身份验证类型：确定用户身份验证或服务主体身份验证是否最合适，具体取决于计划创建的审核解决方案的类型。
• 计划所需的应用注册：考虑要求、工作负载和目标受众（每个应用注册的用户）。 计划需要创建多少个应用注册来支持这些需求。
• 为应用注册创建命名约定：设置命名约定，以便轻松了解每个应用注册的预期用途和预期用户。
• 计划如何安全地管理凭据：考虑安全管理密码、机密和密钥的方法。 考虑可能需要哪些文档和培训。
• 确认 MSAL 的使用：确定是否存在任何依赖于 ADAL 的现有手动或自动审核解决方案。 必要时，创建一个计划来重写这些解决方案，以使用较新的 MSAL 身份验证库。

选择用户 API 或管理员 API

计划检索审核数据时，务必使用正确类型的 API。

需要考虑两种类型的 API。

• 用户 API：依靠登录用户（或服务主体）的权限向 API 发送请求。 例如，在工作区中返回语义模型列表的一种方法是使用用户 API。 可以通过工作区角色或每项权限授予读取语义模型的权限。 有两种方法可以运行用户 API：
  • 用户身份验证：登录用户必须有权访问工作区或项。
  • 服务主体身份验证：服务主体必须有权访问工作区或项。
• 管理员 API：从租户检索元数据。 它有时称为“组织范围”。 例如，若要返回租户中所有语义模型的列表，请使用管理员 API。 有两种方法可以运行管理员 API：
  • 用户身份验证：登录用户必须是 Power BI 管理员才能运行管理员 API。
  • 服务主体身份验证：服务主体必须拥有运行管理员 API 的权限（不像用户 API 那样依赖于安全权限）。

提示

所有管理员 API 都属于管理员操作组。 具有“以管理员身份”前缀的任何 API 都是管理员 API，其余所有 API 都是用户 API。

考虑一个需要获取语义模型列表的示例。 下表显示了可用于执行此操作的六个 API 选项。 四个选项是用户 API，两个选项是管理员 API。 返回的项的范围和数量会有所不同，具体取决于所选的 API。

API 名称	API 的类型	范围	语义模型数
获取数据集	用户	个人工作区	一个
获取数据集	用户	个人工作区	全部
获取组中的数据集	用户	一个工作区	一个，前提是登录用户有权读取该语义模型
获取组中的数据集	用户	一个工作区	全部，前提是登录用户有权读取每个语义模型
以管理员身份获取组中的数据集	管理员	一个工作区	全部
以管理员身份获取数据集	管理员	整个租户	全部

注意

某些 API 名称包含术语“组”作为对工作区的引用。 该术语起源于最初的 Power BI 安全模型，该模型依赖于 Microsoft 365 组。 虽然 Power BI 安全模型多年来发生了重大变化，但现有 API 名称保持不变，以避免破坏现有解决方案。

有关租户设置的信息，请参阅本文后面的设置 Power BI 租户设置。

检查清单 - 选择是使用用户 API 还是管理员 API 时，关键决策和操作包括：

• 参考数据要求：收集和记录审核解决方案的关键业务要求。 根据所需的数据类型，确定用户范围或组织范围是否合适。
• 测试结果：进行一些试验。 测试不同 API 返回的结果的准确性。
• 查看权限：对于任何现有的审核解决方案，确认为 Power BI 管理员和服务主体正确分配了权限。 对于新的审核解决方案，确认将使用哪种身份验证方法。

选择 API 或 PowerShell cmdlet

要做出的一个关键决策是，当 PowerShell cmdlet 可用于要检索的特定数据时，是否使用它们。 如果你已确定 PowerShell 是用于访问审核数据的其中一种技术，则此决策非常重要。

PowerShell 是一种任务自动化解决方案。 术语“PowerShell”是一个统称，指的是脚本语言、命令行 shell 应用程序和配置管理框架。 PowerShell Core 是最新版本的 PowerShell，可在 Windows、Linux 和 macOS 上运行。

PowerShell cmdlet 是执行操作的命令。 PowerShell 模块是包含 PowerShell 成员（例如 cmdlet、提供程序、函数、工作流、变量和别名）的程序包。 这些模块需要下载并安装。

PowerShell 模块在 API 之上创建一个抽象层。 例如，Get-PowerBIActivityEvent cmdlet 检索（或获取）Power BI 租户的审核事件。 此 PowerShell cmdlet 从获取活动事件 REST API 检索其数据。 通常，使用 cmdlet 更容易入门，因为它简化了对基础 API 的访问。

只有一部分 API 可用作 PowerShell cmdlet。 在继续扩展整个审核解决方案时，可能会结合使用 cmdlet 和 API。 本节的其余部分可帮助你确定访问数据的方式。

PowerShell 模块

Microsoft 已发布两个 PowerShell 模块，它们包含与 Power BI 相关的 cmdlet。 分别是 Power BI 管理模块和数据网关模块。 这些 PowerShell 模块充当基础 Power BI REST API 之上的 API 包装器。 使用这些 PowerShell 模块可以更轻松地编写脚本。

提示

除了 Microsoft 发布的模块之外，还有由 Power BI 社区成员、合作伙伴和 Microsoft 最有价值专家 (MVP) 免费提供的 PowerShell 模块和脚本（通常在 GitHub 上）。

从社区解决方案开始可以在构建端到端审核解决方案方面发挥重要作用。 如果选择使用免费提供的解决方案，请确保对其进行全面测试。 熟悉其工作原理，以便日后有效地管理解决方案。 IT 部门可能制定了使用公开提供的社区解决方案的标准。

Power BI 管理模块

Power BI 管理模块是一个汇总模块，包含用于管理、容量、工作区等的特定 Power BI 模块。 可以选择安装汇总模块以获取所有模块，也可以安装特定模块。 Windows PowerShell 和 PowerShell Core 都支持所有 Power BI 管理模块。

重要

建议停止使用 Windows PowerShell（无法运行 PowerShell Core）。 请改用支持 PowerShell Core 的其中一种新式代码编辑器。 Windows PowerShell ISE（集成脚本环境）只能运行 PowerShell 版本 5.1，该版本不再更新。 Windows PowerShell 现已弃用，因此建议使用 PowerShell Core 来进行所有新的开发工作。

可以使用以下几个常用 cmdlet 来检索审核数据。

管理模块	Cmdlet	用途
配置文件	Connect-PowerBIServiceAccount	对 Power BI 用户或服务主体进行身份验证。
管理员	Get-PowerBIActivityEvent	查看或提取租户的 Power BI 活动日志事件。
工作区	Get-PowerBIWorkspace	编译工作区列表。
报表	Get-PowerBIReport	编译工作区或租户的报表列表。
数据	Get-PowerBIDataset	编译工作区或租户的语义模型列表。
Profile	Invoke-PowerBIRestMethod	发送 REST API 请求（命令）。 此 cmdlet 是一个不错的选择，因为它可以调用任何 Power BI REST API。 如果要通过使用 Connect-PowerBIServiceAccount cmdlet 来使用更简单的身份验证形式，并且能够调用没有相应 PowerShell cmdlet 的 API，这也是一个不错的选择。 有关详细信息，请参阅本节后面的使用 PowerShell cmdlet 的注意事项。

提示

还有其他 cmdlet 可用于管理和发布内容。 但是，本文的重点是检索审核数据。

可以从 PowerShell 库下载 Power BI 管理模块。 安装模块最简单的方法是使用 PowerShellGet。

建议安装 Power BI 管理汇总模块。 这样，就能获得你可能需要的所有 cmdlet。 至少需要配置文件模块（用于身份验证）以及包含要使用的 cmdlet 的任何特定模块。

注意

请确保在使用 PowerShell 的每个服务器、用户计算机和云服务（例如 Azure 自动化）上保持模块为最新。 如果不定期更新模块，可能会出现不可预知的错误或问题。 一些工具（如 Visual Studio Code）可帮助你保持更新模块。 另请注意，当你安装或更新较新版本时，PowerShellGet 不会自动卸载较旧版本的模块。 它会在较旧版本的基础上安装较新版本。 建议检查已安装的版本，并定期卸载较旧版本。

数据网关模块

数据网关模块包含从本地数据网关及其数据源检索数据的 cmdlet。 数据网关模块仅在 PowerShell Core 上受支持。 它在 Windows PowerShell 上不受支持。

与 Power BI 管理模块（前面介绍）不同，数据网关模块不包含任何管理员 cmdlet。 许多 cmdlet（以及相应的网关 API）都要求用户具有网关管理员权限。

警告

无法将服务主体分配为网关管理员（即使服务主体是安全组的成员）。 因此，请计划在检索有关数据网关的信息时使用用户凭据。

你可以使用数据网关模块中的以下多个 cmdlet 来检索审核数据。

Cmdlet	用途
Connect-DataGatewayServiceAccount	对 Power BI 用户进行身份验证（通常要求该用户属于网关管理员角色）。
Get-DataGatewayCluster	编译网关群集列表。
Get-DataGatewayClusterDataSource	编译网关群集的数据源列表。
Get-DataGatewayInstaller	验证允许哪些用户在组织中安装和注册网关。

可以从 PowerShell 库下载数据网关模块。

PowerShell 使用方法

可以通过多种不同的方式来使用 PowerShell。 你做出的决策很重要。

下表介绍了三种不同的 PowerShell 使用方法。

方法	说明	示例
使用 PowerShell cmdlet 简化身份验证，并直接调用 API。 推荐的方法	使用此方法时，兼具简单性和灵活性的优点。 Invoke-PowerBIRestMethod cmdlet 可从 Power BI 管理配置文件模块获取。 此 cmdlet 通常称为“瑞士军刀”，因为你可以使用它来调用任何 Power BI REST API。 使用此方法的优点是可以简化身份验证，然后调用任何 Power BI REST API。 强烈建议使用此方法。	使用 Connect-PowerBIServiceAccount cmdlet 进行身份验证后，使用 Invoke-PowerBIRestMethod cmdlet 从首选 API（例如以管理员身份获取管道用户）检索数据。
尽可能多地使用 PowerShell 中的 cmdlet 进行身份验证和数据检索。	使用此方法时，可广泛使用 PowerShell。 PowerShell 用于协调脚本的运行，并尽可能使用 PowerShell 模块来访问数据。 这从多个方面产生了对 PowerShell 的更大依赖。	使用 Connect-PowerBIServiceAccount cmdlet 进行身份验证后，使用 cmdlet（例如 Get-PowerBIActivityEvent）来检索数据。
仅使用 PowerShell 来协调过程的运行。 尽可能少地使用 PowerShell 模块。	使用此方法时，对 PowerShell 作为工具的依赖较小，因为它的主要用途是协调 API 调用的调用。 仅使用一个通用 PowerShell 模块来访问 API（不使用 Power BI 管理模块中的任何模块）。	使用 Microsoft 身份验证库 (MSAL) 进行身份验证后，使用通用 Invoke-RestMethod cmdlet 调用首选 API（例如以管理员身份获取管道用户）来检索数据。

在上表中，第一种方法兼具简单性和灵活性。 此方法可帮助大多数组织在各项需求之间达到最佳平衡，因此建议使用。 某些组织可能具有现有的 IT 策略和员工偏好，会影响你确定 PowerShell 的使用方式。

提示

可以使用 Invoke-ASCmd PowerShell cmdlet 来创建并执行 DAX、XMLA 和 TMSL 脚本。 但是，这些用例不在本文的讨论范围。 有关查询动态管理视图 (DMV) 的详细信息，请参阅数据级审核。

技术用户（和管理员）可以使用 Power BI 管理模块来检索数据或自动执行内容管理的某些方面。

• 对于管理员：将 -Scope 参数设置为 Organization 以访问整个租户中的实体（例如检索所有工作区列表）。
• 对于技术用户：将 -Scope 参数设置为 Individual（或省略参数）以访问属于用户的实体（例如检索用户有权访问的工作区列表）。

考虑需要获取语义模型列表的场景。 如果选择直接使用 API，则必须指定要调用的 API。 但是，如果选择使用 Get-PowerBIDataset cmdlet，则可以设置 -Scope 参数来检索用户特定的或租户范围的语义模型列表。 你所做的选择取决于你对如何使用 PowerShell 的决策（上表介绍）。

下表介绍了 PowerShell cmdlet 中使用的参数如何转换为 API PowerShell 调用。

cmdlet 参数	cmdlet 使用的 API	API 的类型	范围	检索到的项
-DatasetID {DatasetID} -Scope Individual	获取数据集	用户	个人工作区	一个语义模型
-Scope Individual	获取数据集	用户	个人工作区	所有语义模型
-DatasetID {DatasetID} -GroupID {WorkspaceID}	获取组中的数据集	用户	一个工作区	一个语义模型，前提是登录用户有权读取该语义模型
-GroupID {WorkspaceID}	获取组中的数据集	用户	一个工作区	一个语义模型，前提是登录用户有权读取该语义模型
-GroupID {WorkspaceID} -Scope Organization	以管理员身份获取组中的数据集	管理员	一个工作区	所有语义模型
-Scope Organization	以管理员身份获取数据集	管理员	整个租户	所有语义模型

使用 PowerShell cmdlet 的注意事项

Power BI PowerShell cmdlet 使用起来更简单，因为它们抽象了 REST API 调用的某些复杂性。

cmdlet 通过以下几个方面简化审核数据的访问。

• 身份验证：在 PowerShell 脚本中进行身份验证最简单的方法是使用 Connect-PowerBIServiceAccount cmdlet。
• 简单性：更容易入门，因为检索审核数据的方法非常简单。 考虑在使用 Get-PowerBIActivityEvent cmdlet 时，检索一天的审核数据。 然而，直接调用获取活动事件 REST API 时，将检索一小时的审核数据。 因此，使用 REST API 检索一天的审核数据时，必须使用循环调用 API 24 次，以提取一天中的每一小时。
• 大型结果集的分页：通过分页有效地检索大型结果集。 分页涉及一次检索一个结果块。 cmdlet 会自动为你管理分页。 但是，直接使用 REST API 时，脚本必须检查延续令牌以确定是否还有更多结果。 脚本应继续检索结果块，直到未收到延续令牌。 有关使用延续令牌的示例，请参阅活动事件 REST API。
• 访问令牌过期：身份验证后，将返回访问令牌。 它默认在一小时后过期。 cmdlet 会为你处理访问令牌过期。 这样，你便无需编写逻辑来请求刷新令牌。
• 格式：cmdlet 返回的数据的格式比 REST API 返回的数据格式稍好。 输出对用户更友好。 对于自动审核过程，这可能不是问题。 但是，对于手动审核过程，较好的格式可能会有所帮助。

直接使用 REST API 的注意事项

有时，直接调用 Power BI REST API 有一些好处。

• 更多可用的 API：可用的 REST API 比 PowerShell cmdlet 更多。 但是，不要忽视 Invoke-PowerBIRestMethod cmdlet 的灵活性，你可以使用它来调用任何 Power BI REST API。
• 更新频率：Microsoft 更新 REST API 的频率高于更新 PowerShell 模块的频率。 例如，如果将新属性添加到获取数据集 API 响应，则可能需要一些时间才能在 Get-PowerBIDataset cmdlet 的结果中可用。
• 较低的语言/工具依赖性：直接使用 REST API（而不是 cmdlet）时，无需使用 PowerShell。 或者，可以选择仅使用 PowerShell 来协调脚本中许多 API 的调用。 通过消除（或避免）对 PowerShell 的任何依赖，在将来的某个时候，你可以使用其他语言重写逻辑。 当 IT 或开发人员团队对工具和语言有强烈的偏好时，较低的依赖性可能是需要考虑的重要因素。

无论选择使用哪种方法，REST API 都会随时间而变化。 当技术发展时，API（和 PowerShell 模块）可以被弃用和替换。 因此，建议有目的地创建易于维护且可灵活更改的脚本。

检查清单 - 选择是直接访问还是使用 PowerShell cmdlet 访问 REST API 时，关键决策和操作包括：

• 咨询 IT 部门有关 PowerShell 的使用：联系相关的 IT 团队，以确定是否存在关于如何使用 PowerShell 的现有内部要求或偏好。
• 确定如何使用 PowerShell：确定要使用的 PowerShell 方法，以及是要有意增加还是减少对 PowerShell 的依赖。 考虑是否需要内部沟通或培训。
• 升级到 PowerShell Core：研究能否使用 PowerShell Core。 确定是否需要更新管理员计算机。 考虑需要测试哪些现有脚本。 确定管理员或开发人员是否需要额外的培训来升级其技能。
• 确定要使用的 PowerShell 模块：考虑是否使用 Power BI 管理模块和/或数据网关模块。
• 确定是否允许社区项目：确定是否允许（甚至鼓励）使用线上提供的 PowerShell 模块（而不是 Microsoft 发布的模块）。 咨询 IT 部门，以确定对于线上获取的社区项目是否有相应的标准。
• 阐明如何支持社区项目：如果允许 PowerShell 社区项目，请考虑在内部使用后谁将负责支持它们。
• 完成小型概念证明 (POC)：使用技术 POC 进行试验。 确认访问数据的首选客户端工具和方法。
• 确定如何支持高级用户：考虑如何支持使用用户 API 自行创建自动化的技术用户。

确定存储审核数据的位置

计划构建端到端审核解决方案时，需要确定存储原始数据（以及审编数据，下一节介绍）的位置。 有关数据存储的决策与你如何处理数据集成的偏好相关。

提取原始审核数据时，请保持简单。 建议在最初提取数据时不要选择特定属性、执行转换或应用任何格式。 而是提取所有可用属性并以数据的原始状态进行存储。

以原始状态存储原始数据是最佳做法的原因包含以下几个方面。

• 所有数据都在历史记录中可用：随着时间的推移，将有新的属性和事件类型可用。 存储所有原始数据是确保你始终有权访问提取数据时可用的任何数据的好方法。 即使需要时间（可能是数周或数月）才能意识到有新的数据属性可用，也可以从历史角度分析它们，因为你在原始数据中捕获了它们。
• 可复原更改：如果原始数据格式发生更改，提取数据的过程将不受影响。 由于某些审核数据对时间敏感，因此请务必确保设计的数据提取过程在源中发生更改时不会失败。
• 角色和职责：不同的团队成员（例如数据工程师或 Fabric 管理员）可能负责创建访问、提取和存储原始审核数据的过程。 简化数据提取过程可让多个团队更轻松地协同工作。

存储原始数据有以下几个选项。

• 数据湖或对象存储：OneLake 等云服务，专门用于存储任何结构的文件。 它是存储原始审核数据的最佳选择。 在数据湖体系结构中，原始数据应存储在铜牌层中。
• 文件系统：文件系统（如 Windows 或 Linux）是存储原始审计数据的常见选择。
• 数据库：可以将 JSON 数据存储在关系数据库中，如 Azure SQL 数据库。 但是，它不如将数据存储在数据湖或文件系统中那么常见。 这是因为查询和维护 JSON 数据可能会变得具有挑战性且成本高昂，尤其是在数据量增加时。

提示

使用数据湖、对象存储或文件系统时，建议以易于组织和保护的方式存储数据。 同样重要的是要清楚数据是否包含事件（通常追加）或是否是时间点快照（需要选择要分析的日期）。

考虑一个涉及数据湖的原始数据区域的示例。 该区域具有用于存储活动日志数据的文件夹层次结构：Raw > ActivityLog > YYYY > MM。 文件夹按年份和月份进行分区。 存储在月份文件夹中的文件使用以下格式：PBIActivityLog-YYYYMMDD-YYYYMMDDTTTT.json。 YYYYMMDD 表示实际数据，YYYYMMDDTTTT 表示提取时间戳。 通过包含提取时间戳，可以确定哪个文件是最新的（以防需要再次提取数据）。 例如，如果在 2023 年 4 月 25 日上午 9 点 (UTC) 提取 2023 年 4 月 23 日活动的数据，则文件名将为 PBIActivityLog-20230523-202305250900。

强烈建议使用一种允许将原始数据写入不可变存储的技术。 不可变存储保证一旦写入数据，就不能覆盖或删除数据。 这种区别对审核员很重要，它使你可以相信原始数据是可靠的。

还需要考虑如何安全地存储原始数据。 通常，很少有用户需要访问原始数据。 通常根据需要提供对原始数据的访问权限，原始数据通常供数据工程师和系统管理员使用。 你的内部审核员可能也需要访问权限。 负责创建审编数据（下一节介绍）的团队成员也需要访问原始数据。

你可以通过考虑以下几个注意事项来选择原始数据存储。

• 是手动审核过程还是自动审核过程？ 自动审核过程通常对数据的存储方式和存储位置有更严格的要求。
• 主题领域是否特别敏感？ 根据数据类型及其敏感度，组织可能对其存储方式和存储位置有要求。 Power BI 审核数据包含用户标识信息和 IP 地址，因此应将其存储在安全区域中。
• 是否有首选的存储技术？ 组织内可能正在使用现有的存储技术，因此这是一个合乎逻辑的选择。
• 用户是否会直接访问存储？ 安全模型是一个重要考虑因素。 通常，很少有用户被授予对原始数据的访问权限。 对审编数据的访问权限通常提供给负责创建集中数据模型（用作报告层的语义模型）的 Power BI 内容创建者。
• 是否有数据驻留要求？ 某些组织具有法律或法规数据驻留要求，需要将数据存储在特定数据区域中。
• 如何组织数据？ 使用奖牌体系结构是一种常见做法，尤其是在数据胡和湖屋实现中。 目标是将数据存储在铜牌、银牌和金牌数据层中。 铜牌层包含最初的原始数据。 银牌层包含用于转换的已验证数据和已删除重复数据的数据。 金牌层包含可随时用于分析的经过高度优化的审编数据。

检查清单 - 计划存储原始数据的位置时，关键决策和操作包括：

• 咨询 IT：与相关 IT 团队联系，以确定是否正在运行现有过程来提取原始审核数据。 如果是，请了解是否可以访问现有数据。 如果需要新的数据提取过程，请确定是否对数据的存储位置有偏好或要求。
• 确定原始数据的存储位置：确定用于存储原始数据的最佳存储位置和结构。
• 确定数据驻留要求：了解对于数据存储位置是否有法律或法规要求。
• 创建文件夹结构和命名约定：确定要用于原始数据文件的命名约定，包括文件夹结构。 请在技术文档中包含这些详细信息。
• 考虑原始数据的安全性如何工作：设计原始数据存储位置时，请考虑谁需要访问数据以及如何授予访问权限。

计划创建审编数据

审编数据支持分析，设计为便于用户阅读。 需要就如何以及在何处创建审编数据做出一些决策。 选择用于存储审编数据的技术可能是上一节中列出的任何技术。

审编数据的目标是将数据转换为更友好的格式，并针对分析和报告进行优化。 它构成了 Power BI 数据模型的数据源，这意味着你将使用 Power BI 数据模型来分析组织中 Power BI 的使用情况。 适用基本数据模型指南：应采用星型架构设计，该设计针对性能和可用性进行了优化。

你可以选择以不同的方式创建审编数据。 你需要确定如何执行数据集成，以及在上游多远处应用转换，以准备数据将其加载到星型架构中。

数据湖

可以在数据湖中应用转换和创建审编数据文件。 应对审编数据使用金牌层，使其在逻辑上与存储在铜牌层中的原始数据分开。 分层分隔数据还可以简化设置不同用户访问权限的过程。

在以下情况下使用数据湖来转换和审编数据：

• 你预计会有多个 Power BI 数据模型提供报告服务（这证明创建中间银牌层是合理的）。
• 需要支持多个需要访问租户级审核数据的自助内容创建者。
• 有要用于转换和加载数据的现有工具和过程。
• 你希望最大程度地减少需要在一个或多个 Power BI 数据模型中完成（并可能重复）的数据准备。

Power BI 数据模型

可能可以在 Power BI 中完成所有转换工作。 使用 Power Query 访问数据并将其从原始状态转换为审编格式。

在以下情况下使用 Power BI 数据模型：

• 你想要简化端到端体系结构，并直接从原始数据加载数据模型。 （增量刷新有助于缩短刷新持续时间。）
• 首选在加载数据模型时执行所有转换工作。
• 你希望为租户级审核数据创建一个集中数据模型。 所有报表（或其他数据模型）都可以使用集中 Power BI 语义模型作为其源。
• 你希望仅向用户提供对集中 Power BI 语义模型（而不是任何源数据）的访问权限。

提示

创建审编数据时，请以某种方式对其进行设置，以便针对较早的日期范围轻松重新运行该过程。 例如，如果你发现三个月前审核日志中出现了一个新属性，你将希望能够自该属性首次出现以来对其进行分析。 必须以原始状态存储原始数据（本文前面介绍）有几个原因，能够重新加载审编数据历史记录就是其中之一。

有关星型架构中可能包含哪些维度表和事实数据表的详细信息，请参阅本文后面的创建数据模型。

检查清单 - 计划如何创建审编数据时，关键决策和操作包括：

• 确定应在何处执行转换：考虑应该在上游多远处完成转换工作，以及它适合整个体系结构计划的位置。
• 确定使用哪种工具来将数据转换为星型架构：确认使用哪些工具和服务来将原始数据转换为审编数据。
• 确定审编数据的存储位置：确定存储已转换为星型架构格式的原始数据的最佳选择。 确定中间银牌层在端到端体系结构中是否有用。
• 创建命名约定：确定要用于审编数据文件和文件夹的命名约定（如适用）。 请在技术文档中包含这些详细信息。
• 考虑审编数据的安全性如何工作：在设计审编数据存储位置时，请考虑谁需要访问数据以及如何分配安全性。

数据源决策

此时，你应该清楚要求、数据需求和权限。 你已做出关键技术决策。 现在需要就如何获取某些类型数据的方法做出一些决策。

访问用户活动数据

Power BI 用户活动数据（有时称为“活动日志”或“审核日志”）包含大量信息，可帮助你了解 Power BI 租户中发生的情况。 有关确定数据需求的详细信息，请参阅本文前面的用户活动数据。

Power BI 将其日志与 Microsoft Purview 统一审核日志（以前称为 Microsoft 365 统一审核日志）整合。 这种整合是一个优势，因为它意味着 Microsoft 365 中的每个服务都不必实施自己独特的日志记录方式。 默认启用。

重要

如果尚未提取用户活动数据，请将其设为紧急优先级。 用户活动数据最长可保留 30 天或 90 天（取决于源）。 即使尚未准备好进行深入分析，也请务必尽快开始提取和存储数据。 这样，就可以分析有价值的历史记录。

有多个选项可用于检索用户活动数据。

方法	说明	历史记录默认保留天数	手动审核过程的不错选择	自动审核过程的不错选择	设置警报的不错选择	快速入门的不错选择
手动（用户界面）	Microsoft Purview 合规性门户	90
手动（用户界面）	Defender for Cloud Apps	30
编程	Power BI 活动日志（API 或 PowerShell cmdlet）	30
编程	Office 365 管理活动 API	7
编程	Microsoft Sentinel (Azure Monitor)	30

本节的其余部分介绍表中显示的每一种技术。

Microsoft Purview 合规性门户

通过 Microsoft Purview 合规门户（以前称为 Microsoft 365 合规中心）中的审核搜索工具，可以方便地查看活动和警报。 此工具不需要你创建脚本来提取和下载数据。 可以选择 Power BI 工作负载来查看某个时间范围内的所有审核日志记录。 还可以通过选择特定活动和用户来缩小结果范围。 例如，经理要求你找出当天早些时候删除工作区的人员，以便他们可以快速联系该人员讨论情况。

最近 90 天的历史记录可通过审核（标准）获得。 借助审核（高级），长期保留允许你更长时间保留审核日志（可选）。 由于长期保留仅适用于许可的 E5 用户，因此它不包括非 E5 用户和来宾用户的审核记录。 因此，建议你仅依赖默认的 90 天历史记录，以确保捕获所有活动。

访问 Microsoft Purview 合规门户中的审核日志有许可要求。 访问审核日志还需要提升的 Exchange Online 权限。

提示

Power BI 管理员默认无权访问 Microsoft Purview 合规门户中的统一审核日志搜索。 由于它包含许多 Microsoft 365 服务的数据，因此是一个高特权角色。 在大多数组织中，这些权限是为少数 IT 管理员保留的。 Power BI 管理员可以使用其他选项，本节稍后将对此进行介绍。

Microsoft Purview 合规门户中的用户界面可用于手动审核过程和用户活动的偶尔调查。

Defender for Cloud Apps

Defender for Cloud Apps 中的门户是一个便利的地方，无需创建用于提取和下载数据的脚本即可查看活动和警报。 它还允许你查看 Power BI 活动日志和用户登录中的数据。

Defender for Cloud Apps 包含一个用户界面，用于查看和搜索各种云服务（包括 Power BI）的活动日志。 它显示源自 Microsoft Purview 统一审核日志的相同日志事件，并包含诸如来自 Microsoft Entra ID 的用户登录活动等其他事件。

与 Microsoft Purview 合规门户（上一节介绍）一样，Defender for Cloud Apps 具有可搜索的用户界面。 但是，筛选器选项不同。 除了标准的 30 天历史记录外，还可以使用 Defender for Cloud Apps 查看最多六个月的活动日志历史记录（以 7 天为增量）。

访问 Defender for Cloud Apps 有许可要求。 还需要单独的权限。

提示

Power BI 管理员默认无权访问 Defender for Cloud Apps。 Defender for Cloud Apps 中有一个 Power BI 角色。 将 Power BI 管理员添加到此角色是向他们授予有限数据集访问权限的好方法。

Defender for Cloud Apps 中的用户界面可用于手动审核过程和用户活动的一次性调查。

Power BI 活动日志

Power BI 活动日志源自统一审核日志。 它仅包含与 Power BI 服务相关的用户活动。

提示

对于计划提取用户活动的组织，建议从 Power BI 活动日志开始。 它是以编程方式访问的最简单源。

有两个选项可用于访问 Power BI 活动日志。

• 使用所选工具调用获取活动事件 REST API。
• 使用 Get-PowerBIActivityEvent PowerShell cmdlet。 可从 Power BI 管理管理员模块获取它。

有关要使用的选项的信息，请参阅本文前面的选择 API 或 PowerShell cmdlet。

提示

有关如何使用 PowerShell 访问 Power BI 活动日志的示例，请参阅访问 Power BI 活动日志。

所有 Fabric 管理员和 Power Platform 管理员都可以使用 Power BI 活动日志数据。 可以从统一审核日志访问数据，该日志可供某些 Exchange Online 角色使用。 有关详细信息，请参阅跟踪 Power BI 中的用户活动。

当你打算仅检索 Power BI 审核日志记录时，建议使用 Power BI 活动日志。

注意

在审核日志数据中，工作区称为“文件夹”。 在 Power BI REST API 中，工作区称为“组”。

Office 365 管理活动 API

可以从其他服务的统一审核日志中提取数据，例如 SharePoint Online、Teams、Exchange Online、Dynamics 365 和 Power BI。 如果目标是为多个服务实施审核和监视解决方案，建议使用 Office 365 管理活动 API。 由于此 API 从许多服务返回数据，因此它称为“统一审核 API”（或“统一审核日志”）。 它属于 Office 365管理 API。

在构建新解决方案之前，建议联系 IT 部门，以确定现有的 Power BI 审核记录是否可用。 过程可能已经提取并存储了数据。 你也可能获得访问此数据的权限，而无需构建新的解决方案。

可以通过两种方式中的任意一种访问数据。

• 使用所选工具直接调用 Office 365 管理活动 API。 API 默认返回 24 小时的数据。 最多可以检索 7 天的历史记录。
• 使用 Search-UnifiedAuditLog PowerShell cmdlet。 它是一个 Exchange Online PowerShell cmdlet。 最多可以检索 90 天的历史记录。

重要

Search-UnifiedAuditLog cmdlet 无法很好地缩放，它要求你实施循环策略以克服其 5,000 行的限制。 由于这些原因，它适用于偶尔查询或活动较少的小型组织。 如果只需要 Power BI 数据，建议改用 Get-PowerBIActivityEvent cmdlet。

通常，使用 Office 365 管理活动 API 入门比使用 Power BI 活动日志（前面介绍）更具挑战性。 这是因为 API 返回内容 blob，并且每个内容 blob 都包含单独的审核记录。 对于大型组织，每天可能有数千个内容 blob。 由于客户和第三方应用程序大量使用此 API，因此 Microsoft 实施限制，以确保他们对服务的使用不会对其他应用程序产生负面影响（称为“邻近干扰”）。 因此，在大型组织中检索大量历史记录可能是一项挑战。 有关详细信息，请参阅此疑难解答文章。

若要使用此 API，必须使用已授予从 Office 365 管理活动 API 检索数据的权限的服务主体进行身份验证。

提示

Power BI 管理员默认无权访问 Office 365管理活动 API。 由于它包含许多 Microsoft 365 服务的数据，因此访问需要高特权管理员或审核角色。 在大多数组织中，这些权限是为少数 IT 管理员保留的。 Power BI 活动日志供 Power BI 管理员使用。

当 IT 需要从各种服务（Power BI 之外）提取和存储审核日志时，以编程方式从 Office 365 管理活动 API 检索审核数据是一个不错的选择。

Microsoft Sentinel

Microsoft Sentinel 是一项 Azure 服务，可用于收集、检测、调查和响应安全事件及威胁。 可以在 Microsoft Sentinel 中将 Power BI 设置为“数据连接器”。 连接后，审核日志（包含数据子集）将从 Power BI 流式传输到 Azure Log Analytics，它是 Azure Monitor 的一项功能。

提示

Azure Log Analytics 基于工作区级语义模型事件日志使用的同一体系结构。 有关语义模型事件日志的详细信息，请参阅数据级审核。

由于它是单独的 Azure 服务，因此必须在 Azure Log Analytics (Azure Monitor) 中向要运行 Kusto 查询语言 (KQL) 查询的任何管理员或用户授予权限。 当他们具有权限时，便可查询存储在 PowerBIActivity 表中的审核数据。 但请记住，在大多数情况下，你将授予用户访问金牌层中审编数据而不是铜牌层中原始数据的权限。

使用 KQL 分析 Azure Log Analytics 中存储的活动日志事件。 如果你有 SQL 经验，你会发现与 KQL 有很多相似之处。

可通过多种方式访问存储到 Azure Log Analytics 的事件。 可用工具如下：

• 预构建的“适用于 Power BI 语义模型的 Log Analytics”模板应用。
• 适用于 Azure 数据资源管理器 (Kusto) 的 Power BI Desktop 连接器。
• Azure 数据资源管理器中基于 Web 的查询体验。
• 可以发送 KQL 查询的任何查询工具。

注意

请注意，只有部分 Power BI 活动日志数据存储在 Azure Monitor 中。 计划对组织中的 Power BI 使用情况和采用情况进行全面分析时，建议使用其他选项（本节前面介绍）来检索活动数据。

可以检索的历史记录时段取决于 Azure Log Analytics 工作区的数据保留策略。 在确定保留多少数据时，请考虑成本和对原始数据的访问。

当 IT 部门已经对 Microsoft Sentinel 进行了投资时，Microsoft Sentinel 和 Azure Monitor 是不错的选择，捕获的详细程度可以满足你的需求，并且威胁检测等活动优先。 但是，由于 Microsoft Sentinel 不会捕获所有 Power BI 活动数据，因此它不支持对 Power BI 使用情况和采用情况进行全面分析。

用户活动数据注意事项

你可以通过考虑以下几个注意事项来选择用户活动数据源。

• 是手动审核过程还是自动审核过程？ 用户界面选项适用于手动审核过程和偶尔的一次性查询，尤其是在需要调查特定活动时。 若要支持历史数据分析，还需要一个按计划提取用户活动数据的自动审核过程。
• 多久需要一次用户活动数据？ 对于自动审核过程，计划使用协调世界时 (UTC) 而不是本地时间提取至少比当前日期早一天的数据。 例如，如果过程在星期五早上（UTC 时间）运行，则应从星期三提取数据。 应该以一天的延迟提取数据有几个原因。
  • 当你始终一次提取整 24 小时时，文件将更易于处理，从而避免了不足一天的结果。
  • 你将最大程度地降低错过某些审核事件的风险。 通常，审核事件会在 30 分钟内到达。 有时，某些事件最多可能需要 24 小时才能到达统一审核日志。
• 是否需要更多 Power BI 数据？ 考虑访问所需内容的最有效方法。
  • 如果只需要 Power BI 用户活动数据，请使用 Power BI 活动日志。
  • 如果需要来自多个服务的审核日志，请使用 Office 365 管理活动 API 来访问统一审核日志。
• 由谁开发解决方案？ 计划投入一些时间来构建解决方案。 生成生产就绪脚本可能需要花费大量精力。

检查清单 - 计划如何访问用户活动数据时，关键决策和操作包括：

• 明确需求范围：确定是仅需要访问 Power BI 审核记录，还是需要访问多个服务的审核数据。
• 咨询 IT：了解 IT 当前是否提取审核日志，以及是否可以获取对原始数据的访问权限，而无需构建新的解决方案。
• 确定数据源：确定用于访问用户活动数据的最佳源。
• 完成概念证明：计划完成小型技术概念证明 (POC)。 使用它来验证有关如何构建最终解决方案的决策。
• 跟踪其他数据需求：可以将活动日志数据与其他源相关联，以提高数据的价值。 跟踪这些机会的出现，以便将其添加到项目范围内。

访问租户清单数据

租户清单是成熟审核和监视解决方案的宝贵且必要的部分。 它可帮助你了解 Power BI 中存在哪些工作区和内容（语义模型、报表和其他项），并且是对用户活动数据（上一节介绍）的绝佳补充。 有关确定数据需求的详细信息，请参阅本文前面的租户清单。

用户活动（前面介绍）是审核事件，它们是用户在特定日期和时间执行的操作的记录。 但是，租户清单不同。 租户清单是给定时间点的“快照”。 它描述提取时 Power BI 服务中所有已发布项的当前状态。

注意

Power BI REST API 文档将已发布的项称为“工件”。

提示

许多组织发现，在每周的同一时间提取租户清单很有帮助。

若要正确分析 Power BI 租户中发生的情况，同时需要用户活动数据和租户清单。 结合这两者可以让你了解自己拥有多少内容以及其位置。 它还允许你查找未使用或未充分利用的内容（因为活动日志中不会有这些内容的任何事件）。 租户清单还有助于编译所有项的当前名称列表，这在项名称更改时非常有用。

有关租户清单值的详细信息，请参阅本文前面的租户清单。

提示

可以使用以管理员身份获取未使用的工件 API 来搜索在过去 30 天内没有任何用户活动的项。 但是，无法自定义该时间段。 例如，你可能有每季度才使用一次的关键内容。 通过将租户清单与用户活动数据相结合，可以自定义的方式查找未使用的项。

可以通过两种不同的方式获取租户清单数据。

方法	说明	最适合	手动审核过程的不错选择	自动审核过程的不错选择
编程	API Get Groups as Admin 或 Get-PowerBIWorkspace PowerShell cmdlet 可以提供整个租户的工作区列表。 （可选）可以包含每个工作区的单个项（如语义模型和报表）。	规模较小或数据量低的组织
编程	一组异步管理员 API（统称为“元数据扫描 API”或“扫描程序 API”）可以返回工作区和单个项的列表。 （可选）还可以包含详细的元数据（如表、列和度量值表达式）。	数据量大且/或需要获取详细结果的组织

本节的其余部分介绍表中显示的每一种技术。

组 API 或工作区 cmdlet

若要检索工作区列表，可以使用多个 REST API 中的一个，例如以管理员身份获取组 API（使用所选工具）。 结果包括额外的元数据，例如说明以及工作区是否存储在高级容量中。

注意

API 名称中包含“组”一词作为对工作区的引用。 该术语起源于最初的 Power BI 安全模型，该模型依赖于 Microsoft 365 组。 虽然 Power BI 安全模型多年来发生了重大变化，但现有 API 名称保持不变，以避免破坏现有解决方案。

Get Groups as Admin REST API 包含有用的 $expand 参数。 使用此参数可以选择展开结果，以便它们包含发布到工作区的项列表（例如语义模型和报表）。 还可以将 users 数据类型传递给 $expand 参数，以包含分配给工作区角色的用户。

还可以使用 Get-PowerBIWorkspace PowerShell cmdlet。 它来自 Power BI 管理工作区模块。 将 -Scope 参数设置为 organization 时，它的功能类似于 Get Groups as Admin API。 该 cmdlet 还接受 -Include 参数（相当于 REST API 中的 $expand 参数），以包含在工作区中发布的项（如语义模型和报表）。

提示

通过传入参数，可以以不同的方式使用 cmdlet。 本节重点介绍如何检索租户范围的清单。 有关使用 -Scope 参数的详细信息，请参阅本文前面的选择用户 API 或管理员 API。

若要帮助你选择要使用的选项，请参阅本文前面的选择 API 或 PowerShell cmdlet。

Get Groups as Admin REST API 或 Get-PowerBIWorkspace PowerShell cmdlet 最适合手动审核过程和一次性调查。 数据量大的组织通常会发现这些选项使用起来具有挑战性。 REST API 和 cmdlet 始终提取完整的数据集，因此它们可能需要很长时间才能运行。 因此，大型组织也可能会遇到每小时允许的请求数限制（称为“限制”，这样做是为了保护服务的正常运行）。 元数据扫描 API（下一节介绍）提供了一种更可靠且可缩放的替代方案。

元数据扫描 API

元数据扫描 API（通常称为“扫描程序 API”）是一组 API，用于返回工作区及其 Power BI 项（语义模型、报表和其他项）的列表。 从概念上讲，它们提供与组 API 或工作区 cmdlet 相同的数据（甚至更多），如上一节介绍。 但是，用于检索数据的方法不同，更适合提取租户清单。

注意

请注意某些人如何使用术语“扫描程序 API”或短语“扫描租户”。 他们通常使用这些术语来表示“编译租户清单”，并将其与用户活动事件区分开来。 他们可能是指元数据扫描 API 的使用，也可能不是。

应考虑使用元数据扫描 API 而不是 Get Groups as Admin REST API 或 Get-PowerBIWorkspace cmdlet（前面介绍）有两个主要原因。

• 增量数据提取：扫描程序 API 仅提取自上次运行以来更改的数据。 相反，Get Groups as Admin REST API 和 Get-PowerBIWorkspace cmdlet 是同步操作，每次运行时都会提取完整的数据集。
• 更高粒度的详细信息级别：扫描程序 API 可以检索粒度详细信息（如表、列和度量值表达式），前提是由两个租户设置授予对详细元数据的权限。 相反，Get Groups as Admin REST API 和 Get-PowerBIWorkspace cmdlet 提供的最低详细信息级别是按项类型（例如工作区中的报表列表）。

使用扫描程序 API 需要完成更多工作，因为需要调用一系列 API。 此外，它们作为“异步”过程运行。 异步过程在后台运行，因此无需等待它完成。 在创建将要计划的生产就绪脚本时，可能需要与 IT 或开发人员协作。

下面是使用扫描程序 API 时过程应遵循的步骤序列。

1. 登录：使用有权运行管理员 API 的 Power BI 管理员帐户或服务主体登录到 Power BI 服务。 有关详细信息，请参阅本文前面的确定身份验证方法。
2. 获取工作区 ID：发送请求以检索工作区 ID 列表。 首次运行时，不会有修改日期，因此它将返回工作区的完整列表。 通常，你将传递修改日期，以仅检索自该时间点以来更改的工作区。 修改日期必须在过去 30 天内。
3. 启动元数据扫描：通过传入在步骤 2 中检索到的工作区 ID 来发起调用，以请求扫描工作区信息。 请注意，这是一个 POST API（而不是 GET API，后者在检索审计数据时更常见）。 POST API 是一个 HTTP 请求，用于创建或写入指定资源的数据。 此查询指定要提取的详细信息级别，例如数据源详细信息、语义模型架构、语义模型表达式或用户。 提交后，API 会返回扫描的 ID。 它还会返回扫描的日期和时间，你应将其记录为快照日期。
4. 检查扫描状态：使用在步骤 3 中获取的扫描 ID 获取扫描状态。 可能需要多次调用此 API。 当返回的状态为“成功”时，可以继续执行下一步。 扫描所需的时间取决于请求的数据量。
5. 获取结果：使用在步骤 3 中获取的扫描 ID 来获取扫描结果并提取数据。 必须在完成步骤 4 后的 24 小时内执行此步骤。 请记住，快照时间戳应与步骤 3 而不是步骤 5 相关联（当存在明显延迟时）。 这样，你将获得准确的快照时间戳。 将结果保存在首选数据存储位置。 如本文所述，建议以原始状态存储原始数据。
6. 为下一个过程做好准备：记录步骤 3 中获得的扫描时间戳，以便下次运行该过程时可以在步骤 2 中使用它。 这样，你将只提取自该时间点以来更改的数据。 今后，所有后续数据提取都将是增量更改，而不是完整快照。

检查清单 - 计划对租户清单数据的访问时，关键决策和操作包括：

• 确认要求：阐明编译租户清单的需求和数据的分析要求。
• 确定提取租户清单的频率：确认需要新租户清单的频率（例如每周）。
• 确定如何提取租户清单：确认将使用哪种方法来获取租户清单数据（API、cmdlet 或元数据扫描 API）。
• 完成概念证明：计划完成小型技术概念证明 (POC)。 使用它来验证有关如何构建最终解决方案的决策。

访问用户和组数据

除了用户活动数据中包含的标识信息（如电子邮件地址）之外，检索位置或组织详细信息等其他信息也很有价值。 可以使用 Microsoft Graph 检索有关用户、组、服务主体和许可证的数据。 Microsoft Graph 包含一组 API 和客户端库，可用于从各种服务检索审核数据。

下面是有关可以访问的 Microsoft Entra 对象的一些详细信息。

• 用户：Microsoft Entra ID 中作为工作、学校或 Microsoft 帐户存在的标识。 术语“域用户”通常用于描述组织用户，而正式术语是“用户主体名称”(UPN)。 UPN 的值通常与用户的电子邮件地址相同（但是，如果电子邮件地址发生更改，UPN 不会更改，因为它是不可变的）。 每个用户还有一个唯一的 Microsoft Graph ID。 通常，用户帐户与一个人相关联。 某些组织创建的用户是用于自动活动或管理任务的“服务帐户”。
• 服务主体：创建应用注册时预配的不同类型的标识。 服务主体适用于无人参与的自动活动。 有关详细信息，请参阅本文前面的确定身份验证方法。
• 组：用户和服务主体的集合。 可以使用多种类型的组来简化权限管理。 有关详细信息，请参阅使用组的策略。

注意

当本文引用“用户和组”时，此术语还包括服务主体。 为简洁起见，使用这个较短的术语。

检索的用户和组数据是描述给定时间点当前状态的“快照”。

提示

有关用户、服务主体和组的详细信息，请参阅与 Microsoft Entra ID 的集成。

分析属性

对于 Power BI 租户级审核，可以从 Microsoft Graph 提取并存储以下属性。

• 用户的全名：许多数据源仅包括执行活动的用户的电子邮件地址或分配给某个角色的用户的电子邮件地址。 如果要在分析报表中显示全名（显示名称），请使用此属性。 使用全名可使用户更容易分辨报表。
• 其他用户属性：有关用户的其他描述性属性可能在 Microsoft Entra ID 中可用。 具有分析价值的内置用户个人资料属性的一些示例包括职务、部门、经理、区域和办公地点。
• 安全组的成员：大多数数据源都提供组的名称（例如，Power BI 活动日志记录安全组已分配给工作区角色）。 检索组成员身份可提高你全面分析单个用户正在执行的操作或有权访问的内容的能力。
• 用户许可证：分析分配给用户的用户许可证（免费、Power BI Pro 或 Power BI Premium Per User (PPU)）非常有用。 此数据可帮助你确定谁未使用其许可证。 它还可以帮助你分析所有用户（具有许可证的不同用户）与活跃用户（近期有活动）。 如果你正在考虑添加或扩展 Power BI Premium 许可证，建议将用户许可证数据与用户活动数据一起分析，以执行成本分析。
• 管理员角色的成员：可以编译 Power BI 管理员列表（其中包含 Power Platform 管理员）。

有关可在 Microsoft Graph 的审核数据中找到的 Power BI 许可证信息的权威参考，请参阅用于许可的产品名称和服务计划标识符。

提示

从组中检索成员可能是获取审核数据最具挑战性的其中一个方面。 需要执行传递搜索以平展所有嵌套成员和嵌套组。 你可以对组成员执行传递搜索。 当组织中有数千个组时，这种类型的搜索尤其具有挑战性。 在这种情况下，可以考虑使用更好的替代方法来检索数据。 一个选项是从 Microsoft Graph 中提取所有组和组成员。 但是，当只有少量组用于 Power BI 安全性时，这可能不切实际。 另一个选项是预构建任何类型的 Power BI 安全性（工作区角色、应用权限、每项分享、行级别安全性等）使用的组的引用列表。 然后，可以循环访问引用列表以从 Microsoft Graph 检索组成员。

你还可能提取并存储以下其他几个属性。

• 用户类型：用户是成员或来宾。 大多数情况下，成员是内部用户，来宾是外部 (B2B) 用户。 需要分析外部用户的活动时，存储用户类型非常有用。
• 角色更改：执行安全审核时，了解用户在组织中的角色何时更改（例如，当他们转到其他部门时）非常有用。 这样，便可以验证其 Power BI 安全设置是否已更新或应该更新。
• 禁用的用户：当用户离开组织时，管理员通常会禁用其帐户。 可以创建一个过来来检查禁用的用户是工作区管理员还是语义模型所有者。

提示

Power BI 活动日志包含一个事件，用于记录用户注册试用许可证的时间。 可以将该事件与用户许可证数据（源自 Microsoft Entra ID）相结合，以全面了解情况。

检索用户和组数据

可以通过不同的方式检索有关用户和组的数据。

方法	说明	手动审核过程的不错选择	自动审核过程的不错选择
手动	Graph 浏览器
编程	Microsoft Graph API 和 SDK
编程	Az PowerShell 模块

本节的其余部分介绍表中显示的每一种技术。 本节末尾介绍了已弃用且不应用于新解决方案的其他技术。

注意

阅读线上信息时要小心，因为许多工具名称相似。 Microsoft 生态系统中的一些工具在其名称中包含术语 Graph，例如 Azure Resource Graph、GraphQL 和 Microsoft Security Graph API。 这些工具与 Microsoft Graph 无关，并且不在本文的讨论范围。

Microsoft Graph Explorer

Microsoft Graph 资源管理器是一种开发人员工具，可用于了解 Microsoft Graph API。 这是一种简单的入门方法，因为它不需要计算机上的其他工具或设置。 可以登录以从租户检索数据，也可以从默认租户检索示例数据。

可以使用 Graph 资源管理器来：

• 手动向 Microsoft Graph API 发送请求，以检查它是否返回所需的信息。
• 了解如何在编写脚本之前构造 URL、标头和正文。
• 以非正式方式检查数据。
• 确定每个 API 需要哪些权限。 还可以为新权限提供同意。
• 获取创建脚本时要使用的代码片段。

使用此链接打开 Graph 资源管理器。

Microsoft Graph API 和 SDK

使用 Microsoft Graph API 检索用户和组数据。 还可以使用它从 Microsoft Entra ID、SharePoint Online、Teams、Exchange、Outlook 等服务检索数据。

Microsoft Graph SDK 充当基础 Microsoft Graph API 上的 API 包装器。 SDK 是将工具和功能捆绑在一起的软件开发工具包。 Microsoft Graph SDK 公开整组 Microsoft Graph API。

可以选择将请求直接发送到 API。 或者，可以使用首选语言和其中一个 SDK 进行简化。 有关详细信息，请参阅本文前面的选择 API 或 PowerShell cmdlet。

Microsoft Graph SDK 支持多种语言，还有 Microsoft Graph PowerShell 模块。 其他 SDK 可用于 Python、C# 和其他语言。

重要

Microsoft Graph PowerShell 模块取代了 Azure AD PowerShell 模块和 MSOnline (MSOL) 模块，这两个模块均已弃用。 不应使用已弃用的模块创建新解决方案。 Microsoft Graph PowerShell 模块具有许多功能和优势。 有关详细信息，请参阅从 Azure AD PowerShell 升级到 Microsoft Graph PowerShell。

可以从 PowerShell 库安装 Microsoft Graph PowerShell 模块。 由于 Microsoft Graph 适用于许多 Microsoft 365 服务，因此需要安装许多 PowerShell 模块。

对于 Power BI 租户级审核，需要安装以下最常见的 PowerShell 模块。

• 身份验证（用于登录）
• 用户
• 组
• 应用程序（和服务主体）
• 目录对象（和许可证详细信息）

提示

Microsoft 会定期更新 Microsoft Graph PowerShell 模块。 有时，预览模块以预发布或 beta 版终结点的形式提供。 你可能希望在安装和更新模块时指定感兴趣的版本。 此外，当你查看线上文档时，请注意当前版本号会自动附加到 URL 的末尾（因此在保存或分享 URL 时要小心）。

Az PowerShell 模块

还可以使用 Az PowerShell 模块来检索用户和组数据。 它侧重于 Azure 资源。

重要

Az PowerShell 模块取代了已弃用的 AzureRM PowerShell 模块。 不应使用已弃用的模块创建新解决方案。

当 API 没有相应的 cmdlet 时，可以使用 Invoke-AzRestMethod cmdlet。 这是一种灵活的方法，让你可以使用 Az PowerShell 模块将请求发送到任何 Microsoft Graph API。

从 Az 版本 7 开始，Az cmdlet 现在引用 Microsoft Graph API。 因此，Az 模块充当 Microsoft Graph 上的 API 包装器。 Az 模块具有 Microsoft Graph API 和 PowerShell 模块中包含的功能子集。 对于新的解决方案，建议使用 Microsoft Graph PowerShell SDK。

弃用的 API 和模块

你可能会发现一些线上文章和博客文章推荐使用本节中未介绍的替代选项。 强烈建议不要使用以下任何 API 或模块创建新解决方案（和/或迁移现有解决方案）。

• AzureRM PowerShell 模块：已弃用，将停用。 它们已被 Az PowerShell 模块所取代。
• Azure AD Graph API 和 Azure AD PowerShell 模块：已弃用，将停用。 此更改是从 Azure AD Graph 迁移到 Microsoft Graph 的结果（请注意，Graph 出现在两个名称中，但 Microsoft Graph 是未来的方向）。 将来的所有 PowerShell 投资都将在 Microsoft Graph PowerShell SDK 中进行。
• MS Online (MSOL) PowerShell 模块：已弃用，将停用。 将来的所有 PowerShell 投资都将在 Microsoft Graph PowerShell SDK 中进行。

注意

请务必确认当前正在使用的任何已弃用 API 或模块的状态。 有关停用 AzureRM 的详细信息，请参阅此公告。

有关 Microsoft Entra ID 和 MSOL 的详细信息，请参阅此停用公告文章。

如果对编程数据访问的未来方向有疑问或需要澄清，请与 Microsoft 客户团队联系。

检查清单 - 计划访问用户和组数据时，关键决策和操作包括：

• 确认要求：阐明编译与用户、组和许可证相关的数据的需求。
• 确定要求的优先级：确认最高优先级是什么，以便知道首先要花时间做什么。
• 确定提取数据的频率：确定需要用户和组数据新快照的频率（例如每周或每月）。
• 确定如何使用 Microsoft Graph 提取数据：确定将用于检索数据的方法。
• 完成概念证明：计划完成小型技术概念证明 (POC) 以提取用户和组数据。 使用它来验证有关如何构建最终解决方案的决策。

从 Power BI REST API 访问数据

也许作为较低优先级，还可以使用 Power BI REST API 检索其他数据。

例如，可以检索有关以下内容的数据：

• 组织中的所有应用。
• 组织中所有已导入的语义模型。
• 组织中的所有部署管道。
• 组织中的所有高级容量。

在安全审核期间，可能需要识别：

• 已与整个组织广泛分享的项。
• 使用发布到 Web 在公共 Internet 上提供的项。

有关其他类型 API 的详细信息，请参阅本文前面的选择用户 API 或管理员 API。

检查清单 - 计划从 Power BI API 访问数据时，关键决策和操作包括：

• 获取要求：在出现分析需求时对其进行编译。 在积压工作中跟踪它们。
• 确定要求的优先级：为出现的新要求设置优先级。

阶段 2：先决条件和设置

计划和实施租户级审核解决方案的第二个阶段侧重于在开始解决方案开发之前必须完成的先决条件和设置。

创建存储帐户

此时，你已确定存储原始数据的位置以及如何创建审编数据。 根据这些决策，现在可以创建存储帐户了。 根据组织的过程，它可能涉及向 IT 提交请求。

如前所述，建议使用允许将原始数据写入不可变存储的技术。 写入数据后，无法更改或删除数据。 然后，你可以对原始数据充满信心，因为你知道具有访问权限的管理员无法以任何方式更改它。 但是，审编数据（通常）不需要存储在不可变存储中。 审编数据可能会更改，也可能重新生成。

检查清单 - 创建存储帐户时，关键决策和操作包括：

• 创建存储帐户：创建或提交用于创建存储帐户的请求。 尽可能对原始数据使用不可变存储设置。
• 设置权限：确定应为存储帐户设置哪些权限。
• 测试访问：执行小型测试，确保可以读取和写入存储帐户。
• 确认责任：确保清楚谁将持续管理存储帐户。

安装软件和设置服务

此时，你已确定用于访问审核数据的技术。 根据这些决策，现在可以安装软件和设置服务了。

为每个管理员设置首选开发环境。 开发环境将允许他们编写和测试脚本。 Visual Studio Code 是用于开发脚本的新式工具，因此它是一个不错的选择。 此外，许多扩展都可用于 Visual Studio Code。

如果你已确定（前面介绍）使用 PowerShell，则应在以下位置安装 PowerShell Core 和必要的 PowerShell 模块：

• 将编写或测试审核脚本的每个管理员/开发人员的计算机。
• 将运行计划脚本的每个虚拟机或服务器。
• 每个联机服务（例如 Azure Functions 或 Azure 自动化）。

如果已选择使用任何 Azure 服务（例如 Azure Functions、Azure 自动化、Azure 数据工厂或 Azure Synapse Analytics），则还应预配和设置它们。

检查清单 - 安装软件和设置服务时，关键决策和操作包括：

• 设置管理员/开发人员计算机：如果适用，请安装将用于开发的必要工具。
• 设置服务器：如果适用，请在体系结构中存在的任何服务器或虚拟机上安装必要的工具。
• 设置 Azure 服务：如果适用，请预配和设置每个 Azure 服务。 为每个将执行开发工作的管理员/开发人员分配权限。

注册 Microsoft Entra 应用

此时，你已确定如何进行身份验证。 建议注册 Microsoft Entra 应用程序（服务主体）。 它通常称为“应用注册”，应该用于你将实施自动化的无人参与操作。

有关如何创建应用注册以检索租户级审核数据的详细信息，请参阅为只读管理员 API 启用服务主体身份验证。

检查清单 - 注册 Microsoft Entra 应用程序时，关键决策和操作包括：

• 检查是否存在现有应用注册：与 IT 部门核实现有应用注册是否可用于运行管理 员API。 如果是这样，请确定是否应使用现有应用注册，或者是否应创建一个新应用注册。
• 创建新的应用注册：适当时创建应用注册。 请考虑使用诸如 PowerBI-AdminAPIs-EntraApp 等应用名称，该名称清楚地描述了其用途。
• 为应用注册创建机密：应用注册存在后，为其创建机密。 根据轮换机密的频率设置过期日期。
• 安全地保存值：存储机密、应用 ID（客户端 ID）和租户 ID，因为需要它们来向服务主体进行身份验证。 使用安全的位置，例如组织密码保管库。 （如果需要向 IT 请求创建应用注册，请指定需要将这些值返回给你。）
• 创建安全组：创建（或请求）将用于 Power BI 的安全组。 请考虑使用组名称，例如 Power BI 管理员服务主体，这表示该组将用于访问租户范围的元数据。
• 将服务主体添加为安全组的成员：使用应用 ID（客户端 ID）将新的（或现有的）服务主体添加为新安全组的成员。
• 更新 Power BI 中的管理员 API 租户设置：在 Power BI 管理门户中，将安全组添加到“允许服务主体使用只读 Power BI 管理员 API”租户设置。
• 跳过在 Azure 中分配权限：不向应用注册委派任何权限（它将通过 Power BI“允许服务主体使用只读 Power BI 管理员 API”租户设置来访问 Power BI 租户级审核数据）。
• 确定应用注册是否应访问详细的元数据：确定在构建租户清单时是否要提取有关语义模型表、列和度量值表达式的详细信息。
• 在 Power BI 中更新详细的元数据租户设置：（可选）在 Power BI 管理门户中，将安全组添加到“使用详细元数据增强管理员 API 响应”租户设置，以及“使用 DAX 和混合表达式增强管理员 API 响应”租户设置。
• 测试服务主体：创建一个简单的脚本以使用服务主体登录，并测试它是否可以从管理 API 检索数据。
• 创建管理应用注册机密的过程：创建文档和定期轮换机密的过程。 确定如何安全地将新机密传达给需要它的任何管理员和开发人员。

设置 Power BI 租户设置

Power BI 管理门户中有多个与提取租户级审核数据相关的租户设置。

管理员 API

有三个租户设置与运行管理员 API 相关。

重要

由于这些设置授予整个租户的元数据访问权限（不分配直接 Power BI 权限），因此应严格控制它们。

“允许服务主体使用只读 Power BI 管理员 API”租户设置可以设置哪些服务主体可以调用管理员 API。 此设置还使 Microsoft Purview 能够扫描整个 Power BI 租户，以便填充数据目录。

注意

无需将其他 Power BI 管理员显式分配到“允许服务主体使用只读 Power BI 管理员 API”租户设置，因为他们已有权访问租户范围的元数据。

“使用详细元数据增强管理员 API 响应”租户设置可以设置哪些用户和服务主体可以检索详细元数据。 元数据是使用元数据扫描 API 检索的，其中包括表、列等。 此设置还使 Microsoft Purview 能够访问有关 Power BI 语义模型的架构级信息，以便将其存储在数据目录中。

“使用 DAX 和混合表达式增强管理员 API 响应”租户设置可以设置哪些用户和服务主体可以检索详细元数据。 元数据是从元数据扫描 API 检索的，可以包括查询和语义模型度量值表达式。

注意

“允许服务主体使用只读 Power BI 管理员 API”租户设置专门处理管理员 API 的访问。 其名称与用于访问用户 API 的租户设置非常相似（下面介绍）。 有关管理员 API 和用户 API 之间区别的详细信息，请参阅本文前面的选择用户 API 或管理员 API。

用户 API

有一个租户设置适用于调用用户 API。 在这种情况下，服务主体（例如工作区角色）还需要 Power BI 权限。

“允许服务主体使用 Power BI API”租户设置可以设置哪些服务主体有权运行 REST API（不包括由上面介绍的其他租户设置授予的管理员 API）。

还有其他与 API 相关的租户设置，这些设置允许访问嵌入 API、流式处理 API、导出 API 和执行查询 API。 但是，这些 API 不在本文的讨论范围。

有关使用指标的租户设置的详细信息，请参阅报表级审核。

检查清单 - 设置 Power BI 租户设置时，关键决策和操作包括：

• 验证每个服务主体是否在正确的组中：确认“Power BI 管理员服务主体”组包含正确的服务主体。
• 更新 Power BI 中的管理员 API 租户设置：将安全组添加到 “允许服务主体使用只读 Power BI 管理员 API”租户设置，该设置允许使用管理员 API 来检索租户范围的元数据。
• 更新 Power BI 中的详细元数据租户设置：，将安全组添加到“使用详细元数据增强管理员 API 响应”租户设置，以及“使用 DAX 和混合表达式增强管理员 API 响应”租户设置。
• 确认将访问哪些用户 API：验证是否需要一个或多个用户 API（此外，还要使用管理员 API）。
• 更新 Power BI 中的用户 API 租户设置：将安全组添加到 “允许服务主体使用 Power BI API”租户设置，该设置适用于用户 API。

阶段 3：解决方案开发和分析

计划和实施租户级审核解决方案的第三个阶段侧重于解决方案开发和分析。 此时，所有计划和决策都已完成，而且你已满足先决条件并完成了设置。 现在可以开始开发解决方案，以便执行分析并从审核数据中获取见解。

提取和存储原始数据

此时，你的要求和优先级应该明确。 已就如何访问审核数据和存储审核数据的位置做出了关键技术决策。 已选择首选工具，并已设置先决条件和设置。 在前两个阶段中，你可能已完成一个或多个小型项目（概念证明）以证明可行性。 下一步是设置一个过程来提取和存储原始审核数据。

与大多数 Microsoft API 返回的数据一样，审核数据的格式设置为 JSON。 JSON 格式的数据是自描述的，因为它是包含结构和数据的可读文本。

JSON 表示由特性值对和数组组成的数据对象。 例如，"state": "Active" 是 state 属性值为 Active 的示例。 JSON 数组包含用逗号分隔且括在方括号 ([ ]) 内的有序元素列表。 在 JSON 结果中找到嵌套数组是很常见的。 熟悉 JSON 结果的层次结构后，就可以直接理解数据结构，例如工作区中的语义模型列表（数组）。

提取和存储从 API 检索到的原始数据时需要注意以下事项。

• 将使用什么命名约定？ 对于基于文件的系统，文件、文件夹和数据湖区域需要命名约定。 对于数据库，表和列需要命名约定。
• 将使用哪种格式来存储原始数据？ 随着 Power BI 继续引入新功能，将出现目前不存在的新活动。 因此，建议提取并保留原始 JSON 结果。 提取数据时，请勿分析、筛选数据或设置数据格式。 这样，就可以使用最初的原始数据重新生成审编审核数据。
• 将使用什么存储位置？ 数据湖或 blob 存储通常用于存储原始数据。 有关详细信息，请参阅本文前面的确定存储审核数据的位置。
• 将存储多少历史记录？ 将审核数据导出到可以存储历史记录的位置。 计划积累至少两年的历史记录。 这样，就可以分析超过默认 30 天保留期的趋势和更改。 可以选择无限期存储数据，也可以确定较短的期限，具体取决于组织的数据保留策略。
• 如何跟踪过程上次运行的时间？ 设置配置文件或等效文件，以记录过程开始和完成时的时间戳。 下一次运行过程时，它可以检索这些时间戳。 使用元数据扫描 API 提取数据时存储时间戳尤其重要。
• 如何处理限制？ 某些 Power BI REST API 和 Microsoft Graph API 实施了限制。 如果 API 请求受到限制，则会收到 429 错误（请求过多）。 对于需要检索大量数据的大型组织来说，限制可能是一个常见问题。 如何避免因限制而失败的尝试取决于用于访问和提取数据的技术。 一种选择是在脚本中开发逻辑，通过在等待一段时间后重试来响应 429“请求过多”错误。
• 合规性是否需要审核数据？ 许多组织使用原始审核日志记录来执行合规性审核或响应安全调查。 在这些情况下，强烈建议将原始数据存储在不可变存储中。 这样，一旦写入数据，管理员或其他用户就不能更改或删除数据。
• 需要哪些存储层才能满足你的要求？ 存储原始数据的最佳位置是数据湖（如 Azure Data Lake Storage Gen2）或对象存储（如 Azure Blob 存储）。 如果云服务不是选项，也可以使用文件系统。

检查清单 - 提取和存储原始数据时，关键决策和操作包括：

• 确认要求和优先级：阐明要首先提取的数据的要求和优先级。
• 确认要提取的数据源：验证所需的每种数据类型的源。
• 设置一个提取数据并将其加载到原始数据区域的过程：创建初始过程以提取和加载原始状态的原始数据，而不进行任何转换。 测试该过程是否正常工作。
• 创建运行过程的计划：设置定期计划以运行提取、加载和转换过程。
• 验证凭据是否得到安全管理：确认以安全的方式存储和传达密码、机密和密钥。
• 确认安全性设置正确：验证是否为原始数据正确设置了访问权限。 确保管理员和审核员可以访问原始数据。

有关审核和监视解决方案如何随时间而增长的详细信息，请参阅本文后面的实施和改进。

创建审编数据

此时，将提取并存储原始数据。 下一步是为审编数据创建单独的金牌数据层。 其目标是转换数据文件并将其存储在星型架构中。 星型架构由维度表和事实数据表组成，并有意针对分析和报告进行了优化。 审编数据层中的文件将成为 Power BI 数据模型的源（下一主题介绍）。

提示

当预计存在多个数据模型时，投资集中审编数据层特别有用。

检查清单 - 创建审编数据层时，关键决策和操作包括：

• 确认要求和优先级：如果打算对转换的数据使用中间银牌数据层，请阐明需要完成的任务的要求和目标。
• 设置一个转换原始数据并将其加载到审编数据区域的过程：创建一个过程以转换数据并将其加载到星型架构中。 测试该过程是否正常工作。
• 创建运行过程的计划：设置定期计划以填充审编数据层。
• 确认安全性设置正确：验证是否为审编数据正确设置了访问权限。 确保数据模型的开发人员可以访问审编数据。

创建数据模型

本主题介绍如何设置分析数据模型。 数据模型是针对分析进行优化的可查询数据资源。 有时，它称为“语义模型”，或简称为“模型”。 对于审核和监视解决方案，数据模型可能会作为 Power BI 语义模型实施。

在审核和监视的上下文中，数据模型从审编（金牌）数据层获取数据。 如果选择不创建审编数据层，则数据模型会直接从原始数据中获取数据。

建议 Power BI 数据模型实施星型架构设计。 当源数据是审编数据层时，Power BI 数据模型星型架构应镜像审编数据层星型架构。

提示

有关星型架构设计的概述，请参阅了解星型架构和 Power BI 的重要性。

与任何 Power BI 项目一样，创建数据模型是一个迭代过程。 可以根据需要添加新度量值。 还可以在新的审核事件可用时添加新表和列。 随着时间的推移，甚至可以集成新的数据源。

你可以在数据模型中包含以下有用的维度表。

• 日期：一组日期属性，用于按天、周、月、季度、年和其他相关时间段分析（切片和切块）。
• 时间：如果需要按一天中的时间进行分析，并且有大量的审核数据，请考虑将时间部分与日期分开存储。 此方法有助于提高查询性能。
• 用户：描述用户的属性（如部门和地理区域），可以筛选审核数据的许多主题。 目标是从事实数据表中删除所有用户详细信息，并将其存储在此维度表中，以便他们可以筛选多个事实数据表。 还可以在此表中存储服务主体。
• 活动事件：对活动事件（操作）进行分组和描述的属性。 若要增强报告功能，可以创建一个描述每个活动事件的数据字典。 还可以创建一个层次结构，用于对类似的活动事件进行分组和分类。 例如，可以对所有项创建事件、删除事件等进行分组。
• 工作区：租户和工作区属性中的工作区列表，例如类型（个人或标准）和描述。 某些组织记录了有关工作区的更多详细信息（可能使用 SharePoint 列表）。 可以将这些详细信息整合到此维度表中。 需要确定此维度表是仅存储工作区的当前状态，还是存储反映一段时间内工作区重大更改的版本控制数据。 例如，当工作区名称更改时，历史报告是显示当前工作区名称还是那时的当前工作区名称？ 有关版本控制的详细信息，请参阅缓慢更改维度。
• 项类型：Power BI 项类型（语义模型、报表等）的列表。
• 容量：租户中的高级容量列表。
• 网关：租户中的数据网关列表。
• 数据源：任何语义模型、数据流或数据市场使用的数据源列表。

你可以在数据模型中包含以下有用的事实数据表（主题）。

• 用户活动：源自原始 JSON 数据的事实数据。 将删除没有分析值的任何属性。 属于维度表（上面介绍）的任何属性也会被删除。
• 租户清单：租户中发布的所有项的时间点快照。 有关详细信息，请参阅本文前面的租户清单。
• 语义模型：包括涉及语义模型（如语义模型更改）或相关数据源的用户活动。
• 语义模型刷新：存储数据刷新操作，包括有关类型（计划或按需）、持续时间、状态以及启动操作的用户的详细信息。
• 工作区角色：工作区角色分配的时间点快照。
• 用户许可证：用户许可证的时间点快照。 虽然你可能想将用户许可证存储在“用户”维度表中，但这种方法不支持分析许可证随时间推移的变化和趋势。
• 用户组成员身份：分配给安全组的用户（和服务主体）的时间点快照。
• 社区活动：包括与社区相关的事实，例如培训活动。 例如，可以根据培训出席情况分析 Power BI 用户活动。 这些数据可以帮助卓越中心确定潜在的新精英。

事实数据表不应包含报表创建者将筛选的列。 相反，这些列属于相关的维度表。 这种设计不仅对查询更有效，而且还通过多个事实（称为“向下钻取”）促进维度表的重用。 最后一点对于生成有用且用户友好的数据模型非常重要，这种模型在添加新的事实数据表（主题）时可扩展。

例如，“用户”维度表将与每个事实数据表相关。 它应与“用户活动”事实数据表（执行活动的人员）、“租户清单”事实数据表（已发布项目的创建者）和所有其他事实数据表相关。 当报表在“用户”维度表中按用户进行筛选时，该报表中的视觉对象可以显示任何相关事实数据表中该用户的事实。

设计模型时，请确保属性在模型中可见一次，且仅可见一次。 例如，用户电子邮件地址应仅在“用户”维度表中可见。 它也将存在于其他事实数据表中（作为支持模型关系的维度键）。 但是，应在每个事实数据表中隐藏它。

建议创建独立于报表的数据模型。 语义模型及其报表的分离会产生一个集中语义模型，该语义模型可以为许多报表提供服务。 有关使用共享语义模型的详细信息，请参阅托管自助 BI 使用方案。

考虑设置行级别安全性 (RLS)，以便卓越中心、审核员和管理员以外的其他用户可以分析和报告审核数据。 例如，可以使用 RLS 规则来允许内容创建者和使用者报告他们自己的用户活动或开发工作。

检查清单 - 创建数据模型时，关键决策和操作包括：

• 计划和创建数据模型：将数据模型设计为星型架构。 验证关系是否正常工作。 开发模型时，以迭代方式创建度量值并根据分析要求添加其他数据。 必要时，包括积压工作的未来改进。
• 设置 RLS：如果打算使数据模型可供其他常规用户使用，请设置行级别安全性以限制数据访问。 验证 RLS 角色是否返回正确的数据。

增强数据模型

若要有效地分析内容使用情况和用户活动，建议扩充数据模型。 当你发现机会和新要求时，可以逐渐和迭代地完成数据模型增强。

创建分类

增强模型和增加数据价值的一种方法是向数据模型添加分类。 确保报表一致地使用这些分类。

可以选择根据用户的使用级别对用户进行分类，或者根据内容的使用级别对内容进行分类。

用户使用情况分类

考虑以下“用户使用情况”分类。

• 频繁用户：上周以及过去 12 个月中有 9 个月记录了活动。
• 活跃用户：过去 1 个月记录了活动。
• 偶尔用户：过去 9 个月记录了活动，但过去 1 个月没有记录活动。
• 非活跃用户：过去 9 个月没有记录任何活动。

提示

了解偶尔或非活跃用户是谁很有帮助，尤其是当他们拥有 Pro 或 PPU 许可证（涉及费用）时。 了解频繁和最活跃的用户也很有帮助。 考虑邀请他们加入办公时间或参加培训。 最活跃的内容创建者可能是加入精英网络的候选人。

内容使用情况分类

考虑以下“内容使用情况”分类。

• 频繁使用的内容：上周以及过去 12 个月中有 9 个月记录了活动。
• 活跃使用的内容：过去 1 个月记录了活动。
• 偶尔使用的内容：过去 9 个月记录了活动，但过去 1 个月内没有记录活动。
• 未使用的内容：过去 9 个月未记录任何活动。

用户类型分类

考虑以下“用户类型”分类。

• 内容创建者：过去 6 个月记录了创建、发布或编辑内容的活动。
• 内容查看者：过去 6 个月记录了查看内容的活动，但未记录任何内容创建活动。

考虑时效性与趋势

应确定用户或内容的使用情况分类是否应仅基于活动最近发生的时间。 可能还需要考虑一段时间内的平均或趋势使用情况。

考虑一些示例，这些示例演示了简单的分类逻辑可能如何歪曲现实。

• 本周，一位经理查看了一份报表。 然而，在这周之前，这位经理在过去 6 个月没有查看过任何报表。 不应仅根据最近使用情况将此经理视为频繁用户。
• 报表创建者每周发布一个新报表。 分析频繁用户的使用情况时，报表创建者的常规活动看起来是积极的。 但是，经过进一步调查，你会发现此用户每次编辑报表时都会重新发布新报表（使用新的报表名称）。 对于报表创建者来说，接受更多培训会很有用。
• 高管偶尔查看报表，因此其使用情况分类经常更改。 可能需要以不同的方式分析某些类型的用户，例如高管。
• 内部审核员每年查看一次关键报表。 内部审核员可能看起来是非活跃用户，因为他们不经常使用。 有人可能会采取措施删除其 Pro 或 PPU 许可证。 或者，有人可能认为报表应该停用，因为它不经常使用。

提示

可以使用 DAX 时间智能函数计算平均值和趋势。 若要了解如何使用这些函数，请完成在 Power BI Desktop 模型中使用 DAX 时间智能函数学习模块。

检查清单 - 创建分类使用情况数据时，关键决策和操作包括：

• 就分类定义达成共识：与相关利益干系人讨论分类定义。 在做出决策时，请确保达成一致。
• 创建文档：确保分类定义包含在内容创建者和使用者的文档中。
• 创建反馈循环：确保用户可以通过某种方式提出问题或对分类定义提出更改。

创建分析报表

此时，已提取和存储审核数据，并且你已发布数据模型。 下一步是创建分析报表。

专注于与每个受众最相关的关键信息。 审核报表可能有多个受众。 每个受众都会对不同的信息感兴趣，并且出于不同的目的而感兴趣。 可以通过报表服务的受众包括：

• 执行发起人
• 卓越中心
• Power BI 管理员
• 工作区管理员
• 高级容量管理员
• 网关管理员
• Power BI 开发人员和内容创建者
• 审核人员

创建审核报告时可能需要从以下最常见的分析要求开始。

• 热门内容视图：你的执行发起人和领导团队可能主要对摘要信息和随时间变化的趋势感兴趣。 工作区管理员、开发人员和内容创建者对详细信息更感兴趣。
• 热门用户活动：卓越中心将对谁在使用 Power BI、如何以及何时使用感兴趣。 高级容量管理员将对谁在使用容量来确保其运行状况和稳定性感兴趣。
• 租户清单：Power BI 管理员、工作区管理员和审核员将有兴趣了解存在的内容、位置、世系及其安全设置。

此列表并不包含全部信息。 它旨在为你提供有关如何创建针对特定需求的分析报表的想法。 有关更多注意事项，请参阅本文前面的数据需求以及审核和监视概述。 这些资源包含有关如何使用审核数据的许多想法，以及可能选择在报表中显示的信息类型。

提示

虽然呈现大量数据很诱人，但只包含你准备执行操作的信息。 确保每个报表页都明确其用途、应执行的操作以及由谁执行。

若要了解如何创建分析报表，请完成在 Power BI 中设计有效报表学习路径。

检查清单 - 计划分析审核报表时，关键决策和操作包括：

• 查看要求：根据已知需求和应回答的特定问题确定创建报表的优先级。
• 确认受众：谁将使用审核报告，以及其预期用途。
• 创建和部署报表：开发第一组核心报表。 随着时间的推移，逐渐扩展和增强它们。
• 在应用中分发报表：考虑创建一个包含所有审核和监视报表的应用。
• 验证谁有权访问报表：确保报表（或应用）提供给正确的一组用户。
• 创建反馈循环：确保报表使用者可以通过某种方式提供反馈、建议或报告问题。

根据数据执行操作

审核数据很有价值，因为它可以帮助你了解 Power BI 租户中发生的情况。 虽然这看起来很明显，但根据你从审核数据中学到的内容明确执行操作很容易被忽略。 因此，建议你指派负责跟踪可衡量改进的人员，而不仅仅是查看审核报表。 这样，你可以使用 Power BI 在采用和成熟度级别方面逐步取得可衡量的进步。

可以根据目标和从审核数据中学到的内容执行许多不同的操作。 本节的其余部分提供了几个想法。

内容使用情况

你可能根据内容的使用方式执行以下操作。

• 经常（每天或每周）使用内容：验证任何关键内容是否经过认证。 确认所有权明确，并且解决方案得到充分支持。
• 大量工作区查看：出现大量工作区查看时，请调查未使用 Power BI 应用的原因。
• 很少使用内容：联系目标用户，确定解决方案是否满足他们的需求，或者他们的要求是否已更改。
• 刷新活动的发生频率高于查看：联系内容所有者，了解定期刷新语义模型而不使用语义模型或相关报表的原因。

用户活动

你可能根据用户活动执行以下操作。

• 新用户的第一次发布操作：确定用户类型何时从使用者更改为创建者，你可以在他们首次发布内容时确定。 这是向他们发送标准电子邮件的绝佳机会，该电子邮件提供指导和指向有用资源的链接。
• 与最频繁的内容创建者互动：邀请最活跃的创作者加入精英网络，或参与实践社区。
• 许可证管理：验证非活跃创建者是否仍需要 Pro 或 PPU 许可证。
• 用户试用版激活：试用许可证激活可能会提示你在试用期结束之前向用户分配永久许可证。

用户培训机会

你可能从审核数据中识别以下用户机会。

• 同一内容创建者发布大量语义模型：教用户有关共享语义模型的信息以及避免创建重复语义模型的重要性。
• 从个人工作区过度共享：联系从其个人工作区进行大量共享的用户。 教他们有关标准工作区的信息。
• 个人工作区存在大量报表查看：联系拥有大量报表查看的内容的用户。 教他们标准工作区如何优于个人工作区。

提示

还可以通过查看内部 Power BI 社区回答的问题以及提交给技术支持的问题来改进培训内容或文档。

安全性

你可能需要主动监视以下安全情况。

• 分配给高特权 Fabric 管理员角色的用户过多。
• 工作区管理员过多（而成员、参与者或查看者工作区角色就已足够）。
• 分配给语义模型的生成权限过多（而读取权限就已足够）。
• 高度使用每项权限（而 Power BI 应用权限或工作区查看者角色才是内容使用者的更好选择）。
• 如何与外部用户共享内容。

有关详细信息，请参阅安全性计划文章。

治理和风险缓解

你可能会遇到以下情况。 考虑在审核报告中明确查找这些类型的情况，以便准备好快速执行操作。

• 报表（和基础语义模型）的大量查看不受认可。
• 大量使用未知或未经批准的数据源。
• 文件位置不符合源文件应位于何处的治理指南要求。
• 工作区名称不符合治理要求。
• 敏感度标签用于信息保护。
• 一致数据刷新失败。
• 大量和重复使用打印。
• 意外或过度使用订阅。
• 意外使用个人网关。

每种情况下要采取的具体操作将取决于治理策略。 有关详细信息，请参阅 Fabric 采用路线图中的治理。

检查清单 - 根据审核数据计划潜在操作时，关键决策和操作包括：

• 明确期望：创建审核报表，其中包含一组对预期操作的明确期望。
• 明确谁将负责操作：确保已分配角色和职责。
• 创建自动化：尽可能自动执行可重复的已知操作。
• 使用跟踪系统：使用系统跟踪观察到的情况，包括联系、下一步计划的操作、负责人、解决方案和状态。

阶段 4：维护、增强和监视

计划和实施租户级审核解决方案的第四个阶段侧重于维护、增强和监视。 此时，审核解决方案正在生产环境中使用。 你现在主要关注维护、增强和监视解决方案。

实施和改进

初始开发和测试完成后，审核过程通常被视为在生产环境中运行，并且你已将该过程自动化。 生产环境中运行的自动审核过程对质量、可靠性、稳定性和支持有更高的期望（与手动过程相比）。

生产级审核过程已实施。 已实施的解决方案通常包含以下许多特征。

• 安全：凭据得到安全存储和管理。 脚本不包含纯文本形式的密码或密钥。
• 计划：可靠的计划系统已到位。
• 变更管理：使用变更管理做法和多个环境来确保生产环境受到保护。 还可以使用开发和测试环境，或者仅使用开发环境。
• 支持：明确定义支持解决方案的团队。 团队成员经过培训，他们了解运营期望。 已确定后补成员，并在适当时进行交叉培训。
• 警报：出现问题时，警报会自动通知支持团队。 警报最好包括日志和电子邮件（而不仅仅是电子邮件）。 日志可用于分析记录的错误和警告。
• 日志记录：记录过程，以便有审核数据更新时间的历史记录。 记录的信息应记录开始时间、结束时间和运行该过程的用户或应用的标识。
• 错误处理：脚本和过程可以正常处理和记录错误（例如是立即退出、继续还是等待并重试）。 发生错误时，会向支持团队发送警报通知。
• 编码标准：使用性能良好的良好编码技术。 例如，有意避免循环，除非必要。 使用一致的编码标准、注释、格式和语法，使解决方案更易于维护和支持。
• 重用和模块化：为了最大程度地减少重复，代码和配置值（如连接字符串或通知的电子邮件地址）是模块化的，以便其他脚本和过程可以重用它们。

提示

你不必一次完成上面列出的所有操作。 随着经验的积累，可以逐步改进解决方案，使其变得完整和可靠。 请注意，你在线上找到的大多数示例都是简单的一次性脚本片段，可能不是生产质量。

检查清单 - 计划实施和改进审核解决方案时，关键决策和操作包括：

• 评估现有解决方案的级别：确定是否有机会改进和稳定现有的自动审核解决方案。
• 确立生产级标准：确定你希望自动审核过程采用哪些标准。 考虑可以随着时间推移而实际添加的改进。
• 创建改进计划：计划提高生产审核解决方案的质量和稳定性。
• 确定是否需要单独的开发环境：评估风险级别和对生产数据的依赖程度。 确定何时创建单独的开发和生产（以及测试）环境。
• 考虑数据保留策略：确定是否需要实施数据保留过程，以便在一段时间后或根据请求清除数据。

文档和支持

文档和支持对任何生产级解决方案都至关重要。 根据目标受众和用途创建多种类型的文档很有帮助。

技术文档

技术文档面向构建解决方案的技术团队，他们将随着时间的推移逐步改进和扩展解决方案。 对于支持团队来说，这也是一个有用的资源。

技术文档应包含：

• 体系结构组件和先决条件的摘要。
• 谁拥有和管理解决方案。
• 谁支持解决方案。
• 体系结构图。
• 设计决策，包括目标、做出某些技术选择的原因以及约束（如成本或技能）。
• 安全决策和选择。
• 使用的命名约定。
• 编码和技术标准与指南。
• 变更管理要求。
• 部署、设置和安装说明。
• 已知的技术债务领域（如果有机会，可以改进的领域）。

支持文档

根据审核解决方案的关键级别，如果出现紧急问题，你可能需要技术支持或支持团队。 它们可能全天可用。

支持文档有时称为“知识库”或 runbook。 此文档面向技术支持或支持团队，应包含：

• 出现问题时的疑难解答指南。 例如，当数据刷新失败时。
• 要持续执行的操作。 例如，可能需要定期执行一些手动步骤，直到问题得到解决。

内容创建者文档

通过向整个组织中的其他团队提供使用情况和采用情况分析（如有必要，强制实施行级别安全性），可以从审核解决方案中获得更多价值。

内容创建者文档面向自助内容创建者，他们创建用于获取审编审核数据的报表和数据模型。 它包含有关数据模型的信息，包括通用数据定义。

检查清单 - 计划审核解决方案的文档和支持时，关键决策和操作包括：

• 确认应由谁支持解决方案：确定谁将支持被视为生产级（或具有下游报表依赖）的审核解决方案。
• 确保支持团队就绪：验证支持团队是否已准备好支持审核解决方案。 确定是否存在任何需要解决的就绪差距。
• 安排交叉培训：为支持团队安排知识传授课程或交叉培训课程。
• 明确支持团队的期望：确保明确记录和传达对响应和解决方案的期望。 确定是否需要有人随叫随到，以快速解决与审核解决方案相关的问题。
• 创建技术文档：创建有关技术体系结构和设计决策的文档。
• 创建支持文档：更新技术支持知识库，以包含有关如何支持解决方案的信息。
• 为内容创建者创建文档：创建文档以帮助自助创建者使用数据模型。 描述通用数据定义以提高其使用的一致性。

启用警报

你可能希望根据审核数据中的特定条件引发警报。 例如，当有人删除网关或 Power BI 管理员更改租户设置时，你可以引发警报。

有关详细信息，请参阅租户级监视。

持续管理

需要对整个审核解决方案执行持续管理。 在以下情况下，可能需要扩展或更改审核解决方案：

• 组织发现新的数据要求。
• 新的审核事件出现在来自 Power BI REST API 的原始数据中。
• Microsoft 对 Power BI REST API 进行更改。
• 员工找到改进解决方案的方法。

重要

中断性更改很少见，但可能会发生。 请务必有可用的人员，他们可以在必要时快速解决问题或更新审核解决方案。

检查清单 - 计划审核解决方案的持续管理时，关键决策和操作包括：

• 分配技术所有者：确保整个审核解决方案有明确的所有权和责任。
• 验证存在后补：确保有后补技术所有者，如果出现支持人员无法解决的紧急问题，他可以参与其中。
• 保留跟踪系统：确保有办法捕获新请求，并有办法确定近期优先级以及短期、中期和长期（积压工作）优先级。

相关内容

在本系列的下一篇文章中，了解租户级监视。