密码和安全密钥是数十年来数字安全的基础，但它们无法再跟上现代威胁。 与零信任模型一致的无机密身份验证将访问控制和用户验证转移到无凭据方法。 无机密身份验证涉及在云中设计安全应用程序，而无需依赖传统的共享凭据，例如密码、证书、机密或安全密钥。 无机密身份验证具有以下优势：
- 降低凭据风险：通过消除密码，无机密身份验证可缓解与凭据盗窃、网络钓鱼攻击和暴力攻击相关的风险。 此方法使用可验证的标识元素，例如生物识别、数字证书和硬件令牌。
- 简化的访问控制：它通过依赖于验证真实标识而不是共享机密的机制来增强安全性并简化用户体验。 这符合零信任原则，方法是根据真实标识验证每个访问请求。
- 改进了最终用户体验：用户受益于更无缝且更安全的身份验证过程，从而减少了密码重置的需求，提高了用户的整体满意度。
本文探讨 Azure 中的无机密身份验证及其优点，以及如何在各种方案中实现它，包括客户端应用程序、Azure 服务到服务通信和外部工作负载。
密码和机密的安全挑战
密码和其他机密应谨慎使用，开发人员绝不能将它们置于不安全的位置。 许多应用使用用户名、密码和访问密钥连接到后端数据库、缓存、消息传送和事件服务。 如果公开，这些凭据可用于未经授权访问敏感信息，例如为即将到来的市场活动生成的销售目录，或必须专用的客户数据。
由于许多原因（包括通过代码存储库发现）将密码嵌入应用程序本身会带来巨大的安全风险。 许多开发人员使用环境变量外部化此类密码，以便应用程序可以从不同的环境加载这些密码。 但是，这只会将风险从代码本身转移到执行环境。 获得环境访问权限的任何人都可以窃取密码，进而会增加数据外泄风险。
密钥的安全挑战
在 Azure 应用程序开发中使用加密密钥时，存在一些挑战，这会使安全性和作效率复杂化。 一个主要问题是关键管理复杂性，涉及轮换、分发和安全地跨各种服务和环境存储密钥的繁琐任务。 此正在进行的过程需要专用资源，并且由于需要定期维护和监视，可显著增加运营成本。 此外，存在与密钥泄露或滥用相关的重大安全风险，因为因泄露密钥而未经授权的访问可能会损害敏感数据。 此外，基于密钥的身份验证方法通常缺乏动态环境所需的可伸缩性和灵活性，因此难以有效地适应不断变化的要求和缩放作。 这些挑战突出了采用更安全、更高效的身份验证方法（如托管标识）来降低风险和简化作的重要性。
客户端应用程序（面向用户）访问 Microsoft Entra 保护的资源
多重身份验证 (MFA) 等功能是保护组织的绝佳方法，但用户通常会因为必须记住其密码而对额外的安全层感到沮丧。 无密码身份验证方法更方便，因为密码会被删除，并替换为你拥有或知道的内容。
在身份验证方面，每个组织都有不同的需求。 Microsoft Entra ID 集成了以下无密码身份验证选项：
- Windows Hello 企业版
- 适用于 macOS 的平台凭据
- 使用智能卡身份验证 (适用于 macOS 的平台单一登录 PSSO)
- Microsoft验证器
- 通行密钥（FIDO2）
- 基于证书的身份验证
Azure 内部的服务之间传输（在 Azure 中）
在 Azure 资源（服务到服务身份验证）之间进行身份验证时，建议的方法是 对 Azure 资源使用托管标识。 但是，在跨租户对资源进行身份验证和访问时，应在应用程序中将托管标识设置为联合标识凭据。
访问Microsoft Entra受保护资源（同一租户）
对于需要在同一租户中 Azure 资源间进行服务到服务身份验证的场景，建议使用托管标识和 Azure 标识客户端库中的 DefaultAzureCredential 类。
托管标识是可以分配给 Azure 计算资源（例如 Azure 虚拟机、Azure Functions 或 Azure Kubernetes）或任何 支持托管标识的 Azure 服务的标识。 在计算资源上分配托管标识后，可以授权访问下游依赖项资源，例如存储帐户、SQL 数据库、Cosmos DB 等。 托管标识将替换机密信息，例如访问密钥、密码和证书，或者用于服务间依赖的其他形式的身份验证。
有关详细信息，请阅读 什么是 Azure 资源的托管标识？。
在应用程序中实现 DefaultAzureCredential 和管理标识，通过Microsoft Entra ID 和基于角色的访问控制（RBAC）创建与 Azure 服务的无密码连接。
DefaultAzureCredential 支持多种身份验证方法，并自动确定应在运行时使用哪些方法。 此方法使应用能够在不同环境（本地开发与生产环境）中使用不同的身份验证方法，而无需实现特定于环境的代码。
有关在应用程序中使用 DefaultAzureCredential 和托管标识的详细信息，请阅读 “在 Azure 应用和服务之间配置无机密连接”。
访问 Microsoft Entra 保护的资源（跨租户）
在需要在 Azure 资源之间进行服务到服务身份验证的场景中，建议使用托管身份。 但是，在跨租户（多租户应用）访问资源时，不支持托管标识。 以前，你创建了一个具有客户端机密或证书的多租户应用程序作为凭据，用于对多个租户中的资源进行身份验证和访问。 这会使你面临机密泄露的重大风险，并增加了存储、轮换和维护证书生命周期的负担。
Azure 工作负载现在可以使用托管标识作为联合标识凭据，在不依赖机密或证书的情况下安全地访问租户中Microsoft Entra 保护的资源。
若要了解详细信息，请阅读 “配置应用程序以信任托管标识”。
Azure 服务访问外部或非 Microsoft Entra 保护的资源
对于从事身份验证和访问资源的 Azure 工作负载，这些资源没有受到 Microsoft Entra 保护或需要通过密码、机密、密钥或证书来访问的 Azure 服务，您不能直接使用托管标识。 在这种情况下，请使用 Azure Key Vault 存储目标资源的凭据。 使用工作负荷中的托管标识从密钥保管库检索凭据，并使用凭据访问目标资源。
有关详细信息，请查看 在代码中对 Key Vault 进行身份验证。
外部工作负荷（在 Azure 外部）访问受 Microsoft Entra 保护的资源
当软件工作负荷在 Azure 外部运行（例如，本地数据中心、开发人员计算机上或其他云中），并且需要访问 Azure 资源，则不能直接使用 Azure 托管标识。 过去，你将使用Microsoft标识平台注册应用程序，并使用客户端密码或证书登录外部应用。 这些凭据会带来安全风险，必须安全存储并定期轮换。 如果凭据过期，还会面临服务停机的风险。
使用工作负荷标识联合身份验证在 Microsoft Entra ID 中配置用户分配的托管标识或应用注册，以信任来自外部标识提供者（IdP）（例如 GitHub）的令牌。 创建该信任关系后，外部软件工作负载便可以使用来自外部 IdP 的受信任令牌交换来自 Microsoft 标识平台的访问令牌。 然后，软件工作负载将使用该访问令牌来访问自身已获得访问权限的受 Microsoft Entra 保护的资源。 这省去了手动管理凭据的维护负担，并消除了泄露机密或证书过期的风险。
若要了解详细信息，请阅读 工作负荷标识联合。