安全组是白名单
云安全组是云上第一道、也往往是唯一真正生效的边界：它是白名单模型，只有显式放行的流量才能通过，未列出的默认被拒。这意味着两件事——写「拒绝某地址」的规则没有意义，以及暴露面完全由放行条目决定。核查的方法是逐条读规则，把每条放行都能对应到明确的业务与来源范围。
基本信息
| 加固项 | 云边界入方向最小放行 |
|---|---|
| 适用平台 | 云主机（各主流云平台机制相同） |
| 风险等级 | 高 |
| 基线 | 管理类端口不对所有地址开放 |
| 核对三列 | 协议、端口范围、来源地址 |
典型使用场景
- 安全检查：批量核对全部安全组里的放行条目
- 上线前确认：新实例关联的规则是否符合最小放行
- 事件排查：确认暴露窗口是否存在以及对全网开放了哪些端口
- 规则清理：回收临时开通的调试规则
- 合规测评：边界访问控制条款要求来源可限定
以命令行工具列出规则（示例）
以命令行工具列出规则（示例）
aliyun ecs DescribeSecurityGroupAttribute --RegionId cn-hangzhou --SecurityGroupId sg-xxxx
# 关注 IpProtocol / PortRange / SourceCidrIp 三列，逐条评估必要性
aws ec2 describe-security-groups --group-ids sg-xxxx --query 'SecurityGroups[].IpPermissions'
# 多个实例共用安全组时，先确认关联实例清单再判断影响范围从主机侧反向核对
从主机侧反向核对
ss -tulnp | head -30 # 本机监听清单
ss -tulnp | grep -v 127.0.0.1 | head -20 # 对外监听
# 两边取交集：本机监听且安全组放行，才是真正对外可达常见规则问题
| 问题形态 | 风险说明 | 整改方向 |
|---|---|---|
| 管理端口来源为全部地址 | 全网可尝试登录，爆破持续发生 | 限制到办公出口或堡垒机网段 |
| 端口范围写得过宽 | 意外开放了范围中的其他端口 | 改为精确端口 |
| 协议放行全部 | 放开了不需要的协议族 | 按实际协议放行 |
| 临时调试规则未回收 | 暴露面随时间累积 | 纳入定期核查并标记有效期 |
| 实例关联多个安全组 | 按并集生效，容易漏算暴露面 | 统计暴露面时合并全部关联组 |
管理端口优先只放行办公出口地址或堡垒机网段：办公宽带的出口地址会变动时，用堡垒机把出口收敛成固定地址，比每次调整安全组更可控。全量核查时把「当前确认过的规则清单」留档，下一次只看差异即可。
两个容易误判的点：安全组是白名单，只配拒绝规则不会生效，未放行即已被拒；实例关联多个安全组时按允许并集生效，只查其中一个组会漏算暴露面，核查必须把该实例关联的全部组一起统计。
治理流程
建议按季度做一次全量核对：导出全部安全组规则，按来源为全部地址、端口属于管理或数据类两个条件筛出重点条目；逐条与业务方确认用途与来源范围；调整后从外部主机做一次实测验证。同时把新增规则的审批与有效期机制建立起来，避免临时放行长期滞留。