商业银行安全架构设计实践

出处:

一、被低估的安全系统架构

安全相关的功能是每个系统系统必不可少的功能，随着信息化进程的推进，商业银行在业务架构、应用架构、技术架构等方面持续投入了很多资源和精力，然而安全架构似乎处在一个尴尬的位置，安全系统架构因为同时涉及企业的安全能力建设和不断更新的安全威胁，这就要求安全架构人员同时掌握架构设计和攻防。然而目前业内搞安全的工程师很多擅长攻防，并不懂架构；而真正擅长架构设计的工程师又只对安全一知半解。由于缺乏安全架构人员，商业银行的安全系统的建设通常是采购成熟的安全产品，很多时候安全系统的建设完全是为了满足眼前的业务需求，形成了很多烟囱林立式的安全类系统，缺乏提前规划和布局，从而表现为对业务系统项目组无法形成及时和有力支撑。

二、安全系统分类

①按安全功能分类

常见的安全系统列表可以参照闷哥的上一篇《商业银行安全架构设计实践》文章。

②按建设方式分类

安全系统的建设模式分为自研、开源引入、采购，部分安全类产品研发的技术门槛并不是特别高，比如像SSO这样的系统。另外还有些安全组件系统是在市面上并不容易买到而建议优先通过开源方式引入，例如密钥生成工具，如openssl。另外有些安全系统因为涉及法律合规的风险，这恰恰是第三方专业厂商所擅长的，所以建议优先通过采购引入。法律合规风险与系统的复杂度无关，大到一个证书权威CA系统，小到一个密码输入控件。从实际工作来看，采购方式引入的系统还是占大多数。

自研

开源引入

采购

自主可控

容易

较困难

困难

研发周期

实现周期长，研发成本高

较短

研发周期短，但采购周期可能长

合规运营服务

合规运营风险大

开源协议存在风险

有配套合规运营服务，如签名验签证书、全流程存证等

③按部署形式分类

集成的方式一般包括页面SDK+API接口、后台SDK、纯API接口、后台SDK+API接口和交易拦截器等多种方式。

三、安全系统架构关注点

1. 内生安全VS安全独立

内生安全是指让应用系统自身具备安全能力，并不是指安全逻辑和功能逻辑必然紧密集成，安全逻辑和功能逻辑的解耦一直是安全建设工作的追求，如从加密SDK转化成加密SDK+API接口的方式，既可以保留安全功能的独立自主性，也可以减少了安全功能集成的复杂度。页面SDK+API接口和拦截器相比其他几种方式的集成复杂度低很多，如智能验证码、终端设备指纹和SE手机盾等系统一般是通过页面SDK的方式集成，而单点登录、鉴权、日志、ServiceMes安全等系统则是通过拦截器的方式实现。

2. 自研实现VS法律风险

部分安全类产品的研发过程并不复杂，技术门槛也不高，但自研方式存在一定的法律风险，如安全系统支持多法人的引起的法律问题、事后纠纷相关的法律风险。最典型的场景就是电子签章系统，签名的功能很容易实现，但出现纠纷后的法律效力是否有效很值得商榷，另外系统是否可以通过增多渠道标识支持兄弟公司这一多法人的场景也是一个值得探讨的问题。

另外自研过程还可能会涉及复用开源安全组件，如与文件签名相关的iText组件，根据iText最新的开源协议，如果我们的应用系统直接使用的话则必须开放源码，而这显然在商业银行内部是绝对不允许出现的，否则只能取得商业许可，这一过程如执行不到位也会存在法律风险。

3. 私有化部署VS云化服务

商业银行总是倾向于将采购的系统进行私有化部署，其中除了监管的原因，一方面是数据安全的原因，另一方面是担心应用系统连续性不可靠的问题。私有化部署的话我们通常会要求系统依赖的组件要符合行内对组件的统一技术要求，需要对接行内的应用系统和监控系统，按行内网络要求部署，甚至因为架构定位的原因需要舍弃采购产品的部分功能。整个“嫁接”的过程需要行内和厂商都投入不少的成本，我们应该进行提前预判。

4. 黑盒子VS灰应用

私有化部署除了以软件部署+license限制方式以外，还有可能是以某个黑盒子的方式完成部署。黑盒子的方式虽然可以大为减少供应商维护的工作量，但其加大了行内对其的了掌握的困难，同时也增大了快速横向扩展的限制，这里我们还是建议通过软件部署+license限制的方式。

5. 功能集成VS策略集中

纯后台SDK这种方式除了集成复杂度高之外，还有一个较大的缺点就是无法实现配置数据线上实时更新，只能通过系统上线的方式才能实现。比如我们提供一个校验PDF文件的组件的话，我们必须集成相关CA的根证书，如果需要使用其他CA的话，我们的SDK就必须要更新，从而需要相关系统配合集成和上线，所以如果我们能预判签名证书对应的CA会发生变化的话，我们就特别不推荐使用纯后台SDK的方式来验签文件，其他场景以此类推。

另外一个关于策略应该集中化的例子是国密改造，如果我们要求业务系统都了解并上送具体的算法、证书等信息时，改造过程中就会要求关联系统改造很多，伤筋动骨，甚至在日常运营中证书到期都需要把相关系统折腾一遍。

6. 分散建设VS集中建设

引入了安全服务以后，如果没有企业级的统筹，由于部门墙的存在，每当业务应用有类似需求的话，项目组通常会倾向自己采购或建设，而我们要从企业级架构的角度出发将这些功能类似的安全类系统进行集中化建设和管理。在这个里面表现最为典型的就是签名服务器网站安全架构，特别是针对行内需要调用外部服务的场景。如果缺少企业级统筹，由于服务方的签名规范实现不一，接入方对接入周期要求特别短，所以业务系统项目组通常希望通过采购实现，所以我们规划和建设了统一签名服务平台，以便减少有此需求的项目组的工作量。

7. 直接接入方VS原始接入方

一个独立的安全类系统的接口中一定不能缺少对接入方的标识，性能容量评估、调用量统计等多个场景都需要明确识别接入方，但接入方将安全接口封装后外放的情况最让人头疼。如果我们不掌握原始的接入方，我们就无法识别调用方前面的渠道，而这增大了渠道系统上线对安全系统性能产生的风险。另外因为一些安全系统涉及针对具体业务调用的统计以确定针对业务部门的收费，建议对采购的安全类产品务必要增加原始接入方和和接入场景相关的字段。

8. 功能集中VS渠道隔离

在实际工作中，安全类系统集中化建设确实减少了各业务系统项目组的负担，但有一个难题不可避免，就是不同应用之间因缺少物理隔离存在相互影响的问题，包括性能、升级频率等多个方面。这个问题我们短期内只能通过集群分组+交易监控的方式解决。随着基础设施的云化，业务系统逐步上云，安全系统物理隔离的需求随着业务系统弹性扩容的要求而变得更加强烈，所以安全系统必须云化并实现物理隔离才能满足这类需求。

9. 按需采购VS架构规划

”组件用时方恨少“是安全工作落地的最大困扰之一，安全应用架构的主要目的就是从业务风险出发，提前布局安全产品。业务和科技每年都在演进，安全架构必须围绕业务和技术进行统一规划，形成体系和演进路线，而不能沉醉于一轮又一轮的应急类安全系统建设中。

四、总结

安全系统架构需要考虑的方面很多，我们应将其做为企业架构的一部分，因其十分复杂所以需要提前规划并逐步实现，而不是仅将其当作风险发生后的补救措施，希望本文能给大家一些启发。

（编辑：好传媒网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!