HSM 用户与角色管理

上一期我们聊了 HSM 密钥的生命周期，这次轮到一个更容易被忽略、但翻车频率极高的环节——用户与角色。说白了，HSM 不是一把锁，而是一个有多个权限房间的保险库。谁有钥匙开哪扇门，必须严格定义。

我个人习惯先把角色分成三大类：管理员、Crypto Officer、Crypto User。很多新手以为“管理员就是最高权限”，其实在 HSM 里，管理员和 Crypto Officer 是平级的，只是分工不同。我见过一次项目，因为把管理员当万能角色用，结果密钥导出权限被误开，差点出事。

角色定义：谁该干什么

先看每个角色的核心职责：

• HSM 管理员 (Security Officer / SO) — 负责 HSM 的初始化、网络配置、固件升级、审计日志管理等基础运维。不能碰任何密钥。
• Crypto Officer (CO) — 管理密钥生命周期：生成、导入、导出、删除、备份。负责制定密钥策略，但不能直接使用密钥做加解密。
• Crypto User (CU) — 只能使用已经存在的密钥进行签名、加密、解密等密码操作。不能管理密钥，不能改变策略。

你想想看，这有点像公司里的三个职位：SO 是行政主管（管门禁卡、监控、设备），CO 是仓库管理员（管货物进出记录），CU 是普通员工（只能领货用，不能自己进货）。三个角色各司其职，缺一不可。

权限划分：边界在哪里

我整理了一份常见的权限矩阵，直接看表格更清晰：

操作 / 角色	SO	CO	CU
HSM 初始化/恢复出厂	✓	✗	✗
网络参数配置	✓	✗	✗
审计日志导出	✓	✗	✗
生成密钥对	✗	✓	✗
导入/导出密钥	✗	✓	✗
删除密钥	✗	✓	✗
设置密钥使用策略	✗	✓	✗
使用密钥加密/解密	✗	✗	✓
使用密钥签名/验签	✗	✗	✓

这里面有个坑：SO 不能操作密钥，CO 不能直接用密钥。我记得有一次做等保测评，对方 HSM 的 SO 和 CO 被配成了同一个人，整个三权分立直接废掉。审计不过关，只能重新初始化。

配置方法：实操演示

下面我用一个常见的 HSM 命令行工具（以 Thales Luna 为例）演示配置过程。不同厂商命令有差异，但逻辑一样。

第一步：初始化时创建 SO 和 CO 的访问口令。

# 初始化 HSM，设置 SO 口令
hsm init -so-password "S0!StrongPass123"

# 创建 CO 用户（角色为 Crypto Officer）
user create -name "co_admin" -role CO -password "CO!Pass456"

第二步：分配 CU 用户。

# 创建 CU 用户
user create -name "app_server" -role CU -password "CU!App789"

第三步：CO 创建密钥并授权给 CU。

# 以 CO 身份登录，生成 RSA 2048 密钥对
login -name "co_admin"
key generate -algorithm RSA -size 2048 -label "signing_key_01"

# 将密钥的使用权授予 CU 角色
key assign -label "signing_key_01" -role CU -permission sign

第四步：用 CU 身份签名验证。

# 切换到 CU 登录
login -name "app_server"
sign -hash SHA256 -key "signing_key_01" -in data.txt -out data.sig

# CU 无法删除该密钥（会报错）
key delete -label "signing_key_01"   # 权限拒绝

嗯，这里要注意：CU 虽然能使用密钥，但任何管理操作都会被拒绝。你可以在生产环境里把 CU 的密码交给应用服务器，即使服务器被攻破，攻击者也只能用密钥，拿不走也删不掉。

避坑指南

# 查看某个密钥的访问控制列表
key listAcl -label "signing_key_01"

角色关系知识图

下面这张图把三个角色、权限方向和关键操作串了起来，方便你形成整体认知：