“删库” 事件将引发快速构建低成本云安全灾备架构

“删库”事件，不只一次发生，这次突发事件影响很大，影响的不只是6天144小时的服务暂停、10亿港币蒸发，约300万商户苦苦等待，还有SaaS信息系统重大突发事件处理经验和教训，以及企业对灾难备份重视。其实，类似事件时有发生是有原因的。按照海因里希安全法则，此类事件属于300∶29∶1法则中的1/330。这个1/330从信息系统的视角分析。这意味着：当一个企业的信息系统持续有300起安全隐患或违规问题，非常可能要发生29起轻度问题或故障事件，另外还有一起突发的重大信息系统事故。

参照海因里希安全法则，无论是传统基于数据中心的架构的信息系统，还是基于云架构的SaaS信息系统，都会面临同样的风险，同类的事件。依据《中华人民共和国突发事件应对法》，参照中国银监会《银行业重要信息系统突发事件应急管理办法》的要求，“删库”事件属于人为破坏类事件，按照判断标准，如果事件影响用户规模覆盖两个省，业务无法正常开展达3个小时以上，或者用户规模覆盖一个省，业务无法正常开展达6个小时以上，就属于I级特别重大突发事件，也是最高等级突发事件。

从安全风险评估视角分析，一个重大安全事件发生，不是单个漏洞导致的，是由至少3个以上漏洞才导致发生重大事件的。所以，重大突发事件暴露问题或漏洞不是单方面的原因，而是多个方面原因长时间没有发现或得不到解决引起的。从安全管理体系的人、策略、流程、技术等四个维度分析。

首先，可能是人的问题，即数据库或系统运维人员的权限管控不严、或没有对特权人员进行岗位轮换和发展提升；

其次，可能是策略问题，即可能没有制定核心业务数据库的备份、存储和验证的策略，或者没有为重要数据库突发事件制定应急恢复和响应策略；

第三，可能是流程的问题，即没有制定远程登录维护的操作权限的审批流程、操作复核流程，或者没有制定重大突发事件应急演练流程；

第四，可能是技术的问题，即没有为数据库在启用的时候配置防删除安全功能，或没有为数据库远程登录密码提供双因素分开申请功能。

作为云服务商，我们无法代替客户管理自己的系统和数据库，也无法为我们客户恢复数据和系统。但是我们可以为客户提供多层面的数据安全保障功能选项和灵活多样的灾难恢复安全架构，以及自动化的恢复模版和高效的数据拷贝和恢复方案。

在AWS云平台上，企业可以根据业务规模和实时性，更容易选择多种方式灾备架构，更低的成本构建云安全灾备架构。如果客户使用AWS的EC2、Amazon Aurora、RDS、DynamoDB、MySql、CloudEndure等服务，在部署和启用的新服务器和数据库的时候，客户可以选择防删除的功能选项，同时客户还可以选择服务器的操作系统和数据库的定期的镜像快照选项，还可以把镜像透明加密并快速的复制到不同区域用于恢复和开拓新业务市场，通过专属、专用可轮换的数据密钥加密存储数据、镜像，保证在不同网络区域安全的恢复镜像快速和安全；以便在发生突发重大事件的时候，可以快速、安全恢复数据、恢复系统、恢复应用、恢复业务。客户甚至可以选择把已经安装好应用和数据库的操作系统，创建成一个AMI镜像模版，快速的在服务器上快速启用AMI镜像，快速的恢复系统、应用、数据和业务。所以在云上，客户可以更高效、更安全、更低成本购构建云上高可用应用架构的同时，也可以构建低成本的灾难恢复架构，在云上无论何时，企业都可以设计、构建、测试、实施和关闭不同等级的云安全灾备架构。

从业务连续性管理(Business Continuity Management,简称”BCM”)视角分析，企业的突发的重大信息系统事件，在参考《公共安全业务连续性管理体系要求》（GB/T30146-2013）国家标准（等同采用国际标准ISO22301:2012），按照国标《信息系统灾难恢复规范》(GB/T 20988-2007)对信息系统的灾难恢复的6个等级分类，微盟“删库”事件应属于重要信息系统，而且是在线实时为微商客户提供服务；所以其灾难恢复等级应至少定为灾备“等级五”，即实时数据传输及完整设备支持，对数据要求是每天至少进行一次完全数据备份，且备份介质场外存放外，还要求采用远程数据复制技术，利用通信网络将关键数据实时复制到备用场地。其中信息系统灾难恢复能力等级五的恢复时间目标（RTO）是数分钟到2天、恢复点目标（RPO）是0到30分钟。

AWS云平台上灾难恢复资源7个要素

