月度归档: 2019年9月

企业上云后面临的三大安全管理挑战和应对策略

前言

CSA于2018年12月至2019年2月在网上,向来自不同组织规模和地点的近700名IT和安全专业人士,大约500个组织进行了关于企业上云及云上安全管理等20个问题的调查。调查发现,许多组织将越来越多的工作负载迁移到基于云的资源,包括混合环境、多云环境以及两者的组合。这些组织还致力于将来自公有云和私有云服务提供商的各种应用程序与它们自己的内部资源集成在一起。(此部分内容,详见《CSA证实混合云和多云策略将是企业未来的主要云策略》一文)。

随着云计算环境变得更加复杂,企业将面临怎样的挑战,又将如何应对呢?作者根据CSA的调查报告进行分析,得出以下的结论,与大家分享。

挑战一:安全问题挑战

在调查中,大约有81%的受访者表达了将数据转移到云计算时对安全性的担忧。可见安全是企业使用云计算道路上最大的拦路虎。

受到企业高度和中度以上关注的安全问题,包括:

注:上图翻译自CSA报告原图

用户高度重视的六大安全挑战

由于多云和混合云的复杂度增加,在安全方面,企业也遇到相当多的挑战。调查发现,企业普遍认为下述安全挑战已经需要引起他们的高度重视,下面我们按照用户的关注度级别从高到低,进行排列:

  1. 对错误配置和安全风险的主动检测
  2. 整体云资产缺乏可见度
  3. 合规性和审计要求
  4. 同时管理云和本地环境
  5. 管理多云环境
  6. 缺乏对云原生安全架构的经验

调查报告显示,企业认为,最大的挑战是如何主动检测出错误配置,识别安全风险,而整体云环境的可见性被列入第二位。

挑战二:合规性和法律方面的挑战

除了常见的合规框架(如ISO 27001、PCI-DSS、HIPAA、SOX、NIST 800-53),云服务提供商还在不断升级服务和平台,以符合新的监管政策和行业标准,如新的欧洲通用数据保护法规(GDPR)和CSA安全、信任、保证、风险(STAR)。近年来,很多政府都已经加强了对违反安全的行为的执法,并加大了惩罚力度。而我国2019年5月10日发布的信息安全技术网络安全等级条例中,也开始对云计算专门制定了等级保护要求。(此部分,详见《等保2.0对云计算的安全设计技术要求》一文)

与此同时,使用云服务的客户可能不确定谁应对此类安全违规行为负责。超过一半的受访者(57%)对合规性表示担心,近一半的受访者表示在采用公有云服务时,对法律问题感到不安(44%)。对于客户如何利用这些平台来遵守法规,以及谁应该为违反法规的行为负责,仍然存在很多不确定性。

企业需要了解行业和政府法规的政策法规要求,了解企业IT环境架构正在使用的服务和平台对法规的遵从情况,改进复杂环境中系统的安全性,达到合规要求。无疑,这将是一个非常大的挑战!

挑战三:专业的安全组织和人员培训

由于很容易访问云服务,组织中的每个单独的业务部门对其使用的服务有更多的控制权和所有权。随着这种服务使用的增加,组织必须确定哪个部门将负责安全性。关于此问题,调查报告显示:大多数受访者(79%)表示,他们的IT部门拥有这项管理权。在这些回复中,只有16%的人表明他们的IT部门有专门的云安全团队。与此同时,其余的应答者依赖于其他安全服务,如DevOps或托管服务提供者。安全服务与云服务一样容易获得,且更加迅速,应该考虑在整个组织中共享安全责任,让每个业务单元了解它们使用的每个服务的安全问题。

使用多云和混合云环境可以提供许多好处,同时也增加了保护这些环境的复杂性。随着云计算环境变得更加复杂,IT专业人员必须能够看到基于云的资源,并能够信任自己的安全人员和云服务提供商人员的专业知识。云计算的迅速普及以及技术的复杂性,造成了云安全技能方面人员的巨大缺口。

在调查报告中,也显示了这一点。其中,大约三分之一的受访者表示缺乏专业知识,四分之一的受访者表示缺乏管理云环境的员工。这项调查的一半受访者对将公有云与其现有IT基础设施集成表示担忧。此外,调查报告表明,在一个2017年的调查中发现,已经使用混合云的受访者中,61%的人表示,跨混合环境的安全一致性管理是他们组织面临的最大挑战之一。随着多云平台使用的明显增加和向公有云环境的转移,技能差距问题将越来越明显!

因此,如何快速建立专业的云安全团队,并培养云安全技能人员将是企业的一大挑战!

有趣的是,在调查报告中,很多企业不约而同表达了此方面的担心。在调查中,被调查者被问到在过去12个月是否经历过安全事件,其中报告经历过安全事件的44%的受访者,都不约而同对缺乏管理云安全的人员表示了担心!

应对策略一:使用安全管理工具和安全策略

为了更好地理解组织是如何进行这些复杂环境下的安全管理的,调查对象被问到他们使用什么网络安全控制来保护他们的公有云部署。大多数受访者报告,使用多个安全控制来管理他们的公有云部署,最流行的选择是使用云服务提供商自带的安全控制软件,此方面调查者占70%。在2017年进行的一项类似研究中,只有大约四分之一的受访者使用他们的云服务提供商的自身的安全工具。

注:上图翻译自CSA报告原图

同时,安全管理也被做为应用程序设计的基本要求。调查报告表明,59%的企业要求将安全管理作为应用程序设计的一部分。当被问及他们在公共云应用程序编程过程中,使用什么来管理安全性时,答案是多样的:其中32%,选择了编程和配置管理工具,29%选择了云原生工具,还有13%采用了云服务提供商的API开发的脚本。

早期发现潜在的安全风险仍然是安全管理的一个重要方面。用于检测和管理这些风险或漏洞的工具对于早期检测非常重要。在这项调查中,约三分之一的受访者使用云服务提供商的风险评估服务来检测和管理漏洞,而近四分之一的受访者使用指定的第三方安全工具。另有五分之一的受访者使用一般风险或脆弱性评估工具。这表明,使用上述工具的不到一半,超出了CSP所提供的范围。

应对策略二:采用合规的技术和云平台

