此安全基线将 Azure 安全基准版本 2.0 中的指南应用到 Power BI。 Azure 安全基准提供有关如何在 Azure 上保护云解决方案的建议。 内容按 Azure 安全基准定义的 安全控制 以及适用于 Power BI 的相关指南进行分组。
当某个功能具有相关的 Azure Policy 定义时，这些定义将列在此基线中，以帮助衡量 Azure 安全基准控件和建议的符合性。 某些建议可能需要使用付费 Microsoft Defender 计划来启用特定的安全方案。
注意
已排除不适用于 Power BI 的控件以及建议逐字使用全局指导的控件。 若要查看 Power BI 如何完全映射到 Azure 安全基准，请参阅 完整的 Power BI 安全基线映射文件。
网络安全
有关详细信息，请参阅 Azure 安全基准：网络安全。
NS-3：建立对 Azure 服务的专用网络访问权限
指导：Power BI 支持将 Power BI 租户连接到专用链接终结点并禁用公共 Internet 访问。
责任：共享
NS-4：保护应用程序和服务不受外部网络攻击
指导：Power BI 是完全托管的 SaaS 产品/服务，内置了拒绝服务保护，Microsoft管理。 客户无需执行任何操作即可保护服务免受外部网络攻击。
责任：Microsoft
NS-7：安全域名服务（DNS）
指导：不适用;Power BI 不公开其基础 DNS 配置，这些设置由Microsoft维护。
责任：Microsoft
标识管理
有关详细信息，请参阅 Azure 安全基准：标识管理。
IM-1：将 Azure Active Directory 标准化为中央标识和身份验证系统
指导：Power BI 与 Azure Active Directory（Azure AD）集成，这是 Azure 的默认标识和访问管理服务。 应在 Azure AD 上标准化，以管理组织的标识和访问管理。
在组织的云安全做法中，应优先处理 Azure AD 保护事宜。 Azure AD 提供标识安全分数，帮助你评估与 Microsoft 的最佳做法建议相关的标识安全状况。 使用评分来估计你的配置与最佳做法建议的匹配程度，并改善你的安全状况。
注意：Azure AD 支持外部标识，使没有Microsoft帐户的用户能够使用其外部标识登录到其应用程序和资源。
责任：客户
IM-2：安全且自动地管理应用程序标识
指导：Power BI 和 Power BI Embedded 支持使用服务主体。 将用于加密或访问 Power BI 的任何服务主体凭据存储在密钥库中，将适当的访问策略分配给保管库并定期查看访问权限。
责任：客户
IM-3：使用 Azure AD 单一登录 (SSO) 进行应用程序访问
指导：Power BI 使用 Azure Active Directory （Azure AD）为 Azure 资源、云应用程序和本地应用程序提供标识和访问管理。 此内容包括企业标识（例如员工）以及外部标识（如合作伙伴和供应商）。 这样，单一登录 (SSO) 便可以管理和保护对本地和云中的组织数据和资源的访问。 将所有用户、应用程序和设备连接到 Azure AD，实现无缝的安全访问和更好的可见性和控制。
责任：客户
IM-7：消除意外凭据泄露
指导：对于 Power BI 嵌入式应用程序，建议实现凭据扫描程序来识别代码中的凭据。 凭据扫描程序还会建议将发现的凭据转移到更安全的位置，例如 Azure Key Vault。
将用于加密或访问 Power BI 的任何加密密钥或服务主体凭据存储在密钥库中，将适当的访问策略分配给保管库并定期查看访问权限。
对于 GitHub，可以使用本机机密扫描功能来标识代码中的凭据或其他形式的机密。
责任：共享
特权访问
有关详细信息，请参阅 Azure 安全基准：特权访问。
PA-1：保护和限制高特权用户
指导：为了降低风险并遵循最低特权原则，建议将 Power BI 管理员的成员身份保留为少数人。 具有这些特权权限的用户可能会访问和修改组织的所有管理功能。 全局管理员可通过 Microsoft 365 或 Azure Active Directory (Azure AD) 隐式拥有 Power BI 服务中的管理员权限。
Power BI 具有以下高特权帐户：
- 全局管理员
- 计费管理员
- 许可证管理员
- 用户管理员
- Power BI 管理员
- Power BI Premium 容量管理员
- Power BI Embedded 容量管理员
Power BI 支持 Azure AD 中的会话策略，以通过 Microsoft Defender for Cloud Apps 服务启用 Power BI 中使用的条件访问策略和路由会话。
使用 Microsoft 365 中的特权访问管理，为 Power BI 管理员帐户启用即时 (JIT) 特权访问。
责任：客户
PA-3：定期审查和协调用户访问权限
指导：作为 Power BI 服务管理员，可以使用基于 Power BI 活动日志的自定义报表分析租户级别所有 Power BI 资源的使用情况。 可以使用 REST API 或 PowerShell cmdlet 下载活动。 还可以按日期范围、用户和活动类型筛选活动数据。
必须满足以下要求才能访问 Power BI 活动日志：
- 必须是全局管理员或Power BI 服务管理员。
- 你已在本地安装 Power BI Management cmdlet ，或使用 Azure Cloud Shell 中的 Power BI 管理 cmdlet。
满足这些要求后，可以按照以下指南跟踪 Power BI 中的用户活动：
责任：客户
PA-6：使用特权访问工作站
指导：安全隔离的工作站对于管理员、开发人员和关键服务作员等敏感角色的安全性至关重要。 使用高度安全的用户工作站和/或 Azure Bastion 执行与管理 Power BI 相关的管理任务。 使用 Azure Active Directory (Azure AD)、Microsoft Defender 高级威胁防护 (ATP) 和/或 Microsoft Intune 来部署安全的托管用户工作站，以便执行管理任务。 可以集中管理安全工作站，以强制实施安全配置，包括强身份验证、软件和硬件基线、受限逻辑和网络访问。
责任：客户
数据保护
有关详细信息，请参阅 Azure 安全基准：数据保护。
DP-1：对敏感数据进行发现、分类和标记
指导：在报表、仪表板、数据集和数据流上使用来自 Microsoft Purview 信息保护的敏感度标签来保护敏感内容，防止未经授权的数据访问和泄露。
使用Microsoft Purview 信息保护 Power BI 服务中的敏感度标签对报表、仪表板、数据集和数据流进行分类和标记，并在将内容从Power BI 服务导出到 Excel、PowerPoint 和 PDF 文件时防止未经授权的数据访问和泄露。
责任：客户
DP-2：保护敏感数据
指导：Power BI 与来自 Microsoft Purview 信息保护的敏感度标签集成，用于敏感数据保护。 有关更多详细信息，请参阅 Power BI 中 Microsoft Purview 信息保护中的敏感度标签
Power BI 允许服务用户自带密钥来保护静态数据。 有关详细信息，请参阅 为 Power BI 创建自己的加密密钥
客户可以选择在本地保留数据源，并利用直接查询或实时连接与本地数据网关，以最大程度地减少数据暴露给云服务。 有关详细信息，请参阅 什么是本地数据网关？
Power BI 支持行级别安全性。 有关更多详细信息，请参阅 Power BI 的行级别安全性（RLS）。 请注意，甚至可以将 RLS 应用于直接查询数据源，在这种情况下，PBIX 文件充当启用代理的安全。
责任：客户
DP-3：监视未经授权的敏感数据传输
指导：此控制可以通过利用 Microsoft Defender for Cloud Apps 支持的 Power BI 来部分实现。
将 Microsoft Defender for Cloud Apps 与 Power BI 结合使用，可以帮助保护 Power BI 报表、数据和服务免遭意外泄漏或破坏。 借助 Microsoft Defender for Cloud Apps，可以使用 Azure Active Directory (Azure AD) 中的实时会话控制为组织的数据创建条件访问策略，这有助于确保 Power BI 分析是安全的。 设置这些策略后，管理员可以监视用户访问和活动、执行实时风险分析，以及设置特定于标签的控制。
责任：客户
DP-4：加密传输中的敏感信息
指导：确保针对 HTTP 流量，连接到 Power BI 资源的任何客户端和数据源都可以协商 TLS v1.2 或更高版本。
责任：客户
DP-5：加密静态敏感数据
指导：Power BI 对静态和进程中的数据进行加密。 默认情况下，Power BI 使用 Microsoft 托管密钥来加密数据。 组织可以选择使用自己的密钥在 Power BI 中静态加密用户内容，从报表图像到高级容量中的导入数据集。
责任：共享
资产管理
有关详细信息，请参阅 Azure 安全基准：资产管理。
AM-1：确保安全团队可以了解与资产相关的风险
指导：将 Microsoft Sentinel 与 Power BI Office 审核日志配合使用，以确保安全团队能够了解 Power BI 资产的风险。
责任：客户
AM-2：确保安全团队有权访问资产清单和元数据
指导：确保安全团队有权访问持续更新的 Power BI Embedded 资源清单。 安全团队通常需要此清单来评估组织可能面临新兴风险的风险，并作为持续安全改进的投入。
Azure Resource Graph 可以查询和发现订阅中的所有 Power BI Embedded 资源。
根据组织的分类，使用标记以及 Azure 中的其他元数据（名称、说明和类别）以逻辑方式组织资产。
责任：客户
AM-3：仅使用已批准的 Azure 服务
指导：Power BI 支持基于 Azure 资源管理器的 Power BI Embedded 部署，并且可以使用自定义策略定义通过 Azure Policy 限制其资源的部署。
使用 Azure Policy 审核和限制用户可以在环境中预配的服务。 使用 Azure Resource Graph 查询和发现订阅中的资源。 你也可以使用 Azure Monitor 来创建规则，以便在检测到未经批准的服务时触发警报。
责任：客户
日志记录和威胁检测
有关详细信息，请参阅 Azure 安全基准：日志记录和威胁检测。
LT-2：启用 Azure 标识和访问管理的威胁检测
指导：将 Power BI 中的任何日志转发到 SIEM，可用于设置自定义威胁检测。 此外，使用 Power BI 中的 Microsoft Defender for Cloud Apps 控件，通过 此处的指南启用异常检测。
责任：客户
LT-3：为 Azure 网络活动启用日志记录
指导：Power BI 是一种完全托管的 SaaS 产品/服务，基础网络配置和日志记录Microsoft负责。 对于使用专用链接的客户，可以使用某些日志记录和监视进行配置。
责任：共享
LT-4：为 Azure 资源启用日志记录
指导：使用 Power BI，可以使用两个选项来跟踪用户活动：Power BI 活动日志和统一审核日志。 这些日志都包含 Power BI 审核数据的完整副本，但存在一些主要差异，如下所示。
统一审核日志：
除了 Power BI 审核事件之外，还包括来自 SharePoint Online、Exchange Online、Dynamics 365 和其他服务的事件。
只有具有仅查看审核日志或审核日志权限的用户才有访问权限，例如全局管理员和审核员。
全局管理员和审核员可以使用 Microsoft 365 Defender 门户和 Microsoft Purview 合规门户搜索统一审核日志。
全局管理员和审核员可以使用 Microsoft 365 管理 API 和 cmdlet 下载审核日志条目。
将审核数据保留 90 天。
保留审核数据，即使租户移动到其他 Azure 区域也是如此。
Power BI 活动日志：
仅包括 Power BI 审核事件。
全局管理员和 Power BI 服务管理员具有访问权限。
目前还没有用于搜索活动日志的用户界面。
全局管理员和 Power BI 服务管理员可以使用 Power BI REST API 和管理 cmdlet 下载活动日志条目。
将活动数据保留 30 天。
当租户移动到其他 Azure 区域时，不会保留活动数据。
有关详细信息，请参阅以下参考文献：
责任：共享
LT-5：集中管理和分析安全日志
指导：Power BI，将日志集中到两个位置：Power BI 活动日志和统一审核日志。 这些日志都包含 Power BI 审核数据的完整副本，但存在一些主要差异，如下所示。
统一审核日志：
除了 Power BI 审核事件之外，还包括来自 SharePoint Online、Exchange Online、Dynamics 365 和其他服务的事件。
只有具有仅查看审核日志或审核日志权限的用户才有访问权限，例如全局管理员和审核员。
全局管理员和审核员可以使用 Microsoft 365 Defender 门户和 Microsoft Purview 合规门户搜索统一审核日志。
全局管理员和审核员可以使用 Microsoft 365 管理 API 和 cmdlet 下载审核日志条目。
将审核数据保留 90 天。
保留审核数据，即使租户移动到其他 Azure 区域也是如此。
Power BI 活动日志：
仅包括 Power BI 审核事件。
全局管理员和 Power BI 服务管理员具有访问权限。
目前还没有用于搜索活动日志的用户界面。
全局管理员和 Power BI 服务管理员可以使用 Power BI REST API 和管理 cmdlet 下载活动日志条目。
将活动数据保留 30 天。
当租户移动到其他 Azure 区域时，不会保留活动数据。
有关详细信息，请参阅以下参考文献：
责任：客户
LT-6：配置日志存储保留期
指导：根据合规性、法规和业务要求，为 Office 审核日志配置存储保留策略。
责任：客户
LT-7：使用批准的时间同步源
指导：Power BI 不支持配置自己的时间同步源。 Power BI 服务依赖于 Microsoft 时间同步源，不会向客户公开以允许其进行配置。
责任：Microsoft
安全状况和漏洞管理
有关详细信息，请参阅 Azure 安全基准：状况和漏洞管理。
PV-1：为 Azure 服务建立安全配置
指导：使用适合组织和安全立场的设置配置 Power BI 服务。 应仔细考虑访问服务以及内容以及工作区和应用安全性的设置。 请参阅 Power BI 企业部署白皮书中的 Power BI 安全性和数据保护。
责任：客户
PV-2：维持 Azure 服务的安全配置
指导：使用 Power BI 管理员 REST API 监视 Power BI 实例。
责任：客户
PV-3：为计算资源建立安全配置
指导：Power BI 是一种完全托管的 SaaS 产品/服务，该服务的基础计算资源由Microsoft进行保护和管理。
责任：Microsoft
PV-4：为计算资源维护安全配置
指导：Power BI 是一种完全托管的 SaaS 产品/服务，该服务的基础计算资源由Microsoft进行保护和管理。
责任：Microsoft
PV-5：安全存储自定义操作系统和容器映像
指导：Power BI 是一种完全托管的 SaaS 产品/服务，该服务的基础计算资源由Microsoft进行保护和管理。
责任：Microsoft
PV-6：执行软件漏洞评估
指导：Power BI 是一种完全托管的 SaaS 产品/服务，该服务的基础计算资源通过Microsoft进行扫描和管理。
责任：Microsoft
PV-7：快速自动修正软件漏洞
指导：Power BI 是一种完全托管的 SaaS 产品/服务，该服务的基础计算资源通过Microsoft进行扫描和管理。
责任：Microsoft
PV-8：执行定期攻击模拟
指导：根据需要，对 Azure 资源执行渗透测试或红团队活动，并确保修正所有关键安全发现。
请遵循 Microsoft 云渗透测试互动规则，确保你的渗透测试不违反 Microsoft 政策。 使用 Microsoft 红队演练策略和执行，以及针对 Microsoft 托管云基础结构、服务和应用程序执行现场渗透测试。
责任：共享
终结点安全性
有关详细信息，请参阅 Azure 安全基准：终结点安全性。
ES-1：使用终结点检测和响应 (EDR)
指导：Power BI 不会部署任何面向客户的计算资源，这要求客户配置终结点检测和响应（EDR）保护。 Power BI 的基础结构由 Microsoft 处理，其中包括反恶意软件和 EDR 处理。
责任：Microsoft
ES-2：使用集中管理的新式反恶意软件
指导：Power BI 不会部署任何面向客户的计算资源，这要求客户配置反恶意软件防护。 Power BI 的基础结构由 Microsoft 处理，其中包括反恶意软件扫描。
责任：Microsoft
ES-3：确保反恶意软件和签名已更新
指导：Power BI 不会部署任何面向客户的计算资源，因此不要求客户确保反恶意软件签名的一致更新。 Power BI 的基础结构由 Microsoft 处理，其中包括所有反恶意软件处理。
责任：Microsoft
备份和恢复
有关详细信息，请参阅 Azure 安全基准：备份和恢复。
BR-3：验证所有备份，包括客户管理的密钥
指导：如果在 Power BI 中使用“自带密钥”（BYOK）功能，则需要定期验证是否可以访问和还原客户管理的密钥。
责任：客户
BR-4：降低丢失密钥的风险
指导：如果在 Power BI 中使用“自带密钥”（BYOK）功能，则需要确保使用以下 Power BI 文档中 BYOK 中的指南配置控制客户管理的密钥的 Key Vault。 在 Azure 密钥库中启用软删除和清除保护，防止密钥意外或恶意删除。
对于网关密钥资源，请确保遵循以下网关恢复密钥文档中的指导。
责任：客户
后续步骤
- 请参阅 Azure 安全基准 V2 概述
- 详细了解 Azure 安全基线