实战丨内部可信安全建设

欢迎金融科技工作者积极投稿！

各抒己见！

投稿邮箱： 

[e-mail]

                                 ——金融电子化

盛京银行信息科技部副总经理  罗英凯

中国银行保险监督委员会办公厅313号文指出:相关机构在系统建设和开发过程中，安全需求考虑不全面，系统安全设计存在缺陷，生产交易系统底层的身份认证、权限控制、数据完整性校验、数据加密等安全控制技术缺失，安全测试不充分，系统“带病”上线，导致安全风险敞口增大。核心应用系统的数据库用户账号和口令直接以明文方式暴露在源代码中，为采取有效的保护措施，内部开发人员在核心应用系统中植入恶意程序，利用该账号口令非法篡改数据库生产交易数据；相关机构对内部生产网络安全风险认识不清，盲目认为内部网络“可信”。并督促银行业金融机构加强生产交易系统安全风险控制，切实保障资金安全。

需求分析

应用系统之间是通过报文传输交易，通讯方式有两种：长链接通讯方式和短链接通讯方式。应用系统之间只对交易密码等敏感数据进行了加密处理，在交易前，并未验证应用系统双方之间的身份。

1.交易报文可信需求分析

在应用系统之间，如核心系统、ESB系统、柜面系统、手机银行、内管系统、IC卡前置、贷记卡前置等内部系统之间的交易报文缺乏相应安全措施，接口安全防范能力薄弱。据此，应对内部各应用系统之间的生产交易报文，进行相应的安全防护升级，防范交易报文的篡改，确保报文的完整性，防止产生交易报文被篡改、丢失或泄漏，以致引起生产事故。

2.系统关键信息需求分析

应用系统在启动、运行时，通常需要使用诸多的关键信息，如数据库访问凭证，面向服务架构的通讯凭证，涉及启动的关键参数等。这些关键信息缺乏有效的保密管理手段，若存本地落地，则同样存在泄露风险。

建设规划

1.建设思路

解决内部可信，应该从应用系统交易的生命周期入手。第一步是解决应用系统之间可信，对应用系统的双方身份进行互验；第二步是解决应用系统交易报文可信，根据交易的类别，采用不同的加密技术；第三解决应用系统运行所依赖关键信息的安全可信。

2.建设原则

应用系统内部可信涵盖了全行几乎所有的应用系统，影响范围非常广泛，因此统一的规划能有效地保证应用系统的匹配以及协调的运转，应遵循统一规划、统一标准；分级、分阶段实施；以需求为导向、安全稳定可靠原则。

3.建设目标

本次我行内部可信安全建设方案以313号文为出发点，初步目标是消除监管机构提示的生产风险，避免类似问题发生。同时，重新审视我行内部系统的安全流程，建设一个可信认证管理平台，融合当前密码技术和创新技术手段，为我行的业务发展提供高标准、严要求的管理服务。

建设方案

可信认证管理平台是一个集中管理平台，但又可分布式部署，为应用系统提供可信认证支撑，可信认证管理平台有以下子系统。

数字证书认证子系统，简称：UAS。负责应用系统长链接模式下SSL证书的管理，负责应用系统短链接模式下Token管理，以及负责应用系统在系统可信认证过程中的身份鉴别等。

密码服务子系统，简称：CSSP。提供数据保密性服务、完整性服务、不可否认性服务。

关键信息保护子系统，简称：ASV。负责数据库访问凭证、面向服务架构的通信凭据，涉及关键信息数据的保护。ASV为应用访问各类关键信息数据提供统一的接口，同时提供严格的访问控制和访问审计记录。

可信认证管理平台门户，简称：CAP。B/S架构，对UAS、CSSP进行用户权限的统一管理。

1.系统可信安全设计

为了保证内部应用系统之间的安全、可信。应用系统在相互通讯前，需要访问可信认证管理平台，并将可信认证管理模块嵌入应用系统中。

（1）应用系统之间为长链接模式。对于应用系统之间采用长链接模式，当应用系统A需要与应用系统B建立通讯链接时，使用双方应用可信认证模块进行证书双向验证。

在实现长链接通讯模式下，双向SSL认证的过程，采用以下两种实现方案。

