AI 年度盘点与2025发展趋势展望,50+案例解析亮相AICon 了解详情
写点什么

「企业上云」之云安全与持续优化

  • 2016-07-11
  • 本文字数:5843 字

    阅读完需:约 19 分钟

伴随着近些年云计算大潮的冲击和洗礼,以及大家对云的不断了解和接受,更多的应用和系统被逐渐的迁移并部署到了云端。迁移之后,云端的高可用性、弹性、高度的易用性等特点,都给用户带来了更多的方便和实惠。随之而来的,更多的安全问题,也不可避免的呈现在了我们的面前。那么今天,我们就针对云端的安全问题,做一些实践性的建议讨论。

对云安全的理解

不同的人群,对云安全的理解是千差万别的。从云的服务提供商(IaaS、PaaS、SaaA)、终端用户到运维服务商、等等,他们眼中的云安全和对于云安全的关注点,甚至可能是大相径庭的。

对于云的终端用户而言,尤其是 IaaS 用户,云安全的关注点,其实更多的是在强调如何保证客户的云上应用系统和服务的安全性。

为了实现这个目标,需要从底至上的安全支撑,主要包括:

基础设施物理安全 > 平台安全 > 应用安全 > 数据安全,等。

通用云安全体系介绍

那么,有没有一个通用的安全体系?如果有的话,它应该是什么样的呢?七层的概念大家都不陌生,通用的安全体系一般可以划分为 7 层,包括:设备安全、网络安全、系统安全、平台安全、应用安全、数据安全、信息安全。其细节如下图所示:

在这个七层安全体系里,不同角色的人群在其中起到的作用和对于安全的关注点,是截然不同的。下面我们来详细聊聊各个角色在这个体系中的作用和关注的问题。

云端网络设计和安全隔离

在使用 IaaS 云服务的时候,终端用户可以利用一些 IaaS 的基础特性,通过一些部署结构的设计和编排,提升安全级别。

  • 使用云的最大好处之一,就是可以根据用户自己的需要,完全自定义二层网络,也就是我们常说的 SDN。
  • 用户可以把不同的应用系统或服务部署在不同的网络中,通过设置路由策略等方式,实现访问控制、隔离、等。
  • 配合防火墙、安全组等安全服务,则可以更加容易的实现内外网隔离和访问控制。

一个典型的安全云网络结构如下图所示。

云服务提供商需考虑的安全问题

作为云服务提供商,提供了云服务所需的物理硬件、场地、安全设备等基础设施,同时也提供了云平台和运营运维等在这之上的软件和服务。所以,他们一般需要考虑的云安全问题主要包括:

  • 平台层以下 (包括平台层本身) 的安全性,是云服务提供商需要着重处理和保障的。
  • 物理安全和网络安全,是云服务提供商需要首先考虑的两大主要因素,实现包括:物理设备隔离、网络隔离、分区规划、电力保障、DDosS 防御、入侵检测、访问控制、流量控制 (东西向+南北向)、等。
  • 系统安全主要包括主机层面的接入安全、密钥管理、补丁升级、漏洞防护、帐号管理、等。
  • 平台安全主要涉及平台本身的设计层面是否充分考虑了安全因素、是否通过了比较严格的安全性测试和认证、是否能够提供客户需要的安全服务、等。
  • 此外,云服务提供商是否配备专门的安全团队,来保障其安全性,也是一个非常重要的考虑因素。

因此,作为终端用户,在选择云服务提供商的时候,需要重点考察和衡量其安全性,择优选用安全级别更高的云服务。这也是对于您云端应用和服务最基础保障的选择。

用户自身需保障的安全问题

根据 AWS 最早提出的责任共担模型——也是目前业界公认的机制,用户自身也要在安全方面做许多工作。在我们看来,用户自身需要保障的安全问题有以下几个方面:

  1. 作为终端用户,首先需要充分利用云服务提供商提供的安全服务,保障自己应用系统或服务的安全。这些安全服务主要包括:IAM、MFA、安全组、防火墙、密钥对、VPN、审计日志、等。
  2. 同时,用户需要利用云服务资源的一些特性,合理设计和部署,保护自己应用系统或服务的安全。常用的主要可以利用的资源特性包括:自定义网络拓扑结构和访问控制、弹性公网 IP 和自定义路由策略、等。
  3. 应用系统或服务本身的安全设计,从本质上讲是与上云与否没有直接关系的。从任何角度看,即使不上云,这也是用户自身需要周全考虑和实现的,保障应用系统或服务本身不存在安全问题或漏洞。
  4. 数据安全和信息安全策略也是同样道理,类似密码密钥的管理规范,数据使用和保存的规范,不管上不上云,都是用户自身需要充分保障的。

这其中,IAM 与 MFA 尤是大家常常提及的重要一环。

