总结： Power BI 是 Microsoft一种联机软件服务（SaaS 或软件即服务）产品/服务，可让你轻松快速地创建自助服务商业智能仪表板、报表、语义模型和可视化效果。 借助 Power BI，可以连接到许多不同的数据源，合并和调整这些连接中的数据，然后创建可与其他人共享的报表和仪表板。
作家： 伊扎克·凯塞尔曼、帕迪·奥斯本、马特·尼利、托尼·本契奇、斯里尼瓦桑·图鲁韦克雷、克里斯蒂安·佩库雷斯库、阿迪·雷杰夫、纳文·西瓦拉杰、本·格拉斯坦、埃夫根尼·齐奥尼、阿蒂·拉马苏布拉马尼亚·伊耶， 西德·贾亚德万、罗纳德·张、奥里·埃杜尔、安东·弗里茨、伊丹·希恩伯格、罗恩·吉拉德、萨吉夫·哈达亚、保罗·因巴尔、伊戈尔·乌日维耶夫、迈克尔·罗斯、海梅·塔基诺、根纳迪·帕茨、奥里·李、尤里·贝雷赞斯基、玛雅·申哈夫、罗米·查托帕德亚伊、亚里夫·迈蒙、 Bogdan Crivat
技术审阅者： 克里斯蒂安·佩库雷斯库、阿米尔·内茨、谢尔盖·冈多罗夫
适用于： Power BI SaaS、Power BI Desktop、Power BI Premium、Power BI Embedded Analytics、Power BI Mobile。
注释
可以通过从浏览器选择“ 打印 ”，然后选择“ 另存为 PDF”来保存或打印此白皮书。
介绍
Power BI 是一种联机软件服务（SaaS 或软件即服务）Microsoft 产品/服务，可让你轻松快速地创建自助式商业智能仪表板、报表、语义模型和可视化效果。 借助 Power BI，可以连接到许多不同的数据源，合并和调整这些连接中的数据，然后创建可与其他人共享的报表和仪表板。
世界正在迅速变化：组织正在经历加速的数字化转型，我们看到远程工作大幅增长，对在线服务的需求增加，以及运营和商业决策中的先进技术的使用增加。 所有这些都由云提供支持。
随着向云的转移从涓涓细流变成洪水，伴随而来的新的暴露面，更多公司都在询问 我的数据在云中究竟有多安全？ 以及 有哪些端到端保护措施可以防止敏感数据泄露？ 对于经常处理企业中一些最战略信息的 BI 平台，这些问题至关重要。
BI 安全模型（对象级和行级安全性）的几十年基础，虽然仍然很重要，但显然不再足以提供云时代所需的安全类型。 相反，组织必须为其商业智能数据寻找云原生多层深层防御安全解决方案。
Power BI 旨在为数据提供行业领先的全面和严密保护。 该产品获得了行业内所能达到的最高安全分类，如今，许多国家安全机构、金融机构和医疗卫生服务提供商都信任该产品用于保护其最敏感的信息。
这一切都从基础开始。 在2000年代初经历了一段艰难时期之后，Microsoft进行了大量投资来解决其安全漏洞问题，在接下来的几十年里，它构建了一个强大的安全堆栈，其深度与计算机芯片上的 bios 内核一样深入，并一路扩展到最终用户体验。 这些深度投资仍在继续，如今，超过3,500名Microsoft工程师致力于构建和增强Microsoft的安全堆栈，并积极应对不断变化的威胁格局。 由于数十亿台计算机、数万亿次登录名和无数的信息委托Microsoft的保护，该公司现在拥有技术行业最先进的安全堆栈，并被广泛视为打击恶意参与者的全球领导者。
Power BI 基于这一强大基础。 它使用相同的安全堆栈，使 Azure 有权提供和保护世界上最敏感的数据，并与 Microsoft 365 的最先进的信息保护和合规性工具集成。 最重要的是，它通过多层安全措施提供安全性，从而提供端到端保护，旨在应对云时代的独特挑战。
为了提供用于保护敏感资产的端到端解决方案，产品团队需要解决多个同时出现的具有挑战性的客户问题：
- 如何控制谁可以连接、连接位置以及连接方式？如何控制连接？
- 数据的存储方式是什么？它是如何加密的？我对数据有哪些控制措施？
- 如何控制和保护敏感数据？如何确保此数据无法在组织外部泄露？
- 如何审核谁执行了哪些作？如果服务存在可疑活动，如何快速做出反应？
本文提供了所有这些问题的综合答案。 它从服务体系结构的概述开始，并说明了系统的主要流的工作原理。 然后，它会继续介绍用户如何向 Power BI 进行身份验证、如何建立数据连接，以及 Power BI 如何存储数据并通过服务移动数据。 最后一部分讨论了允许你作为服务管理员保护最有价值的资产的安全功能。
Power BI 服务受 Microsoft在线服务条款和 Microsoft企业隐私声明的约束。 有关数据处理的位置，请参阅 Microsoft联机服务条款 和 数据保护附录中的数据处理条款位置。 对于符合性信息， Microsoft信任中心 是 Power BI 的主要资源。 Power BI 团队正在努力为客户提供最新的创新和工作效率。 详细了解 Microsoft合规性产品/服务中的合规性。
Power BI 服务遵循安全开发生命周期（SDL），严格的安全做法，支持安全保证和符合性要求。 SDL 通过减少软件中漏洞的数量和严重性，帮助开发人员构建更安全的软件，同时降低开发成本。 有关详细信息，请参阅 Microsoft安全开发生命周期实践。
Power BI 体系结构
Power BI 服务基于 Azure（Microsoft的 云计算平台）构建。 Power BI 目前在全球许多数据中心进行部署；这些数据中心所在区域的客户可以访问多个活动部署，同时每个活动部署还有相同数量的备用部署作为备份。
Web 前端群集 （WFE）
Web 前端群集 （WFE） 群集为用户的浏览器提供站点加载时的初始 HTML 页面内容，以及指向用于在浏览器中呈现站点的 Azure 内容分发网络（CDN）内容的指针。
WFE 群集由在 Azure 应用服务环境中运行的 ASP.NET 网站组成。 当用户尝试连接到 Power BI 服务时，客户端的 DNS 服务可能会与 Azure 流量管理器通信，以使用 Power BI 部署查找最合适的（通常最接近）的数据中心。 有关此过程的详细信息，请参阅 Azure 流量管理器的性能流量路由方法。
静态资源（例如 *.js、*.css 和映像文件）主要存储在 Azure CDN 上，并由浏览器直接检索。 请注意，主权政府群集部署是此规则的例外，出于符合性原因，将省略 CDN，而是使用来自合规区域的 WFE 群集来托管静态内容。
Power BI 后端群集
后端群集是 Power BI 中提供的所有功能的主干。 它由 WFE 和 API 客户端使用的多个服务终结点以及后台工作服务、数据库、缓存和其他各种组件组成。
后端服务在大多数 Azure 区域中可用，并正在新的区域中进行部署，当这些区域开放时。 单个 Azure 区域托管一个或多个后端群集，一旦单个群集的垂直和水平缩放限制耗尽，即可允许无限横向缩放 Power BI 服务。
每个后端群集都是有状态的，托管分配给该群集的所有租户的所有数据。 包含特定租户数据的群集称为租户的主群集。 经过身份验证的用户的主群集信息由全局服务提供，WFE 使用该信息将请求路由到租户的主群集。
每个后端群集由多个虚拟机组合成多个可调整大小的规模集，这些虚拟机针对执行特定任务、有状态资源（如 SQL 数据库、存储帐户、服务总线、缓存和其他必要的云组件）进行了优化。
租户元数据和数据存储在群集限制内，但对于数据复制到同一 Azure 地理位置的配对 Azure 区域中的辅助后端群集这一情况除外。 在发生区域性服务中断时，辅助后端群集充当故障转移群集，在任何其他时间都是被动的。
后端功能由群集虚拟网络中无法从外部访问的不同计算机上运行的微服务提供服务，但可从公共 Internet 访问的两个组件除外：
- 网关服务
- Azure API 管理
Power BI Premium 基础结构
Power BI Premium 为需要高级 Power BI 功能的订阅者提供服务，例如高级 AI、向未经许可的用户分发等。当客户注册 Power BI Premium 订阅时，会通过 Azure 资源管理器创建高级容量。
Power BI Premium 容量托管在独立于常规 Power BI 后端的后端群集中，如上所述。 这提供更好的隔离、资源分配、可支持性、安全隔离和高级产品/服务的可伸缩性。
下图说明了 Power BI Premium 基础结构的体系结构：
可以通过多种方式连接到 Power BI Premium 基础结构，具体取决于用户方案。 Power BI Premium 客户端可以是用户的浏览器、常规 Power BI 后端、通过 XMLA 客户端、ARM API 等直接连接。
Azure 区域中的 Power BI Premium 基础结构由多个 Power BI Premium 群集组成（最低为一个）。 大多数高级资源封装在群集（例如计算）内，并且存在一些常见的区域资源（例如元数据存储）。 高级基础结构允许两种方法实现区域中的水平可伸缩性：增加群集内部的资源和/或根据需要按需添加更多群集（如果群集资源接近其限制）。
每个群集的主干是 由虚拟机规模集 和 Azure Service Fabric 管理的计算资源。 随着使用情况的增长，虚拟机规模集和 Service Fabric 允许快速且无痛地增加计算节点，并协调 Power BI Premium 服务和应用程序的部署、管理和监视。
有许多周边资源可确保安全可靠的基础结构：负载均衡器、虚拟网络、网络安全组、服务总线、存储等。Power BI Premium 所需的任何机密、密钥和证书都由 Azure Key Vault 专门管理。 任何身份验证都是通过独占方式与 Microsoft Entra ID 集成完成的。
Power BI Premium 基础结构的任何请求都首先转到前端节点， 它们是唯一可用于外部连接的节点。 其余资源隐藏在虚拟网络后面。 前端节点对请求进行身份验证、处理请求或将其转发到相应的资源（例如后端节点）。
后端节点提供大多数 Power BI Premium 功能和功能。
Power BI Mobile
Power BI Mobile 是专为三个主要移动平台设计的应用集合：Android、iOS 和 Windows（UWP）。 Power BI 移动应用的安全注意事项分为两类：
- 设备通信
- 设备上的应用程序和数据
对于设备通信，所有 Power BI 移动应用都与 Power BI 服务通信，并使用浏览器使用的相同连接和身份验证序列，本白皮书前面对此进行了详细介绍。 适用于 iOS 和 Android 的 Power BI 移动应用程序在应用程序本身中启动浏览器会话，而 Windows 移动应用会启动代理，以便与 Power BI 建立通信通道（用于登录过程）。
下表显示了基于证书的身份验证（CBA）对 Power BI Mobile 的支持，具体取决于移动设备平台：
| CBA 支持 | iOS | 安卓 | Windows操作系统 |
|---|---|---|---|
| Power BI （登录服务） | 已支持 | 已支持 | 不支持 |
| 本地部署的 SSRS ADFS（连接到 SSRS 服务器） | 不支持 | 已支持 | 不支持 |
| SSRS 应用代理 | 已支持 | 已支持 | 不支持 |
Power BI 移动应用主动与 Power BI 服务通信。 遥测用于收集移动应用使用情况统计信息和类似数据，这些数据将传输到用于监视使用情况和活动的服务;不会使用遥测发送任何客户数据。
Power BI 应用程序在设备上存储数据，方便使用应用：
- Microsoft使用行业标准安全措施将 Entra ID 和刷新令牌存储在设备上的安全机制中。
- 数据和设置（用户配置的键值对）缓存在设备上的存储中，可由 OS 加密。 在 iOS 中，当用户设置密码时，会自动完成此作。 在 Android 中，可以在设置中配置此配置。 在 Windows 中，它通过使用 BitLocker 完成。
- 对于 Android 和 iOS 应用，数据和设置（用户配置的键值对）会被缓存到设备的沙盒和内部存储中，而这些存储只有应用可以访问。
- 用户显式启用或禁用了地理位置。 如果已启用，则地理位置数据不会保存在设备上，并且不会与 Microsoft 共享。
- 用户显式启用或禁用了通知。 启用该功能后，Android 和 iOS 不支持通知的地理数据驻留要求。
可以通过Microsoft Intune（提供移动设备和应用程序管理的软件服务）应用文件级加密来增强数据加密。 Power BI Mobile 在支持 Intune 的三个平台上均可使用。 启用和配置 Intune 后，移动设备上的数据将加密，Power BI 应用程序本身不能安装在 SD 卡上。 详细了解 Microsoft Intune。
Windows 应用还支持 Windows 信息保护（WIP）。
为了实现 SSO，与基于令牌的身份验证相关的一些安全存储值可用于其他Microsoft第一方应用（如 Microsoft Authenticator），并由 Microsoft身份验证库 （MSAL）管理。
删除应用、用户注销 Power BI Mobile 或用户无法登录（例如令牌过期事件或密码更改后）时，将删除 Power BI Mobile 缓存数据。 数据缓存包括以前从 Power BI 移动应用访问的仪表板和报表。
Power BI Mobile 无法访问设备上的其他应用程序文件夹或文件。
适用于 iOS 和 Android 的 Power BI 应用允许通过配置其他标识来保护数据，例如为 iOS 提供人脸 ID、触摸 ID 或密码，以及适用于 Android 的生物识别数据（指纹 ID）。 了解更多有关附加标识的信息。
对 Power BI 服务的身份验证
对 Power BI 服务的用户身份验证由用户浏览器与 Power BI 服务或 Power BI 使用的 Azure 服务之间的一系列请求、响应和重定向组成。 该序列描述了 Power BI 中的用户身份验证过程，该 流程遵循 Microsoft Entra 身份验证代码授予流。 有关组织用户身份验证模型（登录模型）的选项的详细信息，请参阅 为 Microsoft 365 选择登录模型。
身份验证序列
Power BI 服务的用户身份验证顺序如以下步骤中所述进行，如下图所示。
用户通过浏览器启动与 Power BI 服务的连接，方法是在地址栏中键入 Power BI 地址，或者从 Power BI 营销页https://powerbi.microsoft.com（）中选择“登录”。 连接是使用 TLS 和 HTTPS 建立的，浏览器和 Power BI 服务之间的所有后续通信都使用 HTTPS。
Azure 流量管理器会检查用户的 DNS 记录，以确定部署 Power BI 的最合适的（通常最接近）数据中心，并使用应将用户发送到的 WFE 群集的 IP 地址响应 DNS。
然后，WFE 将 HTML 页面返回到浏览器客户端，其中包含启动登录流所需的 MSAL.js 库引用。
浏览器客户端加载从 WFE 接收的 HTML 页面，并将用户重定向到 Microsoft Online Services 登录页。
对用户进行身份验证后，登录页会使用身份验证代码将用户重定向回 Power BI WFE 页面。
浏览器客户端加载 HTML 页面，并使用身份验证代码从 Microsoft Entra ID 请求令牌（访问、ID、刷新）。
浏览器客户端使用用户的租户 ID 查询 Power BI 全局服务，后者维护租户及其 Power BI 后端群集位置的列表。 Power BI 全局服务确定哪个 Power BI 后端服务群集包含用户的租户，并将 Power BI 后端群集 URL 返回回客户端。
客户端现在可以使用授权标头中的 HTTP 请求访问令牌与 Power BI 后端群集 URL API 通信。 Microsoft Entra 访问令牌将根据 Microsoft Entra 策略设置到期日期，并且为了维护当前会话，用户浏览器中的 Power BI 客户端将定期请求在访问令牌过期之前续订访问令牌。
在极少数情况下，客户端身份验证由于意外错误而失败，代码会尝试回退到在 WFE 中使用服务器端身份验证。 有关服务器端身份验证流的详细信息，请参阅 本文档末尾的问题和解答部分 。
数据驻留
除非文档中另有说明，否则 Power BI 将客户数据存储在首次注册 Power BI 服务的 Microsoft Entra 租户 时分配的 Azure 地理位置。 Microsoft Entra 租户储存与组织及其安全性相关的用户和应用程序标识、组以及其他相关信息。
租户数据存储的 Azure 地理位置分配是通过在 Microsoft Entra 租户设置阶段，将所选的国家或地区映射到 Power BI 部署所在的最适合的 Azure 地理位置来完成。 确定此决定后，除组织使用多地理位置部署的情况外，所有 Power BI 客户数据都将存储在此所选的 Azure 地理位置（也称为 主地理位置）。
多个地理区域（多地理位置）
某些组织具有全球影响力，可能需要在多个 Azure 地理位置使用 Power BI 服务。 例如，一家企业可能在美国拥有总部，但也可能在澳大利亚等其他地理区域开展业务。 在这种情况下，企业可能要求某些 Power BI 数据仍存储在远程区域中，以遵守本地法规。 Power BI 服务的此功能称为 多地理位置。
查询执行层、查询缓存和分配给多地理位置工作区的项目数据托管并保留在远程容量 Azure 地理位置中。 但是，某些项目元数据（如报表结构）可能仍存储在租户的主地理位置中。 此外，某些数据传输和处理可能仍然发生在租户的本地地理区域，即使工作区托管在多地理区域的高级容量中也是如此。
有关创建和管理跨多个 Azure 地理位置的部署的详细信息，请参阅 配置 Fabric 的多地理位置支持。
区域和数据中心
Power BI 服务在特定 Azure 地理位置可用，如 Microsoft信任中心中所述。 有关数据的存储位置及其使用方式的详细信息，请参阅 Microsoft信任中心。 在 Microsoft 在线服务条款的“数据处理条款”中指定了有关静态客户数据位置的承诺使用量。
Microsoft还提供主权实体的数据中心。 有关国家/地区云的 Power BI 服务可用性的详细信息，请参阅 Power BI 国家/地区云。
数据处理
本部分概述了在存储、处理和传输客户数据时 Power BI 数据处理做法。
静止的数据
Power BI 使用两种主要数据存储资源类型：
- Azure 存储
- Azure SQL 数据库
在大多数情况下，Azure 存储用于保存 Power BI 项目的数据，而 Azure SQL 数据库用于保存项目元数据。
默认情况下，Power BI 保留的所有数据都使用Microsoft管理的密钥进行加密。 使用 Azure SQL 的透明数据加密（TDE） 技术完全加密存储在 Azure SQL 数据库中的客户数据。 Azure Blob 存储中存储的客户数据使用 Azure 存储加密进行加密。
（可选）组织可以利用 Power BI Premium 使用自己的密钥来加密导入到语义模型中的静态数据。 此方法通常描述为自带密钥（BYOK）。 使用 BYOK 有助于确保即使出现服务作员错误，也不会公开客户数据 - 使用透明服务端加密无法轻松实现的内容。 有关更多信息，请参阅适用于 Power BI 的自带加密密钥。
Power BI 语义模型允许各种数据源连接模式，用于确定数据源数据是否保留在服务中。
| 语义模型模式（种类） | Power BI 中持久保存的数据 |
|---|---|
| 进口 | 是的 |
| DirectQuery（直接查询） | 否 |
| 实时连接 | 否 |
| 复合 | 如果包含导入数据源 |
| 流媒体 | 如果配置为持久化 |
无论使用哪种语义模型模式，Power BI 都可能会暂时缓存任何检索到的数据，以优化查询和报表加载性能。
处理中的数据
当数据被一个或多个用户主动用作交互式方案的一部分，或者当后台进程（如刷新）触及此数据时，数据正在处理中。 Power BI 会将主动处理的数据加载到一个或多个服务工作负荷的内存空间中。 为了方便工作负荷所需的功能，不会加密内存中已处理的数据。
传输中的数据
Power BI 要求使用 TLS 1.2 或更高版本加密所有传入的 HTTP 流量。 任何尝试使用 TLS 1.1 或更低版本的服务的请求都将被拒绝。
向数据源进行身份验证
连接到数据源时，用户可以选择将数据副本导入 Power BI 或直接连接到数据源。
在导入时，用户基于用户的登录建立连接，并使用凭据访问数据。 将语义模型发布到 Power BI 服务后，Power BI 始终使用此用户的凭据导入数据。 导入数据后，在报表和仪表板中查看数据不会访问基础数据源。 Power BI 支持所选数据源的单一登录身份验证。 如果连接配置为使用单一登录，则语义模型所有者的凭据用于连接到数据源。
如果数据源使用预配置的凭据直接连接，则当任何用户查看数据时，预配置的凭据将用于连接到数据源。 如果使用单一登录直接连接数据源，则当用户查看数据时，当前用户的凭据用于连接到数据源。 与单一登录一起使用时，可以在数据源上实现行级安全性（RLS）和/或对象级安全性（OLS）。 这允许用户仅查看他们有权访问的数据。 当连接到云中的数据源时，Microsoft Entra 身份验证用于单一登录;支持本地数据源、Kerberos、安全断言标记语言（SAML）和Microsoft Entra ID。
如果数据源是 Azure Analysis Services 或本地 Analysis Services，并且配置了 RLS（行级别安全）和/或 OLS（对象级别安全），则 Power BI 服务将应用相应的安全策略。用户如果没有足够的访问权限凭据，无法访问仪表板、报表或其他数据项目中使用的查询等基础数据，他们就看不到没有相应权限的数据。
高级功能
数据流体系结构
数据流提供用户配置后端数据处理操作的能力，这些操作将从多样化数据源中提取数据，对数据执行转换逻辑，然后将数据存入目标模型，以便在各种报告展示技术中使用。 工作区中具有成员、参与者或管理员角色的任何用户都可能会创建数据流。 查看者角色中的用户可以查看数据流处理的数据，但可能不会对其组合进行更改。 创作数据流后，工作区的任何成员、参与者或管理员都可能会计划刷新，并通过获取数据流的所有权来查看和编辑数据流。
每个配置的数据源都绑定到用于访问该数据源的客户端技术。 为了满足数据源的实现详细信息，访问凭据的结构已被设计成与之匹配。 转换逻辑在数据处于运行状态时由 Power Query 服务应用。 对于高级数据流，Power Query 服务在后端节点中执行。 可以直接从云源或通过本地安装的网关拉取数据。 从云源直接拉取到服务或网关时，传输将使用特定于客户端技术的保护方法（如果适用）。 将数据从网关传输到云服务时，会对其进行加密。 请参阅上面的 “传输中的数据 ”部分。
当客户指定的数据源需要凭据才能访问时，数据流的所有者/创建者将在创作期间提供它们。 它们使用标准产品范围的凭据存储进行存储。 请参阅上述 数据源的身份验证 。 用户可以配置各种方法来优化数据持久性和访问。 默认情况下，数据放置在 Power BI 拥有和保护的存储帐户中。 在 Blob 存储容器上启用存储加密，以保护静止状态的数据。 请参阅下面的 静态数据 。 但是，用户可以配置与其自己的 Azure 订阅关联的自己的存储帐户。 执行此作时，向 Power BI 服务主体授予对该存储帐户的访问权限，以便它可以在刷新期间写入数据。 在这种情况下，存储资源所有者负责在配置的 Azure Data Lake Storage 帐户上配置加密。 数据始终使用加密传输到 Blob 存储。
由于访问存储帐户时的性能对于某些数据可能不理想，因此用户还可以选择使用 Power BI 托管的计算引擎来提高性能。 在这种情况下，数据冗余存储在可通过后端 Power BI 系统访问的 SQL 数据库中供 DirectQuery 使用。 数据始终在文件系统上加密。 如果用户提供用于加密存储在 SQL 数据库中的数据的密钥，该密钥将用于对它进行双重加密。
使用 DirectQuery 进行查询时，加密传输协议 HTTPS 用于访问 API。 DirectQuery 的所有辅助或间接使用都由前面所述的相同访问控制控制。 由于数据流始终绑定到工作区，因此对数据的访问始终受到该工作区中用户的角色的限制。 用户必须至少具有读取访问权限才能通过任何方式查询数据。
当 Power BI Desktop 用于访问数据流中的数据时，必须先使用 Microsoft Entra ID 对用户进行身份验证，以确定用户是否有足够的权限查看数据。 如果是这样，则获取 SaS 密钥，并用于直接使用加密传输协议 HTTPS 访问存储。
整个数据管道中的数据处理会发出 Office 365 审核事件。 其中一些事件将涉及与安全和隐私相关的操作。
分页报表
分页报表是设计用于打印或共享的报表。 它们之所以称为分页，是因为它们被格式化为适合页面上。 他们在一个表格中展示所有数据，即使该表格跨越多个页面。 你可以精确控制报表页面布局。
分页报表支持使用 Microsoft Visual Basic .NET 编写的丰富且强大的表达式。 表达式在 Power BI 报表生成器分页报表中广泛使用，用于检索、计算、显示、分组、排序、筛选、参数化和设置数据格式。
表达式由报表的作者创建，可以访问 .NET Framework 的广泛功能。 分页报表的处理和执行在沙盒中执行。
分页报表定义（.rdl）存储在 Power BI 中，若要发布和/或呈现分页报表，用户需要以与 向 Power BI 服务的身份验证中所述的方式进行身份验证和授权的方式相同。
身份验证期间获取的Microsoft Entra 令牌用于直接从浏览器与 Power BI Premium 群集通信。
在 Power BI Premium 中，Power BI 服务运行时为每个报表呈现提供适当的隔离执行环境。 这包括呈现的报表属于分配给同一容量的工作区的情况。
分页报表可以在呈现报表过程中访问一组广泛的数据源。 沙盒不直接与任何数据源通信，而是与受信任的进程通信以请求数据，然后受信任的进程会将所需的凭据追加到连接。 通过这种方式，沙盒永远不会有权访问任何凭据或机密。
为了支持必应地图或调用 Azure Functions 等功能，沙盒的确能够访问互联网。
Power BI Embedded 分析
独立软件供应商（ISV）和解决方案提供商在其 Web 应用程序和门户中嵌入 Power BI 项目有两种主要模式： 为你的组织嵌入 和 为客户嵌入。 制品嵌入到应用程序或门户中的 IFrame 中。 不允许 IFrame 从外部 Web 应用程序或门户读取或写入数据，并且使用 POST 消息通过 Power BI 客户端 SDK 完成与 IFrame 的通信。
在 嵌入组织方案 的场景中，Microsoft Entra 用户通过企业及 IT 部门自定义的门户访问自己的 Power BI 内容。 本文中所述的所有 Power BI 策略和功能（如 RLS 和 OLS）都会自动应用于所有用户，而不管他们是通过 Power BI 门户 还是自定义门户访问 Power BI。
在 嵌入为客户的应用场景 中，ISV 通常拥有 Power BI 租户和 Power BI 项目（仪表板、报表、语义模型等）。 ISV 后端服务负责对最终用户进行身份验证，并确定哪个项目以及哪个访问级别适合该最终用户。 ISV 策略决策在 Power BI 生成的 嵌入令牌 中加密，并传递给 ISV 后端，以便根据 ISV 的业务逻辑进一步分发给最终用户。 使用浏览器或其他客户端应用程序的最终用户无法解密或修改嵌入令牌。 客户端 SDK（如 Power BI 客户端 API ）会自动将加密的嵌入令牌作为 授权：EmbedToken 标头追加到 Power BI 请求。 根据此标头，Power BI 将强制实施所有策略（如访问或 RLS），就像生成过程中 ISV 所指定的一样。
若要启用嵌入和自动化并生成上述嵌入令牌，Power BI 会公开一组丰富的 REST API。 这些 Power BI REST API 支持用户委托的和服务主体的 Microsoft Entra 身份验证和授权方法。
Power BI 嵌入式分析及其 REST API 支持本文中所述的所有 Power BI 网络隔离功能，包括 服务标记 和 专用链接。
AI 功能
Power BI 目前支持产品中的两大类 AI 功能：AI 视觉对象和 AI 扩充。 视觉级别的 AI 功能包括关键影响因素、分解树、智能叙述、异常检测、R 视觉对象、Python 视觉对象、聚类分析、预测、Q&A、快速见解等功能。AI 扩充功能包括 AutoML、Azure 机器学习、认知服务、R/Python 转换等功能。
目前，共享工作区和高级工作区都支持上述大部分功能。 但是，由于 IP 限制，AutoML 和 CognitiveService 仅在高级工作区中受支持。 现在，借助 Power BI 中的 AutoML 集成，用户可以生成和训练自定义机器学习（ML）模型（例如预测、分类、回归等），并在将数据加载到高级工作区中定义的数据流时应用它来获取预测。 此外，Power BI 用户可以应用多个认知服务 API（例如 TextAnalytics 和 ImageTagging），在将数据加载到高级工作区中定义的数据流/语义模型之前对其进行转换。
高级 AI 扩充功能可最好地视为无状态 AI 函数/转换的集合，Power BI 用户在 Power BI 语义模型或数据流使用的数据集成管道中可以使用这些功能。 请注意，还可以从 Power BI 服务和 Power BI Desktop 中的当前数据流/语义模型创作环境访问这些函数。 这些 AI 函数/转换始终在高级工作区/容量中运行。 这些函数作为数据源显示在 Power BI 中，该数据源需要为使用 AI 函数的 Power BI 用户提供Microsoft Entra 令牌。 这些 AI 数据源很特殊，因为它们不呈现自己的任何数据，它们只提供这些函数/转换。 在执行期间，这些功能不会向其他服务发出任何出站调用，以传输客户的数据。 让我们单独查看高级方案，以了解通信模式以及与它们相关的相关安全详细信息。
为了训练和应用 AutoML 模型，Power BI 使用 Azure AutoML SDK，并在客户的 Power BI 容量中运行所有训练。 在训练迭代期间，Power BI 调用试验 Azure 机器学习服务，为当前迭代选择合适的模型和超参数。 在此出站调用中，仅发送上一次迭代中相关的试验元数据（例如准确性、ml 算法、算法参数等）。 AutoML 训练生成 ONNX 模型和训练报表数据，然后保存在数据流中。 然后，Power BI 用户可以将训练好的 ML 模型作为一种转化应用，定期使用该模型实现操作化。 对于 TextAnalytics 和 ImageTagging API，Power BI 不会直接调用 CognitiveServices 服务 API，而是使用内部 SDK 在 Power BI Premium 容量中运行 API。 如今，Power BI 数据流和语义模型都支持这些 API。 在 Power BI Desktop 中创作数据模型时，如果用户有权访问 Premium Power BI 工作区，则只能访问此功能。 因此，系统会提示客户提供其Microsoft Entra 凭据。
网络隔离
本部分概述了 Power BI 中的高级安全功能。 某些功能具有特定的许可要求。 有关详细信息，请参阅以下部分。
服务标记
服务标记表示给定 Azure 服务中的一组 IP 地址前缀。 它有助于最大程度地减少对网络安全规则的频繁更新的复杂性。 客户可以使用服务标记在 网络安全组 或 Azure 防火墙上定义网络访问控制。 创建安全规则时，客户可以使用服务标记代替特定 IP 地址。 通过在规则的相应源或目标（API）字段中指定服务标记名称（例如 PowerBI），客户可以允许或拒绝相应服务的流量。 Microsoft 会管理服务标记包含的地址前缀，并会在地址发生更改时自动更新服务标记。
专用链接集成
Azure 网络提供 Azure 专用链接功能，使 Power BI 能够通过 Azure 网络专用终结点提供安全访问。 使用 Azure 专用链接和专用终结点时，数据流量使用Microsoft的主干网络基础结构私下发送，因此数据不会遍历 Internet。
专用链接可确保 Power BI 用户在转到 Power BI 服务中的资源时使用Microsoft专用网络主干。
将专用链接与 Power BI 配合使用可提供以下优势：
- 专用链接可确保流量通过 Azure 主干流向 Azure 基于云的资源的专用终结点。
- 网络流量与非基于 Azure 的基础设施的隔离（例如本地访问）需要客户配置 ExpressRoute 或 VPN。
有关其他信息，请参阅 专用链接，以便安全访问 Fabric 。
VNet 连接
虽然专用链接集成功能提供与 Power BI 的安全入站连接，但 VNet 连接功能支持从 Power BI 到 VNet 中的数据源的安全出站连接。
VNet 网关（由 Microsoft 管理）消除了安装和监控本地网关以连接到与 VNet 相关的数据源的麻烦。 但是，与本地数据网关一样，它们仍遵循管理安全和数据源的熟悉过程。
以下是使用 VNet 网关与连接到 VNet 中的数据源的 Power BI 报表交互时会发生什么情况的概述：
Power BI 云服务（或其他受支持的云服务之一）启动查询，并将查询、数据源详细信息和凭据发送到 Power Platform VNet （PP VNet） 服务。
然后，PP VNet 服务安全地将运行 VNet 网关的容器注入子网。 此容器现在可以连接到可从此子网中访问的数据服务。
然后，PP VNet 服务会将查询、数据源详细信息和凭据发送到 VNet 网关。
VNet 网关获取查询，并使用这些凭据连接到数据源。
然后，查询将发送到数据源以供执行。
执行后，结果将发送到 VNet 网关，PP VNet 服务安全地将数据从容器推送到 Power BI 云服务。
服务主体
Power BI 支持使用服务主体。 存储用于在 Key Vault 中加密或访问 Power BI 的任何服务主体凭据，为保管库分配适当的访问策略，并定期查看访问权限。
有关更多详细信息，请参阅 使用服务主体自动执行高级工作区和语义模型任务 。
适用于 Power BI 的 Microsoft Purview
Microsoft Purview 信息保护
Power BI 与 Microsoft Purview 信息保护深度集成。 Microsoft Purview 信息保护使组织能够跨 Azure、Power BI 和 Office 提供一个用于分类、标记、审核和合规性的集成解决方案。
在 Power BI 中启用信息保护时：
- 敏感数据（无论是在 Power BI 服务和 Power BI Desktop 中）都可以使用 Office 和 Azure 中使用的相同敏感度标签进行分类和标记。
- 当 Power BI 内容导出到 Excel、PowerPoint、PDF、Word 或 .pbix 文件时，可以强制实施治理策略，以帮助确保数据在离开 Power BI 时受到保护。
- 可以轻松地在 Power BI Desktop 中对 .pbix 文件进行分类和保护，就像在 Excel、Word 和 PowerPoint 应用程序中所做的那样。 可以根据文件的敏感度级别轻松标记文件。 此外，如果它们包含业务机密数据，则可以对其进行加密，确保只有经过授权的用户才能编辑这些文件。
- Excel 工作簿在连接到 Power BI 时自动继承敏感度标签，以便在 Excel 中分析 Power BI 语义模型时维护端到端分类并应用保护。
- 应用于 Power BI 报表和仪表板的敏感度标签在 Power BI iOS 和 Android 移动应用中可见。
- 当 Power BI 报表嵌入到 Teams、SharePoint 或安全网站时，敏感度标签会保留。 这有助于组织在嵌入 Power BI 内容时在导出时保持分类和保护。
- 在 Power BI 服务中创建新内容时，标签继承可确保应用于语义模型或 Power BI 服务中的数据市场中的标签将应用于在这些语义模型和数据市场之上创建的新内容。
- Power BI 管理员扫描 API 可以提取 Power BI 项的敏感度标签，使 Power BI 和 InfoSec 管理员能够监视 Power BI 服务中的标签并生成执行报表。
- Power BI 管理员 API 使中心团队能够以编程方式将敏感度标签应用于 Power BI 服务中的内容。
- 中心团队可以创建强制标签策略，以强制在 Power BI 中对新内容或编辑的内容应用标签。
- 中心团队可以创建默认标签策略，以确保敏感度标签应用于所有新的或更改的 Power BI 内容。
- Power BI 服务中的自动下游敏感度标签可确保在语义模型或 Datamart 上的标签应用或更改时，将自动对连接到语义模型或 Datamart 的所有下游内容应用或更改标签。
有关详细信息，请参阅 Power BI 中的敏感度标签。
适用于 Power BI 的 Microsoft Purview 数据丢失防护 （DLP） 策略
Microsoft Purview 的数据丢失防护（DLP）策略可帮助组织降低 Power BI 中敏感数据泄露的风险。 DLP 策略帮助他们满足政府或行业法规的合规性要求，例如欧盟的一般数据保护条例（GDPR）或加州消费者隐私法（CCPA），并确保其数据在 Power BI 中得到管理。
设置 Power BI 的 DLP 策略时：
- 策略中指定的工作区中的所有语义模型都由策略评估。
- 可以在将敏感数据上传到高级容量时进行检测。 DLP 策略可以检测：
- 敏感度标签。
- 敏感信息类型。 支持超过 260 种类型。 敏感信息类型检测依赖于 Microsoft Purview 内容扫描。
- 当你遇到被标识为敏感的语义模型时，你会看到一个自定义的策略提示，帮助你了解应该采取的措施。
- 如果你是语义模型所有者，则可以重写策略，并阻止语义模型被标识为“敏感”（如果有这样做的有效原因）。
- 如果你是语义模型所有者，则可以报告策略问题（如果得出结论，敏感信息类型已被错误识别）。
- 可以调用自动风险缓解措施，例如安全管理员的警报。
有关详细信息，请参阅 Fabric 和 Power BI 的数据丢失防护策略。
微软云应用防护器适用于Power BI
Microsoft Defender for Cloud Apps 是世界领先的云访问安全代理之一，被评为Gartner云访问安全代理（CASB）市场魔力象限中的领头羊。 Defender for Cloud Apps 用于保护云应用的使用。 它使组织能够实时监视和控制有风险的 Power BI 会话，例如从非托管设备进行用户访问。 安全管理员可以定义策略来控制用户操作，例如下载含有敏感信息的报表。
借助 Defender for Cloud Apps，组织可以获得以下 DLP 功能：
- 设置实时控制，以在 Power BI 中强制实施有风险的用户会话。 例如，如果用户从所在国家或地区外部连接到 Power BI，则可以由 Defender for Cloud Apps 实时控制监控会话，并立即阻止风险行为，例如下载标记有“高度机密”敏感标签的数据。
- 使用 Defender for Cloud Apps 活动日志调查 Power BI 用户活动。 Defender for Cloud Apps 活动日志包括 Office 365 审核日志中捕获的 Power BI 活动，其中包含所有用户和管理员活动的相关信息，以及应用、更改和删除标签等相关活动的敏感度标签信息。 管理员可以利用 Defender for Cloud Apps 的高级筛选器和快速操作，以进行有效的调查问题。
- 创建自定义策略，以针对 Power BI 中的可疑用户活动发出警报。 可以使用 Defender for Cloud Apps 活动策略功能来定义自己的自定义规则，以帮助检测偏离规范的用户行为，甚至可能自动处理它（如果看起来太危险）。
- 与内置异常检测的 Defender for Cloud Apps 搭配工作。 Defender for Cloud Apps 异常情况检测策略提供现成的用户行为分析和机器学习，以便你从一开始就准备好在云环境中运行高级威胁检测。 当异常情况检测策略标识可疑行为时，它会触发安全警报。
- Defender for Cloud Apps 门户中的 Power BI 管理员角色。 Defender for Cloud Apps 提供特定于应用的管理员角色，可用于仅向 Power BI 管理员授予他们访问门户中与 Power BI 相关的数据所需的权限，例如警报、有风险的用户、活动日志和其他 Power BI 相关信息。
有关其他详细信息，请参阅 在 Power BI 中使用 Microsoft Defender for Cloud Apps 控件。
Power BI 安全问题和解答
以下问题是 Power BI 的常见安全问题和解答。 这些内容基于添加到本白皮书的时间进行组织，以方便你在更新本文时快速找到新问题和答案的能力。 最新问题将添加到此列表的末尾。
用户在使用 Power BI 时如何连接和获取对数据源的访问权限？
Power BI 为每个用户管理云服务凭据或通过个人网关连接的数据源凭据。 本地数据网关管理的数据源可以跨企业共享，这些数据源的权限可由网关管理员管理。配置语义模型时，允许用户从其个人存储中选择凭据，或使用本地数据网关使用共享凭据。
在导入案例中，用户基于用户的登录建立连接，并使用凭据访问数据。 将语义模型发布到 Power BI 服务后，Power BI 始终使用此用户的凭据导入数据。 导入数据后，在报表和仪表板中查看数据不会访问基础数据源。 Power BI 支持所选数据源的单一登录身份验证。 如果连接配置为使用单一登录，则语义模型所有者的凭据用于与数据源连接。
对于与 DirectQuery 连接的报表，数据源使用预配置的凭据直接连接。 在任何用户查看数据时，预配置的凭据用于连接数据源。 如果使用单一登录直接连接数据源，则当用户查看数据时，当前用户的凭据用于连接到数据源。 使用单一登录时，可以在数据源上实现 RLS 和/或 OLS，这允许用户查看他们有权访问的数据。 当连接到云中的数据源时，使用 Microsoft Entra 身份验证进行单点登录；对于本地数据源，支持 Kerberos、SAML 和 Microsoft Entra ID。
使用 Kerberos 进行连接时，用户的 UPN 将传递到网关，并使用 Kerberos 约束委派来模拟用户身份并连接到相应的数据源。 SAP HANA 数据源的网关也支持 SAML。 您可以在网关单一登录的概述中找到更多信息。
如果数据源为 Azure Analysis Services 或本地 Analysis Services，并配置了 RLS 和/或 OLS，则 Power BI 服务将应用该级别的安全性。对于没有足够凭据访问基础数据（这可能是仪表板、报表或其他数据工件中使用的查询）的用户，他们不会看到自己没有足够权限的数据。
使用 Power BI 的 RLS 可用于限制给定用户的数据访问。 筛选器在行级别限制数据访问，可以在角色中定义筛选器。
OLS 可用于保护敏感表或列。 但是，与 RLS 不同，OLS 还保护对象名称和元数据。 这有助于防止恶意用户发现甚至存在此类对象。 使用 Excel 或 Power BI 等报告工具时，受保护的表和列在字段列表中被遮盖，此外，没有权限的用户无法通过 DAX 或任何其他方法访问受保护的元数据对象。 从没有适当访问权限的用户的角度来看，受保护的表和列根本不存在。
OLS 与 RLS 一起，可增强报表和语义模型的企业级安全性，确保只有具有必要权限的用户有权查看和与敏感数据交互。
如何将数据传输到 Power BI？
- Power BI 请求和传输的所有数据都使用 HTTPS（除非客户选择的数据源不支持 HTTPS）在传输中加密，以便从数据源连接到 Power BI 服务。 与数据提供程序建立安全连接，只有建立该连接后，数据才会遍历网络。
Power BI 如何缓存报表、仪表板或模型数据，以及它是否安全？
- 访问数据源时，Power BI 服务遵循 “向数据源进行身份验证”中概述的过程。
客户端是否在本地缓存网页数据？
- 浏览器客户端访问 Power BI 时，Power BI Web 服务器将 Cache-Control 指令设置为 无存储。 no-store 指令指示浏览器不要缓存用户正在查看的网页，而不是将网页存储在客户端的缓存文件夹中。
基于角色的安全性、共享报表或仪表板和数据连接呢？ 这如何在数据访问、仪表板查看、报表访问或刷新方面发挥作用？
对于 启用非 RLS 的 数据源，如果仪表板、报表或数据模型通过 Power BI 与其他用户共享，则数据可供共享的用户查看和交互。 Power BI 不会 针对原始数据源重新对用户进行身份验证;将数据上传到 Power BI 后，针对源数据进行身份验证的用户负责管理哪些其他用户和组可以查看数据。
当数据连接到 支持 RLS 的 数据源（例如 Analysis Services 数据源）时，Power BI 中仅缓存仪表板数据。 每次在 Power BI 中查看或访问使用支持 RLS 数据源的数据的报表或语义模型时，Power BI 服务都会访问数据源，以基于用户的凭据获取数据;如果存在足够的权限，数据将加载到该用户的报表或数据模型中。 如果身份验证失败，用户将看到错误。
有关详细信息，请参阅 对数据源的身份验证。
我们的用户一直连接到同一数据源，其中一些数据源需要不同于其域凭据的凭据。 如何在每次建立数据连接时避免输入这些凭据？
- Power BI 提供 Power BI 个人网关，该功能允许用户为多个不同的数据源创建凭据，然后在随后访问每个数据源时自动使用这些凭据。 有关详细信息，请参阅 在 Power BI 中使用个人网关。
本地数据网关和个人网关使用哪些端口？ 是否有需要允许用于连接目的的域名？
- 以下文章提供了此问题的详细答案： 调整本地数据网关的通信设置。
使用本地数据网关时，如何使用恢复密钥及其存储位置？ 安全凭据管理呢？
在网关安装和配置过程中，管理员输入一个网关恢复密钥。 该 恢复密钥 用于生成强 AES 对称密钥。 还会同时创建 RSA 非对称密钥。
这些生成的密钥（RSA 和 AES）存储在位于本地计算机上的文件中。 该文件也是加密的。 文件的内容只能由该特定 Windows 计算机解密，只能由该特定网关服务帐户解密。
当用户在 Power BI 服务 UI 中输入数据源凭据时，凭据使用浏览器中的公钥进行加密。 网关使用 RSA 私钥解密凭据，并在数据存储在 Power BI 服务中之前使用 AES 对称密钥重新加密凭据。 在此过程中，Power BI 服务永远不会访问未加密的数据。
本地数据网关使用哪些通信协议以及如何保护它们？
网关支持以下两种通信协议：
AMQP 1.0 – TCP + TLS：此协议需要端口 443、5671-5672 和 9350-9354 才能进行传出通信。 此协议是首选协议，因为它的通信开销较低。
HTTPS – 基于 HTTPS + TLS 的 WebSocket：此协议仅使用端口 443。 WebSocket 由单个 HTTP CONNECT 消息启动。 建立通道后，通信本质上是 TCP+TLS。 可以通过修改 本地网关文章中所述的设置来强制网关使用此协议。
Azure CDN 在 Power BI 中的角色是什么？
如前所述，Power BI 使用 Azure CDN 根据地理区域设置有效地将必要的静态内容和文件分发给用户。 为了进一步详细介绍，Power BI 服务使用多个 CDN 有效地通过公共 Internet 将必要的静态内容和文件分发给用户。 这些静态文件包括产品下载（例如 Power BI Desktop、本地数据网关或各种 ISV 中的 Power BI 应用）、用于启动和建立与 Power BI 服务的任何后续连接以及初始安全 Power BI 登录页的浏览器配置文件。
根据在与 Power BI 服务的初始连接期间提供的信息，用户的浏览器会联系指定的 Azure CDN（或某些文件 WFE），以下载启用浏览器与 Power BI 服务交互所需的指定通用文件的集合。 然后，浏览器页面在 Power BI 服务浏览器会话期间包括 Microsoft Entra 令牌、会话信息、关联的后端群集的位置，以及从 Azure CDN 和 WFE 群集下载的文件集合。
对于 Power BI 可视化，在将自定义视觉发布到库之前，Microsoft 是否会进行任何安全或隐私评估？
- 否。 客户负责查看并确定是否应依赖自定义视觉代码。 所有自定义视觉对象代码都在沙盒环境中运行，因此自定义视觉对象中的任何异常代码不会对 Power BI 服务的其余部分产生负面影响。
是否有其他 Power BI 视觉对象在客户网络外部发送信息？
- 是的。 必应地图和 ESRI 视觉化组件将数据从 Power BI 服务中传输出，供使用这些服务的可视化组件使用。
对于模板应用，在将项发布到库之前，Microsoft是否对模板应用执行任何安全或隐私评估？
- 否。 应用发布者负责内容，而客户负责查看并确定是否信任模板应用发布者。
是否有模板应用可以在客户网络外部发送信息？
- 是的。 客户有责任查看发布者的隐私策略，并确定是否在租户上安装模板应用。 发布者负责告知客户应用的行为和功能。
数据主权如何？ 能否在特定地理位置的数据中心预配租户，以确保数据不会离开国家或地区边界？
某些地理位置的一些客户可以选择在国家/地区云中创建租户，其中数据存储和处理与所有其他数据中心保持隔离。 国家/地区云具有略有不同的安全类型，因为单独的数据受托人代表Microsoft运营国家/地区云 Power BI 服务。
或者，客户还可以在特定区域中设置租户。 但是，此类租户没有与Microsoft分开的数据受托方。 国家/地区云的定价不同于通用商业 Power BI 服务。 有关国家/地区云的 Power BI 服务可用性的详细信息，请参阅 Power BI 国家/地区云。
Microsoft如何为拥有 Power BI Premium 订阅的客户处理连接？ 这些连接是否不同于为非高级 Power BI 服务建立的连接？
- 使用 Power BI Premium 订阅为客户建立的连接实现了 Microsoft Entra 企业到企业（B2B） 授权过程，使用 Microsoft Entra ID 启用访问控制和授权。 Power BI 处理从 Power BI Premium 订阅者到 Power BI Premium 资源的连接，就像处理任何其他 Microsoft Entra 用户一样。
服务器端身份验证在 WFE 中的工作原理是什么？
- 用户身份验证顺序服务端身份验证按以下步骤中所述进行，如下图所示。
用户通过浏览器启动与 Power BI 服务的连接，方法是在地址栏中键入 Power BI 地址，或者从 Power BI 营销页https://powerbi.microsoft.com（）中选择“登录”。 连接是使用 TLS 1.2 和 HTTPS 建立的，浏览器和 Power BI 服务之间的所有后续通信都使用 HTTPS。
Azure 流量管理器会检查用户的 DNS 记录，以确定部署 Power BI 的最合适的（通常最接近）数据中心，并使用应将用户发送到的 WFE 群集的 IP 地址响应 DNS。
然后，WFE 将用户重定向到 Microsoft Online Services 登录页。
对用户进行身份验证后，登录页会使用身份验证代码将用户重定向到之前确定的最近的 Power BI 服务 WFE 群集。
WFE 群集使用 Microsoft Entra ID 进行检查，以使用身份验证代码获取 Microsoft Entra 安全令牌。 Microsoft Entra ID 返回用户的成功身份验证并返回Microsoft Entra 安全令牌时，WFE 群集会查阅 Power BI 全局服务，该服务维护租户及其 Power BI 后端群集位置的列表，并确定哪些 Power BI 后端服务群集包含用户的租户。 然后，WFE 群集将应用程序页返回到用户的浏览器，其中包含其作所需的会话、访问和路由信息。
现在，当客户端的浏览器需要客户数据时，它会使用授权标头中的 Microsoft Entra 访问令牌将请求发送到后端群集地址。 Power BI 后端群集读取 Microsoft Entra 访问令牌并验证签名，以确保请求的标识有效。 Microsoft Entra 访问令牌将根据 Microsoft Entra 策略设置到期日期，并且为了维护当前会话，用户浏览器中的 Power BI 客户端将定期请求在访问令牌过期之前续订访问令牌。
其他资源
有关 Power BI 的详细信息，请参阅以下资源。