1. 企业云安全边界与网络隔离体系导论

当企业把业务系统从自建机房迁移到 AWS 之后，最先被打破的往往不是应用逻辑，而是“边界”这个概念。在传统数据中心里，边界是机房门禁、防火墙机柜和一条明确的物理出口链路；而在云上，VPC、子网、路由表、安全组、网络 ACL、终端节点、PrivateLink、Transit Gateway 共同构成了一个逻辑边界。它没有围墙，却必须比围墙更精确——因为云上任何一条错误的路由或过宽的安全组规则，都可能在几秒内把内部服务暴露到公网。

本节作为整个课程的开篇，目标是建立一张“全局地图”：先厘清云安全边界与网络隔离的核心概念，再理解企业实际面对的威胁模型，然后看清合规要求如何约束架构设计，最后给出一个可落地的整体架构视图。后续 29 章会分别深入 VPC 设计、子网分层、安全组与 NACL、PrivateLink、集中出口、混合云连接、日志审计与自动化治理等专题，而本节要回答的是：这些组件为什么必须组合在一起，以及它们各自在边界体系中扮演什么角色。

一、核心概念：边界不是一条线，而是一组控制面

在 AWS 语境下，“安全边界”至少包含四个层次。第一层是网络可达性边界，由 VPC、子网、路由表、Internet Gateway、NAT Gateway、Transit Gateway 决定“谁能到达谁”。第二层是实例与资源级边界，由安全组、网络 ACL、资源策略（如 S3 Bucket Policy、KMS Key Policy）决定“到达之后能否访问”。第三层是身份与权限边界，由 IAM 策略、权限边界、SCP、角色信任策略决定“以什么身份、能做什么操作”。第四层是数据与加密边界，由 KMS、TLS、VPC 终端节点策略决定“数据在传输和静态存储时是否可见”。

网络隔离则是实现这些边界的手段。它不等于“把东西藏起来”，而是通过分段、最小权限、默认拒绝、显式放行四个原则，把攻击面压缩到可审计、可控制的范围。一个常见的误区是只依赖安全组：安全组是有状态的、作用于 ENI 的虚拟防火墙，但它无法阻止子网间的路由可达性，也无法替代 NACL 的无状态子网级过滤。真正有效的隔离，是路由层、子网层、实例层、身份层同时收敛。

二、威胁模型：企业云上最现实的六类风险

设计边界之前，必须先明确敌人在哪里。企业云环境中最常见的威胁可以归纳为六类：

• 公网暴露面过大：EC2 直接绑定公网 IP、RDS 开启 Publicly Accessible、S3 Bucket 误设为 public-read，导致扫描器在数分钟内发现入口。
• 横向移动：攻击者通过一个被攻陷的 Web 实例，利用过宽的安全组或扁平子网，直接访问数据库、缓存或内部管理接口。
• 凭证与角色滥用：实例元数据服务（IMDS）未强制 IMDSv2，或 IAM 角色权限过大，使临时凭证被窃取后可调用高权限 API。
• 数据外泄通道：通过 NAT Gateway、VPC 终端节点策略缺失或 DNS 隧道，把数据传出企业账号边界。
• 供应链与第三方接入：合作伙伴 VPC、SaaS 集成、跨账号角色信任配置不当，形成未审计的信任链。
• 配置漂移与人为误操作：安全组规则被临时放开后未回收，路由表被误改，导致边界在无人察觉时失效。

这六类风险对应到架构上，分别要求：收敛公网入口、实施子网分层、强制最小权限角色、限制出站流量、审计跨账号信任、以及用 IaC 与 Config 规则持续检测漂移。威胁模型不是一次性文档，而是边界设计的输入约束。

三、合规要求：把监管条款翻译成技术控制

合规要求通常不会直接告诉你“安全组要怎么写”，但它会给出必须满足的控制目标。以等保 2.0、ISO 27001、PCI DSS 和 SOC 2 为例，它们共同关注几个方向：网络区域划分、访问控制最小化、边界防护、入侵检测、日志留存与审计、数据加密与密钥管理。落到 AWS 上，这些目标会转化为具体控制项：

关键认知是：合规不是“额外加一层”，而是边界体系必须内建的可验证属性。如果架构本身没有分段、没有日志、没有最小权限，事后补文档无法通过审计。因此，合规要求应当作为架构设计的第一类需求，而不是上线前的检查项。

四、整体架构视图：从互联网到核心数据的五段边界

把上述概念、威胁与合规要求合并，可以得到一个典型的企业云边界参考架构。它按数据流方向分为五段：互联网入口段、公有子网段、应用私有子网段、数据私有子网段、以及集中服务与管理段。每一段都有明确的信任级别和放行策略。

这张图的关键在于：网络可达性、身份权限、数据加密、日志审计是四条并行的控制线，任何一条缺失，边界都会出现缺口。例如，即使应用子网没有公网 IP，如果实例角色拥有 s3:* 权限且没有终端节点策略限制，攻击者仍可通过被攻陷的实例把数据写入外部 S3 桶。因此，后续章节会分别沿着这四条线展开，而不是只讲网络。

五、落地起点：先做资产与流量盘点

在动手设计之前，建议先完成一次最小化的现状盘点。它不需要复杂工具，但必须覆盖以下对象：当前账号下所有 VPC 及其 CIDR、每个子网的路由表指向、所有安全组中 0.0.0.0/0 的入站规则、所有带公网 IP 的 EC2/RDS/ELB、所有跨账号角色信任关系、以及 VPC Flow Logs 与 CloudTrail 是否开启。一个可参考的检查清单如下：

完成盘点后，你会得到一张真实的“边界现状图”，它与本节给出的参考架构之间的差距，就是后续 29 章要逐项收敛的工作清单。边界体系不是一次建成的，而是通过持续盘点、收敛暴露面、补齐审计与自动化检测逐步逼近目标状态。