AWS 论剑 Azure：安全组之争

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

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

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

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

本文将重点介绍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 个字段：

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

(点击放大图像)

安全组应用的传入规则

类型、协议和端口范围的概念相当直观。来源/ 目标可用于指定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、测试环境，或者与您用例有关的任何其他环境创建基于角色的安全组。

(点击放大图像)

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 中的默认规则为：

传入：

(点击放大图像)

传出：

(点击放大图像)

请留意默认的 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 同时允许的情况下流量才能顺利通过。

(点击放大图像)

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

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 是出于向后兼容性的目的提供这种规则。

结论

本文讨论的重点如下：

• 云计算催生了一种全新的安全模式，传统的防火墙概念可能无法始终适用
• 在规划云环境的安全性时，需要考虑云战略日后扩展的可能性，以及在环境中引入更多平台的可能性。请使用一致的方式管理策略，如果能让 AWS 和 Azure 的策略实现一致的效果，无疑可以让你的管理工作更为简单。

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

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

关于作者

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

感谢陈兴璐对本文的审校。

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