云身份认证日志的盲点

TrustedSec 的一支安全团队最近披露了绕过 Azure 登录日志记录的第三和第四种方法。也就是说，已经有四种独立的技术，可以在不产生日志记录的情况下完成 Microsoft 云服务的身份认证，而安全团队恰恰依赖这些日志做检测。登录确实发生了，日志却没有记录。任何监控这些日志以发现可疑活动的人，什么都看不到。

这不是纸上谈兵的问题。如果攻击者窃取凭证并用来访问你的 Azure 环境，安全团队的第一反应就是查看登录日志。如果这些日志不完整，如果整类身份认证根本不会生成日志条目，那么你的检测能力就存在一个你并不知道的漏洞。而你一直基于日志是完整的这一假设在做安全决策。

认证日志为何会有缺口

一种常见的想法是，身份认证日志记录很简单：有人完成认证，你就记下来。实际上，云端身份认证是一个庞大复杂的系统，涉及数十种协议、端点和令牌类型，而各处的日志覆盖范围参差不齐。

Azure Active Directory（现称 Entra ID）负责处理 Microsoft 365、Azure 资源、通过 SAML/OIDC 接入的第三方应用、经由 App Proxy 访问的本地遗留应用、服务主体、托管标识等的身份认证。每条认证路径都有自己的后端、自己的日志管道，以及自己的边界情况。登录日志由认证服务生成，但某些认证流程会绕过标准服务，或者走的是早于当前日志基础设施的遗留路径。

遗留协议的缺口

Microsoft 为了向后兼容，仍保留着 2000 年代初期的认证协议，而这些协议早于其现代日志基础设施。一些 SMTP、IMAP 和 POP3 的认证路径使用「Basic Auth」流程，在邮件传输层完成认证，而不是通过标准的 Azure AD 令牌端点。这些认证可能不会生成现代 OAuth/OIDC 流程所产生的同类登录日志条目。

Microsoft 多年来一直在逐步弃用 Basic Auth，但在企业环境中，弃用进展十分缓慢。仍在使用旧版邮件客户端、会通过邮件发送文档的扫描仪，或较老业务应用的组织，可能仍开启着 Basic Auth。每一条遗留路径都可能是一个潜在的日志缺口。

服务主体认证

服务主体是应用程序和自动化任务使用的非人类身份，它们的认证方式与用户不同。它们的登录事件出现在独立的日志流中（服务主体登录、交互式登录与非交互式登录各自分开）。如果安全团队只监控交互式登录日志，就会完全漏掉服务主体的活动。

这一点很关键，因为服务主体被攻陷是常见的攻击入口。攻击者只要拿到服务主体的凭证或证书，就能以该应用的身份完成认证，并访问它有权限的任何资源。如果安全团队只盯着用户登录，他们永远不会发现这类活动。

令牌重放与刷新

并非每次访问都需要重新认证。OAuth 刷新令牌允许在不再次认证的情况下持续访问。如果攻击者通过被攻陷的设备、截获的流量或恶意软件窃取了有效的刷新令牌，就可以用它换取新的访问令牌，而不会触发基于密码认证时那样的登录日志。最初的登录会被记录，但后续的令牌刷新可能以非交互式登录的形式出现，而很多检测规则并不监控这类事件。

检测工程的难题

认证日志的缺口揭示了云安全中一个更广泛的问题：我们在那些想当然认为完整的日志之上构建检测系统，然后当攻击者找到不产生日志的路径时，又表现得十分意外。

云环境的标准安全架构大致是这样的：云服务生成日志 → 日志流入 SIEM（安全信息与事件管理系统）→ 检测规则分析日志中的可疑模式 → 告警触发调查。只有日志确实捕获了所有相关活动，这套体系才能发挥作用。如果日志不完整，你的 SIEM 就只是在用一种非常昂贵的方式监控一幅残缺的画面。

Typical detection rule logic:
IF sign-in from unusual location
AND sign-in at unusual time
AND multiple failed attempts followed by success
THEN alert: possible credential compromise
What this misses:
- Authentication via legacy protocol → no sign-in log entry
- Stolen refresh token → appears as normal non-interactive sign-in
- Service principal abuse → in a different log stream entirely
- Authentication bypasses → sign-in doesn't appear at all
The rule is correct. The data it operates on is incomplete.