很多公有云服务提供商已经开始提供具有附加可视性和安全性的本地工具,可以满足或已经超过其他传统的安全管理,(例如:内部系统的安全控制)。企业需要了解如何利用云平台和使用提供者工具,以便最大化云的所有好处。云服务提供商继续提供具有附加可视性和安全性的本地工具,经常满足或超过其他传统(内部和第三方)安全控制。云服务提供商平台和服务,将满足行业和政府法规的一些更严格的合规要求。

将企业的IT环境架构在合规的技术和平台上,允许企业使用云平台本身提供的相关工具,以改进复杂环境中的安全性和内置遵从性,将帮助企业的系统满足相关的法律法规要求。

应对策略三:安全责任分担和自动化手段

云服务提供商和客户IT管理团队应该能够清楚地说明他们的安全目标,并建立一个可由双方度量和共享的安全需求基线级别。这种分担责任的办法可以大大提高透明度,并有助于进一步遵守安全条例和最佳做法。在将组织的任何重要资源迁移到供应商的云之前,客户必须与云服务供应商建立信任。

除了与云服务提供商建立共享的安全责任之外,企业的每个单独的业务单元还应该对其组织建立的安全目标有一定程度的了解,确定一个负责云安全的独立部门,跨业务单元建立云安全策略,提高全体员工的教育水平和意识,完成了现代化的共享责任模式。在企业中,数据所有者被要求负责包括外部业务伙伴和内部业务单元在内的数据安全性。

由于许多功能在云中得到扩展,现有和未来的安全风险和漏洞可能也会扩展。云服务提供商在不断努力提供更多的安全特性,而企业做为最终用户,也在努力增加人员和专家,以运用这些工具进行安全管理。

由于多云和混合云本身的复杂度,在云服务操作中,需要对安全管理人员进行培训,同时尽可能的利用自动化手段,避免人工操作的失误。安全组件的自动化,有助于解决缺乏管理高端云安全技能人员的问题。

日志活动、数据聚合、威胁检测和安全策略管理,这些工具和策略,只能解决识别安全漏洞、遵从性违规、服务错误配置、服务中断和其他异常行为的一小部分安全问题。当我们希望加快使用云环境中的新技术、设备和管理用户时,自动化工具有望帮助企业及其员工跟上未来的云上安全运营的需求。

本文参考资料:

Cloud Security Complexity: Challenges in Managing Security inHybrid and Multi-Cloud Environments (2019)

AWS快速部署指南 | Python 3.6 on CentOS

除了AmazonLinux之外,CentOS也是广泛使用的Linux发行版本,本文将介绍如何在AWS的Centos 6和Centos 7镜像基础之上,安装Python3.6的开发环境。

AWS官方未提供CentOS的镜像。我们建议当需要在AWS中使用CentOS时,选择由CentOS.org提供的最新版本的CentOS镜像。

推荐的CentOS镜像

CentOS 6

CentOS.org提供的CentOS6是CentOS 6.10(Final)。登录CentOS之后,可以执行以下命令查看CentOS的版本。

cat /etc/redhat-release

CentOS 6.1默认的Yum源中没有包括Python3.6的安装包,因此无法通过Yum安装Python3.6,因此我们介绍一种下载安装包并手工安装Python 3.6.8的方法。

首先需要安装相关的工具和支持包。如附图所示,

sudo yum install wget -y
sudo yum -y install zlib-devel bzip2-devel openssl-devel ncurses-devel
sudo yum -y install gcc automake autoconf libtool make
sudo yum -y install gcc-c++ gcc
wget https://www.python.org/ftp/python/3.6.8/Python-3.6.8.tgz

安装依赖包

解压缩并执行编译。

tar -zxvf Python-3.6.8.tgz
sudo mv Python-3.6.8 /opt/python36
cd /opt/python36
./configure –prefix=/opt/python36
make && make install

配置并编译

切换到root账户,加入相关Path .

echo PATH=’/opt/python36/bin/:$PATH’ >> /etc/profile
source /etc/profile

配置路径

执行完上述的操作后,Python3.6.8就安装成功了。这个安装包中同样包含pip和virtualenv等组件。安装完成后,可以直接执行以下的命令检查python3的版本。

python3 -V

类似Amazon Linux由于yum默认使用的python2,因此我们并不建议修改系统中python命令默认关联的python程序版本。而是通过使用virtualenv创建单独的Python3开发环境。运行以下的命令将创建一个名为dev的python3工作环境,并在当前目录下创建相应的工作目录。

python3 -m venv dev

可以运行以下的命令进入这个虚拟环境。参考附图所示。

source ./dev/bin/activate

建立Dev环境

CentOS 7

CentOS.org提供的CentOS 7是CentOS Linux release 7.6.1810 (Core)。登录CentOS之后,可以执行以下命令查看CentOS的版本。

cat /etc/redhat-release

CentOS 7之上安装Python3.6.8的方式和CentOS 6完全一致,其他的CentOS和RedHat都可以参考上述的方式安装Python3.6.8开发环境。

AWS快速部署指南 | Python 3.6 on Ubuntu

Ubuntu是另外一个广泛使用的Linux发行版本,本文将介绍如何在AWS的Ubuntu 16和Ubuntu 18镜像基础之上,安装Python3.6的开发环境。

AWS官方提供了两个不同Ubuntu的镜像。

官方的Ubuntu镜像

Ubuntu 16

CentOS.org提供的CentOS6是CentOS 6.10(Final)。登录CentOS之后,可以执行以下命令查看CentOS的版本。

Ubuntu 16已经默认安装了Python 3.5.2,我们需要在保留Python3.5.2的基础之上安装Python3.6,否则Ubuntu 16的某些功能无法正常运行。

sudo add-apt-repository ppa:jonathonf/python-3.6
sudo apt-get update
sudo apt-get install python3.6
sudo update-alternatives –install /usr/bin/python3 python3 /usr/bin/python3.5 1
sudo update-alternatives –install /usr/bin/python3 python3 /usr/bin/python3.6 2

具体的安装过程如附图所示:

设置APT源

Update APT源

安装并配置Python 3.6

执行完上述的操作后,Python3.6.8就安装成功了。同样的,我们建议建立虚拟工作环境。

python3.6 -m venv dev
source ./dev/bin/activate

Ubuntu 18

Ubuntu 18默认已经安装了Python 3.6.8,因此不需要单独安装Python3.6.8。

默认的Python3

但是我们需要通过以下命令安装pip和venv。

sudo apt-get update
sudo apt install python3-pip
sudo apt install python3-venv

更新APT源

安装pip

安装venv并创建DEV环境

完成上述的安装后,我们就可以建立一个工作环境。

python -m venv dev
source ./dev/bin/activate

巧用EC2“本地存储”

Amazon Web Services的用户大多知道,EC2的类型很多。其中m5d、r5d等类型的,跟对应的m5、r5系列有什么区别,知道的人可能少一些。不过看了本文标题也会猜到,这些机型是带有一定容量的本地存储的。按aws不太接地气的用词,叫做实例存储

大家知道,EBS其实不是EC2所在服务器的本地盘,而是从大的分布式存储中划出来、通过网络连到EC2所在服务器的,八成是采用iSCSI等协议映射成EC2的块设备的。好处是独立于特定服务器,这样EC2才可以在不同服务器、甚至不同的机房和机楼之间方便地飘移。

凡事有利就有弊。大家知道,从磁盘上读写大文件有时很占资源,衡量存储性能的最主要指标是吞吐量和IOPS。EBS模式下这俩指标不只取决于磁盘本身、也受网络带宽和波动的影响,而且是受最差的影响。

而所谓的实例存储,就是EC2所在服务器上插着的磁盘,所以性能表现不受网络影响。但是EC2飘走后磁盘带不走,这就是这类存储关机就丢失的内在原因,因为下次开机不见得还跑在原来的服务器上。

这个道理专业IT人员容易理解。一般情况下,EBS跟服务器之间是高速专有网络,网络不一定会成为存储性能瓶颈。所以大多数实际使用场景中,用户对两者的性能差别没什么感觉。但是笔者最近调测一个程序,需要多次顺序读写和处理好几T的文件,执行一遍要等半天,比较痛苦。而且同样数据、同样程序,不同时候执行感觉时快时慢的。这个EC2是东京区域的,初步怀疑受到了同AZ内其他租户业务忙闲的影响。

于是我修改了实例类型,从r5.large改成了r5d.large, 并在操作系统内对本地磁盘创建分区、文件系统,并挂载到程序访问的数据目录。再次跑程序,发现性能还是有明显改善的。

从价格看,带d的系列比不带d的贵不了多少。我的程序输入输出数据都在S3上,本机不需要永久保存数据,EC2跑完程序就会关机。这种情况下采用带d的机型,不但可以提高性能、缩短运行时间,而且关机后也无需为数据盘付费,是个少有的双份好处、没有坏处的选择,推荐给大家参考。

实例存储与 EBS 之间有何区别?

实例存储(Amazon EC2 instance store)User Guide

等保2.0对云计算的安全设计技术要求

2019年5月10日发布的信息安全技术网络安全等级条例,又称等保2.0,该条例将于2019年12月1日正式实施。等保2.0中专门针对云计算进行了相关技术要求。做为云从业者,作者对该标准的安全设计技术要求部分(GB/T25070—2019)的此部分内容进行了拆解,与大家进行共享。

关于安全级别的定义

在标准中定义:“等级保护对象根据其在国家安全、经济建设、社会生活中的重要程度,遭到破坏后对国家安全、社会秩序、公共利益以及公民、法人和其他组织的合法权益的危害程度等,由低到高被划分为五个安全保护等级”。

不同级别的等级保护对象要求的保护能力也不同,级别也是依次升高的。

具体内容见下表:

等保级别 能力要求
第一级安全保护能力 应能够防护免受来自个人的、拥有很少资源的威胁源发起的恶意攻击、一般的自然灾难,以及其他相当危害程度的威胁所造成的关键资源损害,在自身遭到损害后,能够恢复部分功能。
第二级安全保护能力 应能够防护免受来自外部小型组织的、拥有少量资源的威胁源发起的恶意攻击、一般的自然灾难,以及其他相当危害程度的威胁所造成的重要资源损害,能够发现重要的安全漏洞和处置安全事件,在自身遭到损害后,能够在一段时间内恢复部分功能。
第三级安全保护能力 应能够在统一安全策略下防护免受来自外部有组织的团体、拥有较为丰富资源的威胁源发起的恶意攻击、较为严重的自然灾难,以及其他相当危害程度的威胁所造成的主要资源损害,能够及时发现、监测攻击行为和处置安全事件,在自身遭到损害后,能够较快恢复绝大部分功能。
第四级安全保护能力 应能够在统一安全策略下防护免受来自国家级别的、敌对组织的、拥有丰富资源的威胁源发起的恶意攻击、严重的自然灾难,以及其他相当危害程度的威胁所造成的资源损害,能够及时发现、监测发现攻击行为和安全事件,在自身遭到损害后,能够迅速恢复所有功能。
第五级安全保护能力

在标准中,对云计算从一级到四级都给出了非常具体的技术要求。

 

云计算等级保护安全计算设计框架

在等保2.0专门针对云计算等级保护安全给出了要求的安全技术设计框架。

图 1 云计算等级保护安全计算设计框架

在标准中,明确规定:“用户通过安全的通信网络以网络直接访问、API接口访问和WEB服务访问等方式安全地访问云服务商提供的安全计算环境,其中用户终端自身的安全保障不在本部分范畴内。安全计算环境包括资源层安全和服务层安全。其中,资源层分为物理资源和虚拟资源,需要明确物理资源安全设计技术要求和虚拟资源安全设计要求,其中物理与环境安全不在本部分范畴内。服务层是对云服务商所提供服务的实现,包含实现服务所需的软件组件,根据服务模式不同,云服务商和云租户承担的安全责任不同。服务层安全设计需要明确云服务商控制的资源范围内的安全设计技术要求,并且云服务商可以通过提供安全接口和安全服务为云租户提供安全技术和安全防护能力。云计算环境的系统管理、安全管理和安全审计由安全管理中心统一管控。结合本框架对不同等级的云计算环境进行安全技术设计,同时通过服务层安全支持对不同等级云租户端(业务系统)的安全设计。”

由于篇幅限制,我们仅就第三级的安全要求进行介绍。其他级别有增减。

 

第三级系统安全保护设计中对云计算的要求

1、云安全计算环境设计技术要求

标准中要求:“

a) 用户身份鉴别

应支持注册到云计算服务的云租户建立主子账号,并采用用户名和用户标识符标识主子账号用户身份。

b) 用户账号保护

应支持建立云租户账号体系,实现主体对虚拟机、云数据库、云网络、云存储等客体的访问授权。

c) 安全审计

应支持对云服务商和云租户远程管理时执行的特权命令进行审计。

应支持租户收集和查看与本租户资源相关的审计信息,保证云服务商对云租户系统和数据的

访问操作可被租户审计。

d) 入侵防范

应能检测到虚拟机对宿主机物理资源的异常访问。应支持对云租户进行行为监控,对云租户

发起的恶意攻击或恶意对外连接进行检测和告警。

e) 数据保密性保护

应提供重要业务数据加密服务,加密密钥由租户自行管理;应提供加密服务,保证虚拟机在迁

移过程中重要数据的保密性。

f) 数据备份与恢复

应采取冗余架构或分布式架构设计;应支持数据多副本存储方式;应支持通用接口确保云租户

可以将业务系统及数据迁移到其他云计算平台和本地系统,保证可移植性。

g) 虚拟化安全

应实现虚拟机之间的CPU、内存和存储空间安全隔离,能检测到非授权管理虚拟机等情况,并

进行告警;应禁止虚拟机对宿主机物理资源的直接访问,应能对异常访问进行告警;应支持不同云租户虚拟化网络之间安全隔离;应监控物理机、宿主机、虚拟机的运行状态

h) 恶意代码防范

物理机和宿主机应安装经过安全加固的操作系统或进行主机恶意代码防范;虚拟机应安装经

过安全加固的操作系统或进行主机恶意代码防范;应支持对Web应用恶意代码检测和防护的能力。

i) 镜像和快照安全

应支持镜像和快照提供对虚拟机镜像和快照文件的完整性保护;防止虚拟机镜像、快照中可能

存在的敏感资源被非授权访问;针对重要业务系统提供安全加固的操作系统镜像或支持对操

作系统镜像进行自加固。“

2、云安全区域边界设计技术要求

标准中要求:“

a) 区域边界结构安全

应保证虚拟机只能接收到目的地址包括自己地址的报文或业务需求的广播报文,同时限制广播攻击;应实现不同租户间虚拟网络资源之间的隔离,并避免网络资源过量占用;应保证云计算平台管理流量与云租户业务流量分离。

应能够识别、监控虚拟机之间、虚拟机与物理机之间的网络流量;提供开放接口或开放性安全服务,允许云租户接入第三方安全产品或在云平台选择第三方安全服务。

b) 区域边界访问控制

应保证当虚拟机迁移时,访问控制策略随其迁移;应允许云租户设置不同虚拟机之间的访问控制策略;应建立租户私有网络实现不同租户之间的安全隔离;应在网络边界处部署监控机制,对进出网络的流量实施有效监控。

c) 区域边界入侵防范

当虚拟机迁移时,入侵防范机制可应用于新的边界处;应将区域边界入侵防范机制纳入安全管

理中心统一管理。

应向云租户提供互联网内容安全监测功能,对有害信息进行实时检测和告警。

d) 区域边界审计要求

根据云服务商和云租户的职责划分,收集各自控制部分的审计数据;根据云服务商和云租户的职责划分,实现各自控制部分的集中审计;当发生虚拟机迁移或虚拟资源变更时,安全审计机制可应用于新的边界处;为安全审计数据的汇集提供接口,并可供第三方审计。“

3、云安全通信网络设计技术要求

标准中要求:“

  1. 通信网络数据传输保密性

应支持云租户远程通信数据保密性保护。

应对网络策略控制器和网络设备(或设备代理)之间网络通信进行加密。

b) 通信网络可信接入保护

应禁止通过互联网直接访问云计算平台物理网络;应提供开放接口,允许接入可信的第三方安全产品。

c) 通信网络安全审计

应支持租户收集和查看与本租户资源相关的审计信息;应保证云服务商对云租户通信网络的访问操作可被租户审计。“

4、安全管理中心设计技术要求

标准中要求:“

(1)系统管理

在进行云计算平台安全设计时,安全管理应提供查询云租户数据及备份存储位置的方式;云计算平台的运维应在中国境内,境外对境内云计算平台实施运维操作应遵循国家相关规定。

(2)安全管理

在进行云计算平台安全设计时,云计算安全管理应具有对攻击行为回溯分析以及对网络安全事件进行预测和预警的能力;应具有对网络安全态势进行感知、预测和预判的能力。

(3)审计管理

在进行云计算平台安全设计时,云计算平台应对云服务器、云数据库、云存储等云服务的创建、删除等操作行为进行审计;应通过运维审计系统对管理员的运维行为进行安全审计;应通过租户隔离机制,确保审计数据隔离的有效性。“

CSA证实混合云和多云策略将是企业未来的主要云策略

前言

云安全联盟(CSA)是一个非盈利组织,其使命是广泛推广云计算和IT技术中确保网络安全的最佳实践。CSA还负责教育这些行业内的各种利益相关者,让他们了解所有其他形式计算的安全问题。CSA的成员由广泛的行业从业者、公司和专业协会组成。CSA的主要目标之一是进行评估信息安全趋势的调查。这些调查有助于评估信息安全技术在业界不同阶段的成熟度,以及采用安全最佳实践的速度。

领先的网络安全解决方案提供商AlgoSec委托CSA进行一项调查,以增加业界对混合云和多云安全的了解,该调查由CSA于2018年12月至2019年2月在网上进行,向来自不同组织规模(涉及到50人、500人、1000人、2000人、5000人到10000人以上的企业)和地点(涉及南/北美、亚洲、欧盟、东欧、中东和澳大利亚)的近700名IT和安全专业人士提交。大约500个组织回答了20个问题调查的大部分问题。问题涉及到云平台类型,负载比例等各方面,这项调查结果显示了当今云计算环境的复杂性,以及企业各层级对管理安全风险的关注。

笔者对CSA此次调查内容进行了分析,对企业在使用云技术的策略和问题有了三大发现,与大家分享。

发现一:混合云和多云策略的趋势将继续上升,预计在未来三年将显著增加

调查发现,大多数(66%)的受访者使用了多云环境;有超过三分之一的受访者使用公有云平台。组织内部可能同时存在公有云和私有云,其中超过55%的受访者系统运行在混合云环境。有趣的是,有超过三分之一的公司同时拥有多云和混合云。

发现二:企业对公有云的需求持续上升

在过去的十年中,很多企业已经制定了将工作负载从数据中心转移到云计算的计划,过去两年也不例外。CSA调查了受访者组织当前工作负载的上云情况,并要求对2020年底前的情况进行预测。根据调查报告,笔者做了一个简单的对比图,如下:

上图可以看出:

  1. 当前14%的企业将工作负载的61%-100%放到了公有云上,较2017年增加了一倍。
  2. 虽然有9%的受访者表示,目前根本没有使用云计算来处理任何工作负载,但在他们对2020年的预测中,这一比例降到了4%。
  3. 2020年企业对公有云的需求还在不断增加,预测将超过40%的组织增加一倍左右。其中,IT行业的员工更倾向于选择81-100%的云计算工作量,而医疗保健(7%)和金融服务(8%)等受监管行业的员工则不这么认为。

发现三:安全问题是影响企业选择公有云平台的主要问题

当受访者被访问将企业的应用迁移到公有云上时的主要顾虑时,绝大多数受访者表示了对安全问题的担忧。安全问题是可以说是影响绝大多数企业的最大问题,数据丢失和泄露风险,合规性、法律问题,则分别列入了影响企业上云的第二、三和五位。在安全问题中,企业高度关注的核心问题是敏感客户和个人信息的泄露问题。

下面我们列出影响企业上云的五大问题:

  1. 安全问题(占81%)
  2. 数据丢失和泄露风险 (占62%)
  3. 合规性问题(占57%)
  4. 与现有的IT系统集成问题(49%)
  5. 法律问题(占44%)

除以上内容外,CSA的调查报告还在安全工具及安全事故等方面进行了分析,由于篇幅限制,将于下一次与大家分享。

本文参考:

Cloud Security Complexity: Challenges in Managing Security inHybrid and Multi-Cloud Environments (2019)

VPC配置指南

本文主要包含以下内容

  • 公有子网和私有子网的区别
  • 如何新建IGW,如何更改路由表
  • 如何创建NAT网关,如何更改路由表
  • 合理的网络拓扑
  • VPC Wizard

公有子网与私有子网

  • 子网:VPC是跨可用区的.在创建VPC后需要为每个可用区添加一个或多个子网,子网不可跨可用区。
  • 公有子网:子网的关联路由表包含指向Internet网关的路由的子网。
  • 私有子网:子网的关联路由表不包含指向Internet网关的路由的子网。
  • 仅限VPN的子网:特别的,一个子网没有通向Internet网关的路由,但其流量会被路由到虚拟专用网关以进行VPN连接,则这个子网就是仅限VPN的子网。

image-20180821103147315

如上图

  • Subnet1:有通向Internet网关的路由,因此它是公有子网
  • Subnet2:没有通向Internet网关的路由,因此它是私有子网
  • Subnet3:没有通向Internet网关的路由,但流量可达VPN,因此它是仅限VPN的子网

InternetGateways

使用Internet网关(InternetGateways,igw),可实现VPC中的实例与Internet之间的通信。

Internet网关有两个用途:

  1. 在VPC路由表中为Internet可路由流量提供目标
  2. 为已经分配了公有IPv4地址的实例执行网络地址转换(NAT)

当生成AWS账户的时候,AWS系统会默认的在每一个区域内都生成一个默认的VPC,并且这个默认的VPC已经绑定了一个Internet网关;一个Internet网关一次只能绑定一个VPC;当VPC中有EC2实例等AWS资源的时候,Internet网关是不能手动和相结合的VPC相分离的

路由表

每个子网都会和路由表相结合使用,并且只能使用一个路由表;VPC中的子网是共有子网还是私有子网是由该子网使用的路由表决定的

如果该路由表中有Internet网关路由条目,那么该子网就是共有子网;

路由表由一系列的路由规则组成,决定了子网的访问权限;默认情况下,同一个VPC之间的子网之间是可以相互通信的;当路由表和子网已经结合的情况下,该路由表是不能被删除的。

配置Internet网关

Internet网关在配置时需要具有对应的子网,在配置之前请确保您已经添加了所需的子网

  • 创建Internet网关并将其附加到VPC
    • 打开AmazonVPC控制台https://console.aws.amazon.com/vpc/
    • 在导航窗格中,选择Internet网关,然后选择创建Internet网关。 image-20180821114813780
    • (可选)为Internet网关命名,然后选择创建
    • 选择刚刚创建的Internet网关,然后选择操作,附加到VPC。 image-20180821114052114
    • 从列表中选择VPC,然后选择附加。

image-20180821114448728

  • 创建自定义路由表
    • 打开AmazonVPC控制台https://console.aws.amazon.com/vpc/
    • 在导航窗格中,选择RouteTables,然后选择CreateRouteTable。 image-20180821115416967
    • 在CreateRouteTable对话框中,可以选择命名您的路由表,选择您的VPC,然后选择Yes,Create。

image-20180821135611911

    • 选择您刚刚创建的自定义路由表。详细信息窗格中会显示选项卡,以供您使用其路径、关联和路线传播。
    • 在Routes选项卡中,依次选择Edit、Addanotherroute,然后根据需要添加以下路由。完成此操作后,选择Save。
      • 对于IPv4流量,在Destination(目的地)框中指定0.0.0.0/0,然后在Target(目标)列表中选择Internet网关ID。
      • 对于IPv6流量,在Destination(目的地)框中指定::/0,然后在Target(目标)列表中选择Internet网关ID。

image-20180821140205194

    • 在SubnetAssociations选项卡上,选择Edit,选中子网的Associate复选框,然后选择Save。

image-20180821140326210

NAT网关

使用网络地址转换(NAT)网关允许私有子网中的实例连接到Internet或其他AWS服务,但阻止Internet发起与这些实例的连接。在创建NAT网关时需要指定与该网关关联的弹性IP地址。创建NAT网关之后,必须更新与您的一个或多个私有子网关联的路由表,以将Internet绑定流量指向该NAT网关。这使您的私有子网中的实例可以与Internet通信。

配置NAT网关

image-20180821152642033

    • 指定要在其中创建NAT网关的子网,并选择要与该NAT网关关联的弹性IP地址的分配ID。完成后,选择CreateaNATGateway。

image-20180821160503177

    • NAT网关会显示在控制台中。片刻之后,其状态会更改为Available,此后它即准备好供您使用。

