Amazon SCS-C02: 网络与 VPC 安全 — 学习指南

By Laurynas Brazys · 25 July 2026 · #amazon #scs-c02 #certification #exam-prep #study-guide

属于 AWS Security Specialty SCS-C02 — 学习指南. 使用经过验证的答案练习： Amazon 考试中心, 或参加限时模拟考试： ExamRoll.io.

VPC 端点和端点策略

VPC 端点可将流向 AWS 服务的流量保留在 AWS 网络内，从而绕过公共互联网、NAT 网关和互联网网关。VPC 端点有两种结构上不同的类型，混淆它们是最常见的设计错误之一。

网关端点仅适用于 Amazon S3 和 DynamoDB。它们是路由表条目——您将端点与路由表关联，目标为服务前缀列表（例如，us-east-1 中 S3 的 pl-63a5400a）的流量会被静默地通过该端点重新路由。它们不产生费用，并且无法从其所附加的 VPC 外部访问。

接口端点（由 AWS PrivateLink 提供支持）是放置在您子网中的、带有私有 IP 地址的 ENI。除了 S3 和 DynamoDB 之外的每个服务都需要它——例如 Secrets Manager、KMS、STS、SSM、CloudWatch Logs、ECR API/DKR 以及数百个其他服务。如果一个没有 NAT 网关的私有子网中的 EC2 实例需要从 Secrets Manager GetSecretValue，网关端点将无济于事；您必须创建一个 com.amazonaws.<region>.secretsmanager 接口端点并启用私有 DNS，以便标准的服务主机名解析到该端点的私有 IP。

端点策略独立于调用者的 IAM 策略，用于限制什么操作可以通过该端点执行。用于防止数据外泄的两个最重要的条件键是 aws:PrincipalOrgID（发起调用的身份必须属于您的 Organization）和 aws:ResourceOrgID（正在接触的 S3 存储桶、KMS 密钥等必须属于您的 Organization）。同时应用这两个条件可以关闭典型的数据外泄路径，即一个被攻破但拥有合法 S3 权限的实例向您组织外部由攻击者控制的存储桶写入数据——凭证对 S3 仍然有效，但端点会拒绝转发该请求。

{
  "Statement": [{
    "Effect": "Allow",
    "Principal": "*",
    "Action": "s3:*",
    "Resource": "*",
    "Condition": {
      "StringEquals": {
        "aws:PrincipalOrgID": "o-abc123",
        "aws:ResourceOrgID":  "o-abc123"
      }
    }
  }]
}

默认的端点策略是完全允许的（"Resource":"*" 上的 "Action":"*"），这就是为什么一个只有网关端点和最小权限 IAM 的子网，如果不收紧端点策略本身，仍然可能被滥用于数据外泄。

混合连接：VPN 和 Direct Connect

Site-to-Site VPN 在虚拟专用网关（或 Transit Gateway）和客户网关设备之间建立两个 IPsec 隧道。它部署迅速，默认加密，并穿越公共互联网——因此吞吐量和延迟取决于您的 ISP 路径。

AWS Direct Connect 通过一个 Direct Connect 站点预置一条专用的物理线路。它提供可预测的低延迟和高且一致的带宽（1/10/100 Gbps），这对于通信频繁的本地数据库流量至关重要。Direct Connect 本身在第 3 层未加密；数据帧在私有光纤上传输。对于既需要低延迟又需要 IPsec 的工作负载，标准的解决方案是通过公有 VIF 运行的 Direct Connect + Site-to-Site VPN（或在较新的 DX 端口上使用 MACsec 的 Transit Gateway）。单独使用 VPN 也是主 Direct Connect 链路推荐的加密备份方案，以便在线路故障时提供弹性。

• 仅 Direct Connect： 低延迟、私有，但在 IP 层未加密。
• 仅 VPN： 加密、部署快速，但存在互联网路径的延迟和抖动。
• Direct Connect + VPN： 兼具低延迟和 IPsec 加密；也是标准的 HA 模式。

安全组、NACL、DHCP 和源/目标检查

安全组是有状态的：如果您允许一个入站请求，其响应会自动被允许出站。它们只支持允许规则，并按每个 ENI 进行评估。

