安全组与网络 ACL

1 策略过滤回答什么问题：路由通了还不等于允许连接

C9 已经为订单系统安排了地址、子网、路由与网关。本课沿用这些路径，并假设路由配置正确。现在应用仍然连不上数据库，问题就从「包往哪里走」推进到「这个包是否允许经过」。路由给出下一跳，策略过滤决定是否放行；连接成功还要求目标主机接收请求，且服务正在监听。

描述连接时，先写清 5 元组：源 IP、源端口、目标 IP、目标端口和传输层协议。例如应用发出 TCP 请求 10.20.2.15:49160 → 10.20.3.21:5432，其中 5432 是数据库服务端口，49160 是客户端此次连接选择的源端口。把两端地址或端口写反，会把看似合理的规则加到错误方向。相同端口号的 TCP 与 UDP 也不是同1种允许关系。

策略通常不只存在于 1 个位置。安全组可以保护某张网卡，网络 ACL 可以保护某个子网边界，主机防火墙仍可能继续筛选。路由通而安全组拒绝，连接失败；安全组允许而网络 ACL 拒绝，连接也失败；各层都允许而数据库只监听本机回环地址，远程访问仍失败。不能把其中某层的「允许」解释成整条路径的成功承诺。

排查时采用稳定顺序：解析 → 路由 → NACL → SG → 主机防火墙 → 监听。它是整理证据的教学顺序，不是所有云平台内部执行过滤的物理顺序。先确认域名解析到预期地址，再沿 C9 的路径定位涉及的子网与网卡，然后逐层检查允许条件。反向响应也要沿对应路径检查，尤其不能漏掉无状态过滤。

最有价值的问题不是「端口开了吗」，而是「哪个源，通过什么协议，从哪个端口，访问哪张网卡上的哪个端口，在什么时间失败」。记录这份连接描述后，后续规则、日志和测试才有共同参照。本课讨论的是网络来源及连接策略，不把安全组名称理解为用户身份，也不延伸到 C6 的身份权限体系。

2 安全组：有状态、绑定网卡与允许合并

安全组可以理解为赋给网卡类资源的连接允许集合。不同产品可能通过实例、负载均衡器或其他资源入口配置，但排查时应落到实际承载流量的网络接口，确认它绑定了哪些组。实例详情页上的某个组名，并不天然代表这台实例所有接口的全部策略。

常见实现的核心性质是有状态：当请求按规则获准建立连接，系统会记录连接状态，属于该连接的响应通常自动获准返回。应用访问数据库时，数据库安全组允许来自应用的 TCP 5432 入站，应用安全组也允许相应出站；随后数据库发回应用临时端口的响应，一般不需要在应用安全组额外开放一片入站临时端口。这里说的是已获准连接的响应，不是允许数据库随意向应用发起新连接。

有状态也不等于永远记住连接。空闲超时、连接跟踪能力、特殊协议以及经过中间设备后的流量处理，均取决于实现。策略变更对已有连接何时生效也可能不同。收紧规则后的验收应包含新建连接，不能仅凭原有数据库连接池还在工作，就判断规则没有收紧或规则完全正确。

许多安全组主要提供允许规则。同1组内多条允许通常合并，绑定到同一网卡的多个安全组也常按允许并集合并。假设网卡绑定 sg-app、sg-maint、sg-old 共 3 个组：第 1 个只允许负载均衡器访问 8080，第 2 个允许办公出口访问 22，第 3 个允许 0.0.0.0/0 访问 8080。最终 8080 仍向全部 IPv4 来源开放。第 1 个组的精确规则不会覆盖第 3 个组的宽规则。

这解释了「我已经删掉允许，为什么仍然能连」的1类问题：管理员只看了自己编辑的组，没有看网卡绑定的全部组。在这种允许合并模型里，增加更窄的允许规则不会收紧已有的更宽允许；必须处理真正提供宽许可的规则或绑定。具体产品若提供拒绝规则或不同合并方式，应按其实际求值规则评估。

