云服务器安全组怎么设置？端口开放规则与最小权限原则

安全组是云服务器最容易理解、也最容易配错的一层。它就在控制台里，点几下就能加规则，正因为太方便，很多机器的安全组长这样：入方向一条 0.0.0.0/0 全端口全放行，"先跑起来再说"。这条规则配上的那一刻，主机上所有服务的防护就全部依赖各自的认证强度了，包括那些本来只打算内网访问、压根没设密码的服务。

这篇文章讲清楚安全组的工作特性（尤其是有状态这个关键点）、入站与出站的方向差异、优先级规则，给出一套典型的最小权限规则集，以及常见错误和用 IaC 管理的方法。

安全组是什么：有状态防火墙

安全组是云平台提供的虚拟防火墙，作用在实例的虚拟网卡层面。它和系统内部运行的 firewalld、ufw、nftables 是两层独立的机制，各自生效，流量要同时通过两者才能到达服务。

理解安全组最关键的一点是：它是有状态（stateful）的。这意味着它跟踪连接状态，只需要配置一个方向的规则。

具体来说：如果你在入方向放行了 80 端口，那么外部访问 80 的响应流量会自动被允许出去，不需要在出方向再配一条允许规则。反之，如果本机主动访问外网的 443，返回流量也会被自动放行，同样不需要额外的入方向规则。

这一点经常引起误解。有人配完入站放行 80 之后发现访问正常，就以为"出站也要配"；也有人把出站全部拒绝，结果本机主动发起的请求全部失败。记住这张表：

出站默认是放行的，这是大多数云平台的默认配置。出站全放行意味着：如果机器被入侵，木马可以顺畅地连接控制端、外发数据、横向扩散。所以安全要求高的场景应该按最小权限配置出站，只放行必要的目标（比如 yum/apt 源、NTP、日志服务器、监控上报地址）。

入站默认是拒绝的，这是安全的一侧。任何没有明确放行的入站流量都会被丢弃，且不产生日志（部分平台支持流日志，需要单独开启）。

规则的方向、优先级与匹配逻辑

方向（direction）只有两个：入站（ingress / inbound）和出站（egress / outbound）。

优先级（priority）在不同云平台上表示方式不同：有的是数字越小优先级越高，有的是按规则顺序从上到下匹配。共同点是：一旦匹配到规则就执行动作并停止匹配后面的规则。所以拒绝规则要放在放行规则之前才有效，反之则会被放行规则先吃掉。

这带来一个常见错误：配置了"拒绝某个 IP"，但它在"放行全部"规则之后，结果完全没有效果。检查规则顺序应该是排查访问控制失效的第一步。

协议与端口方面，常见写法有：

协议类型要选对。放行 DNS 要同时考虑 TCP 和 UDP 的 53，放行 NTP 是 UDP 123。只配 TCP 会导致 UDP 服务不通，这是排障时的常见疏漏。

来源与目标的写法有三种，用途不同：

• CIDR：203.0.113.10/32 表示单个 IP，198.51.100.0/24 表示网段。用于指定办公网出口、CDN 回源段、合作伙伴的固定 IP。
• 安全组 ID：把对端安全组作为授权对象。这是云上最推荐的做法，下面会展开。
• 前缀列表 / IP 组：把一组 CIDR 抽象成可复用的对象，规则多了之后便于维护。

最小权限原则与典型规则集

最小权限的意思是：只开放业务必须的端口，只对这些端口授权必须的来源。它的价值不只是防攻击，还包括缩小审计范围和降低误配置的影响面。

一套典型的 Web 服务器规则集长这样：

关键点逐条说明：

22 与 3389 只对办公网出口 IP 放行。 这是收益最大的一条规则。管理端口对公网开放意味着全世界都能尝试登录，改成只对几个固定 IP 放行之后，日志里的爆破记录会直接归零。家庭宽带等动态 IP 场景不适合这种方式，可以退而求其次：用 VPN 或堡垒机作为唯一入口，后端机器只对堡垒机 IP 放行。

80 与 443 对 0.0.0.0/0 放行是合法的，因为这就是对外服务的本质。但如果前面挂了 CDN 或 WAF，就应该改成只对 CDN 的回源 IP 段放行，避免源站暴露后被绕过。

数据库端口用安全组 ID 互信，而不是写 IP。 这是云上非常重要的一条实践：

Web 服务器安全组：sg-web
数据库安全组：    sg-db

sg-db 入站规则：
  TCP 3306  授权对象 = sg-web

