[Power BI]Power BI安全白皮书

语言 Chinese, Simplified

SEO Title

介绍

Power BI是Microsoft提供的一种在线软件服务（SaaS或软件即服务），可让您轻松快速地创建自助式商业智能仪表板、报告、语义模型和可视化。使用Power BI，您可以连接到许多不同的数据源，组合和塑造这些连接中的数据，然后创建可以与他人共享的报告和仪表板。

世界正在迅速变化；组织正在经历加速的数字化转型，我们看到远程工作的大幅增加，客户对在线服务的需求增加，以及在运营和业务决策中越来越多地使用先进技术。所有这些都是由云提供动力的。

随着向云的过渡从涓涓细流变成了洪水，以及随之而来的新的暴露表面区域，越来越多的公司开始问我的云中数据有多安全？有什么端到端的保护措施可以防止我的敏感数据泄露？对于经常处理企业中一些最具战略意义的信息的BI平台来说，这些问题具有双重重要性。

BI安全模型几十年的基础——对象级和行级安全——虽然仍然很重要，但显然不再足以提供云时代所需的安全性。相反，组织必须为其商业智能数据寻找云原生、多层、深度防御的安全解决方案。

Power BI旨在为数据提供业界领先的完整和密封保护。该产品已获得业内最高的安全分类，如今许多国家安全机构、金融机构和医疗保健提供者将其最敏感的信息委托给它。

这一切都始于基础。在21世纪初的一段艰难时期之后，微软进行了大量投资来解决其安全漏洞，并在接下来的几十年里建立了一个强大的安全堆栈，其深度与机器片上bios内核相当，并一直延伸到最终用户体验。这些深度投资仍在继续，如今有3500多名微软工程师正在构建和增强微软的安全堆栈，并积极应对不断变化的威胁形势。凭借数十亿台计算机、数万亿次登录和无数泽字节的信息委托给微软保护，该公司现在拥有科技行业最先进的安全堆栈，并被广泛视为打击恶意行为者的全球领导者。

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构建。Power BI目前部署在世界各地的许多数据中心——在这些数据中心服务的地区，有许多主动部署可供客户使用，也有相同数量的被动部署作为每个主动部署的备份。

WFE和后端

Web前端集群（WFE）

WFE集群为用户的浏览器提供网站加载时的初始HTML页面内容，以及指向用于在浏览器中呈现网站的CDN内容的指针。

WFE

WFE集群由ASP。NET网站在Azure应用服务环境中运行。当用户尝试连接到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区域中的辅助后端群集除外。辅助后端群集在发生区域性停机时充当故障转移群集，在任何其他时间都是被动的。

后端功能由运行在集群虚拟网络中不同机器上的微服务提供，这些机器无法从外部访问，但可以从公共互联网访问的两个组件除外：

网关服务
Azure API管理

后端集群

Power BI高级基础设施

Power BI Premium为需要高级Power BI功能（如高级AI、向未授权用户分发等）的订阅者提供服务。当客户注册Power BI Premium订阅时，将通过Azure资源管理器创建Premium容量。

Power BI Premium容量托管在独立于常规Power BI后端的后端集群中（见上文）。这为Premium产品提供了更好的隔离、资源分配、可支持性、安全隔离和可扩展性。

下图说明了Power BI Premium基础架构的架构：

Power BI高级版

根据用户场景，可以通过多种方式连接到Power BI Premium基础架构。Power BI Premium客户端可以是用户的浏览器、常规的Power BI后端、通过XMLA客户端的直接连接、ARM API等。

Azure区域中的Power BI Premium基础架构由多个Power BI Premium群集组成（最少一个）。大多数高级资源都封装在集群中（例如，计算），还有一些常见的区域资源（例如，元数据存储）。高级基础架构允许在一个地区实现横向可扩展性的两种方式：增加集群内的资源和/或根据需要添加更多集群（如果集群资源接近极限）。

每个集群的骨干是由虚拟机规模集和Azure服务结构管理的计算资源。虚拟机规模集和服务结构允许随着使用量的增长快速无痛地增加计算节点，并协调Power BI Premium服务和应用程序的部署、管理和监控。