网络 ACL 是无状态的，在子网边界上操作。每个流量都需要两条规则——一条用于初始方向，另一条用于临时端口范围（Linux 通常为 32768–60999，Windows 为 49152–65535，NLB/ELB 使用 1024–65535）上的返回流量。一个允许入站 TCP 443 但忘记允许出站 TCP 1024–65535 的 NACL 会静默地破坏 TLS 连接。ICMP 不是 TCP/UDP：返回的“echo reply”报文必须被明确允许，而 Path MTU Discovery 依赖于 ICMP 类型 3 代码 4，这很容易被无意中丢弃。NACL 规则也按数字顺序评估，首个匹配即生效，并在末尾有一个隐式的拒绝规则。

DHCP 选项集控制 VPC 在实例启动时向其提供的内容：domain-name-servers、domain-name、NTP 服务器、NetBIOS。用自定义的本地解析器替换默认的 AmazonProvidedDNS 可能是合法的，但这会带来实际的安全后果。像 GuardDuty 这样的服务从遍历 Route 53 Resolver 的查询中获取基于 DNS 的发现结果（例如“加密货币”和“C&C 域名”检测）。一旦您将实例指向第三方 DNS 服务器，GuardDuty 将无法看到这些查询，这些类型的发现结果就会消失——这是一种很容易意外地使检测失效的方法。

源/目标检查是一个 ENI 属性，它会丢弃任何源或目标 IP 与该 ENI 不匹配的数据包。对于普通实例，该默认设置是正确的，但会破坏任何负责转发流量的设备——例如 NAT 实例、虚拟防火墙（Palo Alto、Fortinet、Check Point）、中转路由器、VPN 集中器。对于这些 ENI，请禁用该检查：

aws ec2 modify-instance-attribute \
  --instance-id i-0abc123 \
  --no-source-dest-check

VPC 对等连接、RAM 共享 VPC 与 NAT 设计

VPC 对等连接 (peering) 是一种一对一、非传递性的第三层链接。如果 A 与 B 对等，B 与 C 对等，那么 A 无法访问 C——您必须直接建立 A-C 的对等连接，或使用 Transit Gateway。双方的路由表都必须包含指向对等 CIDR 的路由，并且安全组只能在同一区域内引用对等的安全组 ID。

通过 AWS Resource Access Manager (RAM) 实现的共享 VPC，允许一个网络账户拥有一个 VPC，并与参与者账户共享单个子网。参与者在共享子网中启动资源，但不能修改 VPC、路由表或端点——所有者保留对连接策略的控制权。这通常比对等连接多个 VPC 更便宜、更简单。

对于私有子网的出站互联网访问，应每个可用区部署一个 NAT 网关，并将每个私有子网路由到其所在可用区内的 NAT。单个 NAT 网关会造成跨可用区依赖，并成为扩展和可用性瓶颈。当您的工作负载调用需要将您的出口 IP 加入白名单的第三方（例如支付处理商）时，您注册的是 NAT 网关的弹性 IP。由于 Auto Scaling 组后面的所有实例都通过该固定的 EIP 出口，因此即使组进行伸缩，源 IP 也不会改变。将 EC2 实例和 RDS 数据库放置在私有子网中，并仅在 ALB 上终止 HTTP/HTTPS 流量，即可完成此模式。

Route 53 Resolver：转发与查询日志记录

Route 53 Resolver（每个 VPC 中的 .2 地址）是混合 DNS 的枢纽。出站解析器端点通过条件转发规则，将指定的域名从 AWS 转发到本地 DNS 服务器——例如，用于让 corp.example.internal 能够根据您的 Active Directory 进行解析。入站解析器端点则反向操作，为本地主机在您的 VPC 中提供一个私有 IP，它们可以查询该 IP 来解析 *.eu-west-1.compute.internal 和私有托管区。

解析器查询日志记录功能会将 VPC 中发出的每个 DNS 查询写入 CloudWatch Logs、S3 或 Kinesis Firehose。它是调查可疑数据泄露或滥用的权威记录，能够补充——但不能替代——GuardDuty。请记住，如果 DHCP 选项集将实例重定向到非 Amazon 解析器，那么查询日志记录和 GuardDuty 的 DNS 发现都会失效，因为查询从未触及 Route 53 Resolver。

实践问题：用例场景

