酷应用

云迁移及云端安全防护指南

百家作者：InfoQ 2019-01-07 09:46:38

近年来，越来越热的云计算被推倒风口浪尖，各大中型企业纷纷把企业服务迁移到云上。从进取到保守，云的扩散，让传统行业用户已然开启了奋起直追的模式！但如何保障云迁移过程中业务连续不中断？如何合理的调度和编排资源，大幅提升效率？云费用的潜在浪费点在哪里？公有云和私有云的统一安全与通信安全如何保障？

10 月至 12 月，ChinaMSP 资深云计算架构师携手极客邦科技 InfoQ 布道南京、成都、北京、上海及深圳，来自 ChinaMSP、Fortinet、AWS 的四位技术专家分别就“基于零业务终端的云迁移探索与实践”、“针对云管理及云费用优化的最佳实践详解”、“混合云环境下的安全挑战与防护指南”以及“AWS 云服务及混合 IT 架构实践”主题详解了相关技术与应用，为企业量身定做一站式云化解决方案，助力企业 IT 快速上云。InfoQ 对本专场的精华内容做了部分梳理和总结。

基于零业务终端的云迁移探索与实践

现如今，云已经成为一个必选项。云迁移已然不仅仅是虚机迁移、数据迁移和应用迁移，它的目标是业务迁移，让业务转型数字化，更加敏捷，进而让企业敏捷。完整的云迁移应该包括四个步骤：

分析评估，一切都是从了解分析开始的，在迁移之前，对现有系统环境进行完整分析，对应用的云化程度，以及成本和风险等项目进行评估；
计划和设计，定义目标基础设施环境的架构选择适当迁移工具和迁移模式，制定清单，分解任务，规划迁移节奏；
迁移实施，按照既定的方式进行迁移、测试和割接；
运行优化，整体调优。

在整个过程中，前期的评估和规划是迁移能否成功的重要前提。针对云化成熟度不同，迁移策略也会有所不同。通常云化成熟度指的是应用改造后的目标态，依据它们与云环境下最优适配的原生应用的差距，有时将它们以颜色来区分: 褐色 (Brown)、蓝色 (Blue) 和绿色 (Green)。

从实践上看，对于已经部署在企业私有数据中心的非云环境下的应用来说，绝大多数应用可以在不修改应用代码和配置的情况下改造成褐色的 ; 改造成蓝色的需要对应代码或配置做非常小的“外科式”改动 ; 但改造成绿色的，应用架构和代码需要做很大的改动。可以说改造的难度基本是数量级提升的，但能够获得的上云的收益也相应有很大的差别。

对此 ChinaMSP 根据应用云化的成熟程度不同，将迁移方法论总结为“5R”：

Retain：不迁移，保留在现有环境下
Rehost：对托管的基础设施进行适配（操作系统的存储、网络驱动 ; 计算的规格、存储的等级等），尽量做少的客户 OS 之上可感知的改变。通常尽量通过工具自动实现大部分重复的、耗时的工作。Reflatform: 根据目标的云平台进行一些应用代码或配置可感知的少量变化，以好地使用云平台。如与自动化配置相关的 cloud init 、监控相关的 agent 部署、安全相关的 4A 纳管、运行环境相关的中间件 / 运行库标准化等。但更典型的数据库转换，从传统数据库转换到为云优化过的 RDS 服务或更适合云环境的商业数据库版本 (如 Oracle 12c 等)。
Refacor/Reengineering : 以云原生应用为参考，对应用架构进行重构，代码进行部分重写。
Retire/Repurchase: 转换为购买 SaaS 服务的模式。

应用 5R 迁移方法论，中国 MSP 行业翘楚 ChinaMSP 推出了 MigFlash 迁移方案。

MigFlash 通过一系列的组合，把技术的复杂度通过软件工具体系的方式隐藏起来，使得最终迁移的项目获得非常敏捷易用的效果。具体来说：

针对源生产环境影响：

第一，无代理，消除对源生产环境的入侵；第二，没有安装代理，通过 VMware 的 CBT 或者快照技术进行磁盘的复制；第三，从复制的过程里面还是可能不是从虚机里读，优先使用 LAN 加速的方式，从虚拟化的存储层直接复制，不通过 ESXi 服务器，从而对整个环境影响最低。

针对“网络带宽”的挑战，优化分为四个方面：

离线全量＋网络增量，即从源端拷贝到 NAS 上，之后把 NAS 带到云端，网络的增量通过广域网传输；
复制保护点的时间周期：广域网上传的增量支持去传递一个固定时间周期，这两个时间节点的差分，中间过程的变化其实都不用去传递了，这也是来控制网络上面带宽里面、优化里面比较有效的途径；
网络压缩、去重；
过滤 SWAP 分区：在运行的系统里面的，大多数里面对磁盘的变化至少一半以上是 SWAP 内存里面的数据。这些数据在转换的过程里完全可以屏蔽掉。经过四项全面优化以后，广域网上传输的带宽的要求可以节省到 90% 以上。

针对“虚拟化平台转换”的挑战：

转换是通用性问题，能不能适配更多目标环境和源端的操作系统，但是更重要的一点在平台转换以后，甚至上云以后有没有自动化管理的 Agent 和新上的云管平台进行一些配合的。MigFlash 迁移方案在智能驱动、OS 配置、代理替换 / 安装三个部分都有

