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

 

本期继续讨论中小银行信息安全管理。上期提到，金融行业关系到国计民生，支撑其运营的重要的信息系统是国家关键基础设施，是信息安全重点保护对象。由于互联网金融的快速发展，以及来自互联网的安全威胁层出不穷，以银行业为代表的金融行业的安全建设思路开始发生深刻变化，变化趋势和特点有以下几点：

 

◆ 监管合规向自身业务安全需求导向转变；

◆ 安全技术体系向安全运营体系转变；

◆ 安全防护能力向攻防对抗能力转变；

◆ 静态防护向动态智能化防护转变；

◆ 边界防护向零信任体系转变。

 

在目前的大趋势下，中小银行业金融机构总体上处于被动应对的状态，普遍缺乏洞察变化后的主动调整和跟进，反映在金融企业内部安全建设上，仍然存在头痛医头、脚痛医脚，整体网络安全能力建设难以适应外部环境变化。网络安全团队和人员，不论是理念意识、知识技能，还是实战经验，以及同实际保障业务安全的需求上存在很大差距。

 

在这样的背景下，我们重新来回顾《商业银行信息科技风险管理指引》（以下简称《指引》）中关于信息安全管理的监管要求，我们会发现，监管层面的底线要求仍然在发挥着重要的指导作用，我们会围绕这些核心监管要求，并结合当前中小银行信息科技安全管理实操的现状，分享行业内的一些出色或有效实践。

 

上期我们分享了（一）信息分类保护和人员意识、（二）安全管理职能、（三）用户访问控制机制、（四）物理安全保护区域、（五）逻辑安全保护区域的现状和出色实践。如果想了解上期内容，可以参考文章【盛邦观察：中小银行业金融机构信息科技风险管理现状（3）】。

 

我们本次接着分享的领域是（六）操作系统和系统软件安全、（七）信息系统安全、（八）日志安全、（九）信息加密等部分；下期将分享（十）终端设备安全、（十一）数据安全、（十二）安全意识等部分。

 

六、操作系统和系统软件安全

 

《指引》第二十五条对操作系统和系统软件安全做出了明确管控措施的要求，简单归纳一下包括基线安全、访问权限控制、特权账号控制、补丁管理、日常监控管理等。

 

目前大多数中小银行都在监管检查的推动下制定了本行的操作系统、数据库、中间件等系统的安全基线核查标准，普遍存在的问题是基线标准并没有涵盖所有系统软件，以及基线标准执行和检查力度不够；领先的城商行会加强对系统上线前的基线核查，不满足基线标准的系统整改后才可上线，此外基线的变更和生产环境的配置变更保持同步。

 

对操作系统和相关系统软件的访问控制权限，尤其是针对生产网的访问控制权限一般都较为严格，通过生产网的堡垒机或4A平台来控制访问权限，这个控制环节存在的普遍问题是部分系统未纳入统一访问控制机制，以及存在授权访问权限细粒度不够的情形，尤其是对于关键敏感操作命令的控制权限；领先的城商行会对堡垒机或4A系统的账号权限进行定期复核和评估，以确保不必要的系统访问带来的风险。

 

对于重要系统的特权账号或高权限账号部分银行也采取了双人保管密码、双人登录以及定期特权账号审查等方式来加强控制和审计，但对于大多数中小银行这部分的控制往往因为运维人员人力和管理意识不足的原因，并没有采取严格控制。

 

补丁管理方面大多数中小银行都建立了生产环境补丁管理的机制，银行不会采取自动的补丁修补机制，但在实际执行时又因为测试环境不满足测试需求等原因而不能在生产网对所有的补丁进行手工修补；领先的城商行会建立漏洞/补丁修补评估机制，对于不满足修补条件的情形建立授权审批机制。

 

对于操作系统和系统软件的日常监控管理方面，一般都会开启和保留系统相关日志，但是大多中小银行不会主动对日志中记录不成功的登录、重要系统文件的访问、对用户账户的修改等有关重要事项进行审计和分析，这项工作确实是比较费力的一个环节，同时又需要一定的分析能力，通过自动化的日志分析工具或态势感知分析一定程度上可以帮助运维人员简化人工分析的压力。

 

领先的城商行会积极探索基于UEBA(用户及实体行为分析)的分析技术和解决方案，结合SIEM（安全信息和事件管理系统/平台）/SOC（安全管理中心/平台）等相关技术来综合分析重要的异常客户行为，从而更智能的筛选出可能的关注事项。

 

七、信息系统安全

 

《指引》第二十六条对信息系统安全做出了明确管控措施的要求，简单归纳一下包括系统管理者和使用者的角色和职责、采取有效的身份验证方法、关键和敏感岗位采取双重控制、系统的输入输出验证和核对、保密信息的输入和输出控制、系统出现例外的处置、系统审计轨迹以及对未成功的登录和修改行为进行审查等。

 

此处的信息系统安全，我们理解的是偏狭义银行业务系统的安全，因为在其他的领域和条款中对于业务系统之外的系统安全都有专门的要求。《指引》中明确要求所有的信息系统都要考虑上述的控制机制，至于控制机制的强弱则要根据系统重要性、处理信息的敏感性去考量。

 

