Azure密钥保管库与VM磁盘加密‘访问被拒绝’问题排查

我之前在做Azure VM加密的时候也踩过类似的“访问被拒”坑，结合你描述的场景，整理了几个最可能的原因和实用的调试步骤，应该能帮你定位问题：

• 权限生效延迟或范围问题：就算你给了密钥保管库全权限，Azure的权限同步偶尔会有5-10分钟的延迟，刚设置完就执行命令很可能还没生效。另外要确认应用注册的权限是针对这个特定密钥保管库的，而不是全局的（有些时候不小心选了整个订阅但没指定到具体Vault），还有应用的客户端密钥有没有过期——过期的凭据直接导致身份验证失败。
• PowerShell身份不对：你执行加密命令时，是不是用自己的用户账号登录的PowerShell？加密操作需要用应用注册的服务主体身份来执行，而不是你的个人账号。要是没切换身份，就算Vault给了应用权限，当前会话用的身份还是没权限的。
• 密钥保管库的网络限制：如果你的Vault开了防火墙或虚拟网络规则，那执行PowerShell的机器或者目标VM可能不在允许访问的范围内。比如Vault只允许特定VNet内的资源访问，而你在本地机器执行命令，IP不在白名单里，直接就被拒了。
• VM/磁盘的权限缺失：加密VM不光需要Vault的权限，还得有VM和磁盘的写入权限！应用注册需要对目标VM所在的资源组有Microsoft.Compute/virtualMachines/write和Microsoft.Compute/disks/write权限，不然就算Vault能访问，也没法修改VM的加密设置。
• 软删除/ purge保护的冲突：虽然概率低，但如果Vault之前有软删除的密钥，或者开了purge保护，可能在加密过程中触发权限校验问题，可以排查下Vault的软删除状态。

• 先确认当前PowerShell的身份：执行Get-AzContext，看输出里的Account是不是你的应用注册ID。如果不是，用这个命令切换身份：

  $cred = Get-Credential -Message "输入应用注册的客户端ID和密钥"
  Connect-AzAccount -ServicePrincipal -ApplicationId <你的应用ID> -TenantId <租户ID> -Credential $cred
  

• 测试Vault的基础访问：用当前身份执行Get-AzKeyVault -VaultName <你的Vault名称>，如果这一步就报错，那肯定是Vault的权限或身份问题；如果能成功获取，说明Vault权限没问题，问题出在VM那边或者网络。
• 临时关闭Vault网络限制测试：去Azure门户的Vault“网络”设置里，临时把访问范围改成“所有网络”，再执行加密命令。如果成功了，说明之前的网络规则限制了访问，再把规则改回合适的范围就行。
• 检查VM资源组的IAM权限：进入VM所在的资源组，打开“访问控制(IAM)”，搜索你的应用注册，确认它有虚拟机参与者或磁盘参与者角色，或者自定义角色包含必要的写入权限。
• 查Azure活动日志找细节：这是最有效的方法！进入Vault的“活动日志”，筛选“失败”的事件，找到“访问被拒”的那条，里面会明确告诉你是哪个权限缺失、哪个身份发起的请求，直接定位问题根源。
• 重新刷新权限：有时候权限同步慢，你可以先移除应用注册的Vault访问策略，过2分钟再重新添加，等5分钟后再执行加密命令试试。

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