文/中国银联智能化创新中心 江波 周睿奇 徐湧
近年来,金融机构依托数字化手段优化业务流程、创新金融产品与服务,极大提升了运营效率与客户体验。然而,随着海量敏感数据在不同系统间的频繁流转,数据泄露事件频发,不仅可能引发客户信任危机和监管处罚,还可能影响金融机构的声誉与市场竞争力,甚至冲击金融市场稳定。为此,中国人民银行等监管机构多次对数据安全提出明确要求,包括在公网传输时加密传输、存储时加密存储等,其中《金融数据安全 数据生命周期安全规范》中明确“三级数据存储应采取加密等技术措施保证数据存储保密性,四级及以上数据应采取密码算法加密存储”,并在《金融数据安全 数据安全分级指南》中明确分级,见表1。
表1 金融数据安全分级
账户密码等用户鉴别信息所属的四级数据在数据流转全链路已有一套成熟的安全管控体系。本文重点针对以用户姓名、手机号、身份证号为代表的三级数据进行研究;二级数据虽然没有数据存储保密性要求,也可根据需要参考本文的技术方案。
《金融数据安全 数据生命周期安全规范》针对三级数据的存储保密性问题,各金融机构都开展了大量研究实践,主要解决方案如下。
常见方案是实现单个系统的数据存储加密。该方案的主要特征:系统加工处理过程中采用明文,在展示环节对敏感数据的部分内容进行掩码处理(例如手机号中间4位用*代替,姓名中的部分字用*代替),在数据存储环节完成加密。在具体实现加密的方法上,有应用层、数据库代理层、数据层等实现方式。
改进方案中,改进方案1(专利号CN115422570A)实现了密钥集中管理,该方案的原理是建设一个集中的密钥管理系统,该系统负责主密钥和工作密钥的统一管理,向业务系统提供工作密钥,由业务系统使用工作密钥对业务数据进行加解密。改进方案2(专利号CN115514483A)提出了一种面向云环境的模块化密码服务处理系统,通过密码安全防护系统实现集中的密钥管理和密码安全模块管理,各个应用节点通过密码安全模块进行加解密运算。相关方案的对比分析,见表2。
表2 方案对比分析
在企业级架构建设实践中,敏感数据保护涉及设计开发、技术运维、业务运营、数据分析等全过程。而企业的业务功能一般由多个系统共同承载,如果系统间交互仍采用明文,意味着系统内部还存在敏感数据泄漏的风险。本文提出了一种基于统一密钥平台的企业级加密与密文跨系统交互方案,其目标是实现密文的跨系统交互以及可追溯的明文最小化使用。
1. 总体架构。建设企业级统一密钥平台(Key Management System,简称KMS平台),设置由主密钥(Master Key,简称MK)和工作密钥(Working Key,简称WK)构成的两级密钥结构。通过KMS平台实现密钥的集中管理与跨系统共享(见图)。
图 企业级敏感数据加密与密文跨系统交互总体架构图
任何系统获得的数据,如果是外部机构通过系统交换输入的加密数据,在常规解密环节即完成转加密,在转加密过程中原则上可实现业务系统不接触明文数据;如果是人机交互获得的明文数据,在进入系统时即完成加密。内部各系统的逻辑处理及存储、系统间交互原则上均使用密文,同时支持按需最小化使用明文,明文的使用均支持追溯。
2. 典型场景应用。涉及敏感数据的典型场景分别说明如下。
业务系统A是个人敏感数据的入口系统,如果该系统收到明文数据则立即加密,之后在所有业务系统的交互中均使用数据密文。如果该系统收到了外部机构上送的密文数据,则通过加密机“解密转加密”二合一指令,在加密机内部一次性完成密文转换,业务系统全程不接触明文。
业务系统B是涉及个人敏感数据的业务系统,该系统大部分业务场景中均使用密文,在少量需要明文的场景中,通过向KMS平台上送密文以及该密文对应的工作密钥索引(或工作密钥密文,视具体方案而定。考虑到主密钥更换的影响性,本文推荐使用工作密钥索引),由KMS平台负责解密。此时KMS平台对所有解密操作做好审计日志记录,如果被解密数据的工作密钥处于“有序更换有效期”,则同步使用新的工作密钥完成转加密。
通过KMS平台,大幅提升了敏感数据的安全水平,减少不同系统间对敏感数据的反复加解密,通过制定企业级标准化密文结构,规范密文的存储与传输,实现密文的跨系统流转与使用。
1. 主密钥及全局唯一索引。主密钥MK作为一级密钥,用于保护工作密钥WK,并在企业内实现安全共享。通过KMS维护的主密钥相关功能说明如下。主密钥跨系统映射关系示意,见表3。
表3 主密钥跨系统映射关系示意
(1)生成与维护MK全局唯一索引gIndex。gIndex是使用MK的凭证,企业内统一。企业可以基于安全隔离等因素设置若干MK。
(2)维护MK在各加密机集群中的物理索引hsmIndex。MK在各个加密机集群中录入之后需要将相应的hsmIndex录入到KMS,以hsmClusterId代表不同的加密机集群,将hsmClusterId+hsmIndex映射到全局唯一索引gIndex,gIndex在各业务系统中流通使用,密钥体系中的hsmClusterId、hsmIndex均与业务系统无直接关系。
(3)需要对工作密钥加解密时,KMS通过gIndex及可用的加密机集群标识hsmClusterId,映射到唯一对应的物理索引hsmIndex。
(4)基于KMS平台本身的高可用和安全隔离考虑,KMS可部署多套,多套之间可按需实现密钥管理数据的同步。
2. 工作密钥及唯一索引。工作密钥(WK)为二级密钥,由主密钥提供保护。工作密钥(WK)用于保护业务数据,工作密钥索引在企业内实现安全共享。通过KMS维护的工作密钥相关功能说明如下。
(1)生成工作密钥WK,在KMS中统一生成与维护由主密钥加密后的WK密文及WK的唯一索引wIndex。wIndex是使用工作密钥WK的凭证,企业可基于安全隔离等因素设置若干WK。
(2)维护工作密钥密文和工作密钥唯一索引wIndex,以及保护该工作密钥的gIndex之间的关系。wIndex在各业务系统中流通使用,密钥体系中的工作密钥密文、保护该工作密钥的主密钥等均与业务系统无直接关系。工作密钥更换对业务系统基本透明,存量密文数据的翻转加密根据企业策略有序开展,未翻转加密的密文数据不影响使用。
(3)业务系统需要加解密时,同时传递密文数据以及对应的wIndex,KMS通过wIndex可得到工作密钥密文及保护该工作密钥的主密钥gIndex,通过gIndex及可用加密机集群标识hsmClusterId获取实际的hsmIndex,再将后二者与数据密文一并传递至加密机,在加密机内部先获得工作密钥明文,再对数据密文进行解密。
3. 企业级标准化密文结构。为便利密文跨系统交互,制定企业级标准化密文结构,统一密文格式及加解密规范。结构可以是位图、也可以是JSON等其他格式。密文结构中的部分字段说明见表4。
表4 密文结构中的部分字段说明
4. 主密钥更换。在主密钥到期等情况下执行主密钥更换,并对所保护工作密钥进行转加密。主要步骤如下。
(1)在加密机集群和KMS系统中录入新增的主密钥及新增的gIndex等记录。
(2)由KMS逐条对过期主密钥保护的工作密钥进行转加密:①随机生成一段用于验证目的的数据明文,即“待验证数据明文”。使用原工作密钥WKold进行加密,得到“待验证数据密文”。②新增工作密钥WKnew,WKnew与WKold对应的工作密钥明文保持一致。先经WKold解密后得到工作密钥明文,再经步骤(1)新增的gIndex加密,整个解密和加密均在加密机内完成,保证工作密钥明文的保密性。③验证WKnew:使用WKnew,对“待验证数据密文”进行解密,并与“待验证数据明文”比对;对“待验证数据明文”进行加密并与“待验证数据密文”比对。④如验证成功,即上一步骤两个比对结果均一致,将WKnew状态置为生效,将WKold状态置为失效,WKnew的wIndex值与WKold保持一致,该条工作密钥更新完毕。⑤如验证失败,则重新执行上述流程。
特别说明:主密钥更换是极低频、极严谨的工作,工作密钥转加密逐条进行,加密机执行转加密前后都做好记录,确保逐条验证通过,整个过程中不删除主密钥和工作密钥,以确保安全。
5. 工作密钥更换。在工作密钥到期等情况下执行工作密钥更换,并对所保护业务数据有序进行转加密。主要步骤如下。
(1)为工作密钥设置2个到期时间点,例如2.5年为密钥完全有效期,2.5~3年为有序更换有效期,3年以后为失效期。
(2)在“有序更换有效期”期间,生成并启用新版本的工作密钥。业务数据加密操作都使用新版本工作密钥,业务数据解密操作都隐含执行“使用原工作密钥解密+使用新工作密钥加密”,并将新工作密钥索引随业务数据密文一并返回给业务系统,实现隐式转加密。
(3)在“失效期”,通知业务系统对尚未完成转加密的活跃数据进行转加密。对于不活跃的历史数据可根据企业规定视情况处理。
本文提出的基于统一密钥平台的企业级敏感数据加密与跨系统交互方案,通过主密钥与工作密钥的分层管理、统一密钥平台(KMS)及企业级标准化密文结构,解决了金融机构等企业敏感数据存储及传输加密的关键诉求。未来可进一步探索该方案在云计算、区块链等技术环境中的应用。
(此文刊发于《金融电子化》2025年6月上半月刊)