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

一、重申以业务为中心的安全目标

安全架构设计人员首先要了解银行业务，尽管银行业务不断推陈出新，但基本的业务流程变化不大，比如我们从客户旅程的角度针对零售类业务总结了以下流程：

 如上图所示，其中交易包括存款类、贷款类、汇款类和中间业务类等交易，可以说我们日常安全需求分析和设计申请多数来源于上述这些类型的业务需求。安全架构设计的目标并不是要求业务零风险上线，而是通过引入领先的安全技术能力和构建灵活的纵深防御体系，帮助业务在机会和风险中间取得平衡，最终赢得客户和市场。

二、应用系统风险生命周期管理

线上应用系统的安全事件除可能对银行自身及客户造成损失外，处理安全事件的过程同样费时费力，成本高昂。为了减少生产事件数量，我们自然很希望在系统上线前即保证其对风险免疫。应用系统的建设过程如同养娃，而系统上线则是将娃养大成人后推向社会，最终成为能够修身，齐家，治国，平天下的有用之人，当然这一切的前提是其能够屏蔽社会上的各类危害的不良影响。

图 1 风险生命周期管理

三、安全架构设计的定义

我们的目标是保护业务安全，尽管安全架构设计在业界分享不是很多，为了使安全工作降本增效，我们需要摸索推进安全架构设计工作。在谈安全架构设计的时候我们必须考虑到实战场景的威胁模型和安全属性（如机密性、完整性、可用性、隐私性、真实性等等）组成的安全模型（包括下文提到的5A模型），脱离威胁模型和安全模型空谈绝对安全几乎毫无意义。

四、安全架构设计的价值

除了上面提到的可以实现安全工作降本增效之外，安全架构设计还有以下2个好处：

1.识别体系化的结构缺陷：大多数安全问题是设计缺陷问题，通过安全架构模型全面识别这些体系化设计缺陷，比漏洞测试角度更具整体观，识别风险更为全面，提前减少风险敞口。

2.识别国内外合规要求：由于银行通常涉及跨国分行和海外业务，通过向监管机构和合作伙伴提供产品的风险管理活动的完整记录，帮助开发团队遵守国内或全球法律法规要求如《个人金融信息保护技术规范》、PCI DSS、GDPR等。

五、安全架构设计概述

安全架构设计主要从组织人员、管理流程、安全技术三个方面推进工作，组织人员方面需明确人员分工，持续提升人员能力；管控流程上实现安全管控流程左移，特别是安全需求分析和安全设计；安全技术上实现安全能力解耦，确保安全功能的独立性和可复用。

1、组织人员

在进行复杂的安全架构设计时并非一个团队就可以独立完成的，还需要数据安全、IT安全、风控合规、应用架构、网络、隐私保护、法务、运维等多个团队协作，各参与者最好提前建立对基础设施、架构设计规约、应用架构、安全分工的认知，清楚各应用的作用、适用场景、特点、接入办法。对于实施安全架构设计的负责人有以下基本技术能力要求，其中第2条并不是安全人员的特长而是开发人员的特长，需要较长时间的工作积累：

a.熟悉常用的攻击方法、危害、规范要求、安全模型、安全技术、安全机制，加密算法；

b.熟悉业务、项目流程、内部技术服务、产品与产品之间、组件和组件之间的关系；

2、管控流程

对于外部采购的系统，立项、POC阶段就开展安全需求分析和设计活动；对于自研类的系统，在系统建设初期，参照SDL流程，做好安全需求分析、安全设计、安全方案评审等安全活动，但因为面临工作多、难度大，人员少等问题、所以务必需要对需求分类分级。

安全需求分析

传统的安全一般是分层的，物理安全、网络安全、系统安全、应用安全、数据安全和业务安全，然后再纵向切分，如软件开发安全生命周期、运维纵深防护体系。通常除了数据安全和业务安全需求对开发人员可见外，理论上这两层的安全需求应该是业务需求的一部分，而其他层次的安全需求的可见度并不高，需要进行安全需求分析。

实施安全需求分析最常用的方法是威胁建模，在研发团队的安全活动中，对于一些拥有重要数据资产、安全事件影响大、攻击暴露面大的系统除了要进行常规的安全测试之外，更应该系统地按迭代版本或定期开展威胁建模活动，保证这些系统的安全需求分析的覆盖率、及时率和有效率。因为银行是强监管行业，我们需要定制化威胁建模。

1.识别干系方

银行是业务最容易数字化的行业，各种业务都需要信息系统的支持，随着银行应用架构成熟度的提高，通常一个业务需求会涉及到多个业务应用系统。我们应提前识别干系人，干系人包括业务需求人员、业务风控人员、主办系统开发人员、配合系统开发人员、系统对口业务人员等，对干系人的正确全面识别是后续工作顺利开展的前提条件。

