通过 VPN 访问合作伙伴的 HSM：界定密钥操作

合作伙伴那边有人要用一把指定密钥签署文件，而请求却以网络问题的形式提出：他们要能到达 HSM。把这句话当作服务合同尚未界定的征兆，而不是路由问题，因为一条能到达设备的隧道本身并不授予任何权限。请求背后有三道门：可达性、HSM 身份和密钥策略，而每一道都由不同的团队在不同的地方管理。把它们逐一写下来，否则你最终会因为证书沟通更难而先批准一条路由。

请记住这个具体场景：合作伙伴只提交一份已批准的文件，用一把指定密钥签署，别的什么都不做。下面的一切都从这一句话推出来。

可达性、身份和密钥策略是三道门

VPN 集中器决定谁可以打开隧道、可以访问哪些地址。HSM 自己决定，提交给它的哪条用户记录可以登录。密钥策略再决定那条用户记录可以用某一把特定密钥做什么。通过第一道门不会改变另外两道门的状态，所以一次成功的握手能证明的东西少得可怜，所以合作伙伴能到达设备，却仍可能在每一项操作上失败。

在写需求之前，先给每道门指定负责人。当第二道门没人负责时，通常的结果是发放一个宽泛的 HSM 管理员身份，因为那是唯一能用的凭据。

第一道门：给合作伙伴的网络路径

写明被批准的客户端或服务、它需要的目标地址，以及该服务监听的协议和端口。然后把 VPN 一侧的访问限制在这对地址和端口上，双向都限，包括回程路径，这样策略就是一句可以读给合作伙伴听的话。网关管理、HSM 管理界面和无关的内部系统应当位于普通合作伙伴访问范围之外，而不仅仅是在默认路由之外。

专用网段让这些跨越变得可见，但网段的名字本身不强制任何东西。流量必须真的经过你以为它经过的那道控制。允许合作伙伴发起连接，也不等于说合作伙伴那边的每台机器都可信。

第二道门：究竟是谁在向 HSM 认证

VPN 身份和 HSM 身份是两个独立对象，除非某种受支持的集成有意把它们合并。使用 PKCS#11 客户端时，应用用存放在合作伙伴主机某处的凭据登录某个槽位，HSM 评估的正是这次登录。

AWS CloudHSM 是一个有用的参照，因为它把两者区分开：HSM 用户不同于 IAM 用户，而用户类型决定账户能做什么。加密管理员管理用户和密钥，但不是执行加密操作的身份；而加密用户可以使用密钥，却不能管理密钥。这种分离正是你希望在别的厂商设备上看到的形态，只是角色名称会不同。

无论你签发什么身份，它都必须能以你日后需要的粒度撤销并归责。在多个合作伙伴之间共用一个运维凭据，恰恰会在两者都最重要的那起事件里让隔离和追责更难。

第三道门：哪把密钥，以及哪项操作

签名、解密、密钥生成、密钥封装和用户管理是彼此独立的权限，必须分别列出。用 PKCS#11 的话说，CKA_SENSITIVE 和 CKA_EXTRACTABLE 这类属性描述密钥材料能否以可用形式离开模块，它们是按密钥设置，而不是按设备设置。要读密钥上实际的策略，而不是从“硬件”这个词或隧道的存在推断不可导出。

然后找到业务审批。如果只有已批准的文件才能签署，那么在请求到达 HSM 之前，由哪个组件确立这项批准？接受授权请求的密码接口并不知道文件是否经过审阅，所以那项检查属于它前面的服务。

被允许的客户端一旦被攻陷，也可以滥用其凭据合法授权的操作，而完全不必导出私钥。因此，保护存储的密钥材料和控制密钥使用是两个验收条件，而不是一个。

拒绝也是验收测试的一部分

接受被允许的签名请求，也接受拒绝：未授权的身份、无关的密钥，以及来自合作伙伴路径的管理操作。记录调用方、操作、密钥标识、时间和结果，并把私钥材料、凭据和文件内容排除在常规诊断日志之外。

为合作伙伴退出、合作伙伴一侧的疑似失陷，以及策略变更和恢复分别指定负责人。改一条路由并不能恢复对一台可能已被攻陷的主机的信任，所以吊销也必须到达 HSM 身份。

一次完成的 VPN 握手属于那份记录。它不能替代哪怕一项针对 HSM 的结果。