问题描述
删除资源组通常是一个控制平面操作，但它会让资源组中的应用、网络和密钥依赖同时失效。最容易引起误判的是 Key Vault：门户里看不到保管库，应用开始报机密读取失败，重新创建同名保管库又提示名称已经被占用。
这时常见的三个问题是：
- 资源组已经不存在，Key Vault 还能不能找回？
- 恢复时是否必须先创建资源组？资源组的位置是否必须和 Key Vault 一致？
- 恢复后，原来的密钥、机密和证书是否都会自动回来？
这几个问题不能用“重新创建一个同名保管库”解决。真正需要确认的是：保管库是否处于软删除状态、保留期是否已结束，以及恢复操作所需的目标资源组是否存在。
问题解答
一、先判断：这是软删除，还是已经永久清除？
软删除可以理解为 Key Vault 的回收站。保管库被删除后，会在配置的保留期内保持可恢复状态；当前 Azure CLI 文档显示，保留期可配置为 7 到 90 天，新建保管库默认通常为 90 天。软删除状态下，保管库名称仍然被占用，因此不能通过创建同名保管库来“覆盖恢复”。
清除保护是另一层机制。它不是恢复功能，而是防止在保留期内执行永久删除的时间锁。启用清除保护后，包括 Microsoft 在内的任何人都不能绕过它；如果已经执行清除，或者保留期结束后系统完成自动清除，本文的软删除恢复流程就不再适用，只能依赖事先准备的备份或其他灾难恢复方案。
可以先用下面的流程判断处理方向：
这里有一个容易被忽略的边界：软删除只保证保管库及其软删除对象在保持期内可恢复，不等于所有依赖资源都会回滚到删除前状态。恢复成功后仍要重新检查控制平面的配置。
二、恢复前的四项核对
第一，确认云环境和订阅。 全球 Azure 与 Azure 中国区使用不同的云环境和文档入口。如果命令行列不出预期保管库，先检查当前登录的云环境、租户和订阅，不要马上执行 purge。
第二，记录已删除保管库的名称和区域。 az keyvault recover 的 --name 和 --location 针对的是已删除的保管库；区域必须填写保管库原来的区域，而不是随意选择一个新区域。
第三，准备目标资源组。 恢复命令需要一个现存的目标资源组。资源组被删除时，应先用原资源组名称重新创建它，再执行恢复。资源组名称是恢复目标的一部分，但资源组的 Azure Resource Manager 元数据位置不必与 Key Vault 的部署区域相同；不要把“资源组存在”误解成“资源组和保管库必须同区域”。
第四，确认权限。 查看已删除保管库需要订阅级别的 Microsoft.KeyVault/locations/deletedVaults/read 权限；清除需要 Microsoft.KeyVault/locations/deletedVaults/purge/action 和查询操作结果的权限；恢复软删除保管库需要足够的管理平面权限，官方文档列出的内置角色是“密钥保管库管理员”（Key Vault Administrator）。实际操作中应遵循最小权限原则，不要为了排障直接给订阅所有者权限。
三、Azure 门户恢复步骤
登录 Azure 门户 → 选择页面顶部的搜索栏 → 搜索“密钥保管库”服务（不要选择单个密钥保管库）→ 在屏幕顶部选择“管理已删除的保管库”选项，此时会在屏幕右侧打开一个上下文窗格 → 选择订阅；如果你的密钥保管库已被软删除，它会显示在右侧窗格中（保管库过多时可选择窗格底部的“加载更多”，或改用 CLI/PowerShell 获取结果）→ 找到要恢复的保管库后勾选其旁边的选框 → 选择上下文窗格底部的“恢复”选项。
四、Azure CLI：重建资源组并恢复保管库
下面的命令适合资源组已被删除、但 Key Vault 仍处于软删除状态的场景。先替换变量，再执行；不要把示例值直接用于生产环境。
# 全球 Azure 使用 AzureCloud；Azure 中国区使用 AzureChinaCloud az cloud set --name AzureCloud az login az account set --subscription "<订阅 ID 或名称>" # 列出当前订阅中仍可恢复的已删除保管库 az keyvault list-deleted -o table # 查看指定保管库的删除时间、保留截止时间和原始位置 az keyvault show-deleted \ --name "<保管库名称>" \ --location "<保管库原始区域>" # 资源组已删除时，先创建同名资源组 az group create \ --name "<原资源组名称>" \ --location "<资源组位置>" # 恢复保管库；location 必须使用 Key Vault 原始区域 az keyvault recover \ --name "<保管库名称>" \ --resource-group "<原资源组名称>" \ --location "<保管库原始区域>"
Azure 中国区将第一行改为 az cloud set --name AzureChinaCloud，并在对应云环境中重新登录。这里有两个 location，不要混淆：az group create 的位置属于资源组元数据，az keyvault recover 的位置属于 Key Vault。真正决定恢复目标保管库的是后者。
恢复是长时间运行操作时，可以先检查资源是否出现，再做数据平面验证：
# 确认保管库已经恢复到目标资源组 az keyvault show \ --name "<保管库名称>" \ --resource-group "<原资源组名称>" \ --query "{id:id,location:location,provisioningState:properties.provisioningState}" \ -o table # 只验证名称和版本元数据，不要在终端输出机密值 az keyvault secret list \ --vault-name "<保管库名称>" \ --query "[].{name:name,enabled:attributes.enabled}" \ -o table
五、Azure PowerShell：等价恢复流程
Connect-AzAccount Set-AzContext -SubscriptionId "<订阅 ID>" # 查看当前订阅中的已删除保管库 Get-AzKeyVault -InRemovedState # 资源组已删除时先重建同名资源组 New-AzResourceGroup ` -Name "<原资源组名称>" ` -Location "<资源组位置>" # 使用 Key Vault 原始区域恢复保管库 Undo-AzKeyVaultRemoval ` -VaultName "<保管库名称>" ` -ResourceGroupName "<原资源组名称>" ` -Location "<保管库原始区域>"
如果命令返回权限错误，先区分是管理平面权限不足，还是恢复后访问 Key Vault 数据平面的权限不足。恢复保管库与读取机密是两件不同的事，不要用“能恢复”推断“应用一定能读取”。
六、只删除了密钥、机密或证书时怎么办？
如果 Key Vault 本体仍然存在，只是其中的对象被删除，不需要恢复整个保管库。在门户中打开 Key Vault，进入“密钥”“机密”或“证书”选项卡，选择对应的“管理已删除项”，然后执行恢复。
命令行也可以分别处理对象：
az keyvault secret list-deleted --vault-name "<保管库名称>" az keyvault secret recover --vault-name "<保管库名称>" --name "<机密名称>" az keyvault key list-deleted --vault-name "<保管库名称>" az keyvault key recover --vault-name "<保管库名称>" --name "<密钥名称>" az keyvault certificate list-deleted --vault-name "<保管库名称>" az keyvault certificate recover --vault-name "<保管库名称>" --name "<证书名称>"
对象恢复同样受软删除和保留期约束。对象不存在于已删除列表中，可能意味着它没有启用软删除、已经被清除，或者当前身份访问的是错误的保管库或订阅。
七、恢复成功后，不要只测试一个机密
我建议按“资源、权限、网络、应用”四层验证，而不是看到门户中的保管库名称就宣布恢复完成：
| 验证层 | 重点检查 | 常见遗漏 |
| 资源 | 保管库名称、订阅、资源组、区域、SKU | 恢复到了错误订阅或资源组 |
| 数据 | 密钥、机密、证书及版本是否可见 | 只验证对象名称，没有验证版本和有效状态 |
| 权限 | Azure RBAC 角色或访问策略、托管身份 | 恢复后应用身份仍然收到 403 |
| 网络 | 防火墙、网络 ACL、专用终结点、DNS | 门户能访问，但应用网络不可达 |
| 依赖 | App Service、AKS、Data Factory、磁盘加密等 | 应用仍缓存旧配置或旧资源 ID |
| 运维 | 诊断设置、日志目标、告警 | 恢复了数据，却没有恢复审计链路 |
恢复后不要把机密值打印到终端、日志或截图中。对应用做一次最小读取测试即可；如果出现 403，优先检查身份和数据平面授权；如果出现 timeout，优先检查网络路径、专用 DNS 和防火墙规则。
八、如何降低下一次误删的影响？
我的建议是把防护分成三层，而不是只依赖软删除：
- 恢复层： 为 Key Vault 保持软删除，并在生产环境启用清除保护；通过 Azure Policy 统一检查相关配置。
- 误操作层： 为资源组和 Key Vault 设置
CanNotDelete资源锁。锁只能阻止普通删除操作，不能替代权限治理和灾备。 - 灾备层： 定期备份需要长期保存的密钥、机密和证书，并记录恢复演练结果。备份不是软删除的替代品，而是应对清除、保留期到期和区域级故障的另一条路径。
如果业务必须保留原资源 ID、原名称和原应用配置，优先选择软删除恢复；如果保管库已经被清除，重新创建同名保管库只能得到一个空资源，不能恢复原有对象。
常见问题
资源组被删除后，必须重建同名资源组吗？
恢复命令需要一个现存的目标资源组。对于“原资源组被删除”的场景，最稳妥的做法是先重建原名称，再执行恢复。恢复到其他资源组是否可行取决于具体服务和接口行为，不应在紧急恢复时临时试错。
资源组和 Key Vault 必须在同一个区域吗？
不必把两者强制设为同一区域。资源组位置和 Key Vault 的部署区域是不同概念；恢复命令中的 --location 应填写 Key Vault 原始区域。
恢复后，访问策略和专用终结点一定会回来吗？
不要假设一定会回来。Key Vault 数据对象的恢复与外围控制平面资源不是同一个恢复边界，必须重新核对 RBAC、访问策略、网络规则、专用终结点、DNS、诊断设置和依赖应用。
已经执行 purge，还能恢复吗？
不能使用软删除恢复流程。清除是永久删除操作；此时只能检查是否有 Key Vault 对象备份、基础设施定义、应用密钥轮换记录或其他灾备副本。
总结
资源组误删不等于 Key Vault 立即永久丢失，但恢复窗口受软删除保留期限制。正确顺序是：确认云环境和订阅，读取已删除保管库的原始区域，重建目标资源组，执行恢复，再按资源、数据、权限、网络和应用五个层面验证。最重要的边界是：软删除解决“误删除后的恢复”，不能替代清除保护、资源锁、备份和恢复演练。
参考资料
当在复杂的环境中面临问题，格物之道需：浊而静之徐清，安以动之徐生。 云中，恰是如此!