安全组引用也容易误读。sg-db 允许来源 sg-app，表示授权符合该产品引用语义、带有 sg-app 的网卡集合访问数据库，不是把 sg-app 的规则复制进 sg-db。应用组中允许办公来源登录，不会因此让办公来源直接获得数据库权限。引用适合表达角色之间的连接，但组的绑定变更也随之成为安全边界变更。

不要凭记忆推断默认规则。默认组、自建组、控制台向导与基础设施模板可能有不同的入站、出站起点；有的默认允许广泛出站，有的模板会收紧。创建完成后读实际规则，逐项确认协议、方向、地址族、端口和来源，才算完成配置。

3 网络 ACL：无状态、子网边界与编号命中

网络 ACL，简称 NACL，在本课中指子网边界上的访问控制表。教学以常见的无状态模型为例：每个包独立匹配规则，设备不会因为先前允许了请求，就自动允许响应。因此请求方向和返回方向都必须有匹配的允许条件。安全组已经认可连接，不能替另1层无状态规则补上返回许可。

与按允许并集合并的安全组不同，典型 NACL 同时支持允许与拒绝，并按规则号从小到大检查，首条命中就停止。以下是 AWS 风格的教学例子，编号、字段及默认行为仍应查对应产品：入站规则 100 允许来自应用子网的 TCP 5432，规则 200 拒绝来自某个被隔离应用地址的 TCP 5432。如果那个地址也属于应用子网，它先命中 100，后面的拒绝就不起作用。

要让这个例子中的隔离有效，应将精确拒绝放在更早的位置，例如 90，再由 100 允许其余应用地址。数字本身没有神奇作用，关键是较早规则会遮住较晚规则。审查规则时必须带着实际包逐条求值，不能只确认表里「存在拒绝」。

方向始终以正在检查的子网边界为参照。应用到数据库的请求，是应用子网的出站，也是数据库子网的入站；数据库响应则是数据库子网的出站、应用子网的入站。对于跨子网连接，如果两侧都使用自定义 NACL，就要分析这些方向，不能只编辑数据库子网的入站表。实际平台对同子网流量是否经过这类边界过滤也需核实。

默认 NACL 有时较宽松，新建自定义 NACL 却可能从拒绝起步。迁移时若只照着服务清单补入站端口，容易让响应落到末尾拒绝。切换子网关联也会影响整个子网的适用流量，应先列出受影响连接，再检查返回规则。这里不把某个厂商的默认表当成通用事实。

NACL 适合承担明确的子网边界限制，例如阻止某类来源进入某个区域；安全组适合表达网卡角色之间的细粒度许可。是否需要自定义 NACL，应由边界要求决定。无需求地再复制一套细规则，会增加方向、地址族及端口范围不同步的机会。采用自定义规则时，就必须同时承担回程分析、编号审查和变更验收。

4 回程与临时端口：为何「只开放 5432」仍可能超时

继续看应用 10.20.2.15 访问数据库 10.20.3.21。客户端选择源端口 49160，请求为 TCP 10.20.2.15:49160 → 10.20.3.21:5432；服务器响应为 TCP 10.20.3.21:5432 → 10.20.2.15:49160。返回时地址与端口角色互换，响应的目标端口是 49160，不是 5432。

假设数据库子网入站已允许应用子网访问 5432，应用子网出站也已允许访问数据库 5432，请求可以抵达数据库。但数据库子网出站若只允许目标端口 5432，响应会被挡住；即使这里放行，应用子网入站若没有允许响应目标端口 49160，连接仍不能完成。以目标端口为匹配字段的规则，必须使用该方向真正的目标端口。

