通过 Client Secret 或 Client Certificate 识别应用程序

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

Is it the local path to the certificate that is downloaded as CER/PEM format from Azure Key Vault ?

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

if I am operating in private cloud, does it really matter (client secret / client certificate)?

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

客户端密钥和客户端证书的优缺点：

Client secret:

Pro: Easy to deploy - just takes some code and a secure data store. Depending on the security policy, can autogenerate passwords or force new users to create them.

Pro: Easy to administrate - password resets can (for some security policies) be done with automated tools

Con: For good security, passwords should be reset early and often. User's forgetting or failing to change passwords is either a security risk or a usability hassle.

Con: Good passwords can be hard to remember, which leads to the issues of users reusing passwords or writing them down.

Con: Password data stores are a weak point - if an intruder gets the password store, he gets the motherload.

Con: All parts of password transmission can lead to exposure - websites that store passwords locally for ease of use, internal server components that transmit in the clear, log files in COTS products that store passwords in the clear. With the secret being part of the transmission, you're only as strong as your weakest link - it takes serious effort to prevent exposure and the requirement is on both the user and the system developer.

Certificates:

Pro: Doesn't require the transmission of the secret. Proof of private key contains no secret information - mitigates all sorts of storage/transmission weak points.

Pro: Issued by a trusted party (the CA) which allows for a centralized management system for status across multiple applications. If a cert goes bad, it can get revoked. Fixing a password breakin must be done separately for each system unless a shared ID is used.

Pro: Non-repudiation case is stronger - in most password systems, the way the user is initially authenticated prior to account creation is pretty weak and the password reset mechanisms can offer another factor of plausible deniability. With many forms of certificate issuance, it's far harder for a user to say it wasn't them. Caveat - you're still only as good as your CA's issuance policies.

Pro: Serves more purposes than just authentication - can provide integrity and confidentiality as well.

Con: Still requires a password/pin - almost any private key pair storage mechanism is then unlocked with a PIN. SmartCards can have tamper protection and lockout capabilities to prevent brute force, but that doesn't fix the fact the user wrote his PIN on a sticky note next to the computer where the card is docked. Sometimes password issues reappear on a smaller scale with PKI.

Con: Complexity of infrastructure - setting up a PKI is no easy task and generally so expensive in both deployment and maintenance that it can only be used for large/expensive systems.

Con: Certificate Status reporting and updates are not easy - revoking a user credential that has become corrupted is onerous due to the size and complexity of the infrastructure. Usually, a CA generates a CRL that may or may not be provisioned within an OCSP server. Then every application should check every login for the CRL or OCSP status. This introduces a variety of time delays into the system between the time a PKI credential is reported as compromised and the time when the systems that rely on that credential actually start denying access. The speed of status update can be accelerated - but at a greater system complexity cost.

通过 Client Secret 或 Client Certificate 识别应用程序

Identify an app by Client Secret or Client Certificate

c#

azure-keyvault