📚 课程目录第4章设备身份模型设计

4. 设备身份模型设计

在mTLS设备安全接入工程中，证书不是一张“通行证”那么简单，它承载的是设备的完整身份模型。如果身份模型设计得含糊，后续的准入策略、权限分级、吊销追溯都会变得脆弱。本节围绕五个相互咬合的要素展开：设备唯一标识、证书主题字段、SAN扩展、设备类型分级，以及身份生命周期。它们共同决定了一个设备“是谁、能做什么、何时失效、如何被追溯”。

一、设备唯一标识：身份的根

设备唯一标识是整个身份模型的锚点。它必须满足三个条件：全局唯一、不可篡改、可被CA在签发时验证。工程上常见的候选包括硬件序列号、芯片UID、TPM/EK公钥哈希、MAC地址等。MAC地址可被软件修改，不适合作为强身份根；硬件序列号在批量设备中可能重复或缺失；相对可靠的是芯片唯一ID或安全芯片内的密钥对公钥指纹。

推荐做法是：以设备安全芯片内生成的密钥对公钥哈希（如SHA-256）作为唯一标识，记为 deviceId。该值在设备出厂或首次激活时由设备自身生成，私钥永不出芯片，CA仅对公钥及其哈希进行签发。这样，标识与私钥天然绑定，无法被复制到另一台设备上冒用。

二、证书主题字段：可读身份与结构化属性

X.509证书的Subject字段是设备身份的可读表达。对于设备证书，不建议照搬人员证书的CN=姓名、O=公司结构，而应设计为面向设备管理的结构化字段。一个可用的示例：

Subject:
  CN  = DEV-7F3A9C21          # 设备短标识，便于日志检索
  O   = ExampleIoT            # 组织
  OU  = Factory-A/Line-3      # 产线或部署单元
  C   = CN
  serialNumber = SN-2024-000871   # 硬件序列号，用于资产对账

其中CN建议使用与deviceId关联的短标识，而不是直接放完整哈希，便于人工识别；serialNumber用于与资产系统对账；OU表达部署位置或业务单元，便于策略按组织维度下发。需要注意，Subject字段在证书签发后不可更改，因此它适合承载“出厂即确定”的属性，不适合承载会频繁变化的运行状态。

三、SAN扩展：机器可读的身份入口

现代TLS栈在验证证书时，越来越依赖SAN（Subject Alternative Name）而非CN。对于设备证书，SAN应至少包含两类条目：一类是设备唯一标识，另一类是设备类型或角色标识。例如：

X509v3 Subject Alternative Name:
  DNS:dev-7f3a9c21.fleet.example.com
  URI:urn:example:device:7f3a9c21
  otherName:1.3.6.1.4.1.99999.1;UTF8:type=sensor;class=B

DNS条目用于服务端按域名规则做校验；URI条目承载全局唯一URN，便于策略引擎直接提取deviceId；otherName可携带设备类型、分级等自定义属性。SAN是机器可读的，Subject是给人看的，两者应保持语义一致但用途分离。设计时要避免把可变属性（如IP、在线状态）写入SAN，否则每次变化都要重签证书。

四、设备类型分级：从身份到权限的映射

设备类型分级决定了同一套mTLS体系下不同设备的权限边界。分级维度通常包括：安全能力（是否有安全芯片）、数据敏感度、网络位置、可控程度。一个实用的四级模型如下：

级别	典型设备	证书策略	准入权限
A级	安全芯片网关、核心采集器	硬件密钥、短有效期、强制吊销检查	可访问核心数据面
B级	工业传感器、边缘控制器	硬件或软密钥、中等有效期	仅访问所属业务域
C级	普通终端、辅助设备	软密钥、较短有效期	受限只读或上报
D级	临时调试设备	一次性证书、极短有效期	仅调试通道，到期即失效

分级信息应写入证书的扩展字段或SAN的otherName中，由策略引擎在TLS握手后读取并映射为访问控制决策。这样，权限不再依赖外部数据库的实时查询，而是随证书本身携带，降低策略服务的耦合度。

五、身份生命周期：从出生到注销

设备身份不是静态的，它有一条完整的生命周期：注册→签发→激活→轮换→吊销→归档。每个阶段都有明确的触发条件和状态迁移。

注册：设备首次接入或产线初始化时，向注册服务提交deviceId和CSR，注册服务验证设备来源后批准。
签发：CA根据设备分级签发对应策略的证书，写入Subject、SAN和扩展字段。
激活：设备加载证书和私钥，完成首次mTLS握手，身份正式生效。
轮换：在证书到期前，设备用旧证书建立受信通道，提交新CSR，CA签发新证书，实现无缝切换。
吊销：设备丢失、退役或私钥泄露时，CA将序列号写入CRL或OCSP，服务端在握手时拒绝。
归档：吊销后的证书和审计记录保留，用于追溯和合规审计。

轮换窗口建议设置为证书有效期的1/3。例如有效期90天，则在到期前30天启动轮换，留出重试和故障处理时间。

六、身份模型落地时的关键判断

设计完成后，可以用几个问题检验模型是否可用：设备唯一标识是否与私钥绑定、能否防止复制冒用？Subject和SAN是否分工清晰、语义一致？分级信息是否随证书携带、策略引擎能否直接读取？生命周期各阶段是否有明确的触发条件和状态记录？如果这些问题都有确定答案，身份模型就具备了工程可实施性。

上图把五个要素放在同一张结构图中：唯一标识是根，证书主题字段和SAN扩展是两种表达方式，类型分级把身份映射为权限，生命周期则管理身份从产生到消亡的全过程。实际工程中，这五个要素需要在CA策略、注册流程和策略引擎三处保持一致，任何一处脱节都会导致身份模型失效。

不要把可变属性（如IP地址、在线状态、固件版本）写入证书的Subject或SAN。证书一旦签发即不可更改，可变属性应通过设备上报或策略服务动态获取。

最后需要强调，设备身份模型不是一次性设计，而是随设备规模、安全要求和合规要求演进的。建议在项目初期就确定deviceId的生成规则、SAN的命名规范、分级字段的编码方式，以及生命周期各阶段的触发条件，并以文档形式固化。这样，后续增加设备类型、调整权限策略或接入新的CA时，才不会因为身份模型不一致而返工。