终端合规检查是网络准入认证系统里最重要，也最容易翻车的功能模块。它的逻辑本身不复杂——检查终端是否满足安全要求，满足了就放行，不满足就隔离。但现实落地的时候，这个模块带来的事故比它解决的问题还多：要么检查规则太宽松变得形同虚设，要么规则太激进把正常业务全拦住了。本文从几个实际角度，聊聊合规检查到底怎么设计才能不踩坑。

合规检查项目怎么选，先保底线再求完美

一套准入系统的合规检查项目列表可以很长：操作系统补丁、杀毒软件状态、防火墙是否开启、特定端口是否封闭、是否安装了指定的安全组件、注册表键值是否符合要求、硬盘是否加密、USB 口是否禁用。理论上都可以查，但实际不能全都查。

合规检查的设计原则是：先确定几条绝对不能让步的底线规则，这些规则一旦不满足，设备不能接入网络。底线规则的数量应该控制在 5 条以内，而且要足够明确——比如"杀毒软件必须正在运行且病毒库更新不超过 72 小时""操作系统必须安装最近 60 天内发布的关键安全补丁"。

底线以上的规则可以设为"告警但不断网"的软性检查。设备接入网络后，系统弹出一个提醒，告知用户有哪些项需要整改，并给出整改期限——期限到了还没改，软性检查自动升级为硬性阻断。

这个"软硬分级+自动升级"的机制，比一开始就全部硬性阻断要合理得多。它给终端使用者留出了整改时间，也给 IT 团队留出了沟通和调整策略的缓冲期。

补丁检查怎么做才能准

补丁检查是合规检查里最常见、也最容易出错的一项。Windows 补丁的命名和编号规则变过好几次，而且不同语言版本、不同系统版本（Windows 10、Windows 11）的补丁编号也可能不同。准入系统 Agent 在做补丁检查的时候，必须能正确处理这些差异。

一个实用的方案是，不做"精确匹配特定 KB 编号"的检查，而是做"安全等级是否满足"的检查。比如定义规则为"需要安装 Microsoft 定义的 Critical 和 Important 级别的安全更新"，Agent 通过调用 Microsoft 的更新 API 来判断终端是否满足，而不是自己维护一个 KB 编号黑名单。

但这个方案的局限性也很明显——它要求终端能访问微软更新服务器，而很多企业内网终端是不具备这个条件的，它们依赖内部的 WSUS 或 SCCM 来分发补丁。如果内部补丁服务器不稳定或者没有及时同步最新补丁，合规检查就会有不准确的情况。

在实际项目中，比较务实的做法是：以内部 WSUS/SCCM 服务器的状态为准，但不直接要求终端"安装了所有可用补丁"，而是给一组已知的高危 KB 编号做对照。这组编号来自单位的漏洞管理平台或者安全通报，每季度维护一次。

杀毒软件检查要防"装了但没跑"

准入系统检查杀毒软件，通常有两种方式：通过 Agent 读取终端的操作系统 API（如 Windows Security Center 或 WMI 接口），检查杀毒软件是否已注册、是否正在运行、病毒库更新时间。这两种方式看起来可靠，但其实有盲区。

有些杀毒软件在安装成功后，可以在操作系统的安全中心里注册，但如果用户手动停止它的实时保护功能，安全中心可能仍然报告"安装了"，准入系统就这样放行了。还有一些非主流杀毒产品根本不向 Windows 安全中心注册，准入系统 Agent 也就检测不到。

为了降低漏检概率，可以在 Agent 里增加"进程检查"作为补充手段。不直接依赖 Windows 安全中心的注册信息，而是去确认对应杀毒软件的守护进程是否确实在运行。还可以加上定时重检机制——即使终端通过了第一次认证，每隔一段时间重新抽查一次杀毒软件状态，发现异常就立即触发隔离。

这些额外检查会增加 Agent 的资源开销，但只要把检查频率控制合理（比如每次认证时做一次，之后每 4 小时重检一次），就不会对终端使用体验产生明显影响。

注册表和配置文件检查要控制数量

一些安全要求较高的单位，会要求准入系统检查终端上某些注册表键值或配置文件是否符合安全基线。例如：Windows 的 UAC 开启状态、Remote Desktop 是否禁用、TLS 的最低版本要求、某些服务是否禁止启动。

这个功能在落实中容易出现的两个问题：一是检查项数量太多，Agent 每次认证都要扫描几十个注册表键值，影响终端启动速度；二是检查规则内写死了路径，一旦操作系统版本更新或编辑了组策略，路径就会变化，合规检查就会产生大量误判。

控制注册表检查数量的方法是：只检查通过组策略管理的几个核心注册表路径，不检查通过第三方软件写入的自定义键值。路径方面要尽量使用"注册表根键+键值名"的方式来检查，避免使用硬编码的完整路径，这样在不同 Windows 版本之间才能保持兼容。

磁盘加密检查的兼容性坑

磁盘加密合规检查（BitLocker 或 FileVault 是否开启）是一个看起来简单但兼容性问题不少的项目。BitLocker 的状态不是单纯的开或关，它可能处于"加密中""解密中""已暂停""等待激活"等多个中间状态。准入系统的合规检查需要能正确区分这些状态，做出对应判断。

FileVault 在 macOS 上的情况类似——它可能已经开启但尚未完成首次加密，或者加密密钥已经托管到 MDM 管理平台，但在本地接口里显示状态为"未完全保护"。

处理方式是，把磁盘加密的合规规则从简单的"是/否"改成"状态级别"的方式来检查。例如："正在加密中"和"已加密"都视为合规，"已暂停"视为告警，"未启用"才视为不合规。这样能显著降低误判率。

合规失败后的隔离不能太粗暴

终端合规检查不通过时，准入系统的默认动作通常是"隔离到修复区"，终端只能访问修复服务器来下载补丁或更新杀毒软件。但这有一个用户体验问题——终端被隔离后，用户几乎立刻就会打电话给 IT 支持，而 IT 支持对这些合规检查规则可能也不熟悉，双方的沟通成本非常高。

改进方式是提升隔离页面的信息可读性。终端被隔离后，浏览器跳转到 Portal 页面，页面上必须清晰地告诉用户：你不合规的具体原因是什么、你需要做什么来修复、修复后点哪个按钮重新检测、大概需要多长时间。如果隔离页面只是一句"您的设备不符合安全策略"，那它的唯一作用就是让用户去投诉。

另外，有些设备被隔离是因为企业策略变更导致的（比如昨天合规基线更新了），而不是终端状态发生变化。这类情况如果也直接隔离，从用户的角度看就是"我什么都没干，突然上不了网了"。应该在策略变更通知里加入缓冲期设置，让终端有几天时间主动更新，逾期未更新再执行隔离。

合规检查模块的颗粒度、隔离提示、整改流程，这三件事配好了，这个模块才算真的能跑起来。配不好，就是每天都在接电话处理误报。