有许多周围的资源可以确保安全可靠的基础设施：负载平衡器、虚拟网络、网络安全组、服务总线、存储等。Power BI Premium所需的任何秘密、密钥和证书都由Azure密钥库专门管理。任何身份验证都是通过与Microsoft Entra ID（以前称为Azure Active Directory）的集成来完成的。

Power BI Premium基础架构的任何请求都会首先到达前端节点——它们是唯一可用于外部连接的节点。其余的资源隐藏在虚拟网络后面。前端节点对请求进行身份验证、处理或将其转发到适当的资源（例如后端节点）。

后端节点提供了Power BI Premium的大部分功能和特性。

Power BI移动版

Power BI Mobile是为三个主要移动平台（Android、iOS和Windows（UWP））设计的应用程序集合。Power BI Mobile应用程序的安全考虑分为两类：

设备通信
设备上的应用程序和数据

对于设备通信，所有Power BI Mobile应用程序都与Power BI服务通信，并使用浏览器使用的相同连接和身份验证序列，本白皮书前面对此进行了详细描述。iOS和Android的Power BI移动应用程序会在应用程序本身中启动浏览器会话，而Windows移动应用程序则会启动一个代理程序，与Power BI建立通信渠道（用于登录过程）。

下表显示了基于移动设备平台的Power BI Mobile的基于证书的身份验证（CBA）支持：

CBA support	iOS	Android	Windows
Power BI (sign in to service)	Supported	Supported	Not supported
SSRS ADFS on-premises (connect to SSRS server)	Not supported	Supported	Not supported
SSRS App Proxy	Supported	Supported	Not supported

Power BI Mobile应用程序主动与Power BI服务通信。遥测用于收集移动应用程序使用统计数据和类似数据，这些数据被传输到用于监控使用情况和活动的服务；遥测技术不会发送客户数据。

Power BI应用程序在设备上存储数据，以方便使用该应用程序：

Microsoft Entra ID和刷新令牌使用行业标准安全措施存储在设备上的安全机制中。
数据和设置（用户配置的键值对）缓存在设备上的存储器中，可以由操作系统加密。在iOS中，当用户设置密码时，这会自动完成。在Android中，可以在设置中配置。在Windows中，它是通过使用BitLocker来实现的。
对于Android和iOS应用程序，数据和设置（用户配置的键值对）缓存在设备上的沙盒和内部存储中，只有应用程序可以访问。对于Windows应用程序，数据只能由用户（和系统管理员）访问。
地理定位由用户明确启用或禁用。如果启用，地理位置数据不会保存在设备上，也不会与Microsoft共享。
通知由用户明确启用或禁用。如果启用，Android和iOS不支持通知的地理数据驻留要求。

通过Microsoft Intune应用文件级加密可以增强数据加密，Microsoft Intune是一种提供移动设备和应用程序管理的软件服务。Power BI Mobile可用的所有三个平台都支持Intune。启用并配置Intune后，移动设备上的数据将被加密，Power BI应用程序本身无法安装在SD卡上。了解有关Microsoft Intune的更多信息。

Windows应用程序还支持Windows信息保护（WIP）。

为了实现SSO，与基于令牌的身份验证相关的一些安全存储值可用于其他Microsoft第一方应用程序（如Microsoft Authenticator），并由Microsoft身份验证库（SSO）管理。

当应用程序被删除、用户退出Power BI Mobile或用户无法登录时（例如在令牌过期事件或密码更改后），Power BI Mobile缓存的数据将被删除。数据缓存包括以前从Power BI Mobile应用程序访问的仪表板和报告。

Power BI Mobile无法访问设备上的其他应用程序文件夹或文件。

iOS和Android的Power BI应用程序允许您通过配置其他身份来保护您的数据，例如为iOS提供Face ID、Touch 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将客户数据存储在Azure地理位置中，该地理位置是在Microsoft Entra租户首次注册Power BI服务时分配的。Microsoft Entra租户包含用户和应用程序身份、组以及与组织及其安全相关的其他相关信息。