那么在企业根据自己应用系统服务客户规模和业务时段，明确了灾备建设中灾难恢复能力等级等级和目标之后，需要重点关注的问题是在具体建设中应该考虑在需要哪些资源要素。在AWS云平台上，灾难恢复关键AWS服务资源，包括区域（Region）、存储（Storage）、服务器（EC2、AMI）、网络、数据库、部署流程和复制服务等。企业需要云平台上构建灾备中心需要的资源7个要素与AWS服务资源对应关系，如下表所示：

AWS云平台上4个灾难恢复方案

图1: AWS 四个可选灾难恢复方案

对于灾难恢复方案选项，当企业从“备份和还原”选项（左）移至“多站点”选项（右）时，RTO和RPO随着成本的增加而降低，如图1所示。

方案1: 备份与还原

AWS可用于以经济高效，持久和安全的方式备份数据，以及快速，可靠地恢复数据。

备份阶段

在大多数传统环境中，如果发生中断或灾难，则数据会定期备份到磁带上并定期发送到异地，这需要更长的时间来恢复系统。

1. Amazon S3可用于备份数据并执行快速还原，也可从任何位置使用
2. 通过将存储设备绕过Internet直接直接运送到AWS，AWS Import / Export可用于传输大型数据集
3. Amazon Glacier可以用于归档数据，其中几个小时的检索时间足够并且可以接受
4. AWS Storage Gateway可以将本地数据卷的快照（用于创建的EBS卷）透明地复制到S3中进行备份。它既可以用作备份解决方案（网关存储的卷），也可以用作主数据存储（网关存储的卷）
5. AWS Direct connect可用于始终如一地将数据直接从本地直接传输到Amazon
6. Amazon EBS卷，Amazon RDS数据库和Amazon Redshift数据仓库的快照可以存储在Amazon S3中

图2:从数据中心主站备份到AWS云上S3存储桶

恢复阶段

然后备份的数据可用于快速还原和创建Compute和Database实例

图3:将系统或数据从存储桶S3备份恢复到EC2

备份和还原的关键步骤：

1. 选择适当的工具或方法将数据备份到AWS中。
2. 确保对此数据采取适当的保留策略。
3. 确保对此数据采取适当的安全措施，包括加密和访问策略。
4. 定期测试此数据的恢复和系统的恢复。

方案2:指示灯(冷灾恢复备份和恢复)

在“试点轻型灾难恢复”方案选项中，最低版本的环境始终在云中运行，该版本基本上托管了应用程序的重要功能，例如：数据库

用这种方法：

1. 通过在AWS中配置和运行系统中最关键的核心元素（例如需要复制和保持数据的数据库）来维护指示灯。
2. 在恢复过程中，可以围绕关键核心快速配置（例如，应用程序和Web服务器的）全面生产环境（使用预配置的AMI和EBS卷快照）
3. 对于网络连接，可以使用ELB将流量分发到多个实例并使DNS指向负载均衡器，也可以使用与实例关联的预分配弹性IP地址
4. 准备阶段步骤：
5. 设置Amazon EC2实例或RDS实例以复制或镜像数据关键数据
6. 确保所有支持的自定义软件包在AWS中都可用。
7. 创建和维护需要快速恢复的关键服务器的AMI。
8. 定期运行这些服务器，对其进行测试，然后应用所有软件更新和配置更改。
9. 考虑自动化AWS资源的调配。

图4: 指示灯场景准备阶段

恢复阶段的步骤：

1. 从自定义AMI启动应用程序EC2实例。
2. 调整现有数据库/数据存储实例的大小以处理增加的流量，例如，如果使用RDS，则可以轻松地垂直扩展它，而EC2实例可以轻松地水平缩放
3. 添加其他数据库/数据存储实例以在数据层中提供DR站点的弹性，例如，为RDS启用多可用区以提高弹性。
4. 更改DNS以指向Amazon EC2服务器。
5. 最好以自动化方式安装和配置任何非基于AMI的系统。

图4: 指示灯场景恢复阶段

方案3:暖待机

在热备用灾难恢复场景中，与业务关键系统相同的全功能环境的缩减版本始终在云中运行，此设置可用于测试，质量保证或内部使用。万一发生灾难，可以轻松扩展或扩展该系统以处理生产负荷。

准备阶段步骤：

1. 设置Amazon EC2实例以复制或镜像数据。
2. 创建和维护AMI以加快配置速度
3. 使用最小的EC2实例或AWS基础设施运行应用程序。
4. 根据企业的实时环境修补和更新软件和配置文件。

图5: 热备份场景准备阶段

恢复阶段步骤：

