AWS Technical Support AWS Security Group Inbound Rule Configuration Guide

把这三个问题回答清楚，你的规则就会自然地变得更“窄”、更安全。反过来，如果你先凭感觉把端口全放开，再慢慢收敛，过程中很容易留下不符合预期的残留规则。

安全组与 NACL 的关系：不要把职责搞混

很多人第一次配置网络时会把安全组和网络 ACL（NACL）混在一起。简单区分：

• 安全组：面向实例（或 ENI），状态型，主要管入站是否允许。
• NACL：面向子网，非状态型，需要同时考虑入站与出站，且规则是按顺序匹配。

如果你已经在子网级别使用 NACL 限制，仍然需要在安全组做最小授权，因为最终对实例的访问仍会取决于这两层的允许与拒绝组合。

配置前的准备：让变更更可控

在真正改规则之前，建议你做几项准备工作：

• 确认资源类型与端口需求：例如 EC2 上跑的是 Web（80/443）、SSH（22）、应用自定义端口还是数据库端口。
• 明确访问来源：来自公网还是 VPC 内？是某个子网、还是某个服务的安全组？
• 记录现状：导出当前入站规则，至少把端口、来源、协议写下来。你后面排错会省很多时间。
• 制定回滚策略：比如先在非生产环境验证，或准备好恢复到旧规则的方案。

安全组的变更通常是即时生效的，但一旦影响到线上流量，你就需要能快速定位是规则写错还是来源变化导致的。

逐步配置指南：为入站规则做一次“标准化”创建

下面按步骤讲清楚如何配置入站规则。不同控制台界面略有差异，但逻辑一致。

步骤 1：选择正确的安全组

首先进入 AWS 控制台，找到你要修改的安全组。检查它关联的资源（EC2 实例、ENI、弹性网卡等）。

常见错误是：你改了一个看似相关的安全组，但实例实际挂的是另一个安全组，导致你以为“规则没生效”。所以在动之前先确认关联关系。

步骤 2：理解默认状态与“允许/拒绝”机制

安全组的典型行为是：默认拒绝入站，你需要显式添加放行规则。你添加的每条入站规则是“允许”。

AWS Technical Support 这带来一个直接后果：如果你没有添加规则，端口访问会被拒绝；如果你添加了过宽规则，可能会导致本来不该进来的流量也能进。

步骤 3：选择规则类型（或手动指定协议与端口）

常见做法是选择 自带的模板（如 SSH、HTTP、HTTPS）。模板能降低配置出错率，但并不总适用于自定义端口或非标准需求。

手动配置时，你需要确定：

• 协议：TCP/UDP/ICMP。
• 端口范围：单端口还是范围。

尽量避免“一条规则放一大段端口”。如果你的服务只需要 8443，就写 8443-8443，而不是 8400-9000 这种宽范围。

AWS Technical Support 步骤 4：选择来源（Source）——优先安全组来源而不是 CIDR

来源是入站规则最重要的部分。来源可以是：

• CIDR：如 203.0.113.0/24。
• 安全组：允许来自另一个安全组的实例/网卡访问。

在很多架构里，使用“来源为安全组”比直接写 CIDR 更稳健：

• 当源实例扩缩容、迁移时，只要它仍属于该安全组，你的规则不需要改。
• 当源端 IP 变化时，规则不会失效。

如果只能用 CIDR，就要确保 CIDR 覆盖准确，并定期检查是否仍然符合当前拓扑。

步骤 5：添加描述与标签（如果你的团队使用）

控制台对规则的描述能力有限，但你可以在规则规划时为每条入站规则写清楚“为什么要开”。比如：

• Allow inbound 443 from ALB SG
• Allow inbound 22 from Bastion SG
• Allow inbound 5432 from App SG

这会显著降低未来排查成本，也能减少“后来的人不知道为什么这样配”的隐患。

步骤 6：应用变更后做验证

验证不只是“端口通不通”。你还要看连接是否来自期望来源、以及应用层是否报错。

• 从允许的来源主机执行连通性测试（比如 curl、telnet/端口探测、或你们已有的探测脚本）。
• 确认服务端在目标端口确实监听。
• 检查路由与目标实例的网络状态（子网路由、路由表、弹性网卡是否健康等）。

很多人只测“从我的机器能访问”，却忽略了实际线上来源不是这台机器。

常见场景的推荐入站规则写法

下面用典型业务来说明如何把规则写得更合理。你可以把它当作模板思路，而不是照抄端口。

场景 A：Web 服务对公网访问（HTTP/HTTPS）

推荐做法通常是：让公网流量先进入负载均衡（如 ALB），再由 ALB 的安全组访问后端实例。

• 后端实例安全组：入站允许 80/443 来自 ALB 的安全组。
• 不要直接让后端实例对 0.0.0.0/0 开 80/443（除非你明确知道后端就是要公网暴露）。

这样能把对外暴露的范围集中到负载均衡层，后端更安全，且源更可控。

场景 B：SSH 运维（强烈建议限制来源）

最常见的错误是把 22 端口对公网开放。更安全的方式是通过堡垒机（Bastion）或使用 VPN/专线。

• 入站 22：来源选择“堡垒机安全组”，而不是 0.0.0.0/0。
• 如果你必须用 CIDR，就只允许办公网或 VPN 网段，并确保网段不会频繁变化。