IAM 与 MFA

IAM (Identity and Access Management) 是一种 Web 服务,可帮助您安全地控制用户对云端资源的访问权限。通过 IAM 可以控制哪些人可以使用您的云端资源(身份验证)以及他们可以使用的资源和采用的方式(授权)。InfoQ 上前 Juniper 的安全专家陈天曾专门撰文详细介绍过 IAM 的使用:《深入了解IAM 和访问控制》。

MFA (Multi-Factor Authentication) 是一种非常简便的最佳实践方法,它能够在用户名称和密码之外再额外增加一层保护。启用 MFA 后,用户登录云服务网站时,系统将要求他们输入用户名和密码(第一安全要素 – 用户已知),以及来自其 MFA 设备的身份验证代码(第二安全要素 – 用户已有)。这些多重要素结合起来将为您的云服务账户设置和资源提供更高的安全保护。

IAM 和 MFA 双重安全保障的效果如上图所示,现在的云服务提供商,多数都已支持或部分支持了 IAM 和 MFA。如果想了解更多,关于 IAM,您可以参考 AWS 的官方文档“ AWS Identity and Access Management ”;关于 MFA,可以参考 AWS 的官方文档“ Multi-Factor Authentication ”。

善用 IaaS 基本安全服务之 Security Group

刚才我们提到,在责任共担模型下,用户要自身做很多安全方面的工作,其中之一便是善用 IaaS 服务商提供的各类基础安全服务。

安全组,翻译成英文是 security group,是一些规则的集合,用来对虚拟机的访问流量加以限制。可以定义 n 个安全组,每个安全组可以有 n 个规则(规则本身可以是其它安全组),可以给每个实例绑定 n 个安全组。云服务提供商一般总会提供一个 default 安全组,这个通常是不能被删除的。创建实例的时候,如果不指定安全组,会默认使用这个 default 安全组。安全组在功能上,跟防火墙十分类似,但实质上又有所不同。

  • 典型的安全组使用场景如下图所示。

善用 IaaS 基本安全服务之 Firewall As A Service

熟悉防火墙的都知道,防火墙一般放在网关上,用来隔离子网之间的访问。一个可能混淆的概念是安全组(Security Group),安全组的作用对象是虚拟机,通过配置规则来限制虚拟网卡的进出访问。防火墙可以在安全组之前隔离外部过来的恶意流量,但是对于同个子网内部不同虚拟网卡间的通讯不能过滤(除非它要跨子网)。作为用户,可以同时部署防火墙和安全组实现双重防护。

  • 以常见的 OpenStack 体系为例,防火墙使用场景如下图所示。

  • 用户开启防火墙服务以后,防火墙就成为了服务的必经入口,用户可以按照源目的 IP、源目的端口等条件,像使用标准物理防火墙一样进行访问控制。

当然,这里提到的应用场景是一些在线业务,或者说是在线状态。旁路安全则需要镜像流量进行其他的安全分析和防御。

借力 IaaS 高级安全服务之 DDoS 防护

众所周知,国内的网络环境相对恶劣,DDoS 是个不得不说的话题。

DoS(Denial of Service,拒绝服务)攻击通过某些手段使得被攻击的目标系统或者网络不能提供正常的服务。具体手段可以是对一个攻击对象的资源(带宽资源或系统资源)耗尽式攻击;或者利用程序实现上的缺陷导致对异常行为处理不正确。

DDoS(Distributed Denial of Service,分布式拒绝服务)攻击是指多台主机合作同时向一个目标发起 DoS 攻击。DDoS 攻击过程中,攻击者使用的主机并不直接发起攻击,所以不会受到检测和跟踪,身份也较难发现。

国内各大云服务商都打着扛 DDoS 攻击可以达到百 G 的广告,所以大家可以试用一下。总的来说有以下几点:

  • 现在,一般的云服务提供商,都会在网络出口处架设 DDoS 防护设备。
  • DDoS 设备根据 DDoS 策略中的学习规则发现流量,生成检测规则。而后,根据检测规则进行异常流量检测,并在检测到异常流量时生成过滤规则,阻止异常流量通过设备。

我个人认为,DDoS 光在技术层面入手是不够的,还要在法律层面捍卫自己的权益,比如通过司法手段对攻击源的调查取证,等。

借力 IaaS 高级安全服务之 WAF 防护

几年前国内有不少的新型安全公司,主要从事的业务就是 WAF 防护,比如大家都熟知的安全宝、加速乐等服务。

  • WAF 是 Web Application Firewall 的缩写,中文可以翻译成:网站应用防护系统。通过执行一系列针对 HTTP/HTTPS 的安全策略来专门为 Web 应用提供保护。
  • WAF 的工作原理可参考下方示意图,不难看出,和 DDoS 防护很像。

  • 未来,针对软件定义 WAF 与分布式 WAF 技术,我想我们会做出更多的思考和探索。
  • 想了解更多关于 WAF 的信息,您可以参考 AWS 的文档“ AWS WAF – Web 应用程序防火墙”的介绍。