这样配置的效果是：属于 sg-web 的所有实例都能访问 sg-db 里的实例，而不需要知道它们的 IP。好处有三：内网 IP 变化时规则自动跟随，不需要改配置；扩容新实例自动获得权限，不需要逐条加规则；IP 复用（比如另一个租户拿到同一个内网 IP）不会导致越权访问，因为授权依据是安全组成员身份而不是 IP 地址。

用 IP 授权的隐患就在这里：云环境里内网 IP 会被回收复用，如果你按 IP 授权，一个不属于你的实例拿到那个 IP 后就自动获得了访问权限。安全组 ID 授权不存在这个问题。

出站规则按需收紧。 生产环境建议至少做到：禁止出方向访问常见的高危端口（如 25 邮件端口，防止被用作垃圾邮件中继），或者只允许访问必要的外部服务。收紧出站能显著提升入侵后的遏制能力，但要充分测试，避免影响 yum/apt 更新、NTP 同步、监控上报、License 校验。

与安全组配合的双层防御

安全组和系统防火墙是两层，两者都要配置，不能互相替代：

为什么要两层？

安全组防不了内网。 同一 VPC 内的机器之间，如果安全组放行了内网段，那么横向移动的阻力很小。主机防火墙是内网横向的第二道防线。

系统防火墙有单点风险。 主机上的规则可能被误操作清空、被攻击者修改、或者因为服务未启动而失效。安全组在云平台侧，不依赖主机状态，即使主机被攻破也无法从内部修改（前提是云账号凭证没有泄露）。

安全组提供批量与标准化能力。 几十台机器共用一组安全组规则，改一处全部生效，比逐台维护主机防火墙可靠得多。

分层建议：安全组做粗粒度的边界（谁可以访问这台机器的哪些端口），主机防火墙做细粒度控制（具体的来源、协议细节、速率限制）。两者都按最小权限配置，不要因为有了其中一层就放松另一层。

常见错误

错误一：为图省事全放行。 一条 0.0.0.0/0 加全部端口，等于没有安全组。更糟糕的是临时测试时加的，事后忘了删。正确做法是：需要临时访问时加一条精确规则并标注用途和时间，测试完立刻删除。

错误二：忽略 IPv6。 配置完 IPv4 规则就以为完事了，但实例如果分配了 IPv6 地址，安全组里还需要单独配置 IPv6 规则。写 ::/0 等同于 0.0.0.0/0，是全放行。很多"我明明配了限制怎么还能访问"的排查，最后发现是 IPv6 侧没有限制。不需要 IPv6 的业务，可以不分配 IPv6 地址，或者在安全组里显式拒绝 ::/0。

错误三：改规则把自己锁在外面。 修改了 22 端口的来源限制，结果自己的出口 IP 不在范围内。防范措施：修改前先确认当前公网出口 IP；保留一条备用规则（比如放行 VPN 出口网段）；确认云控制台的 VNC 或串口终端可用；不要一次性删除所有管理端口规则。已经锁死的话，用 VNC 登录改回，或者联系厂商支持。

错误四：规则写了但顺序不对。 拒绝规则排在放行全部之后，等于没配。检查时要完整看一遍规则列表和优先级，而不是只看有没有那一条。

错误五：把应用监听地址配错怪到安全组头上。 服务监听在 127.0.0.1 时，无论安全组怎么配外部都访问不到。排查顺序应该是：安全组 → 系统防火墙 → 服务监听地址 → 服务本身状态。

# 确认服务监听地址，0.0.0.0 才是对外可见
sudo ss -lntp
sudo ss -lntp | grep -E ':80|:443|:3306'

错误六：安全组规则长期不清理。 项目下线、人员离职、合作方变更之后，对应的规则还留在列表里。建议每季度审计一次，每条规则都要能说出用途和责任人，说不清的就删掉（先改为拒绝观察一段时间再删）。

多网卡与内网互通

一台实例有多张网卡时，安全组的绑定关系要注意：多数平台是按网卡绑定安全组的，每张网卡可以有独立的安全组。这意味着入站流量的过滤依据是流量从哪张网卡进来。

常见配置方式：

• 公网网卡（或有 EIP 的网卡）：严格限制入站，只放行必要端口和来源。
• 内网网卡：放行内网段或按安全组 ID 互信，用于数据库、缓存、内部服务通信。
• 管理网卡：只对运维来源开放管理端口。

内网互通的配置要点是：用安全组 ID 互信，而不是写网段 CIDR。写网段的话，同网段内任何一台机器（包括被入侵的机器）都能访问；按安全组授权则精确到"哪些角色的机器可以访问"，横向移动的范围小得多。

多网卡场景下还要注意：安全组规则里指定的端口是目的端口，与流量从哪张网卡进来有关。测试时要用内网地址而不是公网地址测试内网规则，否则测的是另一张网卡的规则。

审计与 IaC 管理

