安全组与网络ACL：如何选择您的AWS VPC防火墙

在Amazon Web Services（AWS）中设计安全的虚拟私有云（VPC）环境时，管理员依赖多层控制来管理网络流量。在网络层面过滤流量的两个基础组件是安全组（SG）和网络访问控制列表（NACL）。

它们在控制台中看起来相似，但失败方式截然不同。安全组通常是描述应用程序意图的地方。网络ACL则是强制执行广泛子网边界或紧急拒绝的地方。

AWS VPC中防火墙的角色

AWS在VPC内提供两个主要层面的网络安全：

实例层面（安全组）： 充当特定EC2实例或资源（如RDS数据库或弹性负载均衡器）的防火墙。它控制进出网络接口的流量。
子网层面（网络ACL）： 充当整个子网的无状态防火墙，控制进出子网边界的流量流。

深入探讨安全组（SG）

安全组作为单个资源的主要、细粒度防火墙。它们是有状态的，并按协议、端口和源或目标进行过滤。

安全组的关键特性

特性	描述	使用影响
范围	直接应用于实例的弹性网络接口（ENI）。	控制进出实例本身的流量流。
有状态性	有状态。如果入站请求被显式允许，则相应的返回流量（出站响应）会自动允许，无论出站规则如何。	简化配置；只需定义发起流量方向。
规则类型	仅允许。无法使用显式拒绝规则。不匹配显式`ALLOW`规则的流量会被隐式拒绝。	专注于定义允许的内容。
评估	所有规则在做出决定前都会被评估。它们没有编号，并且直到所有`ALLOW`规则都失败后，才会处理隐式`DENY`。	顺序无关紧要；所有规则被平等对待。

安全组配置示例

要允许SSH访问（端口22）EC2实例，您只需要一条入站规则。SSH响应的出站规则由SG的有状态特性自动处理。

类型	协议	端口范围	源	描述
入站	TCP	22	0.0.0.0/0（或特定管理员IP）	允许SSH访问
出站	全部	全部	0.0.0.0/0	（默认：允许所有流量，但可根据需要限制）

# 有状态流的概念表示
用户（源IP） --> [入站SG规则：ALLOW 22] --> EC2实例
EC2实例（响应） --> [隐式状态跟踪] --> 用户（收到响应）

最佳实践提示： 始终使用最小权限原则定义安全组规则。尽可能限制源IP范围，而不是允许0.0.0.0/0。

深入探讨网络ACL（NACL）

网络ACL提供第二层防御，作为子网边界的无状态过滤器。它们对于网络分段和广泛拒绝策略非常强大。

网络ACL的关键特性

特性	描述	使用影响
范围	应用于整个VPC子网。一个子网一次只能关联一个NACL。	控制进出子网的所有流量，影响其中的所有实例。
有状态性	无状态。入站请求和相应的出站响应都必须被显式允许。	需要仔细配置返回流量（临时端口）。
规则类型	允许和拒绝。您可以显式定义规则以允许或阻止流量。	非常适合阻止已知恶意IP或拒绝网络范围内的特定协议。
评估	规则编号（1到32766）并按顺序评估，从最低编号开始。第一个匹配的规则立即应用。	规则顺序至关重要。隐式拒绝规则（最后处理的规则）拒绝所有未被显式允许的内容。

处理无状态流量（临时端口）

由于NACL是无状态的，您必须考虑客户端连接到您的服务器时使用的临时端口。当客户端发起连接时，它使用目标端口（例如，HTTP为80）和一个高编号的源端口（临时端口范围，通常为1024-65535）。

要允许Web流量（HTTP）进入子网，您需要两条规则：

入站规则： 允许目标端口上的流量（例如，80）。
出站规则： 允许使用临时源端口返回客户端的流量。

规则编号	类型	协议	端口范围	源/目标	规则操作
100	入站	TCP	80	0.0.0.0/0	ALLOW（Web流量进入）
110	出站	TCP	1024-65535	0.0.0.0/0	ALLOW（Web响应外出 - 临时端口）
*	隐式拒绝	全部	全部	全部	DENY（最后处理）

警告： 如果您在NACL中遗漏了临时端口的相应出站规则，流量将到达实例（由于入站规则），但响应将在子网边界被丢弃，导致连接超时。

比较总结：SG vs. NACL

下表总结了两种防火墙类型之间的关键区别：

特性	安全组（SG）	网络ACL（NACL）
适用范围	实例/ENI层面	子网层面
状态	有状态	无状态
规则类型	仅允许	允许和拒绝
规则评估	所有规则评估，无特定顺序。	规则按编号顺序评估（最低优先）；第一个匹配获胜。
默认行为	拒绝所有入站，允许所有出站（除非限制）。	默认NACL允许所有入站/出站。自定义NACL拒绝所有入站/出站。
对流量影响	仅当流量目的地为或源自关联资源时应用规则。	过滤通过子网边界的流量，影响子网中的所有资源。

