迪康准入场景下终端安全基线检查的技术实现

​一、定位：安检是"有条件准入"的执行环节

准入控制回答"这台终端能不能入网"，通常有三类判定依据：身份（它是谁）、合规（它够不够安全）、权限（它能访问什么）。其中"合规"这一层由终端安全检查（下称安检）承担。

逻辑很简单：终端通过了身份认证，只能说明"它是登记在册的那台机器"，不代表它当前是安全的——杀毒软件可能卸载了，系统补丁可能半年没打，GUEST账户可能开着，密码可能是123456。如果放任这类终端入网，准入系统等于只在门口查了身份证，没查健康状况。

因此完整准入策略通常被设计成条件组合：

允许入网 = 设备注册且审核通过
         AND 客户端在线（若干小时内上过线）
         AND 客户端安检通过

不满足条件的终端不被放行，或者放行到隔离区只许访问修复资源。安检的精确性直接决定这套机制会不会误伤正常办公——检查项设计得太粗，正常终端频繁被拦；太细，客户端开销和维护成本又上去。

二、检查项的技术原理

安检项可以按实现方式分成四类。

2.1 配置与状态读取类

这类检查本质是读取操作系统提供的标准接口，与人工核查用同一信息源，可信度高、开销低。

• 杀毒软件检测：Windows通过WMI查询AntiVirusProduct命名空间，或在注册表SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall中匹配指定杀软的卸载项，确认其安装状态；进一步可查询杀软的病毒库更新时间（多数杀软在注册表或WMI中暴露）判断"装了但长期没更新"的情况。检查配置支持指定杀软名称和下载地址，未安装时引导用户从指定地址下载安装。
• 系统防火墙检测：查询Windows Firewall服务运行状态及各配置文件（域/专用/公用）的启用状态。注意"服务在运行但防火墙被组策略关闭"这种半开状态，需要同时校验服务与策略两个层面。
• GUEST账户检测：查询本地账户的启用状态。Windows的GUEST账户有SID后缀"-501"的固定标识，直接查比按名称查可靠（账户可被改名）。
• 屏保/共享/账户策略检测：读注册表（屏保超时、密码保护屏保）和net share等接口。共享检测需要排除系统默认管理共享（ADMIN、IPC ），只关注用户创建的共享，否则所有Windows终端都过不了检。

2.2 内容比对类

这类检查需要维护一份"基准清单"，把终端现状和清单逐项比对。

• 操作系统漏洞检测（补丁检查）：客户端通过WMI Win32_QuickFixEngineering或Windows Update Agent API枚举已安装补丁，与管理员维护的补丁清单比对。清单之外的内核版本检测则是读取版本号，判断是否在允许的最高/最低版本区间内。
• 安装软件/运行程序检测：枚举已安装程序（注册表卸载项、开始菜单快捷方式、安卓的包管理器列表）和运行中的进程，与黑名单/白名单比对。支持"安装a或者安装b"这类柔性条件，本质是把白名单设计成析取逻辑，避免业务上合理的软件替代方案被误杀。
• 侦听端口/系统服务/启动项检测：枚举TCP/UDP监听socket、服务控制管理器中的服务状态、注册表Run键和启动文件夹。风险端口清单和服务清单由管理员维护。

2.3 口令强度类

• 弱口令检测：在终端本地执行口令校验，而非把密码传到服务器。实现方式通常是客户端调用操作系统的口令验证接口，用弱口令字典逐个尝试本地账户。字典的覆盖质量决定检出率——默认字典加自定义条目。信创环境下需要适配国产操作系统的PAM认证接口。这类检查天然敏感，必须保证只在本地内存中完成比对、不留存任何口令明文。

2.4 环境探测与自定义类

• 违规外联检测：客户端主动探测当前网络环境能否到达互联网——向多个公网探测点发起HTTP/ICMP/DNS请求，任一可达即判定外联。与无客户端的外联检测（网络侧推断）不同，客户端检测是终端自己"自首"，准确率高，但需要客户端在线。
• AD域检测：终端加入的域是否在指定域列表内，读ComputerSystem.Domain属性即可。
• 自定义脚本检测：管理员编写脚本下发到终端执行，以进程退出码作为判定依据——退出码0通过，非0不通过。这是整个安检体系的扩展出口：系统内置检查覆盖不了的场景（注册表特定键值、行业专有客户端的运行状态），都可以脚本化接入。退出码约定简单到近乎简陋，但换来了最大的灵活性，这也是各类终端管理平台的通用做法。

