Azure Key Vault相比加密配置设置的安全性更高的原因是什么？

你看到的是过时的、不符合当前Azure安全最佳实践的用法，你忽略的核心要点有这些：

• 现在访问Key Vault根本不需要在应用配置里存储任何敏感凭据
  你查阅的教程用的是早期的服务主体客户端密钥认证方案，目前Azure App Service原生支持托管标识功能，你只需要给你的Web App开启系统/用户分配托管标识，再给这个标识分配Key Vault的对应访问权限（比如密钥读取、签名权限），应用连接Key Vault时用DefaultAzureCredential即可自动完成认证，全程不需要在配置里存放任何客户端密钥这类敏感信息，配置里只需要存Key Vault的端点地址，这个地址本身属于公开非敏感信息，就算泄露也不会带来安全风险。
  目前官方推荐的连接代码非常简单，不需要传入任何凭据：

var keyVaultEndpoint = settings["AzureKeyVault:Endpoint"];
if (!string.IsNullOrEmpty(keyVaultEndpoint))
{
    config.AddAzureKeyVault(new Uri(keyVaultEndpoint), new DefaultAzureCredential());
}

• 哪怕退一步使用客户端密钥的认证方式，Key Vault依然能带来远高于直接存应用配置的安全性
  • 密钥生命周期管理更安全：你用来签名交易的核心密钥可以存在Key Vault的HSM硬件模块中，全程无法导出，签名操作直接在Key Vault内部完成，密钥永远不会进入你的应用内存，哪怕应用被攻破，攻击者最多只能发起签名请求，无法偷走密钥造成永久性泄露；而如果直接把密钥存在应用配置中，应用启动后密钥会加载到进程内存，攻击者拿到内存dump就能直接获取密钥，后续可以随意伪造签名。
  • 细粒度权限控制与审计：Key Vault支持对每个密钥单独配置访问权限，还可以记录所有的访问、操作日志，一旦出现异常操作可以快速溯源；而应用配置的权限粒度更粗，也没有针对单条敏感配置的操作审计能力。
  • 降低泄露风险范围：如果你的应用配置不慎泄露，比如误提交到代码仓库、运维人员误导出配置，存在应用配置里的核心签名密钥会直接泄露；而如果配置里只有Key Vault的非敏感端点信息，攻击者就算拿到配置也无法访问Key Vault里的内容。
  • 密钥无需修改应用配置即可轮换：如果核心签名密钥需要定期轮换，你只需要在Key Vault中更新密钥即可，应用可以自动读取新值，不需要修改应用配置、不需要重启服务，大幅降低密钥轮换过程中的泄露风险和操作成本。

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