咨询从web.config迁移SQL连接字符串至Azure Key Vault的最佳实践

我之前帮不少团队处理过类似的Azure Key Vault迁移问题，针对你提到的连接字符串在web.config多处引用（角色提供者、EF这些地方都用）的场景，确实有几个成熟的模式和最佳实践能帮你平滑完成迁移，不用挨个改每个引用点：

核心就是让所有依赖连接字符串的模块，不再直接读取web.config里的硬编码值，而是通过统一的配置入口从Azure Key Vault获取，这样只需要改配置或者加一层封装，不用修改各个模块的引用逻辑。

具体实现模式 #

模式1：用ASP.NET配置构建器直接集成Key Vault（最推荐，零代码修改） #

这是最适合你场景的方案——ASP.NET Framework有官方的配置构建器可以直接把Azure Key Vault作为配置源，原来web.config里的所有连接字符串引用都不用改，配置好之后系统会自动从Key Vault拉取值。

步骤很简单：

1. 安装NuGet包 Microsoft.Configuration.ConfigurationBuilders.Azure
2. 在web.config里添加配置构建器节点，指向你的Key Vault：

<configSections>
  <section name="configBuilders" type="System.Configuration.ConfigurationBuildersSection, System.Configuration, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" restartOnExternalChanges="false" requirePermission="false" />
</configSections>
<configBuilders>
  <builders>
    <add name="AzureKeyVault" 
         vaultName="你的Key Vault名称" 
         type="Microsoft.Configuration.ConfigurationBuilders.AzureKeyVaultConfigBuilder, Microsoft.Configuration.ConfigurationBuilders.Azure" />
  </builders>
</configBuilders>

3. 给connectionStrings节点加上configBuilders="AzureKeyVault"属性：

<connectionStrings configBuilders="AzureKeyVault">
  <add name="DefaultConnection" connectionString="" providerName="System.Data.SqlClient" />
</connectionStrings>

4. 在Key Vault里创建同名的机密（比如DefaultConnection），值就是你的数据库连接字符串。

这样不管是EF、角色提供者还是成员资格提供者，只要是用ConfigurationManager.ConnectionStrings["DefaultConnection"]的地方，都会自动从Key Vault读取值，完全不用改业务代码！

模式2：自定义连接字符串提供者（适合有特殊逻辑的场景） #

如果你的系统需要动态切换环境、加缓存逻辑，或者有些自定义模块，那可以封装一个统一的连接字符串获取类，让所有模块依赖这个类而不是直接读配置：

public static class ConnectionStringProvider
{
    // 用Lazy实现懒加载+缓存，避免重复调用Key Vault
    private static readonly Lazy<string> _defaultConn = new Lazy<string>(FetchDefaultConnectionFromKeyVault);

    public static string DefaultConnection => _defaultConn.Value;

    private static string FetchDefaultConnectionFromKeyVault()
    {
        // 用托管标识获取Key Vault访问令牌，避免硬编码凭据
        var credential = new DefaultAzureCredential();
        var client = new SecretClient(new Uri("https://你的vault地址.vault.azure.net/"), credential);
        var secret = client.GetSecret("DefaultConnection").Value;
        return secret.Value;
    }
}

然后在自定义的DbContext或者服务里直接用：

public class MyDbContext : DbContext
{
    public MyDbContext() : base(ConnectionStringProvider.DefaultConnection)
    {
    }
}

不过要注意，ASP.NET的内置提供者（比如MembershipProvider）可能不支持直接引用代码，所以这种模式更适合自定义模块，内置模块还是用模式1更省心。

模式3：环境变量中转（适合容器化/App Service部署） #

如果你的应用部署在Azure App Service或者容器里，可以用环境变量做中转：

1. 在Azure App Service的「配置」里添加应用设置，名称设为DefaultConnection，值用Key Vault引用格式：@Microsoft.KeyVault(VaultName=你的vault名;SecretName=DefaultConnection)
2. 在web.config里把连接字符串改成读取环境变量：

<connectionStrings>
  <add name="DefaultConnection" connectionString="%DefaultConnection%" providerName="System.Data.SqlClient" />
</connectionStrings>

这样各个模块还是原来的引用方式，实际值来自环境变量，而环境变量自动从Key Vault同步，不用加额外的NuGet包，适合快速迁移。

关键最佳实践 #

• 一定要用托管标识（Managed Identity）：不管用哪种模式，都别在代码或配置里硬编码Service Principal的凭据，让应用通过托管标识自动获取Key Vault的访问权限，安全又好维护。
• 缓存机密值：Key Vault有调用次数限制，而且每次调用有延迟，用懒加载或者配置构建器的缓存功能，避免重复拉取。
• 分环境隔离机密：开发、测试、生产环境用不同的Key Vault，或者在同一个Vault里给机密加环境后缀（比如DefaultConnection-Dev），避免串环境。
• 全链路测试：迁移后一定要测试所有用到连接字符串的模块——登录功能（成员资格提供者）、角色权限、EF数据操作等，确保都能正常工作。
• 清理敏感历史：迁移完成后，删掉web.config里的明文连接字符串，还要清理Git历史里的敏感信息，防止泄露。

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