为租户数据存储分配Azure地理位置是通过将作为Microsoft Entra租户设置的一部分选择的国家或地区映射到存在Power BI部署的最合适的Azure地理位置来完成的。一旦做出此决定，所有Power BI客户数据都将存储在此选定的Azure地理位置（也称为家庭地理位置）中，除非组织使用多地理位置部署。

多个地理区域（多地理区域）

一些组织具有全球影响力，可能需要在多个Azure地区提供Power BI服务。例如，一家企业的总部可能设在美国，但也可能在其他地理区域开展业务，如澳大利亚。在这种情况下，企业可能需要将某些Power BI数据静态存储在远程区域，以遵守当地法规。Power BI服务的这一功能被称为多地理。

分配给多地理工作区的查询执行层、查询缓存和工件数据托管在远程容量Azure地理中。然而，一些工件元数据（如报告结构）可能仍存储在租户的家庭地理位置中。此外，一些数据传输和处理仍可能发生在租户的家庭地理位置，即使是以多地理高级容量托管的工作区。

有关创建和管理跨多个Azure地理区域的Power BI部署的更多信息，请参阅Power BI Premium的配置多地理支持。

区域和数据中心

Power BI服务在特定的Azure地区可用，如Microsoft信任中心所述。有关数据存储位置和使用方式的详细信息，请参阅Microsoft信任中心。有关静止客户数据位置的承诺在Microsoft Online Services条款的数据处理条款中进行了规定。

微软还为主权实体提供数据中心。有关国家/地区云的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语义模型允许各种数据源连接模式，以确定数据源数据是否持久化在服务中。

Semantic Model Mode (Kind)	Data Persisted in Power BI
Import	Yes
DirectQuery	No
Live Connect	No
Composite	If contains an Import data source
Streaming	If configured to persist

无论使用何种语义模型模式，Power BI都可以临时缓存任何检索到的数据，以优化查询和报告负载性能。

数据处理中

当数据被一个或多个用户作为交互场景的一部分积极使用时，或者当刷新等后台进程接触到这些数据时，数据正在处理中。Power BI将主动处理的数据加载到一个或多个服务工作负载的内存空间中。为了方便工作负载所需的功能，内存中的处理数据没有加密。

传输中的数据

Power BI要求所有传入的HTTP流量都使用TLS 1.2或更高版本进行加密。任何试图使用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服务主体被授予对该存储帐户的访问权限，以便在刷新期间将数据写入其中。在这种情况下，存储资源所有者负责在配置的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编写的丰富而强大的表达式。网。表达式在Power BI Report Builder的分页报告中被广泛使用，用于检索、计算、显示、分组、排序、过滤、参数化和格式化数据。

表达式由报告作者创建，可以访问的广泛功能。NET框架。分页报告的处理和执行是在沙盒内执行的。

分页报告定义（.rdl）存储在Power BI中，要发布和/或呈现分页报告，用户需要以与上述Power BI服务身份验证部分所述相同的方式进行身份验证和授权。

在身份验证过程中获得的Microsoft Entra令牌用于从浏览器直接与Power BI Premium群集通信。

在Power BI Premium中，Power BI服务运行时为每个报告呈现提供了一个适当隔离的执行环境。这包括呈现的报告属于分配给相同容量的工作区的情况。

分页报告可以访问大量数据源，作为报告呈现的一部分。沙箱不直接与任何数据源通信，而是与受信任的进程通信以请求数据，然后受信任进程将所需的凭据附加到连接中。通过这种方式，沙盒永远无法访问任何凭据或秘密。

为了支持Bing地图或对Azure Functions的调用等功能，沙盒确实可以访问互联网。

Power BI嵌入式分析

独立软件供应商（ISV）和解决方案提供商在其web应用程序和门户中嵌入Power BI工件有两种主要模式：为您的组织嵌入和为您的客户嵌入。工件被嵌入到应用程序或门户中的IFrame中。IFrame不允许从外部web应用程序或门户读取或写入数据，与IFrame的通信是通过使用Power BI Client SDK使用POST消息完成的。

在为您的组织嵌入场景中，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-visual、Python可视化、聚类、预测、问答、快速洞察等功能。AI丰富功能包括AutoML、Azure机器学习、认知服务、R/Python转换等功能。

