Power Platform 安全性常见问题解答
关于 Power Platform 安全性的常见问题分为两类：
Power Platform 的设计如何帮助缓解前 10 大 Open Web Application Security Project® (OWASP) 风险
客户提问
为了方便您查找最新信息，新问题被添加到本文末尾。
OWASP 前 10 大风险：Power Platform 中的缓解措施
Open Web Application Security Project® (OWASP) 是一个致力于提高软件安全性的非营利性基金会。 通过社区主导的开放源代码项目、全球数百个分会、数以万计的成员以及领先的教育和培训会议，OWASP 基金会成为了开发人员和技术人员保护网络安全的来源。
OWASP top 10 是适用于开发人员以及其他对 Web 应用程序安全性感兴趣的人的标准认知文档。 它代表了对 Web 应用程序最严重的安全风险的广泛共识。 本节将讨论 Power Platform 如何帮助缓解这些风险。
- Power Platform 安全模型基于最低特权访问 (LPA) 构建。 LPA 使客户能够构建具有更精细访问控制的应用程序。
- Power Platform 使用 Microsoft Entra ID 的（Microsoft Entra ID） Microsoft Identity Platform 对行业标准 OAuth 2.0 协议的所有 API 调用进行授权。
- Dataverse 为 Power Platform 提供基础数据，具有丰富的安全模型，包括环境级别、基于角色以及记录和字段级安全性。
传输中的数据：
- Power Platform 使用 TLS 加密所有基于 HTTP 的网络流量。 它使用其他机制来加密包含客户数据或机密数据的非 HTTP 网络流量。
- Power Platform 采用强化的 TLS 配置，支持 HTTP 严格传输安全性 (HSTS)：
- TLS 1.2 或更高版本
- 基于 ECDHE 的密码套件和 NIST 曲线
- 强密钥
静态数据：
- 所有客户数据在写入非易失性存储介质之前都会被加密。
Power Platform 使用行业标准最佳实践来防止注入攻击，包括：
- 将安全 API 与参数化接口一同使用
- 应用不断发展的前端框架功能来清理输入
- 使用服务器端验证功能清理输出
- 在生成期间使用静态分析工具
- 无论是否已更新代码、设计或基础结构，每六个月都审查一次每项服务的威胁模型
- Power Platform 建立在安全设计的文化和方法之上。 通过 Microsoft行业领先的 安全开发生命周期 （SDL）和 威胁建模 实践，文化和方法都得到了不断加强。
- 威胁建模审查流程可确保在设计阶段识别威胁，并缓解和验证威胁，以确保威胁已得到缓解。
- 威胁建模还考虑通过持续的定期检查对已投入使用的服务进行的所有更改。 依靠 STRIDE 模型有助于解决最常见的不安全设计问题。
- Microsoft的 SDL 相当于 OWASP 软件保障成熟度模型 （SAMM）。 两者都建立在安全设计对于 Web 应用程序安全性不可或缺的前提之上。
- “默认拒绝”是 Power Platform 设计原则的基础之一。 使用“默认拒绝”，客户需要查看并选择加入新功能和配置。
- 生成期间的任何错误配置都将使用安全开发工具通过集成式安全分析来捕获。
- 此外，Power Platform 使用基于“OWASP 前 10 大风险”构建的内部服务进行动态分析安全测试 (DAST)。
- Power Platform 遵循 Microsoft SDL 的做法来管理 开源和第三方组件。 这些实践包括维护完整的库存、执行安全分析、使组件保持最新，并使组件符合经过试用和测试的安全事件响应流程。
- 在极少数情况下，由于外部依赖关系，某些应用程序可能包含过时组件的副本。 不过，在根据前面概述的实践处理这些依赖关系之后，将跟踪和更新这些组件。
- Power Platform 基于 Microsoft Entra ID 而构建，依赖它进行标识和身份验证。
- Microsoft Entra 帮助 Power Platform 启用安全功能。 这些功能包括单一登录、多重身份验证和单一平台，实现更安全地与内部和外部用户联系。
- 随着 Power Platform 即将实施 Microsoft Entra ID 连续访问评估 (CAE)，用户识别和身份验证将更加安全和可靠。
- Power Platform 的组件治理流程强制执行包源文件的安全配置以维护软件完整性。
- 此流程确保只提供内部来源的包来解决替代攻击。 替代攻击也称为依赖项混淆，是一种可用于在安全企业环境中破坏应用构建流程的方法。
- 所有加密数据在传输之前都经过了完整性保护。 所有用于传入加密数据的完整性保护元数据都将得到验证。
OWASP 十大低代码/无代码风险：Power Platform 中的缓解措施
有关减轻 OWASP 发布的 10 大低代码/无代码安全风险的指导，请参见以下文档：
Power Platform - OWASP 低代码无代码 10 大风险（2024 年 4 月）
客户的常见安全问题
以下是我们的客户提出的一些安全问题。
Power Platform 如何帮助防范点击劫持？
点击劫持使用 嵌入式 iframe 以及其他组件来劫持用户与网页的交互。 特别是对于登录页面，这将构成重大威胁。 Power Platform 阻止在登录页面上使用 iframe，从而大大降低点击劫持的风险。
此外，组织可以使用内容安全策略 (CSP) 将嵌入限制在受信任的域。
Power Platform 是否支持内容安全策略？
Power Platform 支持模型驱动应用的内容安全策略 (CSP)。 我们不支持以下由 CSP 替换的标头：
X-XSS-ProtectionX-Frame-Options
如何安全地连接到 SQL Server？
请参阅安全地将 Microsoft SQL Server 与 Power Apps 配合使用。
Power Platform 支持哪些密码？ 不断向更安全的密码迈进的路线图是什么？
所有 Microsoft 服务和产品都配置为按照 Crypto Board 指示 Microsoft 的确切顺序使用批准的密码套件。 要获取完整列表和精确顺序，请参阅 Power Platform 文档。
有关密码套件弃用的信息将通过 Power Platform 的重要更改文档来传达。
为什么 Power Platform 仍然支持被认为较不安全的 RSA-CBC 密码（TLS_ECDHE_RSA_with AES_128_CBC_SHA256 (0xC027) 和 TLS_ECDHE_RSA_with_AES_256_CBC_SHA384 (0xC028)）？
Microsoft 权衡在选择要支持的密码套件时客户运营的相对风险和中断。 RSA-CBC 密码套件尚未断开。 我们启用它们来确保我们的服务和产品的一致性，以及支持所有客户配置。 但是，它们位于优先级列表的底部。
我们将根据 Microsoft Crypto Board 的持续评估，在适当的时候弃用这些密码。
为什么 Power Automate 在触发器/操作输入和输出中公开 MD5 内容哈希？
Power Automate 会按原样将 Azure 存储返回的可选 content-MD5 哈希值传递给客户端。 Azure 存储将此哈希用作校验和算法，用于在传输期间验证页面的完整性，在 Power Automate 中，出于安全目的，它不用作加密哈希函数。 您可以在 Azure 存储文档中找到有关如何获取 Blob 属性以及如何使用请求标头的更多详细信息。
Power Platform 如何防御分布式拒绝服务 (DDoS) 攻击？
Power Platform 基于 Microsoft Azure 构建，并使用 Azure DDoS 防护来防御 DDoS 攻击。
Power Platform 是否会检测越狱的 iOS 设备和取得 root 权限的 Android 设备来帮助保护组织数据？
建议使用 Microsoft Intune。 Intune 是一个移动设备管理解决方案。 它可以通过要求用户和设备满足某些要求来帮助保护组织数据。 有关详细信息，请参阅 Intune 的合规性策略设置。
为什么会话 Cookie 的范围是父域？
Power Platform 将会话 Cookie 限定为父域，以允许跨组织进行身份验证。 子域不用作安全边界。 也不托管客户内容。
比如，我们如何将应用程序会话设置为在 15 分钟后超时？
Power Platform 使用 Microsoft Entra ID 进行标识和访问管理。 它采用 Microsoft Entra ID 的建议会话管理配置来提供最佳用户体验。
但是，您可以自定义环境，使环境具有明确的会话和/或活动超时。 有关详细信息，请参阅用户会话和访问管理。
随着 Power Platform 即将实施 Microsoft Entra ID 连续访问评估，用户识别和身份验证将更加安全和可靠。
该应用程序允许同一用户同时从多台计算机或多种浏览器进行访问。 我们如何防止这种情况发生？
同时从多台设备或多种浏览器访问应用程序对用户来说很方便。 Power Platform 即将实施的 Microsoft Entra ID 连续访问评估将有助于确保访问来自授权设备和浏览器并且仍然有效。
为什么某些 Power Platform 服务会公开带有详细信息的服务器标头？
Power Platform 服务一直在努力删除服务器标头中不必要的信息。 目的是在详细级别与可能削弱整体安全态势的暴露信息的风险之间取得平衡。
Log4j 漏洞如何影响 Power Platform？ 客户应该对此执行哪些措施？
Microsoft 已评估 Log4j 漏洞没有影响 Power Platform。 请参阅我们关于阻止、检测和搜寻对 Log4j 漏洞的利用的博客文章。
我们如何确保没有因浏览器扩展或统一接口客户端 API 允许启用禁用的控件而导致的未经授权的交易？
Power Apps 安全模型不包括禁用控件概念。 禁用控件是一项 UI 增强。 您不应依赖禁用控件来提供安全性。 而应改用 Dataverse 安全控件（如字段级安全性）来阻止未经授权的交易。
哪些 HTTP 安全标头用于保护响应数据？
| 客户 | Details |
|---|---|
| 严格传输安全 | 这在所有响应中都设置为 max-age=31536000; includeSubDomains。 |
| X 框架选项 | 这已弃用，取而代之的是 CSP。 |
| X- 内容类型选项 | 这在所有资产响应中设置为 nosniff。 |
| 内容安全策略 | 如果用户启用 CSP 则设置此项。 |
| X-XSS 保护 | 这已弃用，取而代之的是 CSP。 |
我在哪里可以找到 Power Platform 或 Dynamics 365 渗透测试？
最新的渗透测试和安全评估可以在 Service Trust Portal 上找到 Microsoft 。
备注
要访问 Service Trust Portal 上的某些资源，您必须使用云服务 Microsoft 账户（Microsoft Entra 组织账户）以经过身份验证的用户身份登录，并查看并接受 Microsoft 合规性材料的保密协议。
相关文章
安全性 Microsoft Power Platform
对服务进行身份验证 Power Platform
连接数据源并对其进行身份验证
数据存储 Power Platform