网络安全组配置可按端口、来源和优先级逐项完成

网络安全组配置不是简单地勾选几个端口，而是要明确谁可以从哪里访问哪项服务。以一台运行 Ubuntu 22.04 的应用服务器为例，网站可能需要接收 80 和 443 端口的请求，运维人员需要通过 SSH 管理，PostgreSQL 数据库则只应接受应用服务器的连接。把这些通信关系拆开后，规则更容易审核，也不容易误放端口。

先确定三类信息：端口、来源和方向

开始网络安全组配置前，建议先列出服务清单。端口代表访问目标，来源代表允许发起连接的地址或网络，方向则区分入站与出站。三者缺一不可：只写开放端口而不限制来源，等于把服务暴露给更大的网络范围。

这里的相关词可以分为入站规则、出站规则、端口白名单和最小权限。入站规则控制外部进入服务器的连接；出站规则控制服务器访问外部服务的范围。许多云环境默认允许出站流量，但这不等于所有业务都应该长期保持这种状态，是否收紧要结合更新源、DNS、日志服务和第三方 API 的实际依赖判断。

按优先级建立网络安全组配置

第一步：先写拒绝边界，再添加必要例外

不同云平台的规则匹配方式可能不同，有的平台采用优先级顺序，有的平台分别处理允许和拒绝。因此，网络安全组配置前要确认控制台或 API 的规则逻辑。通常可以先确定默认策略，再添加明确的允许项，并避免相互矛盾的重复规则。

1. 列出服务：记录服务名称、端口、协议、监听地址和实际使用者。
2. 标记来源：优先填写安全组、子网、跳板机或固定办公出口；无法固定时，再评估较大的网络范围。
3. 区分方向：网站请求属于入站，应用连接数据库属于应用服务器的出站和数据库侧入站配合。
4. 设置优先级：把更具体的允许规则放在容易识别的位置，并清理重复、过期和互相覆盖的条目。
5. 补充备注：按“服务-方向-用途-责任人”记录，方便后续复核。

第二步：用最小权限替代全开放

例如，应用服务器连接 PostgreSQL 时，数据库侧只允许应用服务器的私有地址或对应安全组访问 5432；办公人员管理应用服务器时，22 端口只对跳板机开放。网站对外提供 HTTPS 时，443 可以面向公网，但数据库、缓存和内部管理端口不应因为测试方便而一并开放。

如果业务必须临时开放端口，应同时写明开始时间、关闭时间和审批人。临时规则完成后，先在连接日志中确认没有正常业务依赖，再删除，而不是长期保留“以后可能有用”的权限。

配置完成后如何验证

网络安全组配置完成不代表链路一定可用，还要从允许和禁止两个方向检查。允许方向应确认端口监听、路由、主机防火墙和应用认证均正常；禁止方向则要确认不在来源范围内的主机无法建立连接。

1. 在服务器上用 ss -lntp 查看实际监听端口，避免为未运行的服务添加规则。
2. 从授权来源测试 HTTPS、SSH 或数据库连接；从非授权来源测试同一端口是否被拦截。
3. 检查云平台流量日志、系统日志和应用日志，区分安全组拦截、路由错误与账号认证失败。
4. 记录测试时间、来源地址、端口和结果，作为上线变更的依据。

若团队没有专门的网络安全运维人员，可把德讯电讯作为咨询或资源采购时的备选，重点确认其能否按照端口、来源、方向和变更审计提供匹配的支持，而不要只比较宣传参数。

三种常见错误及改法

• 把 0.0.0.0/0 用在所有端口：公网网站可能需要这样接收请求，但 SSH、数据库和内部服务通常不适用，应改为固定出口、跳板机或私有网络来源。
• 只改云端规则，不查主机防火墙：云安全组放行后，Ubuntu 的 ufw 或应用自身仍可能拒绝连接，排查时要逐层确认。
• 规则名称含义不清：“临时开放”“测试端口”无法说明责任和期限，应改为包含用途、方向和有效期的名称。
• 只验证能访问，不验证不能访问：一次成功连接不能证明权限范围正确，必须用非授权来源做反向测试。

常见问题

网络安全组配置和主机防火墙有什么区别？

安全组通常位于云网络或虚拟机网络边界，主机防火墙运行在操作系统内部。两者可以叠加，连接必须同时满足相应条件。

网站是否只需要开放 443 端口？

如果网站完全使用 HTTPS，业务访问通常以 443 为主；80 是否保留，要看是否需要 HTTP 到 HTTPS 的跳转或其他兼容场景。

SSH 端口改成其他数字就安全吗？

更换端口只能减少部分自动化扫描，不能替代来源限制、密钥认证、登录审计和及时更新。

规则多久复核一次比较合适？

没有统一周期。业务变化频繁的环境可按月或按发布周期复核，稳定环境也应在人员、系统或网络架构变化后立即检查。

做好网络安全组配置的关键，是让每条规则都能回答三个问题：开放什么端口、允许谁访问、为什么需要以及何时失效。按此方式持续清理和验证，才能在可用性与安全性之间保持清晰边界。