4. 云网络边界与微分段架构
云上边界防护的核心矛盾在于：南北向入口需要“收窄暴露面”，东西向内部通信需要“按身份与用途放行”。如果只依赖一个 VPC 加几条宽松安全组，攻击者一旦突破某台 Web 主机，就能横向扫描数据库、缓存、管理端口。微分段的目标不是把网络切得越碎越好，而是让每一段流量都有明确的“谁访问谁、走哪个端口、经不经过检查点”的答案。
一、先定拓扑：三层子网与两条路径
以典型三层 Web 应用为例，规划一个 VPC（10.20.0.0/16），按可用区 A/B 各切三类子网：公网子网承载 ALB/NAT 网关，私网应用子网承载业务实例，私网数据子网承载 RDS 与 Redis。公网子网路由指向 Internet Gateway，私网子网默认路由指向 NAT 网关（仅出站），数据子网不配置任何出站默认路由。这样南北向入口只落在 ALB，东西向流量在私网内按安全组收敛。
南北向路径为：Internet → IGW → ALB（公网子网）→ 应用实例（私网子网）→ RDS（数据子网）。东西向路径为：应用实例之间、应用与数据之间、运维跳板与各层之间。两条路径的放行策略必须分开设计，不能共用一条“全通”规则。
二、安全组与网络 ACL 的分工
安全组是有状态的实例级虚拟防火墙，只支持允许规则，返回流量自动放行；网络 ACL 是无状态的子网级过滤，支持允许与拒绝，需要显式放行双向端口。实践中把“精细放行”交给安全组，把“粗粒度兜底与显式拒绝”交给网络 ACL。
以应用层安全组 sg-app 为例，入站只允许来自 sg-alb 的 8080 端口，出站允许到 sg-db 的 3306 与到 sg-cache 的 6379，其余出站默认拒绝。数据层安全组 sg-db 入站仅允许 sg-app 的 3306，且不配置任何 0.0.0.0/0 入站。网络 ACL 在数据子网入站方向先放行 3306/6379 来自应用子网 CIDR，再显式拒绝 0.0.0.0/0 的 22 与 3389，最后放行 1024-65535 的返回端口。
# 安全组规则示例（伪代码，字段含义：方向/协议/端口/来源/说明）
sg-app ingress TCP 8080 sg-alb # 仅 ALB 可访问应用
sg-app egress TCP 3306 sg-db # 应用访问数据库
sg-app egress TCP 6379 sg-cache # 应用访问缓存
sg-db ingress TCP 3306 sg-app # 仅应用可访问数据库
sg-db ingress TCP 3306 0.0.0.0/0 # 禁止：默认不应存在
nacl-data-subnet ingress TCP 3306 10.20.11.0/24 allow
nacl-data-subnet ingress TCP 22 0.0.0.0/0 deny
nacl-data-subnet ingress TCP 1024-65535 0.0.0.0/0 allow # 返回流量三、服务端点与私有链路：让流量不出公网
访问对象存储、密钥管理、日志服务时，如果走公网 NAT，既增加成本又扩大暴露面。做法是在 VPC 内创建接口端点（Interface Endpoint），把服务域名解析到子网内的私有 IP，安全组只允许应用子网访问 443。跨 VPC 或跨账号访问第三方服务时，使用私有链路（PrivateLink）建立端点服务，消费方只需在自己的 VPC 内创建端点，无需对等连接或路由打通，天然实现单向、最小化暴露。
判断端点是否生效，可在应用实例上执行 dig +short s3.us-east-1.amazonaws.com，若返回 10.20.x.x 的私有地址而非公网 IP，说明私有 DNS 已接管；再用 curl -v https://s3.us-east-1.amazonaws.com 观察 TLS 握手目标 IP，确认未经过 NAT 网关。
四、东西向隔离的落地检查
微分段不是一次性配置，而是持续验证。建议按以下顺序检查：第一，确认每个安全组的入站来源都是安全组 ID 或明确 CIDR，不存在 0.0.0.0/0 的管理端口；第二，确认数据子网没有默认路由指向 IGW；第三，确认应用实例之间默认不互通，只有明确声明的调用关系才放行；第四，确认所有出站访问云服务均走端点或私有链路；第五，用 VPC 流日志抽样观察是否存在被拒绝的异常端口扫描。
把上述拓扑、安全组、ACL、端点与私有链路组合起来，南北向入口收敛到 ALB 与受控运维通道，东西向流量按应用—数据—缓存的最小权限放行，云服务访问全部走私有路径。这样即使某一台应用实例被攻陷，攻击者能触达的目标也被限制在已声明的调用关系内，横向移动成本显著提高。