云 HSM，密钥控制清晰明确。

私有连接、域名解析、身份认证和延迟，都会影响每一次加密调用。我们会依据真实负载情况测试连接路径，并规划连接中断时的应对方式。只有当密钥和权限在第二个端点同样可用时，该端点才能真正起到备用作用。外部密钥服务或客户自行管理的密钥，在其实际控制的数据和服务范围上也各不相同。我们会清晰记录这些边界，以便业务负责人了解服务商仍然保留的影响力。

退出方案会说明哪些密钥可以导出、哪些数据需要重新加密，以及哪些服务需要被替换，同时还包括期限、删除确认以及对备份的依赖关系。在项目中，我们会商定可实现的运维目标，并检验恢复运行和权限撤销的可行性。若未经过这样的检验，笼统承诺“完全可移植”是站不住脚的。

AWS CloudHSM 和 Azure Key Vault Managed HSM 代表着不同的集成与运维模式。AWS CloudHSM 为适合的应用提供 HSM 客户端对接；Azure Managed HSM 则提供与 Azure 集成的托管密钥服务。我们会针对每种工作负载检查其 API、密钥类型、身份和恢复模型。因此，更换服务并不只是替换一个服务器地址那么简单。关键在于具体应用和所需的控制范围是否与该服务相匹配。

Bring Your Own Key（自带密钥）首先指的是将自有密钥材料导入受支持的服务。它本身并不能说明谁可以发起密钥操作，或明文数据在何处被处理。采用外部密钥管理时，还会产生额外的技术依赖，例如某个外部服务负责特定的密钥释放或解封装操作。我们会记录这些信任边界，并测试有针对性的权限撤销。功能和限制会针对具体的云服务逐一核实。

一个现有应用需要迁移，但其密钥运维必须保持可控。OTOKO® 首先会检查现有接口能否继续使用，或是否需要调整。在试点阶段，我们会测量来自目标网络的响应时间，检查管理员角色的分离情况，并验证恢复流程。退出方案既会说明哪些密钥可以导出，也会说明哪些情况下需要重新生成密钥并进行数据转换。由此形成一套责任明确的运维模式。