Power BI 安全性白皮书
摘要： Power BI 是一种联机软件服务（SaaS 或软件即服务）产品/Microsoft 服务，可让你轻松快速地创建自助式商业智能仪表板、报表、语义模型和可视化效果。 使用 Power BI，可以连接到多个不同的数据源，合并并调整来自这些连接的数据，然后创建可与其他人共享的报表和仪表板。
作者：Yitzhak Kesselman、Paddy Osborne、Matt Neely、Tony Bencic、Srinivasan Turuvekere、Cristian Petculescu、Adi Regev、Naveen Sivaraj、Ben Glastein、Evgeny Tshiorny、Arthi Ramasubramanian Iyer、Sid Jayadevan、Ronald Chang、Ori Eduar、Anton Fritz、Idan Sheinberg、Ron Gilad、Sagiv Hadaya、Paul Inbar、Igor Uzhviev、Michael Roth、Jaime Tarquino、Gennady Pats、Orion Lee、Yury Berezansky、Maya Shenhav、Romit Chattopadhyay、Yariv Maimon、Bogdan Crivat
技术审阅者：Cristian Petculescu、Amir Netz、Sergei Gundorov
适用于：Power BI SaaS、Power BI Desktop、Power BI Premium、Power BI 嵌入式分析、Power BI 移动版。
注意
可以从浏览器中选择“打印”，然后选择“另存为 PDF”，以保存或打印此白皮书。
介绍
Power BI 是 Microsoft 提供的一个在线软件服务（SaaS 或软件即服务），你可以通过它轻松快速地创建自助式商业智能仪表板、报表、语义模型和可视化效果。 使用 Power BI，可以连接到多个不同的数据源，合并并调整来自这些连接的数据，然后创建可与其他人共享的报表和仪表板。
世界正在迅速变化：组织正在经历加速的数字化转型，我们看到远程工作大幅增加，客户对联机服务的需求增加，在运营和业务决策中更多地使用先进技术。 所有这些都由云提供支持。
随着向云的过渡已经从涓滴细流转变为汹涌大潮，以及随之而来的新的表层领域向外公开，更多公司正在询问我的数据在云中的安全性如何？以及可以使用哪种端到端保护来防止敏感数据泄露？。对于经常处理企业中一些最具战略意义的信息的 BI 平台来说，这些问题尤为重要。
拥有数十年的 BI 安全模型基础（对象级别安全性和行级别安全性）虽然仍然很重要，但显然已经不足以提供云时代所需的安全性。 相反，组织必须为其商业智能数据寻找云原生、多层、深层防御的安全解决方案。
Power BI 旨在为数据提供行业领先的完整密封保护。 该产品获得了业内最高的安全分类，如今，许多国家安全机构、金融机构和医疗保健提供者将其最敏感的信息托付给它。
这一切都从基础开始。 在经历了二十一世纪初的艰难时期后，Microsoft 投入了大量资金来解决其安全漏洞，并在随后的几十年中构建了功能强大的安全堆栈，深入到计算机芯片 BIOS 内核级别，并一直延伸到最终用户体验。 这些深度投资仍在继续，目前有 3,500 多名 Microsoft 工程师参与构建和增强 Microsoft 的安全堆栈，并主动应对不断变化的威胁环境。 有数十亿台计算机、数万亿次登录名和无数泽字节的信息都托付 Microsoft 进行保护，现在公司拥有科技行业最先进的安全堆栈，并被广泛视为打击恶意行为者的全球领导者。
Power BI 基于此强大的基础构建。 它使用与 Azure 获得服务和保护世界上最敏感数据的权利相同的安全堆栈，并与 Microsoft 365 最先进的信息保护和合规性工具集成。 除此之外，它通过多层安全措施提供安全性，从而提供端到端保护，旨在应对云时代的独特挑战。
若要提供用于保护敏感资产的端到端解决方案，产品团队需要在多个方面同时解决具有挑战性的客户问题：
- 如何控制谁可以连接、连接位置以及连接方式？如何控制连接？
- 如何存储数据？如何加密？我对我的数据有哪些控制？
- 如何控制和保护敏感数据？如何确保此数据不会泄露到组织外部？
- 如何审核谁执行了哪些操作？如何在服务上存在可疑活动时快速做出反应？
本文提供了所有这些问题的全面解答。 本文首先概述了服务体系结构，并介绍了系统中主要流的工作原理。 然后，继续介绍用户如何向 Power BI 进行身份验证、如何建立数据连接，以及 Power BI 如何通过服务存储和移动数据。 最后一部分讨论允许你作为服务管理员保护最有价值的资产的安全功能。
Power BI 服务受 Microsoft Online Services 条款和 Microsoft Enterprise Privacy 声明约束。 有关数据处理的位置，请参阅 Microsoft 联机服务条款中的数据处理位置条款和数据保护附录。 有关符合性信息，Microsoft 信任中心提供了适用于 Power BI 的大量资源。 Power BI 团队正在努力为客户提供最新创新和提高生产效率。 在Microsoft 合规性产品/服务中了解有关合规性的详细信息。
Power BI 服务遵循安全开发生命周期 (SDL)，即支持安全保证和合规性要求的严格安全做法。 SDL 通过减少软件中漏洞的数量和严重性，帮助开发人员构建更安全的软件，同时降低开发成本。 有关详细信息，请参阅 Microsoft 安全开发生命周期做法。
Power BI 体系结构
Power BI 服务基于 Azure 构建，后者是 Microsoft 的云计算平台。 Power BI 目前部署在世界各地的多个数据中心 – 在这些数据中心提供服务的区域，向客户提供了许多主动部署，以及相同数量的被动部署，被动部署用作每个主动部署的备份。
Web 前端群集 (WFE)
网站加载时，WFE 群集可向用户的浏览器提供初始 HTML 页面内容，以及指向用于在浏览器中呈现站点的 CDN 内容的指针。
WFE 群集由在 Azure 应用服务环境中运行的 ASP.NET 网站组成。 用户尝试连接到 Power BI 服务时，客户端的 DNS 服务可以与 Azure 流量管理器通信，以查找具有 Power BI 部署的最合适的（通常是最近的）数据中心。 有关此过程的详细信息，请参阅 Azure 流量管理器的性能流量路由方法。
静态资源（如 *.js、*.css 和图像文件）主要存储在 Azure 内容分发网络 (CDN) 上，并可由浏览器直接检索。 请注意，主权政府群集部署是此规则的例外，出于合规性原因，将省略 CDN，改用来自合规区域的 WFE 群集来托管静态内容。
Power BI 后端群集 (BE)
后端群集是 Power BI 中所有可用功能的主干。 它由 Web 前端客户端和 API 客户端使用的多个服务终结点以及后台工作服务、数据库、缓存和各种其他组件组成。
后端在大多数 Azure 区域中可用，并在新区域可用时部署在新区域中。 单个 Azure 区域托管一个或多个后端群集，一旦单个群集的垂直和水平缩放限制用尽，这些群集允许对 Power BI 服务进行无限制的水平缩放。
每个后端群集都是有状态的，并托管分配给该群集的所有租户的所有数据。 包含特定租户数据的群集称为租户的主群集。 经过身份验证的用户的主群集信息由全局服务提供，并由 Web 前端用于将请求路由到租户的主群集。
每个后端群集都由多个虚拟机组成，这些虚拟机组合成多个可调整大小的规模集，这些规模集针对特定任务的执行、有状态的资源（如 SQL 数据库、存储帐户、服务总线、缓存和其他必要的云组件）进行了优化。
租户元数据和数据存储在群集限制内，但数据复制到同一 Azure 地理位置中配对 Azure 区域中的辅助后端群集除外。 辅助后端群集在发生区域性中断时充当故障转移群集，并且在任何其他时间都是被动的。
后端功能由群集虚拟网络内不同计算机上运行的微服务提供，这些计算机不可从外部访问，但可从公共 Internet 访问的两个组件除外：
- 网关服务
- Azure API 管理
Power BI Premium 基础结构
Power BI Premium 为需要高级 Power BI 功能的订阅者提供服务，例如高级 AI、向未经许可的用户分发等。客户注册 Power BI Premium 订阅时，将通过 Azure 资源管理器创建高级容量。
Power BI Premium 容量托管在独立于常规 Power BI 后端的后端群集中 - 见上文）。 这为 Premium 产品/服务提供了更好的隔离、资源分配、可支持性、安全隔离和可伸缩性。
下图展示了 Power BI Premium 基础结构的体系结构：
可以通过多种方式实现与 Power BI Premium 基础结构的连接，具体取决于用户方案。 Power BI Premium 客户端可以是用户的浏览器、常规 Power BI 后端、通过 XMLA 客户端的直接连接、ARM API 等。
Azure 区域中的 Power BI Premium 基础结构由多个 Power BI Premium 群集组成（最小值为 1）。 大多数 Premium 资源都封装在群集（例如计算）中，并且提供了一些常见的区域资源（例如元数据存储）。 Premium 基础结构允许通过两种方式在区域中实现水平可伸缩性：增加群集内的资源和/或根据需要添加更多群集（如果群集资源接近其限制）。
每个群集的主干都是由虚拟机规模集 和 Azure Service Fabric 管理的计算资源。 虚拟机规模集和 Service Fabric 允许随着使用量的增长快速、轻松地增加计算节点，并协调 Power BI Premium 服务和应用程序的部署、管理和监视。
许多周边资源可以确保基础结构安全可靠：负载均衡器、虚拟网络、网络安全组、服务总线、存储等。Power BI Premium 所需的任何机密、密钥和证书由 Azure 密钥保管库专门管理。 任何身份验证都是通过独占方式与 Microsoft Entra ID 集成完成的。
传入 Power BI Premium 基础结构的任何请求将会首先转到前端节点 - 它们是可用于外部连接的唯一节点。 其余资源隐藏在虚拟网络后面。 前端节点对请求进行身份验证、处理请求或将其转发到相应的资源（例如后端节点）。
后端节点提供大多数 Power BI Premium 功能和特性。
Power BI 移动版
Power BI 移动版是专为三个主要移动平台设计的应用集合：Android、iOS 和 Windows (UWP)。 Power BI 移动版应用的安全注意事项分为两类：
- 设备通信
- 设备上的应用程序和数据
对于设备通信，所有 Power BI 移动版应用程序都与 Power BI 服务进行通信，并使用浏览器使用的相同连接和身份验证序列，本白皮书前面部分对此进行了详细介绍。 适用于 iOS 和 Android 的 Power BI 移动版应用程序在应用程序内启动浏览器会话，而 Windows 移动版应用启动中转站以与 Power BI 建立通信通道（用于登录过程）。
下表按移动设备平台列出了对 Power BI 移动版的基于证书的身份验证 (CBA) 的支持：
| CBA 支持 | iOS | Android | Windows |
|---|---|---|---|
| Power BI（登录服务） | 支持 | 支持 | 不支持 |
| SSRS ADFS 本地（连接到 SSRS 服务器） | 不支持 | 支持 | 不支持 |
| SSRS 应用代理 | 支持 | 支持 | 不支持 |
Power BI 移动版应用主动与 Power BI 服务进行通信。 遥测用于收集移动应用使用情况统计数据和类似数据，这些数据传输到用于监视使用情况和活动的服务；遥测数据中未发送个人数据。
Power BI 应用程序在设备上存储有助于使用应用的数据：
- Microsoft Entra ID 和刷新令牌存储在设备上的安全机制中，使用行业标准安全措施。
- 数据和设置（用于用户配置的键值对）缓存在设备上的存储中，可由操作系统加密。 在 iOS 中，当用户设置密码时，会自动执行此操作。 在 Android 中，可以在设置中配置此项。 在 Windows 中，它是通过使用 BitLocker 来实现的。
- 对于 Android 和 iOS 应用，数据和设置（用于用户配置的键值对）缓存在沙盒中设备的存储中，以及只能由应用访问的内部存储中。
- 地理位置由用户显式启用或禁用。 如果启用，则不会在设备上保存地理位置数据，也不会与 Microsoft 共享。
- 通知由用户显式启用或禁用。 如果启用，Android 和 iOS 将不支持通知的地理数据驻留要求。
可以通过 Microsoft Intune 应用文件级加密来增强数据加密，Microsoft Intune 是一种提供移动设备和应用程序管理的软件服务。 Power BI 移动版可用的所有三个平台都支持 Intune。 启用并配置 Intune 后，将会加密移动设备上的数据，并且 Power BI 应用程序本身无法安装在 SD 卡上。 了解有关 Microsoft Intune 的详细信息。
Windows 应用还支持 Windows 信息保护 (WIP)。
为了实现 SSO，某些与基于令牌的身份验证相关的安全存储值可用于其他 Microsoft 第一方应用（如 Microsoft Authenticator），并由 Microsoft 身份验证库 (MSAL) 管理。
删除应用、用户注销 Power BI 移动版或用户登录失败（例如在令牌过期事件或密码更改后）时，将删除 Power BI 移动版缓存数据。 数据缓存包括以前从 Power BI 移动版应用访问的仪表板和报表。
Power BI 移动版不会访问设备上的其他应用程序文件夹或文件。
适用于 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 服务的连接。 使用 TLS 和 HTTPS 建立连接，浏览器和 Power BI 服务之间的所有后续通信都使用 HTTPS。
Azure 流量管理器检查用户的 DNS 记录，以确定部署 Power BI 的最合适的（通常是最近的）数据中心，并使用应将用户发送到其中的 WFE 群集的 IP 地址响应 DNS。
然后，WFE 将 HTML 页面返回到浏览器客户端，其中包含发起登录流所需的 MSAL.js 库引用。
浏览器客户端会加载从 WFE 接收的 HTML 页面，并将用户重定向到 Microsoft 联机服务登录页面。
对用户进行身份验证后，登录页面会使用身份验证代码将用户重定向回 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 会将客户数据存储在 Azure 地理位置中，该地理位置是在 Microsoft Entra 租户首次注册 Power BI 服务时分配的。 Microsoft Entra 租户包含用户和应用程序标识、组以及与组织及其安全性相关的其他相关信息。
租户数据存储的 Azure 地理位置分配是通过将在 Microsoft Entra 租户设置过程中选择的国家或地区映射到存在 Power BI 部署的最合适的 Azure 地理位置来完成的。 做出此决定后，所有 Power BI 客户数据都将存储在此选定的 Azure 地理位置（也称为主地理位置）中，组织使用多地理位置部署的情况除外。
多地理位置
某些组织具有全球业务，可能需要多个 Azure 地理位置中的 Power BI 服务。 例如，一家企业的总部可能在美国，但也可能在其他地理区域开展业务，例如澳大利亚。 在这种情况下，企业可能要求某些 Power BI 数据保持静态存储在远程区域中，以符合当地法规。 Power BI 服务的此功能称为“多地理位置”。
分配给多地理位置工作区的查询执行层、查询缓存和项目数据托管并保留在远程容量 Azure 地理位置中。 但是，某些项目元数据（如报表结构）可能仍静态存储在租户的主地理位置中。 此外，某些数据传输和处理可能仍发生在租户的主地理位置中，即使是托管在多地理位置 Premium 容量中的工作区也是如此。
有关创建和管理跨多个 Azure 地理位置的 Power BI 部署的详细信息，请参阅为 Power BI Premium 配置多地理位置支持。
区域和数据中心
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 数据库中的客户数据使用 Azure SQL 的透明数据加密 (TDE) 技术进行完全加密。 存储在 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 服务将应用该行级别安全性，并且因凭据不足而无法访问基础数据（这可能是仪表板、报表或其他数据项目中使用的查询）的用户将看不到他们无权查看的数据。
Premium 功能
数据流体系结构
数据流使用户能够配置后端数据处理操作，这些操作将从多态数据源中提取数据，对数据执行转换逻辑，然后将其放入目标模型中，以便在各种报告呈现技术中使用。 在工作区中具有成员、参与者或管理员角色的任何用户都可以创建数据流。 具有查看者角色的用户可以查看数据流处理的数据，但不能更改其构成。 创作数据流后，工作区的任何成员、参与者或管理员都可以计划刷新，以及通过获取数据流的所有权来查看和编辑数据流。
每个配置的数据源都绑定到用于访问该数据源的客户端技术。 访问它们所需的凭据结构是按照数据源的所需实现详细信息而形成的。 转换逻辑由 Power Query 服务在数据运行时应用。 对于高级数据流，Power Query 服务在后端节点中执行。 可以直接从云源或通过本地安装的网关提取数据。 当直接从云源拉取到服务或网关时，传输将使用特定于客户端技术的保护方法（如果适用）。 将数据从网关传输到云服务时，会对其进行加密。 请参阅上面的传输中的数据部分。
当客户指定的数据源需要凭据进行访问时，数据流的所有者/创建者将在创作期间提供这些凭据。 它们是使用标准产品范围的凭据存储来存储的。 请参阅上面的对数据源进行身份验证部分。 用户可以配置多种方法来优化数据持久性和访问。 默认情况下，数据放置在 Power BI 拥有且受保护的存储帐户中。 在 Blob 存储容器上启用存储加密，以保护处于静态状态的数据。 请参阅下面的静态数据部分。 但是，用户可以配置自己的存储帐户，该帐户与自己的 Azure 订阅相关联。 执行此操作时，将向 Power BI 服务主体授予对该存储帐户的访问权限，以便它可以在刷新期间将数据写入该存储帐户。 在这种情况下，存储资源所有者负责在已配置的 ADLS 存储帐户上配置加密。 数据始终使用加密传输到 Blob 存储。
由于访问存储帐户时的性能对于某些数据可能不是最佳的，因此用户还可以选择使用 Power BI 托管的计算引擎来提高性能。 在这种情况下，数据以冗余方式存储在 SQL 数据库中，该数据库可通过后端 Power BI 系统的访问供 DirectQuery 使用。 数据始终在文件系统上加密。 如果用户提供用于加密存储在 SQL 数据库中的数据的密钥，则该密钥将用于对其进行双重加密。
使用 DirectQuery 进行查询时，将使用加密的传输协议 HTTPS 来访问 API。 DirectQuery 的所有次要或间接使用都由前面所述的相同访问控制进行控制。 由于数据流始终绑定到工作区，因此对数据的访问始终由该工作区中的用户角色控制。 用户必须至少具有读取访问权限才能通过任何方式查询数据。
使用 Power BI Desktop 访问数据流中的数据时，它必须先使用 Microsoft Entra ID 对用户进行身份验证，以确定用户是否有足够的权限来查看数据。 如果有，则会获取 SaS 密钥，并用于使用加密传输协议 HTTPS 直接访问存储。
整个管道中的数据处理会发出 Office 365 审核事件。 其中一些事件将捕获与安全和隐私相关的操作。
分页报表
分页报表是设计用于打印或共享的报表。 它们被称为“分页”，因为它们已进行了格式化，以适应页面。 即使某个表跨多个页，分页报表也能显示表中的所有数据。 你可以精确控制报表页面布局。
分页报表支持用 Microsoft Visual Basic .NET 编写的丰富且功能强大的表达式。 表达式在 Power BI Report Builder 分页报表中被广泛用于检索、计算、显示、分组、排序、筛选、参数化和格式化数据。
表达式由报表的作者创建，该作者可以访问 .NET 框架的各种功能。 分页报表的处理和执行在沙盒中执行。
分页报表定义 (.rdl) 存储在 Power BI 中，若要发布和/或呈现分页报表，用户需要按照上面对 Power BI 服务进行身份验证部分中所述的相同方式进行身份验证和授权。
身份验证期间获取的 Microsoft Entra 令牌用于直接从浏览器与 Power BI Premium 群集进行通信。
在 Power BI Premium 中，Power BI 服务运行时为每个报表呈现器提供适当隔离的执行环境。 这包括呈现的报表属于分配给相同容量的工作区的情况。
分页报表可以在呈现报表过程中访问一组广泛的数据源。 沙盒不直接与任何数据源通信，而是与受信任的进程通信以请求数据，然后受信任的进程将所需的凭据追加到连接。 通过此方法，沙盒将永远无权访问任何凭据或机密。
为了支持必应地图或调用 Azure Functions 等功能，沙盒可以访问 Internet。
Power BI Embedded 分析
独立软件供应商 (ISV) 和解决方案提供商在其 Web 应用程序和门户中嵌入 Power BI 项目有两种主要模式：为组织嵌入和为客户嵌入。 项目嵌入到应用程序或门户中的 IFrame 中。 不允许 IFrame 从外部 Web 应用程序或门户读取或写入数据，并且与 IFrame 的通信是通过使用 POST 消息的 Power BI 客户端 SDK 完成的。
在为组织嵌入方案中，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会自动将加密的嵌入令牌作为“Authorization: EmbedToken”标头追加到 Power BI 请求。 基于此标头，Power BI 将完全按照 ISV 在生成期间指定的策略（例如访问或 RLS）强制实施所有策略。
为了启用嵌入和自动化，并生成上述嵌入令牌，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 视觉对象、聚类分析、预测、问答、快速见解等功能。AI 扩充功能包括 AutoML、Azure 机器学习、认知服务、R/Python 转换等功能。
目前，Shared 工作区和 Premium 工作区都支持上述大多数功能。 但是，由于 IP 限制，AutoML 和 CognitiveService 仅在 Premium 工作区中受支持。 目前，借助 Power BI 中的 AutoML 集成，用户可以生成和训练自定义 ML 模型（例如预测、分类、回归等），并在将数据加载到 Premium 工作区中定义的数据流时应用它来获取预测。 此外，Power BI 用户可以应用多个 CognitiveServices API（如 TextAnalytics 和 ImageTagging），在将数据加载到 Premium 工作区中定义的数据流/语义模型之前对其进行转换。
Premium AI 扩充功能最好被视为 Power BI 用户在其 Power BI 语义模型或数据流使用的数据集成管道中使用的无状态 AI 函数/转换的集合。 请注意，还可以从 Power BI 服务和 Power BI Desktop 中的当前数据流/语义模型创作环境访问这些函数。 这些 AI 函数/转换始终在 Premium 工作区/容量中运行。 这些函数在 Power BI 中显示为数据源，该数据源需要使用 AI 函数的 Power BI 用户的 Microsoft Entra 令牌。 这些 AI 数据源的特殊性在于它们并不呈现自己的任何数据，并且只提供这些函数/转换。 在执行期间，这些功能不会向其他服务进行任何出站调用来传输客户的数据。 我们将单独查看 Premium 方案，以了解通信模式以及与它们相关的安全相关详细信息。
为了训练和应用 AutoML 模型，Power BI 使用 Azure AutoML SDK，并在客户的 Power BI 容量中运行所有训练。 在训练迭代期间，Power BI 可调用试验 Azure 机器学习服务，以便为当前迭代选择合适的模型和超参数。 在此出站调用中，将仅发送来自上一次迭代的相关试验元数据（例如，准确度、ml 算法、算法参数等）。 AutoML 训练生成 ONNX 模型和训练报告数据，然后将其保存在数据流中。 然后，Power BI 用户可以将训练后的 ML 模型应用为转换，以便按计划操作 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)。
有关其他信息，请参阅用于访问 Power BI 的专用链接。
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 支持使用服务主体。 将用于加密或访问 Power BI 的任何服务主体凭据存储在密钥保管库中，为保管库分配适当的访问策略，并定期审核访问权限。
有关其他详细信息，请参阅使用服务主体自动完成 Premium 工作区和语义模型任务。
适用于 Power BI 的 Microsoft Purview
Microsoft Purview 信息保护
Power BI 数据保护已与 Microsoft Purview 信息保护集成深度集成。 Microsoft Purview 信息保护使组织能够跨 Azure、Power BI 和 Office 拥有用于分类、标记、审核和确保合规的单一集成解决方案。
在 Power BI 中启用信息保护时：
- 可以使用 Office 和 Azure 中使用的相同敏感度标签对 Power BI 服务和 Power BI Desktop 中的敏感数据进行分类和标记。
- 在将 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 服务中的自动下游敏感度标签可确保在应用或更改语义模型或数据市场上的标签时，将自动对连接到语义模型或数据市场的所有下游内容应用或更改标签。
有关详细信息，请参阅 Power BI 中的敏感度标签。
适用于 Power BI 的 Microsoft Purview 数据丢失防护 (DLP) 策略
Microsoft Purview 的 DLP 策略有助于组织降低 Power BI 中敏感业务数据泄露的风险。 DLP 策略有助于组织满足欧盟《一般数据保护条例》(GDPR) 或《加利福尼亚州消费者隐私保护法》(CCPA) 等政府或行业法规的合规性要求，并确保其在 Power BI 中的数据得到管理。
设置 Power BI 的 DLP 策略后：
- 策略中指定的工作区中的所有语义模型都由策略进行评估。
- 可以检测敏感数据何时上传到 Premium 容量。 DLP 策略可以检测：
- 敏感度标签。
- 敏感信息类型。 支持超过 260 种类型。 敏感信息类型检测依赖于 Microsoft Purview 内容扫描。
- 遇到标识为敏感的语义模型时，可以看到自定义的策略提示，可帮助你了解应执行的操作。
- 如果你是语义模型所有者，则可以覆盖策略并防止将语义模型标识为“敏感”（如果有正当理由这样做）。
- 如果你是语义模型所有者，则可以在断定敏感信息类型被错误识别时报告策略问题。
- 可以调用自动风险缓解措施，例如向安全管理员发出警报。
有关详细信息，请参阅 Power BI 和 Fabric Power BI 的数据丢失防护策略。
适用于 Power BI 的 Microsoft Defender for Cloud Apps
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 控件。
预览安全功能
本部分列出了计划在 2021 年 3 月发布的功能。 由于本主题列出了可能尚未发布的功能，因此交付时间线可能会更改，预计功能可能会晚于 2021 年 3 月发布，或者可能根本不发布。 有关预览版的详细信息，请查看联机服务条款。
Bring Your Own Log Analytics (BYOLA)
Bring Your Own Log Analytics 可实现 Power BI 和 Azure Log Analytics 之间的集成。 此集成包括 Azure Log Analytics 的高级分析引擎、交互式查询语言和内置的机器学习构造。
Power BI 安全问题与解答
以下问题是 Power BI 的常见安全问题和解答。 这些内容按其添加到本白皮书的时间进行组织，以便在本文更新时快速找到新的问题和答案。 最新的问题将添加到此列表的末尾。
在使用 Power BI 时，用户如何连接并访问数据源？
Power BI 管理每个用户的数据源凭据，以获取云凭据或通过个人网关进行连接。 本地数据网关管理的数据源可以跨企业共享，这些数据源的权限可由网关管理员管理。配置语义模型时，允许用户从其个人存储中选择凭据，或通过本地数据网关使用共享凭据。
在导入情况下，用户可基于用户的登录建立连接，并使用凭据访问数据。 将语义模型发布到 Power BI 服务后，Power BI 始终使用此用户的凭据导入数据。 导入数据后，查看报表和仪表板中的数据不会访问基础数据源。 Power BI 支持对所选数据源进行单一登录身份验证。 如果连接配置为使用单一登录，则使用语义模型所有者的凭据与数据源连接。
对于与 DirectQuery 连接的报表，将会使用预配置的凭据直接连接数据源，并在任何用户查看数据时使用预配置的凭据连接到数据源。 如果使用单一登录直接连接数据源，则当用户查看数据时，将使用当前用户的凭据连接到数据源。 使用单一登录时，可以在数据源上实现行级别安全性 (RLS) 和/或对象级别安全性 (OLS)，这允许用户查看他们有权访问的数据。 当连接到云中的数据源时，Microsoft Entra ID 身份验证用于单一登录；对于本地数据源，支持 Kerberos、SAML 和 Microsoft Entra ID。
与 Kerberos 连接时，用户的 UPN 将传递到网关，并使用 Kerberos 约束委派，模拟用户并连接到相应的数据源。 SAP HANA 网关数据源也支持 SAML。 有关详细信息，请参阅网关的单一登录概述。
如果数据源是 Azure Analysis Services 或本地 Analysis Services，并且配置了行级别安全性 (RLS) 和/或对象级别安全性 (OLS)，则 Power BI 服务将应用该行级别安全性，并且因凭据不足而无法访问基础数据（这可能是仪表板、报表或其他数据项目中使用的查询）的用户将看不到他们无权访问的数据。
Power BI 行级别安全性可用于限制给定用户的数据访问。 筛选器限制行级数据访问，你可以在角色中定义筛选器。
对象级别安全性 (OLS) 可用于保护敏感表或列。 但是，与行级别安全性不同，对象级别安全性还保护对象名称和元数据。 这有助于防止恶意用户发现此类对象的存在。 在使用 Excel 或 Power BI 等报表工具时，将会遮盖字段列表中受保护的表和列，此外，没有权限的用户无法通过 DAX 或任何其他方法访问受保护的元数据对象。 从没有适当访问权限的用户的角度来看，受保护的表和列根本不存在。
对象级别安全性与行级别安全性一起增强了报表和语义模型的企业级别安全性，确保只有具有必要权限的用户才能查看敏感数据并与之交互。
如何将数据传输到 Power BI？
- Power BI 请求和传输的所有数据在传输过程中使用 HTTPS 进行加密（客户选择的数据源不支持 HTTPS 的情况除外），以便从数据源连接到 Power BI 服务。 与数据提供程序建立安全连接，并且只有在建立了该连接后，数据才能遍历网络。
Power BI 如何缓存报表、仪表板或模型数据，以及缓存是否安全？
- 访问数据源时，Power BI 服务将遵循本文档前面的对数据源进行身份验证部分中概述的过程。
客户端是否在本地缓存网页数据？
- 浏览器客户端访问 Power BI 时，Power BI Web 服务器会将“Cache-control”指令设置为“no-store”。 “no-store”指令指示浏览器不缓存用户正在查看的网页，并且不会将网页存储在客户端的缓存文件夹中。
什么是基于角色的安全性、共享报表或仪表板以及数据连接？ 数据访问、仪表板查看、报表访问或刷新如何工作？
对于启用了非角色级别安全性 (RLS)的数据源，如果通过 Power BI 与其他用户共享仪表板、报表或数据模型，则该数据将可供获得共享的用户进行查看并与其交互。 Power BI 不会针对原始数据源重新验证用户身份；将数据上传到 Power BI 后，对源数据进行身份验证的用户将负责管理可以查看数据的其他用户和组。
与支持 RLS 的数据源（例如，Analysis Services 数据源）建立数据连接时，仅在 Power BI 中缓存仪表板数据。 每次在 Power BI 中查看或访问使用支持 RLS 的数据源中的数据的报表或语义模型时，Power BI 服务都会访问数据源以根据用户的凭据获取数据。如果存在足够的权限，则将数据加载到该用户的报表或数据模型中。 如果身份验证失败，用户将看到错误。
有关详细信息，请参阅本文档前面的对数据源进行身份验证部分。
用户始终连接到相同的数据源，其中一些数据源需要与其域凭据不同的凭据。 用户如何避免每次连接数据时都必须输入这些凭据？
- Power BI 提供了 Power BI Personal Gateway，该功能允许用户为多个不同的数据源创建凭据，随后在访问这些数据源时可自动使用这些凭据。 有关详细信息，请参阅 Power BI Personal Gateway。
本地数据网关和个人网关使用哪些端口？ 是否有任何需要允许用于连接的域名？
- 有关此问题的详细答案，请访问以下链接：网关端口
使用本地数据网关时，如何使用恢复密钥以及密钥存储在何处？ 什么是安全凭据管理？
在网关安装和配置期间，管理员键入网关“恢复密钥”。 该恢复密钥用于生成强 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 的 WebSocket + TLS：此协议仅使用端口 443。 WebSocket 由单个 HTTP CONNECT 消息发起。 建立通道后，通信实质上是 TCP+TLS。 可以通过修改本地网关文章中描述的设置，强制网关使用此协议。
Azure CDN 在 Power BI 中的角色是什么？
如前所述，Power BI 使用 Azure 内容分发网络 (CDN) 来有效地根据地理区域设置将所需的静态内容和文件分发到用户。 为了进一步详细说明，Power BI 服务使用多个 CDN 通过公共 Internet 有效地将所需的静态内容和文件分发到用户。 这些静态文件包括产品下载（如 Power BI Desktop、本地数据网关或来自各个独立服务提供商的 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 订阅的客户的连接？ 这些连接是否与为非 Premium Power BI 服务建立的连接不同？
- 使用 Power BI Premium 订阅为客户建立的连接实现了 Microsoft Entra 企业到企业（B2B） 授权过程，使用 Microsoft Entra ID 启用访问控制和授权。 Power BI 处理从 Power BI 订阅者到 Power BI 资源的连接，就像处理任何其他 Microsoft Entra 用户一样。
服务器端身份验证在 WFE 中如何工作？
- 用户身份验证序列服务端身份验证如以下步骤中所述进行，这些步骤后面的图像对此进行了说明。
用户通过在地址栏中键入 Power BI 地址或从 Power BI 市场页面 () 中选择“登录”，从浏览器发起与 Power BI 服务的连接。 使用 TLS 1.2 和 HTTPS 建立连接，浏览器和 Power BI 服务之间的所有后续通信都使用 HTTPS。
Azure 流量管理器检查用户的 DNS 记录，以确定部署 Power BI 的最合适的（通常是最近的）数据中心，并使用应将用户发送到其中的 WFE 群集的 IP 地址响应 DNS。
WFE 随后会将用户重定向到 Microsoft 联机服务登录页面。
对用户进行身份验证后，登录页会使用身份验证代码将用户重定向到之前确定的最近的 Power BI 服务 WFE 群集。
WFE 群集使用 Microsoft Entra ID 检查，以使用身份验证代码获取 Microsoft Entra 安全令牌。 当 Microsoft Entra ID 返回用户的成功身份验证并返回 Azure AD 安全令牌时，WFE 群集将咨询 Power BI 全局服务，该服务维护租户及其 Power BI 后端群集位置的列表，并确定哪个 Power BI 后端服务群集包含用户的租户。 然后，WFE 群集将应用程序页返回到用户的浏览器，其中包含其操作所需的会话、访问和路由信息。
现在，当客户端的浏览器需要客户数据时，它会使用授权标头中的 Microsoft Entra 访问令牌向后端群集地址发送请求。 Power BI 后端群集读取 Microsoft Entra 访问令牌并验证签名，以确保请求的标识有效。 Microsoft Entra 访问令牌将根据 Microsoft Entra 策略设置到期日期，为了维护当前会话，用户浏览器中的 Power BI 客户端将定期请求在访问令牌过期之前续订该令牌。
其他资源
有关 Power BI 的更多信息，请参阅以下资源。