目前，共享和高级工作区都支持上述大多数功能。但是，由于IP限制，AutoML和CognitiveServices仅在高级工作区中受支持。如今，通过Power BI中的AutoML集成，用户可以构建和训练自定义ML模型（例如，预测、分类、回归等），并在将数据加载到高级工作区中定义的数据流中时应用它来获得预测。此外，Power BI用户可以应用几个CognitiveServices API，如TextAnalytics和ImageTagging，在将数据加载到高级工作区中定义的数据流/语义模型之前对其进行转换。

高级AI丰富功能最好被视为无状态AI功能/转换的集合，Power BI用户可以在Power BI语义模型或数据流使用的数据集成管道中使用这些功能/转换。请注意，这些功能也可以从Power BI服务和Power BI桌面中的当前数据流/语义模型创作环境中访问。这些AI功能/转换始终在高级工作区/容量中运行。这些功能在Power BI中作为数据源出现，需要为使用AI功能的Power BI用户提供Microsoft Entra令牌。这些人工智能数据源很特殊，因为它们不显示任何自己的数据，只提供这些功能/转换。在执行过程中，这些功能不会向其他服务发出任何出站呼叫来传输客户的数据。让我们单独查看高级场景，以了解通信模式和与之相关的安全相关细节。

为了培训和应用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中创建数据模型时，用户只有在有权访问高级Power BI工作区的情况下才能访问此功能。因此，系统会提示客户提供其Microsoft Entra凭据。

网络隔离

本节概述了Power BI中的高级安全功能。其中一些功能有特定的许可要求。请参阅以下章节了解详细信息。

服务标签

服务标签表示给定Azure服务的一组IP地址前缀。它有助于将频繁更新网络安全规则的复杂性降至最低。客户可以使用服务标签在网络安全组或Azure防火墙上定义网络访问控制。客户在创建安全规则时可以使用服务标签代替特定的IP地址。通过在规则的相应源或目标（API）字段中指定服务标记名称（如PowerBI），客户可以允许或拒绝相应服务的流量。Microsoft管理服务标记所包含的地址前缀，并在地址更改时自动更新服务标记。

Private Link集成

Azure网络提供Azure专用链接功能，使Power BI能够通过Azure网络专用端点提供安全访问。通过Azure Private Link和私有端点，数据流量使用微软的骨干网络基础设施进行私有发送，因此数据不会通过互联网传输。

Private Link确保Power BI用户在访问Power BI服务中的资源时使用Microsoft专用网络骨干网。

将Private Link与Power BI结合使用具有以下好处：

Private Link确保流量将通过Azure骨干网流向基于Azure云的资源的专用端点。
与非基于Azure的基础架构（如本地访问）的网络流量隔离将要求客户配置ExpressRoute或虚拟专用网络（VPN）。

有关更多信息，请参阅访问Power BI的专用链接。

VNet connectivity

虽然Private Link集成功能提供了到Power BI的安全入站连接，但ExpressRoute连接功能实现了从Power BI到Contoso内数据源的安全出站连接。

Contoso网关（由Microsoft管理）消除了安装和监控本地数据网关以连接到与Contoso关联的数据源的开销。然而，它们仍然遵循熟悉的管理安全和数据源的过程，就像使用本地数据网关一样。

以下是当您与Power BI报告交互时会发生什么的概述，该报告使用ExpressRoute网关连接到ExpressRoute中的数据源：

Power BI云服务（或其他受支持的云服务之一）启动查询，并将查询、数据源详细信息和凭据发送到Power Platform ExpressRoute服务（PP ExpressRoute）。
然后，PP ViewModel服务将一个运行ExpressRoute网关的容器安全地注入子网。此容器现在可以连接到此子网内可访问的数据服务。
然后，PP Contoso服务将查询、数据源详细信息和凭据发送到Contoso网关。
ExpressRoute网关获取查询，并使用这些凭据连接到数据源。
然后将查询发送到数据源以供执行。
执行后，结果将被发送到Contoso网关，PP Contoso服务将数据从容器安全地推送到Power BI云服务。

服务主体

