.NET7/EF+SQL Server/Azure下租户外部API凭据安全存储方案问询

一、双向加密并非最优方案 #

不需要自行实现双向加密，Azure Key Vault已经提供了符合FIPS 140-2标准的加密存储，密钥由Azure托管，比自行维护加密密钥更安全可靠，避免了密钥管理不当带来的风险。

二、当前方案的优化方向与标准实践 #

• 租户级别的凭据隔离
  不要仅通过命名规则（如{tenantId}-{credentialNamespace}）区分租户凭据，建议结合Azure RBAC实现权限隔离：

  • 可为每个租户创建独立的Key Vault，彻底隔离数据；
  • 若使用单个Key Vault，需为每个租户对应的服务主体分配仅能访问自身凭据的权限，禁止跨租户访问。

• 使用Azure Key Vault SDK直接访问
  当前通过IConfiguration读取的方式依赖配置系统的映射，更规范的做法是直接使用Azure Key Vault的官方SDK（Azure.Security.KeyVault.Secrets）获取凭据，避免中间层的潜在风险，示例代码：

  using Azure.Security.KeyVault.Secrets;
  using Azure.Identity;
  
  public record ApiCredentials(string UserName, string Password);
  
  public static async Task<ApiCredentials> GetApiCredentialsAsync(string tenantId, string credentialNamespace)
  {
      var vaultUri = new Uri("https://your-key-vault-resource.vault.azure.net/");
      // 使用DefaultAzureCredential自动适配环境（本地开发、Azure托管等）
      var secretClient = new SecretClient(vaultUri, new DefaultAzureCredential());
  
      var usernameSecretName = $"tenant-{tenantId}-{credentialNamespace}-username";
      var passwordSecretName = $"tenant-{tenantId}-{credentialNamespace}-password";
  
      var usernameSecret = await secretClient.GetSecretAsync(usernameSecretName);
      var passwordSecret = await secretClient.GetSecretAsync(passwordSecretName);
  
      return new ApiCredentials(usernameSecret.Value.Value, passwordSecret.Value.Value);
  }
  

• 遵循最小权限原则
  为访问Key Vault的服务主体分配最窄的权限：仅授予Secrets/Get权限，禁止Secrets/List、Secrets/Set等不必要的权限，防止意外泄露或篡改凭据。

• 优先使用现代身份认证替代用户名密码
  如果外部API支持OAuth2.0（如Client Credentials流）、证书认证等方式，应优先使用这些方案，替代传统的用户名密码，减少凭据泄露的风险，同时符合现代API安全标准。

• 自动化凭据轮换与监控

  • 利用Azure Key Vault的自动轮换功能，定期更新凭据，避免过期导致服务中断；
  • 开启Key Vault的审计日志（集成Azure Monitor），实时监控凭据访问行为，异常操作及时告警。

三、总结 #

基于Azure Key Vault的方案方向是正确的，通过上述优化措施，可以让凭据的存储与访问更符合安全规范，同时降低运维和安全风险。

内容的提问来源于stack exchange，提问作者Lennart Hammarström