某银行业务连续性和应急处理方案

XX银行业务系统

业务连续性和应急处理方案

总则

业务系统的安全性是从技术角度与业务角度相互配合来保证，主要以防范为主，对于出现的突发事件必须有相应的组织机构来统一解决。为减少我行业务停顿造成的损失，降低重要业务进程和数据重大失效或灾难的影响，应急恢复工作组应制定详尽的应急计划，并且分工明确责任清晰。制定应急计划应分析灾难、安全失效及服务停顿的影响，明确关键设备如重要服务器、网络设备、通信线路以及软件系统的备份恢复措施和每一部分需要恢复的时间。应急计划应该明确针对不同情况的应急处理流程和恢复不同软件硬件的操作规范，并且定期进行实地演练；用作备份的设备应保持设备完好，而且应随时可以提供使用。应急计划应该经我行领导的审批，当业务系统发生变动时应急计划也应进行必要的修改、演练并获得领导审批。

第一章应急反应工作组

1.应急反应工作组的建立原则

应急反应工作组由业务部门与科技部相关人员组成，采取组长负责制。成员由专业技术人员与业务人员组成，应急反应工作组成员在业务、技术水平上具有足够的能力处理紧急事件。各成员要具有良好

的团队精神，每位成员应有明确的责任划分，在紧急事件出现时能够全力配合，服从领导安排、具有协同解决问题的能力。应急反应工作组在人员配备上要充分考虑备份方案，对于关键性岗位采取双人备份策略，以备在紧急情况发生时，保证关键岗位人员能顺利到位。

2.应急反应工作组职能

应急反应工作组职能主要包括根据业务需要确定业务系统的应急策略，并制定相应的应急计划；在事件发生时负责组织相关人员排除故障并恢复系统；平时应负责督促检查应急处理措施的准备落实情况；组织内部人员定期进行应急措施的培训和演练；每年对系统的应急策略和应急计划进行测试和评审，对需要修订的项目提出修改意见报安全领导小组审批。

3.定期修改应急计划与措施

为了适应业务系统业务快速增长的需要，业务系统系统日益复杂化，因此应急反应工作组会定期对应急计划与措施进行审计，检查各种恢复措施，确保能够从硬件、软件、网络、数据各个环节做到完整恢复。对于不断扩充的系统要即时有效地补充、修改应急计划与恢复措施，确保应急计划的可行性与高效性。

4.注重业务连续性管理的过程

根据业务系统交易及开户等重要业务进程，对围绕这些业务进程的软件硬件设备分出先后确定重点，如Web、LDAP、我行数据库等服

务器及其运行的应用软件和有关交换机、路由器等网络设备停顿可能影响业务设备更大。确定具体的备份措施，并经常检查备份措施的落实情况，保证对业务连续性的管理被整合到组织的流程和结构中。

5.定期测试应急恢复策略

对应急恢复策略要定期进行测试，一方面确保应急恢复策略的正确性，另一方面保证应急反应工作组成员对应急措施能够熟练掌握，确保应急恢复方案在故障发生后能够迅速有效地进行恢复，将恢复时间缩短到最小。

6.定期进行应急恢复培训

对于不断补充更新的应急计划及恢复措施，要及时对应急反应工作组成员进行培训，对各个环节出现的故障如何恢复进行培训，确保成员对应急措的熟练掌握，在系统出现故障及业务出现疏漏时做到快速响应，达到快速解决问题的目的。

7.汇报机制

对于安全事件引起的影响业务的问题，包括各种类型和不同严重程度的安全事件要根据第二章的有关要求及时上报，同时应急反应工作组按照应急计划实施步骤开始工作。

8.法律咨询

对出现的安全问题要向专门的法律咨询部门咨询，及时讨论解决

方案，使问题最小化。

9.建立健全的沟通渠道

应急反应工作组成员内部应建立健全的沟通机制，具有有效的联络方式，同时与硬件设备提供商、业务系统集成商等建立良好的沟通渠道，确保在问题出现时能够及时通知厂商及集成商，确保问题能够得到快速解决。

第二章安全事件管理

通常应急处理工作总是由安全事件触发的，建立事件管理的责任及程序，可以确保快速、有效和有序地做好应急处理工作。对安全事件管理是应注意以下几点：

1.安全事件种类

从表现形式分析安全事件可能会发生的安全事件种类，主要如下：

1)信息系统失败及服务丢失

一般指硬件设备出现故障，通信线路出现故障，网络配置丢失或出现错误，操作系统和数据库系统软件运行故障，业务应用程序运行故障等有关方面引起的信息系统不能正常运行甚至系统中断，所提供部分或全部应用服务也不正常或停止。也包括电源引起部分或全部系统瘫痪。

2)拒绝服务

一般指重要服务器受到恶性代码的攻击或病毒传播感染，造成系统故障或中断运行；防火墙及网络设备等受到恶性代码攻击造成阻塞使应用系统无法正常运行或运行效率低下。

3)因未完成或不准确的业务数据所引致的错误

一般指应用数据丢失、密码丢失、应用数据不正确而应用程序检查不严格容错能力又差，造成应用系统错误不能正常运行甚至中断。另外还有计算机犯罪出现数据不准确引起的系统错误。

4)泄密

一般指计算的加密解密密钥、加密解密参数、加密解密算法或函数、终端设备识别参数、IC卡的母卡及其存放介质和相关技术资料等；计算机系统所有源程序、网络参数、客户信息、用户密码、业务数据和相关的技术资料以及相应的存放介质等等被窃取，对系统造成威胁或已经造成损失，出现计算机犯罪现象。

5)恶性事件

一般指暴力、恐吓、有意破坏以及自然灾害等。

2.安全事件严重程度

安全事件的严重程度可分为四级：

1)严重程度1级：事件发生后立即得到控制，并可消除影响或尚未造成明显影响；

2)严重程度2级：事件发生造成系统30分钟至2小时停顿；

3)严重程度3级：事件发生造成系统2小时至8小时停顿；

4)严重程度4级：事件发生造成系统8小时以上停顿。

3.安全事件后期处理

对安全事件的处理除了正常应急计划（用来第一时间恢复系统或服务）之外，还应包括：

1)分析及确定事件发生的原因；

2)补救方法的计划及实施，以免再次发生；

3)收集审计追踪及其它类似证据；

4)与受影响的、或与恢复事件的人员保持联系；

5)把所作的行动报告有关部门。

4.安全事件证据保存

对安全事件进行应急处理的同时，应注意收集审计追踪及其它类似证据并保存妥善，主要用于：

1)内部分析事件使用；

2)作为破坏合同、违法或民事或犯罪诉讼（例如关于滥用计算机或数据保护条例）的证据；

3)索取软件及服务供应商的赔偿。

此外，收集的证据要符合法律要求，一般应注意：

1)证据的适用性：证据是否能够作为法庭证据；

2)证据的分量：证据的质量及完整性；