对于银行的业务系统而言，是一个大的范畴，概要来说涵盖产品管理类系统、渠道管理类系统、客户管理类系统、财务管理类系统、决策支持类系统、共享支持类系统等。我们观察到面向客户、账户和交易类的业务处理，系统通常分布在产品管理类、渠道管理类以及客户管理类系统类别中，这类系统的安全管控标准往往比较严格，采用的技术的安全性也非常高，尤其是面向互联网的交易系统，这也符合重要业务系统本身的防护定位。但是对于非面向账户、客户以及交易类的系统，往往安全管控机制会弱很多；这里面存在的一个问题是，这些非面向客户、账户和交易类的系统，例如财务数据处理相关系统、决策分析类系统以及共享支持类系统中，很多处理的数据的敏感性并不低，甚至本身也处理跟客户、账户和交易类系统所产生的敏感数据，如果考虑到这些因素，那么对于这些系统的安全管控机制就普遍存在管控弱点，这些弱点可能会造成银行的敏感数据的泄露；一旦发生数据泄露，如果系统日志管理和设计有缺陷又很难审计和回溯。

 

而实际上，我们发现对于大多数银行客户内部的决策支持类、财务管理类、共享支持类系统的安全控制机制和管理机制都很薄弱，普遍存在账号权限分配不合理、共享管理账号、敏感信息传输和存储不加密、审计信息不完备、系统使用过程的监控和审计机制缺失等问题。目前银行普遍采取的渗透测试和代码审计等安全检测机制，也很少应用到这些非客户、账户以及非交易类系统领域，很少揭露这类系统的漏洞，而这些漏洞目前在银行内潜在的风险比较大，很容易被恶意的银行员工或者第三方人员利用，造成里面处理的敏感数据泄露。

 

领先的城商行会在全行范围执行统一的业务系统安全控制架构和标准，发挥架构管理的优势，这些安全控制架构和标准本身涵盖针对特定业务处理场景的安全控制要求和管理要求，在保留统一架构的前提下，通过场景安全评估，保留系统建设的弹性，杜绝“一刀切”；此外，领先银行也在开展基于信息系统生命周期（SDLC）的安全体系建设，从技术平台和管理体系两个方面提升信息系统安全能力，较大程度杜绝“带病上线”的系统。

 

八、日志安全管理

 

《指引》第二十七条对日志的管理提出了明确要求，明确规定商业银行应制定相关策略和流程，管理所有生产系统的活动日志，以支持有效的审核、安全取证分析和预防欺诈。指引把日志划分为交易日志和系统日志两大类，对于日志要包含的信息以及保管期限都明确做了规定。

 

我们发现，银行设计交易的信息系统产生的交易日志基本都涵盖监管要求的用户登录尝试、数据修改、错误信息等；对于交易日志的保管要求基本都是无限期保管，大多都能依托“两地三中心”的数据中心灾备架构来保管，能够满足国家会计准则的要求。

 

对于系统日志，大多数银行都开启了包括操作系统、数据库管理系统、防火墙、入侵检测系统和路由器等设施的日志功能，内容一般涵盖管理登录尝试、系统事件、网络事件、错误信息等；对于系统日志的保存期限，目前大多数银行也是无限期保存，基本满足监管要求的一年的保存期限。大多数银行也都部署了集中日志管理系统，统一收集各类系统和设备的日志信息，有些日志平台能够按照检测规则实现实时的监控和报警；有些银行会明确定期对日志进行回顾和分析的要求；而我们实际工作中发现，真正落实对日志开展定期复核机制的很少，基本还是依靠日常运维监控过程中发生的报警事件进行响应和分析。

 

《指引》对于日志复查频率和保存周期有个细节要求，就是由科技部门和业务部门共同决定，并报信息科技管理委员会批准；大多数银行都忽略了这个要求；也有些银行是把日志复查频率和保存周期明确在相关的安全管理制度中，安全管理制度的发布是要通过信息科技管理委员会审议通过才能行内发布，因此也可以满足监管的这个细节要求，而没有必要针对这一个细节专门提报信息科技管理委员会批准。

 

九、信息加密

 

《指引》第二十七条明确对涉密信息在传输、处理、存储过程中采取加密机制，防范出现泄露或被篡改的风险，并建立密码设备管理制度。主要要求包括采用符合国家要求的机密技术或者设备、加强涉及密码设备人员的管理、加密强度满足机密性要求、加强密钥和证书的管理。

 

商业银行加密体系的管理基本都类似，一般都建设了加密平台和加密设备，普遍采用满足国密算法的加解密体系；涉及交易的应用系统通过统一调用加密平台的加密接口；管理比较严格的银行一般密钥都是由多人保管，并存放在保险箱；保险箱的密码又是另外一个人管理，密钥使用申请需要走审批流程。

 

总体来说，银行业金融机构对交易信息的传输和存储是非常重视，在技术层面的配置一般都比较完备，面临的一个问题类似我们之前在业务系统安全里面谈到的，非交易类系统使用交易数据或者其他敏感的客户或者账户数据，在传输、处理和存储过程中的加密处理机制上往往就比较缺乏，应当引起足够的重视。

 

安全部分的现状观察未完待续，我们下期会分享中小银行终端设备安全、数据安全、安全意识等部分的现状观察。

 

本文内容来自盛邦安全对中小金融机构信息科技风险管理现状的观察与调研，难免管中窥豹，其中不全面或不当之处欢迎大家交流指正，也请各位不要对号入座。针对中小金融机构信息科技风险管理现状观察的系列文章将陆续发布，敬请期待。