场景： Meridian Financial 公司在一个多账户 AWS 环境中运行着一个中心辐射型 (hub-and-spoke) 网络：一个通过 RAM 共享的共享服务 VPC 托管了集中的 NAT 网关、Route 53 Resolver 端点和 Transit Gateway 连接，而多个应用程序 VPC 则与 Transit Gateway 对等或连接。本地数据中心通过 Direct Connect 连接，并使用 VPN 作为故障转移。团队依赖集中的 DHCP 选项集和共享的解析器端点进行混合 DNS 解析。

挑战： 最近一次事件显示，由于分支 VPC 将流量路由到共享 NAT 而不是 VPC 端点，导致敏感 S3 对象通过公共互联网被访问；内部区域的 DNS 查询泄露到了公共解析器；以及一个禁用了源/目标检查、被用作临时路由器的 EC2 实例促成了横向移动。

推荐方法：

1. 在共享服务 VPC 中为 S3 和 DynamoDB 部署网关 VPC 端点，为 Secrets Manager 和 KMS 部署接口端点 (AWS PrivateLink)，并附加明确的端点策略，将访问限制在指定的存储桶和服务主体。
2. 重新设计 NAT，使应用程序子网使用 VPC 端点访问 AWS API 和 S3；仅为真正的互联网出口保留 NAT 网关，并配置严格的出口安全组和到 CloudWatch/S3 的 Flow Logs。
3. 在所有 EC2 实例上重新启用源/目标检查，有文档记录的路由设备除外；将路由功能转移到 Transit Gateway 连接或托管的 NAT 实例，并强制执行路由表的最小权限原则。
4. 将安全组和子网 NACL 收紧为默认拒绝的姿态，并通过 AWS Organizations SCP 和 AWS Config 规则应用集中的 IAM+SG 基线。
5. 通过部署 Route 53 Resolver 入站/出站端点来加固混合 DNS，配置条件转发和 DNS Firewall 规则，启用解析器查询日志记录到 CloudWatch Logs，并使用 DHCP 选项集为所有通过 RAM 共享的 VPC 强制使用内部解析器。

理由： 此方法通过使用带端点策略的 VPC 端点消除了不必要的互联网出口，通过 Transit Gateway/Direct Connect 集中化并控制路由，恢复了实例级别的保护，并利用 Resolver 端点和日志记录防止了 DNS 泄露——这与 AWS 的网络和纵深防御最佳实践相符。

VPC 端点和端点策略

VPC 端点允许 VPC 内的工作负载访问 AWS 服务 API，而无需通过公共互联网或 NAT 网关。它有两种架构类型，选择错误是导致流量路由错误的常见原因。

• 网关端点 (Gateway endpoints): 仅用于 Amazon S3 和 DynamoDB。它们在路由表中以目标的形式实现（一个指向 vpce-xxxxxxxx 的前缀列表 pl-xxxxxxxx）。这种方式不会创建 ENI，无需更改 DNS，也没有每小时的费用。

• 接口端点 (Interface endpoints) (PrivateLink): 用于 KMS、SQS、SNS、Secrets Manager、STS、EC2 API 以及大多数其他服务。它们会在选定的子网内配置具有私有 IP 的 ENI，并按小时和每 GB 流量计费。

对于一个跨账户的批处理作业，其中账户 B 中的 EC2 实例需要读取账户 A 中由账户 A 的 KMS 密钥加密的 S3 存储桶，正确的设计是为 S3 使用一个网关端点，为 KMS 使用一个接口端点。网关端点使 s3:GetObject、s3:PutObject、s3:PutObjectAcl 和 s3:ListBucket 等操作无需通过互联网；接口端点对 kms:Decrypt、kms:Encrypt 和 kms:GenerateDataKey 也起到了同样的作用。由于 KMS 密钥的 ARN 使用标准的 kms.<region>.amazonaws.com 主机名，接口端点必须启用私有 DNS (Private DNS enabled)，这样 SDK 未经修改的主机名才能解析到端点 ENI，而不是公共的 KMS 服务。如果没有启用私有 DNS（或者没有同时在 VPC 级别启用 DNS 主机名和 DNS 解析），客户端仍然会访问公共端点——因此，“无需更改代码”的要求隐含地需要启用私有 DNS。

端点策略是第二个独立的授权层。虽然存在一个宽松的默认策略，但针对特定存储桶和密钥进行加固的策略如下所示：

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": "*",
    "Action": ["s3:GetObject","s3:PutObject","s3:PutObjectAcl","s3:ListBucket"],
    "Resource": ["arn:aws:s3:::acct-a-bucket","arn:aws:s3:::acct-a-bucket/*"]
  }]
}

