盛邦安全在同众多银行业金融机构的沟通和服务过程中，对当前银行业金融机构，尤其是中小银行业金融机构信息科技风险管理的现状有了较深入的了解，本系列文章旨在基于对中小银行信息科技风险管理的整体现状的认知，提炼和分享当前行业信息科技风险管理体系建设的面临的问题和良好实践，以期启发更多的行业思考和讨论。

本期讨论的主题是银行业金融机构信息系统开发、测试和运维管理实操。信息系统的开发和维护一直被视为银行业金融机构的核心能力，也是监管机构非常重视的信息科技风险监管领域，因为信息系统的开发和运维潜藏着影响巨大的固有风险。这些固有风险包括但不限于大范围的系统中断、数据篡改、信息泄露等；尤其是针对银行业金融机构，此类风险事件一旦发生，造成的影响，不论是直接的账户资金损失，还是机构声誉损失，都是金融机构不希望面对的。

最近几年在银行业金融机构发生多起网络安全相关案件，暴露出涉案金融机构在信息系统的研发、测试以及运维环节存在机制缺失或执行中存在漏洞。加强对信息系统开发和维护的管控，其重要性不言而喻。从实际案例来看监管要求，我们会发现监管指引或者办法的监管举措，着实是从防范风险的角度提出来的，如果能按照监管要求提到的原则开展信息系统的开发和运维，以上安全事件发生的可能性会大大降低。

本期，我们以《商业银行信息科技风险管理指引》（以下简称《指引》）第五章信息系统开发、测试和维护的监管要求出发，来看当前中小银行金融机构在信息系统开发、测试和运维的管控现状和出色实践。

一、关于信息系统开发、测试和运维能力

《指引》第三十二条提到，“商业银行应有能力对信息系统进行需求分析、规划、采购、开发、测试、部署、维护、升级和报废”; 此外还提到，“应在信息系统投产后一定时期内，组织对系统的后评价。” 从监管要求中我们可以看到，信息系统建设和维护的能力涵盖整个生命周期的各个阶段，同时，加强信息系统建设的后评价机制，也是通过回顾的方式检查和发现潜在的系统建设改进和优化环节。

目前中小银行普遍建立了涵盖信息系统生命周期的信息系统建设管理制度体系，明确了各个阶段的管理要求、执行流程以及操作细则，但完全依赖行方的技术能力和人员配置，还不足以承担所有信息系统的规划、需求、开发、测试以及维护；中小银行普遍存在研发人员配置不足以及人员能力缺失的现状，基本上大多数信息系统项目的开发和测试，甚至运维，需要依赖外包商或者外包人员的方式来开展；也是基于此，监管机构推出了《银行业金融机构信息科技外包风险监管指引》，用以明确信息科技外包策略，规范银行业金融机构外包商和外包人员的管理，控制因各类外包活动带来的风险。

针对后评价机制，目前我们发现大多数中小银行虽然有类似的管理机制，但评估或者评价的目标更贴近于项目验收的内容；有的后评价执行过程中关注的是参与项目的外包商或者外包人员的评价；缺少对于设计和落地的差距分析、投入和产出分析、项目预算和决算分析等关键指标的后评价，并通过这些指标能进一步追溯根本原因，为后续的信息系统建设整体机制持续提供优化和提升的建议。

中小银行信息系统开发建设以及维护的全面能力的提升，首先需要来自于银行管理层对信息科技重视程度的提升；金融机构管理层能够认识到信息科技能力对于银行业务转型和创新带来的价值，就会在信息科技进行持续投入；我们看到部分领先的中小银行设置了“一部两中心”的模式，其中开发中心的开发人员编制大幅提升，开发人员超过一两百人的规模，部分银行甚至更多；部分中小商业银行为了招募有竞争力的人才，研发中心往往设在人才聚集的一线或省会城市。

二、关于信息科技项目风险

《指引》第三十三条提到，商业银行应认识到信息科技项目相关的风险，包括潜在的各种操作风险、财务损失风险和因无效项目规划或不适当的项目管理控制产生的机会成本，并采取适当的项目管理方法，控制信息科技项目相关的风险。

目前大多数中小银行都制定了围绕系统开发建设的项目管理办法，一般都明确了项目的预算、立项、可行性分析、实施、质量管理、交付、投产、验收、后评价等环节的管理要求；以及明确了各个环节的参与部门及各自承担的职责。