选择合适的防火墙：场景和最佳实践

成功的VPC安全依赖于在分层方法（纵深防御）中一起使用SG和NACL。

何时优先使用安全组

安全组应是过滤网络访问的主要工具，因为它们具有有状态性，并且能够引用其他SG，从而简化应用程序配置。

细粒度应用程序控制： 使用SG精确定义特定应用程序所需的端口和协议（例如，仅允许从Web服务器SG到数据库SG的端口3306流量）。
内部通信： 管理同一子网内或跨子网实例之间的流量安全（例如，确保负载均衡器可以与其目标组通信）。
易于管理： 由于它们是有状态的，SG需要的规则更少，并且比使用NACL管理临时端口更不容易出错。

何时实施网络ACL

NACL最适合用于设置广泛的网络范围边界和分段策略。

广泛拒绝策略： 使用显式DENY规则（规则编号100）在流量到达实例之前，阻止整个子网中的特定恶意IP地址或IP范围。
子网分段： 在架构的各层之间强制执行严格边界（例如，确保数据库子网NACL显式拒绝来自互联网的所有入站流量，无论SG如何配置）。
合规要求： 某些合规标准可能要求子网级过滤，使NACL成为必需品。
无状态协议过滤： 如果您需要过滤SG无法有效自行管理的无状态协议（尽管对于标准TCP/UDP流量来说这很少见），则NACL是必需的。

导致中断的常见错误

最常见的NACL中断是忘记返回流量。有人允许入站TCP 443到公共子网，但出站规则过于严格。负载均衡器或实例收到SYN，但响应在出去的路上被丢弃。从客户端看，这看起来像超时，而从实例看，服务可能看起来完全健康。

另一个错误是将NACL用于每个应用程序的策略。如果一个子网包含Web、Worker和管理员实例，一个NACL适用于所有实例。为一个工作负载添加的规则可能会意外暴露或破坏同一子网中的另一个工作负载。如果您需要不同的网络行为，请使用不同的安全组，并且仅在需要强制执行真正边界时才考虑单独的子网。

规则编号也需要小心。留出间隔，如100、110、120，而不是1、2、3，以便以后可以插入紧急规则。请记住，第一个匹配获胜。规则90处的拒绝将击败规则100处的允许，即使对于快速浏览控制台的人来说，允许看起来更具体。

对于安全组，常见的错误是广泛的源范围。公共负载均衡器的443端口上的0.0.0.0/0可能是正常的。SSH、RDP、Redis、PostgreSQL或内部管理员API上的相同源通常是个问题。在VPC内部优先使用安全组引用，并为操作员访问使用窄CIDR。

当您继承现有VPC时，导出规则并按意图分组：公共入口点、应用程序到应用程序流量、数据存储、管理和紧急拒绝。没有明确所有者或原因的规则通常是过时暴露所在。

纵深防御方法

在典型的、设计良好的VPC中，流量必须同时通过NACL和安全组。如果任一安全控制拒绝流量，数据包将被丢弃。

入站流： 流量进入子网 -> NACL检查规则 -> 流量到达实例ENI -> 安全组检查规则 -> 流量到达应用程序。
出站流： 应用程序生成响应 -> 安全组（有状态检查通过） -> 流量离开实例ENI -> NACL检查规则 -> 流量离开子网。

通过利用NACL进行粗粒度分段和拒绝规则，以及SG进行精确、有状态、应用程序级别的权限，您可以最大化安全有效性，同时保持配置简单性。

实用的设计模式

对于大多数应用程序VPC，从安全组开始。给负载均衡器一个面向公众的安全组，给应用程序实例一个仅接受来自负载均衡器安全组流量的安全组，给数据库一个仅接受来自应用程序安全组在数据库端口上流量的安全组。该模型遵循应用程序依赖关系图，并能承受IP更改。

更谨慎地使用NACL。一个好的NACL用例是对已知恶意CIDR的子网级拒绝、数据库子网的硬边界，或在流量到达子网中任何ENI之前必须应用的合规规则。当团队试图在那里镜像每个应用程序规则时，NACL会变得痛苦。无状态返回端口规则很容易出错，一个低编号的拒绝可能会破坏整个子网。

当连接超时时，检查数据包路径中的两个层。对于公共子网中EC2实例的入站互联网流量，请求必须通过入站NACL规则、路由表和入站安全组规则。响应必须通过有状态安全组跟踪和出站NACL规则。如果SG看起来正确但客户端仍然挂起，则NACL临时端口规则通常是缺失的部分。

最清晰的思维模型是：安全组说明哪些资源可以与哪些其他资源通信；NACL说明子网永远不会允许什么。保持这些职责分离，设计将更易于审计。