把跨子网路径展开，就有 4 个检查点：应用子网出站允许到数据库服务端口，数据库子网入站允许到服务端口，数据库子网出站允许到应用临时端口，应用子网入站允许到临时端口。每处还要约束正确的对端地址范围和协议。只有端口数字对了，地址对象写错，仍然不会命中。

49160 只是本次连接的例子。临时端口范围由客户端操作系统配置、运行环境及可能改写端口的中间设备共同决定。不能把样例端口写成唯一回程许可，也不能把某个操作系统常见范围当成所有客户端的保证。经过地址转换后，应以相关边界实际观察到的地址和端口建立规则。

用1个可算的教学模型说明间歇超时。假设某客户端实际可能使用 49152–65535，共 16384 个临时端口，而返回规则只覆盖 49152–57343，共 8192 个。范围覆盖率是 8192 ÷ 16384 = 50%。若新连接选到 52000，返回可通过；选到 61000，返回被拒。覆盖率不是实测成功率，因为操作系统分配、端口复用和连接池都可能不均匀。

交互中缩小返回范围，观察同一服务端口下哪些响应被挡住。生产环境应先确认真实端口范围，再让经过的无状态边界完整覆盖它；开放必要的回程范围时仍约束对端地址。不要把「需要较宽临时端口范围」误译成「所有来源的所有端口都应放行」。

安全组的有状态机制通常已处理这类响应，无需另加应用入站临时端口规则；NACL 的无状态机制则要求显式分析。2种机制并存时，应各按各的语义求值。若新建连接偶发超时、复用已有连接却正常，先检查无状态回程覆盖与实际源端口，再根据证据继续定位。

5 按角色建模：sg-lb / sg-app / sg-db 与引用源

订单系统分成入口负载均衡器、应用和数据库。为它们分别建立 sg-lb、sg-app、sg-db，让规则表达业务关系：入口接收 TCP 443；应用接收来自入口角色的 TCP 8080；数据库接收来自应用角色的 TCP 5432。组名只是便于理解的标签，真正决定权限的是规则及网卡绑定。

入口面对公众时，可以按需求允许互联网访问 443；内部入口则应改为指定来源前缀。应用入站来源引用 sg-lb，数据库入站来源引用 sg-app。这里采用负载均衡器终止客户端连接、再建立后端连接的例子；若产品保留客户端源地址或采用透明转发，后端看到的来源可能不同，规则必须随实际转发模式调整。

角色引用减少了散落 IP 的维护负担。应用从 2 台扩到 6 台，只要新实例网卡正确绑定 sg-app，数据库许可不必逐台追加地址。但这也要求控制绑定范围：给临时测试机挂上 sg-app，可能同时赋予它访问数据库的网络能力。回收实例时，应确认遗留接口、旧组和错误绑定，而不只是删除清单里的实例名称。

出站同样属于模型的一部分。sg-lb 需要到应用 8080，sg-app 需要到数据库 5432，还可能需要到支付服务的 HTTPS 443。数据库若无业务要求，不应因为模板默认允许出站就省略评估。响应与主动发起连接要分开描述：允许数据库响应应用，不代表数据库必须获准主动访问应用的任意服务。

引用是否可用于出站目标、跨 VPC 或跨账号，以及经过代理、防火墙等中间设备后如何判定来源，都有产品限制。引用不生效时，应根据官方支持范围和实际观察地址选取可维护的前缀方案，并写清原因。不能仅因2个网络已经互通，就推断所有安全组引用也自动有效。

这段动画把初始的宽泛允许逐步收紧为角色关系。每1步同时观察业务是否可用、非授权来源是否被拒；最后检查网卡是否还绑定旧的宽松组。以角色建模的结果应当是一张可验证的连接矩阵，而不只是 3 个命名整齐的安全组。

6 规则卫生：审计、漂移与回收

规则卫生从完整性开始。审计对象应是「网卡及其全部绑定组 → 各组规则 → 有效允许集合」，再关联子网 NACL。1 张网卡绑定 3 个安全组，就评估 3 个组的并集；单独导出项目主组，不能证明实例已满足最小允许原则。多网卡资源还要分别核对接口地址、用途与绑定。

