白名单的执行逻辑
应用白名单在系统层面拦截程序启动请求，只放行已授权条目。授权依据可以是文件路径、文件哈希或数字签名：路径授权最省事但可被同名文件替换，哈希授权能防替换但升级后需要重新授权，签名授权维护成本最低但要求软件本身有可信签名。落地路径是先在目标主机上以学习模式运行一段时间，收集实际执行的程序与加载的模块，再人工评审这份清单，去掉不该授权的条目后切换到执行模式。之后每次软件升级、补丁实施或新增工具，都需要回到清单维护环节。
基本信息
| 授权依据 | 路径（最弱）、哈希（防替换、升级需重授权）、数字签名（维护省但依赖软件签名） |
|---|---|
| 运行模式 | 学习模式采集、执行模式拦截、部分产品支持混合与告警模式 |
| 常见遗漏项 | 计划任务、脚本解释器、动态库、驱动、更新程序、组态软件的插件模块 |
| 维护触发 | 组态软件升级、补丁实施、新增调试工具、更换控制器型号 |
| 与防病毒的关系 | 白名单限制「能跑什么」，特征检测判断「跑的东西是否恶意」，两者互补 |
| 兼容性前提 | 老旧系统可能不支持，需评估替代控制，支持范围以厂商文档为准 |
落地步骤
- 确认支持性：核对操作系统版本与内核要求，确认该主机能否部署白名单并长期维护
- 确认现场干净：学习前确认主机未处于异常状态，避免把可疑程序学入清单
- 学习期采集：覆盖完整业务周期，包括日常操作、班次切换、月度任务与软件自身更新
- 人工评审清单：逐条确认来源与用途，重点审查通用解释器与命令行工具
- 执行模式上线：先以告警模式观察一段时间，再切到拦截模式，保留快速回退手段
- 持续维护：把软件升级与新增工具纳入变更流程，升级前确认清单同步更新
授权依据对照
| 授权依据 | 防护强度 | 维护代价 |
|---|---|---|
| 文件路径 | 弱，同名文件可替换 | 最低，软件移动或升级后易失效或误放 |
| 文件哈希 | 中高，文件改动即失效 | 较高，每次升级都需重新授权 |
| 数字签名 | 高，可校验发布方 | 较低，但依赖软件具备可信签名 |
| 综合策略 | 高，按程序重要性选择依据 | 最高，需要分类管理与复核 |
如果白名单授权了通用脚本解释器或系统自带命令行工具，等于开放了执行任意逻辑的能力，白名单的防护意义会大幅下降。这类条目必须单独评估：能否改为只授权具体脚本与脚本所在目录，能否限制脚本的写入权限。