【零信任安全架构】设备姿态与远程证明：TPM、osquery 和信任分数

零信任架构中的”持续验证”要求系统在每一次访问决策时评估设备的当前安全状态——不只是”登录时是否打了补丁”，而是”此刻这个设备是否仍然符合安全基线”。这个评估依赖两种信号源：硬件级可信测量（TPM 2.0 远程证明）和操作系统级信号采集（osquery / MDM / EDR）。

前置阅读：NIST SP 800-207 架构拆解。

一、TPM 2.0：设备身份的硬件信任根

1.1 TPM 不是什么

TPM（Trusted Platform Module）经常被误解为一个”安全芯片”——实际上它是一个嵌入式的密码协处理器，提供了一组有限的、经过硬件保证的命令：

• 生成密钥对（但私钥永远不离开 TPM）
• 签名数据（用 TPM 内的密钥）
• 哈希和扩展 PCR
• 加密和解密（用 TPM 内的密钥）

TPM 不能做的事：它不主动检查任何东西。TPM 不会告诉你”BIOS 被篡改了”——它只提供 PCR 的值的加密证明，是否被篡改由验证者（Verifier）决定。

1.2 PCR：系统的加密指纹

PCR（Platform Configuration Register，平台配置寄存器）是 TPM 的核心数据结构。TPM 2.0 有 24 个 PCR，每个是一个 256 位的哈希值。

PCR 的特殊操作是 extend——不是直接写入值，而是累积哈希：

\[PCR_{new} = \text{SHA256}(PCR_{old} \parallel \text{new\_measurement})\]

因为是单向哈希，PCR 的值无法回退。一个 PCR 最终的哈希值依赖于所有顺序排列的扩展操作——任何一步不同，最终值一定不同。

PC Client 平台的典型 PCR 分配（TCG PC Client PTP 规范）：

PCR 0-7 由固件在启动过程中依次扩展。任何引导链中的篡改——修改 BIOS、替换启动管理器、注入恶意内核模块——都会导致 PCR 值与已知的良好值不同。

1.3 启动度量链（Measured Boot）

从系统上电开始的完整测量链：

sequenceDiagram
    participant CRTM as CRTM<br/>(不可变 ROM)
    participant BIOS as BIOS/UEFI
    participant BL as Bootloader<br/>(GRUB/systemd-boot)
    participant OS as OS Kernel
    participant PCR as TPM PCR 0-7

    CRTM->>PCR: Extend PCR 0 (BIOS code)
    CRTM->>BIOS: 跳转到 BIOS
    BIOS->>PCR: Extend PCR 1-7 (配置、ROM、Secure Boot)
    BIOS->>BL: 验证并启动 Bootloader
    BL->>PCR: Extend PCR 8 (kernel + cmdline)
    BL->>OS: 验证并启动内核
    OS->>PCR: Extend PCR 9 (initrd)

1.4 AIK 与 Quote：远程证明的核心

AIK（Attestation Identity Key）是 TPM 内部生成的非对称密钥，专门用于远程证明。关键属性：

• 私钥不离开 TPM——永远无法导出
• 受限签名密钥：只能签名 TPM 自己生成的数据结构（TPMS_ATTEST），不能签名任意外部数据。这是硬件保证的。
• AIK 本身不证明 TPM 的真实性——它需要一个证书链。AIK 的证书由 Privacy CA 签发，而 Privacy CA 必须先验证该 TPM 的 EK（Endorsement Key）证书（由 TPM 厂商签发）

Quote 是远程证明的产物——TPM 对选定 PCR 集合的当前值做签名证明：

Verifier → 生成随机 nonce + 选择 PCR [0,4,7] → 设备
设备 → TPM2_Quote(AIK_handle, nonce, PCR_selection) → 已签名的 Quote
设备 → Quote + PCR 值 + Event Log → Verifier
Verifier → 用 AIK 公钥验证签名 + 比对 PCR 值 + 重放 Event Log

Quote 的验证步骤： 1. 验证 AIK 证书链 → 确认 AIK 确实在一个真实 TPM 内部 2. 用 AIK 公钥验证 Quote 签名 3. 确认 extraData 中包含原始 nonce → 防重放 4. 重放 Event Log → 从第一步到最新一步逐条计算 PCR 期望值 → 比对实际 PCR 值 5. 将 PCR 值中的各组件测量值与已知的良好白名单比对 → 确认没有恶意软件