我们发现，大多数中小银行的信息系统建设很少会引入风险管理部门或合规部门参与信息系统的业务流程需求和设计，这些业务流程大多由业务需求部门、开发商的固有流程确定，并最终落地上线，系统是否存在可能不合规的操作风险或者业务逻辑漏洞，往往没有进行评估或者验证。之前曾经发生过的某股份制商业银行的ATM虚增存款的案例，攻击者利用的就是系统存在确保交易的唯一性的机制存在严重不足的漏洞，从而会让一笔真实的交易被复制提交并被确认，从而产生“虚增”。

一些领先的中小银行在信息系统（尤其是业务/交易系统）需求和设计阶段，便会引入风险管理条线的相关操作风险或合规专家参与其中。此外，一些领先的中小银行中，推行“一二道防线融合机制”，风险管理部门（二道防线）会将信息科技风险管理团队派驻到信息科技部门参与一道防线信息系统建设的过程风险评估，把控各个环节的风险控制机制的执行，并根据业务实际情况调整和优化相关管控机制。

三、关于信息系统开发方法

《指引》第三十四条提到“商业银行应采取适当的系统开发方法，控制信息系统的生命周期”以及“所采用的系统开发方法应符合信息科技项目的规模、性质和复杂度。”

银行传统的开发模式通常采用“瀑布模式”，即包含问题定义、可行性分析、需求分析、系统概要设计、详细设计、编程调试、测试发版、上线运行等明确的步骤和阶段。

传统开发模式管控机制严格，可以较大程度控制开发风险，在生产环境发布经过严格测试的软件版本，保证系统运行的安全稳定。但随着互联网金融的发展，面向客户需求，需要对银行自身的金融产品（如理财或者消费金融产品）进行快速响应和迭代，传统的开发模式很明显不能满足这种需求场景。“敏捷开发”模式就成为金融行业必须要增加的一个选项。

在很多金融机构，目前开发模式被定义为“双速IT”，即以稳定为基本需求的信息系统（如银行核心、网银、支付等）采用传统的瀑布式开发模式；而以“响应速度”为基本需求的信息系统则采取“敏捷”的模式。

针对“敏捷”开发可能带来的人员、技术、产品、过程等常见风险，领先的中小银行金融机构设计了围绕“敏捷”开发的管理体系，建立了支持敏捷开发的DevOps机制（含系统及安全风险控制机制）。对于银行业客户有个特色，即使是基于敏捷开发的模式，响应的项目依然需要补充必要的系统开发的必要文档，如需求说明、设计说明、测试文档、变更说明等等，大多数都是通过后续补充来达到制度或监管的要求。

四、关于信息系统变更和升级

《指引》第三十五条和第三十八条分别提到了信息系统变更和升级的要求。第三十五条中主要强调商业银行应制定相关控制信息系统变更的制度和流程，确保系统的可靠性、完整性和可维护性，具体要求包括（一） 生产系统与开发系统、测试系统有效隔离。（二） 生产系统与开发系统、测试系统的管理职能相分离。（三） 除得到管理层批准执行紧急修复任务外，禁止应用程序开发和维护人员进入生产系统，且所有的紧急修复活动都应立即进行记录和审核。（四） 将完成开发和测试环境的程序或系统配置变更应用到生产系统时，应得到信息科技部门和业务部门的联合批准，并对变更进行及时记录和定期复查。第三十八条中主要强调商业银行应制定相关制度和流程，控制系统升级过程。

银行业金融机构都按照监管机构要求制定了信息系统变更和升级的管理制度，一般都规定了变更的分类和变更级别、职责分工、变更申请、变更受理、变更规划、变更测试、变更评估、变更审批、变更实施、变更复核、变更后处理、变更归档等相关环节；在变更流程中，一般都区分了一般变更、重大变更和紧急变更的区别流程。