做好以上这些安全措施显然是不够的,接下来我们要说说善用审计日志的重要性。

善用审计日志

审计日志,就不用多说了,它记录了用户账户下全部账号的所有详细操作记录。当需要追溯问题或查找详细操作信息时,它就非常重要了。

大家可以看到,日志中的信息十分丰富,任何安全问题都能从日志中找到蛛丝马迹。除此之外,另一个很重要的安全措施就是严格的密钥管理。

严格密钥管理

从诸多案例可以得知,很多安全问题并非安全技术环节出了差错,而是密钥管理不规范导致的。

复制代码
1. 密钥是用户访问资源的钥匙。
2. 对于不同的资源和用户,分配不同的密钥,分开管理。
3. 建立内部安全管控机制。

其它安全手段和措施

最后介绍一些其他的安全手段和措施:

  • 关闭一切不必要端口。
  • 开通 VPN,只通过 VPN 访问方式管理资源。
  • Web 应用开启 HTTPS。
  • 用户与权限的严格管理,通过用户组来映射角色和权限。

答疑环节

问:云安全的现状及瓶颈是怎样的?

崔远智:从整体上,大多数云服务提供商都能够通过运维和技术手段保证云端的基本安全性(包括定期更新 OS 补丁、严格的管理制度和服务标准,等)。其实要点在于,终端用户如何利用现有服务和功能,保证自身应用或服务的安全。常见的问题有很多,类似:弱口令、端口全开、未使用 SSL 加密通信、等等。

问:云迁移的过程中,有哪些安全上的问题和解决方案,云安全面临那些挑战?

崔远智:首先,要考察和选择安全级别较高的云服务提供商,一般情况下都需要通过等保三级、可信云、ISO27001、cstar 认证等。云安全的问题,尤其 IaaS 服务的用户,个人认为其实多数还要靠终端用户自身来保证。如文档中提到的,端口封闭、开启 https、弱口令,等等。谈到面临的挑战,我认为,更多的是云服务提供商需要去面对,比如曾经出现过的主机方面的“心脏出血”漏洞,等等,这样的安全漏洞,会影响整个云服务的提供。但其实话说回来,不使用云而使用托管,需要处理的问题其实也都是一样的。云服务提供商反而帮助终端用户解决了很多系统层面的安全问题。

问:云端的优势不可否认,但是对于分散在各处的客户机来说,网络如何保持健壮性,以维持高效的连接速率?

崔远智:这个问题本身跟云安全并无直接关系,但这是一个好问题,也是实际上我们需要认真考虑和对待的问题。对于客户 VM 的网络,一般都是在云服务提供商的物理网络之上实现的虚拟网络,其高可靠性主要由云服务提供商的硬件和平台保证。这里就包括了网络设备和链接的冗余配置,网络控制节点的 HA 配置,等等。同时,对于客户 VM,也会设置 QoS,来保障虚拟网络的服务质量。具体来说,就是设置带宽上下限,等等。另外,现在多数的云服务提供商,也都针对高端用户提供了基于 SR-IOV 的高性能网络 VM,可以实现更低的网络延时和极小的网络抖动,保证关键业务的 TPS。

问:云端解决了分布式计算的问题,提高了产能,云端的安全性变得尤为重要,我们知道云并非绝对的安全,在保障云端运维上,需要注意哪些细节?

崔远智:对于云端运维,首先要保证的,就是规则上的安全,也就是我们常说的合规性。所有的运维动作,都要遵循一定的安全规范和守则,从而最大程度上保证客户所使用服务的安全可用。另外,对于自动化运维快速发展的今天,系统的发布、升级等,都通过自动化批量操作来实现。这一方面带来了操作上的简便和高效,同时,也增加了操作的风险。因为对于生产环境批量操作,一旦失误,若是没有回滚机制和预案,后果将不堪设想。比如,前些天某国内知名旅游网站的网站误删除,就是由于自动化脚本造成的。此外,还有密钥的保存、审计,等等,这里就不一一细说了。

问:最近一直想利用云计算的 Paas 平台,从系统架构、容器管理或是网络 SDN、日志或镜像管理、登录认证等多个方面,选取一个点或者组合解决方案,可以结合实际的应用,转化为学术成果,可以写出论文,希望崔老师能指导一下思路。

崔远智:这个问题和今天的分享也是关联不大,不过也可以尝试回答一下。但我首先需要了解一下,您这个“结合实际的应用”,是什么应用,想实现什么效果?需要先设计一下目标。目标确定了,才能够有针对的进行技术选型和业务规划。比如,你可以设计一个结合硬件设备的多因子认证服务,您看是不是可行?