你实际能做什么

云服务商的日志缺口你无法直接修补，那是 Microsoft（或 AWS、Google）的责任。但你可以构建不完全依赖认证日志完整性的检测策略。

监控多个日志来源

认证日志只是一个信号源，活动日志是另一个。即使攻击者的登录没有出现在认证日志中，他们随后的操作（读取邮件、访问文件、查询数据库、修改配置）仍会生成各自的日志条目。将活动日志与认证日志交叉关联，可以揭示其中的不一致：无论登录为何没有被记录，来自一个近期没有对应登录的身份的活动本身就是可疑的。

-- Detection query: activity without recent authentication
-- (KQL-style for Azure Sentinel/Microsoft Sentinel)
let timeframe = 24h;
let activity_logs = AuditLogs
| where TimeGenerated > ago(timeframe)
| summarize Actions = count() by Identity, bin(TimeGenerated, 1h);
let signin_logs = SigninLogs
| where TimeGenerated > ago(timeframe)
| summarize LastSignIn = max(TimeGenerated) by UserPrincipalName;
activity_logs
| join kind=leftanti signin_logs
on $left.Identity == $right.UserPrincipalName
| where Actions > 5  // filter noise
// Results: identities with activity but no sign-in log entry
// These need investigation — either a logging gap or a bypass

禁用遗留身份认证

如果你没有在使用遗留协议（SMTP、IMAP、POP3 的 Basic Auth），那就把它们禁用掉。绕过现代日志记录的认证路径一旦无法使用，整类日志缺口也就随之消失。Azure 的条件访问策略可以按用户、按组或按租户范围阻止遗留认证。

禁用之前，先审计当前的使用情况。讽刺的是，Azure 登录日志确实会显示部分遗留认证尝试，而 Entra ID 中用于遗留认证的工作簿有助于找出仍在使用旧协议的应用。先修复这些应用，再阻止遗留认证。

监控令牌活动

如果你的环境支持，请启用持续访问评估（CAE）。CAE 允许 Azure AD 在条件变化时近实时地撤销令牌（例如用户被禁用、检测到高风险登录、IP 位置变化）。没有 CAE 的话，被盗的访问令牌会一直有效直到过期，通常是一小时，无论安全团队做了什么。

还要监控令牌的生命周期和刷新模式。如果某个刷新令牌从新的 IP 地址、新设备或异常时段被使用，就应该标记出来，这往往是令牌被盗的唯一信号。

测试你自己的日志记录

最有效的做法，是定期测试你的日志是否真的捕获了你以为它们会捕获的内容。通过你的环境支持的每一种方式进行认证（交互式、非交互式、服务主体、遗留协议），然后验证每一种方式是否都生成了预期的日志条目。如果没有，你就在攻击者之前发现了一个缺口。

这是一种很少有组织系统性去做的检测工程测试。大多数团队编写检测规则后就默认它们能正常工作。验证底层数据质量，确认规则所依赖的事件确实被记录了下来，可以说比规则本身更重要。

更广泛的启示

Azure 登录日志的绕过问题并非 Microsoft 独有。每家云服务商都存在日志记录不完整的认证路径。AWS CloudTrail 也有其已知的缺口，例如某些区域的部分控制平面操作、某些服务关联角色的承担行为，以及可能掩盖原始身份的跨账户角色链式调用模式。Google Cloud 的审计日志同样存在类似的边界情况。

这个教训不是「Azure 日志坏了」，而是所有日志都是不完整的，假设并非如此的安全架构终将失效。纵深防御不仅仅是部署多层安全控制，更在于拥有多个相互独立的可见性来源。如果你的检测完全依赖某一个日志源是完整的，那么你的安全态势就存在单点故障。

围绕「任何单一日志源都可能不完整或被绕过」这一假设来构建你的检测体系。关联认证日志、活动日志、网络日志和端点遥测数据。留意不同来源之间的不一致，它们往往恰好指向攻击者正在利用的那些缺口。并且定期测试你的日志，因为你不知道的那个缺口，终将被用来对付你。