华为云安全组：90% 的人都在犯的 5 个错误

前言

安全组是华为云上最基础的安全防线，每个用云的人都配过。但"配过"不等于"配对了"。

我在团队里做过一次内部审计，抽查了 30 多套环境的 ECS 安全组规则，结果发现：超过 90% 的安全组配置都存在至少一个安全隐患。不是什么高深的问题，都是基础概念没搞清楚导致的。

这篇文章把我见过的最高频的 5 个错误列出来，每个都讲清楚"为什么错"和"怎么改"。不念经，直接说场景。

先搞清楚一个概念：安全组不是防火墙

很多人把安全组当防火墙用，这是一个根本性的误解。

防火墙是串在链路上的——流量必须经过它，它决定放行还是丢弃。你拔掉防火墙，流量就不通了。

安全组是挂在网卡上的——它更像一张白名单，贴在 ECS 的网卡上。流量到了网卡，安全组检查一眼，不在白名单里的直接丢弃。你删掉安全组，流量反而全通了（默认全放行）。

这个区别很重要，因为它决定了安全组的两个特性：

1. 安全组是"默认拒绝"的——你没写的规则，默认不放行。但注意，华为云新建安全组时会自带几条默认规则（出向全放行），很多人没注意到。
2. 安全组只管"进"和"出"，不管"转发"——它不是路由器，不做 NAT，不改变流量方向。它只回答一个问题：这个包能不能进出这张网卡。

理解了这一点，下面 5 个错误就很好懂了。

错误一：0.0.0.0 全放行，还开所有端口

这是最经典、最危险、也是最常见的错误。

典型场景： ECS 装了个 MySQL，为了方便远程连接，安全组入向规则加了一条——来源 0.0.0.0（全部地址），端口 3306，放行。

为什么危险： 你的数据库直接暴露在公网上，任何人只要知道你的公网 IP 就能尝试连接。MySQL 默认 root 密码强度有限，暴力破解工具扫一圈，几分钟就进来了。这不是假设，是每天都在发生的事——全网有数百万个暴露在公网上的 MySQL 实例，其中大量是云服务器。

正确做法：

第三种是生产环境的标准做法。数据库只对应用层开放，运维通过堡垒机访问，公网上看不到数据库的任何端口。

一句话记住：数据库的安全组入向规则里，不应该出现 0.0.0.0。出现一次就是一次事故隐患。

错误二：一个安全组管所有资源

典型场景： 创建了一个安全组，规则加了 22（SSH）、80（HTTP）、443（HTTPS）、3306（MySQL），然后把这个安全组挂给了 Web 服务器、数据库、缓存……所有 ECS 都用同一个。

为什么有问题： 这相当于给每台服务器都开了所有端口。Web 服务器开了 3306，数据库开了 80——每个角色都暴露了不该暴露的端口。攻击面成倍增加。

正确做法：按角色拆分安全组。

一个典型的三层 Web 架构至少需要三个安全组：

ELB 安全组：入向只开 80 和 443（对公网）
ECS 安全组：入向只开 80（只允许 ELB 安全组的流量）
RDS 安全组：入向只开 3306（只允许 ECS 安全组的流量）

注意第三条——RDS 安全组的入向规则里，来源不是 IP 段，而是引用 ECS 的安全组 ID。这是华为云安全组的一个关键能力：安全组可以引用另一个安全组作为来源。这样即使 ECS 的 IP 变了，规则也自动生效，不用手动改。

分层的好处： 每一层只暴露它需要的最小端口，攻击面降到最低。就算某一台 ECS 被攻破，攻击者也访问不到数据库——因为数据库安全组只信任 ECS 安全组的流量，被攻破的 ECS 如果不在那个安全组里，流量照样被拒绝。

错误三：出向规则全放行，不管去哪

典型场景： 安全组的出向规则是默认的——目的地 0.0.0.0，所有端口，放行。大多数人从来没改过出向规则。

为什么有问题： 如果这台 ECS 被植入了恶意程序（比如挖矿木马、反弹 shell），它可以自由向外连接任何地址——C2 服务器、矿池、数据外泄的目标地址。出向全放行等于给攻击者留了一条后路。

正确做法： 按实际需求收紧出向。

收紧出向规则会增加一些运维成本——比如应用需要调一个新的外部 API，你得先加出向规则。但这个成本远低于被攻击后的损失。

实际建议： 至少给数据库服务器收紧出向。数据库不应该有任何公网出向需求，如果它需要公网出向，说明架构有问题。

错误四：安全组规则没有优先级概念，以为越细越好

典型场景： 安全组里加了 50 条规则，入向 30 条，出向 20 条。每次有新需求就加一条，从不删。最后没人能说清楚每条规则是为什么加的，哪些还有用。

为什么有问题： 规则越多，维护成本越高，出错概率越大。而且华为云安全组规则是有优先级的——数字越小优先级越高。如果你不关注优先级，规则之间的覆盖关系可能和你预期的不一样。

正确做法：

1. 定期清理： 每季度审计一次安全组规则。每条规则应该能回答"谁在用、为什么开、什么时候可以关"。回答不了的，关掉观察一周没问题就删除。

2. 善用端口范围： 不要一条规则开一个端口，连续端口用范围。比如被动模式 FTP 用 20000-21000，一条规则搞定，不用开 1000 条。

3. 理解优先级： 华为云安全组规则按优先级数字从小到大匹配，命中一条就停止（对于相同五元组的规则）。如果你加了一条"拒绝所有"优先级 100，又加了一条"允许 80"优先级 200，那 80 端口的流量会被先匹配到的"拒绝所有"挡掉。先写拒绝规则，再写允许规则，顺序别搞反。

4. 命名和备注： 每条规则加描述，写清楚"2024-03 为某项目临时开放，负责人张三"。这不是多此一举，下次审计时你会感谢自己。

错误五：改了安全组不测，出了问题不知道是哪条规则

典型场景： 安全组加了一条规则，应用就连不上了。或者删了一条规则，某个服务默默挂了半小时才有人发现。

为什么有问题： 安全组规则变更的影响面有时候不直观。你删了一条"允许 80"的入向规则，影响的可能不只是 Web 服务，还有负载均衡器的健康检查——健康检查走的就是后端端口，规则删了，健康检查失败，ELB 把所有后端摘掉，整个服务就挂了。

正确做法：

1. 改之前先在测试环境验证。 安全组规则是配置变更，和改代码一样，应该先在测试环境跑通再上生产。

2. 改的时候分批。 如果要删一条不确定的规则，先把优先级调到最低（或者把动作改成拒绝），观察一段时间没问题再物理删除。

3. 改完立刻验证关键路径。 不要改完就去干别的，花 5 分钟把核心业务流程跑一遍：Web 能不能访问、数据库能不能连、健康检查是不是正常。

4. 用日志审计追踪变更。 华为云的 CTS（云审计服务）会记录安全组规则的所有变更操作。出了事可以回溯到"谁在什么时间改了什么"。团队协作环境下，这个比事后猜来猜去高效得多。

一张表总结

写在最后

安全组配置不复杂，5 条规则就能管好一套标准 Web 架构。但正因为简单，反而容易被忽视——觉得"能通就行"，不去想"通得对不对"。

我建议你现在就花 10 分钟，打开华为云控制台，检查一下你生产环境的安全组：

1. 有没有 0.0.0.0 开 3306 的规则？
2. 数据库和 Web 服务器是不是用了同一个安全组？
3. 出向规则是不是全放行？

如果中了任何一条，看完这篇文章就该改了。安全这事，早改早安心。

有疑问或不同意见，欢迎评论区交流。