Power BI支持使用服务主体。将用于加密或访问Power BI的任何服务主体凭据存储在密钥保管库中，为保管库分配适当的访问策略，并定期检查访问权限。

有关更多详细信息，请参阅使用服务主体自动化高级工作区和语义模型任务。

Microsoft Purview for Power BI

Microsoft权限信息保护

Power BI与Microsoft权限信息保护深度集成。Microsoft权限信息保护使组织能够拥有一个单一的集成解决方案，用于跨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服务中的自动下游敏感性标签可确保在应用或更改语义模型或数据集市上的标签时，该标签将自动应用于或更改连接到语义模型或数据库的所有下游内容。
有关更多信息，请参阅Power BI中的灵敏度标签。

Microsoft授权Power BI的数据丢失防护（DLP）策略

Microsoft Permissions的DLP政策可帮助组织降低Power BI中敏感业务数据泄露的风险。DLP政策帮助他们满足政府或行业法规的合规要求，如GDPR（欧盟通用数据保护条例）或CCPA（加州消费者隐私法），并确保他们在Power BI中的数据得到管理。

设置Power BI的DLP策略时：

策略中指定的工作区内的所有语义模型都由策略评估。
您可以检测敏感数据何时上传到您的高级容量中。DLP策略可以检测：
- 灵敏度标签。
- 敏感信息类型。支持260多种类型。敏感信息类型检测依赖于Microsoft权限内容扫描。
当您遇到被标识为敏感的语义模型时，您可以看到一个定制的策略提示，帮助您了解应该做什么。
如果您是语义模型所有者，您可以覆盖策略，并在有正当理由的情况下防止您的语义模型被识别为“敏感”。
如果您是语义模型所有者，如果您认为敏感信息类型被错误识别，则可以报告策略问题。
可以调用自动风险缓解措施，例如向安全管理员发出警报。
有关更多信息，请参阅Power BI的数据丢失预防策略。

Microsoft Defender for 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活动日志调查Power BI用户活动。Defender for Cloud Apps活动日志包括Office 365审核日志中捕获的Power BI活动，其中包含有关所有用户和管理员活动的信息，以及应用、更改和删除标签等相关活动的敏感标签信息。管理员可以利用Defender for Cloud Apps高级过滤器和快速操作进行有效的问题调查。
在Power BI中创建自定义策略以提醒可疑的用户活动。可以利用云应用活动策略功能的Defender来定义自己的自定义规则，帮助您检测偏离规范的用户行为，甚至在看起来太危险的情况下自动采取行动。
使用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进行云应用控制。

预览安全功能

本节列出了计划于2021年3月发布的功能。由于本主题列出了可能尚未发布的功能，交付时间表可能会发生变化，预计功能可能会在2021年3月之后发布，或者可能根本不会发布。有关预览的更多信息，请查看在线服务条款。

自带日志分析（BYOLA）

自带日志分析功能可实现Power BI和Azure日志分析之间的集成。此集成包括Azure日志分析的高级分析引擎、交互式查询语言和内置的机器学习结构。

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的行级安全可用于限制给定用户的数据访问。筛选器在行级别限制数据访问，您可以在角色内定义筛选器。

对象级安全（OLS）可用于保护敏感表或列。然而，与行级安全不同，对象级安全还保护对象名称和元数据。这有助于防止恶意用户发现此类对象的存在。使用Excel或Power BI等报告工具时，字段列表中的安全表和列会被遮挡，此外，没有权限的用户无法通过DAX或任何其他方法访问安全的元数据对象。从没有适当访问权限的用户的角度来看，安全的表和列根本不存在。

对象级安全性和行级安全性可增强报告和语义模型的企业级安全性，确保只有具有必要权限的用户才能查看敏感数据并与之交互。

数据如何传输到Power BI？

Power BI请求和传输的所有数据在传输过程中都使用HTTPS进行加密（客户选择的数据源不支持HTTPS时除外），以便从数据源连接到Power BI服务。与数据提供者建立安全连接，只有建立了连接，数据才会通过网络传输。
Power BI如何缓存报告、仪表板或模型数据，它是否安全？

当访问数据源时，Power BI服务会遵循本文档前面“数据源身份验证”一节中概述的过程。

