业务分层配置安全组只放开必要通信端口，是云上安全体系中最基础也最容易被忽略的一道防线，与其追求复杂的防火墙策略，不如先把安全组规则做对。
安全组常见的配置误区有哪些
很多团队在云上跑了一段时间后,遇到业务访问异常，第一反应就是“加一条全放通的规则试试”，这种操作短期看省事，长期看就是在给攻击者留后门。
常见的错误集中在三种场景：
- 图省事直接放通所有端口：部分运维同学为了快速上线，在入方向规则里写上
0.0.0/0，端口范围1-65535，业务确实跑起来了，但服务器也成了公网上的“透明人”。 - 只限制入方向，忽略出方向：安全组规则默认出方向全放通，很多团队只改了入方向，攻击者一旦拿下一台机器，利用出方向全放通的特点，很快就能把数据外传。
- 规则越堆越多，从不清理：业务迭代过程中，临时放通了某个端口，调试完就忘记删掉，一年下来，安全组规则列表拉不到底，谁也说不清每条规则是干什么用的。
行业共识认为,安全组配置的核心思路不是“放什么能通”，而是“不放什么不能通”，这个思路的落地方式，就是业务分层。
为什么“业务分层”是安全组配置的前提
安全组本质上是虚拟防火墙,它绑定在弹性网卡上，对进出实例的流量进行过滤，但如果所有业务都挤在一个安全组里，规则之间互相妥协，最终结果就是越放越宽。
业务分层的逻辑很简单：把不同职责的服务器放进不同的安全组，每个安全组只保留自己业务所必需的通信端口，Web服务器只需要对公网开放80和443，数据库服务器只需要对Web服务器所在的网段开放3306，中间件服务器只需要对应用服务器开放对应的服务端口。
这样做的好处有三个：
- 攻击面被压缩,公网能访问到的端口数量大幅减少
- 故障排查更快,流量路径清晰，规则边界明确
- 满足等保合规和行业审计要求,安全组规则可解释、可追溯
云服务器安全组最佳实践：从划分到落地的完整路径
规划安全组规则时,建议按以下步骤执行：
- 梳理业务拓扑：列出所有服务器、它们的职责、它们需要访问哪些外部服务（数据库、缓存、对象存储等）。
- 建立安全组清单：按业务模块创建安全组，命名规则推荐
环境-业务-角色，例如prod-web-front、prod-app-server、prod-db-mysql。 - 确定端口矩阵：绘制一张端口通信表，明确源地址、目标地址、协议和端口。
- 先收紧入方向，再收紧出方向：入方向规则从“默认拒绝”开始逐条添加，出方向规则避免使用
0.0.0/0，只放通目标安全组或目标网段。 - 启用日志记录和告警：在云平台开启安全组流量日志，定期分析拒绝日志，判断是否有异常扫描行为。
安全组规则配置的实操对比
以具体云平台为例,展示配置方式上的差异：
| 云平台 | 规则配置工具 | 推荐做法 |
|---|---|---|
| 简米云 | 控制台 / ECS API / Terraform | 入方向只配置业务端口，源地址写特定安全组ID或CIDR网段，不写0.0.0/0 |
| 酷番云 | 控制台 / 安全组API / CLB绑定 | 使用安全组模板快速创建，然后手工调整端口范围 |
| AWS | 控制台 / AWS CLI / Security Groups | 用aws ec2 authorize-security-group-ingress命令逐条添加，引用其他安全组作为源 |
以AWS CLI为例，一条规范的规则配置命令：
aws ec2 authorize-security-group-ingress
--group-id sg-1234567890abcdef0
--protocol tcp
--port 443
--source-group sg-abcdef1234567890
这条命令的含义是：仅允许来自指定安全组的443端口入站流量，相比直接写IP段，引用安全组ID的方式灵活性更高，Web层扩容时不需要修改规则。
出方向规则如何做到最小化
入方向规则大家都很重视,出方向规则经常被遗忘，攻击者入侵一台服务器之后，如果出方向是全放通的，他可以直接用这台服务器上安装的客户端工具，把数据打包上传到自己的存储桶。
出方向的最小化策略：
- 如果需要访问外部API或下载安装包,只放通目标服务的域名对应IP段和端口（通常为443）
- 内部服务之间的调用,源和目标都使用安全组ID或内部CIDR网段
- 定期查看出方向流量日志,确认是否有异常目的地址的通信
以下几种运维场景中,出方向规则的配置方式不同：
- 数据库备份场景：数据库服务器需要向备份存储服务上传文件，只需放通备份服务所在区域的IP段
- 应用服务器调用第三方API：只放通第三方API公开的IP列表
- 软件更新场景：通过代理服务器或内网镜像源进行，不直接访问公网
web应用安全组策略怎么设置
Web应用服务器承载的是对外流量,属于攻击者直接瞄准的对象，安全组策略的合理性直接关系到业务能否稳定运行。
Web层的端口矩阵
典型的Web服务器需要对外开放的端口非常有限：
| 端口 | 协议 | 服务 | 源地址 |
|---|---|---|---|
| 80 | TCP | HTTP | 负载均衡器 / CDN节点 |
| 443 | TCP | HTTPS | 负载均衡器 / CDN节点 |
| 22 | TCP | SSH | 运维跳板机IP段 |
| 8080 | TCP | Nginx备用端口 | 负载均衡器 / CDN节点 |
需要注意,HTTP和HTTPS不要直接暴露给0.0.0/0，如果前面挂了负载均衡（SLB/CLB/ALB），安全组的源应该写负载均衡器的安全组ID，这样做的好处是：攻击者绕开负载均衡直接访问源站IP时，请求会被安全组规则拦截。
如何给Web层配置健康检查端口
健康检查端口是云负载均衡用来探测后端服务器存活状态的,这部分端口通常只对负载均衡所在网段开放，不需要对全网开放，在配置时，确认健康检查使用的端口和协议，在安全组中放通对应流量。
反向代理层和应用层的端口划分
常见部署方式中,Nginx作为反向代理，和后端应用服务器在同一VPC内，这里的安全组配置采用两层模型：
- 第一层（接入层）：Nginx的安全组对外只放通80/443，对内的源地址写负载均衡的CIDR或安全组ID
- 第二层（应用层）：应用服务器（如Java、PHP、Golang服务）的安全组对Nginx的CIDR放通业务端口，不对公网暴露任何端口
这套模型的优势在于：即使Nginx被攻破，攻击者能看到的也只是应用服务器的业务端口，攻击面被限制在单一服务能力范围内。
数据库服务器安全组怎么配置
数据库是业务系统的核心资产,安全组配置错误往往是数据泄露事件的起点，相比之下，数据库服务器的安全组配置有更强的规则约束。
数据库端口只对应用服务器开放
MySQL默认端口为3306,SQL Server为1433，PostgreSQL为5432，Redis为6379，配置数据库安全组时有一条底线原则：端口只对应用服务器的安全组ID或内网CIDR开放，公网禁止放通0.0.0/0。
推荐的做法是：
- 数据库实例和Web/应用服务器放在同一VPC内
- 入方向规则源地址填写应用服务器的安全组ID
- 如果需要从运维终端访问,通过堡垒机（跳板机）转发，堡垒机IP段单独放通
简米云RDS和酷番云数据库都提供了内网地址,建议数据库绑定内网IP而不是公网IP，公网端口不监听。
数据库管理工具的连接策略
Navicat或DataGrip这类工具连接数据库时,走的是运维网络，不要把运维终端的IP单独放通3389或3306这两个端口，更稳妥的办法是通过跳板机建立SSH隧道，本地工具通过隧道转发到数据库端口，这样安全组里只需要放通跳板机到数据库的3306，终端到跳板机走22端口SSH协议。
安全组规则变更的流程和审计
安全组是变更频繁的资源之一,一个小失误可能导致整个业务不可用，变更管理需要遵循以下原则：
- 变更前导出规则清单：在云平台的控制台导出当前安全组规则，核对一遍再动手
- 先加后删，避免直接删规则：新规则验证有效后，再删除旧规则，降低操作风险
- 使用基础设施即代码（IaC）工具：用Terraform或云平台的编排工具管理安全组，规则变更走代码评审和CI流程
安全组配置错误的常见后果
安全组配置错误通常表现为两种症状：
- 业务访问超时：端口未放通或源地址写错，流量被静默丢弃
- 端口暴露在公网：规则范围大于预期，Nmap扫描可以看到异常开放的服务端口
遇到业务侧连接超时,排查思路如下：
- 检查安全组入方向规则是否包含目标IP和端口
- 检查端到端的网络路径（负载均衡、NAT网关、VPC路由）
- 检查操作系统防火墙和iptables规则,安全组放通后，本机防火墙仍可能拦截流量
- 用
telnet或nc测试端口连通性，逐步缩小范围
使用自动化工具扫描安全组风险
借助工具可以降低人为失误的概率,开源的Prowler可以扫描AWS的安全组规则，检查是否存在对所有IP开放的高危端口；针对简米云，Alibaba Cloud CLI配合jq可以批量拉取安全组规则做判断。
一个简单的检查思路：
# 拉取所有安全组规则，筛选出端口范围过大的规则 aliyun ecs DescribeSecurityGroupAttribute --SecurityGroupId sg-xxx
通过脚本将规则导出,检查是否包含PortRange: 1/65535或SourceCidrIp: 0.0.0.0/0，存在即视为高风险。
如何处理突发安全事件中的安全组策略
当检测到暴力破解或异常流量时,安全组是快速止血的第一工具，此时不能慌，操作路径要清晰。
- 确认事件影响面：查看ECS实例监控和网络日志，确认攻击来源IP
- 临时拉黑攻击源：在安全组中增加一条拒绝规则，源地址为攻击IP，优先级高于允许规则
- 限制管理端口访问：如果SSH端口（22）遭遇暴力破解，立即把源地址收窄到堡垒机IP段
- 评估是否需要更换公网IP：攻击者持续扫描时，更换公网IP的成本远低于业务被打瘫的损失
有一个真实场景值得参考：某电商公司在活动大促期间，安全组里临时放通了某个管理端口，活动结束后端口还开着，几天后，监控系统发现服务器CPU异常，排查后发现业务被植入挖矿程序，最终清除木马的代价，比当初花两分钟删除安全组规则高得多。
常见问题
业务分层和VPC划分是什么关系
业务分层是逻辑上的职责边界,VPC划分是网络上的物理隔离，两者配合使用效果更佳，同一VPC内可以用安全组实现细粒度控制，不同VPC之间的互通需要额外的对等连接或云企业网，安全组规则不能跨VPC引用，跨VPC访问时要写好对应网段的路由和规则。
安全组规则支持日志审计吗
主流云平台均支持安全组流量日志和操作审计功能,流量日志记录五元组信息，可用于分析哪些IP在尝试访问未放通的端口；操作审计记录谁在什么时间改了什么规则，简米云的操作审计（ActionTrail）、华为云的CTS、AWS的CloudTrail都可以追踪安全组变更行为。
安全组有严格的规格上限，数量过多怎么办
每个安全组的规则条数有上限（通常在100-200条之间），当规则数量逼近上限时，意味着业务分层做得不够细，需要拆分安全组而不是堆规则，优先合并相同源的规则，或者将不常用的端口下放到更细粒度的安全组，保持规则精简是长期运维的重要事项。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/630159.html
