通过

有关保护应用程序机密的建议

  • 项目

适用于此 Power Platform Well-Architected 安全检查表建议：

东南：07 通过强化应用程序机密的存储、限制访问和操作以及审核这些操作来保护应用程序机密。 运行可靠且定期的轮换过程，以便为紧急情况临时轮换。

本指南介绍了保护工作负载中敏感信息的建议。 正确管理机密对于维护应用程序、工作负载和相关数据的安全性和完整性至关重要。 机密处理不当可能导致数据泄露、服务中断、违反法规和其他问题。

API 密钥、Open Authorization（）OAuth 令牌和安全外壳（SSH）密钥等凭据是密钥。 合规性要求可能会导致通常不被视为机密的配置设置被视为应用程序机密。

定义

术语 定义
证书 保存用于加密或解密的公钥的数字文件。
凭据 用于在通信渠道中验证发布者或使用者身份的信息。
凭据扫描 验证源代码以确保不包含机密的过程。
加密 使用机密代码使数据不可读和锁定的过程。
项 用于锁定或解锁加密数据的机密代码。
最小特权访问 一个零信任原则，旨在最大程度地减少一组完成工作职能的权限。
托管标识 分配给资源并由 Azure 管理的标识。
非机密 如果泄露，不会危及工作负载的安全状况的信息。
旋转 定期更新机密的过程，以便在机密遭到泄露时，它们仅在有限的时间内可用。
机密 系统的机密组件，用于促进工作负载组件之间的通信。 如果泄露，机密可能会导致泄露。
X.509 定义公钥证书格式的标准。

重要提示

不要将非机密视为机密。 机密需要操作严格，这是非机密不必要的，这可能会导致额外的成本。

应用程序配置设置（例如应用程序使用的 API 的 URL）是非机密的示例。此信息不应与应用程序代码或应用程序机密一起存储。 要存储应用程序配置，请考虑使用自定义连接器或环境变量。 另一种选择是使用 Dataverse 表来存储关于应用程序配置的元数据。 然而，您需要找到在新环境中填充这些数据的方法，比如将配置数据从开发转移到测试或生产。 您可以使用数据流来实现这一点。

关键设计策略

在存储和管理机密之前，请考虑以下几个方面：

  • 创建的机密应保存在具有严格访问控制的安全存储中。
  • 机密轮换是主动操作，而吊销是被动的。
  • 只有受信任的标识才有权访问机密。
  • 应保留审核线索来检查和验证对机密的访问权限。

围绕这些要点构建策略，以帮助防止身份盗用、避免抵赖，并最大限度减少不必要的信息暴露。

机密管理的安全做法

建议密钥具有三个不同的角色：用户、管理员和审核员。 角色区分有助于确保只有受信任的标识才能访问具有适当权限级别的机密。 向开发人员、管理员和其他相关人员介绍机密管理和安全最佳做法的重要性。

预共享密钥

可以通过为每个使用者创建不同的密钥来控制访问。 例如，客户端（例如应用或流）使用预共享密钥与第三方 API 通信。 如果另一个客户端需要访问同一 API，则必须使用另一个密钥。 即使两个使用者具有相同的访问模式或角色，也不要共享密钥。 使用者范围可能会随时间而更改，在共享密钥后，您无法独立更新权限或区分使用模式。 不同的访问也使吊销更容易。 如果使用者的密钥泄露，则撤销或轮换该密钥会更容易，而不会影响其他使用者。

本指南适用于不同的环境。 不应将同一密钥用于预生产和生产环境。 如果你负责创建预共享密钥，请确保创建多个密钥以支持多个客户端。

有关更多信息，请参阅标识和访问管理的建议。。

机密存储

使用机密管理系统（如 Azure Key Vault）将机密存储在强化环境中，加密静态和传输中机密，以及审核对机密的访问和更改。 如果需要存储应用程序机密，请将其保存在源代码之外，以便于轮换。

使用专用的机密管理系统可以轻松存储、分发和控制对应用程序机密的访问。 只有经过授权的标识和服务才有权访问机密存储。 可以通过权限限制对系统的访问。 分配权限时，始终应用最低特权方法。

还需要在机密级别控制访问。 每个机密应仅有权访问单个资源范围。 创建隔离边界，使组件只能使用所需的机密。 如果隔离组件遭到入侵，则它无法控制其他机密，甚至无法控制整个工作负载。 隔离机密的一种方法是使用多个密钥保管库。 创建额外的密钥保管库不会增加成本。