给每条允许记录用途、负责人、对应连接矩阵行、变更依据和适用期限。例如「订单应用到 PostgreSQL，负责人订单服务组，关联连接 M3」，比「临时规则」更有利于后续判断。到期不是盲删的理由，而是复核触发点；先确认依赖、调用频率和日志覆盖，再执行回收。

基础设施即代码可以保存预期配置，但控制台紧急修改可能让实际规则偏离代码，这就是漂移。若故障时临时添加了数据库入站允许，恢复后必须决定它是否长期保留：合理变更回写代码，不合理变更按既定时间撤回，并验证撤回结果。只修控制台，后续部署可能覆盖修复；只改代码未应用，实际暴露仍然存在。

删除宽规则前，先计算它覆盖了哪些连接，以及是否还有并列组提供相同许可。假设 sg-old 的全源 8080 被删，另1个遗留组仍有全源全端口允许，表面变更成功，暴露却没有减少。反过来，如果宽规则悄悄承载了监控探针，直接删除也可能引发健康检查失败。应先补齐有依据的精确许可，再移除旧许可并双侧验证。

日志是依赖分析的证据，但要结合采样、保留期和业务周期解读。「过去 1 小时没有记录」不足以证明月末作业不需要该连接。回收计划可以选择覆盖关键周期的观察窗口，记录预期拒绝与误拒绝的告警条件，并保留配置回滚版本。

规则审查最终要回答 3 个问题：为什么存在、现在谁能用、何时可以移除。把这些答案与资源生命周期、代码评审和定期盘点连接起来，才能避免扩容、迁移及应急处理把角色模型逐渐变成全互通。

7 常见坑：0.0.0.0/0 入站、只改1组忽略并列组、IPv6 旁路

0.0.0.0/0:22 表示允许任意 IPv4 来源尝试连接 SSH。它不会替代主机登录认证，但会扩大网络可达范围。运维访问应按已选的管理通道约束来源；确需短期放行，也应记录对象、负责人和回收时间。不要因为数据库没有公网地址，就认为内部所有主机都可以作为可信运维源。

另1个常见失误是只收紧 IPv4。某资源同时具备 IPv4 与 IPv6，IPv4 规则限定到办公前缀，IPv6 却仍允许 ::/0 访问相同端口。如果实际存在 IPv6 路径与监听，访问者就可能从 IPv6 获得更宽许可。地址族必须分别检查，验收也应覆盖实际启用的协议栈，不能把 IPv4 测试通过视作全部完成。

并列组造成的遗漏尤其隐蔽。管理员将 A 组的 8080 来源改成 sg-lb，随后从测试机连接成功，便怀疑安全组系统故障。若网卡上的 B 组仍允许测试机所在网段，结果恰好符合允许并集。修复前应先识别是哪条规则提供许可；继续在 A 组添加更细规则，不会削弱 B 组。

把 NACL 当成安全组，会制造貌似随机的超时。只允许服务端口，却没有覆盖响应临时端口，可能因不同客户端配置、不同源端口或不同子网关联而只影响部分连接。同一应用扩容后才出现故障，也可能是新实例所在子网用了另1份自定义 NACL，并非应用版本一定有问题。

「临时全开」恢复业务，只能说明扩大允许集合改变了结果，不能指出究竟缺了哪条规则。若没有记录变更前配置和实际连接，事后很难安全收回。应保留故障 5 元组，在受控范围验证假设，恢复后补齐精确许可、撤回应急规则，再执行禁止来源测试。

还要防止把超时与拒绝混为一谈。静默丢弃常表现为等待和重试，TCP 复位可能说明到达某个明确拒绝连接的端点，HTTP 403 则表明已经得到应用层响应。这些现象只是定位线索，需结合捕获位置、代理行为和日志判断。网络允许范围扩大后仍有 403，继续扩大端口许可通常不能解决应用授权问题。