如果这五步全部通过，验证者可以确信：这台设备从启动开始，运行的每一行代码都是未篡改的。

二、操作系统级信号采集：osquery

TPM 远程证明回答的是”启动过程是否可信”，但很多安全信号在运行时才能获取——硬盘是否加密、哪些进程在运行、防火墙是否开启。这就是 osquery 的领域。

osquery 是一个开源的端点检测工具（最初由 Facebook 开发，现由 Linux Foundation 托管），它把操作系统状态抽象为 SQL 表：

-- 磁盘加密状态
SELECT name, encrypted FROM disk_encryption;
-- macOS: FileVault 状态
-- Linux: dm-crypt/LUKS 状态
-- Windows: BitLocker 状态

-- 已安装的补丁
SELECT name, version, install_date FROM patches;
-- Windows: 从 Windows Update 获取
-- macOS: 从 softwareupdate 获取
-- Linux: 从各包管理器获取

-- 正在监听的端口
SELECT pid, port, address FROM listening_ports;

-- 启动项
SELECT name, path, source FROM startup_items;

-- USB 设备历史
SELECT model, serial, vendor FROM usb_devices;

osquery 本身只是一个查询引擎——它不决定哪些信号重要、什么值算合规。这些判断在它的上层：设备管理平台（如 Fleet DM、Kolide、osctrl）和信任评估引擎。

2.1 不同操作系统的信号不对等

osquery 可以直接暴露”操作系统的安全状态”，但这个安全状态的测量方式在不同平台上完全不同：

工程坑点：信任引擎必须理解这些信号在每种平台上的含义不同。例如，“磁盘加密已启用”在 macOS 上意味着 FileVault 开启且恢复密钥已 escrow——而在 Linux 上可能只意味着根分区使用了 LUKS，但 /home 分区没有。一个跨平台的信任分数系统需要为每个平台的每个信号定义独立的条件逻辑。

2.2 信号采集的运维现实

在大规模设备机群中，信号采集本身是第一个瓶颈：

• 单机采集频率：如果 osquery 每 5 分钟向集中式服务器推送一次完整的设备状态，10000 台设备的写入压力是每秒 333 次状态更新。
• 状态不一致窗口：补丁在 10:00 打上，下次 osquery 查询在 10:05 运行——这 5 分钟的窗口内，设备可能被”旧状态”拒绝访问。
• 设备离线：工程师合上笔记本后，设备在公司的设备姿态系统中显示为”最后在线 3 小时前”——在这 3 小时内，设备的安全状态完全黑盒。

三、信任分数模型

3.1 简单加权和模型的优缺点

最直接的信任分数计算：

\[S = \sum_{i=1}^{n} w_i \cdot s_i\]

其中 \(s_i\) 是每个信号维度的评分（0-100），\(w_i\) 是该维度的权重。权重通常由安全团队根据组织的风险偏好确定。

但这有根本性的问题：分数的可解释性差。一台最终信任分数为 75 的设备，可能是因为磁盘加密正常（满分 20）、操作系统补丁落后一期（扣了部分分）、防火墙正常（满分 15）、防病毒过期 1 天（扣了 15 分）——或者任何其他组合得出了 75。策略引擎只能看到 “信任分数 = 75”，看不到”什么导致了这个分数”。

一个改进是输出分数 + 降级原因的组合：

{
  "device_id": "macbook-pro-abc123",
  "trust_score": 75,
  "trust_tier": "basic",
  "downgrade_reasons": [
    "os_patches: macOS 14.3 behind latest (14.4)",
    "antivirus: definitions 12 hours old"
  ]
}

这样策略引擎可以做更精细的判断：“因为补丁落后而分数不足的设备，允许访问 Internal Wiki——但因为杀毒软件未运行的设备，即使是 Internal Wiki 也禁止。”

3.2 Google BeyondCorp 的三级模型

Google BeyondCorp 使用的是等级模型，不是分数模型——设备被分配到 Unprivileged / Basic / Privileged（即 Untrusted / Basic / Trusted）三个等级之一。每个等级对应一组明确的准入条件。

Trusted:
  - 企业配发的设备
  - TPM 远程证明通过
  - 全盘加密启用
  - 所有安全补丁在 SL A 内
  - 安全软件运行中且更新
  → 可访问所有企业资源

Basic:
  - 设备被识别但部分信号缺失
  - 或补丁稍落后
  - 或杀毒软件定义过期
  → 可访问低敏感资源（Wiki、HR 系统、邮件）