客户端是否在本地缓存网页数据？

当浏览器客户端访问Power BI时，Power BI web服务器将缓存控制指令设置为无存储。no store指令指示浏览器不要缓存用户正在查看的网页，也不要将网页存储在客户端的缓存文件夹中。

基于角色的安全性、共享报告或仪表板以及数据连接呢？这在数据访问、仪表板查看、报告访问或刷新方面是如何工作的？

对于未启用角色级安全性（RLS）的数据源，如果通过Power BI与其他用户共享仪表板、报告或数据模型，则与之共享数据的用户可以查看和交互这些数据。Power BI不会根据原始数据源对用户进行重新身份验证；数据上传到Power BI后，根据源数据进行身份验证的用户负责管理哪些其他用户和组可以查看数据。

当与支持RLS的数据源（如Analysis Services数据源）建立数据连接时，Power BI中只缓存仪表板数据。每次在使用支持RLS数据源的数据的Power BI中查看或访问报告或语义模型时，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上的WebSockets：此协议仅使用端口443。WebSocket由单个HTTP CONNECT消息启动。一旦通道建立，通信基本上就是TCP+TLS。您可以通过修改本地网关文章中描述的设置来强制网关使用此协议。

Azure CDN在Power BI中的作用是什么？

如前所述，Power BI使用Azure内容分发网络（CDN）根据地理区域有效地向用户分发必要的静态内容和文件。更详细地说，Power BI服务使用多个CDN通过公共互联网高效地向用户分发必要的静态内容和文件。这些静态文件包括产品下载（如Power BI Desktop、本地数据网关或来自各种独立服务提供商的Power BI应用程序）、用于启动和建立与Power BI服务的任何后续连接的浏览器配置文件，以及初始安全的Power BI登录页面。

根据与Power BI服务的初始连接期间提供的信息，用户的浏览器会联系指定的Azure CDN（或对于某些文件，WFE），下载浏览器与Power BI服务器交互所需的指定通用文件集合。然后，浏览器页面包括Microsoft Entra令牌、会话信息、相关后端集群的位置，以及在Power BI服务浏览器会话期间从Azure CDN和WFE集群下载的文件集合。

对于Power BI视觉效果，在将项目发布到库之前，Microsoft是否对自定义视觉代码进行了任何安全或隐私评估？

不是。客户有责任审查和确定是否应该依赖自定义视觉代码。所有自定义可视化代码都在沙盒环境中运行，因此自定义可视化中的任何错误代码都不会对Power BI服务的其余部分产生不利影响。

是否有其他Power BI视觉效果可以将信息发送到客户网络之外？

对。Bing地图和ESRI视觉效果将数据从Power BI服务中传输出来，用于使用这些服务的视觉效果。

对于模板应用程序，Microsoft在将项目发布到库之前是否对模板应用程序进行任何安全或隐私评估？

不可以。应用程序发布者对内容负责，而客户有责任审查并确定是否信任模板应用程序发布商。

是否有可以在客户网络之外发送信息的模板应用程序？

对。客户有责任审查发布者的隐私政策，并确定是否在租户上安装模板应用程序。发布者负责向客户告知应用程序的行为和功能。
那么数据主权呢？我们能否为位于特定地理位置的数据中心的租户提供服务，以确保数据不会离开国家或地区边界？

某些地区的一些客户可以选择在国家/地区云中创建租户，在那里数据存储和处理与所有其他数据中心分开。国家/地区云的安全类型略有不同，因为一个单独的数据受托人代表微软运营国家/地区的云Power BI服务。

或者，客户也可以在特定地区设置租户。然而，这些租户没有与微软分开的数据受托人。国家/地区云的定价不同于通常可用的商业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客户端将在访问令牌到期前定期请求续订。

Additional resources

For more information on Power BI, see the following resources.

本文地址

https://architect.pub/power-bi-security-white-paper

登录发表评论
11 次浏览

发布日期

星期二, 八月 27, 2024 - 15:22

最后修改

星期二, 八月 27, 2024 - 17:00

热门内容

今日:

总体:

最近浏览：

category

介绍