针对“可恢复性与数据一致性”的挑战：

源端的虚机还在运行业务，数据不停的在写磁盘。特别是 Windows 环境，大多数里面数据还在缓存里面并没有落到磁盘里面，这时候磁盘复制过去的是脏数据，并不能保证数据的一致性，在目标端机器起来以后，机器可能能够起来，但是数据库就打不开了。

解决方式主要是利用微软的 VSS 的影像的技术，每次做复制的时候，先让源端瞬时暂停对磁盘的读写，并且把内存里的数据复制到硬盘里面，然后产生可恢复的快照点以后，把快照点的数据慢慢传输到远端，传的过程里面原系统可以继续进行运行。这样的话既能保证数据的一致性，而且暂停时间，也是毫秒级的。

混合云环境下的安全挑战与防护指南

云服务是数字化转型的支柱，但它们也成为许多安全架构师们在安全建设之路上的荆棘。

多云环境带来的安全挑战与现有安全部署之间的不对等

云的孤岛阻碍了网络可见性与威胁响应速度。安全团队的任务是保护整个企业应用程序和数据资产。虽然他们通过云提供商的门户网站可以看到每种云部署，但通常没有统一的视图来查看所有云中的威胁。同样，无法立即评估在一个孤立的云中对整个威胁组织的潜在影响。
不可预期的管理负担。大多数企业不会同时创建多云环境。相反，他们一次订阅一个云服务。每个云服务都有自己的安全规定和管理工具。这造成了一些行政上的负担，例如管理负担，以及合规性的考量；以及随着每个云应用程序的自主发展和运营，企业安全团队需要在所有云中传播企业安全策略的变化，并将企业安全技术与每个云提供商的安全技术集成。
安全覆盖落后于基于云的应用部署。云服务的大部分价值在于使组织能够快速部署和扩展应用程序。业务线经理可以在云中部署应用程序，并在几分钟内将信息移到异地。随着 DevOps 的采用，企业现在可以快速推出新的软件更新。使用单个云确保通过这种加速部署实现防水安全覆盖是很困难的，尤其是在安全配置不是自动化的情况下。多云部署会使问题成倍增加，结果是 IT 和安全管理人员的痛苦折衷。
人力的投入是不能赶超高级威胁的进化的。在如今紧俏的安全劳动力市场中，企业如果能够招聘到足够的有才能和经验丰富的员工，那就很幸运。然而，即使是最优秀和最聪明的安全专家也无法跟上在数量，速度和复杂性方面爆发的威胁 - 除非他们在正确的架构中拥有合适的技术。

面对以上挑战，Fortinet 所倡导的 Security Fabric 架构能够防御来自主要攻击平面的威胁，包括云端、移动端、终端。Security Fabric 内的安全组件的协同与统一管理成为关键。 Security Fabric 将安全的配置实现扩展至私有云及公有云平台，给客户带来更广泛的选择性同时，降低了使用难度，同时具备了全局的可视化。

这也就是说， Fortinet 现有的安全架构及方案整合了不同的安全场景，提供了一致的安全能力，并且架构是完全开放的，客户能够自动化地实现不同安全防御技术之间的智能协同，无论在公有云或是私有云上，实现统一的安全。

需要强调的是， Fortinet 的产品与解决方案并不针对某个特定的供应商，而是支持多数主流的云平台。现在很多客户的云环境都是“多云”的状态，如果不能在生态层面实现对尽可能多的云平台的支撑，安全防护的效果必然大打折扣。

在活动中，Fortinet 的技术专家还为开发者介绍了云上常规的部署模式以及云上的自动扩展模式。如下图所示是 AWS 的 WAPC 架构。

两个 AZ 的 FW（防火墙）与 WAF 工作在 AA 模式
与 FW（防火墙）与 WAF 完全集成将 HTTP 转至 WAF
入向流量通过 ELB 负载分摊
FW（防火墙）开启 NGFW 威胁检测功能
WAF 对 HTTP 流量进行深度检测
FW（防火墙）将流量映射至内部 ELB FQDN
WAF 将 HTTP 流量映射至内部 ELB

对于 NGFW 来讲，用户、应用、DDOS、病毒攻击，这个是 NGFW 天生具有的属性，一旦上云以后，这个上面会做相应的事情保证你云的安全。

如下图所示为云上的自动扩展的模式，以 AWS CloudWatch 为例。CloudWatch 创建自动扩展消息，CloudWatch 通过 SNS 通知 Lambda，Lambda 在 Autoscale 成员中增加 FW 并通过 API 通知 FW 同步配置，FW 同步完配置通过 API 通知 Lambda，最后 Lambda 更新 ELB 配置。

此外，Fortinet 扩展了 Transit Security Hub 概念，即把所有安全的功能集中在一个 Security Hub 管理。Security Hub 可对 VPC 的流量以及不同的云进行相应的安全过滤，并支持自动扩充。当 Hub 里面的流量增大，可以自动进行相应的拉升，扩充 Security Hub 安全的能力。

Transit Security Hub 适用于对组网有严格的要求；应用场景复杂，有多 VPC 的需求；对于安全策略的管理有严格的要求，需要集中管控的场景。并且适合对于应用系统以及 Web 应用的安全有严格的要求，需要将系统安全和业务安全分离；安全策略的管理要求严格统一；需要监控 VPC 之间的流量业务安全的安全需求。