微服务安全组应按业务单元边界划分，每个服务或强耦合组独享安全组，实现最小权限、故障隔离与横向攻击阻断；规则需基于安全组id引用、区分流量方向、匹配环境生命周期，并与服务发现及网格协同。
在微服务架构中，安全组不是按“服务器”而是按“业务单元的网络访问边界”来划分的。每个微服务或一组强耦合微服务（如订单+库存）应归属独立安全组，实现最小权限通信和故障隔离。
按业务域划分安全组
不同业务域之间默认不通，例如用户中心、支付服务、通知服务各自使用专属安全组。这样即使某个服务被攻破，攻击者无法直接扫描或调用其他业务域的内网接口。
- 用户中心安全组：只开放 8081 端口给 API 网关安全组，禁止与其他业务组直连
- 支付服务安全组：仅允许来自订单服务安全组的 8082 端口调用，且限定源端口为服务注册发现端口（如 8000）
- 通知服务安全组：接受来自多个上游组的请求，但出方向只允许访问短信/邮件网关的特定 IP 和端口
区分流量方向与通信角色
同一业务单元内部可能有提供方与消费方角色，需在安全组规则中体现状态化控制：
- API 网关所在安全组作为统一入口，入方向放通公网 443，出方向仅允许访问后端各业务安全组的指定端口
- 数据库中间件（如 Redis、MySQL）单独部署在无公网 IP 的 ECS 上，其安全组只授权给对应业务安全组，不开放给网关或其它非关联服务
- 日志采集 Agent 所在节点的安全组，出方向限制为仅能发往日志平台的固定端口，入方向默认拒绝
配合服务发现与动态授权
微服务实例常动态扩缩容，IP 不固定，因此安全组规则应优先使用“引用安全组 ID”而非 CIDR 段：
- 在订单服务安全组中，添加一条入方向规则：协议 TCP，端口 8080，源为“用户中心安全组 ID”
- 避免写成 172.16.0.0/16 这类大网段，防止横向越权
- 若使用服务网格（如 Istio），安全组只需保障底层网络可达，mTLS 和细粒度策略交由 Sidecar 控制
环境与生命周期对齐
不同环境的微服务应使用不同安全组，避免测试流量误触生产服务：
- dev-sg、staging-sg、prod-sg 分别对应开发、预发、生产三套微服务集群
- 预发环境安全组可临时开放 SSH（22 端口）供排查，但生产环境该规则必须删除
- 灰度发布时，新版本 Pod 所在节点加入灰度安全组，仅允许被网关的灰度路由策略访问，不进入主业务安全组