第一种模式：应用系统之间双向SSL握手认证、协商对称密钥过程通过可信认证管理平台，认证和协商对称密钥成功后，使用对称密钥对链路加密的过程由应用系统中的可信模块负责。

第二种模式：应用系统之间双向SSL的握手认证、对称密钥协商、链路加密均由可信认证模块负责，但证书还是统一由可信认证管理平台统一生成、管理。

（2）应用系统之间为短链接模式。对于应用系统之间采用短链接模式，我行采用两种实现方案。

第一种模式：设计代理链接转换模式。在应用系统中部署代理,并将可信认证模块部署在内。应用系统依旧采用现有的短连接创建链接。在首次交互时，当应用系统A与应用系统B创建短连接，链接通过应用系统A代理与应用系统B代理建立长链接通道。

交互流程：首先，代理通过可信认证模块进行双向认证，认证通过后长链接通道保持，并将应用系统A报文通过建立的长链接通道转发给应用系统B代理；其次，应用系统B代理与应用系统创建短连接，并将接收到的报文数据转发至应用系统B接收端完成交易；再次，长链接通道始终维持，根据定义安全策略定期重新进行可信认证。

第二种模式：通过Token认证。应用系统A与应用系统B之间的身份认证采用Token认证机制。

交互流程：首先，应用系统A、B须在UAS子系统中注册，UAS为其分配系统ID、初始Token。其次，应用系统与UAS之间采用双向SSL认证，UAS为应用系统颁发唯一证书，该证书只能在认证后的系统使用，以此确认每一个应用系统的身份。为保证效率，应用系统与UAS之间采用长链接。再次，应用系统A与应用系统交易时，应用系统A首先向UAS申请Token，然后将申请后的Token和交易发送应用系统B。最后，应用系统B收到应用系统A的Token，将Token发送UAS进行验证。

2.交易报文可信设计

内部系统交易报文可信设计，从交易报文的数据分类开始，制定内部交易数据的保护等级，从而采用合适的防护机制。

根据国家《信息安全技术-信息系统安全等级保护定级指南》确定信息系统保护等级，并根据应用系统中数据对组织的价值、法规要求、敏感性、关键性进行数据分类。一般可以将数据划分为：一般数据、重要数据、敏感数据。

内部应用系统应保证数据交换与传输过程中敏感数据和重要数据的完整性、来源鉴别、可用性以及敏感信息的机密性，并防止在交换与传输过程中，非授权获取数据或对数据进行篡改、破坏。

应用系统应对交换与传输过程中的交易报文提供如下保障。

报文的机密性：保证交易报文中的重要或敏感信息受密码技术保护。

报文的完整性：防止交易报文被非授权修改。

报文防重放控制：防止交易报文被模仿或截获重放。

报文序列号控制：防止交易报文被恶意预测或伪造。

报文源鉴别：防止交易报文被伪造或破坏、提供源不可否认性。

报文目的鉴别：提供目的不可否认性。

3.关键信息可信安全设计

构建应用系统的关键信息保护，将应用系统所需要的配置参数、数据库帐号等统一保存在可信认证管理平台关键信息子系统（application security vault），简称:ASV。ASV为任何secret提供统一的接口，同时提供严格的访问控制并记录详细的审计日志。

交互流程：首先，应用系统通过ASV-API访问ASV操作关键信息时，首先需要进行应用的身份校验；其次，ASV中保存的关键信息数据采用HSM加密，存放DB应用调用的ASV-API采用HTTPS；再次，认证凭据需要有全局时间控制，控制认证凭据的有效时间；最后，ASV具有全局开关控制，若发现有异常访问时，可关闭此开关，限制所有应用及用户操作敏感数据。

往期精选：

（点击查看精彩内容）

关于仿冒我刊收费的声明

我刊自创刊以来，从未向投稿人收取过任何费用。任何以刊发文章为名向投稿人收取费用的行为，均属于对投稿人的欺诈行为。

我刊官网地址为 www.fcmag.com.cn。

我刊投稿邮箱为 [e-mail]。

对于仿冒我刊网站、网页的违法行为，我社将追究其侵权责任，以维护我社和投稿人的合法权益。仿冒网站、网页举报电话：[phone]

《金融电子化》新媒体部：主任 / 邝源  编辑 / 潘婧 傅甜甜