本地Windows Service访问Azure Service Bus的Service Principal证书认证问询

证书认证方案可行性说明 #

使用证书对Service Principal进行认证是非常合适的方案，相比你已经测试过的客户端密钥、SAS连接字符串，安全性高很多，完全适配本地部署的场景：

• 规避密钥泄露风险：证书不需要硬编码在配置文件、代码中，可以存储在本地Windows系统的证书存储区，仅开放给Windows Service运行的账号读取权限，不会出现密钥误提交到代码仓库、配置泄露的问题
• 官方原生支持：Azure.Identity库提供了ClientCertificateCredential类，你只需要把之前使用的ClientSecretCredential替换为该类即可，无需修改业务逻辑，配置参数仅需要租户ID、Service Principal客户端ID、证书指纹/证书路径
• 生命周期可控：你可以自行控制证书的有效期、轮转规则，也可以配合Azure Key Vault统一管理证书的自动轮转，进一步降低维护成本

更优替代方案说明 #

如果你的本地环境已经部署了Azure Arc，可以使用Azure Arc启用的托管身份作为更优方案：

• 无需自行维护证书、密钥的生命周期，Azure Arc会自动轮转身份凭据
• 权限配置逻辑和云端托管身份完全一致，不需要单独维护Service Principal的身份信息
• 权限颗粒度和Service Principal认证一致，依然可以配置最小必要权限

如果你的环境没有部署Azure Arc，那么基于Service Principal的证书认证就是当前场景下的最优方案，安全性远高于SAS密钥、客户端密钥认证。

示例代码参考 #

using Azure.Identity;
using Azure.Messaging.ServiceBus;

// 从Windows证书存储读取证书，也可直接指定本地证书文件路径
var credential = new ClientCertificateCredential(
    tenantId: "<你的Azure租户ID>",
    clientId: "<Service Principal客户端ID>",
    certificateThumbprint: "<证书指纹>",
    options: new ClientCertificateCredentialOptions()
);

// 初始化Service Bus客户端
var serviceBusClient = new ServiceBusClient(
    "<你的Service Bus命名空间>.servicebus.windows.net",
    credential
);

注意：给Service Principal/Arc托管身份分配权限时，遵循最小权限原则，仅分配业务需要的角色即可，比如仅发消息就分配Azure Service Bus Data Sender角色，不要分配过高权限。

内容的提问来源于stack exchange，提问作者Drew Wiley