1. 使用负载平衡器增加服务中的Amazon EC2机队的规模（水平扩展）。
2. 根据需要在更大的Amazon EC2实例类型上启动应用程序（垂直扩展）。
3. 手动更改DNS记录，或使用Route 53自动运行状况检查将所有流量路由到AWS环境。
4. 考虑使用Auto Scaling调整机队大小或适应增加的负载。
5. 添加弹性或扩大数据库规模，以防止灾难性灾难减少

图6: 热备份场景恢复阶段

方案4:多站点

Multi-Site是一种主动-主动配置灾难恢复方法，其中相同的解决方案在AWS上作为企业的现场基础架构运行。通过使用DNS服务加权路由方法，可以按需将流量平均分配到两个基础结构。在发生灾难的情况下，可以调整DNS以将所有流量发送到AWS环境，并相应地扩展AWS基础架构。

准备阶段步骤：

1. 设置企业的AWS环境以复制生产环境。
2. 设置DNS加权或类似的流量路由技术，以将传入请求分发到两个站点。
3. 配置自动故障转移以将流量重新路由到受影响的站点之外。例如，应用程序检查主数据库是否可用（如果不可用），然后重定向到AWS DB

图7: 多站点场景准备阶段

恢复阶段步骤：

1. 手动或使用DNS故障转移，更改DNS权重，以便将所有请求发送到AWS站点。
2. 具有故障转移的应用程序逻辑，以将本地AWS数据库服务器用于所有查询。
3. 考虑使用Auto Scaling自动调整AWS舰队的大小。

图8: 多站点场景恢复阶段

AWS云平台上灾难恢复服务的使用场景

CloudEndure Disaster Recovery是一种自动化的IT弹性灾难恢复解决方案，旨在帮助企业最大程度地减少停机时间和数据丢失。CloudEndure提供了高度自动化的灾难恢复和迁移到AWS的解决方案。

借助对任何源基础架构和在支持的操作系统上运行的所有应用程序的支持，CloudEndure可以确保您的整个IT格局随着其不断增长而保持强大和可靠。

CloudEndure Disaster Recovery可让企业从意外的基础架构或应用程序中断，数据损坏，勒索软件或其他恶意攻击中恢复环境。它利用了块级连续数据复制功能，该功能可确保在灾难或钻探期间将目标计算机以最新状态启动，从而使组织可以实现亚秒级恢复点目标（RPO）。这种连续数据复制在AWS的低成本暂存区域中进行，以将计算和存储空间降至最低。万一发生灾难，CloudEndure会触发高度自动化的机器转换流程和可扩展的编排引擎，该引擎可以在几分钟之内启动目标AWS区域中的机器。

块级复制实质上涵盖了受保护系统的各个方面，包括操作系统，配置文件，数据库，应用程序和数据文件。CloudEndure Disaster Recovery可以复制在支持的Linux或Windows版本上运行的任何数据库或应用程序，并且通常与Oracle和SQL Server等企业应用程序一起使用。如果企业执行从AWS到AWS的复制，则会复制指定VPC内的AWS环境；其中包括VPC本身，子网，安全组，路由，ACL，Internet网关和其他服务组件。基于CloudEndure Disaster Recovery构建的适合企业数据中心和其它云服务平台的推荐灾备架构如下：

根据不同企业的核心业务部署模式，企业可以选择多种方式构建低成本的灾难恢复架构，列举三个场景如下：

场景1:本地数据中心到Cloud Disaster Recovery

此场景将辅助企业数据中心构建Cloud Disaster Recovery，而不会造成停机时间或性能影响。企业可以提高可靠性，可用性和安全性，而不必投资购买重复的硬件，网络或软件。

场景2:跨区域灾难恢复

如果企业的应用程序已经在AWS上，则可以通过设置跨区域灾难恢复来增加一层具有成本效益的保护，并提高业务连续性。可以在区域或可用区之间设置连续复制，并满足严格的RPO（恢复点目标）或RTO（恢复时间目标）要求。

场景3:跨云灾难恢复

如果企业在其他云上运行工作负载，则可以通过将AWS用作灾难恢复站点来提高整体弹性并满足合规性要求。CloudEndure Disaster Recovery将复制和恢复企业的工作负载，包括自动转换源服务器，以便它们在AWS上本地启动和运行。

AWS今天将CloudEndure Disaster Recovery的价格降低了约80％，恢复快速而强大，使其比以往更具成本效益：每小时0.028美元，或每个服务器每月20美元。

如果企业尝试以传统方式实施灾难恢复解决方案，那么企业将知道它需要一组昂贵的重复IT资源（存储，计算和网络）和软件许可证。通过将工作负载复制到首选AWS区域中的低成本暂存区中，CloudEndure Disaster Recovery可以将计算成本降低95％，并且无需为重复的OS和第三方应用程序许可证付费。