此外，建议运维上配合：

• 最小化需要 SSH 的实例范围。
• AWS Technical Support 开启更强的登录策略（密钥、禁止密码或降低暴力尝试风险）。

场景 C：数据库访问（只允许应用安全组）

数据库往往是最敏感的部分。你应该避免对整个 VPC 开放数据库端口。

• 入站数据库端口（例如 5432/3306/1433 等）：来源设置为“应用安全组”。
• 如果有只读/写分离，也可以分别使用不同规则或不同端口策略。

这样做的价值是：即便有人把一台不该访问数据库的实例放进了某个子网，也不会因为子网范围就获得访问权限。

场景 D：需要从特定服务到特定端口的内部调用

当你需要服务之间互相调用时，优先使用“来源为安全组”。例如：

• 服务 A（App SG）调用服务 B（Worker SG）上的端口 8080：写入站允许 TCP 8080 来自 App SG。
• 服务 B 只需要开放该端口，不要为其它无关端口开洞。

这种方式在扩容时不会频繁改规则，维护成本也更低。

入站规则的常见坑：不踩雷比你想的更重要

坑 1：端口写错或协议不匹配

看似简单，但实际经常发生。比如你以为是 TCP 443，结果应用监听的是 TCP 8443；或者你写了 UDP，但服务是 TCP。

建议做法：

• 确认应用监听协议与端口。
• AWS Technical Support 核对安全组规则的协议与端口范围。

AWS Technical Support 坑 2：把 0.0.0.0/0 当成“临时开一下”

临时开一段时间很常见，但常常会忘记关闭。并且临时开放会引入扫描、撞库、探测等风险。

如果确实需要对外开放，至少保证：

• 仅开放必要端口。
• 配合 WAF/限流/认证策略。
• 有明确的关闭时间或审批流程。

坑 3：只在安全组改了入站，忘了应用层或监听配置

安全组放行 ≠ 应用可用。你可能已放通端口，但应用没有监听、监听在别的网卡/地址上，或服务只接受特定 Host header。

排错时要同时检查：

• 实例网络与安全组
• OS 防火墙或容器网络策略（如果适用）
• 应用监听与日志

坑 4：引用“另一个安全组”时忽略了实例实际归属

当你用“来源为安全组”时，前提是源实例确实属于那个安全组。如果实例变更后安全组归属发生变化，你的规则可能会立刻失效。

建议用变更流程管理：把安全组归属的调整纳入同一次变更计划。

排错思路：当连接失败时如何一步步定位

网络故障最怕“猜”。你需要一个更系统的排查顺序。

第一步：确认失败发生在哪个方向与协议

确定你访问的是哪个端口、哪个协议、从哪里访问。比如你要访问的是 HTTPS（TCP 443），还是内部接口（TCP 8080）。

第二步：检查目标实例的安全组是否正确

确认你改的安全组确实绑定在目标实例（或 ENI）上。若目标有多个网卡或多个安全组，要逐一核对。

第三步：核对入站规则是否匹配“来源”与“端口范围”

来源不匹配是最常见原因之一。举例：

• AWS Technical Support 你以为源是某个 CIDR，但实际源 IP 不在范围内。
• 你用源安全组，但实际源实例不在该安全组。
• 端口范围写窄了或写成了另一协议。

第四步：检查路由与网络路径

即便安全组允许，路由错误也会导致连接失败。特别是跨子网、跨 VPC、或使用了网关/路由器时。

第五步：确认 OS/应用层没有阻断

某些情况下，实例内部还有额外防护层，比如操作系统防火墙、容器网络策略、或云代理的规则。排错时要把这些纳入考虑。

最佳实践：让入站规则长期保持“干净”

安全不是一次性配置，而是持续维护。下面是一些能显著降低风险的做法。

1）按角色分组安全组，而不是按“凑端口”

AWS Technical Support 建议围绕服务角色创建安全组，例如：

• ALB-SG
• Web-SG
• App-SG
• DB-SG
• Bastion-SG

规则写到“角色与角色之间”，通常比写到“某个临时 IP”更稳定。

2）优先使用安全组作为来源

当你能用“来源安全组”表达需求，就少用 CIDR。它更抗变化。

3）把对公网暴露集中到最少的层

一般来说，让公网先落到负载均衡或网关层，再由内部安全组控制访问后端。这样后端实例不会成为直接暴露面。

4）避免宽端口与宽网段

尽量做到“端口最窄、来源最小”。宽网段带来的问题不仅是风险增加，还有合规与审计的复杂度。

5）定期复查并清理遗留规则

上线后规则并不会自动变干净。建议定期复查：

• 是否仍需要某些临时开放端口
• AWS Technical Support 是否仍需要某些 CIDR（比如办公网改址后）
• 是否有人临时加了规则但没有申请关闭

复查的意义在于减少“安全债务”。

结语：把入站规则当作“访问合同”来写

安全组入站规则不是为了“让它能通”，而是为了“只让需要的人与协议进来”。当你用最小暴露、明确来源、窄化端口范围的方式来写规则，后续的排错会更少，安全风险也更可控。

如果你愿意从今天就开始改进一个点：优先把对公网的端口开放收紧到必要范围，并尽可能改用“来源为安全组”的表达。这样通常能在不大幅重构系统的前提下，立刻显著提升安全性。