安全组是云服务器的分布式有状态虚拟防火墙，必须遵循“默认拒绝、显式放行、源可溯、变可审”四原则；未配置规则时默认拒绝所有流量，规则自上而下匹配，入站允许后对应出站响应自动放行，一个实例可绑定多个安全组，授权对象推荐使用IP段或安全组ID。
安全组不是端口开关，而是云环境里的最小权限执行单元。它必须体现“默认拒绝、显式放行、源可溯、变可审”四个刚性特征，否则在等保三级测评中直接判不合规。
安全组的本质与核心规则逻辑
安全组是分布式的有状态虚拟防火墙，作用于实例级别。它的底层逻辑非常清晰：
- 未配置任何规则时，默认拒绝所有入站和出站流量
- 规则按列表从上到下匹配，一旦命中即执行，不再继续匹配后续规则
- 允许入站后，对应会话的出站流量自动放行（有状态），但新连接仍需独立规则
- 一个实例可绑定多个安全组，规则合并生效，高优先级组先匹配
- 授权对象支持三种类型：IP段（如10.10.1.0/24）、IPv6地址、其他安全组ID（推荐用于内网互通）
生产环境必须落地的四条硬性要求
等保2.0三级系统中，以下四点不能靠“口头承诺”或“上层防火墙兜底”，必须在安全组层面显性配置：
IT技术解决互联网公司网站模板
下载
IT技术解决互联网公司网站模板是一款适合提供APP设计、网页开发、SEO优化、云服务、数据分析等服务的互联网公司宣传网站模板下载。提示：本模板调用到谷歌字体库，可能会出现页面打开比较缓慢。
- SSH/RDP仅限跳板机访问：22或3389端口禁止对0.0.0.0/0开放；只允许堡垒机所在子网（如10.10.100.0/24），且建议额外限定源端口（如2222）提升识别精度
- 数据库端口严禁公网暴露：3306、1433、6379等一律禁止填0.0.0.0/0；只允许指向具体应用服务器安全组ID（如sg-prod-app-api），而非测试组或泛用组
- 高危端口默认关闭：Elasticsearch（9200）、MongoDB（27017）、ZooKeeper（2181）等非业务必需端口，在全部安全组中不得出现allow规则；确需启用须走变更审批并登记台账
- 每条规则必须带可读描述：不能写“临时开放”“测试用”，而应注明用途、责任人、有效期（如“支付回调接口-订单服务调用-张三-20261231”）
从新建到关联的实操闭环
配置不是一次性动作，而是一套可验证、可回滚、可归责的操作流：
- 创建安全组时，名称需含环境+角色+用途（如“sg-prod-web-lb”“sg-dev-db-mysql”），避免使用“default”“test”等模糊命名
- 添加规则优先选“手动添加”，禁用“一键放通全部端口”模板；协议类型明确到TCP/UDP/ICMP，端口范围写成“80/80”而非“80”
- 授权对象尽量用CIDR或安全组ID，避免填单IP（易失效）；如必须用IP，应配合IP地址组管理（如“运维办公IP池”）
- 规则生效后，立即用
telnet ip port或nmap -Pn -p port ip验证连通性；同时检查VPC流日志是否捕获到该会话 - 将实例绑定安全组后，登录服务器执行
ss -tln确认监听状态，并核对iptables -L -n（部分平台透出）是否与安全组策略一致
常见踩坑与替代方案
这些配置在真实测评中高频落红，务必规避：
- 错误：Web组同时放行80/443（对外）和22（对所有IP）→ 合规做法：22单独拆出，绑定跳板机专用安全组，并启用MFA联动（如RAM策略限制仅MFA用户可调用DescribeInstances）
- 错误：数据库组授权对象填“sg-all-app”，结果包含测试服务器→ 合规做法：为生产应用、灰度应用、测试应用分别建独立安全组，数据库组只引用sg-prod-app
- 错误：出站规则全开（0.0.0.0/0），导致恶意程序外联失管→ 合规做法：出站按需收紧，例如只允许访问OSS域名解析IP、NTP服务器、License校验地址
- 错误：规则改完不记录，被问“谁、何时、为何改”答不上→ 合规做法：每次变更触发云审计日志（如CloudTrail/SLS），导出操作记录存档至少180天
