微服务架构中，子网划分与安全组协同实现纵深防御：按业务角色划分为前端、应用、数据、管理子网，各子网间严格控制通信；子网内绑定服务级安全组，按标签或身份精细化授权；叠加服务网格（如istio）实现http/grpc层鉴权，形成网络层+应用层双重防护。
微服务架构结合子网划分实现精细化安全组控制，核心在于“网络分层 + 策略下沉”：用子网做逻辑边界，用安全组（或等效机制）做细粒度访问控制，两者协同形成纵深防御。
按业务角色划分子网，明确信任边界
不要把所有服务塞进一个子网。应依据数据敏感性、调用关系和合规要求，将微服务划入不同子网：
- 前端子网：仅部署 API 网关、静态资源服务，面向公网开放 443/80，禁止直连内部服务
- 应用子网：承载业务逻辑服务（如订单、用户），只允许从前端子网和数据库子网双向通信
- 数据子网：放置数据库、缓存、消息队列，仅接受应用子网的指定端口（如 5432、6379），拒绝所有其他来源
- 管理子网：独立部署监控、日志、配置中心等运维组件，与业务子网单向连通（只收不发）
在子网内启用服务级安全组策略
子网是粗粒度隔离，安全组才是执行点。关键不是“开几个端口”，而是“谁可以调用谁”：
- 为每个微服务实例绑定专属安全组，例如 order-service-sg 只放行来自 api-gateway-sg 的 8080 端口请求
- 数据库安全组不按 IP 段授权，而是按服务名或标签（如 app=payment）匹配，避免因容器漂移导致策略失效
- 禁用宽泛规则（如 “0.0.0.0/0” 或 “全部端口”），每条规则必须注明用途，例如：
[支付服务 → Redis] 允许 TCP 6379，限源标签 env=prod, role=payment
对接服务网格强化东西向流量控制
纯网络层安全组无法识别 HTTP Header、gRPC 方法或 JWT 声明。当需要更细控制时，应叠加服务网格能力：
- Istio 的 AuthorizationPolicy 可基于服务身份（SPIFFE ID）、请求路径、Header 值做鉴权，弥补子网+安全组的语义盲区
- 将安全组设为“第一道防线”（阻断非法源 IP 和非预期端口），服务网格作为“第二道防线”（校验 Token、路由前鉴权）
- 例如：安全组允许 user-service 访问 auth-service:9001，而 Istio 策略进一步限定只有带 scope=profile:read 的 Token 才能调用 GET /v1/profile
避免常见设计陷阱
实际落地中容易忽略的细节会削弱整体效果：
- 子网 CIDR 不重叠且预留扩展空间，例如用 10.10.0.0/16 总网段，再切出 /24 子网，避免未来扩容需重构
- 安全组规则遵循“最小权限+默认拒绝”，删除所有隐式允许（如 Docker 默认桥接网络的互通行为）
- 跨子网通信必须显式配置（如 VPC 对等连接、NAT 网关或服务网格 Sidecar），杜绝“以为隔离了其实没隔离”的假象
- 定期审计：用工具扫描未被任何服务使用的安全组、长期未更新的规则、开放高危端口（如 22、3389）的实例