对机密访问实施审核和监视。 记录访问机密的人员以及何时识别未经授权的或可疑活动。 有关从安全角度进行日志记录的信息，请参阅有关安全监视和威胁检测的建议。

机密轮换

制定一个保持机密卫生的流程。 机密的寿命会影响该机密的管理。 为了减少攻击途径，应尽可能频繁地停用机密并替换为新机密。

谨慎处理 OAuth 访问令牌，同时考虑其生存时间。 考虑曝光时段是否需要调整为较短的时间段。 刷新令牌必须安全地存储，对应用程序进行有限公开。 续订的证书还应使用新的密钥。 有关刷新令牌的信息，请参阅 Secure OAuth 2.0 On-Behalf-Of 刷新令牌。

在生命周期结束之后替换机密，不再被工作负载使用，或者如果它们已遭到入侵，请替换它们。 相反，除非是紧急情况，否则不要停用活动机密。 可以通过查看访问日志来确定机密的状态。 机密轮换过程不应影响工作负荷的可靠性或性能。 使用策略在机密、使用者和访问方法中构建冗余，实现平稳轮换。

使用机密的安全做法

作为机密生成人或操作员，你应该能够以安全的方式分发机密。 许多组织使用工具在组织内部和外部与合作伙伴安全地共享机密。 在没有工具的情况下，要有一个适当的流程将凭据交给授权的接收者。 灾难恢复计划应包括机密恢复过程。 针对密钥泄露或泄露后需要按需重新生成的情况，请创建一个流程。 使用机密时，请考虑以下安全最佳做法：

防止硬编码

不要在代码项目（如云端流和画布应用程序、配置文件和构建部署管道）中将机密硬编码为静态文本 。 这种高风险做法会使代码易受攻击，因为机密会向具有读取访问权限的每个人公开。

使用定期检测应用程序代码中公开的密钥 并构建构件的工具。 可以将这些工具添加为部署管道的一部分，用于在源代码提交部署之前扫描凭据。 定期检查和清理应用程序日志，以帮助确保不会无意中记录任何机密。 还可以通过同级评审来加强检测。

备注

如果扫描工具发现机密，则必须将机密视为已泄露。 应将其撤销。

响应机密轮换

作为工作负载所有者，您需要了解机密轮换计划和策略，以便在对用户造成最小中断的情况下加入新机密。轮换机密时，可能会出现旧密码无效但新密码尚未放置的窗口期。 在该时段内，工作负载尝试访问的组件不会确认请求。 可以通过在代码中生成重试逻辑来最大程度地减少这些问题。 还可以使用并发访问模式，这些模式允许你拥有多个凭据，这些凭据可以安全地更改，而不会相互影响。

与运营团队合作，成为变更管理过程的一部分。 解除使用不再需要的凭据的工作负载的一部分时，应告知凭据所有者。

将机密检索和配置集成到自动化部署管道中。 机密检索有助于确保在部署期间自动提取机密。 还可以使用机密注入模式在运行时将机密插入到应用程序代码或配置中，从而防止机密意外公开给日志或版本控制。

Power Platform 简化

以下部分描述了可用于管理应用程序机密的 Power Platform 特性和功能。

使用 Azure 密钥保管库机密

环境变量允许引用存储在 Azure 密钥保管库中的机密。 然后，这些机密可在 Power Automate 流和自定义连接器中使用。 请注意，这些机密不可用于其他自定义项或通常通过 API 使用。

实际机密存储在 Azure 密钥保管库中，环境变量将引用密钥保管库机密的位置。 将 Azure 密钥保管库机密与环境变量一起使用需要配置 Azure 密钥保管库，以使 Power Platform 可以读取您要引用的特定机密。 有关更多信息，请参阅在解决方案中使用环境变量以及在解决方案自定义连接器中使用环境变量。

使用解决方案检查器

通过解决方案检查器，您可以使用一组最佳实践规则对解决方案执行各种静态分析检查，并快速确定这些问题模式。 检查完成后，将收到详细报告，其中列出了确定的问题，受影响的组件和代码，以及介绍各问题解决方法的文档的链接。 查看安全类别中可用的解决方案检查器规则。 有关更多信息，请参阅使用解决方案检查器验证解决方案。

使用 CyberArk 操作

CyberArk 提供了一个标识安全平台，该平台可以在端到端之间保护用户和计算机的标识。 Power Automate 桌面流使您能够从 CyberArk 中检索凭据。 有关更多信息，请参见 CyberArk 操作。

安全清单

请参考整套建议。

安全检查表