除了AWS CloudEndure灾难恢复服务。AWS提供了很多第三方灾难恢复管理服务，尽管许多公司永远不会使用其中的大多数服务，但在大多数用例中，都会为企业提供选项。但是拥有选项并不意味着企业必须完全依赖AWS。相反，企业可以考虑使用AWS Marketplace中提供的一些第三方工具，无论是用于灾难恢复还是完全用于其他目的。N2WS备份和恢复是适用于AWS的顶级备份和灾难恢复解决方案，可创建高效的备份并以较低的总拥有成本满足积极的恢复点和恢复时间目标。N2WS备份和恢复提供了将快照移动到S3的功能。这项新功能使组织可以节省大量成本以及更灵活的数据存储和保留方法。

AWS云平台上灾难恢复方案两个基础实践

基础实践1: 用云存储替代磁带备份

准备事项：

AWS 账户：您将需要一个 AWS 账户来下载 AWS Storage Gateway 以及创建 VTL 和虚拟磁带。注册 AWS。

管理程序和主机：最简单的方法是在本地将 AWS Storage Gateway 作为虚拟机 (VM) 运行。

技能水平：建议（但不强制要求）具备存储和备份技术、联网、虚拟化、备份工具和磁带解决方案方面的经验。

AWS 使用经验：无需具备 Amazon S3、Glacier 或S3 Glacier Deep Archive 使用经验。

实现目标：

磁带介质管理、介质成本、第三方异地合同以及大量的数据增长使磁带备份成为各个组织面临的挑战。AWS Storage Gateway 服务提供了磁带网关配置，能够与您当前的备份流程无缝集成，取代物理备份磁带。现在，您拥有磁盘的本地性能、低成本且高度可扩展的云后端，并且可以最大限度地减少现有系统的中断。

在网关的虚拟磁带库中创建虚拟磁带。 虚拟磁带存储在 Amazon S3 中，可以通过 VTL 接口供备份软件使用。这可以取代磁带和磁带自动化，因此您可以将云用作备份目的地，并尽可能减少现有系统和流程出现的中断。

使用现有备份软件备份到这些虚拟磁带。 借助磁带网关，您可以向云中备份，同时保留现有的软件许可投入、备份作业和目录。

使用 Amazon S3 Glacier 和 Amazon S3 Glacier Deep Archive，通过长期存档存储降低成本。您可以使用备份软件将虚拟磁带迁移到 Amazon S3 Glacier 或 Amazon S3 Glacier Deep Archive，以便进一步降低成本。

基础实践2: 将PB级数据迁移到云

如果企业计划在应用程序迁移或数据中心关闭期间将数据迁移到云中，则会遇到数据传输的硬限制。如果Internet 速度不足以支持数据迁移计划，企业应该考虑使用 AWS Snowball。借助 Snowball 设备，能够以比 Internet 速度更快的速度将档案、数据湖以及企业拥有的任何数据迁移到 Amazon S3 存储桶中。

准备事项：

大量数据：Snowball 经过专门设计，适用于进行大规模数据传输。为了实现成本效益，如果企业想将至少12TB的数据迁移到云中，建议使用 Snowball。

AWS 账户：需要一个 AWS 账户才能开始预置 Amazon S3 存储桶，以便存储数据并申请 Snowball 设备。

AWS IAM 用户：设置一个 AWS Identity and Access Mangement (IAM) 用户以访问 Snowball。

IT 技能：需要对存储和联网技术有大致的了解，并熟悉适用于 Linux、Mac 或 Windows 的命令行界面。

AWS 使用经验：无需具备 AWS 使用经验即可使用本指南。

实现目标：

使用 AWS 控制台创建一个数据导入任务。然后，AWS 会准备 Snowball 设备并将其寄送到您指定的地址。

使用客户端将数据传输到 Snowball。然后将 Snowball 寄回到 AWS。Snowball 上集成式电子墨水标签可以自动更新寄回地址，可使您更加轻松。您无需对 Snowball 进行包装，因为 Snowball 自带包装箱。

企业可以看到数据已安全地导入云并存储在 Amazon S3 中。收到企业寄回的 Snowball 之后，我们会将企业的数据导入 Amazon S3 存储桶。数据导入完毕后，我们将遵循 NIST 介质清理准则对 Snowball 设备进行数据擦除，以保护企业的数据。

将数据迁移到 AWS 中的总成本会有所不同，具体取决于要迁移的数据量。设备的服务费为 250 USD。将数据传输到 Amazon S3 是免费的。

本篇作者