Question

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

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

        _client = new SecretClient(keyVaultUri, clientCredential);

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

即使我选择转向基于证书的身份验证，代码片段也如下所示：

        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：密码传输的所有部分都可能导致暴露- 在本地存储密码以方便使用的网站，内部服务器在 COTS 产品中以清晰的日志文件传输的组件以明文形式存储密码。随着秘密成为传输，你的强度取决于你最薄弱的环节——它需要认真努力防止暴露，要求是用户和系统开发者。

证书：

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

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

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

Pro：除了身份验证之外，还有更多用途 - 可以提供完整性和保密性也是如此。

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

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

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

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

1 个答案: