背景

7月17日，国家互联网应急中心发布的《2018年中国互联网网络安全报告》显示：

近年来，云作为互联网基础设施在我国迅速发展，越来越多的业务场景逐步向云端迁移。在当前云服务使用过程中，云服务商和云用户对云的安全性（即避免危害云的网络攻击）和可控性（即避免利用云发起网络攻击）关注较少。

根据CNCERT/CC监测数据显示：

2018年11-12月，在安全性方面，虽然境内云IP地址感染木马或僵尸网络的概率较低，但是由于云上承载的服务越来越多、越来越重要，在其他攻击方面境内云则成为攻击的重灾区；在可控性方面，由于云服务获得的便捷性和低成本，越来越多的黑客倾向于利用云主机进行网络攻击。因此，云服务商和云用户应加大对网络安全的重视和投入，分工协作构建网络安全纵深检测防御体系，保障云的安全性和可控性，共同维护网络空间安全。

中国最大的云计算平台不带之一的阿里云在IDC报告中2018年下半年，阿里云在国内基础设施及服务占比高达42.9%，由于基数很大，因此阿里云上的用户也承受了国内公有云一半以上的攻击，下图是根据威胁猎人的报告绘制的，2018年上半年黑灰产对公有云的攻击次数中阿里云占比超过了55.32%。

即便是比例并不大，但是阿里云上也存在部分服务器被劫持为肉鸡的情况对外发送攻击，因此也会出现如下图的情况：

甚至有客户还会怀疑是不是阿里云想让我购买高昂的云安全类产品因此主动攻击我？当然了其实这种论调在各个云平台都有发生。

介绍

只要是暴露在公网上的业务就有可能成为被攻击的对象，因此我们需要积极的构建云上安全体系进行防御常见的安全攻击，同时也要保障自己的云产品不被劫持为肉鸡对外发送攻击加重互联网安全态势。

其实攻击者视角是来自方方面面的，360°无死角的盯着咱们的业务进行攻击，而安全又是一个典型的木桶的短板模型，即便其他的安全措施做的再好，只要存在一个明显的安全短板，就会导致整个业务系统的不安全。而防守者视角往往是单一的，通常是见招拆招式的的，甚至有些时候当安全事件已经发生了，很多人都无法及时做出对安全事件的反应。

这是我根据阿里云安全团队安全三步走的基础上修改来的云上安全体系构建路线图，本文我们重点聚焦云上安全第0步——安全基础建设。因为很多云上用户在没有做好第0步的时候就开始购买一些第一二步云安全产品，就会出现木桶短板效应，花费了高昂的费用却没有起到响应的安全作用。

边界安全

专有网络

专有网络VPC（Virtual Private Cloud）是基于阿里云构建的一个隔离的网络环境。每个专有网络（也就是每个VPC）之间逻辑上彻底隔离。

专有网络是网络容器
专有网络VPC是一个网络容器，用户可以免费开通，开通后再在这个容器中“放置”需要的云产品基本组件包含路由器和交换机。

专有网络是用户私有的
专有网络VPC是用户私有的，和其它VPC默认都是隔离的，和经典网络也是隔离的。

专有网络是用户在云上具备网络管理能力的基础
使用专有网络VPC，用户可以自主进行网络规划，比如自定义网段，划分子网，管理路由，管理公网出入等等。

相较于早期的经典网络，专有网络拥有更佳丰富的网络化产品和自定义性的同时，也更安全可靠，早期的经典网络是一张大内网，不用的阿里云用户同一地域即在同一内网内，隔离性极差。

同时在专有网络下可以使用EIP、NAT网关等产品，当服务器遇到攻击后，通过弹性公网IP（EIP）产品可以快速的变更服务器IP防止一些基于IP的定向攻击。一些用户遇到攻击后再购买高防IP、Web应用防火墙等产品会发现并不起作用，很大原因是因为服务器源站IP并没有进行及时修改，即便使用了安全产品，攻击者依旧知道最终的源站服务器IP是多少。

下面是VPC的宣传视频：

扩展阅读：

VPC帮助文档 | VPC最佳实践

安全组

安全组是一种虚拟防火墙，具备状态检测和数据包过滤功能，用于在云端划分安全域。您可以通过配置安全组规则，允许或禁止安全组内的ECS实例对公网或私网的访问。

如果将咱们的服务器比作一个学校的话，这座学校一开始没有围墙，学校师生可以任意出入，其他人员也可以自由出入学校，这样学校就容易出现一些危险人员（病毒、攻击）进入学校进行破坏。因此我们就需要建立一个围墙，这就是我们的安全组开启后不开放任何端口的情况。

这时候我们需要开放一些出入口方便师生上下学，因此便会设立学校的大门，这就是我们对外开放的端口（80端口、443端口），一些重要的端口例如校长办公室（22端口），我们需要更严格的措施，即需要核对人员身份，及只有对应的IP才能访问该端口。

很多用户早期往往为了方便会开放全部协议并向全部端口即0.0.0.0/0开放，这严重违背了安全组的初衷。

安全组作为一个提供中文界面的图形化防火墙产品，已经大大降低了我们使用防火墙的成本，像 iptables、FireWallD 其实对新手来说命令行还是英文的就很难学。

例如在云上非常常见的例用 Redis 未授权访问漏洞进行加密勒索的事件，如果我们及时的通过安全组限制 Redis 被公网访问的情况就可以很好的避免相关安全事件的发生。

针对安全组，我们仅开启80、443这样的通用端口向用户进行开发，针对22、3389等端口应当仅面向自己或者公司网络的固定IP开放。

下面视频是安全组的宣传视频：

扩展阅读：

安全组帮助文档 | 安全组最佳实践 | 操作视频

访问控制

访问控制RAM提供非常丰富的阿里云上的服务和资源的管理能力：

使用RAM，您可以创建、管理RAM用户（比如员工、系统或应用程序），并可以控制这些RAM用户对资源的操作权限。当您的企业存在多用户协同操作资源时，使用RAM可以让您避免与其他用户共享云账号密钥，按需为用户分配最小权限，从而降低企业信息安全风险。

很多用户在使用RAM子账号的时候往往会创建一个子帐后拥有管理一整个大产品的权限，这样虽然方便却留下了非常大的隐患。

例如这里就为了图方便将整个OSS的访问管理能力开放给子账户，特别是一些代码解释型语言填写到 config 的AccessKey 和 AccessKeySecrt 就有可以会暴露，这样的话当我们OSS上部署了多个Bukcet后，就有可能会被非法利用，导致文件被删除或者被下载的情况。

同样的，还有部分云上用户会开放测试账号给一些外包的运维部署人员，为图方便会创建非常简单的密码对外提供，或者部署完成后没有及时的回收并删除账号。我就遇到过一个朋友因为这样，导致了ECS服务器被充值系统盘并删除了所有快照。

扩展阅读：

访问控制帮助文档| 访问控制最佳实践 | 访问控制视频教程

操作审计

操作审计(ActionTrail)会记录您的云账户资源操作，提供操作记录查询，并可以将审计事件保存到您指定的日志服务Logstore或者OSS存储空间。利用ActionTrail保存的所有操作记录，您可以实现安全分析、资源变更追踪以及合规性审计。

操作审计是一款开箱即用的产品，在不创建追踪日志存储到OSS的情况下最多可以查看近30天的用户操作审计日志。

如上图可见，当我操作了更新 AccessKey 后就立马有了响应的日志，包括事件源、事件时间、源IP等信息，可以让我们很好的进行操作的溯源审计，满足安全合规的需求。

扩展阅读：

操作审计帮助文档 | 操作审计最佳实践

数据安全

很多用户都觉得上了云之后那么阿里云便会全权负责用户的数据和业务安全，因此我的很多销售阿里云的同事就会反馈说好多客户在中毒或者加密普遍都会说不应该阿里云这样的服务厂商来负责我们的服务器安全的吗？为什么我还是会中毒。

其实这时候我们就需要明确一下云上的这个责任构成了，针对像ECS云服务器这样的IaaS类产品，其实阿里云仅负责物理安全，网络控制和主机基础设施建设和用户共建，而这之上的责任都是需要用户自行承担的，具体的情况可以见下图：

然后还有很多用户会认为租用的阿里云ECS云服务器的云盘有 99.9999999% 的数据可靠性，这个是不是就意味着我放在云上的数据不会丢啊。这时候客户还会意识到说数据的三盘副本，一些客户在文件误删的时候就会说：“你们阿里云有三盘副本，我现在这个云盘里的文件我不小心误删了，那另外两个盘上的副本快取出来帮我恢复一下。”

其实这时候就有必要澄清一下，三盘副本主要是为了防止系统错误导致的文件丢失的i情况，并不能防止因为误删除或者病毒进程删除文件导致的逻辑错误，具体如下图：