一次公司内部的 Azure OpenAI 调用生成了不该出现在外网的文本。安全团队的反应很标准——一分钟吊销密钥。可是问题并没有因此消失，反而更显眼了：谁用这把密钥干的？吊销后的密钥没办法回答这个。

密钥通过校验，不是因为它是安全的选择，只因为它有效。有效和可追踪是两码事。密钥能证明调用者有权限，可是对“作者是谁”一丁点线索都不给。安全事故复盘时，全部工作正好就卡在这个断层上。

打开网易新闻 查看精彩图片

接下来是一个工程拆解：为了获得调查能力，访问 Azure AI 时该选微软 Entra ID 而不是密钥；并且在把这种访问称作“可调查”之前，到底需要看到什么证据。下面会用两个服务主体的场景跑一遍可重现的检查计划——注意，这不是一份已完成实验的报告。

开发者在搜索框敲 azure ai api，通常五分钟就能跑通：从门户复制密钥，塞进请求头，模型立刻返回结果。这份便利本身就是陷阱。密钥是整个资源的共享秘密，根本不等同于使用者的身份。如果密钥被五个服务和三个工程师同时知道，一次成功调用只能说明：发起方手里有这把密钥。

先把讨论边界划清楚：这不是泛泛的“托管身份比密码好”，而是针对 Azure AI 调用的可审计性——能不能凭日志证明，是哪个工作身份、带着哪个角色，执行了这次数据平面上的模型推理？跑在 Azure 外部的负载不在这个范围里，因为外部环境有自己的日志和答案路径。

贯穿全文的待验证命题是：如果日志无法把某次 Azure AI 调用与对应的工作身份及其角色绑定起来，那 Entra ID 在这个场景里就没有优势，谈不上“有利于调查”。不是“通常更好”，是“没绑上就不叫更好”。

根据 Microsoft Learn 文档（访问日期 2026-07-18），Azure OpenAI 和 Foundry 资源支持通过微软 Entra ID 代替 API 密钥进行身份验证，但必须满足两个硬性条件。第一，资源必须配置了自定义子域，否则 Entra ID 认证根本打不开。第二，调用方（用户、服务主体或托管身份）必须持有类似 Cognitive Services OpenAI User 或 Cognitive Services OpenAI Contributor 的角色，否则推理请求会被直接拒绝。

客户端的调用流程在文档里展示得很清楚：用 DefaultAzureCredential 从 Entra ID 拿到 bearer 令牌，然后用这个令牌去请求模型。双服务主体的审计场景就是这条流程的复现，区别只在于每个身份各拿各的令牌。

这样一来，调查的核心链条就变得可验证了。不再凭一把不知道谁在用的密钥，而是靠明确的身份与角色去对应每一笔调用。安全团队看日志时，不再是面对一堆来源不清的请求，而是直接看到“带着 Cognitive Services OpenAI User 角色的 app-eu-checkout-dev 在 14:22 调用了模型”。

真正的分水岭在于可证明性。如果日志里有关身份、角色和时间戳的记录足够完整，Entra ID 才算真正发挥了调查价值。否则，哪怕换掉了密钥，也只是换了一个同样无头无尾的访问凭据。