问问几支 IT 团队如何处理员工离职，你会听到同样的回答：在 Active Directory 中禁用账户，关闭工单，然后继续处理其他事务。
随后，审计人员调取 Entra ID 清单，发现该账户仍处于启用状态，并且仍被分配了第一天就拥有的应用程序角色。同步过程遗漏了这项变更；由于未配置任何警报，因此没有触发警报；两个目录都显示该账户状态正常，只是对其实际状态的判断不一致。
我经常听到团队说类似的话：在第一次混合审计之前，他们一直信心满满，认为身份安全管理已经万无一失。
“我们已做好 AD 安全治理”并不等于“我们能通过混合环境审计”
大多数团队都有某种 AD 清理流程：每季度审查长期未使用的账户、审核特权组，以及检查密码策略。这套流程确实存在，而且通常有效……但仅限于 Active Directory。
大多数已发布的 AD 安全建议都侧重于通过安装补丁、对管理员账户进行分层管理以及封堵委派路径来加固 AD，以抵御攻击者。这些措施确实有用，但并未回答审计人员真正关心的问题。他们并不是在测试你的目录能否抵御攻击，而是在检验事后审查时，你的身份数据能否作为可靠证据。
问题在于范围界定。该流程几乎总是仅涵盖本地 AD，因为相关工具、职责归属和组织惯例都集中在那里。但审计人员界定审查范围的方式不同：他们关注的是身份在所有可用环境中的实际存在形式和运作方式。在混合 Microsoft 环境中，这也包括同步后的 Entra ID 端。
这就是安全团队认为会被检查的内容与审计人员实际调取的内容之间的差距：
- 团队认为会检查的内容： AD 账户规范、密码策略合规性以及 AD 特权组成员资格。
- 审计人员实际会调取的内容：上述所有内容，以及同步状态和延迟、两个目录之间的权限偏差、同步配置本身的变更历史，还有 Entra 中存在但本地环境没有对应项可供核查的任何权限。相关框架也印证了这一点：SOC 2 的逻辑访问标准（CC6.1–CC6.3）和 ISO 27001:2022 的访问控制措施（A.5.15、A.5.18，以及关于特权访问的 A.8.2）都要求按访问权限的实际状态进行审查，而不是依据某个系统单方面报告的状态。这正是大多数团队在混合环境审查中因仅关注 AD 而产生的盲区。
团队能通过清单中与 AD 相关的检查，却常常在 Entra 相关的检查上措手不及。这并非因为他们工作马虎，而是因为他们仍在用 AD 时代的安全维护流程应对混合时代的环境。
审计人员第一周会调取的五项资料
- 同步延迟与偏差： 该账户已在 AD 中禁用，但在 Entra 中仍拥有特权，因为同步尚未运行、未完整运行，或悄然排除了其从未配置为覆盖的范围。审计人员要求查看差异，而非快照，但大多数团队从未生成过差异报告。没有任何厂商或分析机构公布此类情况发生频率的汇总数据，因为根本没人衡量你被要求弥合的这一差距。只有通过差异比对，才能了解自身现状。
- 同步配置本身的变更历史： 您需要了解谁在何时更改了同步范围或筛选规则。这一点至关重要，因为在真实事件中，它是有据可查的关键转折点，而不只是审计清单上的一个勾选项。微软在2025年8月发布的 Storm-0501 勒索软件团伙分析中就描述了这一情形：攻击者攻陷了一台未受监控的 Entra Connect Sync 服务器，提取了目录同步账户的凭据，随后重置目标用户的本地密码；Entra Connect Sync 随即按其正常机制将新密码同步到云端身份，使攻击者获得了一个从未启用 MFA 的同步全局管理员账户。同步机制完全按照设计运行，却被发现这台无人监控服务器的攻击者所利用。如果同步配置及其管理凭据没有变更日志，您就无法排除这种情况，审计人员也同样无法排除。这也并非孤立现象；CISA、FBI、RCMP、ASD 与 NCSC-UK 针对 Scattered Spider 团伙发布的联合公告记录了多个受害者遭遇的同类手法：攻击者通过诱导服务台重置凭据或 MFA，再借助混合同步路径横向进入高权限云角色。
- 仅限云端且本地无对应项的权限： 直接在 Entra 中分配、从不涉及 AD 的角色或组成员身份，对于仍以 AD 为中心的任何审查流程而言都是不可见的。这些权限既容易被意外创建，也很容易被彻底遗忘。
- 同步/服务账户自身的权限： 运行 Connect Sync 或 Cloud Sync 进程的账户通常拥有比环境中任何人工账户都更高的常驻权限，但在常规 AD 审查中，它往往最少受到检查，因为它看起来不像“用户”。
- 覆盖两端的证据链，而非仅反映当前状态： 审计人员希望了解两个目录中由谁在何时更改了哪些内容。大多数团队都能提供清晰的当前状态报告，但真正能跨越 AD 与 Entra 边界的报告却少之又少。
谁来负责填补这一空白？
AD 通常由基础设施或身份团队负责，而 Entra 则由云或 M365 团队负责。问题在于这种职责分割，而非工具缺失。审计准备工作默认沿袭这种分工，这意味着每个团队都能拿出一份清晰的报告，但仅涵盖各自负责的部分。
原生工具非但没有弥合这一缺口，反而使其更加明显。Active Directory 管理中心可以清晰呈现 AD，Entra 管理中心也可以清晰呈现 Entra。但两者都无法展示它们之间发生了什么，因为这并不属于任何一方的职责范围。
审计失败并不是因为你的目录不干净，而是因为目录被割裂成两部分，却没人负责填补两者之间的空白。
本周检查事项
您无需等到收到审计通知，才了解自身的合规状况。在下次审查前：
- 调取同步错误日志：不要只看成功/失败摘要，还要检查是否有任务虽显示“成功”，实际却存在部分失败或无提示失败。
- 直接比较特权组成员身份在 AD 与 Entra 之间的差异，而无需分别审查两端。
- 盘点同步账户和服务账户的权限，就像盘点人工管理员账户一样。
- 确认变更历史记录的保留情况在双方均存在且具有可比性；不仅要比较当前状态，还要比较历史记录。
- 检查仅限云端的角色分配，这些分配在 AD 端没有可供比较的对应项。
这些都不需要引入新工具即可开始，但确实需要有人对两个目录进行对比，而不是孤立地逐一审查。
这对您意味着什么
混合 AD/Entra 审计所检验的内容与 AD 审计有本质区别，因此它并不只是同类审计的高难度版本。大多数团队仍然只带着一份针对 AD 的检查清单入场，这也正是首次审计往往会发现一些出乎所有人意料的问题的原因。
Netwrix Directory Manager 不会主动提醒你这一同步缺口，但它可以帮助你完成上述大部分手动核对工作，无需再自行拼凑信息。你可以在一个平台上查看 AD、Entra ID 和 Google Workspace 中的组生命周期、所有权及管理员活动，并通过内置审计跟踪记录管理员操作。这能帮助你提前准备好审计人员所需的证据。
分享到
了解更多
关于作者
Dave Miles
David Miles是Netwrix的资深产品经理，负责领导公司身份和访问管理组合中的Netwrix目录管理器（NDM）产品战略。
拥有超过二十年的身份和网络安全经验，David为组织在管理身份、保障访问安全以及降低复杂企业环境中的风险方面面临的挑战提供了实用的视角。
在他的职业生涯中，David一直活跃于技术、安全和产品战略的交汇点，曾在Arctic Wolf、One Identity、Dell和Quest Software担任高级职务。他的经验涵盖产品领导、软件工程、客户参与和市场推广，使他对企业身份安全的技术和业务挑战有着广泛的理解。
David定期与全球的客户和技术团队合作，了解新兴的身份挑战，并将其转化为实用的产品战略和解决方案。
他常驻英国萨默塞特。