终端环境感知与合规检查：终端健康检查
设备能不能接入网络，不是看它“是谁”，而是看它“现在是什么状态”。
这句话我反复跟团队强调过。零信任里没有“永久信任”这回事。一台笔记本，昨天还合规，今天可能就被植入了恶意软件。所以，终端环境感知和合规检查，就是设备接入前的“体检”。
说白了，我们要回答三个问题：
- 系统本身健康吗？（OS版本、补丁、杀毒软件）
- 关键文件被篡改了吗？（进程与文件完整性）
- 启动过程可信吗？（基于TEE/TPM的可信启动）
核心逻辑： 终端健康检查不是一次性动作，而是持续评估。设备接入前检查一次，接入后还要定期复查。一旦发现违规，立即触发隔离或修复流程。
4.1 系统健康基线：OS版本、补丁与杀毒软件
这是最基础的检查项。我见过不少团队，花大价钱买了零信任平台，结果连“Windows 7 是否还在运行”这种问题都没管住。
4.1.1 OS版本与补丁检查
检查点其实很明确：
- OS版本： 是否在支持周期内？比如Windows 10 21H2 已经停止支持，就不该允许接入。
- 补丁级别： 至少最近一个月的安全更新是否已安装？
- 关键补丁： 针对已公开漏洞的紧急补丁，必须强制安装。
我在项目中遇到过一件事：某客户内网爆发勒索病毒，溯源发现是一台未打补丁的Windows Server 2012 被攻破，然后横向移动。事后检查，那台机器已经半年没更新了。嗯，从那以后，我把补丁检查的“硬性阻断”策略写进了所有方案里。
我的习惯： 补丁检查不要只看“是否安装”，还要看“安装时间”。有些设备虽然装了补丁，但装完没重启，补丁根本没生效。这种情况要标记为“待重启”，不允许接入。
4.1.2 杀毒软件与EDR状态
杀毒软件（AV）和端点检测与响应（EDR）是终端安全的最后一道防线。检查内容包括：
- 是否安装： 指定的AV/EDR产品是否在运行？
- 是否启用： 实时防护是否开启？
- 病毒库版本： 是否在有效期内？
- 最近扫描时间： 是否在规定时间内完成过全盘扫描？
| 检查项 | 合规标准 | 违规处理 |
|---|---|---|
| AV安装状态 | 已安装指定产品 | 阻断接入，提示安装 |
| 实时防护 | 已启用 | 阻断接入，提示开启 |
| 病毒库版本 | 不超过7天 | 允许接入，但触发修复流程 |
| 全盘扫描 | 30天内完成 | 允许接入，但触发扫描任务 |
你想想看，如果一台设备的杀毒软件都过期了，它凭什么能访问核心业务系统？零信任的逻辑就是：不满足条件，就不给权限。
4.2 进程与文件完整性校验
系统健康检查只是第一步。更精细的检查，要看设备上正在跑什么进程，关键文件有没有被篡改。
4.2.1 进程白名单与黑名单
我建议的做法是：
- 白名单： 只允许运行经过批准的进程。比如办公设备只能跑Office、浏览器、VPN客户端等。
- 黑名单： 禁止运行已知恶意进程或高危工具。比如Mimikatz、破解工具、远程控制软件等。
曾经有个案例：某员工电脑上跑着一个“合法”的远程桌面软件，但那是他私自安装的。结果这台电脑被外部攻击者利用，通过远程桌面跳板进入了内网。所以，进程白名单一定要严格执行。
注意： 进程检查不能只看进程名。恶意软件经常伪装成系统进程名。要结合进程路径、数字签名、哈希值综合判断。
4.2.2 文件完整性校验
文件完整性校验，说白了就是检查关键文件有没有被改过。常用的方法有：
- 哈希比对： 对系统关键文件（如lsass.exe、kernel32.dll）计算SHA-256哈希，与已知的“干净”哈希比对。
- 数字签名验证： 检查文件的数字签名是否有效，是否被篡改。
- 文件属性检查： 检查文件大小、修改时间、创建时间是否异常。
我在项目中遇到过一种情况：攻击者替换了系统的“notepad.exe”，植入了一个后门。因为文件名没变，普通检查根本发现不了。后来我们加了哈希校验，才揪出来。
# 示例：使用PowerShell计算文件哈希
Get-FileHash -Path "C:\Windows\System32\notepad.exe" -Algorithm SHA256
# 输出示例
Algorithm Hash Path
--------- ---- ----
SHA256 A1B2C3D4E5F6... C:\Windows\System32\notepad.exe
我的习惯： 文件完整性校验要定期做，但不能太频繁。我一般建议每天一次，或者每次设备接入时做一次。太频繁会影响性能，尤其是对老旧设备。
4.3 基于TEE/TPM的可信启动验证
这是终端健康检查里最硬核的部分。为什么需要可信启动？因为如果设备在启动阶段就被攻破了，后面的所有检查都是白费。
4.3.1 什么是可信启动？
可信启动（Trusted Boot）的核心思想是：从硬件到操作系统，每一级启动组件都要验证下一级的完整性。
具体流程是这样的：
- BIOS/UEFI： 首先验证自身完整性，然后验证引导加载程序（Bootloader）。
- Bootloader： 验证操作系统内核的签名和哈希。
- 操作系统内核： 验证系统关键驱动和服务的完整性。
- 应用层： 验证关键应用程序的完整性。
如果任何一级验证失败，启动过程就会中断，或者设备被标记为“不可信”。
4.3.2 TPM与TEE的角色
TPM（可信平台模块）和TEE（可信执行环境）是可信启动的硬件基础。
| 组件 | 作用 | 典型应用 |
|---|---|---|
| TPM | 提供硬件级别的密钥存储、哈希计算、平台度量 | 存储PCR值、生成签名密钥、验证启动链 |
| TEE | 提供隔离的执行环境，保护敏感计算 | 运行可信应用、处理密钥、执行远程证明 |
TPM里有一组“平台配置寄存器”（PCR），用来记录启动过程中每个组件的哈希值。启动完成后，这些PCR值就是设备的“指纹”。
我记得有一次，客户问：“如果攻击者物理接触设备，替换了TPM芯片怎么办？” 嗯，这个问题问得好。TPM芯片是焊死在主板上的，替换成本极高。而且，即使替换了，PCR值也会变，远程证明时就能发现异常。
4.3.3 远程证明（Remote Attestation）
可信启动的最终目的，是让远程的零信任控制平台能够验证设备的启动状态。这个过程叫“远程证明”。
流程大致如下：
- 设备启动，TPM记录PCR值。
- 设备向零信任控制平台发起接入请求，同时提交PCR值。
- 控制平台验证PCR值是否与预期一致。
- 如果一致，允许接入；否则，拒绝或隔离。
关键点： 远程证明必须基于硬件信任根。如果PCR值是通过软件模拟的，那攻击者完全可以伪造。所以，一定要用TPM或TEE提供的硬件级证明能力。
4.4 知识体系总览
下面这张图，把终端健康检查的三大模块串起来了。你可以看到，从系统基线到文件校验，再到可信启动，层层递进，最终形成完整的设备信任评估。
4.5 落地建议与避坑指南
讲了这么多，最后分享几个我在实际项目中踩过的坑：
- 不要只检查不修复： 有些团队部署了终端健康检查，发现违规设备只是记录日志，不采取行动。这等于没做。一定要有自动化的修复流程，比如触发补丁安装、强制开启杀毒软件。
- 注意性能影响： 文件完整性校验和进程检查会消耗CPU和内存。尤其是对老旧设备，要控制检查频率和范围。我一般建议对关键文件做全量检查，对非关键文件做抽样检查。
- TPM不是万能的： 虽然TPM提供了硬件信任根，但远程证明的通信过程本身也要保护。如果证明请求被中间人篡改，结果就不可信了。所以，一定要用TLS加密证明通道。
- 兼容性问题： 不是所有设备都支持TPM 2.0。对于老旧设备，可以考虑用软件模拟的信任根，但风险要明确告知业务方。
我曾经踩过的坑： 有一次，我们部署了严格的进程白名单，结果把业务系统的一个合法后台服务给误杀了。原因是那个服务在安装时注册的进程名和我们白名单里的不一致。从那以后，我要求所有白名单必须经过业务方确认，并且要有灰度上线流程。
终端健康检查，说白了就是“先查后放”。查得越细，放得越放心。但也要注意平衡安全与效率，别让检查变成业务瓶颈。