业务上云之后，加解密在哪里完成、密钥由谁掌管，答案与本地机房时期并不相同。评估云密码服务，与其急着把厂商名单拉出来对比，不如把数据流向与合规要求这两条线索理在前头。这两条理顺了，名单上的候选才具备可比性。
一、先把数据流向画出来
数据在哪里产生、存放在何处、调用加解密的又是哪个环节，画在一张图上，云密码服务的接入点就清楚了。数据留在云端对象存储里，服务就近调用，路径短、时延低，跨地域访问时这一点尤其明显;数据要回传本地处理的，则需要云端与本地设备之间的协同。有些调用在应用内完成，有些依赖平台能力，图上分别标注清楚，后续与各方的沟通才不会各说各话。
二、密钥归属决定控制权
云端加密不等于交出密钥。云密码服务在密钥归属上通常有两种模式：由服务方托管，或由使用方自带、仅在云端受控调用。两者的控制权差别明显，对敏感数据有自主要求的团队，往往倾向于让密钥留在自己掌握的范围之内。自带密钥的模式里，密钥的生成与备份在哪儿完成、日常运维由谁负责，都是要写进方案的细节。能落实到什么程度，各家方案的边界并不一致，这里才是比较的焦点。
三、合规要求逐项核对
行业规范对算法、密钥长度、日志留存各有要求，上云之后同样适用。云密码服务是否具备相应资质、能否支撑密评所需的材料，直接关系到项目能否验收。把合规条目与服务能力一一对照，缺项显性化，后续沟通也更有依据。服务日志能否导出自查，也是核对时的一项。涉及跨境业务的，还要留意数据与密钥的出境边界，这一条容易被忽略，却常常是审核时的重点。
四、迁移与退出路径
用得顺手固然好，也要留后路：密钥如何迁出、加密数据如何带回本地、服务停止之后历史数据还能否读取，这些问题在开始之前就问清楚，日后才有主动权。退出路径答得越痛快，越能看出服务商的准备程度，含糊其辞的环节，往往就是日后容易出问题的地方。合同里把数据可迁移性写成条款，是对自己有效的保护。
安策信息在云密码服务与本地密码设施的协同上有较多实践。上云路径怎么走，可向安策信息索取一份对照检查清单。
业务上云之后，加解密在哪里完成、密钥由谁掌管，答案与本地机房时期并不相同。评估云密码服务，与其急着把厂商名单拉出来对比，不如把数据流向与合规要求这两条线索理在前头。这两条理顺了，名单上的候选才具备可比性。