2.需求分析

需求分析这一步骤的输出就是绘制数据流图，数据流图这项技术本身存在的不足是：关注组件的交付是还是相对偏数据流动视角，例如钓鱼等风险不能充分揭示；不能完全表达出应用系统的全部交易，只能关注重点交易；数据流会额外显示出其他安全层引起的风险，并不仅仅是业务自身的应用安全。

针对上面这些缺点，需求分析一般包括2个方面，一个是业务方面，一个是技术方面，业务方面首先梳理所有的交易清单并明确是否关键交易，因为不同交易的数据流可能是不一致的。技术方面我们需要梳理出关键链路上的所有节点应用，对每个节点应用进行安全多层分析，分析其层间依赖组件。

3.合规研判

  银行是强监管行业，除了国家标准要求的安全规范外，还有金融行业的各类安全规范，监管规范通常会对银行的各类业务场景给出了明确指导意见，如《网上银行系统信息安全通用规范》对电子银行安全进行了明确，《商业银行应用程序接口安全管理规范》对开放银行等外联类业务安全提出了指导意见。通常银行会将这些规范解读后形成行内的安全规范，这样可以提高合规研判这一步骤的效率。

4.威胁分析

目前业内有STRIDE、Trike、OCTAVE等多种常见威胁分析方法论，有很多可以参考的资料，我们这里不做详细讨论，这里我想提醒大家的是威胁分析的第一步是确认该业务需求是否必需，如非必需建议不做，这样可最大程度降低攻击面。针对银行的常见业务，我们分别梳理了相关的威胁库、需求库、设计库和漏洞库。梳理的威胁风险列表示例如下：

业务流程	渠道	营销	开户	认证	鉴权	交易	权益	客服	数据分析
常见风险	PC、H5、APP、三方渠道、5G消息、公众号、小程序、自助机具	薅羊毛	冒名开户、交易步骤绕过	短信炸弹、人脸替换等、密码加密等。	功能越权 数据越权	冒名转账、冒名贷款、冒名合同	活动达标配置错误	视频客服	个人信息泄露

基于数据流图的威胁建模对于业务开发人员来说的门槛还是比较高的，建议开发人员在安全需求分析和安全设计时跳过前面的威胁分析步骤，直接使用安全架构模型，毕竟开发人员更熟悉安全架构模型。安全模型的代表是5A安全模型：

身份认证（Authentication）：用户主体是谁？
授权（Authorization）：授予某些用户主体允许或拒绝访问客体的权限。
访问控制（Access Control）：控制措施以及是否放行的执行者。
可审计（Auditable）：形成可供追溯的操作日志。
资产保护（Asset Protection）：资产的保密性、完整性、可用性保障。

我们都知道无论哪层的架构都包括三要素：职责明确的模块或者组件、关联关系、约束和指导原则，5A安全模型就是对组件间的交互过程提供保护，当然这种保护是跨安全分层的。

图 2 5A安全模型

5.同类参考

根据保持同一交易在不同渠道的安全机制一致的原则，与现有同类业务场景的安全需求进行相比，保障安全需求的一致性，一方面确保现有的安全需求为我所用，避免遗漏安全需求，另一方面明确现有业务场景在安全需求方面的不足，为后续安全整改奠定基础。

除了参考行内同类业务的安全需求之外，我们还可以了解同业机构中同类业务的安全控制机制有哪些，这些信息除了对安全需求分析提供参考之外，还可以帮忙我们与业务人员沟通该项业务需求的可行性。

6.综合评估

安全需求文档的初稿普通要求较为严格，通过召集各干系方沟通，请大家对安全需求清单、安全需求分级结果进行讨论，讨论取舍哪些需求，最终确定安全需求文档终稿，如果各方实在无法达成一致，则申请专家联合评审。

2　安全设计

针对上述安全需求文档进行方案设计，复用安全设计库的中现有方案，重点关注该应用个性化的安全需求，主要步骤包括：

1. 回顾安全设计原则：因为大家都很熟悉这里不做赘述。

2.了解现有安全设计：包括主办应用、关联应用，如果我们对各应用的情况有所了解，则可以大大提高效率，通过与开发人员面对面访谈了解安全设计现状。

3.参考标准安全模型：安全架构设计的一个很重要的原则是标准化设计。认证相关的模型如OIDC、OAuth2、CAS、SAML和Kerberos等，访问控制相关的模型如ACL、RBAC、ABAC等、NIST和CIS发布容器安全指南、IC卡密钥设计、SpringSecurity、Shiro、RKL远程密钥加密、FIDO实现生物识别等。除了业界标准外，目前安全产品的实现机制也是重要参考之一。

