EC2安全组实例捆绑安全策略

除少数特殊情况以外，AWS客户很少会关心或者考虑控制云基础设施的位置或配置。EC2安全组和网络访问控制列表将有助于保护工作负载。

当企业架构师们在为云设计应用架构时，他们会面临众多的挑战。这些挑战之一就包括他们无法掌控物理硬件或网络的无所适从感。了解如何确保资源安全性将是一项棘手的工作，因为这些资源从物理上来说都是不在用户控制范围内的，但是作为工程师，他们必须将未知的、抽象的实施与已知的、熟悉的概念一一联系起来。

确保云应用安全性的基本要求是，了解如何实现资源隔离。在内部部署环境中，这一点涉及到路由器、子网和防火墙。而在云环境中，当在共享基础设施上运行时，服务器隔离似乎是有一点问题的，因为其中某台特定虚拟机的物理位置不仅是未知的而且是有可能会发生变化的。虚拟机管理程序提供了针对服务器上其他应用程序的内存保护，但这一做法可能还无法让所有的IT团队感到满意。所以，企业用户应如何在AWS中实现针对其他用户的网络隔离，以及在其自有虚拟机组中的网络隔离？弹性计算云（EC2）安全组是回答这个问题的关键部分。

EC2安全组可作为虚拟子网和客户端防火墙的一个组合。EC2安全组中的每一个实例都共享着一个通用安全策略；类似于防火墙的规则控制着各个组之间的流量。防火墙的默认行为是拒绝流量的，而特定规则可允许出入站的连接。

安全组与亚马逊虚拟私有云（VPC）密切相关，后者可作为某家用户AWS基础设施中的子网。两者都提供了基于端口的访问控制，安全组就如同基于服务器的防火墙（例如Linux iptables），而VPC则类似于基于网络的传统路由器或防火墙，其预定义安全策略覆盖了整个子网。下表重点突出了AWS安全组和VPC之间的差异。

安全组为每个虚拟机控制着出入站的流量，而一个组内的所有实例共享着相同的策略；VPC ACL则为网络子网做着相同的工作。两个安全构建体是正交的：特定VPC中的EC2实例（即共享通用网络安全策略的多个EC2实例）可以属于不同的安全组。但是，如果管理员在实例化一个实例时没有指定EC2安全组，那么系统会为VPC自动分配默认组。如果管理员还没有定义任何的VPC，那么AWS会创建一个默认网络。

EC2安全组的大拇指规则

EC2安全组在AWS中为虚拟机网络安全策略基线提供了一个结构，它应当被视为第一道防线——一个必要但不充分的安全组件。

企业AWS部署也应包括一个或多个VPC以便为网络安全策略增加一个层。

我们提出以下建议策略，以确保AWS部署：

为每一个应用、应用层和管理用户组创建一个独立的安全组，并使用专为特定工作负载或服务层需求而调整的策略：不要为每一个实例创建一个独立的安全组；不要把所有的实例都放在同一个安全组。这种旧式的“护城河和城堡”式的防火墙策略明显外强中干，面对如今使用多重攻击和内部试探在先针对性攻击在后的攻击方式已无法发挥防火墙作用；不要依靠VPC的默认AWS安全组。在默认情况下，AWS只允许默认组中其他实例的入站流量和所有出站流量。这可能并不是用户所需要的。

仔细规划网络路由和子网设计（VPC），并使用网络之间的严格ACL。网络ACL为互联网和应用程序协议提供了精细化控制，例如GRE、IPSec、ICMP、HTTP、SSL、DNS以及源/目的IP地址范围之间的流量限制。一方面VPC ACL独立于安全组，另一方面两者又相互协作。在不必要的流量和潜在有害的流量到达EC2实例和安全组策略之前，VPC ACL和安全组就就把它们剔除了。

当为网络和实例进行ACL规则定义时，使用最低权限标准。只允许绝对需要的连接、端口和用户。

特别关注出站安全组策略。出站规则限制对特定地址的连接，例如Dropbox或中国黑客，以及可用于未授权数据泄露的端口（FTP）。

支持无所不在的日志记录：VPC流量日志、CloudTrail、亚马逊身份与访问管理等等。事件日志可提供故障问题排除、现场安全漏洞和随时间推移安全策略完善所必须的详细信息。

正如任何安全指南一样，每一家IT组织都必须确定其安全配置文件，并根据适应特定应用和使用场景需要定义策略细节。尽管如此，正确睿智地使用EC2安全组是支持云计算安全策略的坚实支柱之一。