CloudFront 部署小指南（二十五） – 网络级源站防护

摘要：本文介绍了两种 AWS 源站防护方案：针对多 CDN 架构的 mTLS 双向认证方案（CloudFront Origin mTLS + ALB mTLS）和针对纯 CloudFront 架构的 VPC Origin 网络隔离方案。文章从”为什么 CDN 前置 WAF 不够”出发，详细讲解了每种方案的配置步骤、多 CDN 证书管理、DDoS 防护策略及选型建议，帮助读者构建从传输层到网络层的纵深防御体系。

一、背景：为什么 CDN 前置 WAF 不够？

在典型的 CDN + 源站架构中，客户通常在 CDN 层部署 WAF 来防御 DDoS、CC 攻击和恶意请求。然而，一个常被忽视的安全漏洞是：源站本身仍然暴露在公网上。

正常流量路径：
Client → CDN (WAF) → Origin (公网 IP/域名)

攻击者绕过 CDN：
Attacker → Origin (公网 IP/域名)  ← 直接攻击！

攻击者可以通过以下方式发现并直接攻击源站：

• DNS 历史记录查询（如 SecurityTrails）
• 证书透明度日志（Certificate Transparency Logs）
• 全网端口扫描（如 Shodan、Censys）
• 源站 IP 泄露（错误配置、邮件头、API 响应）

一旦源站 IP 暴露，CDN 层的 WAF 防护形同虚设——攻击者可以直接绕过 CDN 对源站发起攻击。

1.1 为什么不推荐“双 WAF”架构？

一种直觉的解决方案是在源站前再部署一层 WAF（即 CDN WAF + 源站 WAF 的双层架构）。但这种方案存在根本性缺陷：

源站 WAF 无法统一识别请求的真实客户端 IP。源站同时接收两类请求

• 经 CDN 转发的请求：真实客户端 IP 通过 X-Forwarded-For 头传递，TCP 源 IP 为 CDN 节点地址
• 来自互联网的直连请求：TCP 源 IP 即为真实客户端 IP，不携带 X-Forwarded-For 或该头部被伪造

这两类请求混杂在一起，使 WAF 面临两难：

• 若基于 TCP 源 IP 判断 —— CDN 转发的合法流量全部来自少量 CDN 节点 IP，无法区分正常用户和攻击者
• 若基于 X-Forwarded-For 判断 —— 直连请求可以伪造该头部，规则形同虚设

这种混杂导致 WAF 的速率限制、地理封锁、anti-DDoS、信誉库规则、机器人管理等规则误报和漏报概率显著增大，增加了运维复杂度和成本，却无法提供有效防护。

正确的思路是：确保只有 CDN 的流量能到达源站，从网络层和传输层彻底阻断非法直连。

二、方案概览

根据不同的部署场景，我们推荐两种源站防护方案：

三、场景一：多 CDN + mTLS 源站防护

3.1 适用场景

• 业务使用多个 CDN 厂商（如 CloudFront + Cloudflare + Akamai）
• 源站部署在 AWS 上（如 ALB + EC2/ECS）
• 需要确保只有授权的 CDN 能访问源站

3.2 为什么选择 mTLS 而非其他方案？

mTLS 的核心优势：

• 传输层认证：在 TLS 握手阶段即完成身份验证，无法被应用层伪造
• 多 CDN 兼容：每个 CDN 使用各自的客户端证书，源站通过 Trust Store 统一管理
• 证书轮换：支持平滑的证书更新，不影响业务
• 细粒度控制：可以按 CDN 厂商颁发不同证书，随时撤销特定 CDN 的访问权限

3.3 架构图

                    ┌─────────────────────────────────────────────┐
                    │              AWS Cloud                       │