image-20180821160905824

  • 为NAT网关配置路由表
    • 打开AmazonVPC控制台https://console.aws.amazon.com/vpc/
    • 在导航窗格中,选择RouteTables。
    • 选择与私有子网关联的路由表,然后依次选择Routes、Edit。
    • 选择Addanotherroute。对于Destination,键入0.0.0.0/0。对于Target,选择NAT网关的ID。

image-20180821162613752

    • 在SubnetAssociations选项卡上,选择Edit,选中子网的Associate复选框,然后选择Save

image-20180821171757732

    • 选择Save。

为确保NAT网关可以访问Internet,与NAT网关所在子网关联的路由表必须包含使Internet流量指向Internet网关的路由。如果删除NAT网关,则NAT网关路由会保留为blackhole状态,直到您删除或更新这些路由。

合理的网络拓扑

image-20180821171757732

一个合理的网络拓扑应该包含有以下几部分:

  • Internet Gateway
  • Elastic Load Balancing

Elastic Load Balancing可以在多个目标(如AmazonEC2实例、容器和IP地址)之间自动分配传入的应用程序流量,实现负载均衡。它可以在单个可用区内处理不断变化的应用程序流量负载,也可以跨多个可用区处理此类负载。ElasticLoadBalancing提供三种负载均衡器,它们均能实现高可用性、自动扩展和可靠的安全性,因此能让您的应用程序获得容错能力。

Elastic Load Balancing:

    • 直接与InternetsGateway连接
    • 与AutoScalingGroup连接
  • 堡垒机/NAT网关

通常情况下,堡垒机(也称为“跳转机”)是在系统中访问私有主机的一个最佳实践。例如,您的系统可能包含一个不希望被公开访问的应用服务器,当需要在这台服务器上进行产品的更新或系统补丁程序的管理时,您通常会登录到堡垒机,然后从那里访问(即“跳转到”)应用服务器。

在本拓扑中,Web实例以及数据库实例位于私有子网中,无法被直接访问。因此,您需要通过堡垒机来访问并管理这些实例。

堡垒机:

    • 最好仅向特定的IP地址范围开放
    • 直接与InternetsGateway连接
    • 位与公有子网,通常情况下,AutoScaling会与ELB结合使用,之后实例在启动后会自动加入ELB的目标组,在终止实例前会先等待ELB连接耗尽。
    • 为了保证实例的安全与可用性,实例应分别位于多个可用区的私有子网中

数据库实例:

    • 为了保证您数据的安全,数据库实例不应能直接从外网访问,数据库实例应位于私有子网中。
    • 使用主从架构:

将读操作和写操作分离到不同的数据库上,避免主服务器出现性能瓶颈

主服务器进行写操作时,不影响查询应用服务器的查询性能,降低阻塞,提高并发

    • 为了保证可用性,主数据库与从数据库应位于不同的可用区中

VPC Wizard

VPC控制台中提供了四种VPC向导用于创建常用场景下的VPC的创建

image-20180822135511214

实例在 AWS 云的专用隔离部分中运行,该部分可直接访问 Internet。可使用网络访问控制列表和安全组对您实例的入站和出站网络流量提供严格控制。适用于运行单层、面向公众的Web应用程序(如博客或简单网站)的VPC。

除了包含公有子网之外,此配置还添加了一个私有子网,该子网的实例无法从 Internet 寻址。私有子网中的实例可以使用 Network Address Translation (NAT) 通过公有子网与 Internet 建立出站连接。适用于运行面向公众的Web应用程序的VPC,同时仍在第二个子网中保留非公开访问的后端服务器。

此配置在 Amazon VPC 和数据中心之间添加了 IPsec VPN 连接,可有效地将数据中心扩展到云中,同时为 Amazon VPC 中的公有子网实例提供面向 Internet 的直接访问。适用于将数据中心扩展到云中的VPC,并实现从VPC直接访问Internet。

实例在 AWS 云的专用隔离部分中运行,该部分带有一个私有子网,该子网的实例无法从 Internet 寻址。您可以通过 IPsec 虚拟专用网 (VPN) 隧道将此私有子网连接到您的企业数据中心。适用于将数据中心扩展到云中的VPC,无需将您的网络连接到Internet即可使用Amazon基础设备。

戏说云上日式搬家

声明

这不是一个搬家公司的广告,只是一个漂泊云上的挨踢狗的戏说。

前言

做为一个北漂,搬家就如同家常便饭,但是每次搬家仍然感觉是一次灾难:打包时发现纸壳箱各种不足,搬家过程的各种混乱,家具被磕磕碰碰,很多小物件从此消失不见,在搬家后,有那么几天,感觉生活停摆。做为一个云上挨踢狗,帮助更多的企业将系统搬迁上云也已经是日常工作的一部分。某日,在总结工作时,忽然发现两者居然是如此的类似,于是决定把二者合二为一来戏说下,给生活增添下乐趣。

第一次用公有云,很多人会发现,原来你在本地机房中繁琐的安装和配置工作,在云端只需要分发一个小程序,数秒内你部署在世界各地的系统就可以同步更新,系统迭代的速度大幅度提升。相信这是很多人喜欢上公有云的重要原因。但是,真正把系统搬迁到公有云,就会发现,一切并非那么简单。数据问题、存储问题、网络问题、接口系统、安全问题等等,各种问题就像那挡在你搬家道路上的障碍物,严重的时候让你的业务停摆。不合理的迁移是一场灾难,让你的上云信心大打折扣。

不知道大家是否看过日本人搬家公司的搬家过程,可以说全过程追求细节的保护与服务,策划、打包、搬运、归位、清洁,一站式服务,搬家变得更加有条不紊,更加安全。做为一个资深运维专家,神州泰岳在结合了AWS的相关最佳实践,以及本身的迁移经验基础上,提出了五步迁移法,使得上云迁移服务就如同日式搬家服务一样,提升了用户的云端感受。

五步迁移法

下图为AWS给出的最佳经验。神州泰岳在上云迁移方面遵循了五步法,同时通过自身经验,对五步法进行了完善,形成了泰岳上云五步法,就是我们后面想要戏说的云上的日式搬家法。

AWS五步迁移方法论

下面开始我们的戏说吧,看看日式的云上搬家会是什么样子的呢?

第一步:定目标