仅仅创建端点是不够的。有两种常见的失败模式：(1) 端点已存在，但私有子网的路由表没有指向 S3 前缀列表的条目，因此流量仍然通过 NAT 网关出站；(2) 端点策略遗漏了某个操作（如 s3:PutObjectAcl）或指向了错误的存储桶 ARN，从而静默地阻止了那些 IAM 本来会允许的调用。存储桶策略和端点策略都必须允许该请求——它们的权限是交集，而不是并集。

安全组、NACL 和快速遏制

安全组和 NACL 在不同层面上解决重叠的问题，考试中经常要求在两者之间为事件响应做出选择。

• 安全组 (Security groups): 有状态的，在 ENI 级别进行评估。返回流量被自动允许。只存在允许规则。非常适合用于主机级别的策略（例如“Web 层可以访问应用层的 8080 端口”）。

• 网络 ACL (Network ACLs): 无状态的，在子网边界进行评估。同时存在允许和拒绝规则，并按规则编号顺序处理。非常适合用于粗粒度的、子网范围的阻止——特别是将某个 IP 范围加入黑名单，或关闭子网中每个实例上的特定端口。

当恶意软件爆发，迫使您需要阻止多个实例向一组命令与控制 (C2) IP 的出站 TCP/2905 流量时，NACL 拒绝规则是正确的工具。安全组无法表达“拒绝”，并且需要枚举并修改每个受影响 ENI 引用的每一个 SG。一个低规则编号（例如 90）的子网级 NACL 拒绝规则可以立即覆盖该子网中的所有实例，同时保留由后续允许规则评估的不相关流量。

因为 NACL 是无状态的，请记住出站和入站方向都需要规则。阻止 2905 端口的出站流量不需要入站规则，但如果您也想拒绝入站的响应，则必须添加入站条目——并且必须存在针对临时端口 (1024–65535) 的入站允许条目，以允许合法的返回流量通过。

NAT 网关、路由和可用区独立性

NAT 网关是可用区级资源。标准模式是每个可用区一个 NAT 网关，每个私有子网的路由表都将 0.0.0.0/0 指向同一可用区内的 NAT 网关：

PrivateRouteTable-AZ-a:  0.0.0.0/0 -> nat-aaaa (in subnet public-az-a)
PrivateRouteTable-AZ-b:  0.0.0.0/0 -> nat-bbbb (in subnet public-az-b)
PrivateRouteTable-AZ-c:  0.0.0.0/0 -> nat-cccc (in subnet public-az-c)

跨可用区共享单个 NAT 网关看起来更便宜，但会引入两个问题：每个数据包都会产生跨可用区数据传输费用，以及一个硬性的可用性依赖——如果该可用区发生故障，所有私有子网都会失去互联网出口。当与 Transit Gateway 检查（见下文）结合使用时，这种每个可用区一个 NAT 的模式还可以避免非对称返回的奇怪问题。

用于调查的 VPC 流日志

流日志在 VPC、子网或 ENI 级别捕获五元组元数据（源/目标 IP、端口、协议、操作 ACCEPT/REJECT、字节数、数据包数）。要追查向 C2 主机发送 TCP/2905 信标的实例，请在 VPC 上启用流日志，将流量类型设置为 REJECT（因为 NACL 现在正在丢弃这些流量），然后在 CloudWatch Logs Insights 或 Athena 中查询：

SELECT srcaddr, dstaddr, dstport, action, COUNT(*) AS hits
FROM vpc_flow_logs
WHERE dstport = 2905 AND action = 'REJECT'
GROUP BY srcaddr, dstaddr, dstport, action
ORDER BY hits DESC;

srcaddr 列以最小的代价揭示了受感染实例的 IP——无需抓包，也无需主机代理。选择“ALL”流量类型也行，但会产生更多的数据和成本；如果只选择“ACCEPT”，则会完全错过被丢弃的尝试，而这恰恰是您需要看到的信息。

PrivateLink、Transit Gateway 和 Network Firewall

PrivateLink 将接口端点模型扩展到您自己的服务：提供商 VPC 在 VPC 端点服务后面暴露一个 NLB，而消费者创建接口端点来访问它，无需 VPC 对等连接或路由共享。它是单向的，并完全隐藏提供商的 CIDR。