Untrusted:
  - 未知设备
  - 或严重不合规
  - 或未注册
  → 拒绝所有企业资源访问

等级模型牺牲了细粒度（无法区分”补丁落后 1 天”和”补丁落后 1 周”），但换来了可操作性和可解释性——当用户被拒绝访问时，系统可以给出明确的说明（“你的设备是 Basic 等级，需要 Trusted 等级才能访问此资源——原因是 macOS 补丁已落后 7 天以上”）。

3.3 分数衰减

设备信任分数不是静态的——它会随时间衰减。一台在上午 10:00 检查时完全合规的设备，到下午 14:00 如果还没有重新检查，信任分数应该降低：

\[S(t) = S(t_0) \cdot e^{-\lambda (t - t_0)}\]

其中 \(\lambda\) 是衰减速率——取决于信号的敏感程度。补丁检查的衰减速率较慢（几天），杀毒软件更新的衰减速率较快（几小时），防火墙状态的衰减速率最快（可能随时变化）。

衰减模型的服务端实现不需要为每台设备持续计算——而是当设备发起访问时，根据”上次检查时间”和”当前时间”的差值计算衰减后的分数。这样避免了持续计算的 CPU 浪费。

四、运维陷阱

4.1 macOS 的 Secure Enclave vs Linux 的 firmware TPM

macOS 设备有 Apple T2 芯片或 M1/M2/M3 的 Secure Enclave（功能上等同于一个固件 TPM 2.0），而且 Apple 全面控制硬件和 OS。Windows 设备有 Intel PTT 或 AMD fTPM（固件 TPM 2.0），且 BitLocker 与 TPM 紧密集成。但 Linux 设备的情况参差不齐：

• 大多数 Linux 笔记本使用 Intel PTT / AMD fTPM（固件 TPM）——但 Linux 发行版的默认安装不一定配置了测量启动
• 服务器级 Linux 可能配有硬件 TPM 2.0 芯片——但如果是虚拟化环境，vTPM 的信任模型完全不同（vTPM 的 PCR 可以由 hypervisor 回退）
• 自定义 Linux 发行版（如嵌入式）可能根本没有 TPM

结论：零信任设备姿态不能对 Linux 设备施加与 macOS 相同的 TPM 要求。对于没有 TPM 或者 TPM 不受信任的 Linux 设备，设备姿态只能依赖操作系统级信号（osquery）——这是安全上的降级，但工程上不可避免。

4.2 BYOD 的边界

Bring Your Own Device（BYOD）是设备姿态系统最薄弱的环节：个人设备没有 MDM 管理，TPM 远程证明无法强制要求（个人设备的所有者不会让公司 IT 部门控制其 TPM 的 AIK 证书），且安装公司安全软件是自愿的而非强制的。

当前实践的分界线： - 高安全组织（金融、国防、政府）：BYOD 完全禁止，只允许公司配发设备。 - 中等安全组织：BYOD 允许但只能访问低敏感资源（邮件、Wiki、HR），不能访问代码仓库、数据库、生产环境。身份层面强制 MFA。 - 低安全组织：BYOD 和公司设备分开策略，但统一身份认证。

4.3 设备姿态信号的信任根

一个深层的安全问题：设备姿态信号本身可能被伪造。 如果攻击者控制了设备（通过恶意软件），他可以： - 伪造 osquery 返回的数据（拦截 osquery 的 API 调用） - 生成假的 TPM Quote（如果攻击者知道 AIK 的公钥并在软件中模拟签名——不过受限签名密钥机制会阻止”任意内容签名”，但 PCR 值本身的验证需要正确的 Event Log）

防御措施：设备姿态信号应该多层次交叉验证——TPM Quote 提供硬件级的验证（确保启动链未被篡改），osquery 提供运行时信号，EDR 提供行为分析。三者之间的一致性检查可以提高攻击者伪造姿态的难度。

下一篇：持续验证 vs 一次性认证。

参考资料

1. Trusted Computing Group. TPM 2.0 Library Specification, Parts 1-4.
2. Trusted Computing Group. TCG PC Client Platform TPM Profile (PTP) Specification.
3. Arthur, W., Challener, D., & Goldman, K. (2014). A Practical Guide to TPM 2.0. Apress.
4. osquery. GitHub Repository. https://github.com/osquery/osquery
5. Google. Santa (macOS security software). https://github.com/google/santa
6. Fleet DM. Open-source Device Management. https://fleetdm.com