其实准确来说,真实生活中的搬家目标是比较清晰的,而云上的搬家目标则非常复杂。即使是在一个公司,由于职位不同,大家对云上迁移的目标也不尽相同。例如,就CFO而言,云上搬迁可能解决的是本地数据中心的投资问题,其自然希望搬迁后成本能够更加优化;而业务人员可能更多的是希望搬迁的速度更快,业务能够更少受到影响;运维人员可能更多的是希望搬迁更加简单便捷而不是带来更多的工作量和风险;做为安全人员则更多的是希望迁移不要带来更多的安全风险。因此,由于迁移目标的不同,所选择的迁移方法的差异很大,迁移的成本也将会有很大差距,所以,迁移目标的确定在迁移之初是非常重要的。这一点已经远远超出了生活中的搬家。

正是由于制定目标是决定整体迁移活动的关键,AWS在总结经验的基础上,给出了从6个视角来重新审视业务和技术的框架,名为AWS云采用框架(简称AWS CAF)。该框架可以帮助客户更加全面的进行评估,确定合适的目标,从而更快、更低风险地实现采用云带来的可度量的业务收益。框架所涉及的访谈客户上到CTO、CFO,下至系统维护人员,可以说是相当的全面。

实践证明此方法论下,最终确定的目标是科学的,也是得到了用户的一致认可的。目标的确定往往最终与搬迁的结果和搬迁后的效益直接相关。

第二步:策划

一般的搬家公司来了就搬,没有这一步骤,所以往往你也记不清楚到底搬了多少件东西,即使你数清了大件,往往还有很多小件被遗忘。而日式搬家的第一步就是将物品分门别类,然后列出一份一张详细清单,之后按照你家具物品的数量和种类,为你规划出一套最划算、最周全的搬家方案。如果其中有非常贵重的钢琴或者大穿衣镜,将受到额外隆重的待遇。

云上的迁移也是从基础设施和应用的调研开始的。收集客户当前基础设施的性能、使用情况、部署情况,进行记录(包括业务的闲忙时及该期间的使用情况);了解业务应用的优先级,系统间的相互依赖度;列出应用程序基础设施清单。在这方面有很多类似的工具进行现有系统和设备的配置收集。

当处理一个重大的项目时,最具挑战性的部分是决定从哪里开始。如果客户有明确的选择,这一步会相对简单;但是,如果客户的基础设施分布在多个数据中心或多个团队中,没有一组用于评估应用程序的统一度量标准,则很难确定哪个APP最适合第一波迁移。

第一波迁移的项目,我们会希望是那些对业务影响较小,且迁移后效果明显的项目。行业研究表明,多达30%的本地服务器都是僵尸(在6个月或更长时间内没有显示出有用的计算活动的迹象),超过35%的服务器显示活动的时间少于5%。此类应用对业务的影响一般情况下会比较小,首先进行迁移,且在云上正确调整部署的大小,就能够使用户明显感受到迁移到云端的高性价比。毫无疑问,这是云端迁移最佳的撬动点。

事实证明,寻找的与其他应用依赖性少,服务器冗余多,且当前容量有浪费的应用做为首次迁移的应用,会很快让你的客户尝到迁移的甜头,后续的迁移会更加顺利。如果碰巧需要迁移那种大型的,已经无法招待开发人员的应用,则让你的迁移困难重重。

不同的业务,如何迁移上云呢?错误的规划,往往会直接影响到迁移的成败。在云上迁移过程中,我们也会根据用户的业务特性,遵循AWS的6R法则,帮助客户确定,哪些应用是可以直接迁移的(Rehost),哪些是需要修改后迁移的(Replatform),哪些需要重构后再迁移的(Refactor),哪些是不能迁移的(Retain),哪些是停用的(Retire),哪些是需要重新购买服务的(Repurchase)。

当然,最终迁移规划的制定往往也是与财务、公司规划等方面直接相关的,经过各方面的协商,最终才会得出一个被大家认可的迁移计划。

第三步:打包(设计)

从这一步就能够看出来,云上的迁移远远比现实中的搬家复杂的多。当业务真正搬到云端,需要考虑的问题较之前要更加全面,比如安全传输问题,数据的安全存储问题。原来你没有意识到的问题,纷至沓来。公有云与生俱来的弹性扩展、简单易用的高可用性和容灾方案等,只有在真正使用起来才能够发挥其强大的功效,如果只是将物理机上的配置简单搬迁到云端,没有合理的使用这些特点,仍然无法真正实现公有云的优势。因此,优秀的云上良好框架的设计,是云端迁移的基础,也是为什么很多企业请求专业公司协助进行迁移的主要原因。

良好框架的建立除了要求熟悉云端计算,也要求对用户的业务应用情况和应用的相关软件技术非常熟悉。因此,在设计阶段,客户的业务和技术人员也是需要全程参与的。

在架构设计方面,我们遵循AWS的良好框架要求。对设计的合理性,一般在迁移中,挑选部分简易的应用进行验证,然后再根据验证结果进行设计修改。因此,第三步与第四步是循环往复的。

第四步:搬家(迁移和验证)

日式搬家当天,为了不损害大楼墙壁、设备等,工作人员会在搬动前铺设保护垫。算你家是公寓楼,他们也会一路从大楼门口、电梯、楼梯、走廊一路贴到你家地板,以免搬运过程中碰到你的物品。

此外,让人印象最深的是,为了不使衣服在搬运时弄皱,搬家公司会准备像类似简易的移动衣柜的衣架箱,短袖、短裙会塞进小纸箱中,大衣、外套则会放进大纸箱中;鞋子在搬运中不会被挤变形,因为搬家公司会准备专门的简易鞋柜;至于易碎物品,搬家公司也会准备专用的“缓冲气垫包装箱”逐个隔开放。

云上迁移中,我们也是小心翼翼的。有的项目中,在用户预算允许的情况下,为了不影响业务的持续运行,采用了CI/CD的迁移方式。在迁移中,使用AWS CloudFormation模板构建框架,派生出未来的环境;使用AMI和Puppet或Chef等自动化配置管理工具等自动化的迁移手段更是迁移的首选。在迁移过程中,我们也将根据用户的业务和系统的需求,进行迁移工具的选择,如服务器和数据库迁移工具,数据迁移工具等。就如同那些大小的纸箱,完全根据用户的业务要求进行选择。

为了帮助一些初创企业更加顺利的完成迁移,我们更是帮助他们向AWS进行优惠政策的申请,以更低的成本完成迁移。

第五步:清扫归位(优化)