8 案例：3层应用的最小允许矩阵

承接 C9 的订单系统：入口位于 10.20.1.0/24，应用位于 10.20.2.0/24，数据库位于 10.20.3.0/24；路由已经验证。假设入口终止 TLS，以独立后端连接访问应用。下表是业务必需连接，不包括另行建模的管理、解析和监控依赖。公网如何接入留给 C11，本课只明确策略边界。

M2 与 M5 可能共享端口，但不能因此合并证据。探针可能来自不同接口、使用不同路径，也可能在应用层请求 /healthz；业务流量成功不保证探针成功。若某产品的探针源另有发布范围，应在矩阵单独记录，不能为了通过健康检查把应用入站扩大为全源。

对 M3 做数值走查：应用 10.20.2.15:49160 连接数据库 10.20.3.21:5432。先核对应用出站与数据库入站的安全组许可，再按第 4 节的 4 个 NACL 检查点求值。响应目标为 49160，必须落在所有相关返回规则的覆盖内。此例的地址和临时端口仅供复核过程使用，正式配置应采用真实资源集合及已确认的范围。

验收必须同时证明「应该通过」与「应该拒绝」。从带 sg-app 的应用接口新建数据库连接，预期通过；从没有该角色的测试接口访问相同数据库端口，预期失败。从入口角色访问应用 8080 应通过，从非授权业务接口访问则应失败。负向用例需先确认其路由可达，否则失败只能证明整条连接没成功，无法单独证明策略拒绝有效。

健康检查测试要记录探针源地址、实际临时源端口、目标端口及应用响应。不能把健康检查配置的 8080 当成探针源端口；它通常是目标服务端口。测试应按实际客户端配置选取多个新连接，覆盖临时端口范围中的不同位置，并检查 IPv6 是否启用。

发布记录保留连接矩阵版本、网卡组绑定快照、NACL 关联与规则版本、测试结果及回滚入口。回滚恢复的是已知配置，并不自动解释故障；恢复后仍要保留失败样本，补上原因分析，防止下1次部署再次引入同样缺口。

9 排查案例：间歇超时、健康检查失败、放行后仍拒绝

订单系统扩容后，数据库连接偶发超时，部分应用被负载均衡器判为不健康。值班人员说「5432 已放行」，但这句话尚不能定位。先选 1 次失败，记录时间、应用接口、源端口、数据库地址与协议；同时选 1 次成功作对照。随后分成安全组有效集合、NACL 双向求值和健康探针实际路径 3 条证据路径。

路径 A 检查来源引用及并列组。旧应用接口绑定 sg-app，新应用接口误绑 sg-app-new，而 sg-db 只允许 sg-app。请求包到达数据库侧，却不符合来源引用。证据是两张网卡的全部绑定组列表和对应入站规则求值结果。修复角色绑定或经评审更新引用后，用新连接验证，不能靠给数据库加全源 5432 长期掩盖绑定错误。

同1路径还解释「删规则后仍能连接」：若测试接口同时挂了允许数据库访问的遗留组，负向测试仍成功。枚举全部绑定，找到实际提供许可的组；再按它影响的其他接口评估回收。不能为了修复单个实例，直接删除1个仍被其他生产角色使用的共享组。

路径 B 检查 NACL 回程与规则号阴影。假设应用客户端范围为 49152–65535，应用子网入站规则 100 只允许数据库来源到 49152–57343。失败样本使用 61000，成功样本使用 52000，二者恰好落在不同覆盖区域，这就比「网络偶尔不好」更接近可验证解释。继续核对数据库子网出站，避免只修复返回链上的 1 个检查点。