开启流日志。 主流云平台提供 VPC 流日志或等价能力，能记录被接受和被拒绝的流量。它的价值在于：排查"为什么访问不通"（看是被拒绝还是没到达）、发现异常访问模式（比如某台机器一直在扫内网端口）、以及事后溯源。流日志数据量较大，可以采样存储并送到日志服务做分析。

记录规则变更。 云平台的操作审计服务会记录安全组的每一次修改，包括操作人和时间。这是审计和追责的依据，也是排查"谁改了规则"的唯一途径。

定期清理。 建立规则审计清单，每条规则记录：用途、申请人、创建时间、有效期。过期规则自动提醒或自动失效。这对长期运行的系统非常重要，规则表往往是安全债务最集中的地方。

用 IaC 管理。 当机器数量超过十台，手工点控制台就会失控：配置漂移、无法回退、环境不一致。用 Terraform、Ansible 或云平台提供的编排工具管理安全组，好处是配置可版本化、可评审、可复用、可回滚。

Terraform 风格的示意（不同平台资源名不同）：

resource "security_group" "web" {
  name = "sg-web-prod"

  ingress {
    protocol  = "tcp"
    port      = "443"
    cidr      = "0.0.0.0/0"
    desc      = "对外 HTTPS"
  }

  ingress {
    protocol     = "tcp"
    port         = "22"
    cidr         = "203.0.113.10/32"
    desc         = "办公网运维入口"
  }

  egress {
    protocol = "all"
    cidr     = "0.0.0.0/0"
    desc     = "默认出站"
  }
}

IaC 管理的关键实践：配置入库、变更走代码评审、禁止控制台手工修改（或建立定期巡检发现漂移）、以及为不同环境（生产、预发、测试）使用不同的变量文件而不是复制配置。

常见问题

安全组放行了这个端口，为什么还是访问不通？

按四层排查：安全组是否放行且规则顺序正确、系统防火墙是否放行、服务是否监听在 0.0.0.0 而不是 127.0.0.1、服务进程是否正常。用 ss -lntp 确认监听，用 nc -vz -w 3 目标IP 端口 从外部测试。另外不要忘了 IPv6 侧也要检查。

为什么配了入方向放行，还要配出方向？

因为有状态特性，入方向放行后响应流量会自动放行，通常不需要额外配出站。但如果你把出站改成了默认拒绝，那就需要显式放行。反过来说，本机主动访问外部服务（yum、NTP、日志上报）则一定需要出站规则。

数据库端口用 IP 授权和用安全组授权有什么区别？

安全组 ID 授权是按成员身份而不是地址，内网 IP 变化和扩容都会自动跟随，且不会因为 IP 复用导致越权。IP 授权在 IP 被回收复用后可能把权限给了不相干的实例。云上内部互信优先用安全组 ID。

怎么避免改规则把自己锁在门外？

改之前确认自己的公网出口 IP；保留一条备用放行规则（VPN 或堡垒机网段）；确认控制台 VNC 可用；不要一次删除所有管理端口规则。改完立刻开新连接验证，不关当前会话。

安全组和系统防火墙都要配，是不是重复了？

不重复。安全组是实例外的边界防护，不依赖主机状态，批量管理方便；系统防火墙是主机内的细粒度控制，能防内网横向。两者是纵深防御的两层，都应该按最小权限配置。

临时开的规则忘了删怎么办？

建立规则审计机制：每条规则写明用途和有效期，用 IaC 管理并纳入评审，定期（建议每季度）审计一次。也可以用流日志找出长期零流量的规则，这些是优先清理对象。

总结

• 安全组是有状态防火墙：入方向放行后响应流量自动放行，通常不需要配对称的出站规则；但本机主动外连必须有出站规则，出站收紧能显著提升入侵后的遏制能力。
• 规则一旦匹配即执行并停止，拒绝规则必须排在放行规则之前才有效；协议要选对（DNS 需 TCP 加 UDP 53，NTP 是 UDP 123）。
• 典型最小权限规则集是：22/3389 仅对办公网或堡垒机 IP 放行，80/443 对公网或 CDN 回源段放行，数据库端口用安全组 ID 互信而非 IP 授权（避免 IP 复用导致越权，且扩容自动跟随）。
• 常见错误包括全放行图省事、忽略 IPv6 的 ::/0、改规则把自己锁外面、规则顺序错误、以及长期不清理；改规则前要确认自身出口 IP、保留备用通道和 VNC。
• 安全组与系统防火墙是纵深防御的两层，前者是粗粒度边界且不依赖主机状态，后者防内网横向；长期管理应开启流日志、记录变更审计、定期清理，并用 IaC 做版本化和评审。