通过

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

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

  • 项目

适用于此 Azure 架构良好的框架安全清单建议：

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

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

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

定义 

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

重要

不要像机密一样对待非机密。 机密需要非机密不需要的操作严格性，这可能会导致额外的成本。

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

关键设计策略

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

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

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

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

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

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

管理工作负荷机密

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

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

预共享密钥

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

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

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

机密存储

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

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

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

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

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

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

机密轮换

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

仔细处理 OAuth 访问令牌，并考虑其生存时间。 考虑是否需要将曝光窗口调整为较短的时间段。 必须安全地存储刷新令牌，且应用程序暴露有限。 续订的证书还应使用新的密钥。 有关刷新令牌的信息，请参阅 安全 OAuth 2.0 代理刷新令牌。

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

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

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

安全地使用工作负荷机密

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

防止硬编码

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

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

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

注意

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

响应机密轮换

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

请与运营团队协作，并参与变更管理过程。 解除使用不再需要的凭据的应用程序的一部分时，应让凭据所有者知道。

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

Azure 便利化

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

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

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

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

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

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

安全清单

请参阅完整的建议集。

安全清单