2.5 跨平台的裁剪

检查项不是全集下发。以迪康网络准入控制系统的客户端安检配置为例：Windows项最全（杀毒、补丁、域检测等20余项），苹果终端裁掉了域检测、补丁检测（macOS补丁机制不同）等，保留外联、运行程序、启动项、主机名、端口、版本、自定义脚本；安卓则完全围绕移动端特性重建：安装应用、运行应用、锁屏密码、热点、蓝牙。信创终端介于两者之间，防火墙、弱口令（走PAM）、屏保、外设检测都要针对国产系统单独适配。

这种按平台裁剪的设计有一个隐含约束：安检策略引擎的判定逻辑必须与检查项解耦——策略只问"这个检查项通过了吗"，不关心客户端是怎么查的，否则平台扩展时策略层要跟着重写。

三、触发时机与执行策略

检查的触发点有三个：

1. 开机触发：客户端随系统启动完成首轮安检，把住"过夜变化"的主要关口；
2. 环境变化触发：网络切换、IP变更、补丁安装、软件装卸等事件触发复检，防止"开机时合规、使用中变违规"的空窗；
3. 服务器端周期/手动触发：管理员下发即时检查，用于抽查或应急排查。

性能上的工程考虑：全量检查（补丁枚举、软件比对）在终端上是IO和CPU密集操作，开机高峰期数千终端并发执行会冲击准入服务器和终端自身的可用性。常见做法是检查结果在服务端缓存，客户端仅上报变化部分；全量检查错开执行窗口。

四、关键检查项与处置分级

并非所有不合规都等价。"没装指定杀软"和"屏保没设置"的安全权重完全不同，处置必须分级：

• 普通检查项：未通过则记录并弹窗提醒，不阻断入网——管理员可事后追溯整改；
• 关键检查项：管理员可指定任意检查项为关键项（如杀软、补丁、违规外联），该项未通过则触发阻断处置。

这就是"关键检查项"机制的设计意图：让每家单位按自己的风险优先级定义"一票否决"项，而不是厂商替用户拍板。配置灵活性的代价是责任转移——管理员把弱项设成非关键，风险就真实落地了，所以审计上通常要求关键项的变更也留痕。

五、处置动作的实现阻断不是只有"断网"一种。处置动作包含四档，由轻到重：

断网白名单是个关键的工程细节：没有白名单的断网等于把终端变成孤岛，用户连"去哪里装杀软"都不知道，修复无从谈起，投诉会淹没管理员。白名单网段保证"断网不断修复通道"，安检才形成闭环：阻断 → 引导 → 修复 → 复检 → 恢复。

执行顺序上，客户端先执行处置动作、再上报服务端，服务端据此调整准入设备对该终端的放行状态——客户端处置与准入联动是双保险：客户端被卸载或失效时，准入层的MAC/IP阻断兜底；准入层被绕过（终端不经过准入网关）时，客户端本地处置兜底。

六、误报治理

安检误伤的主要来源是检查基准与现实的错配：

• 补丁清单里的某补丁与业务软件冲突，被 IT 私下卸载了——终端合规性事实与清单冲突；
• 软件黑名单写得太宽，把某业务的合法组件拦了；
• 弱口令字典太激进，把包含姓名拼音的正常密码判为弱口令。

对应的治理手段：检查结果必须带详细明细（哪一项、当前值、期望值），用户和管理员能看到"为什么不过"，而不是一句"安检未通过"；安检日志逐次留存，支持按终端回溯每次检查的全量结果，为调整基准提供依据；灰度策略——新检查项先设为"只记录不阻断"运行一段时间，观察误报率后再升级为关键项。

七、结语

终端安检是把"安全基线"从制度文本变成强制执行点的机制。它的技术构成并不复杂——状态读取、清单比对、本地口令校验、脚本扩展——真正的工程难点在三个地方：跨平台检查项的裁剪与适配、处置分级与白名单通道带来的闭环设计、以及用详细留痕和灰度手段控制误报率。安检项查得全不等于管得好，判断一套安检体系成熟与否的标准是：正常业务是否无感，违规终端是否有路可修。

​