安全组与网络 ACL：如何选择您的 AWS VPC 防火墙
在 Amazon Web Services (AWS) 中设计安全的虚拟私有云 (VPC) 环境时，管理员依赖多层控制来管理网络流量。在网络层面过滤流量的两个基本组件是安全组 (SG) 和网络访问控制列表 (NACL)。
虽然两者都充当虚拟防火墙并使用规则来控制入站和出站流量，但它们在 VPC 架构的基本不同层级上运行，并使用不同的机制进行规则评估。理解这些差异——特别是它们的范围、状态性以及规则处理方式——对于建立健壮且合规的网络安全态势至关重要。本指南提供了全面的比较，并解释了如何有效利用 SG 和 NACL 来实现深度防御。
AWS VPC 中防火墙的作用
AWS 在 VPC 内部的两个主要层面提供网络安全：
- 实例级别（安全组）： 作为特定 EC2 实例或资源（如 RDS 数据库或弹性负载均衡器）的防火墙。它控制进出网络接口的流量。
- 子网级别（网络 ACL）： 作为整个子网的无状态防火墙，控制进出子网边界的流量流。
深入了解安全组 (SG)
安全组充当单个资源的初级、细粒度防火墙。它们是有状态的，并在 OSI 模型中工作在第 4 层（传输层）。
安全组的关键特性
| 特性 | 描述 | 对使用的影响 |
|---|---|---|
| 范围 | 直接应用于实例的网络接口 (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 规则: 允许 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 | 允许 (Web 流量进入) |
| 110 | 出站 | TCP | 1024-65535 | 0.0.0.0/0 | 允许 (Web 响应出去 - 临时端口) |
| * | 隐式拒绝 | 所有 | 所有 | 所有 | 拒绝 (最后处理) |
警告： 如果在 NACL 中遗漏了临时端口对应的出站规则，流量会到达实例（由于入站规则），但响应会在子网边界被丢弃，从而导致连接超时。
比较总结：SG 与 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。
深度防御方法
在典型的、设计良好的 VPC 中，流量必须同时通过 NACL 和安全组。如果任一安全控制拒绝了流量，数据包将被丢弃。
- 入站流： 流量进入子网 -> NACL 检查规则 -> 流量到达实例 ENI -> 安全组检查规则 -> 流量到达应用程序。
- 出站流： 应用程序生成响应 -> 安全组（状态检查通过）-> 流量离开实例 ENI -> NACL 检查规则 -> 流量离开子网。
通过利用 NACL 进行粗略分段和拒绝规则，以及利用 SG 进行精确、有状态的应用程序级别权限，您可以最大程度地提高安全有效性，同时保持配置的简便性。
结论
安全组和网络 ACL 不能互换；它们是旨在保护 AWS VPC 不同层的互补工具。安全组在实例级别提供操作性、面向应用的安全性，通过有状态性优先考虑简便性。网络 ACL 在子网级别提供了一个强大的、强制性的屏障，提供明确的拒绝功能，并保护网络边界。掌握它们在范围和状态性上的差异，可确保您设计的 VPC 架构不仅功能正常，而且能够抵御未经授权的网络访问。