通过客户端密钥或客户端证书识别应用程序

Question

我有 .Net 4.6.1 应用程序需要从 Azure Key Vault 访问一些机密，我正在通过以下方式进行操作：

        var clientCredential = new ClientSecretCredential(
            azureClientData.AzureTenantId,
            azureClientData.AzureClientID,
            azureClientData.AzureClientSecret);

        _client = new SecretClient(keyVaultUri, clientCredential); 

Azure 门户的应用注册提到客户端证书是比客户端密码更好的选择。我想知道我是否在私有云中运行，这真的很重要吗（客户端密码/客户端证书）？

即使我选择转向基于证书的身份验证，代码 sn-p 看起来如下：

        var clientCerCredential = new ClientCertificateCredential(
            azureClientData.AzureTenantId,
            azureClientData.AzureClientID,
            azureClientData.AzureClientCertificatePath); // Is it the local path to the certificate that is downloaded as CER/PEM format from Azure Key Vault ?



        _client = new CertificateClient(keyVaultUri, clientCredential); 

Answer 1

是否是下载为 CER/PEM 的证书的本地路径 Azure Key Vault 的格式？

“clientCertificatePath 是包含客户端证书和私钥的文件的路径。” 它始终是本地路径，但如果将其存储到 OneDrive 路径格式类似于“C:\Users\myuser\OneDrive - Microsoft\Documents\Certs”。

如果我在私有云中运营，这真的很重要吗（客户端 秘密/客户证书）？

简而言之，证书比机密更安全，但使用起来很复杂。您选择哪一种取决于您的要求。在我看来，客户端密码可以在每隔几个月更新一次密码时保护 Azure Key Vault。

客户端密码和客户端证书各有优缺点：

客户端密码：

专业版：易于部署 - 只需要一些代码和安全的数据存储。 根据安全策略，可以自动生成密码或强制 新用户来创建它们。

专业版：易于管理 - 密码重置可以（为了某些安全性 政策）使用自动化工具完成

缺点：为了获得良好的安全性，应尽早并经常重置密码。 用户忘记或未能更改密码是一种安全措施 风险或可用性问题。

缺点：好的密码可能很难记住，这会导致问题 的用户重复使用密码或将密码写下来。

Con：密码数据存储是一个弱点 - 如果入侵者获得 密码存储，他得到了motherload。

Con：密码传输的所有部分都可能导致暴露 - 为便于使用而在本地存储密码的网站，内部服务器 在 COTS 产品中以清晰的日志文件传输的组件 明文存储密码。秘密是其中的一部分 传输，你的强大取决于你最薄弱的环节——它需要 认真努力防止暴露和要求是对两个 用户和系统开发者。

证书：

Pro：不需要传输秘密。私人证明 密钥不包含秘密信息 - 减轻各种 存储/传输薄弱环节。

Pro：由受信任方 (CA) 发布，允许集中 跨多个应用程序的状态管理系统。如果一个证书 坏了，它可以被撤销。必须修复密码破解 除非使用共享 ID，否则为每个系统单独分配。

专业人士：不可否认性案例更强 - 在大多数密码系统中， 在创建帐户之前最初对用户进行身份验证的方式是 很弱，密码重置机制可以提供另一个因素 似是而非的否认。通过多种形式的证书颁发， 用户很难说不是他们。警告 - 你是 仍然与您的 CA 的发行政策一样好。

专业版：提供更多目的而不仅仅是身份验证 - 可以提供 完整性和机密性。

缺点：仍然需要密码/pin - 几乎任何私钥对 然后使用 PIN 解锁存储机制。智能卡可以有 篡改保护和锁定功能，以防止蛮力，但 这并不能解决用户在便笺上写下他的 PIN 的事实 到插有卡的计算机。有时密码问题 使用 PKI 以较小的规模重新出现。

缺点：基础架构的复杂性 - 设置 PKI 并非易事 而且通常在部署和维护方面都非常昂贵，以至于 只能用于大型/昂贵的系统。

缺点：证书状态报告和更新并不容易 - 撤销 由于大小，已损坏的用户凭据很繁重 和基础设施的复杂性。通常，CA 会生成 CRL 可能会或可能不会在 OCSP 服务器中提供。然后每 应用程序应检查每次登录的 CRL 或 OCSP 状态。这个 将各种时间延迟引入系统之间的时间 PKI 凭证被报告为已泄露，并且 依赖该凭证的系统实际上开始拒绝访问。 状态更新的速度可以加快 - 但速度更快 系统复杂性成本。