银行业金融机构的生产系统、开发系统和测试系统，一般都采取了严格的隔离机制；领先的中小银行，采用了物理隔离或者准物理隔离的机制；开发和测试区域不能直接访问生产区域，也有很多中小银行在隔离方面并不严谨，存在为变更和升级操作方便，开发测试网络访问生产网络的控制不严格的风险点。大多数中小银行业金融机构系统开发、测试、运维的职责进行了职责分离，不过部分中小银行也因为人员岗位编制限制，普遍存在开发、测试和运维岗位兼职的情况；存在开发人员访问生产环境没有严格执行审批或授权的控制环节。此外，生产环境的变更和升级，我们发现大多数中小金融机构并没有按照监管要求引入业务部门的联合批准；我们之前提到的某股份制商业银行的研发人员进入生产环境恶意操控核心系统，盗窃银行大额资金案中，存在生产环境对开发人员防控控制机制和执行上的漏洞。因此，我们发现环境隔离、职责分离、变更审核、联合审批，都是较大程度上防止或者减少恶意人员通过变更或者升级环节对生产环境恶意操作风险的必要举措。

五、关于信息系统开发中的数据安全

《指引》第三十六条提到商业银行应确保信息系统开发、测试、维护过程中数据的完整性、保密性和可用性。我们上期也提到《指引》第三十条对数据安全做出了原则性的要求，商业银行应制定相关制度和流程，严格管理客户信息的采集、处理、存贮、传输、分发、备份、恢复、清理和销毁。所以针对信息系统开发这个大场景，会涉及生产数据的采集、处理、存储、传输、分发、清理和销毁这些环节，尤其是测试环境会用到生产数据。

我们上期也提到，目前中小银行的数据安全管控在监管的推动下，已经建立了体系化的管控策略，普遍制定了生产数据的管理策略和制度，涵盖了数据采集、处理、保管、备份、销毁等环节；部署了数据安全防护的技术体系，包括但不限于如下环节：数据加密、数据库访问控制、数据库审计、数据脱敏、数据防泄漏等。此外，围绕数据所处的使用环境，分别在应用安全、网络安全、基础设施安全等方面都对数据的采集、传输、存储和使用方面提高了安全管控强度。

针对中小银行开发和测试环境，大多数中小银行业金融机构都建立了生产数据使用申请的审批和执行机制，申请时明确数据使用范围和使用期限，无需真实生产数据都需要借助脱敏工具进行脱敏操作；数据脱敏操作人员和数据使用人员职责分离；数据使用完毕，进行数据的删除或者覆盖操作（尤其针对真实数据测试场景）；对于参与研发和测试的人员如需真实数据，领先的中小银行采用虚拟桌面的方式访问测试系统和生产数据，生产数据“不落地”。部分中小银行也建立了定期抽查开发和测试终端是否存在敏感数据的机制，涵盖外包开发人员的终端。

此外，开发测试环境的生产数据的存储和访问，尤其是目前针对大数据开发和测试的场景，数据使用范围广，使用周期长，考虑到开发和测试环境的访问控制机制相对生产环境会“薄弱”很多，往往没有专人负责这些数据的保管，以及配套相应的技术控制机制，因此潜在的泄露风险也会加大。

六、关于问题管理

《指引》第三十七条提到商业银行应建立并完善有效的问题管理流程，以确保全面地追踪、分析和解决信息系统问题。

大多数中小银行都建立了问题或事件管理相关制度，以及建立了问题或者事件管理的信息化管理平台。目前普遍存在的问题是中小银行没有真正将事件管理和问题管理区分开来进行管理；事件管理更多的是围绕单次发生的故障采取的处置管理流程，而问题管理则是围绕多次同类事件而开展的根本原因分析而采取的管理流程，以期能够从根本上杜绝因同一问题而导致的类似事件再次发生。

领先的中小银行，会基于IS020000（信息技术服务管理体系）要求，或者通过ISO20000体系的认证，建立和完善事件管理和问题管理流程，从行内发生的信息系统多个事件来开展问题根源分析，并根据发现的问题根源，配置必要资源并进行解决。问题管理流程的输入，通常是多个事件的处置信息，而非一个事件的闭环处置流程，这样能够大大降低事件的发生频率和影响后果。

本文内容来自于盛邦安全对中小金融机构信息科技风险管理现状的有限了解，难免管中窥豹，其中不准确、不正确、不恰当之处也请读者谅解和指正，尊贵的银行业金融机构也请不要对号入座。盛邦安全将在本年度陆续发布针对中小金融机构信息科技风险管理现状观察系列文章，如有兴趣，敬请期待。