简介智华计算机终端保密检查系统是一套面向Windows环境的终端保密检查工具主要服务政府机构、企事业单位及研究机构等需要严格保密管理的组织用于实时监控终端行为、发现违规外联与敏感信息泄露风险并提供评估报告与整改建议。资源包共683个文件大小约295.76MB以DLL动态库、BMP图像资源、EXE可执行程序为主体辅以XML配置、INI设置、TTF字体以及说明文档既包含可运行的程序组件也带有配置与辅助资料。系统核心涵盖实时监控、违规行为检测、安全评估、防护策略定制、报警审计与整改指导等环节可对网络活动、文件操作、系统设置变化进行持续跟踪帮助用户在Windows端形成闭环的保密检查流程。目前已有4338人学习/下载适合安全运维人员、保密管理专员以及对终端安全评估感兴趣的开发者参考使用。1. 智华计算机终端保密检查系统把保密检查从人工翻文件变成全量自动扫描一次例行保密检查两名检查人员对着一栋楼的终端逐台开箱翻文件、查U盘记录、看打印日志一周过去只查了三分之一没多久一份标密文档还是从没查到的终端里流了出去。问题不在人在于这种检查方式是抽查、低频、全靠肉眼。智华计算机终端保密检查系统就是把这一环节做成终端侧全量自动扫描客户端装上、策略下发文件、外设、打印、网络、账号五个方向的检查项自动跑违规记录带证据回传管理端直接盯整改闭环。适合保密办、信息化部门和安全运维团队也适合把保密检查从运动式抽查变成常态化审计的单位。这篇笔记按实际落地路径讲部署、参数、误报和坑。2. 把保密要求翻译成终端检测项五个检查域、判定阈值与最小扫描策略2.1 检查域划分文件、外设、打印、网络、账号先圈边界再定动作智华计算机终端保密检查系统上线前第一件事不是装客户端而是把本单位保密制度逐条拆成“终端上可观察的行为”。常见做法是分成五个检查域每个域对应一类违规场景。文件检查域盯的是终端上是否存放标密文件、是否在非涉密目录出现涉密标识文件以及文档名和内容是否命中敏感关键词外设检查域记录USB存储设备接入痕迹识别未登记介质和违规拷贝打印检查域收集打印任务记录和虚拟打印产物重点查“打印后不回收”的涉密文档网络检查域关注违规外联、私自架设热点和异常网络共享账号检查域则检查弱口令、Guest账户、管理员组成员异常。边界圈定后每个检查域还要定义“动作”。文件扫描可以只记录告警也可以对命中文件做隔离外设接入可以记录事后追溯也可以实时弹窗提示。我的建议是刚上线阶段全部先只读不阻断跑两周拿到误报基线再逐步打开限制动作否则第一天就会收到大量“系统把我文件锁了”的投诉。这五个域的开关、扫描路径、关键字库、阈值都是策略配置的一部分在管理端按部门或终端分组下发。同一个单位里研发部门的源码目录和后缀名规则跟行政部门的关键字库完全不同按分组隔离策略是减少误报的第一步。2.2 判定阈值关键词命中不等于违规两级判定才压得住误报很多初次部署的人会把关键字库拉得很长结果第一轮全盘扫描跑完告警上千条保密办根本没人力复核。这里的关键是两级判定先按文件属性过滤再按内容特征复核两级同时命中才记为疑似违规。一级过滤用扩展名和文件名特征比如抓取含“机密”“秘密”“内部”等密级标识的文档名以及Office、PDF、WPS等可承载标密内容的格式二级复核再读取文件内容匹配更细的关键字指纹。只有文件名和内容都命中才产生一个中危以上告警。单靠文件名命中只记低危单靠内容命中也不直接定性而是进入待观察列表。以下是一个简化版的两级判定脚本逻辑上可以直接跑也可以作为策略规则的设计参考import os import re # 一级过滤扩展名 文件名密级标识 TARGET_EXTS {.doc, .docx, .pdf, .wps, .et, .xls, .xlsx} NAME_MARKS [机密, 秘密, 内部资料, 涉密] # 二级复核内容关键字指纹按命中数量决定等级 CONTENT_FINGERPRINTS [ 项目代号, 人员名单, 技术方案, 预算明细, 联系方式 ] def scan_file(file_path): ext os.path.splitext(file_path)[1].lower() name_hit any(mark in os.path.basename(file_path) for mark in NAME_MARKS) if ext not in TARGET_EXTS: return None # 一级过滤未过直接跳过 if not name_hit: return None # 文件名不戴标识最多后续做低危观察 try: with open(file_path, r, encodingutf-8, errorsignore) as f: content f.read() except Exception: return (IO_ERROR, file_path) hit_count sum(1 for fp in CONTENT_FINGERPRINTS if fp in content) if hit_count 2: # 双重命中文件名带标识 内容命中2个以上特征 return (HIGH, file_path) if hit_count 1: # 单内容命中记为疑似 return (MID, file_path) return (LOW, file_path) # 只有文件名命中低危观察逻辑说明这个脚本先通过扩展名和文件名标识做第一级过滤把大量正常文档挡在门外避免每个文件都做内容读取。只有文件名带密级标识的文档才进入内容识别这么做是为了让内容读取的文件数量控制在可接受范围。参数说明NAME_MARKS和CONTENT_FINGERPRINTS是本地的关键词配置实际系统里会在管理端维护一份关键词库客户端启动时拉取增量更新。hit_count 2是典型的最小判定条件太严会漏太松会炸。我更推荐把阈值做成按部门调整的配置项而不是写死在客户端里。2.3 检查项与扫描策略参数表先配一个不会干扰办公的扫描节奏检查项不是越多越好扫描策略也不是越快越好。智华计算机终端保密检查系统的策略下发里以下几项是上线前必须逐项确认的配置项默认值建议说明扫描路径各磁盘用户目录排除系统目录系统目录文件多、权限杂扫描收益低且易触发审计噪音扫描触发方式每日定时 移动介质接入时即时扫描定时扫描覆盖日常即时扫描覆盖U盘插入场景并发扫描线程数2终端配置普遍不高的场景下4线程以上会明显卡顿CPU占用上限30%超过这个值用户办公体验会先崩关键字库更新频率每日增量下发太频繁会让客户端频繁重启扫描任务告警上报方式实时上报网络离线时本地缓存涉密终端常有断网隔离场景必须有离线缓存这份参数表里最容易被忽略的是“扫描触发方式”。很多单位怕漏检把触发方式配成全盘每小时一次结果用户电脑风扇狂转IT部门电话被打爆。合理的节奏是工作时间只做增量扫描午休或下班时间做全盘扫描移动介质插入时做即时扫描。扫描频率和CPU限制不是谁拍脑袋定的而是跟终端硬件强相关。如果单位里还有一批内存4G以下的旧终端并发线程数要降到1扫描时段要推到晚上。策略下发前先做一轮终端硬件摸底按配置分三档下发比一套参数通打全部要稳妥得多。3. 部署与客户端管控从服务端初始化到终端下发关键参数别乱调3.1 服务端环境的初始化与部门终端分组服务端一般部署在一台独立服务器上数据库单独存放审计数据。初始化时需要注意的不仅是装好服务还有目录规划、端口选择、证书配置三件事。数据目录要和程序目录分开这个习惯能在后期做备份恢复时省很多事。服务端口默认有一个但涉密网络里常有端口限制初始化时就把端口改成规划好的内网端口避免上线之后再做变更。客户端和服务端之间的通信建议启用证书校验防止内网里有设备伪造服务端骗取客户端数据。常见的初始化步骤大致如下实际命令以产品手册为准# 1. 创建独立数据目录避免与程序目录混放 mkdir -p /data/zhihua/{db,backup,audit} chown -R zhihua:zhihua /data/zhihua # 2. 初始化服务端数据库 /opt/zhihua/server/bin/init_db.sh --data-dir /data/zhihua/db # 3. 修改服务监听端口 vi /opt/zhihua/server/conf/server.ini # server_port8443 # 按内网规划调整避开常见端口 # 4. 生成并部署通信证书 /opt/zhihua/server/bin/gen_cert.sh --cn zhihua-server # 5. 启动服务端并确认状态 systemctl start zhihua-server systemctl status zhihua-server参数说明--data-dir指定数据目录是为了备份和迁移时只操作这一个目录不用在程序目录里翻找server_port务必改成不冲突的内网端口默认端口在涉密网络里经常被封禁证书的 CN 字段要与服务端实际访问地址保持一致否则客户端校验证书会失败。服务端起来之后先建部门和终端分组。分组结构直接影响策略下发和告警归属建议按行政架构建组比如“综合部”“研发一部”“财务部”每个组单独挂策略。不要只建一个“全员”组否则后面调整关键词库或扫描策略时只能全量下发误报控制无从谈起。3.2 客户端静默安装与策略下发先试点再全量卸载权限要分级客户端安装是上线阶段最容易被低估的工作量。终端数量上百后一台台手工装不现实必须做静默安装。智华系统的客户端安装包一般支持命令行静默参数安装完成后自动在系统服务里注册并在桌面生成一个小的状态图标。静默安装的常见写法如下# 静默安装客户端指定服务端地址和分组编码 zhihua-client-installer.exe /S /server192.168.10.20:8443 /groupresearch1 /silent # 等待安装完成确认服务已注册 sc query zhihua-agent参数说明/S是对应静默安装的通用参数开关不弹交互界面/server指定服务端地址和端口必须与 server.ini 里配置的监听端口一致/group指定终端所属分组这一步决定后续下发哪套策略填错分组会收到完全不该有的关键字规则/silent控制安装完成后不弹“安装成功”对话框。安装完成后先让试点终端的策略状态变为“已连接”再执行全量下发。我的习惯是试点跑一个完整工作日确认没有影响办公、没有误报刷屏再按部门分批次推送。一次推太多终端万一策略有配置问题所有终端同时上报告警管理端会被淹没。卸载权限要分级对待。普通用户不能直接卸载客户端但管理员可以通过输入管理端授权码来卸载同时保留一个应急卸载通道用于终端维修场景。防卸载做得太死一旦客户端和新装的安全软件冲突只能重装系统代价更大。卸载密码或授权码由保密办和信息化部门各持一部分形成互相牵制。3.3 客户端进程保护与离线缓存终端重启、断网都不影响检查客户端在终端上常驻运行服务名为zhihua-agent。它包含一个用户态服务和一个小驱动用户态负责扫描和上报驱动负责防卸载和进程保护。进程保护的意义在于不能让人用任务管理器随手结束掉扫描进程。防卸载能力一般分三层第一层进程保护结束进程会被拒绝第二层服务保护服务被停掉后会自动拉起第三层卸载校验执行卸载时要输入授权码。但要注意第一层和第二层的实现依赖驱动而驱动在不同版本系统上的行为差异很大所以客户端安装完后一定做几台不同系统版本的兼容性验证。离线缓存是涉密场景里非常关键的能力。很多终端在物理隔离网段内不是随时都能连上服务端。客户端扫描产生的告警会先写本地缓存网络恢复后再补报。缓存目录一般放在数据目录下缓存条数达到上限时做滚动清理避免占满磁盘# 查看缓存目录大小确认滚动清理生效 du -sh /var/lib/zhihua-agent/cache # 手动触发一次缓存上报 zhihua-agent-cli flush参数说明cache目录默认容量上限建议设置为 200MB 左右超过后按时间戳从旧到新丢弃并记录丢弃日志防止缓存日志把系统盘写满。flush命令用于网络恢复或排障时手动将缓存补报给服务端正常会自动补报不需要人工干预。心跳间隔默认 60 秒这个参数决定终端在管理端“离线”状态判定的灵敏度。如果网络抖动频繁可以放宽到 120 秒减少掉线误报但也不能放得太宽否则终端真被拔网线后管理端要几分钟才能感知。4. 违规判定与审计闭环分级、白名单、证据留存三件事决定系统是否可信4.1 分级判定把告警分成高中低危别让保密办每天看几百条同级告警检查系统跑起来之后管理端每天会产生大量告警。如果不分级每一条都显示为“违规”保密办很快就麻了。我见过一个单位第一周产生 1300 多条告警全是同级最后根本没人看系统形同虚设。合理的分级规则至少要区分三档高危是“双重命中且文件确实可打开”比如文件名带“机密”、内容又命中多个关键字中危是“文件名带标识但内容命中较少”或“未登记介质接入过涉密终端”低危是“单点命中”或“首次出现的异常外联目标”。分级权重在管理端的判定规则里配置用脚本表达大致如下def judge_risk(scan_result): score 0 if scan_result[name_marked]: score 2 if scan_result[content_hits] 2: score 3 elif scan_result[content_hits] 1: score 1 if scan_result[usb_unregistered]: score 2 if scan_result[outer_link] and scan_result[outer_link_times] 3: score 2 if score 5: return HIGH if score 3: return MID return LOW逻辑说明这里把文件命中和外设、外联行为都统一计分再按总分映射到三档。计分规则应该来自管理端的可配置策略而不是写死在程序里因为不同单位的涉密粒度差异很大。参数说明内容命中 2 个关键字计 3 分是压制误报的关键。很多正常文档会零星出现个别敏感词连续命中两个以上才判定高危能过滤掉大多数文本噪音。usb_unregistered仅在未登记介质接入时计分已登记介质只做记录不告警outer_link_times 3是外联行为的容忍阈值偶尔一次外联可能是误连多次就是主观行为了。分级之后管理端还要支持按等级做不同的处置流程高危自动生成整改工单并催办中危进入周度复核列表低危只存档不打扰。保密办每天看的应该是中高危列表低危留着月底复盘用。4.2 白名单与基线业务系统的关键字日志第一周会把误报刷到让人崩溃系统刚上线那几天告警量高是正常的但其中很大一部分不是真违规而是业务系统产出的正常文件。比如项目管理系统在每天自动生成日志文件名带着“项目”内容里包含“人员名单”“技术方案”这类文件虽然不是涉密文件但会被判定规则命中。这时候就体现出白名单和基线功能的价值。白名单分两层第一层是文件名正则白名单比如“项目管理系统-流水日志-%Y%m%d.log”直接放行第二层是目录白名单比如某个研发服务器的工作目录整目录排除扫描。导入白名单的格式一般是这样的# 白名单规则文件解析后写入管理端 D:\Projects\* # 整目录排除 *项目管理系统*.log # 文件名模式排除 *_debug_*.tmp # 临时文件排除参数说明D:\Projects\*目录通配符会将该目录以及子目录全部排除*项目管理系统*.log是以日志文件名为核心的匹配模式注意这里的通配语义不区分大小写每条规则最好注明添加人和原因方便后面审计时追查。除了白名单基线功能更值得一说。基线是系统自动学习一个部门的文件命名规律和访问行为运行两周左右会生成一份“该部门正常文件和外联目标”的清单。不在基线里的行为才会告警。这个机制能把那些说不清道不明的误报从根源上压下去代价是需要一段学习期学习期内告警量会虚高。4.3 证据留存hash快照、操作日志、前端自证缺一个都没法整改检查系统如果只报“某台终端疑似违规”而没有证据支撑整改环节根本推不动。被检查的同事一句“我没存过这个文件”保密办就得去终端上核对。所以证据留存要提前设计至少包含三部分。第一部分是命中文件本身的证据包括文件路径、文件大小、修改时间以及对文件内容计算出的 hash 值不直接把文件内容拷贝到服务端避免系统自身变成泄密渠道第二部分是终端操作日志记录谁在什么时间登录过终端、是否有拷贝动作第三部分是管理端复核界面上的截图或缩略信息用于快速人工判断。查询一条完整审计记录可以这样看SELECT t.terminal_ip, t.terminal_name, a.alert_level, a.file_path, a.file_hash, a.first_seen, a.last_seen FROM alerts a JOIN terminals t ON a.terminal_id t.id WHERE a.terminal_id 123 AND a.first_seen NOW() - INTERVAL 30 days ORDER BY a.first_seen DESC;逻辑说明这条查询把告警表和终端表关联起来按终端和时间窗口筛选得到一台终端近一个月的完整违规记录。注意file_hash是判定和整改的关键字段同一文件在另一台终端出现时可以通过 hash 直接关联快速判断是不是同一份文件在内部扩散。参数说明时间窗口30 days是按涉密检查的周期习惯设置的季度检查时可以改成90 days。在涉密环境下服务端的数据保留只增不删审计数据至少保留 6 个月以上具体周期按单位保密制度执行。hash 算法建议用 SHA-256文件内容本身不建议明文保存一旦管理端被攻破明文文件会变成新的泄密点。证据留存还有一个容易忽略的细节客户端扫描到违规文件后不要立刻做删除或隔离动作先把证据固定好再执行处置。我见过因为策略配置不当客户端直接隔离文件导致关键证据被“处理”掉的翻车案例。5. 避坑终端保密检查系统上线后最常见的五个坑每个都踩过才会懂5.1 坑一客户端被当作恶意软件隔离全量下发当晚翻车现象客户端全量下发后第二天早上发现大量终端上报“客户端未连接”远程一看客户端进程没了安全软件告警里躺着客户端的可执行文件。原因客户端的行为特征和取证软件很像遍历磁盘、读文件内容、注册系统服务、加载驱动。这些行为被默认规则判为可疑软件直接隔离。解决全量下发前先在一台终端上装好客户端把可执行文件的 hash 和数字签名提交到安全软件的白名单。如果单位里有多个杀毒软件每个都要加白。上线流程改成先试点终端验证白名单生效再按部门分批下发不要一个晚上推完全部终端。这个坑是最常见也最伤士气的一批终端刚下发就掉线后续所有工作都得为解释“这不是病毒”让路。5.2 坑二全盘扫描把终端CPU拉到100%办公体验直接崩现象每天上午 10 点开始办公电脑风扇狂转打开 Word 都要卡几秒。管理端一看扫描任务集中在上午同步触发。原因定时扫描策略默认在上午上班高峰执行扫描线程数配得过高再加上全盘扫描没有排除系统目录大量无意义文件被反复读取。解决扫描时段改到午休或下班时段工作时段只保留增量扫描。扫描线程数从默认值降到 2或者按终端硬件配置分档内存 8G 以上的才允许 4 线程4G 的只跑 1 线程。扫描路径排除 Windows 系统目录和软件安装目录只扫用户目录和常见存储位置。改完这三项CPU 占用能掉到 10% 以下。5.3 坑三密级标识规则太宽全公司一半的文档都成了“疑似涉密”现象全盘扫描完成后告警列表里有几千条“文件名含密级标识”绝大部分是“内部资料”“内部通知”这类行政文件跟涉密完全搭不上边。原因关键字库把“内部”“资料”“会议”这类常见词都当作密级标识判定阈值又只有一个文件名命中就告警导致误报面被放大到整个单位。解决缩窄文件名标识词表只保留明确的密级三要素“机密”“秘密”“绝密”以及在本地保密制度里明确规定的其它标识词。判定规则从“文件名命中即告警”改为“文件名命中 内容命中两个特征才算疑似”。误报率降下来之后再逐步恢复其它标识词但每加一个词都要评估它在业务文件里出现的频率。5.4 坑四防卸载做得太强硬蓝屏和兼容性投诉比违规告警还多现象客户端装上后有几台型号较老的终端频繁蓝屏重启之后客户端日志里有驱动加载失败记录。用户投诉量直接超过了系统的告警量。原因防卸载驱动为了保护自身在系统里嵌入了文件过滤和进程回调。某些终端上的第三方安全软件也做了同样的操作两者冲突导致蓝屏。解决防卸载层级改成可配置。普通终端只开进程保护和服务自拉起不开驱动级文件过滤只有保密重点终端的策略里才打开完整驱动防护。上线前找两三台不同年代、不同系统的终端做兼容性测试发现问题驱动版本回退。如果单位终端型号特别杂建议先去设备台账里拉一个清单按系统版本和硬件年代分区抽样测试。5.5 坑五管理端和终端的时钟不同步审计时间线错乱没法追溯现象排查一次外联事件时发现终端侧记录的接入时间和管理端上报时间差了 20 分钟两边的日志对不上无法确认事件顺序。原因终端休眠后再唤醒系统时钟没有做同步导致扫描和上报记录都带上了错误的时间戳。管理端只存了接收时间没有存终端本地的原始时间。解决在客户端心跳逻辑里加上校时功能每次向服务端上报时携带终端当前时间管理端同时记录终端时间和接收时间审计界面默认按终端时间排序。如果涉密网络内不能使用外部时间源就在服务端部署一个内部 NTP 服务客户端启动和每天定时向它校时。这件事看起来小真要追溯事件的时候时间线对不上所有证据可信度都会被打折扣。6. 用样本终端验证检查覆盖率再用行为基线压住无效告警6.1 小范围验证放三个样本文件就知道检查项有没有生效新环境部署完与其直接全量下发不如先在试点终端上放三个样本文件。第一个文件命名为“年度工作计划-机密.docx”内容里包含两三个敏感关键词这个应该产生高危告警第二个文件命名为“会议通知.docx”内容是“项目代号”加“人员名单”这个应该只产生中危或低危第三个文件是“发布说明.docx”名字和内容都没有敏感词这个完全不应该出现告警。生成样本文件可以直接用脚本代劳再手动确认告警是否按预期上报import os def create_sample(base_dir): samples [ (年度工作计划-机密.docx, 项目代号 技术方案 预算明细\n), (会议通知.docx, 会议安排项目代号与人员名单确认\n), (发布说明.docx, 版本发布说明\n), ] for name, content in samples: with open(os.path.join(base_dir, name), w) as f: f.write(content) create_sample(C:/Users/test/Documents/)逻辑说明三个文件名和内容组合分别对应高危、中危、正常三种预期。扫描结束后管理端如果按预期收到两类告警说明文件检查域、判定阈值、上报链路都正常如果第三个文件也告警说明白名单或判定规则有遗漏。样本验证完成后再把全部检查项的验证样本整理成一个表格存档后续每次调整策略都重新跑一遍这三个样本确保没有改坏原有规则。这个习惯能省下大量排查时间。6.2 进阶技巧外联行为先建立白名单基线再告警告警量能降一半网络检查域最吵的告警来自违规外联。很多终端会定期访问更新服务器、防病毒库地址这些连接本身是正常的。没有基线的情况下第一次外联就会告警每周产生的无效告警能占全部告警的 40% 以上。正确做法是先让外联行为检测跑两周学习期期间只记录不告警两周后把出现频率高的目标地址加入白名单基线之后只对“新出现的外联目标”和“非白名单 IP”告警。后续每个月复盘一次白名单去掉已经失效的地址。外联基线表和文件白名单一样最好标注来源和备注。比如某终端的补丁服务器地址属于正常业务备注写“补丁更新”后续审计时看到告警很快就能判断是否需要豁免。6.3 把系统当审计工具用不当摆设我现在每上线一套检查系统都会先跑样本验证再跑两周基线学习期然后才逐步打开告警和限制策略。这套顺序帮我避开了绝大多数误报投诉和兼容性翻车。系统真正有价值的不是告警数量而是每个告警都查得清、每个整改都闭环希望帮到你。本文还有配套的精品资源点击获取