第 627 页
（业务管理）第十六章业务
连续性管理
业务连续性管理
随着信息化的发展、企业、政府对信息系统运作的稳定性和可靠性的要求就越高。 本
章首先将从什么是业务连续性计划及 BCP相关概念进行了介绍；然后介绍了应急响应概念、
如何建立安全应急响应管理系统和应急响应流程以及针对事件的发生如何处理；最后介绍了
灾难恢复计划相关概念和所使用的技术以及灾难恢复级别是如何定义和如何制定灾难恢复
计划。本章内容适合参加信息安全高级管理师认证的读者。
概述
什么是业务连续性计划
业务连续性计划(Business Continuity Planning，缩写为 BCP)，BCP可被定义为一种
先知先觉的流程, 它可以帮助企业确认影响业务发展的关键性因素及其可能面临的威胁。由
此而拟定的一系列计划与步骤可以确保企业无论处于何种状况下，这些关键因素的作用都能
正常而持续地发挥。BCP的目标是建立一种合理有效的成本控制方案，以平衡由威胁带来的
可能的业务或资产的损失及为保证业务连续性运作而进行的成本投入。
业务连续性对确保灾难发生时企业的生存是至关重要的，不过与之同等重要的是要保证
企业日常的业务运行平稳有序。业务持续管理即 BCM是一种整体管理流程，它能够确定可能
发生的冲击及对企业运作造成的威胁，并提供一个架构来阻止或有效的抵消这些威胁，以保
护股东的利益、公司的名誉及品牌。
BCP运作流程
BCP运作共有 6个阶段，分别为：
1. 项目初始化
2. 风险分析及业务影响
3. 策略及实施
4. BCP开发
5. 培训计划
6. 测试及维护
1. 项目初始化
(1) 获得管理层的支持与投入
为了确保该程序能够成功，高级管理层必须参与其中。BCP计划必须成为公司的战略性
业务计划提供独立的预算。
(2) 建立团队
必须建立一个团队，人员包括财务部，审计部，信息技术部，人事部，行政部等等。当
灾难开始时，这些部门在继续扮演他们承担的支援角色的同时，也必须实施重大的机构转变
以援助受影响的区域。法律部、公关部与投资部在事件发生后需要向公众及股东通告公司的
运作状况。
2. 风险分析及业务影响分析
决定BCP需求的关键驱动力是"企业能在灾难中承受多少金额的损失"？业务影响分析的
目的是回答以下问题：
• 保护何种资产？(资产识别与评估)
• 资产的威胁与脆弱点？(脆弱点和威胁评估)
• 有没有控制措施？控制措施能否预防或减少潜在的威胁？(评估控制)
• 投入金额/劳力的多少？(决定)
• 投入资金的效率如何？(通讯和监控)
当进行业务影响分析时，应考虑以下几方面：
• 金额的影响：如果不采取相应的措施，则组织的经济损失是多少？
• 客户的影响：如果发生业务中断，则组织会损失多少市场占有率。
• 法律的影响：组织是否遵从法律的要求？
• 内部依赖关系的影响：中断的业务是否会其他领域的关键业务？
• 作为业务影响分析的一部分，应该评估业务允许中断的时间长短；
• 组织能提供多常时间的信息；当信息重新可用时，允许损失的信息是多少？
这些问题可以通过恢复时间目标（recovery time objective (RTO)）和恢复点目标
（recovery point objective (RPO)）来决定。
BCP需求的另一个因素是“灾难实际发生的可能性”。此因素由威胁的级别和组织具有
的薄弱点范围决定，威胁的程度取决于下列因素：
• 有恶意性的破坏，如轰炸、纵火、工业间谍等。
• 意外事故，如组织的办公场所、环境，内部系统和处理程序的质量。
3．业务持续性策略及实施
(1) 业务持续性策略
业务影响分析为制定业务持续性策略提供必要的信息，下来，根据提供的信息，可以确
定多种满足组织业务持续管理的方案。必须为各种业务持续方案进行成本、效益及风险分析，
包括：
• 满足业务持续目标的能力
• 影响的可能性
• 安装设备的成本
• 维护、测试及调用设备的成本
• 中断对于技术、组织、文化和管理的干扰及未采取持续管理的潜在影响
• 应该仔细考虑采取业务持续方案确实解决了具体的风险但不会增加其它风险。通过
风险降低和业务持续方案成本的平衡来决定业务持续策略以降低风险达到业务持续的目标。
(2) 实施
• 设立组织及准备实施计划书
• 实施备份安排
• 实施降低风险的措施
4. BCP开发
开发业务持续计划之前，确定灾难发生的情况下执行的行动，你需要熟悉每天的操作任
务。这意味这你需要熟悉每一个业务处理过程的基本文档。在开发业务持续计划之前，须考
虑下列措施是否已经存在：
• 变更控制流程
• 最终用户的标准操作流程
• 操作人员的具体需求和特殊外围设备需求
• 数据流图表及问题管理程序
• 重要记录
• 磁带备份/记录管理日常安排
• 异地存储
开发 BCP计划时，需考虑在计划执行的七个阶段中为每个恢复小组分派任务：
• 评估与声明
• 通告
• 应急反应
• 过渡期处理
• 抢救
• 重新安置及启动
• 重新正常运做
5. 培训计划
一些员工需要的特殊培训如下：
• 有紧急情况时可应用替代的技术流程
• 当自动操作系统正在恢复时可替代的人工操作流程
• 确保团队成员达到推动 BCP所需能力的技术培训
6. 测试及维护
进行演示及有规律的测试，增强信心及效率，确保其相关的文档时常更新。
总之，组织没有业务持续计划就像是不设防，不可能阻止任何不可预测的破坏所造成的
各种损失。所以公司必须认真的对待业务持续计划。
应急响应计划
应急响应概述
应急响应背景
1988年 Morris蠕虫事件直接导致了 CERT/CC的诞生。美国国防部(DoD)在卡内基梅隆
大学的软件工程研究所成立了计算机应急响应组协调中心(CERT/CC)以协调 Internet上的
安全事件处理。目前，CERT/CC是 DoD资助下的抗毁性网络系统计划(Networked Systems
Survivability Program)的一部分，下设三个部门：事件处理、脆弱性处理、计算机安全应
急响应组（CSIRT）。
在 CERT/CC 成立之后的 14年里，共处理了 28万多封 Email，2万多个热线电话，其运
行模式帮助了 80多个 CSIRT组织的建设。
“进入 21世纪，网络技术的高速发展，使物理世界中涉及政治、军事、经济、文化、
外交、安全关系和利益的全球化、多级化的复杂的世界格局，已经全面映射到开放的互联网
体系中，由此形成了一个社会、技术一体化的复杂巨系统！”在首届“全国互联网应急处理
研讨会‘2004”大会上，专家们描述出的国际互联网大环境，使我们深刻地认识到，完全杜
绝互联网安全事件是不可能的，重要的是加强应急响应！
在这一复杂巨系统中，国家公共管理职能开始向互联网世界全面渗透。就像物理世界面
临着 SARS、禽流感等病毒时，国家建立了整套的应急体系和处理能力一样，当互联网上蠕
虫、病毒、网络攻击日益泛滥时，同样需要这样一个体系对网络攻击事件进行紧急处理，包
括事前监测、事中处理和事后的灾难恢复。因此，公共互联网应急体系已经成为国家应急体
系的一个重要分支。
正因为应急响应的重要战略地位，2004年 1月 9日～10日在北京召开的备受信息安全
业界乃至社会各界关注的全国信息安全保障工作会议上，国家将强化应急体系、提高处理能
力作为保障信息安全最重要的基础任务之一。2月 11日～13日由信息产业部互联网应急处
理协调办公室(简称 CNCERT/CC)主办的“全国互联网应急处理研讨会‘2004”大会，正是这
一精神的具体落实和体现。
但是，与物理世界不完全一致的是，面对全球一体化的互联网环境，国家公共互联网应
急体系的建立和应急处理能力的提高，并不能仅仅依靠政府的力量，而是需要世界各国相关
组织在技术、资源、经验方面的共同合作，需要政府与企业、全社会每个人的互动！在互联
网这样一个复杂的巨系统中，如何提高应急响应的处理水平确是摆在我们面前的巨大难题，
这也正是次此会议的初衷——从理论方法学到实际运作经验，探讨如何在复杂巨系统中理清
思路，提高应急响应水平的方法。
“开放的互联网符合复杂巨系统的所有特征，我们要用综合集成的思维方式，考虑应急
响应的管理方法。”
对许多人而言，公共互联网应急响应的概念并不新鲜，也并不难理解，因为物理世界面
对 SARS的处理方法已经让人们充分地认识到了应急响应的必要性和紧急物理隔离的措施和
方法。然而，当现代社会越来越依赖大规模的网络系统时，按照常规的方式已经不能有效处
理网络紧急事件了：计算机蠕虫病毒已经成功实现智能化，开始主动寻找设备进行攻击；感
染速度越来越快，能在数小时内传遍全球；应急响应却越来越慢，网络攻击采取伪造地址方
式，难以追踪到真实的病毒制造者；而进行完全的物理隔离在互联互通时代越来越行不通……
于是，理想与现实的反差越来越大！中国工程院院士何德全认为，这是因为，互联网世界已
经构成了一个“复杂巨系统”！“复杂巨系统具有四个重要特征，而开放的互联网体系完全
符合这四个特征:首先是‘巨’，即子系统数目巨多，不是千万级数量概念，而是数亿级数量
概念；第二是复杂，子系统与子系统之间是高度非线性的内部关系结构；三是自组织，互联
网没有统一的领导，而是依靠统一的协议进行连接；四是开放，任何系统只要符合协议规范，
就可以没有任何限制地任意连入全球网络系统。”
在这种复杂巨系统中，虽然很多企业自己提早做了应急预案，但在具体实施中很难实现
理想的效果。为什么呢？因为目前的应急管理无法适应复杂巨系统的要求：首先是缺少知识
层次上的应急响应的全生命周期管理；其次是做出的应急计划都是线性、彼此完全分割的，
只有任务的分解而没有综合集成，基本无法完成有效的应急响应。
预案不是简单做完了就行的，而应该随着过程、环境的变化而不断变化，不应该是线性
的，而应该是非线性的防灾计划。
信息安全与应急响应的关系
对于一个单位或组织来说，信息和其他重要的商业资产一样都具有价值，因此要给于适
当的保护。信息安全保护信息免受各方面的威胁，以达到确保商业连续性，尽量减小商业损
失并且尽量增加投资回报率和商业机会的目的。
信息能够以多种形式存在。可以打印或写在纸上，以电子形式存储，通过邮寄或使用电
子方式传播，用影片显示或口头转述。无论信息表现为何种形式，或以何种方式分享或储存，
都应该对其进行适当的保护。
信息安全的特点被总结成保护：
a）保密性：确保只有被授权的人才可以访问信息；
b）完整性：确保信息和信息处理方法的准确性和完整性；
c）可用性：确保在需要时，被授权的用户可以访问信息和相关的资产。
信息安全可以通过实行一套控制措施来实现。控制措施除实施安全产品外，还要有必要
的紧急事件的响应和灾难事件的备份与恢复机制，如 2003年 1月 25日爆发的 sql slammer
蠕虫事件，组织中如果没有很好的应急响应流程和方法，就会给组织带来很大的损失。如图
16-1应急响应属于风险管理的一部分。
图 16-1应急响应组成
在信息安全中，对于一个组织来说，最重要的就是保持组织的业务连续性，如图 16-2
清晰地说明了维持业务连续性要制定的相关计划，其中很重要的内容就是事件响应计划。
图 16-2业务连续性计划
因此，下面的章节会讨论应急响应的相关术语及如何有效的建立应急响应小组等，帮助
组织建立自己的应急小组，以辅助组织实现自己的安全目标。
我国的应急响应体制现状
红色代码事件推动了我国应急处理体系的形成，对跨国的计算机攻击事件的处理推动了
国际应急组织的合作，我们已经实现从应急组织向应急体系的转变。
早在 SARS出现之前，早在物理世界的疾病应急体系建立之前，信息产业部就已经着手
建立公共互联网应急体系，在组织结构、人员组成、响应技术方面进行了综合投资和考虑。
整个国家的应急体系都在建设中，不仅包括互联网应急体系，还包括广电系统、医疗卫生系
统、煤炭系统等应急体系，但信息产业部走在了前面，公共互联网应急体系的经验值得推广。
据 CNCERT/CC主任方滨兴介绍，中国 CNCERT组织自 2003年 7月正式成立以来，目前
已经在全国各地建立了31个分中心，授权10家信息安全产品和服务供应商作为重要的技术、
服务合作伙伴，除此而外，信息产业部还要求国内的 10家骨干互联网运营企业(包括 6家电
信运营商和 4个公共信息网)成立自己的应急响应中心(CERT)，这 10家互联网运营企业与中
国数千家的 ISP、个人用户和企业用户，成为了 CNCERT/CC的主要联系成员，由此形成了一
个立体交错的应急体系，形成了信息上下畅通传递的通报制度。这套体系不仅在中国，在世
界也是独一无二的。
通过这套体系，2003年，在 SQL病毒、口令蠕虫和冲击波病毒泛滥致使成千上万台服
务器遭受重创、435台中国的主机网页遭到篡改、各种 DDoS攻击严重的恶劣的互联网环境
下，CNCERT/CC有效及时地将应急方法推广下去，使这些攻击得到有效的遏止。
此外，互联网攻击全球化的特征，使各个国家的 CERT组织必须在深层次上展开合作，
才能形成全球一体化的反应体系，在这个体系中，各国的 CERT组织均是其中重要的一个成
员。CNCERT/CC也一样，目前与国际应急响应组织建立了广泛的技术、交流的合作关系，并
在与国际交流中，在职责、组织结构和技术水平上不断进行完善。
在法律规范上，虽然目前关于互联网应急响应的国际公约还不成熟，但是联合国已经提
出，国家与国家之间在互联网应急上要相互协作。在技术手段上，为了实现应急响应的监测、
响应和恢复三大职责，各个运营商，包括中国移动、中国电信、中国教育网等，都已积极建
立自己的互联网监测平台，并连入 CNCERT/CC的监测平台上。而国家对信息安全监测和预警
技术也给予了充分的投资，国家 863项目的 917监测平台正是在国家层面上建立起的试点性
的监测项目，通过自愿加入的原则吸收成员单位，及时发现互联网上的攻击行为和新的病毒
爆发情况。目前的监测还仅限于流量异常监测、及时发现网络攻击和新型蠕虫病毒，但是，
在未来，我们必然会实现更加细粒度的监测和网络安全应急响应。正因为互联网全球化的特
征，公共互联网的应急响应才具备国际化的特征，需要更多的国际应急响应组织参与到体系
当中，共同进行技术的合作、经验的交流。
应急响应的国际组织结构
计算机应急处理的国际组织惯称为：CERT (计算机紧急响应小组)，也有的被称为
CSIRT (计算机安全事件响应小组)。
在美国的推动下，全世界几十个国家和地区都成立了 CERT或类似的组织。1990年 11
月，在美国、英国等的发起下，一些国家的 CERT组织参与成立了“计算机事件响应与安
全工作组论坛”，简称 FIRST。它的基本目的是使各成员能就安全漏洞、安全技术、安
全管理等方面进行交流与合作，以实行国际间的信息共享、技术共享，最终达到联合防
范计算机网络上攻击的目标。
截止到目前，全球有 30个国家和地区的 CERT组织加入到了 FIRST组织中。
2002年 3月 CNCERT/CC与澳大利亚的 AusCERT就亚太地区各应急处理组织之间如何协
作处理安全事件进行了讨论，并合作草拟了建立亚太地区应急处理工作组(APCERT)的提议，
提交亚太地区安全事件响应协调会议讨论，形成了成立 APCERT组织的声明(征求意见稿)，
并决定成立工作组来负责对该声明进行修订。CNCERT/CC的代表刘欣然博士作为工作组成员
参与了该声明的后续修订工作。
2003年 3月 24～25日，在中国台北召开的 APSIRC2003会议上，APCERT声明获得了所
有成员的一致通过，正式宣告亚太地区应急响应工作组 APCERT的成立。各参会代表投票选
举了 APCERT指导委员会的成员单位，CNCERT/CC与澳大利亚的 AusCERT、日本的
JPCERT/CC、韩国的 KrCERT/CC、中国香港的 HKCERT、新加坡的 SingCERT、马来西亚的 MyCERT
入选，负责 APCERT日常工作。
在美国的推动下，全世界几十个国家和地区都成立了 CERT或类似的组织。1990年 11
月，在美国、英国等的发起下，一些国家的 CERT组织参与成立了“计算机事件响应与安全
工作组论坛”，简称 FIRST。亚太地区应急响应工作组称为 APCERT，作为 APCERT的指导委员
会成员单位，澳大利亚、日本、韩国和中国香港的 CERT组织代表参加了这次会议，他们在
应急体系的建设、应急方法的采用、职责和功能上虽然有着高度的一致，但地区特色依然浓
厚，存在很大的地区差异。但由于应急响应全球合作的特征，这些 CERT
组织间进行有效的沟通和经验交流，将对全球一体化地反击公共互联网威胁起到巨大的
作用。
从组织结构来说，这些 CERT组织无一例外是由该国家或地区的政府倡导成立，大部分
CERT组织的经费来源于政府，也有一些经费来自于信息安全培训和成员的赞助，他们一般
的任务在于进行互联网上的异常监测，及时发现异常流量并进行早期的预警，协调事件的处
理，通过公告和信息论坛的形式进行信息安全普及教育。某些国家还开展了内容监测，并通
过政府、ISP、公众、CERT组织共同参与的方式对紧急事件进行响应。
澳大利亚的 CERT组织(AusCERT)在澳洲重要基础设施的保护中发挥着重要作用，
AusCERT的 Mark McPherson先生认为，应急技术是 CERT组织最重要的内容，只有让成员单
位相信通过自己的技术能得到真实的好处，能在“黄金时间”内得到有效的预警信息，提前
预防，才能使 CERT真正发挥作用。目前，AusCERT的经费来自三方面：政府、成员单位和
信息安全普及培训。
中国香港地区的 CERT组织(HKCERT/CC)由香港生产力促进局运作，其主要职责则在于协
调处理和预防以中小企业为目标的网络攻击。工作重点在于协调，而不是研发。
HKCERT的梁兆昌介绍，对应急事件的协调可能比应急事件本身更重要，因为，协调是
为了保证当事件到来时能有效地沟通，确保事件的统一化处理。因此，HKCERT与各国的 CERT
组织保持着密切的沟通，通过研讨会、论坛以及应急事件描述与交换形式(IODEF)工作组的
交流，及时对各类攻击进行预警。
日本的 CERT组织(JPCERT/CC)除了上述一些职责外，还增加了信息安全技术普及和信
息安全趋势分析职能。JPCERT的 Yurie Ito女士介绍，JPCERT非常重视信息安全技术，目
前，来自不同的 ISP和厂商的 30名信息安全专家是该组织的专业顾问。此外，JPCERT还建
立了一个互联网扫描数据获得系统(ISDAS)，该系统已将几十个探针直接安装在自愿加入该
系统的用户端，随时监测互联网上的流量和内容异常，以便第一时间发现网络上的攻击。
而韩国的 CERT组织(KrCERT/CC)则在现有的基础职责基础之上，正在努力开拓一些新领
域的应急响应，KrCERT的 Jungu Kang先生介绍，目前 KrCERT正在开发对病毒自动进行分
类、统计的系统；开发在 P2P和无线网络领域里发展应急响应技术以及开发针对攻击的早期
预警系统。在公共互联网的应急响应方面，各个国家的 CERT组织的职责、任务、甚至包括
体系结构并不完全一致，国际上也并没有要求必须进行完全的统一。但是，这些 CERT组织
共同的目标是通过发展信息安全应急技术，对互联网攻击进行有效预警。
此外，各国 CERT一个共同的作法是密切保持国际组织间的合作，保持对攻击信息的有
效沟通，为此，正在发展中的紧急事件描述与交换形式(IODEF)就成为一项重要的内容，虽
然目前它尚未成为正式的标准，但显然，包括日本、韩国在内的一些国家的 CERT组织正在
采用它，由于信息沟通在应急响应中的作用日益重要，IODEF的价值就日益突出。但是，遗
憾的是 IODEF目前不适用于中文，这对 CNCERT/CC与国际交流将产生不利的影响，相信不久
之后这种情况会得到改观。
为了紧急应对公共互联网安全事件，各国的政府、运营商、企业、个人开始了全球总动
员！2003年 2月，信息产业部批准将 1999年成立的“国家计算机网络与信息安全管理中心
因特网应急小组协调办公室”更名为“信息产业部互联网应急处理协调办公室”。
2003年 7月 14日，中编办正式批复成立了国家计算机网络应急技术处理协调中心，这
是计算机应急响应的处理中心，简称 CNCERT/CC。
国内外现有安全事件应急响应组织大概可以分 5类：
1. 第一类是网络服务提供商的 IRT组织，如 CERNET的 CCERT，主要为 CERNET的接入
用户提供增值的服务；
2. 第二类为企业或政府组织的 IRT组织，如美国联邦的 FedCIRC、美国银行的 BACIRT
（Bank of America CIRT）等；
3. 第三类是厂商 IRT，如 Sun、Cisco等公司的响应组，主要为本公司产品的安全问题
提供响应和支持；
4. 第四类为商业化的 IRT，面向全社会提供商业化的安全救援服务；
5. 第五类是一些国内或国际间的协调组织如 FIRST、CN-CERT/CC等。
有些 IRT既是协调组织，同时又提供服务，如 CERT/CC。IRT组织不仅仅坐等安全事件
发生以后才去补救，未雨绸缪、防患于未然也是 IRT组织的重要服务内容。所以，一般还提
供安全公告、安全咨询、风险评估、入侵检测、安全技术的教育与培训、入侵追踪等多种服
务。就应急响应服务本身而言，由于它具有以下特点使得这一服务非常困难：
(1) 技术的复杂性与专业性；
(2) 知识和经验的依赖性；
(3) 事件的突发性强；
(4) 需要广泛的协调与合作。
应急响应相关术语
事件响应：对发生在计算机系统或网络上的威胁安全的事件进行响应。事件响应是信息
安全生命周期的必要组成部分。这个生命周期包括：对策、检测和响应，网络安全的发展日
新月异，谁也无法实现一劳永逸的安全服务。
应急响应计划：被设计用于在紧急情况、系统故障或灾难事件中在备用站点维持和恢复
包括计算机运行在内的业务运行的策略和规程。下图 16-3是应急响应计划过程图。
图 16-3应急响应计划过程
应急响应服务的目的是最快速度恢复系统的保密性、完整性和可用性，阻止和减小安全
事件带来的影响。
安全应急响应管理系统的建立
应急响应目标
随着 IT技术越来越多地应用到机构或公司的业务中，IT系统的应急响应功能变得更加
关键。因而 IT安全管理的主要功能就是采取足够的主动措施解决各类安全事件。安全事件
可能被许多不同的事件触发并破坏单个 IT系统或整个网络的可用性、完整性、数据的保密
性。IT安全管理系统要特别注重响应、处理安全事件，因为安全事件可能带来重大破坏。
那些引发或可能引发本地小范围破坏的安全问题应该就地解决，以避免加重 IT安全管理系
统的负担。
安全事件的处理最终是由 IT安全管理系统负责，并且是以保证以下各项为目标的：
（1）响应能力，确保安全事件和安全问题能被及时地发现并报告给适当的负责人；
（2）决断能力，判断是否是本地安全问题抑或构成一个安全事件；
（3）行动能力，在发生安全事件时基于一个很短的提示就能采取必要的措施；
（4）减少损失，立即通知企业内其它可能受影响的部门；
（5）效率，实践和监控处理安全事件的能力。
为实现这些目标，必须建立一个管理系统来处理安全事件。这时管理层有必要参与进来并最
终让管理系统发挥作用，以提高对 IT安全问题的认识，合理分配决定权，更好地支持安全
目标。
下面描述的步骤为如何建立一个管理系统来处理安全事件提供了一个建议
1．步骤 1安全指南内容
对安全事件的处理是 IT安全管理的一个方面，因此应该被列入安全指南及机构或公司的安
全策略中。这些文件必须包括用户和受害单位报告给安全负责人的安全事件及安全问题。除
此之外，还必须有对决断过程的描述并按照规定的过程动员员工。同时，安全指南内容也是
管理层支持 IT安全的一个证明。
2．步骤 2职责规范
本步骤中必须规定在安全事件发生时谁应该承担什么责任。比如，下面各工作组可能有这些
职责：
（1）IT用户：报告安全问题和安全事件。
（2）IT管理员：接收报告、采取初步行动，根据得到的报告判断是一个安全问题还是一个
安全事件，并将它提交高层。
（3）负责 IT应用人员：参与决策过程，根据自己对 IT应用要求的保护程度评估选择措施。
（4）IT安全员或 IT安全管理层：接收报告，判断是安全问题抑或安全事件，并采取必要
步骤。
（5）安全事件队伍：由 IT管理员，IT用户，IT安全员以及公关人员和可能的管理层。处
理安全事件。
（6）IT安全审计员：复查管理系统并评估安全事件。
（7）管理层：做最后决定。
这些职责必须被定义好并被有效实施。
3．步骤 3：处理安全事件的过程规则和报告渠道
为有效地处理安全事件，让那些受到安全事件影响的部门以正确而稳健的方式来做出反应是
很关键的，并且要立即将事件报告。因此必须定义必要的过程规则(包括保持镇定、报告责
任、提供到场环境信息的义务等)，并据此培训 IT用户，其中要特别注意确定好那些 IT安
全问题或事件的报告对象。
在发生安全事件时，那些准备采取的行动指示(比如，出现计算机病毒，内部人员操作数据，
外部黑客试图入侵等)可以提前起草好。一旦发生紧急情况，人们能够迅速地反应以减少损
失。由于这些准备工作并不是毫无作用的，因此应该将其纳入那些可能制定计划的相关部门
的工作中。
4．步骤 4：安全事件的报告提交策略
根据安全事件的处理规则，安全事件越关键，需要的授权就越大。极端情形下，这意味着必
须要及早报告给管理层，并使其参与其中以采取必要的措施，比如：禁止泄漏任何信息、报
警、采用另一种可实现的替代办法(可能成本较高)等。无论采用哪种方法，都要求提前制定
好提交策略，并制定在何种情况下要咨询何人的规定。
5．步骤 5：设置优先级
安全事件的产生，一般是各种不同的原因综合在一起达到一定程度时发生的结果，安全事件
产生的后果则会影响到不同的 IT应用领域，所以针对其采取的各种措施也应该根据应用领
域的不同设置不同的优先级。这种优先级的设定取决于系统保护需求、IT应用范围以及机
构或公司对应用系统的依赖性。因此正如确定保护需求一样，要求提前制定好优先级表，根
据安全事件导致的灾难后果顺序采取相应的应急措施。
6．步骤 6：调查和评估安全事件的方法
一旦收到与安全相关的非常现象报告，必须一开始就判断它是被看作本地安全问题还是会构
成一个潜在的损失更大的安全事件。在做判断之前，有很多因素需要被确定和评估(潜在的
和持续的损失程度、原因、哪个 IT系统受到影响、要采取什么样的即时措施等)。如果有必
要，应象提交策略中的规定那样，咨询上一级管理层。
7．步骤 7：针对安全事件采取补救措施
当采取必要的安全补救措施时，必须牢牢记住这些措施的实施往往有时间限制。因此，措施
本身也可能引发新问题。将采取的措施用适当的方式存档是很重要的。进一步说，假定时间
是人为确定的，还应当考虑如何处理这些人为因素。在某些情形下，可能要暗示当事人。
8．步骤 8：通知受影响各方
如果安全事件冲击的对象不仅仅限于机构、公司和企业内部个人，为控制损失，所有受影响
的企业内部各部门和外部机构都应该被通知到。为提高通知速度，应提早建立沟通渠道和执
行相关性分析。
9．步骤 9：安全事件的评估
为从发生的安全事件中汲取教训，应当规定评估安全事件处理过程的规则。这样可以对改进
安全事件的处理效果或对 IT安全概念有效性的理解做出结论。这里需要考虑以下几个方面：
（1）响应时间；
（2）对报告渠道的了解程度；
（3）提交策略的有效性；
（4）调查的有效性；
（5）通知受影响各方的办法。
10．步骤 10：安全事件发现措施的使用
安全事件越早发现和报告，采取的对策就越有效。应该采用所有可以得到的自动发现方法以
减少因为依赖人而带来的响应延迟。反病毒程序和日志/入侵探测分析系统就是这类方法的
两个实例。
11．步骤 11：有效性测试
为了衡量一个安全事件处理管理系统的有效性，并且加强对这些管理任务的必需演练，应该
进行一些演习和假想训练。由于这可能会需要大量的人力资源、干扰正常工作，因而必须限
制在重点区域内进行。
应该在安全事件处理资料中保留上述步骤执行的结果。对这些结果还应当定期更新，并以合
适的方式通知各利害方。
其余方面的控制：
（1）是否对所有不同类型的安全事件制定好相应的处理过程和规则？
（2）制定的过程规则和上报渠道是否以文本形式加以说明？
（3）员工都知道这些吗？
应急响应策略
1.策略制定
计算机和信息安全开始于策略，结束于策略。信息安全策略是计算机和信息安全必需要
素的最高层次的阐述，它包括建立安全保障需要的最基本的要求和必要的基础设施。策略里
通常告诉用户（可能是系统管理员）该做什么和不该做什么，并且明确了被发现没有遵守该
规定应受到的惩罚。好的策略通常会表明组织对安全的态度—组织是否愿意冒着较小的安
全风险让用户有较大的访问自由，或者是宁愿宁愿用户使用不方便，甚至丧失某些功能和性
能也要保障较高安全，或者居于二者之间。
策略是成功的计算机和信息安全工作中的一个重要部分，没有明确的要求通常会带来厄
运。以下几类比较重要的事件响应要求应当包含在信息安全策略里：
批准建立事件响应机制（表明这是组织要求的功能）
事件响应的任务或者目的，以及范围
(如果需要) 给事件响应的授权。
对事件响应的限制（在对事件响应的过程中什么是允许的，什么是不允许的）
与法律部门的关系（是否应当让法律执行部门介入，如果是，在什么时候）
只是简单地写一个规定当然并不能起多大作用，但事实上却是治疗“遗忘规定”的良方，
争取受影响的人的支持对扫除障碍很有必要。特别是要得到高层管理人员的批准。如果没有
高层管理人员的支持，策略注定要失败。让一个规定起作用的一个最好的策略是让受到影响
的人看到来自高层管理人员的支持。
2. 策略更新
有一个策略条文很重要，但除去那些已经过时了的策略。因此定期检讨一个组织的信息
安全策略，特别是（在当前情况下）与事件响应相关的策略就很重要了。如果需要修改，就
应当进行相应的改动。新的事件类型不断出现，就要求对与事件响应有关的规定进行修补；
有的事件响应的努力并不成功，就要求对情况进行分析，看某些要求是否合适。
3. 事件的分类及处理优先级
并不是每个安全事件都是被优先考虑的。一个小型病毒的发作只需要对几台 PC机进行
杀毒就可以了，这与能蔓延至整个公司电子邮件服务器的大型病毒完全不同。一些针对网络
服务器进行扫描及阻塞服务器的“小型脚本语言”对服务器的影响，无法与一个 DOS 攻击
对该系统产生的影响相比。
要想制定一个能适用于所有情况的优先权及严重程度的标准是不可能的。一个安全事件
的相对重要性是依据其对工作平台及操作系统的影响再加上其在商业上产生的影响而决定
的。从理论上讲，由于使服务器与外网的断开所造成的损失可能会比病毒造成的损害更大。
作为危险因素分析的一部分，公司应对他们的信息资源及相对有价值的资源有所认识。
这是进行优先权分析的第一步。高价值的资源应被分配到高优先权范围。
安全事件的严重程度及范围都应与处理方法相适应。只影响一台 PC机的病毒与影响整
个机构所有机器的病毒完全不同的。很少扩散的病毒危险性小于以随机地址扩散而损坏数据
库或电子邮件的病毒。
例如，机构可以定义如下四个级别的严重程度。
1、 第一级别为单一地点（物理上的或非物理上的）及相对冲击较小的事件。这种情况
包括小型病毒安全事件，它不会对数据库造成损坏以及对当地文件服务器上帐户的
非授权操作。
2、 第二级别为对运行造成严重损害的单一地方安全事件。例如，个人帐户受到攻击，
或是关键设备被盗。
3、 第三级别为影响两个或两个以上地点的安全事件（同样，定义包括物理上的及逻辑
上的地点），但其只造成较小冲击。例如，网络或电子邮件系统上的无损害病毒的扩
散。
4、 第四级别为对多地点造成巨大损害的安全事件。这需要进行强制处理并定位于高优
先权状态。例如：对重要的全球申请系统的非法入侵。
其他的模式可根据其他机构的具体情况进行调整。例如，物理安全部门可以把物理上的
资源作为优先考虑的对象，并按它们的价值进行调整。他们也可以按严重程度进行分类，并
可以同信息资源相匹配。如果公司有一个恢复商业运作或灾难恢复的计划，他们可以以恢复
作为目的来进行优先权的分配。一个已投入使用并为管理者所接受的模式，远比一个新模式
的作用效果要好得多。
很明显，对一次安全事件所带来的后果进行完全量化是不可能的。在前面的例子中，牵连到
网络服务器的安全事件，其严重程度可以归为第二级别，但对商业性的企业来说，其潜在冲
击可使其具有更高优先权。当需要对多个安全事件进行响应时，以一种模式作为依据可以帮
助事件响应组对优先资源进行更好的工作计划和安排。
应急响应责任
当制定应急响应责任的详细规定时，应该假设安全事件发生时的活动顺序。涉及到的工
作组和个人的任务及职责也应该被确定下来，并制定好适当的强制执行措施。下面的例子针
对一些典型的受影响群体，给出一些做法。
1. IT用户
任务：一旦觉察与安全相关的异常事件时，他们必须遵守适当的过程规则并报告这些异
常事件。
职责：IT用户必须决定在当时的情况下采用何种合适的报告渠道。
义务/指导：每一位 IT用户都有义务按照本单位的安全指南来报告任何与安全相关的异
常事件。此外，所有的用户都应该得到一份书面的指令性文件，用以指导他当发生异常事件
时应该采取的行动，以及应该向谁汇报等事项。
2. IT安全管理员：
任务：接收与其负责的 IT系统有关的异常事件报告。报告决定是立即采取行动，还是
按照提交策略向上一级报告。
责任：一个 IT管理员必须能够确定是否真的产生了安全问题，他是否可以独立解决，
是否需要根据提交计划立即咨询其他人，以及他应该通知谁等。
义务/指导：应该在职位描述及安全事件处理策略中指定。
3. IT安全员/IT安全管理层
任务：IT安全员接收安全事件报告。负责调查和评估安全事件，并在其职责范围内选
用适当措施进行处理。如果有必要，他负责组建安全事件处理小组或将问题提交给上级管理
层。
职责：被授权对安全事件进行评估，并可将事件提交给高级管理层。除此之外，他可以
在授权范围内利用财务和人力资源独立处理安全事件。
义务/指导：根据 IT安全管理层制定的“安全事件处理策略”，所有的 IT安全员都承担
其处理安全事件的任务和职责。
4. IT安全审计员
任务：IT 安全审计员必须定期检查安全事件管理系统的有效性，并参与评估安全事件。
职责：在管理层同意下，启动和实施预定义的检查。
义务/指导：见工作职责描述和“安全事件处理策略”规定。
5. 公共关系/信息发布部门
任务：在发生严重安全事件的地方，除了信息发布部门之外，其他任何部门和个人都不
能对公众泄漏任何信息。这样做的目的并不是为了掩盖事件或者降低事件的严重程度，而是
要以目标化的方式解决问题，避免相互矛盾的信息给企业带来的形象损害。
职责：信息发布部门必须和专家一起准备与安全事件相关的信息，在发布之前必须得到
高级管理层的同意。
义务/指导：见工作职责描述和“安全事件处理策略”规定。
6. 代理/公司管理层
任务：严重安全事件发生时，应该通知管理层。如果有必要，管理层要作出决定。
职责：负总体责任，并对上述各工作小组负责。除此之外，当怀疑有犯罪活动时他们可
以报警，起诉罪犯。
义务/指导：管理层必须批准“安全事件处理策略”和基于策略的安全应急计划，作为
计划的一部分，各管理层应明确其在安全事件处理中的角色。
7. 安全事件小组
除了上述工作小组之外，当有困难或发生严重的安全事件时，必须在有限的时间里组织
安全事件应急小组来处理安全事件。这一般由 IT安全员负责实施。
即使安全事件应急小组只是为满足特殊的安全事件需要而设置的，但为保证尽可能快地响应
安全事件，其成员必须被提前安排并被告知分配的任务。安全事件应急小组的成员应该被授
权在其职责范围内完成其相应的任务。整个过程一定要有书面的详细规定，并经管理层授权。
特别要注意的是：必须指定小组的负责人。
根据安全事件的类型，安全事件应急小组的成员应包括以下各部门的成员：
（1）机构/公司管理层；
（2）IT安全管理层/IT安全员；
（3）IT部门的领导；
（4）信息发布部门；
（5）数据保密员；
（6）法律顾问；
（7）工会。
如果有必要，还要召集其它部门，比如：专家部门(部门负责人，IT安全员)、IT管理
员、提供现场服务的部门，一般服务部门，组织，人力资源部门及消防员等。
必须事先对安全事件带来的一些额外工作如何处理做明确的阐述，比如是否需要根据安全事
件处理时间的延长进行加班、周末工作等。要采取措施确保在正常工时之外，若有必要，应
急小组可以使用办公楼。其余控制：
（1）有没有指定安全事件应急小组；
（2）是否对各成员执行的任务进行讲解和说明；
（3）由什么人来协调这些措施；
（4）灾难恢复管理小组的组成最近的一次变化发生在何时。
安全应急程序规则及报告渠道
1. 处理规则
许多安全事件仅仅是因为决定得过于仓促，因而采取了不合适的应对行为进而演变为严
重问题。比如那些可以帮助我们了解整个事件的数据被删除等。必须明确区分应用于所有可
能安全事件的一般性规则与 IT特有的规则之间的不同。可以为所有类型的与安全相关的异
常现象规定以下通用的过程规则 ：
（1）所有当事人应该保持镇定并不要仓促采取行动；
（2）对出现的异常现象应该按照应急计划立即报告；
（3）除非授权人要求，否则不能采取应对措施；
（4）所有现场因素必须被坦率、透明、无遮掩地解释，以尽量减小损失；
（5）应根据个人经验，对受影响的组织内外各方的损失潜在程度、后续损失结果进行
初步评估；
（6）没有经过授权，有关安全事件的信息不能泄漏给第三方。
必须以适当的方式将这些通用的处理规则告知机构或公司里的所有可能受到影响的员工。除
此之外，对那些已经受到影响的人员，尤其是那些当发生安全事件时需要他们做出最早决定
或采取最早措施的人，要为他们提供相应的处理规则，这些人中包括 IT管理员、IT应用负
责人和 IT安全管理员等。
2. 报告渠道
一旦制定好处理规则，报告渠道也要确定好。我们建议按下面的线索开始进行：
（1）如果发生不可抗力比如火灾、水灾、停电、入侵和盗窃，要告知相关的本地服务部门(消
防部门、现场技术服务、入口控制员工、安全保卫等)；
（2）如果发生硬件故障或 IT系统操作出现异常，应该告知具体负责的 IT管理人员；
（3）如果怀疑是故意行为而且不能用任何别的方法解释(比如数据操作、未授权操作、怀疑
有间谍或破坏)，必须告知 IT安全员或 IT安全管理层。
尤为重要的让全体员工知晓在发生各种安全事件时该与谁联系以及使用什么报告渠道，比如
在内部黄页和内部网上包含相关人的名字表、电话号码和电子邮件地址。无论如何，应该使
得员工管理的手续不困难，过程不冗长，必须针对这些工作建立快速、安全的沟通联系方式，
沟通双方的真实性必须得到保障，有关怀疑事件的报告信息也必须保密。要告知所有员工有
关安全事件的信息只能透过 IT安全管理层透露给第三方。要经常对处理规则进行演练，以
检查这些处理安全事件的规则是否合适、是否易于实现以及是否为所有员工所了解。有关安
全事件的经验显示：一个良好的操作环境、一个方便的提示和一个快捷便利的安全事件报告
渠道对于及时、有效地处理安全事件是多么的重要。
要把处理规则和报告计划告知给所有受影响的员工，一个比较有效的方法就是提交一个由管
理层签字的信息清单，在上面概括了最重要的信息，可以将其放在工作间作或内部网上。例
如这种信息清单可以放在 IT系统保护手册光盘的帮助一栏里。建议不仅仅用电子版发布它，
还需要利用其他途径让员工们清楚了解，因为电子版本也可能受安全事件影响。当组织内部
发生变化时，所有关于潜在安全事件的信息都将被及时更新，这样就可以保证处理规则可用、
报告渠道畅通。
3. 其它控制：
（1）对各种不同类型的安全事件是否定义了处理规则；
（2）是不是所有人都了解；
（3）这些信息最近一次更新的时间。
安全应急响应管理系统的有效性测试
为保证安全应急响应管理系统的有效性，需要经常定期对管理系统进行检查，并对其中
的措施进行测试。检查内容包括：
（1）它们是否被涉及的员工所了解？
（2）在发生安全事件、应用不能正常运行时，它是否可行？
（3）它们是否能被纳入操作过程？
为测试管理系统的效率，应该模拟损害事件以检查定义的过程是否能工作，或者它是否
实际可行。如果不实际可行，应该作适当的修改。为测试这点，要进行公开和未公开的演练
实践。当演练实践在未公开状态下进行时，要保证在任何情况下都不能触发可能导致损害 IT
系统、数据或其它系统的动作，不管这种损害是永久的还是修正起来很困难的。
在开始演练实践前，需要认真考虑提前通知谁。要保证演练实践是经过管理层授权的。有些
时候不通知某些特定的人群也是有益的，比如，入口控制人员或管理员。但是，必须采取措
施防止情况失控。应避免惊动警察、消防部门，避免切断机构或公司的网络连接。
例如：
（1）可以给企业或机构的总机打电话，假装成一个已进入内部网的黑客。另外一个方法是，
你可以假装是记者，声称听说黑客已经进入内部网并已拷贝了秘密数据，同时还要给那些发
生安全事件时应该被召集的人，比如信息发布部门或 IT部门的领导打电话。这么做的目的
是试探是否会出现内部混乱，或者，在这种情况下是否已经有目的地采取了合适的行动。
（2）在一天之内可以对感染计算机病毒时采取的所有动作及报告渠道进行检测。不必提前
通知所有相关人员和部门，只是在他们需要知道这一事件的最后一刻通知他们即可。
其余控制：
（1）最近进行过什么演练实践？
（2）这些演练实践提前得到了管理层同意吗？
应急响应流程
应急响应一般的流程是准备检测抑制根除恢复跟踪，
1. 准备
准备就是要做好安全保障工作，从微观上讲就是一要建立应急预案，其中包括准备高效
的事件处理流程，完善的信息发布和汇报流程；其二要建立应急组织，要获得处理问题必须
的资源和人员，同时指定一个应急责任人给予必要的资源和权力；其三就是要建立应急响应
活动的技术平台，通过扫描、风险分析、打补丁增强原有系统的安全性，同时建立全局监控
系统。
从宏观上讲，要建立协作体系件，建立数据汇总分析的体系和能力，制定相关的制度规
范。
2. 检测
检测是确定事件是已经发生还是在进行当中，从微观上讲第一要确定事件的性质，其影
响的严重程度及计划采用什么样的专用资源来修复？第二要作出初步动作和响应，其中包括
选择检测工具，分析异常现象，激活审计功能记录所发生事件，提高系统或网络行为的监控
级别最后估计安全事件的范围。
从宏观上讲，要通过汇总，确定是否发生了全网的大规模事件，确定应急等级，以决定
启动哪一级应急方案。
3. 抑制
抑制就是要限制攻击的范围，同时限制潜在的损失和破坏，从微观上讲第一要初步分析，
重点是确定适当的封锁方法，包括将网络断开；修改防火墙和路由器的过滤规则；拒绝来自
发起攻击的主机的所有的流量；封锁或删除被攻击的登录账号；关闭被利用的服务；完全关
闭所有系统等。第二要确定封锁操作带来的风险，第三可列出若干选项，讲明各自的风险，
由服务对象选择。
从宏观上讲，要确保封锁方法对各网业务影响最小，通过协调争取各网一致行动，实施
隔离，汇总数据，估算损失和隔离效果。
4. 根除
根除就是要寻找长期的补救措施，找出事件根源并彻底根除，从微观上讲第一要详细分
析，确定原因；第二要分析漏洞，并修补漏洞；第三重新审视安全保障策略，包括修改安全
策略，加强防范措施等。
从宏观上要加强宣传，公布危害性和解决办法，呼吁用户解决终端的问题，加强检测工
作，发现和清理行业与重点部门的问题。
5.恢复
恢复就是要将被攻击的系统由备份来恢复，从微观上讲第一是要把所有受侵害或被破坏
的系统、应用、数据库等彻底地还原到它们正常的任务状态；第二是安全措施实施后，重新
数据备份；第三是使服务重新上线，持续监控。
从宏观上看要持续汇总分析，了解各网的运行情况，根据各网的运行情况判断隔离措施
的有效性，通过汇总分析的结果判断仍然受影响的终端的规模适当的时候解除封锁措施。
恢复会涉及以下几个流程：
(1) 系统恢复
① 从备份中恢复系统。
有的安全事件，例如恶意代码事件，可能需要依靠备份进行全面的操作系统恢复方可根
除。在这种情况下，有必要首先检查备份的完整无误性。一般应该使用在系统遭受攻击前所
制作的最新备份。
② 确保恢复过程中不含有已遭修改的代码。
如果在系统受到攻击前，没有进行备份，那么必须重新装载系统，使用补丁，或是使用
一个未受攻击的近似系统的备份在系统恢复过程中应尽一切可能使其不含有已被修改的代
码。
(2) 检验系统恢复
一旦系统恢复确认以后，检验一下操作是否有效，系统是否已回到正常运行状态。确认
理想的情况是专门有一个系统测试计划对系统进行评估。通常情况是系统照常运行任务，同
时应用网络记录器和系统日志文件对其进行监控。有时，用来弥补某个漏洞的补丁或技术会
导致系统的运行情况与发生安全事件前有所不同。
(3) 决定何时恢复运行
由于不确定是否已清除所有的恶意代码，可能会延长恢复时间。
建议由受影响系统的管理层和系统管理员来决定恢复运行的时间。如果可能，系统可以断线
一至二天，以便有时间对系统进行升级或安装补丁。
(4) 监控系统
由于后门与恶意代码有可能隐蔽得很好，难以觉察。 一旦系统重新运行后，应该继续
实施监控，探测先前逃过检测的后门程序。
6. 跟踪
事件之后的跟踪活动是响应安全事件的一个重要环节，目的在于从中吸取经验教训，以
完善将来的工作。经过这一环节的机构组织将会大大增强今后处理安全事件的能力，及时的
跟踪活动还有助于尽快将攻击者绳之以法。
(1) 跟踪报告
跟踪报告是迅速吸取经验教训的好办法。
① 尽快开始
如果等到事件结束几星期后再着手，你将发现人的记忆和美酒不同，不会随着时间的延
长而愈浓愈香。
② 将任务分配给现场处理小组
为了从安全事件中获取尽可能多的经验，许多站点将起草此类报告列为处理安全事件的
必要步骤之一。如果没有这份报告，则工作就没有完成。
③ 填写表格
应鼓励涉及此事的各方一起来审核安全事件处理的草案，提交一份事件总结报告，并和
涉及此事的各方一起来审核。
④ 尽可能达成一致意见
听取来自各方的反应、不同意见、补充意见和建议。鼓励使用电子方式来交换意见，这
样可以尽快的处理完。把来自各方的不同意见记录下来。
⑤ 举行经验交流会
把从各方收集来的意见、建议分别归类，这样可以计划举行一次经验交流会。会议的主
题应紧紧围绕整个事件的处理和处理方法的改进。
最后就整个事件的处理做出总结，在这个总结中应包括整个事件处理的支出、时间和此
事产生的影响。把总结递交给管理层，并承诺此事件就此结束。
⑥ 把相关建议提交给管理层
把从总结经验交流会上得出的结论和修改意见，提交给管理层。这其中应包括整个事件
的评价、计划和此事造成的影响以及采取了什么措施，没有采取什么措施。
⑦ 实施获得批准的措施
一旦方案通过就应严格加以执行。
事件响应通用方法指导
1. 安全应急事件的提交策略
当确定好安全事件的职责，所有相关人员都知晓时间处理规则和报告渠道后，下一步应
确定收到报告后如何提交。
首先，收到安全报告的人必须调查和评估它。如果确实是安全事件，就要采取进一步措施。
下面列出一些问题：
（1）出现什么紧急情况需要提交，即提交给哪些部门，通知哪些工作人员；
（2）什么事件需要立即提交？
（3）在什么环境下合适提交？
（4）什么时候提交 (立即、明天、下一个工作日)？
（5）用什么样的方式提交？
这些问题的答案必须在提交策略中规定好并让大家清楚。可以分以下三个步骤制定提交策略：
步骤 1：提交渠道的规定
在规定由何人负责处理安全事件后，提交渠道的规定中应该明确报送人机器相应的报送对象。
当我们划分好相关组织结构层次后这很容易做到。需要注意的是：不仅要考虑常规提交渠道，
而且还要考虑相关人员不在时的备用渠道。
步骤 2：提交的决策对象
在本步骤中首先应确定在做进一步调查或评估之前需进行什么样的提交，详见下面表格
16-4示例：
然后应该规定在什么环境下要求提交。提交的基础可能有以下：
（1）预计的损失程度超过报送对象的职责范围；
（2）控制损失的成本和资源超过了其权限；
（3）安全事件的负责程度超出了其职责能力。
表 16-4
事 件 类 型 立即报送对象
感染电脑病毒 病毒防治人员，管理员
火灾 入口控制员，消防队
故意行为或怀疑有犯罪行为 IT 安全员
怀疑工业间谍 IT 安全员, 执行董事会
必须报警或犯罪起诉 执行董事会
存在威胁损害 执行董事会
步骤 3：提交方式
报送过程中向上一层提交方式的选择如下：
（1）个人口头报告；
（2）书面报告；
（3）E-mail；
（4）电话、手机；
（5）密封函件。
还应该规定在什么时间段里完成报告。例如：
（1）立即提交：一个小时内；
（2）立即采取措施：一小时内；
（3）事件还在控制中，但要求通知中上层：下一工作日。
提交报告应该通知所有可能的安全事件报送对象。为了控制安全事件的继续发展，通常要求
立即采取行动，还可能要求从其它项目中召回人员或在非工作时间给他们打电话，所以对此
类问题的处理也必须在安全应急计划中加以考虑，并以文字的形式加以规则化，保证员工能
被及时呼叫到。
其它控制：
（1）最近什么时候更新过提交策略？
（2）在演练中试过提交渠道吗？
指定安全应急响应的优先级
经验表明，安全事件是多种因素的综合结果，潜在威胁一般涉及好几类(比如，人员身
体受损、外部关系的负面影响、财务后果等)。因此尽早建立问题处理的优先级就非常重要。
这种优先级决定了事件处理的顺序。
优先级的分配紧密依赖于组织内的环境。要分配优先级，必须考虑下面问题：
（1）哪类损失和组织相关；
（2）在每个类别中，按什么顺序修补损失。
要回答这些问题，首先应根据 IT系统最低保护要求确定保护程度，这将十分有用。而确定
保护程度的过程就定义了与组织相关的损害类别，如：
（1）与法律、规章或合同冲突；
（2）对信息自决权的损害；
（3）对人员身体的伤害 ；
（4）对企业职能的损害；
（5）外部关系的负面影响；
（6）财务后果。
作为详细说明保护程度的一部分，在每个损害类别中定义了损害程度。例如：损害类别“财
务后果”中的损害程度：
表 16-5
损 害 类 别 财 务 后 果
损害 / 损失 = 中 损害或损失小于 DM 25,000
损害 / 损失 = 高 损害或损失介于 DM 25,000和 DM 5 百万之间
损害 / 损失 = 很高 损害或损失大于 DM 5 百万
利用上面的损害类别列表，可以按下面的描述分配优先级。损害类别列在表中第一列，随后
列出三种损害/损失级别：中、高和很高。每个损害类别和损害/损失都分配一个优先级。分
配优先级的一种方法是使用优先级分级系统，比如：
1 = 特别重要
2 = 重要
3 = 相对重要
另一种方法是给每个损害类别分配等级。
示例：
这个示例中的组织是市政机构，通过互连网为公众提供服务。公众可以用 E-mail询问
市政机构他们的案子进展如何。作为信息服务，该市政机构提供互连网服务器的使用。下表
说明了该机构安全应急事件优先级的分配结果：
表 16-6
损害类别 损害/损失=中 损害/损失=高 损害/损失=很高
法律、规章或合同冲突 2 2 2
对信息自决权的损害 1 2 2 1
对信息自决权的损害 2 2 1 1
人员身体伤害 3 3 2
义务绩效的损害 3 2 1
财务后果 3 3 2
分等级结果:
表 16-7
损害类别 损害/损失=中 损害/损失=高 损害/损失=很高
法律、规章或合同冲突 13 12 11
对信息自决权的损害 8 6 3
对信息自决权的损害 5 2 1
人员身体伤害 15 14 7
义务绩效的损害 17 9 4
财务后果 18 16 10
优先级的分配必须得到管理层的批准方可生效，批准后必须通知参与安全事件处理决策的相
关人员。
安全事件发生后，利用下表优先级的分配，一旦安全事件被调查并评估后，就会对预计
的损害作出一个估计，随后产生的损害数据被分配到已知的损害类别中，然后一起归类为“中”、
“高”和“很高”。优先级分配表指明了处理每种损失类型的顺序。但是，前面的优先级分
配只能看作是一个初步指南，它可能因个案的不同而不同。
例如：
表 16-8
损害类别 损害/损失=中 损害/损失=高 损害/损失=很高
法律、规章或合同冲突 D1
对信息自决权的损害 1
对信息自决权的损害 2
人员身体伤害 D2
义务绩效的损害 D3
财务后果 D4
假定在上面的例子中，有黑客成功地闯入互连网信息服务器，抹黑市政机构的形象。这种行
为立即被发现，并通知 IT安全管理员，安全管理员对以上损害进行评估。评估结果可能如
下：
基于以前的优先级分配，损害个案 D1到 D4被分配以下优先级：
优先级分类方法：D1 = 2, D2 = 3, D3 = 1, D4 = 3
优先等级方法：D1 = 13, D2 = 15, D3 = 4, D4 = 18
在这两种情形中，在准备处理其它所有类型的损害之前，损害限制工作很清楚要集中在损害
案例 D3 (外部关系的负面影响)上。为限制对外部关系的负面影响，在采取其它所有措施前，
应该首先将被入侵的互连网服务器与网络断开。如果给外部关系的负面影响这一损害分配一
个低优先级，而给因破坏市政机构的完成工作的能力分配一个高优先级，那么断掉互连网服
务器就不会被看作是需要立即采取的措施。
其它控制：
（1）管理层同意优先级的分配？
（2）优先级的分配是否已通知安全事件处理管理系统的所有决策人？
（3）优先级分配最近在什么时候更新过？
安全应急的调查与评估
不是所有的安全事件都能被立即发现，尤其是对 IT系统的恶意攻击，经常是在事件发
生数天或数周后才能被发现。误报也很常见，比如软件或硬件故障被错认为是计算机病毒。
无论如何，为了调查和评估与安全相关的异常事件，有必要进行一些初级评估，包括：
（1）弄清楚 IT结构和 IT网络 ；
（2）弄清楚 IT系统的联系人和用户 ；
（3）弄清楚 IT系统上的 IT应用 ；
（4）定义 IT系统的保护要求 。
在 IT系统保护手册的第一阶段进行这些调查。IT安全管理也需要得到这些结果。在收到报
告后，根据对结果的评估得到信息，并快速决定哪些 IT系统会受到影响，会涉及到哪些 IT
应用，有何保护要求。同时，由于知道联系人，可以迅速找到他来帮忙做出适当的决定。当
有高级保护要求的 IT系统或 IT应用受到影响时，应该被看作安全事件，并实施预先定义好
的步骤。另一方面，如果只有需要低级保护的 IT系统和 IT应用受到影响，试着就地解决安
全问题即可。如果安全事件显然有很严重的后果，并且相当复杂，应立即找到安全事件应急
小组，不要有任何延迟，这样处理可能更合适。
调查和评估安全事件的第一步是弄清楚下列因素：
（1）安全事件可能影响什么 IT系统和 IT应用？
（2）通过 IT系统网络还会产生后续的损害吗？
（3）哪些 IT系统和 IT应用绝对不会受到损害和后续损害？
（4）安全事件导致的直接损害或后续损害程度如何？应特别留意各种 IT系统和 IT应用之
间的相关性；
（5）能触发安全事件的可能因素；
（6）安全事件发生在什么时候，在哪个地方？由于在探测到安全事件时它很可能已经发生
一段时间了，因此维护好日志文件在这儿非常有用，但要保证它们没有被入侵；
（7）是否只有内部 IT用户受到安全事件的影响？或者外部第三方也受到影响？
（8）有多少关于安全事件的信息已经被泄露给公众？
如果安全事件已经引起严重的后果，它必须要被提交给上一级管理层。澄清这些因素后，必
须确定可选方案，方案中将包含立即措施和补充措施。在这儿也应该考虑从前确定的优先级
分配，还必须对实施这些步骤所需的时间、解决这些问题和恢复正常运作所需的成本和资源
进行估计。如果损害程度、修复所需时间和成本超出预定限度，在做任何决定前，将问题提
交给上级，并与决策层进行磋商，以选择哪种措施。根据上面列出的提纲对安全事件所做的
结构化调查和评估，会成为各种各样的可以利用的选项。
其它控制：
（1）接收安全事件报告的人员和上级能否获得基于保护需求而生成的必要的决策信息？
（2）有没有支持安全事件评估的方法？比如分析日志数据的工具。
与安全应急有关的补救措施
一旦找到导致安全事件的原因，就要选择并实施针对它们的应急措施。首先要控制事件
的继续发展并解决问题，然后再恢复事务状态。
1．提供必要的专业知识。
为查明和处理安全方面的弱点，必须拥有相关的技术知识。因此要么培训员工，要么找专家。
基于此，要准备一份联系地址表，包含各领域的内外部专家，这样就可以直接去寻求他们的
意见，不 用再耽误时间。外部专家包括：
（1）计算机紧急响应小组(Computer Emergency Response Teams ，CERTs) ；
（2）牵涉的 IT系统厂商和销售商；
（3）应用安全系统的厂商和销售商，比如反病毒、防火墙和访问控制等；
（4）专业安全专家组成的外部顾问组。
2．安全恢复的运作
要去除安全弱点，首先应将这些弱点所涉及的 IT系统与网络断开连接，然后再将那些
能提供已发事件性质和原因的信息文件，尤其是所有相关的日志文件做备份。由于整个 IT
系统应该被视为不安全或已经被入侵，所以要检查操作系统和所有应用是否已发生改变。除
了程序之外，配置文件和用户文件也应该被检查以防被操纵。在这里使用校验和程序比较合
适。这预示着，有关的校验和程序应该被事先确定，并且已经被永久保存（记录于写保护数
据介质上）。比如为保证敌方留下的特洛伊木马已被删除，原始文件应该从写保护的数据介
质中恢复。这里要注意的是，所有的与安全相关的配置文件和补丁也要重新恢复。在将备份
数据重新导入这些文件时，必须采取措施保证这些数据没有受到安全事件影响，比如，没有
被计算机病毒感染。另外一方面，检查数据备份有助于确定攻击或计算机病毒感染是什么时
候发生的。
在做数据恢复操作之前，要改变所有涉及到的 IT系统的口令字。这也要包括那些还没有直
接受到影响，但是攻击者可能已经得到用户名或口令字信息的 IT系统。要假设系统已经恢
复到安全状态，并还会受到进一步的攻击。由于这个原因，要使用合适的工具对 IT系统，
尤其是网络连接进行监控。
3．文档
在处理安全问题中的所有动作都应该被尽可能详细地记录归档，以便实现下列目标：
（1）保留发生事情的细节；
（2）能够追朔发生的问题；
（3）能够修正因为匆忙行动可能带来的问题或错误；
（4）在已知的问题再次发生时能迅速解决；
（5）能够消除安全弱点，准备预防措施；
（6）如果要提起诉讼，便于收集证据 。
这种文档不仅包含有关行动的采取、时间的描述，也包含受影响 IT系统的日志文件。
4．对故意行为的反应
当入侵者发起安全事件时，首先要决定是静观攻击还是尽快采取措施。当然也可以试图去抓
住入侵者的“黑手”，但是可能会冒很大的风险，因为在你试图抓住对方的同时，对方可能会
破坏、入侵或读取数据。安全问题的调查结果表明，这种情况在组织内部经常发生，它可能
是因为忽视、不合适的工作过程或技术问题而造成的，也可能是没有仔细观察安全措施或故
意行为的结果。在因为内部原因产生问题的地方，必须调查清楚触发的原由。问题经常起源
于不适当或不完整的过程。因此要对过程进行修改，或者补充其它措施，比如，技术方面。
如果因为故意行为或忽略而产生安全问题，应该采取适当的纪律措施加以控制。
5．其余控制：
（1）安全专家名单的最近更新时间；
（2）以前有没有观测过由内部人员发起的故意攻击行为？
通知受到影响的各方
当发生安全事件时，必须通知所有受其影响的外部和内部各方。这为那些受安全事件直
接影响的部门和机构采取对策提供了方便，对于处理安全事件相关信息的各方协助预防或解
决问题尤为重要。如果有必要，还应告知公众，尤其是在信息已经泄露出去的时候。针对特
殊的安全事件，必须制定出一个关于通知机制、通知谁、谁来通知、用什么顺序以及通知的
细节到什么程度这样一个清晰、明确的规定。在这个规定中，要采取有效措施保证安全事件
的信息只能由指定的负责人发布出去，比如 IT安全管理层或信息发布机构。谁可以接收信
息或接收到何种细节程度，自然主要取决于技术背景。所发布的信息应该是正确的，否则会
引发混乱、错误评估和形象损害。下面给出一个关于信息分发的典型例子。
1．内部
如果还不清楚安全事件是否发生，或者严重到什么程度，应在内部询问受到潜在影响的
员工，检查他们的工作区，是否有异常现象。如果已经知晓处理安全事件的对策，应该立即
告知有关部门通知他们应该做什么，以尽量减小安全事件的影响或恢复安全运作。还应该考
虑以下各方：
（1）IT部门领导；
（2）有关的专家部门领导；
（3）IT用户；
（4）IT管理员；
（5）IT用户服务商；
（6）现场技术服务人员；
（7）监管人员；
（8）内部安全人员；
（9）入口控制人员。
2．外部
如果安全事件冲击的对象不仅仅限于组织内部，则应该告知所有受影响或可能受影响的
外部各方所发生的安全问题、必需的对策以及如何限制影响。如果有关信息没有被及时传达
给受影响的各方，则事件真相出来后，组织与外部各方基于信任的现有合作关系可能会遭受
永久性的破坏。需要通知的外部各方应该考虑：
（1）客户；
（2）供货商；
（3）自由工作人员；
（4）分包人；
（5）IT服务供应商；
（6）有通信联系的各方；
（7）软件开发公司；
（8）网络操作员。
有时还可能报警或采取法律途径来解决问题，这取决于安全事件的类型。
3．公众
在发生严重或复杂的安全事件时，有必要告知公众真相，但是只能通过信息发布机构对
新闻媒体发布消息。需要注意的是：应要求信息发布机构使用恰当的语句来描述安全事件、
损害程度、必要对策并已通知的各方，以免引起混乱。但是，向公众提供的信息不能太具体，
以避免鼓励类似的攻击。同时要注意任何特别关注安全事件相关信息的人的身份，保证罪犯
不能得到他们攻击成功的实时结果。
4．IT安全团体
如果查明安全事件是由于还不了解的安全弱点引发的，那就应该通告各方并警告其在安
全方面的弱点，而不是隐瞒事实，并制定相应的对策。应该通知的各方：
（1）反病毒程序厂商，怀疑感染了新计算机病毒但病毒扫描没有发现；
（2）操作系统或应用软件厂商，其中存在安全弱点；
（3）计算机紧急响应小组, 安全事件归因于系统或应用相关的安全弱点；
（4）IT专业报刊 ；
（5）IT安全相关的公共机构。
例如，注意到个人计算机上的数据偶然遭到破坏或丢失，在得到报告并经过调查后发现，问
题是因为新的宏病毒引发的，该病毒是通过 E-mail附件扩散的。在这种情形下，应该通知
下列部门：
（1）IT部门领导；
（2）IT用户；
（3）IT管理员；
（4）IT用户服务商；
（5）从首次发现计算机病毒之后用电子邮件方式交换过信息的各方；
（6）反病毒程序厂商；
（7）计算机紧急响应小组 。
5．其余控制：
（1）谁负责将与安全事件相关的信息传给第三方？
（2）应该采取何种步骤保证未经授权的人员不得发布任何有关安全的信息。
对安全应急响应的评估
为从安全事件中学习到一些东西，不能忽略对整个安全事件的应急处理过程的总结和评
估。这样做可以改善对安全事件的处理水平，并对 IT安全管理及 IT安全措施的效率做出正
确的评价。这里要考虑的方面包括：
1．响应时间：要搜集有关安全事件是用了多长时间才被发现的信息，检查现有的同类安全
事件发现技术措施是否需要改进。还应该检查事件报告经过上报渠道需要花费的时间。其它
应考虑的方面包括：做出采取措施的决定有多快、需要花费多长时间去实施、受事件影响的
各方什么时间能够被通知到等。当追溯使用的上报渠道时，应该考虑上报渠道是否已被每个
人所了解、是否要采取必要措施让大家知晓并提供其它信息。
2．提交策略的效率：要利用特殊的安全事件来检查制定好的提交策略是否起作用，是否还
需要额外信息以及是否要修改提交策略。
3．评估的效率：当回头来看安全事件时，应该考虑损害程度是否已被正确估计，优先级考
虑是否合适，是否利用了安全事件小组来进行调查。
4．通知受影响的各方：有必要考虑受影响各方是否被真正通知到，是否被及时通知到。有
必要找出更快的通知渠道。
5．对事件报告人的反馈：解决问题后，应该将安全事件所产生的损害和所采取的措施告知
安全事件的发现人及报告人，这样可以证明这类报告会被严肃对待，并鼓励未来发生类似情
况时继续报告。对准确、及时的报告进行表彰和奖励也是合适的，它告诉员工对安全事件的
报告是多么重要。
6．犯罪者的动机 ：如果发现安全事件是一种故意行为，应该调查犯罪动机。当事件牵涉到
内部人员时，动机是非常重要的。如果是因为组织的环境造成的，应该通知管理层，因为这
些错误或故意行为还会再次发生。同时取决于对这些资源的评价结果，管理层应该了解以便
做出改进。因此由安全计划外的机构进行这种评价工作是合理的。
7．制定行动指令：作为安全事件评估的一部分，当类似的安全事件再次发生时，可以利用
本次的结果去检验即将采取的行动或复查采取的过程。一旦拥有解决问题的实际经验，比起
仅仅拥有理论来更能制定出有效的行动指令。所发生的安全事件也显示出：针对这类安全事
件采取行动的指令有一些具体的需求，因此准备采取的指令应该以合适的方式通知相关人员。
8．其余控制：
（1）对最近一次发生的安全事件有没有做评估？
（2）一年中有没有向管理层报告过安全事件？
（3）采取行动的具体指令如何被更新和传达？
安全应急发现措施的使用
在发生安全事件时，不仅及早发现它很重要，预防它同样很重要。对于很多与安全相关
的异常现象，通过使用适当的技术，可以在早期自动的发现。这些发现手段通常都会增加发
现的可靠性，并减少从事件发生到被发现之间的时间。但是要获得这种早期的反应能力，就
需要对实施和监控这些措施多做一些工作，对这种工作的劳动程度应该提前有所估计。如果
潜在的威胁非常大或可能带来人员伤害，那就没有其它选择，只有采用这样的发现措施。
有关这类发现措施的例子包括：
（1）警报告示设备；
（2）远程故障报警；
（3）病毒扫描程序；
（4）入侵探测和入侵防范系统；
（5）加密校验。
不是所有的安全事件都可以用技术手段立即发现，组织措施也是经常必用的。自动发现
措施的可靠性通常依赖于他们的更新程度和适应实际环境的程度。发现措施的有效性紧密依
赖于从事这些任务的人的可靠性，也紧密依赖于这些措施在实际运行过程中实施的简易程度。
作为全部或部分组织性质的发现措施有以下典型例子：
（1）取得系统安全弱点信息 ；
（2）对选择 IT系统进行经常性的安全检查 ；
（3）对日志文件进行经常性分析 。
其余控制
（1）使用什么样的发现措施?
（2）是否采取步骤保证日志文件中的任何异常事件被报告？
灾难恢复计划
概述
背景
当今世界，市场竞争越来越激烈。现代企业越来越依赖于计算机系统，因为这里保存着
企业维系生存、参与竞争的重要资产—企业信息资源。企业对信息的依赖程度从来没有像今
天这样迫切。对企业而言，计算机系统失效无疑是一场灾难。在这种情况下，企业无法正常
运转，甚至可能陷入完全瘫痪。而且，有许多因素威胁着计算机系统的正常运转。大到自然
灾害（地震、洪水、飓风、火灾等），小到失窃、断电乃至操作员不经意的失误，都会影响
系统的正常运转，甚至造成整个系统完全瘫痪。由计算机系统瘫痪造成的影响往往是十分惊
人的。1987年，美国德克萨斯州大学进行过一项名为“计算机系统失效对商业公司之影响”
的调查。在被调查的 160家公司中，有将近 1/3的公司经历过计算机系统失效。在这些公司
中，只有将近二分之一的公司有一套完整的灾难应急计划。完全没有应急计划的公司损失惨
重，灾难后业务无法恢复，十之八九在两年内退出市场。比如 1993年发生在纽约世界贸易
中心的爆炸事件。位于该中心的 350家公司中，有 150家已经退出市场。其原因是由于爆炸
使他们的计算机系统遭到破坏，用户无法访问他们所需的重要信息资源。所以，在灾难发生
后，能够快速、简单、可靠地恢复一个立即可用的系统至关重要！这件事处理得好坏，有时
关系到企业的生死存亡。
灾难恢复技术，是目前在发达国家中十分流行的 IT技术。它能够为重要的计算机系统
提供在断电、火灾、受到攻击等各种意外事故发生，乃至在如洪水、地震等严重自然灾害发
生的情况下保持持续运转的能力，因而对企业和社会关系重大的计算机系统都应当采用灾难
恢复技术予以保护。
灾难恢复涉及的范围
导致系统失效的因素很多，大致可分为两大类。一类是自然灾害和人为破坏，这类因
素很容易被发现并引起警惕。另一类则比较隐蔽，是计算机系统本身潜伏的一些破坏性因
素。在导致计算机系统失效的各种因素中，软件和硬件（包括磁盘）因素占 70%以上。
导致系统失效的主要因素依次是：硬盘崩溃、计算机及其他硬件的损坏、系统软件不兼容、
病毒侵袭以及人为的误操作。
（1）硬盘崩溃。硬盘是机电设备，它的失效是迟早的事。硬盘的任何损坏都可能丢失数据
甚至导致整个系统崩溃。
（2）硬件损坏。内存储器、网卡、电源乃至母板，任何一种硬件失效或遭到破坏都会使系
统无法正常运转。在这种情况下，虽然数据完好地保存在磁盘中，但是在一个失效的系统中，
数据几乎毫无用处。
（3）软件不兼容。今天的商业系统已经很少在大型主机的单独支持下运行，通常需要来自
不同厂家的多种系统软件协同工作。因此，软件的升级、补丁文件、甚至同一软件小小的更
新都可能导致整个系统失效。
（4）病毒侵袭。在 PC使用初期，病毒的危害就已为大家所熟知。今天，一个信息系统如果
未加任何保护措施就联入因特网，那么受病毒侵袭的危险比以往任何时候都大。更糟糕的是，
病毒的危害一般不会立即表现出来，而一旦发作，往往令人措手不及。
（5）操作失误。与上述原因相比，人为操作失误导致系统失效的可能性较小，但确实存在。
典型错误是系统管理员误删除系统文件、数据文件、系统目录。
今天，虽然计算机元器件的可靠性已经大大提高，软硬件中也纳入了不同程度的容错功能
（如 RAID技术、Cluster结构等等），但是面对可能导致系统失效的种种因素，系统整体抗
灾性一直是（并仍将是）必须认真对待的问题。
灾难恢复的基本技术要求
据不完全统计，即使在欧美一些发达国家中，支持企业关键业务的应用系统也有一半左
右是在局域网环境下运行的。因此，灾难恢复的重点也应当在此。
局域网环境下的系统恢复，绝非备份数据和故障后恢复那么简单。一个完备的局域网灾难恢
复计划，应当对所有影响局域网正常运转的事件做出相应的策略。从根本上说，这种恢复计
划应当包括三个重要部分，即数据保护、灾难防备和事后恢复。
1．备份软件
对保护数据来说，功能完善、使用灵活的备份软件必不可少。合格的备份软件应当具有
以下功能：
（1）保证备份数据的完整性，并具有对备份介质（如磁带）的管理能力。数据完整性是系
统恢复后立即可用的前提。因此，只有保证数据完整性，数据备份才有意义。超大系统的备
份介质管理需要备份软件的参与和支持。特别是备份软件需要具有“通知机制”，可以提醒
系统管理员何时更换备份介质，何时从备份设备中取出备份介质，为系统管理员建议介质轮
换周期、备份策略。
（2）支持多种备份方式，可以定时自动备份。除了支持常规备份方式（如完全式、增量式、
差分式）外，还可以设置备份自动启动和停止的日期，记录系统配置以供重用，处理备份中
的各种情况，等等。
（3）具有相应的功能或工具，进行设备管理、介质管理。这种功能或工具应当支持各种类
型的介质，包括级联式磁带、磁带库、磁带组、磁带阵列。备份软件应当保存设备和介质活
动记录，诸如磁带首次格式化的时间、格式化次数，等等。
（4） 支持多种校验手段，以确保备份的正确性。备份软件至少应当提供字节校验、CRC（循
环冗余校验）和快速磁带扫描等手段。还应该提供磁带到磁带的拷贝和比较功能，并对写入
磁带的数据提供保护。
（5）提供联机数据备份功能。在联机状态下进行数据备份对许多系统都是一大挑战。但是，
合格的备份软件必须具有这一功能，因为对依靠数据库服务器管理数据的应用系统来说，这
一功能必不可少。
除了以上功能外，更完善的备份软件还支持 RAID容错技术和图像备份功能。前者保证在个
别硬盘遭到破坏时，整个备份仍然可用。后者使用户可以绕开系统，对图像快速备份。
2．恢复的选择和实施
数据备份只是系统成功恢复的前提之一。恢复数据还需要备份软件提供各种灵活的恢复
选择，如按介质、目录树、磁带作业或查询子集等不同方式做数据恢复。此外，还要认真完
成一些管理工作，如：定期检查，确保备份的正确性；将备份磁带保存在异地一个安全的地
方（如专门的磁带库或银行保险箱）；按照数据增加和更新速度选择恰当的备份周期。一般
而言，部分备份周期不应该超过一个月。
针对服务器/客户机环境而言，传统的大型主机恢复策略很少奏效。服务器/客户机环境恢复
的关键是保护好服务器管理的数据。而服务器磁盘的安全有效又是保护数据的关键。因此，
配备高性能、具有容错能力的磁盘存储器，是保护服务器的有力措施之一。
3．自启动恢复
系统灾难通常会使企业丢失数据或者无法使用数据。利用备份软件可以恢复丢失的数据。
但是，重新使用数据并非易事。很显然，要想重新使用数据并恢复整个系统，首先必须将服
务器恢复到正常运行状态。为了提高恢复效率、减少服务停止时间，应当使用“自启动恢复”
软件工具。通过执行一些必要的恢复功能，使系统可以自动确定服务器所需要的配置和驱动。
因此，无需人工重新安装、配置操作系统，也不需要重新安装、配置磁带恢复软件及应用程
序。此外，自启动恢复软件还可以生成备用服务器的数据集和配置信息，以简化备用服务器
的维护。
4．病毒防护
如果系统中潜伏着病毒，那么即使数据和系统配置没有丢失，服务器中的数据也可能
随时丢失或被破坏。因此，病毒防护也是灾难恢复的重要内容。在数据和程序进入网络之
前，要做清毒处理。更为重要的是，要加强对整个网络的自动监控，防止新病毒出现和传
播。这些功能只有在强大的防病毒软件支持下才能实现。防病毒软件应该与其他防灾方案
密切配合，同时互相透明。总而言之，一个完整的灾难恢复方案必须包括很强的病毒防护
策略和手段。
灾难恢复的局限性
需要注意的是，灾难恢复本身并不是万能的，即便是制定了符合单位实际情况的灾难恢
复计划，还需要根据企业自身情况制定日常备份制度和灾难恢复措施，并由管理人员切实执
行备份制度，否则灾难恢复仅仅是纸上谈兵。
灾难恢复相关技术
做好灾难恢复，首先在备份系统时要考虑到系统容量不断增加的需求，还要考虑备份软
件必须能支持多平台系统下的运行。当网络上连接了其它的应用服务器时，对于网络存储管
理系统来说，只需安装支持这种服务器的客户端软件即可将数据备份到磁带库或光盘库中。
其次，网络数据存储管理系统是指在分布式网络环境下，通过专业的数据存储管理软件，结
合相应的硬件和存储设备，来对全网络的数据备份进行集中管理，从而实现自动备份、文件
归档、数据分级存储以及灾难恢复等功能。
整个网络系统自动数据存储管理，是在备份服务器、备份管理软件与智能存储设备的有
机结合基础上实现的。数据存储管理系统的工作原理是在网络上选择一台应用服务器（当然
也可以在网络中另配一台服务器）作为网络数据存储管理服务器，安装网络数据存储管理服
务器软件，作为整个网络的备份服务器。在备份服务器上连接一台大容量存储设备（磁带机
或磁带库），在网络的其他需要进行数据备份管理的服务器上安装备份客户端软件，通过局
域网将数据集中备份到与备份服务器连接的存储设备上。网络数据存储管理系统的核心是备
份管理软件，通过备份软件的计划功能，可为整个企业建立一个完善的备份计划及策略，并
可借助备份时的呼叫功能，让所有的服务器备份都能在同一时间进行。备份软件也提供完善
的灾难恢复手段，能够将备份设备的优良特性完全发挥出来，使备份和灾难恢复时间大大缩
短，实现网络数据备份的全自动智能化管理。
备份技术简介
灾难恢复的先决条件是要作好备份策略及恢复计划。日常备份制度描述了每天的备份以
什么方式、使用什么备份介质进行，是系统备份方案的具体实施细则。在制订完毕后，应严
格按照制度进行日常备份，否则将无法达到备份方案的目标。数据备份有多种方式，在此磁
带机为例，简单描述一下全备份、增量备份、差分备份的区别和应用。
1．全备份
所谓全备份就是用一盘磁带对整个系统进行完全备份，包括系统和数据。这种备份方式
的好处就是很直观，容易被人理解。而且当数据丢失时，只要用一盘磁带（即灾难发生前一
天的备份磁带），就可以恢复丢失的数据。然而它也有不足之处：首先由于每天都对系统进
行完全备份，因此在备份数据中有大量重复信息，例如操作系统与应用程序。这些重复的数
据占用了大量的磁带空间，这对用户来说就意味着成本增加；其次，由于需要备份的数据量
相当大，因此备份所需时间较长。对于那些业务繁忙、备份时间相对有限的单位来说，这种
备份策略无疑是不明智的。
2．增量备份
所谓增量备份就是每次备份的数据只是相当于上一次备份后增加和修改过的数据。这种
备份的优点很明显：没有重复的备分数据，即节省磁带空间，又缩短了备份时间。但它的缺
点在于当发生灾难时，恢复数据比较麻烦。举例来说，如果系统在星期四早晨发生故障，丢
失大批数据，那么现在就需要将系统恢复到星期三晚上的状态。这时管理员首先需要找出星
期一的那盘完全备份磁带进行系统恢复，然后再找出星期二的磁带来恢复星期二的数据，然
后在找出星期三的磁带来恢复星期三的数据。很明显这比第一种策略要麻烦得多。另外这种
备份可靠性也差。在这种备份下，各磁带间的关系就象链子一样，一环套一环，其中任何一
盘出了问题都会导致整条链子脱节。
3．差分备份
所谓差分备份就是每次备份的数据是相对于上一次全备份之后新增加和修改过的数据。
管理员先在星期一进行一次系统完全备份；然后在接下来的几天里，再将当天所有与星期一
不同的数据（新的或经改动的）备份到磁带上。举例来说，在星期一，网络管理员按惯例进
行系统完全备份；在星期二，假设系统内只多了一个资产清单，于是管理员只需将这份资产
清单一并备份下来即可；在星期三，系统内又多了一份产品目录，于是管理员不仅要将这份
目录，还要连同星期二的那份资产清单一并备份下来。如果在星期四系统又多了一张工资表，
那么星期四需要备份的内容就是：工资表+产品目录+资产清单。
由上可以看出，全备份所需时间最长，但恢复时间最短，操作最方便，当系统中数据量不大
时，采用全备份最可靠；增量备份节省备份空间，备份时间短，但恢复起来比较麻烦；差分
备份在避免了另外两种策略缺陷的同时，又结合了它们的所有优点。首先，它无需每天都做
系统完全备份，因此备份所需时间短，并节省磁带空间；其次，它的灾难恢复也很方便，系
统管理员只需两盘磁带，即星期一的磁带与发生前一天的磁带，就可以将系统完全恢复。我
们在备份时要根据它们各自的特点灵活使用。
灾难恢复措施在整个备份制度中占有相当重要的地位。因为它关系到系统、软件与数据在经
历灾难后能否迅速地恢复。全盘恢复一般应用在服务器发生意外灾难导致数据全部丢失、系
统崩溃或是有计划的系统升级、系统重组等，也称为系统恢复。
综上所述，一个完整的灾难备份及恢复方案，应包括备份设备、备份软件、备份制度和灾
难恢复计划四个部分。但若想做到数据存储的万无一失，还需要根据企业自身情况制定日
常备份制度和灾难恢复措施，并交由管理人员切实执行，否则数据安全则无从谈起。
容灾技术简介
当应用系统的一个完整环境因灾难性事件(如火灾、地震等)遭到破坏时，为了迅速恢复
应用系统的数据、环境，立即恢复应用系统的运行，保证系统的可用性，这就需要异地灾难
备份系统(也称容灾系统)。可以说，对于关键事物的处理系统,如联通的各项业务系统（客
户服务、计费、IDC等），建立最高级别的安全体系，也是提高服务质量、在竞争中立于不
败之地的重要举措。
长期以来，对企业而言，建立一套可行的容灾系统相当困难，主要是高昂的成本和技术
实现的复杂度。鉴于此，从可行性而言，必须具有良好的性能价格比。
建立异地容灾系统，即指建立远程的数据中心，通过配置远程容灾系统将本地数据实时
进行远程复制，同时实现本地系统故障时应用系统的远程启动，确保系统的不中断运行。
建立异地容灾中心的优势在于：
强大的一级灾难抗御能力。
有效防止物理设备损伤产生的灾难后果。
提供 %的安全机制。
实时数据复制提供强大的数据交换能力。
随着数据安全技术的发展，Cluster（HA）的技术越来越成熟，Cluster的部署越来越
普及，Cluster技术确实解决了用户系统的高可用性问题，为业务的良性发展提供了稳定的
基石。随着业务的发展，商业环境对服务供应商提出的要求也越来越苛刻，这必将使应用系
统及其数据对高可用性的要求走上一个新的台阶。
一个本地 Cluster系统理论上可以提供 %以上的系统高可用性，但一旦发生火灾、
自然灾害、人为破坏等意外事件，服务商将如何应对呢？如果没有必要的准备和应对手段，
这样的一次意外对服务上来说将是灾难性的。对于 IT部门来讲，要提高自己的抗灾能力，
其必要的技术就是建立起一个容灾系统。
· 容灾技术的分类
一个容灾系统的实现可以采用不同的技术，一种技术是：采用硬件进行远程数据复制，
我们称为硬件复制技术。这种技术的提供者是一些存储设备厂商。数据的复制完全通过专用
线路实现物理存储设备之间的交换。另一种技术是：采用软件系统实现远程的实时数据复制，
并且实现远程的全程高可用体系（远程监控和切换）。这种技术的代表如 VERITAS等一些著
名存储软件厂商。我们在下面的章节会对以上两种技术进行详细的论述。
容灾系统的归类在另一个方面要由其最终达到的效果来决定。从其对系统的保护程度来分，
我们可以将容灾系统分为：数据容灾和应用容灾。
所谓数据容灾，就是指建立一个异地的数据系统，该系统是本地关键应用数据的一个实
时复制。在本地数据及整个应用系统出现灾难时，系统至少在异地保存有一份可用的关键业
务的数据。该数据可以是与本地生产数据的完全实时复制，也可以比本地数据略微落后，但
一定是可用的。
所谓应用容灾，是在数据容灾的基础上，在异地建立一套完整的与本地生产系统相当的
备份应用系统（可以是互为备份）。建立这样一个系统相对比较复杂，不仅需要一份可用的
数据复制，还要有包括网络、主机、应用、甚至 IP等资源，以及各资源之间的良好协调。
应用容灾应该说是真正意义上的容灾系统。我们先讨论一下数据容灾。
数据容灾（硬件容灾方案和软件容灾方案均包括），又称为异地数据复制技术，按照其
实现的技术方式来说，主要可以分为同步传输方式和异步传输方式（各厂商在技术用语上可
能有所不同。而根据容灾的距离，数据容灾又可以分成远程数据容灾和近程数据容灾方式。
下面，我们将主要按同步传输方式和异步传输方式对数据容灾展开讨论，其中也会涉及到远
程容灾和近程容灾的概念，并作相应的分析。
·同步传输的数据复制
有关同步数据容灾，在传统意义上讲，就是通过容灾软件（可以含在硬件系统内），将
本地生产数据通过某种机制复制到异地。从广义上讲，同步数据容灾是指在异地建立起一套
与本地数据实时同步的异地数据。
采用同步传输方式进行异地数据容灾的过程包括：
1. 本地主机系统发出第一个 I/O请求 A；
2. 主机会对本地磁盘系统发出 I/O请求；
3. 本地磁盘系统完成 I/O操作，并通知本地主机“I/O完成”；
4. 在往本地 I/O的同时，本地系统（主机或磁盘系统）会向异地系统发出 I/O请求 A；
5. 异地系统完全 I/O操作，并通知本地系统“I/O完成”
6. 本地主机系统得到“I/O完成”的确认，然后，发出第二个 I/O请求 B。
不同的异地数据复制技术的实现方式是不同的，包括：
基于主机逻辑卷层的同步数据复制方式（软件复制方式）；
基于磁盘系统 I/O控制器的同步数据复制方式（硬件复制方式）；
一. 基于主机逻辑卷的同步数据复制方式
基于主机逻辑卷的同步数据复制方式以 VERITAS Volume Replicator（VVR）为代表，
VVR是集成于 VERITAS Volume Manager（逻辑卷管理）的远程数据复制软件，它可以运行于
同步模式和异步模式。
当主机发起一个 I/O请求 A之后,必然通过逻辑卷层，逻辑卷管理层在向本地硬盘发出
I/O请求的同时，将同时通过 TCP/IP网络向异地系统发出 I/O请求。其实现过程如下：
1. 本地主机系统发出第一个 I/O请求 A；
2. 主机逻辑卷层会对本地磁盘系统发出 I/O请求；
3. 本地磁盘系统完成 I/O操作，并通知本地逻辑卷“I/O完成”；
4. 在往本地磁盘系统 I/O的同时，本地主机系统逻辑卷会向异地系统发出 I/O请求 A；
5. 异地系统完成 I/O操作，并通知本地主机系统“I/O完成”
6. 本地主机系统得到“I/O完成”的确认，然后，发出第二个 I/O请求 B。
二. 基于磁盘系统的同步数据复制功能
基于磁盘系统的同步数据复制功能实现异地数据容灾，如 SRDF和 PPRC。这两个软件运
行的平台是磁盘系统，部署这样的系统必须要求在两端采用相同种类的磁盘系统。
当主机发出一个 I/O请求 A之后，I/O进入磁盘控制器。该控制器在接到 I/O请求后，
一方面会写入本地磁盘，同时利用另一个控制器（或称通道），通过专用通道（如：ESCON）、
FC光纤通道（IP over FC）或者租用线路，将数据从本地磁盘系统同步的复制到异地磁盘
系统。其实现过程如下：
1. 本地主机系统发出第一个 I/O请求 A；
2. 主机对本地磁盘系统发出 I/O请求；
3. 在往本地磁盘系统 I/O的同时，本地磁盘系统会向异地磁盘系统发出 I/O请求 A；
4. 本地磁盘系统完成 I/O操作；
5. 异地系统完成 I/O操作，并通知本地磁盘系统“I/O完成”
6. 本地次盘系统向主机确认“I/O完成”，然后，主机系统发出第二个 I/O请求 B。
·同步数据容灾的性能分析
利用同步传输方式建立异地数据容灾，可以保证在本地系统出现灾难时，异地存在一份
与本地数据完全一致的数据备份（具有完整的一致性）。但利用同步传输方式建立这样一个
系统，必须考虑“性能”这个因素。采用同步数据传输方式时，从前面的描述来看，本地系
统必须等到数据成功的写到异地系统，才能进行下一个 I/O操作。一个 I/O通过远程链路写
到异地系统，涉及到 3个技术参数：带宽、距离和中间设备及协议转换的时延。
1. 带宽
本地 I/O的带宽是 100MB/秒（SAN网络中），在 I/O流量很大的情况下，如果与远程的 I/O
带宽相对“100MB/秒 == 800Mbit/秒”窄得多的话，如 E1：2Mbit/秒；E3：45Mbit/秒，将
会明显拖慢生产系统的 I/O，从而影响系统性能。
2. 距离
光和电波在线路上传输的速度是 30万公里/秒，当距离很长时，这种线路上的延时将会
变得很明显。例如：一个异地容灾系统的距离是 1000KM，其数据库写盘的数据块大小是 10KB
（一次 I/O的数据量），那么：
本地 I/O时（100米距离内）：
光电在线路上的延时 =
= * 10-6 秒
1秒钟内允许 I/O次 = 1/（ * 10-6 ）= * 10-6 次
1秒钟允许的 I/O量 = 10KB * * 10-6 = 15GB
此数字远远超过光纤通道带宽本身，也就是说，光电在 100米距离的线路上的延时对性能的
影响可以忽略不计。
异地 I/O的（1000公里）：
光电在线路上的延时 = 1000km/300,000km*2次
= 1/150 秒
1秒钟内允许 I/O次 = 1/（1/150 ）= 150次
1秒钟允许的 I/O量 = 10KB * 150 =
此数据表明，在 1000公里距离上，允许的最大 I/O量在不存在带宽限制时，已经远远低于
本地 I/O的能力。（注：上面分析还未考虑中间设备及协议转换的延时）。
3. 中间链路设备和协议转换的时延
中间链路设备和协议转换的方式的不同，时延不同，对性能的影响也不同。在对性能影
响的分析中，这个因数也应计算在内。目前不同异地数据复制技术所依赖的介质和协议不同，
我们将介质、协议和大概时延例表如下，这里提供的数据只精确到数量级，仅供参考，实际
数据应该向设备供应商索取。
链路设备和协议 带宽 支持的距离 设备和协议转换时延
租用线路 任意 不受限制 约 1ms
ESCON 136Mbit 66公里 < 100us
LAN 1000Mbit 10公里 < 100us
ATM 655Mbit 不受限制 < 100us
IP over FC 800Mbit 60公里 < 100us
FC 800Mbit 60公里 < 10us
下面是一个线路时延分析对照表，供参考。
距离
1000KM 100KM 10KM
线路时延 / 次 I/O 6ms 600us 60us
支持的链路和协议 租用线路
ATM
租用线路
ATM
租用线路
ATM
ESCON
LAN
IP over FC
FC
本地磁盘 I/O能力 10KB/ms
在 1000公里和 100公里距离上，采用租用线路和 ATM，允许的最大 I/O能力（假定带宽足
够，数据块大小以 10KB为例）：
1000公里 100公里
租用线路 ATM 租用线路 ATM
线路时延 / 次 I/O 6ms 6ms 600us 600us
设备和协议时延 > 1ms < 100us > 1ms < 100us
每个 I/O响应时间 > 8ms > 7ms >
不适合用同步传输方式
备注 不适合用同步传输
在 10公里距离上，采用各种传输协议允许的最大 I/O能力，数据块大小以 10KB为例（假
定带宽足够）：
10公里
租用线路 ATM
LAN
ESCON
IP over FC
FC
线路时延/次 60us 60us 60us 60us
设备协议时延 > 1ms < 100us < 100us < 10us
I/O次数/秒 485-930 900-5800 900-5800 900-12500
I/O MB/秒 9-58 9-58 9-125
备注 适合用同步传输
·异步数据复制方式
从前面的分析来看，同步数据容灾一般只能在较短距离内部署（10KM-100KM），大于这
个距离，就没有实际应用价值了。因为即使在 1000KM距离上，的速率即使将数据复
制到异地，每个 I/O的响应时间也会超过 10ms，这种响应速度太慢。
异步数据容灾是在“线路带宽和距离能保证完成数据复制过程，同时，异地数据复制不
影响生产系统的性能”这样的要求下提出来的。考虑异步数据容灾，应该注意到以下几个技
术条件和事实。
带宽必须能保证将本地生产数据基本上完全复制到异地容灾端，还要考虑距离对传输能
力的影响。按照前面的估算：在 1000公里范围内，一条带宽足够的线路能支持的 I/O流量
最大为（数据块大小 10KM ）：×3600秒×24小时=120GB/天
异地容灾远端数据会比本地生产端数据落后一定时间,这个时间随采用的技术，带宽、
距离、数据流特点的不同而不同。一般而言，软件方式的数据复制技术具有完整的数据包的
排队和断点重发机制，在灾难情况下可以保证灾难时间点的数据一致性。
异步容灾基本不影响本地系统性能。与同步传输方式相比，异步传输方式对带宽和距离的要
求低很多，它只要求在某个时间段内能将数据全部复制到异地即可，同时异步传输方式也不
会明显影响应用系统的性能。其缺点是在本地生产数据发生灾难时，异地系统上的数据可能
会短暂损失（如果广域网速率较低，交易未完整发送的话），但不影响一致性（类似本地数
据库主机的异常关机）。
通过异步传输模式进行异地数据复制的技术，包括：
基于主机逻辑卷的数据复制方式
基于磁盘系统 I/O控制器的数据复制方式
1. 基于主机逻辑卷（Volume）的数据复制方式
针对这种方式，这里以 VERITAS VVR为例，但并不表示所有基于主机进行复制的其它软
件采用同样方式，也不保证其它软件是有应用价值的。VERITAS VVR （Volume Replicator）
通过基于 Volume和 Log的复制技术，保证在任何时刻本地系统发生自然灾难时，在异地的
数据仍是可用的。VERITAS VVR在异步模式下采用了 Log技术来跟踪未及时复制的数据块，
这个 Log是一个先到先服务的堆栈，每一笔 I/O处理都会首先被放进这个 Log，并按到达先
后顺序被复制到异地服务器系统。
基于主机逻辑卷（Volume）的数据复制方式整个 I/O和复制的过程如下：
1. 本地主机系统发出第一个 I/O请求 A到逻辑卷；
2. 逻辑卷对本地磁盘系统发出 I/O请求；
3. 在往本地磁盘系统 I/O的同时，逻辑卷向本地磁盘系统上的 VVR Log发出相同的写
请求；
4. 本地磁盘系统完成 I/O操作；并通知逻辑卷“I/O完成”；
5. VVR完成针对这个 I/O的远程操作，并通知逻辑卷；
6. 逻辑卷向主机确认“I/O完成”。
服务器的另一个进程：VVR的进程，负责将 Log队列中的 I/O复制到异地服务器。这个
过程和上面的 I/O过程在时间上无关。如上图中的标记：“I”和“II”。
I: 本地 VVR进程从 Log队列中取出最先到达的 I/O，复制到异地服务器
II: 异地服务器接收到本地服务器 VVR发出的 I/O请求，将相应数据写到异地磁盘系统，
然后，通知本地系统 VVR进程，要求下一个 I/O。
这里，跟踪未及时复制的数据块的 Log技术是保证异地数据可用的必要条件。一个数据
库的 I/O是有严格顺序的，这个顺序是保证数据库完整性的必要条件，一个完整性被破坏的
数据库一般是不可用的，比如根本无法启动、打开该数据库，且是无法修复的。本地数据库
的完整性是由数据库本身来维护的。当一个数据库被实时复制到异地时，要保证异地数据库
的完整性，必然保证在异地磁盘 I/O上的 I/O顺序和本地 I/O顺序完全相同，否则，异地数
据库的完整性就无法保证。
VERITAS VVR采用的 I/O控制机制是支持先到先服务的 Log技术，因此，不管异地数据
比本地数据落后多少时间，都能保证异地数据库数据的一致性。比如：本地系统在 12：00
时发生自然灾难，由于部分数据未被及时复制到异地，如有 10分钟的数据未完成复制，那
么在异地系统上存在 11：50分钟以前的所有数据，且这个数据库是可用的。
目前的基于磁盘系统的异地数据复制技术采用 Bitmap技术和 Timestamp技术，这两种
技术都不能保证本地向异地复制数据的顺序严格和本地 I/O的顺序相同，所以，这两种方式
都不能保证异地数据库的完整性。Bitmap（位图）技术记录未被及时复制的数据块的方法是：
对于每个数据块（如 32KB）用一个 Bit来对应，某一个 Bit被置为“1”时，表示其对应的
数据块已被修改过，正在等待处理（这里是等待被复制）。由此可以看出，当有一块以上的
数据块未被及时复制时，系统并无法确认哪一块数据块应该先复制到异地，所以，系统将任
选一块，即不按到达的时间先后进行复制。可以看出，这种方式不能根本保证异地数据库数
据的完整性、一致性。
Timestamp方式是对每个未及时传送的数据块盖上一个时间戳。从表面上看，由于时间
戳的关系，好像能确定一个数据块被修改的时间顺序了。其实不然：当一个未被及时复制的
数据块被第 2次修改，并盖上新的时间戳时，数据复制的顺序就被破坏了。例如：
现在有 10块数据块未被复制，编号“1、2、3、4、5、6、7、8、9、10”；这时，第 3块数
据被再次修改，并被盖上一个新的时间戳“11”；这时，系统会按这样的次序进行复制：
“1、2、（没有 3）、4、5、6、7、8、9、10、11”。我们可以看到，在复制进行到“4~10”
之间时，异地数据的完整性被破坏。
事实上，在一个运行繁忙的系统中，出现这种情况机率极高，甚至每时每刻都处在这种
状态之下。所以，本着严格的，对系统可用性负责任的态度，我们认为“Timestamp”的技
术虽然比 Bitmap技术有一定优势，但实际上也无法保证异地数据的完整性和可用性。
Bitmap和 Timestamp方式的技术弱点：没有 log；
作为磁盘系统内置的数据复制功能，传统的磁盘管理模式没有考虑在磁盘系统内部开辟出一
个磁盘块给磁盘系统控制器本身使用，所以，磁盘系统无法采用 log模式进行异步数据复制。
磁盘系统保留异步传输模式的目的：复制，但不是容灾复制；
数据复制的目的不仅仅是容灾。数据容灾要求两地时时保持连接，数据复制过程在任一时间
都在进行（除非有线路或设备故障）。而非容灾性复制只要求在某一个时间段里将数据复制
到异地，复制告一段落后（在某一时刻完全同步），复制工作会暂停。这种复制可能是为一
个特殊目的只做一次，如在线业务迁移；也可能每天或每月追加一次。这样，在异地就会存
在一份最大损失数据量为 1天或 1个月的生产数据复制品，其对数据的保障能力，如同磁盘
备份。这种方式复制数据的目的包括：1）在异地保存一份备份数据（如同磁带备份异地保
存）。2）在线业务迁移，当信息中心或其中的一个服务要迁移到另一个地方，又希望少停机（实
际上也可用磁带备份和恢复来实现）。3）利用与磁盘快照技术结合，为异地开发中心提供一
个与生产数据尽量相同的测试数据源。当然，也可用于其它可能的目的。
综上所述，我们可以看出，虽然基于磁盘系统的异地数据复制功能有异步传输模式，但
实际上并不支持异步数据容灾，只有像 VERITAS Volume Replicator这样基于先进先出的
Log技术的解决方案才真正支持异步数据容灾。
灾难恢复级别
根据国际标准 SHARE 78 的定义， 灾难恢复解决方案可分为七级，即从低到高有七种
不同层次，用户可根据企业数据的重要性以及需要恢复的速度和程度，来选择并实现灾难恢
复计划。其主要内容包括：
（1）备份/恢复的范围；
（2）灾难恢复计划的状态；
（3）应用地点与备份地点之间的距离；
（4）应用地点与备份地点之间如何相互连接；
（5）数据是怎样在两个地点之间传送的；
（6）允许有多少数据被丢失；
（7）怎样保证备份地点的数据的更新；
（8）备份地点可以开始备份工作的能力 ；
根据国际标准定义，灾难程恢复被定义为七种层次
1．层次 0 – 本地数据的备份与恢复
层次0被定义为没有信息存储和建立备份服务平台的需求，也没有发展应急计划的要求，
数据仅在本地进行备份恢复， 没有数据送往异地。这种方式是成本最低的灾难恢复解决方
案，但事实上并没有真正起到灾难恢复的作用，因为它的数据并没有被送往另外一台专用的
备份服务器上，而且数据的恢复也仅是利用本地的记录。
2．层次 1-批量存取访问方式
作为 层次 1的灾难恢复计划需要设计一个应急方案，能够备份所需要的信息，并将它
存储在另外的备份介质上，然后根据灾难恢复的具体需求，有选择地建立备份平台，进行系
统信息和数据的恢复。批量存取是一种用于多个地点备份的标准方式，数据在完成写操作之
后，将会被保存在另外的备份介质上，同时还保存了数据恢复的程序。在灾难发生后，利用
一台未启用的计算机通过网络完成整个系统的灾难恢复工作。这种灾难恢复方案相对来说成
本较低（仅仅是传输工具和存储设备的消耗），但同时在管理上却存在困难，即我们不知道
数据源来自何处。一旦系统可以工作，标准的做法首先是恢复关键应用，其余的应用根据需
要恢复。在这样的情况下，恢复是可能的，但需要一定的时间，并依赖于什么时候能够准备
好硬件平台。
3．层次 2 – 批量存取访问方式 + 热备份地点
层次 2相当于是层次 1再加上具有热备份能力的地点组成的灾难恢复系统。热备份地点
拥有足够的硬件和网络设备去支持关键应用的安装需求。对于十分关键的应用，在灾难发生
的同时，必须在异地有正运行着的硬件提供支持。这种灾难恢复的方式依赖于用批量存取的
方式去将日常数据放入热备份服务器，当灾难发生的时候，数据再被移动到热备份地点。虽
然移动数据增加了成本，但却明显降低了灾难恢复的时间。
4．层次 3 - 电子链接
层次 3 是在层次 2的基础上用电子链路取代了批量存取方式进行数据传送的一种灾难
恢复方案。接收方的设备必须与热备份的物理地点分开，在灾难发生后，存储的数据用于灾
难恢复。由于热备份地点要保持持续运行，因此增加了成本。但确实是消除了传输工具的需
要，提高了灾难恢复的速度。
5．层次 4 – 工作状态的备份地点
层次 4 这种灾难恢复要求两个地点同时处于工作状态并彼此管理着对方的备份数据，
允许备份行动在任何一个方向发生。接收方设备必须保证与另一方平台物理地相分离，在这
种情况下，工作负载可以在两个地点之间被均匀负担，地点 1成为地点 2 的备份，反之亦
然。在两个地点之间，关键的备份数据在不停地相互传送着。在灾难发生时，需要的关键数
据可立即通过网络得到迅速恢复，通过网络的切换，关键应用的恢复时间也可降低到了小时
级或分钟级。
6．层次 5 - 双重在线存储
层次 5在层次 4的基础上加上镜像管理被选择数据，也就是说，在更新请求被认为是满
意之前，层次 5需要应用地点与备份地点的数据都被更新。我们可以想象这样一种情景，数
据在两个地点之间相互映象，并由同步进程来同步，因为关键应用使用了双重在线存储，所
以在灾难发生时，仅仅是传送中的数据被丢失，恢复的时间被降低到了分钟级。
7．层次 6 – 零数据丢失
层次 6可以实现零数据丢失率，同时保证数据立即自动地被传输到备份地点。层次 6被
认为是灾难恢复的最高级别，在本地和远程的所有数据被更新的同时，利用了双重在线存储
和完全的网络切换能力，保证了数据的完整性和安全性。层次 6是上述灾难恢复方案中最昂
贵的一种信息恢复方式，同时也是速度最快的一种恢复方式。
灾难恢复计划的制定
灾难恢复计划制定目标及原则
在所有的信息系统资源中，数据是最重要的，但也是最不稳定和最复杂的。其他资源，
如计算机硬件设备、系统支持软件、建筑物及场地设施等，都是可替换的，但数据丢失却是
不可挽回的。进行数据备份是减少应用服务遭到长期破坏的关键。对于重要数据来说，有一
个清楚的灾难恢复计划同样也是重要的，它能清楚地显示灾难恢复所需的时间。灾难恢复计
划不是一、两个月的短期项目，也不是一个一旦完成，就可以弃之不管的项目。它是一个长
期有效的系统维护计划。这种计划必须一直有人参与，并且经常被测试、演习。
灾难及业务恢复计划的主要目标是让企业有能力在信息丢失灾难中存活下去，并迅速地
重新开始正常业务的运作。为了生存下来，企业必须保证那些关键的业务运作能够在有效的
时间内恢复。因此灾难及业务恢复计划的目标应该是：
（1）找出弱点并实施灾难预防程序；
（2）减少灾难严重影响业务运作的时间；
（3）加强灾难恢复任务之间的有效协调工作；
（4）减少灾难恢复工作的复杂程度。
以前只有数据处理部门被赋予提供处理意外事故计划的责任，这种做法通常会导致这样一种
结果：就是灾难恢复方案的规划、实施与企业的业务活动不完全相适应。处理意外事故的计
划与其说是数据处理问题，还不如说是一种业务问题。在目前的环境中，长期运行的业务出
现中断的后果则可能是灾难性的。因此，一个可行的灾难恢复策略的制定，不仅是数据处理、
通信和运行中心、服务厂商合作的产物，而且也应该是用户以及负责保护企业财产的管理人
员共同合作的产物。
在制定灾难恢复计划的过程中，应着重考虑以下几点：
（1）全面了解制定并维护一个有效的灾难恢复计划所需的全部工作；
（2）取得管理层以及参与这项工作的有关部门和人员的支持；
（3）从业务部门角度定义灾难恢复的需求；
（4）将信息丢失对业务运作和关键部门造成的影响进行归档；
（5）适当注意灾难预防、减轻灾难的影响以及灾难恢复；
（6）挑选项目队伍，保证计划制定所要求的人员；
（7）制定一个易于理解、易于操作并易于维护的处理意外事故的计划；
（8）考虑如何将灾难恢复计划纳入正在实施的业务计划和系统开发过程中，以使该计划能
够长期可行。
成功、低成本地完成这样一个项目，要求来自企业各部门的紧密配合，数据处理部门的高级
人员和用户部门必须实际参与项目的全过程，保证计划过程的成功。最后，记住计划过程的
目的是：
评估现有系统的弱点；实施灾难避免和预防程序；制定一个综合计划，使单位在灾难发
生时能够及时、恰当地应对。
1. 过程描述
由于制定和实施灾难恢复计划是一个高复杂度和高劳动强度的过程，因此它需要配备一
些专职技术人员、信息处理设备及适当的资金。企业在制定正常的业务计划中必须包括制定
和实施灾难业务恢复计划的项目支出。
推荐的项目方法包括八个独立的阶段，分别说明如下：
阶段一：计划前活动(项目初始阶段)
阶段一是了解企业内部目前存在的业务运行环境。它使得项目组能够限制项目的范围和相关
的工作程序，并快速地制定项目进度表，找出并公开影响项目交付和成功的问题。
在这个阶段，应该成立一个筹划指导委员会，筹划指导委员会应该负责为项目组提供指导方
向，为灾难恢复计划工作做决定。项目经理应该和筹划指导委员会一起完善工作计划的细节
并全面负责安全评估和业务影响分析工作的实施。另外，本阶段两个需要注意的问题是：制
定策略以支持恢复程序；针对那些需要参与项目的管理层和高级人员的认知程序。
阶段二：弱点分析和一般性需求定义
企业内的安全和控制是一个需要长期关心的问题。从经济和业务的角度来讲，应该将精力集
中到那些能够减少灾难发生概率的环节上，而不是主要关心如何减少实际灾难造成的后果。
这个阶段将制定减少灾难发生概率的措施。
本阶段包括以下主要任务：
（1）以下因素的全面的安全评估：包括个人实践在内的业务和通信环境；物理安全；操作
过程；备份和紧急计划；系统开发和维护；数据库安全；数据和语音通信安全；系统和访问
控制安全；保险；安全计划和管理；应用控制和个人电脑。
（2）安全评估使得项目组能够改善现有的紧急应急计划和灾难防止措施，使之对现有的需
求得到加强。
（3）向导委员会提供安全评估活动的内容和建议。
（4）定义计划工作的范围。
（5）提出有助于制定计划和维护的“灾难恢复计划和维护软件”的购买的提出建议。
（6）制定计划框架。
（7）组建项目组并使得每个成员明确职责。
阶段三：业务影响分析
对属于业务环境中的一部分业务单元进行业务影响分析，使得项目组能够标识关键系统、
过程和功能，评估因系统及其它服务、设施的拒绝访问等偶发事件和灾难而造成的经济影响，
正确估算业务单元拒绝访问的时间长度。业务影响分析报告应该呈交给筹划指导委员会。该
报告应标识关键服务功能以及这些服务在中断多长时间内必须恢复的时限，还应作为标识系
统和资源的基础，这些系统和资源能够为信息处理、其它服务和设施提供关键服务。
阶段四：详细的需求定义
在本阶段中，要制定一个灾难恢复要求的特性资料。这个特性资料被用作分析灾难恢复
替代策略的基础，并通过阶段三中的关键服务功能资源标识制定出。特性文件应能包括硬件
(主机，数据，语音通信和个人电脑)、软件(厂商提供、自己开发等)、文件(用户，过程)、
外部支持(公网，数据服务等)、设施(办公区，办公设备等)以及各业务单元的人力，并基于
短期、中期和长期三个层面的考虑。
阶段五：计划定制
在本阶段中，灾难恢复的组件被定义，计划被归档。本阶段也包括对用户过程变化的实施、
升级现有的恢复策略及替代策略的数据处理过程、厂商合同谈判(灾难恢复服务的供应商)、
灾难恢复项目组的角色和责任的定义。灾难恢复标准也在本阶段制定。
阶段六：测试/演习程序
在本阶段中制定测试/演习计划、建立测试/演习的目标以及评价替代测试策略。应根据
环境制定测试策略，并设计好一个能够进行的测试程序。
阶段七：维护程序
计划的维护对一个实际灾难恢复的成功非常重要。计划必须反映出它所支持的环境变化。
在一个灾难恢复计划中考虑环境的变化是很关键的。在那些管理没有变化的场合中，应建议
加入环境变化因素。许多灾难恢复软件已考虑了这一点。
8．阶段八：启动计划测试和实现
一旦计划已经制定，就要启动计划的测试，并根据对测试结果的分析，对计划做出必要的修
改。这个阶段的具体活动包括以下方面：
（1）定义测试目的/方法；
（2）确定测试人员；
（3）结构化测试；
（4）实施测试；
（5）分析测试结果；
（6）根据需要修改计划。
测试计划采用什么方式很大程度上取决于满足灾难恢复要求的灾难恢复策略的选择。随着灾
难恢复策略定义的完成，具体的测试过程也应该明细化以确保计划文本的全面精确。
2. 计划的范围和计划的目标
灾难恢复计划的主要目标是让企业能够在灾难中生存并继续正常的业务运作。为了生存，
企业必须保证关键业务能够恢复并继续正常工作。通过灾难恢复工作，计划将确立明确的授
权范围和工作优先级。紧急计划的关键目标应该是：
（1）灾难时为机房工作人员提供安全保障；
（2）继续关键业务运作；
（3）缩短因遭到严重破坏的业务和资源(信息处理和其它资源)的持续时间；
（4）减少直接损害和损失；
（5）建立管理的连续性并准备应急电源；
（6）加强灾难恢复任务中的有效协调工作；
（7）减少灾难恢复的难度；
（8）标识关键业务的范围和支持功能。
虽然大灾难发生的概率很小，但一旦发生，无论是对业务的影响还是公众形象方面，其
后果都可能是灾难性的。因此管理要充分考虑灾难发生的潜在影响，将负责灾难恢复计划的
责任分配给专职技术人员。管理者必须制定一个方案以满足下列目标：
（1）确定容易导致数据中心和业务设施发生重大服务中断的薄弱点，并制定为减少中断概
率和影响而采取的措施；
（2）标识和分析经济、服务、公众形象以及数据中心和其它业务设施发生服务中断的潜在
影响；
（3）确定直接、间接和潜在的灾难恢复需求和资源要求；
（4）找出替代方案，并选择最有成效的方法以提供数据备份能力和及时恢复能力；
（5）制定和实施紧急计划，解决数据中心和其它业务设施的现有和长期需求。
3. 项目的组织和人员安排
项目及人员的组织安排为最有效地实施处理计划提供了最大程度的灵活性。灾难和业务
恢复计划的实施是一个高复杂度和高劳动强度的过程，成功地制定和实施灾难恢复计划的关
键因素是为灾难恢复及业务连续计划安排专门、全职的人员。灾难恢复计划应该被视为一个
“活”的文档，信息处理和业务环境都是经常在变化的，而且越来越综合化、复杂化，灾难
恢复计划必须跟上这些变化。如果企业想保证在这种环境中的灾难恢复能力的正确性，对计
划的持续测试和演习就非常必要。企业还必须保证那些掌握灾难恢复技术的员工能很好地执
行这些计划。如果没有全职的专业人员负责计划的维护、协调计划的各部分，没有做好充分
的计划测试、人员培训、计划更新（以反映信息处理和业务环境的变化）等事务，灾难恢复
工作是无法实现的。
4. 筹划指导委员会
筹划指导委员会应该包括来自企业内各关键部门的代表包括：
信息处理部门、技术支持部门、系统开发部门、网络和运作服务部门、语音通信部门和关键
业务部门。
5. 项目组
项目组的组成可能因环境和灾难恢复计划所针对的业务部门的不同而不同。计划针对的
业务部门的经理应该负责他们各自计划的维护和测试。但是，负责灾难恢复及计划实施的人
员和部门应该在协调测试活动、修订和维护主要计划的过程中扮演重要角色。项目核心小组
自然就是项目组的一部分，项目组还应该包含内部审计方面的人员。各部门的经理可以选择
各自领域的高级人员来代表他们加入到项目中，并在制定计划时发挥他们的专长。
6. 项目核心小组组成
项目核心小组构成包括：项目经理、计算机和网络操作人员、系统支持人员及网络和通
信人员。
7. 信息系统和技术支持小组组成
信息系统和技术支持小组构成：
网络和通信、设施管理、网络开发和支持、数据库管理、信息系统安全、运作、网络支持以
及网络实现。
业务单位小组的成员组成随着每个业务单位的不同而不同。
8. 控制
灾难恢复项目的管理和控制应该有项目管理软件支持。项目管理软件用来管理诸如：人
力资源的调度、各种最终文档的标识和它们的最终完成日期等工作。比如在计划实施过程的
第二阶段用灾难恢复软件将计划归档；在阶段一的活动里，还利用项目管理软件为下面内容
制定详细的工作计划，包括数据处理、按人标识的任务和职责及其相关联的开始及完成日期。
9. 计划交付的时间表
以下是基于阶段的交付进度，作为项目的一部分被制定和实施。各阶段交付文档：
• 阶段 1计划前活动(项目启动)
（1）修订详细工作计划；
（2）会面时间安排；
（3）策略陈述；
（4）灾难恢复计划认知程序。
• 阶段 2 弱点评估
（1）安全评估报告；
（2）计划范围；
（3）计划框架；
（4）对购买灾难计划软件的建议；
（5）灾难恢复软件的实现功能。
• 阶段 3业务影响分析
（1）业务影响评估报告。
• 阶段 4详细的需求分析
（1）灾难恢复需求的特性文件；
（2）计划范围、目标和假设。
• 阶段 5 制定计划
（1）数据中心灾难恢复计划；
（2）原型业务单位恢复计划；
（3）灾难恢复目标。
• 阶段 6 测试程序
（1）测试目标；
（2）测试策略；
（3）测试过程。
• 阶段 7 维护程序
（1）维护过程；
（2）动态管理建议。
• 阶段 8 计划测试的启动和实现
（1）测试启动报告；
（2）实现。
11. 资源需求
那些希望制定灾难和业务恢复计划、而又不安排专门的人力、物力资源的企业很少能成
功实现有效的灾难恢复目标。有些企业在制定计划上花费了金钱和时间，却没有维护灾难恢
复能力的办法，这主要是缺乏必要的保障措施，以保证他们的计划总能反映最新的情况并对
计划的恢复能力做经常性的测试。管理层要想得到对这些程序进行开发、制定、实现和维护
的承诺，必须在开发周期中配置必要的资源，使得这些资源能够专门用于程序的维护。
资源需求分为三类，分别是：
（1）人员；
（2）投资成本；
（3）运行成本。
12. 投资成本
在制定计划的各阶段过程中要收集大量的数据，这些数据对计划的制定及运行维护非常
必要。市场上有些产品支持灾难恢复计划的制定、测试和维护，在项目实施过程的阶段二中
应对这些产品进行评估。最终成本取决于所选择的产品。其它的一次性成本可能包括购买建
立语音和数据冗余系统的相关设备、数据处理设备(包括个人电脑)、数据处理应急设备、备
份设备(包括 UPS、发电机等)和业务相关设备(复印机、传真机等)。
13. 运行成本
运行成本包括租金、服务合同和合同维护。这些成本有些很难提前估计，但包括以下：
（1）现场合同；
（2）灾难恢复计划软件维护合同；
（3）与灾难恢复、备份设备及服务相关的服务和维护费用。
影响灾难恢复计划实现效果的因素
以下所列各项因素都会影响灾难恢复计划的实现效果：
（1）灾难恢复计划是否可行；
（2）计划所涉及的人员和设备等资源是否能够及时到位；
（3）计划是否被经常演练并为全体有关人员所熟知；
（4）当发生人员调整、设备更新等情况导致企业内部结构发生改变时，计划能否被及时更
新；
（5）是否采取了当前最先进的灾难恢复技术。
