上周半夜接到一个紧急电话客户的业务挂了。打开监控一看源站 ALB 的 CPU 直接拉满连接数爆表。但奇怪的是 CloudFront 那边的请求量完全正常WAF 日志也干干净净。我当时就猜到了——源站 IP 漏了攻击者绕过了 CloudFront 直接打源站。后来确认就是这样客户的源站域名之前在 DNS 里解析过公网 IP虽然后来改成了 CloudFront 的 CNAME但历史记录在 SecurityTrails 上一查就有攻击者拿这个 IP 直接对着 ALB 开干CloudFront 上的 WAF 规则再多也没用因为流量根本没经过 CloudFront。这事儿让我觉得有必要把源站防护这个话题好好聊一聊。很多人觉得 CDN 前面挂个 WAF 就安全了其实这只是第一道门源站本身还在互联网上裸奔呢。你以为的安全其实只防了一半我见过太多团队的架构是这样的CloudFront 挂 WAF后面接一个公网 ALBALB 后面是 ECS/EKS。WAF 规则配了一堆IP Rate Limiting、Geo Block、Bot Control 全上了看起来铜墙铁壁。但你想想WAF 防的是什么是经过 CloudFront 的流量。攻击者如果直接找到你源站的公网 IP 或域名绕过 CloudFront 直接访问 ALB你的 WAF 规则一条都匹配不上。找源站 IP 的手段多得很我随便列几个DNS 历史记录——你以前解析过的 IP 全留着呢SecurityTrails 这种工具一搜就有证书透明度日志——你申请 SSL 证书的时候域名信息就公开了Shodan、Censys 这种全网扫描引擎端口 Banner 证书一把梭还有各种泄露场景邮件头里带源站 IP 的、API 返回值里暴露内网信息的、甚至有把源站域名硬编码在前端 JS 里的……有人可能会说那我源站前面也挂一个 WAF 不就行了CDN 一层、源站一层双重保险。我以前也这么想过后来发现根本行不通。源站 WAF 最大的问题是分不清谁是谁。经过 CDN 转发过来的请求TCP 源 IP 是 CDN 节点的地址真实客户端 IP 在 X-Forwarded-For 里。而直连源站的请求TCP 源 IP 就是攻击者自己的X-Forwarded-For 可以随便编。这两种请求搅在一起WAF 就抓瞎了——按 TCP 源 IP 限速吧CDN 节点的 IP 就那么几个正常用户的请求也全被限了按 X-Forwarded-For 限速吧直连请求伪造这个头部跟玩一样。结果就是误报漏报一大堆运维成本翻倍效果约等于零。所以思路得变别在应用层纠结了直接在网络层或传输层把非 CDN 流量掐死。两条路看你走哪条我根据实际项目经验总结了两种落地方案你的场景推荐方案一句话概括用了好几家 CDN源站在 AWSmTLS 双向认证靠证书验明正身谁有证谁进来只用 CloudFront源站在 AWSVPC Origin源站从互联网上消失谁都找不到下面详细拆解。先说简单的VPC Origin让源站隐身如果你的架构只用 CloudFront 一家 CDN那 VPC Origin 是最省心也最安全的方案没有之一。原理其实很直白把源站放到 VPC 私有子网里不给它公网 IP不给它公网域名。CloudFront 通过 AWS 内部的 ENI弹性网络接口直接连到你的私有子网流量走的是 AWS 内网不经过互联网。攻击者连目标都发现不了更别提攻击了。传统架构下源站是有公网 IP 的Client → CloudFront → ALB (公网IP暴露了) Attacker ─────────────→ ALB (绕过CDN直接打)VPC Origin 架构下源站没有公网 IPClient → CloudFront ──ENI──→ ALB (私有子网无公网IP) Attacker ────────── ✗ ─────→ 不可达根本找不到打个不太恰当的比方传统架构相当于你家大门装了监控WAF但房子就在马路边上谁都能看到门牌号。VPC Origin 相当于把你家搬到了一个没有门牌号的地下室只有知道暗道的人CloudFront才能进来外人连你住哪都不知道。配置过程前提条件有几个要注意的VPC 得挂上 Internet Gateway这是 AWS 的技术实现要求。别担心这只是个标识实际不会有互联网流量通过 IGW 到达私有子网你的源站还是安全的源站必须在私有子网里不能有 NAT Gateway不能有 Internet 路由支持 ALB、NLB、EC2 实例创建 VPC Originaws cloudfront create-vpc-origin\--vpc-origin-endpoint-config\Namemy-vpc-origin,\Arnarn:aws:elasticloadbalancing:us-east-1:123456789012:loadbalancer/app/my-private-alb/abc123,\HTTPSPort443,\OriginProtocolPolicyhttps-only配置安全组限制只有 CloudFront 能进来方式一用 CloudFront Managed Prefix Listaws ec2 authorize-security-group-ingress\--group-id sg-origin-xxx\--ip-permissionsIpProtocoltcp,FromPort443,ToPort443,PrefixListIds[{PrefixListIdpl-3b927c52}]方式二用 CloudFront 托管安全组这个限制更严格只允许 CloudFront 的 ENI 访问aws ec2 authorize-security-group-ingress\--group-id sg-origin-xxx\--ip-permissionsIpProtocoltcp,FromPort443,ToPort443,UserIdGroupPairs[{GroupIdsg-cloudfront-vpc-origins-xxx}]我个人更推荐方式二限制粒度更细。把 VPC Origin 关联到 Distribution就简单了在 CloudFront 控制台的 Origin 配置里选你刚创建的 VPC Origin 资源就行。踩坑提醒gRPC 和 LambdaEdge Origin 触发器不支持如果你的业务用了这些得另想办法IPv6-only 子网不行NLB 做 VPC Origin 时不支持 TLS Listener需要 TLS 终结的话得用 ALB部署大概要等 15 分钟别急支持跨账户共享通过 AWS RAM 实现多团队协作时很方便DDoS不存在的VPC Origin 最让我舒坦的一点就是——源站根本不在公网上DDoS 从何谈起所有面向互联网的流量 CloudFront 接着CloudFront 自带 AWS Shield StandardL3/L4 的基础防护就有了。你不用额外买 Shield Advanced不用在源站做任何 DDoS 防护配置。省钱省心。再说复杂的mTLS多 CDN 场景的刚需如果你的业务同时用了 CloudFront Cloudflare或者还加了 Akamai源站都在 AWS 的 ALB 后面——这在出海业务里太常见了国内走一家 CDN海外走 CloudFront合规要求还得再加一家。这种多 CDN 架构下VPC Origin 就用不了了它只认 CloudFront得靠 mTLS。为什么不是其他方案我知道有人会想到这几种方案我逐个说说为什么不行Security Group 白名单——限制源站只允许 CDN 的 IP 段访问。能用但 CDN 的 IP 段动辄几百个Security Group 有 IP 数量限制容易超。而且 CDN 的 IP 范围会变你得盯着更新运维负担不小。IP 理论上还能被伪造。自定义 Header——CDN 回源时加个X-My-Secret: abc123源站校验这个 Header。简单是简单但 Header 可以被抓包截获也可以被伪造安全性太低。一旦泄露就完了。Direct Connect 专线——安全倒是安全但每个 CDN 厂商拉一条专线成本高得吓人开通周期还长灵活性差。mTLS 优势在哪认证发生在 TLS 握手阶段比应用层早得多。就像你进小区自定义 Header 是到了单元门口才查门禁卡mTLS 是在小区大门口就验身份证——连小区都进不来更别说单元门了。具体来说传输层就完成身份认证应用层没法伪造每个 CDN 用自己的客户端证书源站 Trust Store 统一管理证书轮换可以平滑做不影响业务想断某个 CDN 的访问删掉对应的 CA 证书就行架构长这样┌─────────────────────────────────────────────┐ │ AWS Cloud │ ┌──────────┐ │ ┌───────────────┐ ┌──────────────┐ │ │CloudFront│──mTLS──▶│ ALB (mTLS) │─────▶│ EC2 / ECS │ │ │(CDN #1) │ │ │ Trust Store │ │ (源站) │ │ └──────────┘ │ └───────────────┘ └──────────────┘ │ ┌──────────┐ │ ▲ │ │Cloudflare│──mTLS──────────┘ │ │(CDN #2) │ │ │ └──────────┘ │ │ ┌──────────┐ │ │ │ Akamai │──mTLS──────────┘ │ │(CDN #3) │ │ │ └──────────┘ └─────────────────────────────────────────────┘三家 CDN 各自带自己的客户端证书回源ALB 的 Trust Store 里存了三家的 CA 证书有证的放行没证的 TLS 握手阶段就拒了。配置实操以 CloudFront ALB 为例走一遍完整流程其他 CDN 原理一样只是 CDN 侧证书出示的方式不同。CloudFront 侧让 CloudFront 出示客户端证书几个前提条件别漏了CloudFront 定价计划得是 Business、Premium 或 Pay As You Go免费版不支持客户端证书要存到 ACM而且必须在 us-east-1CloudFront 的老规矩证书的 EKU 属性必须是 TLS Client Authentication不然 CloudFront 不认CLI 配置aws cloudfront update-distribution\--idE1EXAMPLE\--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 和 LambdaEdge Origin 触发器用了这些功能的得另想办法。还有如果源站不要求客户端证书CloudFront 不会主动出示连接照常走这个行为是合理的。ALB 侧验证客户端证书ALB 的 mTLS 有两种模式。Passthrough 模式是 ALB 不验证证书把证书链通过 Header 传给后端让后端自己验。Verify 模式是 ALB 用 Trust Store 直接验证通过才放行。我强烈建议用 Verify 模式。Passthrough 把验证逻辑推给后端应用增加复杂度还容易出漏洞。能在基础设施层解决的事别推到应用层。Verify 模式配置创建 Trust Store上传所有授权 CDN 的 CA 证书aws elbv2 create-trust-store\--namecdn-trust-store\--ca-certificates-bundle-s3-bucket my-certs-bucket\--ca-certificates-bundle-s3-key ca-bundle.pem修改 ALB Listener 启用 mTLSaws elbv2 modify-listener\--listener-arn arn:aws:elasticloadbalancing:...\--mutual-authenticationModeverify,TrustStoreArnarn:aws:elasticloadbalancing:...:truststore/cdn-trust-storeALB 在 Verify 模式下会自动注入一些 Header可以用于后端审计和细粒度授权Header内容X-Amzn-Mtls-Clientcert-Serial-Number证书序列号X-Amzn-Mtls-Clientcert-Issuer颁发者X-Amzn-Mtls-Clientcert-Subject主题X-Amzn-Mtls-Clientcert-Validity有效期X-Amzn-Mtls-Clientcert-Leaf叶子证书比如你想区分请求是从 CloudFront 来的还是 Cloudflare 来的看 Issuer 就行。做审计日志的时候也方便。多 CDN 证书管理——运维的大头配完了只是开始证书的日常管理才是真正的考验。ALB Trust Store 支持在一个 CA bundle 文件里放多个 CA 证书只要 CDN 出示的客户端证书是 bundle 中任一 CA 签发的ALB 就放行。不同 CDN 的证书签发方式不一样CDN签发方式CA 证书怎么拿CloudFront自建 Private CA 签发导入 ACMaws acm-pca get-certificate-authority-certificateCloudflareZone-level AOP 用自建 CAGlobal AOP 用 Cloudflare 公共 CAauthenticated_origin_pull_ca.pemAkamaiAkamai-signed 或 Third-party CAControl Center → CDN → mTLS Origin Keystore证书轮换我推荐双 CA 并存策略先把新 CA 加到 bundle 里更新 Trust Store等所有 CDN 节点都切到新证书了再把旧 CA 从 bundle 里移除。整个过程零中断不用停业务。撤销访问更简单从 Trust Store 里移除对应 CDN 的 CA 证书立刻阻断该 CDN 的回源连接。比如你跟某家 CDN 解约了删掉它的 CA 证书就完事了。mTLS 架构下的 DDoS 防护mTLS 方案有个不得不面对的问题源站 ALB 还是暴露在公网上的。虽然只有持合法证书的请求能通过 TLS 握手但 L3/L4 层的网络攻击不需要完成 TLS 握手就能消耗资源。L7 层的攻击HTTP Flood、CC 之类的mTLS 天然免疫——攻击者没有合法的客户端证书和私钥TLS 握手都完不成HTTP 请求根本发不出来。但 L3/L4/L5 层SYN Flood、UDP 反射、TLS 握手洪泛需要 AWS Shield Advanced 来扛。Shield Advanced 在 AWS 网络边缘就把攻击流量清洗掉了ALB 根本感知不到。一个月 $3,000不便宜但高价值业务该花还是得花。两种方案到底怎么选直接看对比mTLSVPC Origin安全性高传输层认证最高网络层隔离多 CDN✅❌ 只认 CloudFront源站公网暴露还是需要公网域名完全没有DDoS 防护L7 天然免疫L3/L4 要 Shield Advanced天然免疫不需要额外防护证书管理要管不需要部署难度中等低兼容性限制不支持 VPC Origin/gRPC/WebSocket不支持 gRPC/LambdaEdge成本mTLS 免费Shield Advanced 可选 $3,000/月无额外费用我的建议是能用 VPC Origin 就用 VPC Origin配置简单安全性最高还不用管证书。只有确实需要多 CDN 的场景才上 mTLS但证书轮换的运维成本你得提前有心理准备。简单画个决策流程用了多家 CDN ├── 是 → mTLS没得选 └── 否 → 只用 CloudFront ├── 是 → VPC Origin最省心 └── 否 → 看看其他 CDN 有没有 mTLS 能力最后说两句源站防护这事儿核心就一句话让 CDN 成为源站的唯一入口在网络层或传输层把非法直连掐死。别在应用层折腾 WAF 规则了越往底层做越靠谱。多 CDN 用 mTLSTLS 握手阶段就验身份伪造不了。纯 CloudFront 用 VPC Origin源站从互联网上消失攻击者连地址都找不到。不管哪种都比双 WAF或者 IP 白名单强太多。安全防护这东西永远是在和攻击者比谁更底层——你在应用层做规则匹配人家在网络层绕过你你在网络层封堵他就更难搞了。把防线往下沉才是正道。
源站 IP 暴露被直接打穿？这套 AWS 纵深防御方案你一定用得上
上周半夜接到一个紧急电话客户的业务挂了。打开监控一看源站 ALB 的 CPU 直接拉满连接数爆表。但奇怪的是 CloudFront 那边的请求量完全正常WAF 日志也干干净净。我当时就猜到了——源站 IP 漏了攻击者绕过了 CloudFront 直接打源站。后来确认就是这样客户的源站域名之前在 DNS 里解析过公网 IP虽然后来改成了 CloudFront 的 CNAME但历史记录在 SecurityTrails 上一查就有攻击者拿这个 IP 直接对着 ALB 开干CloudFront 上的 WAF 规则再多也没用因为流量根本没经过 CloudFront。这事儿让我觉得有必要把源站防护这个话题好好聊一聊。很多人觉得 CDN 前面挂个 WAF 就安全了其实这只是第一道门源站本身还在互联网上裸奔呢。你以为的安全其实只防了一半我见过太多团队的架构是这样的CloudFront 挂 WAF后面接一个公网 ALBALB 后面是 ECS/EKS。WAF 规则配了一堆IP Rate Limiting、Geo Block、Bot Control 全上了看起来铜墙铁壁。但你想想WAF 防的是什么是经过 CloudFront 的流量。攻击者如果直接找到你源站的公网 IP 或域名绕过 CloudFront 直接访问 ALB你的 WAF 规则一条都匹配不上。找源站 IP 的手段多得很我随便列几个DNS 历史记录——你以前解析过的 IP 全留着呢SecurityTrails 这种工具一搜就有证书透明度日志——你申请 SSL 证书的时候域名信息就公开了Shodan、Censys 这种全网扫描引擎端口 Banner 证书一把梭还有各种泄露场景邮件头里带源站 IP 的、API 返回值里暴露内网信息的、甚至有把源站域名硬编码在前端 JS 里的……有人可能会说那我源站前面也挂一个 WAF 不就行了CDN 一层、源站一层双重保险。我以前也这么想过后来发现根本行不通。源站 WAF 最大的问题是分不清谁是谁。经过 CDN 转发过来的请求TCP 源 IP 是 CDN 节点的地址真实客户端 IP 在 X-Forwarded-For 里。而直连源站的请求TCP 源 IP 就是攻击者自己的X-Forwarded-For 可以随便编。这两种请求搅在一起WAF 就抓瞎了——按 TCP 源 IP 限速吧CDN 节点的 IP 就那么几个正常用户的请求也全被限了按 X-Forwarded-For 限速吧直连请求伪造这个头部跟玩一样。结果就是误报漏报一大堆运维成本翻倍效果约等于零。所以思路得变别在应用层纠结了直接在网络层或传输层把非 CDN 流量掐死。两条路看你走哪条我根据实际项目经验总结了两种落地方案你的场景推荐方案一句话概括用了好几家 CDN源站在 AWSmTLS 双向认证靠证书验明正身谁有证谁进来只用 CloudFront源站在 AWSVPC Origin源站从互联网上消失谁都找不到下面详细拆解。先说简单的VPC Origin让源站隐身如果你的架构只用 CloudFront 一家 CDN那 VPC Origin 是最省心也最安全的方案没有之一。原理其实很直白把源站放到 VPC 私有子网里不给它公网 IP不给它公网域名。CloudFront 通过 AWS 内部的 ENI弹性网络接口直接连到你的私有子网流量走的是 AWS 内网不经过互联网。攻击者连目标都发现不了更别提攻击了。传统架构下源站是有公网 IP 的Client → CloudFront → ALB (公网IP暴露了) Attacker ─────────────→ ALB (绕过CDN直接打)VPC Origin 架构下源站没有公网 IPClient → CloudFront ──ENI──→ ALB (私有子网无公网IP) Attacker ────────── ✗ ─────→ 不可达根本找不到打个不太恰当的比方传统架构相当于你家大门装了监控WAF但房子就在马路边上谁都能看到门牌号。VPC Origin 相当于把你家搬到了一个没有门牌号的地下室只有知道暗道的人CloudFront才能进来外人连你住哪都不知道。配置过程前提条件有几个要注意的VPC 得挂上 Internet Gateway这是 AWS 的技术实现要求。别担心这只是个标识实际不会有互联网流量通过 IGW 到达私有子网你的源站还是安全的源站必须在私有子网里不能有 NAT Gateway不能有 Internet 路由支持 ALB、NLB、EC2 实例创建 VPC Originaws cloudfront create-vpc-origin\--vpc-origin-endpoint-config\Namemy-vpc-origin,\Arnarn:aws:elasticloadbalancing:us-east-1:123456789012:loadbalancer/app/my-private-alb/abc123,\HTTPSPort443,\OriginProtocolPolicyhttps-only配置安全组限制只有 CloudFront 能进来方式一用 CloudFront Managed Prefix Listaws ec2 authorize-security-group-ingress\--group-id sg-origin-xxx\--ip-permissionsIpProtocoltcp,FromPort443,ToPort443,PrefixListIds[{PrefixListIdpl-3b927c52}]方式二用 CloudFront 托管安全组这个限制更严格只允许 CloudFront 的 ENI 访问aws ec2 authorize-security-group-ingress\--group-id sg-origin-xxx\--ip-permissionsIpProtocoltcp,FromPort443,ToPort443,UserIdGroupPairs[{GroupIdsg-cloudfront-vpc-origins-xxx}]我个人更推荐方式二限制粒度更细。把 VPC Origin 关联到 Distribution就简单了在 CloudFront 控制台的 Origin 配置里选你刚创建的 VPC Origin 资源就行。踩坑提醒gRPC 和 LambdaEdge Origin 触发器不支持如果你的业务用了这些得另想办法IPv6-only 子网不行NLB 做 VPC Origin 时不支持 TLS Listener需要 TLS 终结的话得用 ALB部署大概要等 15 分钟别急支持跨账户共享通过 AWS RAM 实现多团队协作时很方便DDoS不存在的VPC Origin 最让我舒坦的一点就是——源站根本不在公网上DDoS 从何谈起所有面向互联网的流量 CloudFront 接着CloudFront 自带 AWS Shield StandardL3/L4 的基础防护就有了。你不用额外买 Shield Advanced不用在源站做任何 DDoS 防护配置。省钱省心。再说复杂的mTLS多 CDN 场景的刚需如果你的业务同时用了 CloudFront Cloudflare或者还加了 Akamai源站都在 AWS 的 ALB 后面——这在出海业务里太常见了国内走一家 CDN海外走 CloudFront合规要求还得再加一家。这种多 CDN 架构下VPC Origin 就用不了了它只认 CloudFront得靠 mTLS。为什么不是其他方案我知道有人会想到这几种方案我逐个说说为什么不行Security Group 白名单——限制源站只允许 CDN 的 IP 段访问。能用但 CDN 的 IP 段动辄几百个Security Group 有 IP 数量限制容易超。而且 CDN 的 IP 范围会变你得盯着更新运维负担不小。IP 理论上还能被伪造。自定义 Header——CDN 回源时加个X-My-Secret: abc123源站校验这个 Header。简单是简单但 Header 可以被抓包截获也可以被伪造安全性太低。一旦泄露就完了。Direct Connect 专线——安全倒是安全但每个 CDN 厂商拉一条专线成本高得吓人开通周期还长灵活性差。mTLS 优势在哪认证发生在 TLS 握手阶段比应用层早得多。就像你进小区自定义 Header 是到了单元门口才查门禁卡mTLS 是在小区大门口就验身份证——连小区都进不来更别说单元门了。具体来说传输层就完成身份认证应用层没法伪造每个 CDN 用自己的客户端证书源站 Trust Store 统一管理证书轮换可以平滑做不影响业务想断某个 CDN 的访问删掉对应的 CA 证书就行架构长这样┌─────────────────────────────────────────────┐ │ AWS Cloud │ ┌──────────┐ │ ┌───────────────┐ ┌──────────────┐ │ │CloudFront│──mTLS──▶│ ALB (mTLS) │─────▶│ EC2 / ECS │ │ │(CDN #1) │ │ │ Trust Store │ │ (源站) │ │ └──────────┘ │ └───────────────┘ └──────────────┘ │ ┌──────────┐ │ ▲ │ │Cloudflare│──mTLS──────────┘ │ │(CDN #2) │ │ │ └──────────┘ │ │ ┌──────────┐ │ │ │ Akamai │──mTLS──────────┘ │ │(CDN #3) │ │ │ └──────────┘ └─────────────────────────────────────────────┘三家 CDN 各自带自己的客户端证书回源ALB 的 Trust Store 里存了三家的 CA 证书有证的放行没证的 TLS 握手阶段就拒了。配置实操以 CloudFront ALB 为例走一遍完整流程其他 CDN 原理一样只是 CDN 侧证书出示的方式不同。CloudFront 侧让 CloudFront 出示客户端证书几个前提条件别漏了CloudFront 定价计划得是 Business、Premium 或 Pay As You Go免费版不支持客户端证书要存到 ACM而且必须在 us-east-1CloudFront 的老规矩证书的 EKU 属性必须是 TLS Client Authentication不然 CloudFront 不认CLI 配置aws cloudfront update-distribution\--idE1EXAMPLE\--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 和 LambdaEdge Origin 触发器用了这些功能的得另想办法。还有如果源站不要求客户端证书CloudFront 不会主动出示连接照常走这个行为是合理的。ALB 侧验证客户端证书ALB 的 mTLS 有两种模式。Passthrough 模式是 ALB 不验证证书把证书链通过 Header 传给后端让后端自己验。Verify 模式是 ALB 用 Trust Store 直接验证通过才放行。我强烈建议用 Verify 模式。Passthrough 把验证逻辑推给后端应用增加复杂度还容易出漏洞。能在基础设施层解决的事别推到应用层。Verify 模式配置创建 Trust Store上传所有授权 CDN 的 CA 证书aws elbv2 create-trust-store\--namecdn-trust-store\--ca-certificates-bundle-s3-bucket my-certs-bucket\--ca-certificates-bundle-s3-key ca-bundle.pem修改 ALB Listener 启用 mTLSaws elbv2 modify-listener\--listener-arn arn:aws:elasticloadbalancing:...\--mutual-authenticationModeverify,TrustStoreArnarn:aws:elasticloadbalancing:...:truststore/cdn-trust-storeALB 在 Verify 模式下会自动注入一些 Header可以用于后端审计和细粒度授权Header内容X-Amzn-Mtls-Clientcert-Serial-Number证书序列号X-Amzn-Mtls-Clientcert-Issuer颁发者X-Amzn-Mtls-Clientcert-Subject主题X-Amzn-Mtls-Clientcert-Validity有效期X-Amzn-Mtls-Clientcert-Leaf叶子证书比如你想区分请求是从 CloudFront 来的还是 Cloudflare 来的看 Issuer 就行。做审计日志的时候也方便。多 CDN 证书管理——运维的大头配完了只是开始证书的日常管理才是真正的考验。ALB Trust Store 支持在一个 CA bundle 文件里放多个 CA 证书只要 CDN 出示的客户端证书是 bundle 中任一 CA 签发的ALB 就放行。不同 CDN 的证书签发方式不一样CDN签发方式CA 证书怎么拿CloudFront自建 Private CA 签发导入 ACMaws acm-pca get-certificate-authority-certificateCloudflareZone-level AOP 用自建 CAGlobal AOP 用 Cloudflare 公共 CAauthenticated_origin_pull_ca.pemAkamaiAkamai-signed 或 Third-party CAControl Center → CDN → mTLS Origin Keystore证书轮换我推荐双 CA 并存策略先把新 CA 加到 bundle 里更新 Trust Store等所有 CDN 节点都切到新证书了再把旧 CA 从 bundle 里移除。整个过程零中断不用停业务。撤销访问更简单从 Trust Store 里移除对应 CDN 的 CA 证书立刻阻断该 CDN 的回源连接。比如你跟某家 CDN 解约了删掉它的 CA 证书就完事了。mTLS 架构下的 DDoS 防护mTLS 方案有个不得不面对的问题源站 ALB 还是暴露在公网上的。虽然只有持合法证书的请求能通过 TLS 握手但 L3/L4 层的网络攻击不需要完成 TLS 握手就能消耗资源。L7 层的攻击HTTP Flood、CC 之类的mTLS 天然免疫——攻击者没有合法的客户端证书和私钥TLS 握手都完不成HTTP 请求根本发不出来。但 L3/L4/L5 层SYN Flood、UDP 反射、TLS 握手洪泛需要 AWS Shield Advanced 来扛。Shield Advanced 在 AWS 网络边缘就把攻击流量清洗掉了ALB 根本感知不到。一个月 $3,000不便宜但高价值业务该花还是得花。两种方案到底怎么选直接看对比mTLSVPC Origin安全性高传输层认证最高网络层隔离多 CDN✅❌ 只认 CloudFront源站公网暴露还是需要公网域名完全没有DDoS 防护L7 天然免疫L3/L4 要 Shield Advanced天然免疫不需要额外防护证书管理要管不需要部署难度中等低兼容性限制不支持 VPC Origin/gRPC/WebSocket不支持 gRPC/LambdaEdge成本mTLS 免费Shield Advanced 可选 $3,000/月无额外费用我的建议是能用 VPC Origin 就用 VPC Origin配置简单安全性最高还不用管证书。只有确实需要多 CDN 的场景才上 mTLS但证书轮换的运维成本你得提前有心理准备。简单画个决策流程用了多家 CDN ├── 是 → mTLS没得选 └── 否 → 只用 CloudFront ├── 是 → VPC Origin最省心 └── 否 → 看看其他 CDN 有没有 mTLS 能力最后说两句源站防护这事儿核心就一句话让 CDN 成为源站的唯一入口在网络层或传输层把非法直连掐死。别在应用层折腾 WAF 规则了越往底层做越靠谱。多 CDN 用 mTLSTLS 握手阶段就验身份伪造不了。纯 CloudFront 用 VPC Origin源站从互联网上消失攻击者连地址都找不到。不管哪种都比双 WAF或者 IP 白名单强太多。安全防护这东西永远是在和攻击者比谁更底层——你在应用层做规则匹配人家在网络层绕过你你在网络层封堵他就更难搞了。把防线往下沉才是正道。
