Azure Key Vault日志中Success与Forbidden共存的原因咨询

问题背景 #

执行以下Log Analytics查询筛选Key Vault禁止访问尝试时，发现部分日志条目存在字段矛盾：

AzureDiagnostics | where ResourceProvider == "MICROSOFT.KEYVAULT" | where ResultSignature == "Forbidden" | order by TimeGenerated desc | take 300

这类日志同时显示ResultType: Success和ResultSignature: Forbidden，且httpStatusCode_d: 403，但对应的Web应用仍能正常检索密钥。已排除网络问题（密钥库与Web应用同子网），但所有环境均存在该现象。

日志示例 #

TenantId：xxxxx-xxxxxx-xxxxxx-xxxxxx
TimeGenerated [UTC]：2024-03-20T20:04:53.0973838Z
ResourceId：/SUBSCRIPTIONS/xxxxx-xxxxxx-xxxxxx/RESOURCEGROUPS/RG-1/PROVIDERS/MICROSOFT.KEYVAULT/VAULTS/KEYVAULT001
Category：AuditEvent
ResourceGroup：RG-1
SubscriptionId：xxxxx-xxxxxx-xxxxxx
ResourceProvider：MICROSOFT.KEYVAULT
Resource：KEYVAULT001
ResourceType：VAULTS
OperationName：SecretGet
ResultType：Success
CorrelationId：xxxxx-xxxxxx-xxxxxx-xxxxxx
ResultDescription：客户端地址未获授权，且调用方并非受信任服务。客户端地址：20.100.100.1；调用方：appid=xxxxx-xxxxxx-xxxxxx-xxxxxx;oid=xxxxx-xxxxxx-xxxxxx-xxxxxx;iss=https://sts.windows.net/xxxxx-xxxxxx-xxxxxx-xxxxxx/;xms_mirid=/subscriptions/xxxxx-xxxxxx-xxxxxx-xxxxxx/resourcegroups/rg-1/providers/Microsoft.ManagedIdentity/userAssignedIdentities/id-managed;xms_az_rid=/subscriptions/xxxxx-xxxxxx-xxxxxx-xxxxxx/resourcegroups/rg-1/providers/Microsoft.ManagedIdentity/userAssignedIdentities/id-managed；密钥库：KEYVAULT001;location=westeurope
requestUri_s：https://KEYVAULT001.vault.azure.net/secrets/GitlabContainerRegistryUsername/?api-version=7.0
DurationMs：17
CallerIPAddress：20.100.100.1
OperationVersion：7.0
ResultSignature：Forbidden
id_s：https://KEYVAULT001.vault.azure.net/secrets/GitlabContainerRegistryUsername
httpStatusCode_d：403
identity_claim_appid_g：xxxx-xxxxxxx-xxxxxxxxx
isAccessPolicyMatch_b：true
SourceSystem：Azure
identity_claim_xms_az_nwperimid_s：[]
identity_claim_appidacr_s：2
tlsVersion_s：TLS1_2
identity_claim_oid_g：xxxx-xxxxxxx-xxxxxxxxx
identity_claim_xms_mirid_s：/subscriptions/xxxx-xxxxxxx-xxxxxxxxx/resourcegroups/rg-1/providers/Microsoft.ManagedIdentity/userAssignedIdentities/id-managed

原因解析 #

1. 多阶段验证的日志聚合 #

Azure Key Vault的访问验证分为网络层校验（防火墙、VNet规则）和身份访问策略校验两个核心阶段：

• 日志中ResultDescription明确提到“客户端地址未获授权”，说明网络层校验返回了403（对应ResultSignature: Forbidden和httpStatusCode_d: 403）；
• 但isAccessPolicyMatch_b: true表明身份访问策略校验通过，最终Key Vault允许了该操作的执行，因此ResultType标记为Success。

这种字段矛盾是由于日志聚合了多阶段验证的结果，而非单一请求的最终响应。

2. SDK自动重试机制 #

Web应用使用的Azure SDK可能内置重试逻辑：当首次请求因网络层规则被拦截返回403后，SDK自动切换到合规的访问路径（比如通过VNet集成的内部端点）进行重试，最终成功获取密钥。

• 你当前的查询仅筛选了ResultSignature == "Forbidden"，因此只看到首次失败的请求记录，而重试成功的日志未被纳入结果集。

3. 日志字段语义差异 #

• ResultType：反映操作的最终执行结果（即密钥是否被成功获取）；
• ResultSignature/httpStatusCode_d：反映单个请求的HTTP响应状态。
  当请求经历内部重定向或多阶段校验时，就会出现字段值不一致的情况。

验证与排查建议 #

1. 查看同一关联ID的完整日志
   执行以下查询，检查同一CorrelationId下的所有日志条目，确认是否存在重试成功的记录：

AzureDiagnostics | where ResourceProvider == "MICROSOFT.KEYVAULT" | where CorrelationId == "xxxxx-xxxxxx-xxxxxx-xxxxxx"

2. 检查Key Vault网络配置

• 确认Key Vault的虚拟网络规则是否允许Web应用所在子网的访问；
• 检查是否启用了“受信任服务例外”，确认Web应用所属的服务是否在例外列表中。

3. 验证Web应用网络路径

• 确认Web应用是否启用了VNet集成或Key Vault服务端点，确保请求通过合规的内部路径访问Key Vault。

内容的提问来源于stack exchange，提问作者Przemysław Doczkal