Amazon CloudFront最近新增了对源站服务器双向 TLS 认证的支持，完成了从浏览者（viewer）经由 CloudFront 到后端基础设施的端到端零信任认证。CDN 服务在 2025 年 11 月就已经添加了浏览者mTLS，但 CloudFront 到源站的请求仍需要客户使用共享密钥或 IP 白名单构建自定义的认证方案。
启用源站mTLS后，CloudFront 在连接源站服务器时会出示客户端证书，源站服务器则验证 CloudFront 的身份后才接受请求。这种基于密码学的认证方式取代了维护 IP 白名单或轮换共享密钥头的运维开销。
Reddit 的用户 J‑4ce指出，这种方案对多云与混合部署场景的价值尤为明显：
这是保护本地或其他云环境中源站的杀手级应用之一，无需引入 VPN 即可实现安全访问。随着 CloudFront 新增的源站 mTLS，这一能力会更进一步：源站可以通过密码学验证流量确实来自 CloudFront，取代 IP 白名单和密钥头信息，实现真正的零信任身份验证。
该认证机制使用带有 clientAuth 扩展密钥的 X.509v3 证书。CloudFront 在 TLS 握手过程中出示自身客户端的证书，同时验证源站的服务端证书，形成双向校验，双方都不依赖隐式信任。客户可以使用 AWS 专用证书管理器（AWS Private CA）的证书（支持自动化生命周期管理与续期通知），也可以通过 AWS Certificate Manager（ACM）导入第三方私有 CA 的证书。
J‑4ce 同时在 Reddit 上强调，最佳实践是使用 AWS Private CA 并开启自动化轮换，而不是使用长期的静态证书：
关于证书：它们确实可以长期有效，但最佳实践恰恰相反，我们应该使用 AWS Private CA 并自动轮换，这样就不会出现泄露“永久密钥”，导致安全范围全面失控的情况出现。
我们需要在源站级别进行配置，允许同一个 distribution 的不同后端使用不同的安全策略。设置需要通过 ACM 在 US East 地区获取客户端证书，配置源站服务器验证客户端证书，并通过控制台、CLI、SDK、CDK 或 CloudFormation 在 CloudFront 源站设置中启用 mTLS。
该功能填补了 CDN 架构中的一个空白。虽然客户端 mTLS 在流量进入网络边界之前对客户端进行了身份验证，但攻击者如果发现了源站的 IP 地址，就可以绕过 CloudFront 直接连接到后端服务器。组织之前需要维护 CloudFront 边缘位置的 IP 允许列表，或者需要实现边缘和源站协调的自定义认证头信息。
Cloudflare 早在 2014 年就提供了认证的源站拉取，但它们有一个区别。Cloudflare 的共享证书证明请求来自 Cloudflare 网络，不是来自特定客户的区域。Cloudflare 客户必须上传自定义证书以实现真正的隔离，而 CloudFront 的方法默认提供了这种隔离。
对性能的影响主要集中在连接建立阶段，而不是数据传输阶段。每次 mTLS 握手都会增加加密操作，但 CloudFront 的连接池将这种开销分散到许多请求上。由于 CloudFront 在边缘位置缓存大部分流量，大多数请求根本不会到达源站。AWS 指出，TLS 1.3 更快的握手机制使得认证开销对于医疗保健、金融服务和政府部门等受监管工作负载来说是有利的，在这些领域中，明确的认证和审计跟踪是强制性的。
最后，源站 mTLS 不收取额外费用，已经包含在 CloudFront 商业版与高级版的统一定价套餐中。
原文链接：
CloudFront Adds Origin mTLS Authentication for End-to-End Zero Trust