Transit Gateway (TGW) 是用于多对多 VPC 和本地连接的中心枢纽。一种常见的模式是使用一个集中的检查 VPC，其中运行 AWS Network Firewall 或第三方设备，并通过 TGW 路由表将分支到分支的流量引导通过该检查 VPC。在默认的 TGW 行为下，这种设计会失效，因为 TGW 会跨不同可用区 (AZ) 的附件 ENI 对流量进行哈希，返回路径可能会进入与转发路径不同的可用区。有状态防火墙会丢弃那些它们从未见过 SYN 的流中数据包。

需要同时进行两项修正。首先，在检查 VPC 的 TGW 附件上启用设备模式 (Appliance Mode)；这将每个双向流固定到同一个可用区的 ENI 上，从而确保转发和返回流量经过相同的防火墙端点。其次，配置 TGW 路由表，使分支附件将流量发送到检查 VPC 附件，并在检查 VPC 上使用一个独立的检查后路由表将流量返回到正确的分支。跳过其中任何一个——无论是只启用设备模式而没有配置路由表，还是只配置路由表而没有启用设备模式——都会导致非对称丢包问题依然存在。

Network Firewall 本身使用与 Suricata 兼容的规则，并依赖对称路由来维持流状态；将其与检查 VPC 和分支 VPC 上的 Flow Logs 结合使用，可以提供所需的取证线索，以证明是哪个分支发起了会话，以及防火墙是允许还是丢弃了该会话。

实践问题：用例场景

场景： Meridian Financial 公司在一个多账户 AWS 环境中运行，其生产 VPC 跨越 us-east-1 的三个可用区，通过一个 AWS Transit Gateway 连接到一个中央安全 VPC。他们为每个可用区的出口流量使用 NAT Gateway，为合作伙伴的 SaaS 使用 S3 Gateway Endpoint 和 Interface Endpoint (PrivateLink)，并使用一个集中的 AWS Network Firewall 以及 Security Group 和 NACL；VPC Flow Logs 会流式传输到 CloudWatch 进行监控。

挑战： 一个生产环境的 EC2 实例被怀疑有横向移动和向外部 IP 及 S3 泄露数据的企图，Meridian 需要在不中断其他业务关键型 VPC 的情况下，跨可用区进行快速遏制。

推荐方法：

1. 立即隔离受感染的实例，方法是将其 Security Group 替换为一个拒绝所有出入站流量的限制性“隔离”SG，并为该实例添加标签以便通过 Systems Manager 进行自动修复；同时，应用子网级别的 Network ACL 规则，以阻止流向可疑外部 IP 范围的出口流量。
2. 在 Transit Gateway 上隔离该 VPC，方法是移除受影响 VPC 的 TGW 路由表附件，或将其更改为一个隔离 TGW 路由表（黑洞路由或无到其他附件的路由），从而阻止向其他 VPC 的横向移动。
3. 通过更新 TGW/路由表条目，将剩余的 VPC 出口流量重定向到集中的 AWS Network Firewall，以强制进行检查并阻止已知的恶意目标，同时通过为每个可用区保留 NAT Gateway 来保持可用区的独立性，实现有弹性的、受检查的出口流量。
4. 通过在 S3/DynamoDB Gateway Endpoint 上应用限制性的 VPC Endpoint 策略，拒绝来自未经批准的主体的 Put/Get 操作，并确保内部 API 使用 Interface Endpoint (PrivateLink) 以避免通过互联网路径，从而加强数据平面控制。
5. 使用 VPC Flow Logs、CloudWatch Logs Insights 和 AWS CloudTrail 进行取证，然后进行修复（重装镜像、轮换密钥），并在验证后才重新引入该实例；通过 AWS Firewall Manager/AWS Config 强制执行规则。

基本原理： 此系列操作在主机和网络层面提供了快速的、最小权限的遏制，通过 Network Firewall 和 Transit Gateway 路由实现集中式检查以最小化爆炸半径，通过每个可用区使用独立的 NAT Gateway 保持了可用区的弹性，并使用 VPC Flow Logs 进行可追溯的调查——这与 AWS 的深度防御最佳实践相一致。

← 数据保护与 S3 · 所有领域 · 边缘与应用安全 →

练习这些题目 → · 在 ExamRoll.io 上限时练习 →

浏览 Amazon →