0

我的许多(机密)应用程序都通过客户端凭据流相互通信。
他们从 Azure Identity 平台请求一个令牌,并使用此令牌对另一个应用程序进行身份验证。
前段时间我使用客户端机密来执行此操作,但后来我读到不建议将其用于生产环境。
出于这个原因,我改为使用有效期更长的自签名证书。
这些证书是我自己使用 Azure Keyvault 生成的。但是,也不建议这样做。
Microsoft 声明,在生产环境中,您应该使用由官方 CA 签名的证书。

如果我现在使用 Lets 加密,这将在三个月内到期,这也不是一个很好的解决方案。

我的问题:

  • 为什么不建议在生产环境中使用客户端密码?
  • 为什么自签名证书有问题?我在 HTTPS 方面确实理解这一点,但如果将其用于客户端凭据流,安全漏洞在哪里?就我而言,我是应用程序应用程序注册的所有者。
  • 我是否需要购买有效期为一年的证书才能“以正确的方式”进行操作?

您在这里有任何最佳实践的来源吗?

4

1 回答 1

0

• 客户端机密包括应用程序凭据、SSH 密钥、API 密钥、数据库密码、加密密钥、连接字符串等,用于连接各种资源并访问数据或功能以实现该应用程序的指定目的。因此,如果这些被破坏,它们可能会使您的应用程序面临很大的危害风险。此外,在 Azure AD 中生成并在 API 中用于连接到 Azure AD 以进行身份​​验证和授权的客户端机密在 API 代码本身中以未加密的形式列出和提及。不过,我们可以选择将该机密存储在密钥保管库中,并通过托管身份或 RBAC 分配来引用该机密,但是,如果托管身份是用户分配的,或者即使根据所需的特定需求没有很好地定义秘密的访问范围,他们的凭据也可能落入坏人之手,并使应用程序容易受到攻击。因此,不建议在生产 API 中使用客户端密码。

• 在客户端凭证流中,应用程序由管理员直接授予权限,以通过证书或联合凭证对要通过其调用的 API 执行特定操作。因此,当在客户端凭据授予场景中使用自签名证书时,管理员已授予请求访问其他 API 的守护程序应用程序有关代码、API、权限、数据等可访问性的所有必要权限,这可能导致验证不佳和误用,因为在没有合理熵的情况下很容易生成证书的密钥对。此外,在自签名证书中不承诺适当地保护密钥对的私钥以使其使用和对其进行强验证,因此不建议在客户端凭据流中使用。

• 有关网络应用服务部署的最佳实践,请参阅以下文档链接:-

https://docs.microsoft.com/en-us/azure/app-service/security-recommendations#general

它解释了部署 Web 应用服务的最佳安全建议。

于 2022-02-22T10:39:18.307 回答