文丨中信银行软件开发中心 朱文义
传统的信息安全工作通常偏向于事中或事后检测漏洞，随着敏捷开发工作的逐步推进，商业银行认识到安全架构设计在实现IT降本增效方面的独特优势。近几年，商业银行逐步构建了安全架构设计工作体系，在组织人员、安全技术与管控流程方面，与企业IT架构密切协同，着力建设安全公共能力，为银行业务快速发展保驾护航。
一、以业务为中心的工作目标
安全架构设计人员首先要了解常见的银行业务类型，尽管银行业务不断推陈出新，但基本的业务流程变化不大，图1从客户旅程的视角针对零售类业务流程进行了抽象总结。
图1 零售类业务流程
常见的银行金融产品包括存款类、贷款类、汇款支付类和中间业务类等产品，日常的架构设计工作也主要围绕与这些产品相关的业务类型。安全架构设计的目标并不是强制要求业务应用必须零风险上线，而是在提前识别风险后引入领先的安全技术能力和灵活的纵深防御体系，使得业务发展在机会和风险之间取得平衡，从而使银行赢得客户和市场。
二、安全架构设计价值
线上应用系统的安全事件除了可能对银行自身及客户造成资金损失和信息泄露外，处理安全事件的过程同样费时费力，甚至需要对应用系统进行伤筋动骨式的整改。为了减少生产安全事件数量，在系统上线前即确保其对风险免疫至关重要。应用风险形成过程如图2所示，安全风险管理的三要素分别是资产、威胁和脆弱性，威胁主体利用资产脆弱性使其处于风险之中。为了最大程度减少生产事件数量，减少应用开发完成后因修复应用脆弱性而带来的大量整改工作，将安全工作左移至开发前的架构设计阶段是非常有意义的。
图2 应用风险形成过程
系统架构是指构成系统的组件及不同组件之间的关系，而安全架构贯穿于其他架构中，对不同架构视图中的组件及其关系进行保护。安全架构和安全设计可以分别看作是企业级和系统级两个不同层面的活动，这两个活动之间有着密不可分的联系。安全架构是从企业级的角度利用架构理论，基于安全技术建设可信身份，且具有鉴权及数据防护等功能的体系化的“安全武器库”；安全设计则是从系统级的角度依据监管要求和风险要求在数据流模型中识别公共安全需求，或者将“安全武器库”中的武器正确地应用到内部子系统之间，或者根据提炼公共能力的架构原则构建新的“武器”并择机纳入“安全武器库”中进行统一管理、运营，从而完善安全架构。本文将安全架构和安全设计统称为安全架构设计，安全架构设计工作至少为企业带来以下两个好处。
1.体系化识别安全设计缺陷，降低安全实现成本
多数安全问题是由于前期设计缺陷引发的，在架构设计阶段，利用安全模型全面识别这些设计缺陷，比从漏洞测试的角度识别更具整体性，识别风险更为全面，可显著降低后续漏洞整改的返工成本。
2.规划建设安全公共能力，提升业务响应效率
在大多数情况下，安全需求属于非功能性需求，天然不易被及时识别，加之安全产品往往需要外部采购，如果在项目实施后期才识别出安全需求，则会使整个项目陷入僵局。参考企业级架构原则，提前规划建设安全技术能力中心，可保证IT建设过程能够及时响应业务需求。
三、安全架构设计与企业架构建设
传统的安全管理往往会演变成“运动式”工作，在监管部门检查或发生安全事件的时候通常会要求项目组紧急或限期整改，这种方式无疑加深了安全部门与开发部门的矛盾，也无法达到长久的安全治理效果。通过融合IT架构的方法提升安全架构设计水平，一方面可推动建设公共类安全系统，以及将安全能力植入基础类平台；另一方面，借助架构管控，可将安全的标准化能力集成到各类应用系统中，以达到“润物细无声”的效果。
IT架构设计工作涉及应用资产管理、规范制定、方案评审、技术组件标准化等，这些工作都是安全架构设计的“使能器”。将安全架构设计融入企业架构工作中，将原来先开发后安全测试的项目管理方式调整为先安全架构设计再进行开发，可大幅度提升安全治理的效率。
四、安全架构设计体系
安全架构设计体系主要包括组织人员、安全技术、管控流程三个方面。组织人员方面，需明确人员分工，持续提升人员能力；安全技术方面，需实现安全能力解耦，确保安全功能的独立性和可复用；管控流程方面，需实现安全管控流程左移，综合管控多项安全活动，提前识别和缓解安全风险。
1.组织人员
复杂的安全架构设计并非一个团队就可以独立完成的，需要数据安全、IT安全、风控合规、应用架构、网络、隐私保护、法务、运维等多个团队协作，各参与方提前建立对基础设施、架构设计规约、应用架构、安全分工的认知，清楚各应用的作用、适用场景、特点、接入办法等。
实施安全架构设计的负责人应同时具备安全和架构两方面的知识和经验，由于业务知识比安全知识更为繁杂，因此我们倾向于对每个业务团队中的系统设计人员进行安全培训，帮助其掌握安全架构设计知识：一是应熟悉常用的攻击方法与危害、规范要求、安全模型、安全技术、安全机制，加密算法；二是应熟悉特定业务、项目流程、内部技术服务，以及产品与产品之间、组件和组件之间的关系。
2.安全技术
安全功能最理想的状态是与业务功能松耦合，具备一定的独立性，这就需要将安全功能从业务逻辑中剥离出来。根据新思科技(Synopsys)发布的BSIMM软件构建成熟度模型要求，不应当让每个项目组自行实施全部的安全功能(如身份验证、角色管理、密钥管理、日志记录、密码、协议等)，而应由软件安全小组(SSG)制定或由SSG推动他人制定，并发布可供工程技术团队使用的安全性功能。这些公共的安全功能被称为安全组件，项目组可受益于SSG预先批准的实施内容，而SSG则免于重复追踪那些处于安全功能之中的细微错误。应用安全组件前后对比情况如图3所示。
图3 应用安全组件前后对比情况
安全组件可实现以下功能：一是帮助项目组聚焦业务功能开发，提升研发效率，凸显安全技术价值；二是协助银行快速满足监管规范中的安全技术要求；三是协助行内安全规范落地，协助安全需求及安全方案落地；四是指导项目组快速修复常见漏洞问题，避免实现方式缺乏标准的问题，实现标准化整改。
安全组件分为技术组件和集成组件，其区别在于集成组件需要调用后端的安全服务实现安全能力，而技术组件则仅依赖自身实现安全能力。图4为公共安全组件统一视图。
图4 公共安全组件统一视图
3.管控流程
为保障安全架构设计落地，对于自研类的系统，应在系统建设初期开展安全需求分析、安全设计、安全开发、安全方案评审等安全活动。
(1)安全需求分析
传统的信息安全分为物理安全、网络安全、系统安全、应用安全、数据安全和业务安全等不同层次，然后再纵向切分，如软件开发安全生命周期、运维纵深防护体系等。除了数据安全和业务安全需求对开发人员可见度较高外，其他层次安全需求的可见度并不高，需要进行安全需求分析。
实施安全需求分析最常用的方法是威胁建模，在研发团队的安全活动中，对于一些拥有重要数据资产、安全事件影响较大、攻击暴露面较大的系统，更应该系统地按迭代版本或定期开展威胁建模活动，保证这些系统安全需求分析的覆盖率、及时率和有效率。银行是强监管行业，需要定制具有金融特色的威胁建模流程(如图5所示)。
图5 定制化威胁建模流程
①识别干系方
银行是业务最易实现数字化的行业之一，各类业务都需要信息系统的支持。随着银行IT架构成熟度的提高，通常一个业务需求会涉及多个业务应用系统，所以应提前识别干系人。干系人包括业务需求人员、业务风控人员、主办系统开发人员、配合系统开发人员、系统对口业务人员等，对干系人正确且全面的识别是后续工作顺利开展的前提条件。
②需求分析
需求分析这一步骤的输出即绘制数据流图，一般包括两个方面：一是业务方面，二是技术方面。在业务方面，根据业务需求说明书梳理所有的交易清单，明确关键交易，并绘制数据流图；在技术方面，需要梳理出关键链路上的所有节点应用，对每个节点应用进行安全多层次分析。
③合规研判
银行是强监管行业，除了国家标准要求的安全规范外，还有金融行业的各类安全规范，监管规范通常会对银行的各类业务场景给出明确指导意见，如《网上银行系统信息安全通用规范》对电子银行安全规范进行了明确，《商业银行应用程序接口安全管理规范》对开放银行等外联类业务安全提出了指导意见。通常银行会将这些规范解读后形成行内的安全规范，从而提高合规研判的效率。
④威胁分析
威胁分析的第一步是确认该业务需求是否必需，如非必需建议不进行威胁分析，这样可最大程度缩小攻击面。针对银行的常见业务，我们分别梳理了相关的威胁库、需求库、设计库、漏洞库和组件库。
对于业务开发人员来说，基于数据流图的威胁建模的技术门槛较高，建议业务开发人员在安全需求分析和安全设计时跳过前面的威胁分析步骤，直接使用安全模型，安全模型的代表是5A安全模型，具体内容如下。
身份认证(Authentication)：用户主体是谁?
授权(Authorization)：授予某些用户主体允许或拒绝访问客体的权限。
访问控制(AccessControl)：控制措施以及是否放行的执行者。
可审计(Auditable)：形成可供追溯的操作日志。
资产保护(AssetProtection)：资产的保密性、完整性、可用性保障。
⑤同类参考
根据同一交易在不同渠道的安全机制保持一致的安全原则，与现有同类业务场景的安全需求进行比较，保障安全需求的一致性。一方面确保现有的安全需求为我所用，避免遗漏安全需求;另一方面明确现有业务场景在安全需求方面的不足，为后续安全整改奠定基础。
除了参考行内同类业务的安全需求之外，还可以了解同业机构中同类业务的安全控制机制，这些信息除了可对安全需求分析提供参考之外，还可以帮助安全架构设计人员与业务人员沟通该项业务需求的可行性。
⑥综合评估
安全需求文档初稿完成后，需要请各干系方对安全需求清单、安全需求分级结果进行讨论，对需求进行取舍，最终确定安全需求文档终稿，如果各方实在无法达成一致，可申请各方面专家进行联合评审。
(2)安全设计
针对上述安全需求文档进行方案设计，复用安全组件库中的现有组件和安全设计库中的现有方案，重点关注个性化的安全需求，主要步骤如下。
第一，重温安全设计原则。因为大家都很熟悉常见的安全设计原则，此处不作赘述。
第二，了解现有各应用的架构信息和存量安全设计内容，包括主办应用、关联应用等。
第三，识别安全组件。安全架构设计的最大价值体现在组件复用上，在方案中明确识别出需要引用的安全组件，以开发人员熟悉的组件调用方式确保安全需求落地。对于无法使用安全组件满足的安全设计项，可以复用已有的成熟的安全设计方案。
第四，参考标准安全设计模型。安全架构设计的一个很重要的原则是标准化设计。认证相关的模型如OIDC、OAuth2、CAS、SAML和Kerberos等，访问控制相关的模型如ACL、RBAC、ABAC等，以及NIST和CIS发布的容器安全指南、IC卡密钥设计、SpringSecurity、Shiro、RKL远程密钥加密、FIDO实现生物识别等都可供参考。除了业界标准外，现有安全产品的实现机制也是重要参考之一。
第五，安全机制通常对易用性、性能等特性产生负面影响，对于这些影响，如果安全团队与业务开发团队无法达成一致意见的话，通常也需要通过专家联合评审确定最终的安全设计文档。
(3)安全开发
安全开发环节是保障应用安全的最重要一环，主要包括以下两个方面：一是对在设计环节识别出的安全组件进行集成，确保安全能力标准化；二是对没有安全组件支撑的安全方案进行落地，并为这部分功能从应用中剥离为独立的安全组件做好技术准备。
五、经验总结
1.接受信息不对称的现实
如果安全人员在与开发人员沟通的过程中不了解基本业务，则安全人员的工作较为被动，沟通效率较低，所以安全人员一方面需要了解基本业务知识，在与业务开发人员沟通的过程中尽可能少地丢失信息;另一方面，可积极对业务开发团队中对安全感兴趣的系统设计人员进行培训，帮助他们掌握安全知识，这样，比较简单的安全架构设计工作可以由他们自行完成。
2.架构设计应以需求为中心而不是应用系统
银行业务的复杂性决定了每个需求不是由一个系统独立实现，安全架构设计人员进行需求分析时很难将所有关联人员组织在一起开会，大多数情况下只能是与系统主管人员沟通业务需求和安全方案，所以往往会遇到对方对很多内容并不清楚的情况，极不利于架构设计工作的开展。
本文刊于《中国金融电脑》2022年第07期
声明：本文来自FCC30+，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。