4.串联安全组件：安全设计的最大价值体现在解决问题上，通常安全设计方案偏向理论说明，落地过程中存在开发人员理解差异等问题，我们日常工作中应该注意收集和规划公共安全组件，在方案中明确引用相关的安全组件，以开发人员熟悉的组件调用方式确保安全方案落地。对于无法使用安全组件满足的安全设计项，还需要与各关联方沟通安全功能的具体分工，以确保方案落地。

5.安全方案评审：

   除了客户和业务的显式安全需求外，安全机制通常对易用性、性能等特性产生负面影响，这些影响如果与业务开发团队无法达成一致的话，通常也需要通过专家评审确定最终的安全设计文档。

3、安全技术

安全功能最理想的状态是与业务功能松耦合，具备相当的独立性，这就要求将安全功能从业务逻辑中剥离出来。安全设计方案的落地离不开安全组件，根据新思科技(Synopsys)发布的BSSIM软件构建成熟度模型要求，不应当让每个项目组自行实施全部的安全功能（例如，身份验证、角色管理、密钥管理、日志记录、密码、协议等等），而应当通过 SSG (软件安全小组)制定或由 SSG (软件安全小组)推动他人制定并发布可供工程技术团队使用的安全性功能来提供前瞻性的指导。这些公共的安全功能被称为安全组件，项目组可受益于SSG预先批准的实施内容，而SSG 则免于重复追踪那些常常处于安全功能之中的细微错误。

图 3 使用安全组件前后对比

安全组件的好处有以下几个：

1　帮助项目组聚焦业务功能开发，促进提升研发效率，突显安全技术价值。

2　协助我行快速满足落实和满足监管规范中的安全技术要求。

3　协助行内安全规范落地，协助安全需求及安全方案落地。

4　指导项目组快速修复常见漏洞问题，避免实现方式缺乏标准的问题，实现源头性整改。

我们目前梳理的应用组件视图如下，分为SDK和系统，其中系统还可以根据封装粒度的大小分为原子系统和组合系统：

图 4  公共安全组件统一视图

六、经验教训

1　承认双方信息不对称

如果安全人员在与开发人员沟通的过程中不了解他们的基本业务，我们安全人员其实是很被动，沟通效率低，所以我们一方面需要了解基本业务知识，这样才能在业务人员沟通的过程中尽可能少的丢失信息，另一方面我们积极培训业务开发团队中对安全感兴趣的人员，帮助他们掌握安全知识，这样比较简单的安全需求可以由他们自行完成。

2　正确理解安全左移

作为软件开发中心的安全人员，虽然理论上我们只需关注应用安全，但在实际操作过程中，作为离应用系统开发人员最近的安全人员我们义不容辞的要承担起其他安全分层中安全左移的工作。如果开发人员在上线前才知道系统的管理端与交易端需要拆分部署，显然为时已晚了。

3　以需求为中心而不是以应用系统为中心

银行业务的复杂性决定了每个需求都不是由一个系统独立实现，而是一个系统工程，然而我们需求分析时很难组织所有关联系统在一起开会，大多数只能会主办系统的人员沟通业务需求和实现方案，所以往往会遇到对方对很多内容并不清楚的情况，这个时候我们就很难继续下去，只能把问题提出来请他们去搞清楚再评估。

4　仅分析相对高阶的安全需求

最开始践行安全需求的时候，我们总是想希望做得很全面，于是出具一个很冗长的安全需求，希望这个安全需求一直可以传递到安全测试阶段。这个方式理论上很好，但也丧失了重点，应该不同阶段解决解决不同的安全需求，基础的安全需求靠组件和自动化测试解决，我们应该重点关注这个业务场景中一些相对独特的或薄弱的安全需求。

5　与开发人员形成信任

开发人员日常开发过程中一定会遇到安全相关的问题，他愿意和你沟通且能帮助他们解决问题的话，双方之间就会逐渐形成信任，信任以后在日常的沟通中开发人员的安全意识就会提高，也就会在这个项目组成为安全的广播员，后续就可以不失时机的安排培训了。

6　为啥新增业务需求不能复用存量的安全设计方案。

a.随着监管制度法规的完善对业务的安全性提出更高的要求，如国密算法要求；

b.公司安全基础设施能力不断提升，为业务提供的公共安全能力不断增强，如之前由应用系统自行实现，目前由公共安全组件统一实现；

7　安全架构设计业内经验分享少。

我们采用的思路是眼前灭火与体系建设同时推进的思路开展安全架构设计工作，在灭火期我的主要目标是提高高风险系统的覆盖率和及时率，后续从组织人员、管控流程和安全技术等方面逐步完善体系。