你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

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

  • 项目

适用于此 Azure Well-Architected Framework 安全清单建议：

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

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

凭据（例如 API 密钥、开放授权 (OAuth) 令牌和安全外壳 (SSH) 密钥）都是机密。 某些凭据（如客户端 OAuth 令牌）可以在运行时动态创建。 尽管动态机密是临时性的，但仍需要对其进行保护。 非加密信息（如证书和数字签名密钥）也可能是敏感的。 合规性要求可能会导致通常不被视为机密的配置设置被视为应用程序机密。

定义 

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

重要

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

应用程序配置设置（例如应用程序使用的 API 的 URL）是非密码的示例。 此信息不应与应用程序代码或应用程序机密一起存储。 请考虑使用专用配置管理系统（如 Azure 应用程序配置）来管理这些设置。 有关详细信息，请参阅什么是Azure 应用程序配置？。

关键设计策略

机密管理策略应尽可能减少机密，并通过利用平台功能将它们集成到环境中。 例如，如果对应用程序使用托管标识，则访问信息不会嵌入到连接字符串中，并且将信息存储在配置文件中是安全的。 在存储和管理机密之前，请考虑以下注意事项：

  • 创建的机密应保存在具有严格访问控制的安全存储中。

  • 机密轮换是主动操作，而吊销是被动的。

  • 只有受信任的标识才有权访问机密。

  • 应保留审核线索来检查和验证对机密的访问权限。

围绕这些点制定策略，以帮助防止身份盗用，避免否认，并尽量减少不必要的信息暴露。

机密管理的安全做法

如果可能，请避免创建机密。 找到将 责任委托给平台的方法。 例如，使用平台的内置托管标识来处理凭据。 机密的减少会导致外围应用减少，在机密管理上花费的时间更少。

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

预共享密钥

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

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

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

机密存储

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

证书只能存储在 密钥保管库 或 OS 的证书存储中。 例如，不建议将 X.509 证书存储在 PFX 文件中或磁盘上。 如果需要更高级别的安全性，请选择具有硬件安全模块的系统 (HSM) 功能，而不是基于软件的机密存储。

权衡：HSM 解决方案以更高的成本提供。 由于增加了安全层，你还可能会看到对应用程序性能的影响。

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

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

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

机密轮换

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

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

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

有关 Azure 存储如何处理轮换的详细信息，请参阅 管理帐户访问密钥。

轮换过程应自动执行，无需任何人工交互即可进行部署。 将机密存储在本机支持轮换概念的机密管理存储中可以简化此操作任务。

使用机密的安全做法

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

防止硬编码

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

可以通过使用托管标识来避免这种情况，而无需存储凭据。 应用程序使用其分配的标识通过标识提供者 (IdP) 对其他资源进行身份验证。 在开发过程中使用假机密在非生产环境中进行测试，以防止意外泄露真实机密。

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

注意

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

响应机密轮换

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

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

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

Azure 便利化

使用 密钥保管库 存储机密。 将机密存储在 Azure 机密管理系统、密钥保管库、Azure 托管 HSM 和其他位置。 有关详细信息，请参阅 如何选择正确的密钥管理解决方案。

集成基于标识的访问控制。 Microsoft Entra ID 和托管标识有助于最大程度地减少对机密的需求。 Microsoft Entra ID 通过用于处理密钥轮换、异常等的内置机制，为访问控制提供高度安全和可用性的体验。

使用 Azure 基于角色的访问控制 (RBAC) 向特定范围内的用户、组和应用程序分配权限。

使用访问模型控制密钥保管库、权限和机密。 有关详细信息，请参阅 访问模型概述。

实现机密暴露检测。 在工作负载中集成进程，以检测可疑活动，并定期检查应用程序代码中公开的密钥。 包括的一些选项如下：

请勿将任何环境类型的密钥和机密存储在应用程序配置文件或持续集成和持续交付 (CI/CD) 管道中。 开发人员应使用 Visual Studio 连接服务 或仅限本地的文件来访问凭据。

安全清单

请参阅完整的一组建议。

安全清单