本地Windows服务存储Service Bus连接字符串的安全方案咨询

直接存储在Appsettings中的可行性结论 #

该方案完全不可行。appsettings.json属于明文配置文件，部署在客户侧的本地服务器权限可控度低，一旦有非授权人员获取到配置文件，可直接拿到Service Bus连接字符串，轻则导致对应客户的消息泄露、篡改，重则整个Service Bus实例被恶意攻击，影响所有客户的业务。

可落地的连接字符串安全防护方案 #

• 优先使用最小权限的访问凭据，不要给客户端分配Service Bus根级连接字符串。针对每个客户的Windows服务，单独创建专属的SAS（共享访问签名）规则，仅开放对应专属订阅/队列的监听权限，关闭发送、管理等多余权限，即使单个客户的凭据泄露，也只会影响该客户自身的业务，不会扩大风险范围。
• 客户侧本地存储时必须加密，禁止明文落盘：
  • 可使用Windows原生DPAPI（数据保护API）加密连接字符串，加密时可绑定到当前服务器或Windows服务运行的专属账号，只有对应机器上、对应账号运行的程序才能解密出明文，即使配置文件被恶意拷贝到其他设备也无法解密。
  • 也可将连接字符串存储在Windows凭据管理器中，服务运行时通过系统API读取凭据，凭据本身受Windows系统级权限保护，普通权限用户无法直接查看明文内容。
• 建立定期密钥轮换机制：可在Azure Service Bus后台定期轮换每个客户对应的SAS密钥，可配合服务端的轻量通知逻辑，让本地Windows服务无感知切换新密钥，即使旧密钥出现泄露，超过有效期后也无法继续使用。
• 如果客户本地环境允许访问Azure公共服务，可替换为Azure AD认证方式：为每个客户的服务分配专属Azure AD服务主体，仅给该主体授予对应订阅的Azure Service Bus Data Receiver角色，本地服务运行时直接申请短期OAuth2.0访问令牌访问Service Bus，无需存储长期有效的连接字符串，令牌默认有效期只有几十分钟，即使出现泄露也不会产生长期风险。

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