日式搬家的后续清扫和归位,也是让人印象深刻的一个地方。大件物品工人会按照主人要求摆放。小型物件会依照原样,摆放在之前的位置。连鞋子和衣架箱里的衣服,工作人员都会帮你挂回相应的地方。待物品都按照主人的指令归位后,他们还不会离开,还会再重新打扫一次。

而云上业务的迁移完成后,我们的架构师也会对系统进行一段时间的观察,保证业务正常进行的同时,检查哪些系统运行较为低效并提出优化建议。通过不断调整和优化,将系统和运营调整到最佳状态,才最终完成整个迁移过程。这就如同日式搬家最终的清扫和归位,云上的优化不仅仅是归位,更多的是为了达到系统状态的最优,达到对业务的促进。

以上关于搬家的内容,参考了一些搬家公司的宣传手册,由于是戏说,云上部分较为笼统,如有兴趣,请留言进行咨询。

 

泰岳云服务-DDoS防护浅谈

随着互联网不断普及,网络带宽增加,全球覆盖的高速网络给大家带来了方便,也为DDoS攻击创造了极为有利的条件。同行业的恶意竞争,涉黑的敲诈勒索,致使DDoS攻击者可以从中获利,目前DDoS攻击已经形成了一条完善的黑色产业链。在利益的驱动下,攻击者和防御方都在不断提高技术。

一句话简单说明DDoS,攻击者借助多种来源(协作者或被盗用主机)发动对目标的攻击。在攻击中,每个来源(协作者或被盗用主机)均参与攻击活动,从而生成海量的数据包或请求来“淹没”目标。

传统IDC由于网络带宽、配置固定等原因,长期以来一直被DDoS攻击所困扰。一直面临客户投诉、商业利益损失、法律纠纷等问题。随着公有云的普及,企业客户纷纷上云,DDoS攻击者也把专注力转向了如何攻击公有云。

经典的公有云防御DDoS架构

  • 分离管理员和用户的访问入口,攻击者一般是通过伪装成普通用户,通过暴力手段和大流量堵塞网络,让其他用户不能正常访问。管理员单独入口访问,攻击时不影响管理员进入。
  • 前端负载均衡器配合WAF服务器,清洗大部分攻击流量,减轻对后端服务器压力。
  • 后端负载均衡器分配正常用户和极少量的攻击流量,减轻对应用服务器压力。
  • WAF服务器和应用服务器均采用自动扩缩机制,在受到流量冲击时自动扩展抵御攻击。
  • 文件管理器保存配置文件和重要文件,管理员可以通过修改配置文件,改变WAF策略快速抵御攻击。

公有云在防御DDoS攻击方面有很大优势,结合泰岳云服务专家团队支持,可以侦测和抵御99.9%以上的DDoS攻击。我们为您司的应用量身定制安全架构,提供全面的托管服务,专职人员全时侦测攻击行为,最快速响应攻击动作,最大限度确保应用正常运行。

DDoS攻击目的性很强,快速确定攻击方式和可能造成的攻击影响,分级别处理攻击,再结合云上环境优势,达到全方位保护系统,最大限度缓解DDoS攻击带来的影响。

分级别应对攻击

对于大流量的DDoS攻击,我们可以选择不同的应对措施:

  • 当非关键性业务或可中断服务被攻击时,考虑到被攻击所产生的多余成本,可以选择短暂停止业务和服务,让攻击者无法继续攻击。
  • 当关键性业务或必须保证实时的服务被攻击时,可以扩大服务器计算能力,这正是云上环境区别于物理机房的优势,让攻击者一直达不到攻击目的,以此放弃攻击。
  • 当业务需要全球化服务时,可以通用云上规则快速分析攻击者来源,通过前端代理规则丢弃该区域流量,虽然可能影响到该区域用户的访问延时,但是可以大幅度减少攻击对全球化服务的影响。

发挥云上环境的优势

  • 云上环境具有高敏感性,在有异常流量出现时可以快速发现,结合专业团队,可以快速响应攻击。
  • 云上环境具有快速改变优势,在攻击进行中,可以在分析攻击记录后,快速改变规则,达到丢弃区域流量,封锁范围IP,黑名单阻拦等。
  • 云上资源的快速伸缩,可以短时间内扩大计算能力,吸收大流量攻击,保障服务正常运行。

我们专注于您的DDoS防护保障,您专注于您的业务领域。

使用CloudWatch一键监控所有EC2实例

使用 CloudWatch 可以轻松监控 AWS 资源和应用程序。它与 Amazon EC2、Amazon DynamoDB、Amazon S3、Amazon ECS、Amazon EKS 和 AWS Lambda 等 70 多种 AWS 服务原生集成.

利用CloudWatch可以深入了解相关内容的日志,比如监控每台EC2实例的CPU使用率、磁盘吞吐量、网络带宽等信息,同时我们可以对每个资源的监控指标设置警告,及时发现资源运行中的异常。

如果我们有几十上百个甚至更多的实例,为每一个实例分别设置告警的工作变得非常困难,那么能否设置一个警告,对所有实例的相应监控指标进行统一监控呢?答案当然是肯定的,

我们可以通过对聚合统计数据设置告警来实现以上需求。

接下来我们将创建一个聚合统计数据告警,监控所有EC2的CPU利用率,当任何实例的CPU利用率超过90%则会告警。

步骤如下:

1、开启详细监控生成聚合统计数据

每个监控指标都有不同的维度,只有开启EC2的详细监控的实例才能以维度生成聚合统计数据,默认情况下EC2的监控间隔为5分钟,开启详细监控后监控间隔会缩短到1分钟,可以在创建EC2时开启详细监控,也可以在实例的监控界面修改既有实例的监控粒度。开启方式如图:

创建EC2时开启详细监控

开启既有实例的详细监控

2、创建警报

Cloudwatch—警报—点击创建警报—选择指标—EC2—跨所有实例—CPU利用率—选择指标

创建警报

选择指标

注意要将统计数据修改为最大值,默认为平均值。 你也可以根据自己的需求设置为最小值或P99、P95等。

修改统计方法

设置告警阈值为80%

配置通知方式—设置名称—下一步—创建警报

设置名称

创建警报

完成

3、测试效果

我们创建两台实例,对其中的一台进行压力测试,将CPU利用率占用到100%。

观察告警情况。

加压的实例

没有压力的实例

我们看到警报已经被成功触发了。