[关闭]
@liuhui0803 2016-05-02T09:52:25.000000Z 字数 5118 阅读 1681

AWS论剑Azure:安全组之争

安全 多云战略


文章翻译自策略驱动的云管理平台——Scalr,作者Ron Harnik,翻译已获得本人授权,点击这里阅读英文原文。

用户在接受云技术过程中所面临的最大挑战之一是:必须习惯于用截然不同的方式完成各种任务。

与我合作过的很多IT和安全工程师都曾带领自己的公司迁入云平台,他们经常会犯同一个错误:在新技术中继续沿用老的范式。

虽然云本身已经不“新”了,但有关云的工作原理,以及不同任务需要用到哪些工具,这方面依然存在很多问题。在这一系列文章中,我们将着重介绍各大主要公有云和私有云平台的安全组(或防火墙规则),下文会将其称之为“四大”。

本文将重点介绍AWS和Azure的安全组。

云安全与传统防火墙截然不同(大部分情况下均是如此)

在传统网络中,通常使用防火墙对不同网络之间传输的流量进行筛选。在最基本的层面上,当一个数据包进入防火墙后,防火墙会通过一系列规则对其进行检查和对比,这些规则决定了是否传递或丢弃这个数据包。

对大部分云平台来说,这一系列任务的执行位置略有不同。此时不再通过专门的网络设施针对传入/传出的流量强制应用规则,而是会为每台服务器关联一套安全策略。更具体来说,需要针对每台服务器上的(虚拟)网卡应用防火墙规则。

3层Web应用 | 安全组
在云端获得保护的一种常规3层Web应用

请注意上述图例仅仅是范例,不同供应商的云平台具体的安全策略也会略有差异。不过在服务器层面进行分隔这种通用原则对大部分云平台来说都是类似的。

需要注意的是,云安全解决方案并不只有安全组。市面上的各种解决方案为云部署提供了不同层面的安全控制,例如Trend Micro的Deep Security或Palo Alto Networks的VM-Series Next Generation Firewall。虽然安全组衍生出不同变体,但依然是大部分云平台内建的安全控制机制,为云部署提供了最基本的安全防护。

AWS安全组

在AWS中,安全组是指不同实例所关联的一系列获得批准的(仅“允许”)传入和传出规则。在VPC内创建实例后,需要将其关联至某一安全组。默认情况下,所有VPC实例都关联了每个VPC中包含的“默认”安全组。

关于AWS安全组,需要注意下列问题:

每个安全组有两套规则:传入规则和传出规则。传入规则决定了流量如何进入实例,传出规则可用于对离开实例的流量进行检查。

安全组规则是有状态(Stateful)的。举例来说,如果配置传入规则“允许来自1.1.1.1的HTTP流量”,就无需为了让这个实例发送HTTP响应而创建对应的传出规则。

上文提过,安全组只能包含“允许”规则,这种设计造成了一种有趣的局面:变则的顺序变得不重要了。作为曾经负责过网络/防火墙的人,不同操作的执行顺序对我自己来说非常重要。在为Cisco ASA或Juniper SRX配置安全策略时,必须确保不同规则不能相互抵消。

通常的最佳实践是创建白名单,这种名单包含大量允许的规则,可允许必要的流量顺利通过,同时通过暗含的或明确指定的“拒绝全部”规则处理其他所有非必要流量。而正是因为这一原因,导致产生大量过于笨重的策略,其中可能包含数千条非常具体的规则,例如“1.1.1.1至2.2.2.2”。

提到这一问题的原因在于,如果你跟我一样,在以往的职业生涯中曾经需要用安全组和虚拟网关取代物理防火墙和路由器,你会注意到,新技术不仅会在具体实施中造成影响,同时也会影响到你的规划工作。

每个安全组规则包含4个字段:

虚拟的私有云安全组
安全组应用的传入规则

类型、协议和端口范围的概念相当直观。来源/目标可用于指定IP地址,地址范围,或其他安全组。如果指定另一个安全组作为来源或目标,则可代表关联至该安全组的每个实例,借此可创建出更清晰的网络拓扑。

EC2 Classic安全组

如果你的AWS帐户足够老,也许可以支持EC2 Classic。EC2 Classic会将计算视作一种位于每个地区的大型资源池,而VPC可用于创建相互独立的云部署。一般来说,EC2 Classic安全组的具体表现与VPC安全组类似,但存在下列差异:

有关安全组的最佳实践

对于AWS安全组,以及大部分其他云平台的安全组来说,限制安全组数量的蔓延都可看做一项最佳实践。重点在于需要尽可能避免产生下列极端的最糟糕“实践”:

为避免以无组织无序的方式实现安全,重点在于要事先创建相关安全组,并在创建实例的过程中酌情分配。

为所有实例使用“默认”安全组,实际上依然是在沿用古老的“外紧内松”安全模式。使用“默认”安全组还会使得基础结构面临各种类型的风险:当实例需要接受某种全新类型的访问方式时,很容易便可添加另一条规则,但如果将这条规则加入“默认”安全组,会导致所有相关联的虚拟机变得更易于遭受攻击。

您可以考虑使用下列AWS安全范式。

由宽到窄的安全组

创建少量“常规用途”安全组,并将其作为VPC的安全基准线。例如,可以为Windows和Linux实例分别创建用于允许RDP和SSH连接的安全组,针对相应的管理工具打开必要的端口,并用这些安全组取代“默认”安全组。因为这些安全组会应用给VPC中的大部分实例,并且无需考虑实例的具体职能,因此还需要考虑是否真的需要这些安全组的成员能够相互通讯。

安全基准线就位后,可以分别针对Web服务器、数据库、ELB、测试环境,或者与您用例有关的任何其他环境创建基于角色的安全组。

基于角色的安全组

Azure网络安全组

AWS适用的很多重要原则同样也适用于Azure,但Azure网络安全组(NSG)也有一些重要差异:

与AWS安全组类似,Azure NSG提供了传入和传出两套规则。

每个规则可包含下列属性:

每个NSG中的默认规则为:

传入:
Microsoft Azure安全组

传出:
Microsoft Azure安全组

请留意默认的Azure标签:VirtualNetwork、AzureLoadBalancer,以及Internet。

根据Azure文档的介绍:

与AWS安全组不同,Azure NSG之间具备层次结构。NSG可应用给虚拟机,子网,或同时应用给这两者。应用给某一子网的NSG也会同时应用该该子网包含的所有虚拟机。

如果NSG同时应用给某一子网,以及该子网中的所有虚拟机,传入的流量将首先到达子网NSG,随后到达虚拟机NSG。此处一定要注意,只有子网和虚拟机NSG同时允许的情况下流量才能顺利通过。

安全组 | Microsoft Azure

但实际使用时会更复杂一些

Microsoft Azure有两种部署模式:经典(Classic)和资源管理器(Resource Manager),简单来说一旧一新。这两种部署模式对Azure云平台的使用方法有所不同,并且资源供应的处理方式也不相同。强烈建议阅读资源管理器部署和经典部署之间的差异这篇文章。

经典部署 - NSG会应用给虚拟机。这意味着NSG规则会应用给虚拟机发出和收到的所有流量。

资源管理器部署 - NSG可应用给网卡。这意味着NSG规则只会应用给相关网卡。在多网卡计算机上,除非明确配置,否则NSG将不处理来自其他网卡的流量。

在这两种部署模式中 - NSG都可应用给子网。这意味着NSG规则可以应用给属于该子网的所有网卡。

我知道这一切看起来有些乱。Microsoft推荐为新的资源使用资源管理器部署,并建议将现有的所有经典部署资源重新部署为资源管理器模式。建议阅读下列重要且实用的信息:

网络安全组最佳实践

上文讨论的大部分实践都适用于不同云平台。如果你的基础结构包含多个云平台的服务,最好能够尝试以类似的方式针对不同云平台强制应用安全保护。

大部分与Azure有关的最佳实践在用于管理NSG时,都能让你的工作生活更为简单。

结论…

本文讨论的重点如下:

我们很乐意了解你对云安全的见解或体验!这一系列的下篇文章将介绍OpenStack和Google Compute Engine的安全策略。

欢迎随时联系我:ron@scalr.com。

关于作者

Ron Harnik

Ron Harnik

Scalr产品营销经理。Ron是一位技术爱好者、优客(YouTuber)、极客、电视剧追剧党,他还会做非常美味的早餐(麦片粥)。

添加新批注
在作者公开此批注前,只有你和作者可见。
回复批注