┌──────────┐       │  ┌───────────────┐      ┌──────────────┐   │
│CloudFront│──mTLS──▶│  ALB (mTLS)   │─────▶│  EC2 / ECS   │   │
│(CDN #1)  │       │  │  Trust Store  │      │   (源站)      │   │
└──────────┘       │  └───────────────┘      └──────────────┘   │
┌──────────┐       │         ▲                                   │
│Cloudflare│──mTLS──────────┘                                    │
│(CDN #2)  │       │                                             │
└──────────┘       │                                             │
┌──────────┐       │                                             │
│ Akamai   │──mTLS──────────┘                                    │
│(CDN #3)  │       │                                             │
└──────────┘       └─────────────────────────────────────────────┘

3.4 配置步骤（以 CloudFront 为例）

下面以 CloudFront 作为 CDN、ALB 作为源站负载均衡为例，说明 mTLS 的端到端配置流程。其他 CDN（如 Cloudflare、Akamai）的配置原理相同，仅 CDN 侧的证书出示方式有所不同。

3.4.1 第一步：CloudFront Origin mTLS 配置

CloudFront Origin mTLS 允许 CloudFront 在回源时向源站出示客户端证书，证明自己的身份。

前提条件

• CloudFront 定价计划需为 Business、Premium 或 Pay As You Go
• 客户端证书需存储在 AWS Certificate Manager (ACM)，且位于 us-east-1 区域
• 证书需包含 Extended Key Usage (EKU) 属性：TLS Client Authentication

CLI 配置

# 更新 CloudFront Distribution 的 Origin，启用 mTLS
aws cloudfront update-distribution \
  --id E1EXAMPLE \
  --distribution-config '{
    "Origins": {
      "Items": [{
        "Id": "my-alb-origin",
        "DomainName": "origin.example.com",
        "CustomOriginConfig": {
          "HTTPSPort": 443,
          "OriginProtocolPolicy": "https-only"
        },
        "OriginMtlsConfig": {
          "ClientCertificateArn": "arn:aws:acm:us-east-1:123456789012:certificate/abc-123"
        }
      }]
    }
  }'

注意事项

• 同一 Distribution 的不同 Origin 可以配置不同的客户端证书
• 不兼容 VPC Origins、gRPC、WebSocket 和 Lambda@Edge Origin 触发器
• 如果源站不要求客户端证书，CloudFront 不会主动出示证书，连接正常进行

3.4.2 第二步：ALB mTLS 配置（源站侧验证）

ALB 的 mTLS 功能负责验证来自 CDN 的客户端证书，确保只有持有合法证书的 CDN 才能访问源站。

ALB mTLS 两种模式

配置步骤（Verify 模式）

1. 创建 Trust Store：上传所有授权 CDN 的 CA 证书（根证书或中间 CA）

# 创建 Trust Store
aws elbv2 create-trust-store \
  --name cdn-trust-store \
  --ca-certificates-bundle-s3-bucket my-certs-bucket \
  --ca-certificates-bundle-s3-key ca-bundle.pem

2. 配置 ALB Listener 启用 mTLS

# 修改 HTTPS Listener 启用 mutual authentication
aws elbv2 modify-listener \
  --listener-arn arn:aws:elasticloadbalancing:... \
  --mutual-authentication Mode=verify,TrustStoreArn=arn:aws:elasticloadbalancing:...:truststore/cdn-trust-store

3. 验证 Header 传递（可选，用于后端审计）

ALB 在 Verify 模式下会自动添加以下 Header：

后端应用可以利用这些 Header 进行更细粒度的授权判断（如区分不同 CDN 厂商）。

完成 CloudFront 和 ALB 的 mTLS 配置后，接下来需要考虑多 CDN 环境下的证书运维管理：

3.5 多 CDN 场景下的证书管理

ALB Trust Store 支持在一个 CA bundle 文件中包含多个 CA 证书。只要 CDN 出示的客户端证书由 bundle 中任一 CA 签发，ALB 即放行。

证书轮换策略：采用双 CA 并存 — 先将新 CA 加入 bundle 并更新 Trust Store，等所有 CDN 节点切换到新证书后，再移除旧 CA。

撤销访问：从 Trust Store 中移除对应 CDN 的 CA 证书即可立即阻断该 CDN 的回源连接。

3.6 mTLS 架构下的 DDoS 防护

在 mTLS 方案中，源站 ALB 仍然暴露在公网上，因此需要考虑 DDoS 攻击的防护：

mTLS 在 L7 DDoS 防护方面具有天然优势：攻击者无法从互联网直接对 ALB 发起有效的 HTTP 层请求 —— 因为没有合法的客户端证书和私钥，TLS 握手就会失败，连接在传输层即被终止。

对于 L3/L4/L5 层的网络层攻击，建议为 ALB 和后端 EC2 关联 AWS Shield Advanced 服务。Shield Advanced 在 AWS 网络边缘进行流量检测和自动缓解（mitigation），无需 ALB 自身参与处理。

四、场景二：CloudFront VPC Origin — 彻底隔离源站

4.1 适用场景

• 仅使用 CloudFront 作为 CDN（无多 CDN 需求）
• 源站部署在 AWS 上
• 希望源站完全不暴露公网 IP 和域名
• 追求最高级别的网络隔离

4.2 为什么 VPC Origin 是最安全的方案？

VPC Origin 从网络层彻底解决了源站暴露问题：

传统架构（有风险）：
Client → CloudFront → Origin (公网 ALB, 有公网 IP)
Attacker ──────────────────→ Origin (直接访问公网 IP)

VPC Origin 架构（安全）：
Client → CloudFront ──ENI──→ Origin (私有子网 ALB, 无公网 IP)
Attacker ────────── ✗ ──────→ Origin (不可达，无公网暴露)

核心优势

• 源站位于 VPC 私有子网，没有公网 IP，没有公网域名
• CloudFront 通过 AWS 托管的 ENI（弹性网络接口）直接连接源站
• 攻击者无法发现源站地址，从根本上消除了直连攻击的可能
• 无需管理证书、IP 白名单或自定义 Header

4.3 配置步骤

前提条件

• VPC 需要附加 Internet Gateway（这是 AWS 的技术实现要求，仅用于标识 VPC 可接收外部流量，实际不会有互联网流量通过 IGW 到达私有子网）
• 源站资源位于私有子网（无 NAT Gateway、无 Internet 路由）
• 支持 ALB、NLB 或 EC2 实例

1. 创建 VPC Origin

aws cloudfront create-vpc-origin \
  --vpc-origin-endpoint-config \
    Name=my-vpc-origin,\
    Arn=arn:aws:elasticloadbalancing:us-east-1:123456789012:loadbalancer/app/my-private-alb/abc123,\
    HTTPSPort=443,\
    OriginProtocolPolicy=https-only

2. 配置源站安全组

# 方式一：使用 CloudFront Managed Prefix List
aws ec2 authorize-security-group-ingress \
  --group-id sg-origin-xxx \
  --ip-permissions IpProtocol=tcp,FromPort=443,ToPort=443,PrefixListIds=[{PrefixListId=pl-3b927c52}]

# 方式二：使用 CloudFront 托管安全组（更严格）
aws ec2 authorize-security-group-ingress \
  --group-id sg-origin-xxx \
  --ip-permissions IpProtocol=tcp,FromPort=443,ToPort=443,UserIdGroupPairs=[{GroupId=sg-cloudfront-vpc-origins-xxx}]

3. 将 VPC Origin 关联到 Distribution：在 CloudFront Distribution 的 Origin 配置中，选择已创建的 VPC Origin 资源即可。

注意事项

• VPC Origin 不兼容 gRPC 流量和 Lambda@Edge Origin 触发器
• 不支持 IPv6-only 子网
• NLB 作为 VPC Origin 时不支持 TLS Listener
• 部署 VPC Origin 约需 15 分钟
• 支持跨账户共享 VPC Origin（通过 AWS RAM）

4.4 DDoS 防护：天然免疫

与 mTLS 方案不同，VPC Origin 架构下源站完全没有公网 IP 和公网域名，对互联网不可见。攻击者无法发现源站地址，更无法对其发起任何形式的 DDoS 攻击。这意味着源站天然免疫于 DDoS 威胁，无需额外部署 Shield Advanced。所有面向互联网的流量由 CloudFront 承接，DDoS 防护职责完全交由 CloudFront 层面（CloudFront 本身默认集成 AWS Shield Standard）。

五、方案对比与选型建议

选型决策树

需要多 CDN 支持？
├── 是 → 使用 mTLS 方案（CloudFront Origin mTLS + ALB mTLS）
└── 否 → 仅使用 CloudFront？
    ├── 是 → 使用 VPC Origin（最安全、最简单）
    └── 否 → 考虑其他 CDN 的 mTLS 能力或自建回源认证方案

六、总结

源站防护的核心原则是：让 CDN 成为源站的唯一入口，从网络层或传输层阻断一切非法直连。

• 如果你使用多个 CDN 厂商，mTLS 是最佳选择 — 它在 TLS 握手阶段即完成身份认证，无法被应用层伪造，且支持多 CDN 的灵活证书管理。
• 如果你仅使用 CloudFront，VPC Origin 是终极方案 — 源站完全不暴露公网，攻击者连源站地址都无法发现。

无论选择哪种方案，都远优于“双 WAF”架构或简单的 IP 白名单。安全防护应该在尽可能低的网络层实现，而不是依赖应用层的规则匹配。

➡️ 下一步行动：

相关产品：

• Amazon CloudFront — 全球内容分发网络
• Amazon VPC — 隔离云网络
• Amazon WAF — Web 应用程序防火墙
• Amazon EC2 — 安全且可调整大小的计算容量
• AWS Lambda — 无需服务器即可运行代码

相关文章：

• 基于Amazon Bedrock的云基础设施代码化自动解决方案实践
• Farewell to Bastion Hosts: Achieving Secure and Intelligent Operations for Private Subnets Using AWS EICE (EC2 Instance Connect Endpoint) and Chaterm
• 利用AWS Firewall Manager统一部署Network Firewall (二) 集中式架构
• CloudHSM的Java SDK使用及IoT场景加密体系设计最佳实践（上）
• Apache SeaTunnel 创新加速 ：AIDLC 方法论实践

七、附录：相关文档链接

*前述特定亚马逊云科技生成式人工智能相关的服务目前在亚马逊云科技海外区域可用。亚马逊云科技中国区域相关云服务由西云数据和光环新网运营，具体信息以中国区域官网为准。

本篇作者

亚马逊云科技中国峰会 开发者挑战赛现场开启，基于真实业务场景亲手构建 Agent。