问:从用户的角度看待云安全应该关注哪些方面?

崔远智:个人认为,首先是应用或服务自身的安全设计,需要保证。其次,选择一家靠谱的云服务提供商。另外,避免常见的安全防范漏洞,比如弱口令,vm 的 root 密钥设成 123456,被人撞开,太容易了。

问:用户和 IaaS 平台在安全角度看是怎样的一种关系,在安全问题上两者怎么侧重,甚至在出现问题后怎样划分责任?

崔远智:AWS 在业界首先提出了责任共担安全模型。IaaS 服务商负责保证云服务的可用性和安全性,也就是我们常所的 vm 及 vm 以下的部分。作为用户,自身需要保证在 VM 以上的,也就是应用和服务的可用性和安全性。

关于作者

崔远智,现任东网科技有限公司云计算云计算研发部部长。主要从事云计算基础服务和应用领域的研究、开发工作,研究方向主要包括主机虚拟化技术、分布式存储技术、软件定义网络技术、容器技术、等。曾从事多年国内解决方案软件和欧美国际软件外包业务并赴美工作。发表过“基于实时控制的多路温度监测系统 [J]”的学术论文,等。


感谢魏星对本文的策划和审校。

给InfoQ 中文站投稿或者参与内容翻译工作,请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博( @InfoQ @丁晓昀),微信(微信号: InfoQChina )关注我们。

2016-07-11 17:241974

评论

发布
暂无评论
发现更多内容

【设计模式】第十三篇 - 享元模式 - 连连看的图片共享

Brave

设计模式 享元模式 11月日更

深度探索 Gradle 自动化构建技术(四、自定义 Gradle 插件)

android 程序员 移动开发

混合开发框架最全对比,为什么我更推荐Flutter?

android 程序员 移动开发

疫情结束后,会影响程序员年后找工作吗?

android 程序员 移动开发

疫情过后,想找工作的你还不看这份资料就晚了!!史上最强总结

android 程序员 移动开发

瞬息万变的技术圈与焦虑的技术人,进阶Android需要掌握的那几个关键技术!

android 程序员 移动开发

灵魂拷问:Android开发初期之后怎么提升?怎么才能叫精通?方向在哪

android 程序员 移动开发

渣渣二本的辛酸面试之路:从深圳外包到杭州蚂蚁金服,4年小Android的爬坑历程

android 程序员 移动开发

滴滴国际化项目 Android 端演进

android 程序员 移动开发

漫谈MVVM(1)ViewModel_DataBinding核心原理(1)

android 程序员 移动开发

深入理解HTTPS协议

android 程序员 移动开发

深度探索 Gradle 自动化构建技术(二、Groovy 筑基篇)

android 程序员 移动开发

温故而知新:重新认识Activity的生命周期

android 程序员 移动开发

盘点2020年Android面试必备知识点

android 程序员 移动开发

深入理解JobScheduler与JobService的使用

android 程序员 移动开发

深入解析Flutter架构

android 程序员 移动开发

源码解析,Glide加载GIF图的原理竟然这么简单

android 程序员 移动开发

EMQ 获评“最具潜力边缘计算企业”,推动边缘计算生态发展

EMQ映云科技

物联网 IoT mqtt

用MVP模式构建Android代码

android 程序员 移动开发

疫情下中年IT的焦虑

android 程序员 移动开发

疫情被裁3个月,看我如何拿下腾讯offer(附面经+面试心得

android 程序员 移动开发

直播App中Android酷炫礼物动画实现方案(下篇):SVGA由来与Lottie的对比

android 程序员 移动开发

深度思考:已经开发8年的你,为何跳槽被多家大厂拒绝?为什么会迷茫Android开发还有什么能学习的

android 程序员 移动开发

漫谈MVVM(1)ViewModel_DataBinding核心原理

android 程序员 移动开发

玩转AppBarLayout,更酷炫的顶部栏(1)

android 程序员 移动开发

疫情下,中年IT的焦虑

android 程序员 移动开发

炒冷饭之Https 建立链接

android 程序员 移动开发

炸裂!一次Android实习经历告诉你:老爸不是张一鸣,该用什么技巧进字节

android 程序员 移动开发

牛掰!阿里P7大佬爆肝半个月,把安卓源码解析编成了508页的PDF

android 程序员 移动开发

漫谈MVVM(1)ViewModel_DataBinding核心原理(2)

android 程序员 移动开发

玩转AppBarLayout,更酷炫的顶部栏

android 程序员 移动开发

「企业上云」之云安全与持续优化_语言 & 开发_崔远智_InfoQ精选文章