转载

AWS论剑Azure：安全组之争

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

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

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

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

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

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

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

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

(点击放大图像)

AWS论剑Azure：安全组之争

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

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

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

AWS安全组

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

关于AWS安全组，需要注意下列问题：

这并不是一种EC2服务，而是属于VPC提供的服务，也可用于保护其他实体，例如RDS或ELB。
默认情况下，安全组存在一些局限，但可申请对其扩展：
- 每个VPC最多可创建500个安全组
- 每个安全组最多可包含50个规则
- 一个网络接口最多可应用5个安全组
在将安全组关联给某个实例后，实际上是将其关联给主要网络接口。此外可通过ENI（Elastic Network Interface）的方式添加额外的接口。
除非明确指定，否则所有实例均会自动关联“默认”安全组。“默认”安全组的初始设置包括：
- 只允许来自关联了同一“默认”安全组的实例所发出的传入流量
- 允许所有传出的流量

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

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

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

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

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

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

类型
协议
端口范围
来源/目标（传入/传出）

(点击放大图像)

AWS论剑Azure：安全组之争

安全组应用的传入规则

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

EC2 Classic安全组

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

只能在创建实例时配置实例的安全组：一旦实例创建完毕开始运行，就只能从关联的安全组中添加或删除规则，无法为其添加或删除安全组（注意：如果修改安全组的规则，改动将影响该安全组关联的所有实例）。
EC2 Classic安全组会绑定至特定地区。若要将某个实例与某个安全组关联，实例和安全组必须位于同一个地区。
在EC2-Classic中，一个实例最多可关联500个安全组，一个安全组最多可添加100条规则（注意：如果某个实例需要多至500个安全组，那肯定是因为其他哪里的设置有误）。

有关安全组的最佳实践

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

为每个新实例使用一个新的安全组
为每个新增的访问需求创建一个新的安全组
所有实例使用同一个安全组

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

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

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

由宽到窄的安全组

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

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

(点击放大图像)

AWS论剑Azure：安全组之争

Azure网络安全组

AWS适用的很多重要原则同样也适用于Azure，但Azure网络安全组（NSG）也有一些重要差异：

NSG可应用于特定虚拟机、子网，或同时应用给这两者
NSG可同时包含“拒绝”和“允许”规则 - 这意味着规则的顺序（或优先级）开始变得重要！
与EC2 Classic安全组类似，Azure NSG只能应用给在同一地区创建的资源
Azure提供了一项名为终结点ACL（Endpoint ACL）的安全功能，同一虚拟机不能同时应用NSG和终结点ACL
所有NSG包含了一套无法更改或删除，但可以覆盖的默认规则

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

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

名称
优先级 - 作为一则最佳实践，可以为优先级使用较大增量的数字（例如100,200），这样在新增规则时就不需要反复修改不同规则的优先级
来源 - 任意/CIDR块/标签（标签的介绍见下文）
协议 - TCP/UDP/任意
来源端口 - 范围/单一端口/任意
目标 - 任意/CIDR块/标签（标签的介绍见下文）
目标端口 - 范围/单一端口/任意
操作 - 允许/拒绝

每个NSG中的默认规则为：

传入：

(点击放大图像)

AWS论剑Azure：安全组之争

传出：

(点击放大图像)

AWS论剑Azure：安全组之争

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

根据Azure文档的介绍：

VIRTUAL_NETWORK（虚拟网络）: 这个默认标签可代表你的所有网络地址空间。其中可以包含虚拟网络地址空间（Azure中定义的CIDR范围）、已连接的本地环境地址空间，以及已连接的Azure虚拟网络（本地网络）。
AZURE_LOADBALANCER（Azure负载平衡器）: 这个默认标签可代表Azure的基础结构负载平衡器。负载平衡器可转换为Azure数据中心内某个用于执行Azure运行状况探测任务的IP地址。
INTERNET（互联网）: 这个默认标签可以代表虚拟网络之外，可从公众互联网访问的IP地址空间。其范围也包括Azure自行拥有的公众IP地址空间。

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

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

(点击放大图像)

AWS论剑Azure：安全组之争

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

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

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

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

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

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

什么是网络安全组？ - 提供了Azure NSG使用方式的绝佳范例，以及经典部署和资源管理器部署方式之间的重要差异。
创建具有多个NIC的VM - 了解如何在Azure虚拟机中使用多个网卡。
了解资源管理器部署和经典部署 - 这篇文章上文也推荐过，可以帮您了解部署模式之间的重要差异，以及针对不同用例所能产生的影响。

网络安全组最佳实践

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

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

使用资源管理器- 可行的情况下尽量使用资源管理器部署，而不要使用经典部署。Azure正在全面转向资源管理器部署，并会逐渐为这种部署模式增加更细致的控制机制。此外新版Azure管理门户也使得NSG的创建和修改工作变得更简单。如果使用云管理平台，请务必使用能够支持这些新API的平台。
使用白名单- 由于可以同时使用“允许”和“拒绝”规则，不同规则之间很有可能相互抵消。为了让工作变得简单些，请按照其他云平台设置安全组的方式设置Azure NSG：创建一系列“允许”规则，其他内容通过“全部拒绝”规则处理。
不要使用黑名单- 或者也可以换种方式主要使用“拒绝”规则，并使用一个“全部允许”规则处理其他内容。但这种做法可能造成过于宽松的策略，以及大量“拒绝”规则。此外一些合规制度不允许针对敏感信息的保护使用“全部允许”规则。这是一种很糟糕的实践，只能猜测Microsoft是出于向后兼容性的目的提供这种规则。