若表中还有 120 拒绝目标端口 60000–62000，而补加的全范围允许排在 200，那么返回到 61000 的包仍先被 120 拒绝。应按升序写出它首个命中的规则号，并修正有误的优先关系。边界产品若不直接记录命中号，可用观测到的包字段和当时规则快照逐条推导，明确标注是推导，不能伪称日志直接给出了编号。

路径 C 检查健康探针。业务后端连接由入口网卡发出，而某种部署的探针却来自独立探针范围；应用安全组只允许入口角色，探针可能无法进入。也可能网络已经通过，但探针请求的路径返回 404，或应用只在 127.0.0.1:8080 监听。应记录真实探针源、端口和应用响应，再决定修改来源规则、监听地址或健康检查配置。

在主机执行 ss -lnt 可以检查 TCP 监听。若输出只有 127.0.0.1:8080，应回到服务绑定配置；若在预期地址监听，再结合主机防火墙和应用日志继续查。工具输出存在监听，并不直接证明外部包已到达；云侧流日志显示允许，也不证明应用已经正确处理请求。

3 条路径共用1份证据清单：网卡全部绑定组、有效规则评估、NACL 关联与首条命中号、探针真实来源、主机监听结果。流日志适合关联接受或拒绝与时间，但未必指出具体安全组规则。间歇超时优先检查无状态回程和偶发源端口；若失败严格跟随某批实例，则比较它们的组绑定与子网关联。

放行后仍拒绝时，应重新识别拒绝发生在哪层。TCP 建连成功而数据库返回认证错误，说明问题已超出网络过滤；HTTP 返回健康检查不接受的状态码，也应查看探针配置和应用。每次只根据证据修正缺口，完成正反向新连接测试后记录结果，让排障结论能被下1位维护者复核。

放进方案里

在 C9 的连接矩阵旁增加策略列，保留源角色、目标角色、协议、目标端口和实际路径，再写入发起端出站组、接收端入站组及引用对象。将 sg-lb、sg-app、sg-db 对应到网卡集合，说明谁维护绑定，扩容和迁移时如何保持角色一致。管理、解析、监控和支付等依赖也应有明确条目，不能依靠默认宽规则隐含承载。

单独声明每个相关子网使用默认还是自定义 NACL，以及选择理由。采用自定义表时，按请求与响应列出方向、对端地址范围、目标端口范围和规则号；临时端口范围注明依据、适用客户端及经过转换后的观察位置。对跨子网连接检查全部边界，并检查较早拒绝是否遮住后续允许。编号和默认行为注明所属产品，避免把教学例子直接当部署模板。

验收计划包含允许来源与禁止来源，分别验证应用、数据库及健康检查。记录探针源地址、临时源端口、目标端口和预期应用响应；对实际启用的 IPv4、IPv6 分别测试。负向来源先确认路径成立，再验证策略拒绝；正向测试使用新连接，并在需要时覆盖临时端口范围的不同位置，避免连接复用掩盖规则问题。

变更流程写清预期配置由哪份代码维护，谁评审，何时发布，以及应急控制台修改如何回写或撤回。规则保留用途、负责人、矩阵关联和到期复核时间。回收前核对依赖与日志覆盖，发布时保存规则版本、网卡绑定和子网关联快照，失败时有明确回滚入口。验收后再评估有效允许并集，确认并列组没有留下宽许可，让方案中的最小允许与实际运行状态持续一致。

10 小结：微隔离收束与公网暴露衔接（C11）

安全组以网卡角色表达允许关系，通常依靠状态跟踪处理响应；网络 ACL 在子网边界逐包判断，通常需要显式覆盖双向流量。最小允许应同时检查角色引用、并列组、无状态回程和地址族，并用允许源与禁止源的新连接验证。

把入口、应用和数据库之间的许可收束后，微隔离才有可审查的边界。C11 将继续讨论公网访问：在已有路由与过滤策略上，判断哪些资源需要对外可达、如何安排入口，以及如何控制公网暴露范围。