**发布时间:** 2025-11-24
**厂商:** AWS
**类型:** BLOG
**原始链接:** https://aws.amazon.com/blogs/networking-and-content-delivery/trust-goes-both-ways-amazon-cloudfront-now-supports-viewer-mtls/
---
<!-- AI_TASK_START: AI标题翻译 -->
[新产品/新功能] 双向信任：Amazon CloudFront 现已支持客户端 mTLS 认证
<!-- AI_TASK_END: AI标题翻译 -->
<!-- AI_TASK_START: AI竞争分析 -->
# 产品功能分析
## 新功能/新产品概述
Amazon CloudFront 现已支持 Viewer **mTLS (Mutual Transport Layer Security)** 功能，旨在为全球分布的敏感应用提供增强的客户端身份验证。该功能的核心是实现客户端与 CloudFront CDN 边缘节点之间的双向认证。在标准的 **TLS** 协议中，仅客户端验证服务器身份，而 **mTLS** 要求客户端也必须提供一个有效的数字证书来证明其身份，CloudFront 会在建立连接前对其进行验证。
该功能通过在网络边缘执行身份验证，将安全防护前置，从而阻止未经授权的请求到达源站。其工作原理如下：
1. 客户将其信任的 **证书颁发机构 (CA)** 的证书链（根证书及中间证书）上传至 S3，并配置到 CloudFront 的 **Trust Store** 中。
2. 当客户端（如 IoT 设备、移动应用或 B2B 服务）向 CloudFront 发起连接请求时，在 **TLS 握手** 过程中，CloudFront 会要求客户端出示其证书。
3. CloudFront 使用 **Trust Store** 中配置的 CA 证书来验证客户端证书的有效性和信任链。
4. 只有验证通过的客户端才能成功建立连接并发送请求。
此功能的目标用户群是需要强制执行严格身份验证的行业，如金融服务、医疗保健、物联网和企业级应用，帮助它们构建 **零信任 (Zero-Trust)** 安全架构，并满足 **PCI DSS**、**HIPAA** 等合规性要求。
## 关键客户价值
- **在网络边缘增强安全性**
- 将客户端身份验证从源站前移至 CloudFront 全球边缘节点。这不仅可以提前拦截恶意或未经授权的流量，减轻源站的计算负载和安全压力，还能利用 CloudFront 的全球网络降低身份验证带来的延迟。
- 与在源站实现 mTLS 相比，此方案具备更高的可扩展性和性能，并能有效抵御针对源站的 **DDoS** 攻击。
- **实现精细化的访问控制与零信任**
- 通过强制执行基于密码学的身份证明，从根本上防止了基于凭证（如 API 密钥、密码）被盗用的攻击。
- CloudFront 可以将客户端证书中的信息（如序列号、颁发者、主题等）提取并作为 HTTP 头（`CloudFront-Viewer-Cert-*`）转发给源站或边缘函数（**Lambda@Edge**、**CloudFront Functions**）。这使得后端应用可以基于客户端的身份信息实现更精细的授权逻辑。
- **简化合规性与审计流程**
- 对于金融（**PSD2**）、医疗（**HIPAA**）等受监管行业，**mTLS** 是保障 API 交易和敏感数据交换安全的关键要求。CloudFront 原生支持此功能，简化了客户满足合规性审查的架构复杂性。
- 新增的 **Connection Logs** 提供了 **TLS 握手** 过程的详细日志，记录了每次连接尝试的成功或失败信息，为安全审计和故障排查提供了清晰的追溯路径。
- **提升运营效率与部署灵活性**
- 与 **AWS Private Certificate Authority (PCA)** 无缝集成，简化了私有证书的签发和管理。同时支持客户自带 **CA (BYOCA)**，为拥有现有 **PKI** 体系的企业提供了灵活性。
- 提供 `Required`（强制）和 `Optional`（可选）两种模式。`Optional` 模式允许在同一分发上同时处理 **mTLS** 和非 **mTLS** 流量，便于客户逐步迁移应用，而不会中断现有服务。
## 关键技术洞察
- **可编程的 TLS 握手层**
- 该功能引入了一种新型的边缘计算能力——**Connection Functions**。这是一种在 **TLS 握手** 期间执行的函数，发生在 HTTP 请求处理之前。
- _这是该功能最核心的技术创新点_，它允许开发者在连接建立的瞬间注入自定义逻辑。例如，可以实时查询 **CloudFront KeyValueStore** 中存储的证书吊销列表（CRL），从而在几毫秒内拒绝已被吊销的证书发起的连接。这种方式远比传统的 OCSP 或 CRL 检查更高效、延迟更低。
- **深度集成的 AWS 生态系统**
- 该功能并非孤立存在，而是与多个 AWS 服务深度集成，形成了一套完整的边缘身份管理解决方案。它使用 **S3** 存储 CA 证书包，与 **AWS Private CA** 协同进行证书管理，借助 **CloudFront KeyValueStore** 实现动态策略（如证书吊销），并通过 **CloudWatch** 进行日志记录和监控。这种生态整合降低了客户的实现和运维成本。
- **统一的日志关联标识符**
- 为了便于端到端的追踪和分析，CloudFront 在多种日志（**Connection Logs**、Standard Logs、Real-time Logs）中引入了统一的 `connectionId`。安全或运维团队可以使用此 ID 将一次特定的 **TLS 握手** 尝试（无论成功或失败）与后续的 HTTP 访问请求关联起来，极大地简化了故障排查和安全事件调查的复杂性。
<!-- AI_TASK_END: AI竞争分析 -->
<!-- AI_TASK_START: AI全文翻译 -->
# 信任是双向的：Amazon CloudFront 现已支持查看器 mTLS
**原始链接:** [https://aws.amazon.com/blogs/networking-and-content-delivery/trust-goes-both-ways-amazon-cloudfront-now-supports-viewer-mtls/](https://aws.amazon.com/blogs/networking-and-content-delivery/trust-goes-both-ways-amazon-cloudfront-now-supports-viewer-mtls/)
**发布时间:** 2025-11-24
**厂商:** AWS
**类型:** BLOG
---
从今天开始，Amazon CloudFront 支持从最终用户到 CloudFront 的查看器相互 TLS (mTLS) 身份验证，从而增强了高度分布式和敏感应用程序的安全性。在现代架构中，保护客户端-服务器通信需要的不仅仅是标准的 TLS，而 mTLS 通过强制执行双向身份验证扩展了此模型。这确保了客户端和服务器在交换任何数据之前都会验证彼此的身份。此外，这项新功能在协议级别强制执行精细的访问控制和身份验证，同时简化了受监管环境的审计和合规性。
## mTLS 为 CloudFront 驱动的应用程序带来的好处
mTLS 通过要求通信双方出示并验证数字证书来增加一个额外的安全层，从而创建双向身份验证。因此，mTLS 现已在身份保证、加密通信和法规遵从性是商业信任基础的各个行业中被广泛采用。它提供了身份的加密证明，防止基于凭证的攻击，并在分布式系统中强制执行零信任 (zero-trust) 原则。关键行业用例包括：
**金融服务：** 由 PCI DSS 和 PSD2 等框架强制要求，用于保护银行、支付网关和受信任的第三方 (TTP) 提供商之间的 API 交易。例如，交易平台使用 mTLS 在允许访问市场数据或交易执行端点之前对经纪商或合作机构进行身份验证。
**物联网 (IoT) 和连接设备：** 在设备 (例如游戏机、联网车辆或传感器) 向云端发送遥测数据之前对其进行身份验证，以防止设备欺骗或数据注入。
**企业应用程序：** 在内部微服务之间或企业系统与软件即服务 (SaaS) 平台 (例如人力资源、薪资和分析平台) 之间强制执行身份验证和加密，从而降低横向移动或未经授权的数据访问风险。
**医疗保健：** 通过对交换敏感患者数据的电子健康记录 (EHR) 系统、医疗设备和 API 进行身份验证，保护符合 HIPAA 法规的受保护健康信息 (PHI)。
**电信和媒体：** 保护边缘节点和源服务器之间的控制和内容分发渠道，确保只有受信任的基础设施组件才能交换直播或点播媒体流量。
为了满足这些多样化且严格的安全需求，CloudFront 现已支持查看器 mTLS。组织可以使用此功能在任何请求到达源站之前，直接在边缘对客户端 (例如应用程序、设备或服务) 进行身份验证。此功能将 mTLS 保护从服务到服务的流量扩展到面向用户的场景，使企业能够以最小的延迟在全球范围内强制执行客户端证书验证。查看器 mTLS 与 CloudFront 信任存储区 (Trust Store) 无缝集成，客户可以使用 Amazon Web Services (AWS) Private Certificate Authority 或自带 CA 来实施精细的身份验证策略、自动化证书配置并实现合规性，而无需增加运营复杂性。
## 入门指南
要为 CloudFront 分配实施 mTLS 身份验证，首先需要设置一个私有证书颁发机构并创建客户端证书。配置过程包括收集根证书颁发机构和任何中间证书颁发机构的 PEM 文件格式的公钥证书。然后，需要将这些证书文件上传到 Amazon S3 存储桶，该存储桶将作为身份验证过程中使用的信任存储区的来源。
在本例中，我们演示了如何使用 OpenSSL 创建私有证书颁发机构和客户端证书。或者，也可以使用 AWS Certificate Manager Private CA (一个完全托管的服务) 来简化此过程。有关更多详细信息，请查看 AWS Private CA 文档。
首先，按照以下步骤使用 OpenSSL 创建一个新的证书颁发机构：
1. 生成私有 CA 的私钥和证书：
```bash
# 生成 CA 私钥
openssl genrsa -out Root_CA.key 4096
# 创建 CA 证书
openssl req -new -x509 -days 3650 -key Root_CA.key -out Root_CA.pem
```
a. 在证书创建过程中，系统会提示您为证书的可分辨名称 (DN) 字段提供信息。
b. (可选) 您可以创建由根 CA 签名的中间证书颁发机构。CloudFront 支持最多 4 层深度的证书链 (例如用于 mTLS 身份验证的根证书)。您必须将根 CA 和中间 CA 证书合并到一个 PEM 包 (CA 证书包) 中。使用 `cat` 命令构建 CA 证书包文件：
```bash
# 创建 CA 证书包
cat Root_CA.pem Intermediate_CA.pem > Trust_store_bundle.pem
```
2. 建立 CA 层次结构后，生成客户端证书的私钥和证书签名请求 (CSR)：
```bash
# 生成客户端证书私钥
openssl genrsa -out my_client.key 2048
# 创建 CSR
openssl req -new -key my_client.key -out my_client.csr
```
a. 输入客户端证书的主题名称、地区、组织和组织单位属性。将可选的密码质询留空。
3. 使用先前创建的根 CA 签署客户端证书：
```bash
# 使用您的根 CA 签署客户端 CSR
openssl x509 -req \
-in my_client.csr \
-CA Root_CA.pem \
-CAkey Root_CA.key \
-set_serial 01 \
-out my_client.pem \
-days 3650 \
-sha256
```
4. 完成这些步骤后，您的目录中应包含以下文件：
## 设置信任存储区
以下部分概述了如何设置信任存储区。
## 先决条件
您必须将来自证书颁发机构的根 CA 证书或 CA 证书包 (PEM 文件) 上传到 S3 存储桶。如果您已完成上一部分，那么您应该已经创建了需要上传到 S3 存储桶的 `Root_CA.pem` 文件。
1. 在 CloudFront 控制台中，选择左侧菜单中 **安全** 下的 **信任存储区**。选择 **创建信任存储区**。
Amazon CloudFront 中的信任存储区
2. 在此页面上指定 S3 存储桶位置。选择 **创建信任存储区**。CA 证书包将被读取一次并存储在 CloudFront 上。
在 Amazon CloudFront 中创建信任存储区
3. 创建信任存储区后，控制台会将您带到信任存储区详细信息页面。在此页面上，您可以通过选择 **关联到分配** 按钮将信任存储区关联到分配。
在 Amazon CloudFront 分配中成功创建信任存储区
4. 在此页面上，您可以选择要将信任存储区关联到的分配。
将信任存储区关联到 Amazon CloudFront 分配
或者，您也可以通过分配设置来关联信任存储区。
## 设置分配
**先决条件**
您必须有一个已启用 **仅 HTTPS** 查看器协议的现有 CloudFront 分配。
1. 要为查看器启用 mTLS 身份验证，请导航到 **分配设置** 并将 **查看器相互身份验证 (mTLS)** 设置切换为 **开启**。
在 CloudFront 分配中启用 mTLS
2. 为您的用例选择适当的 mTLS 参数。
**模式**
CloudFront 的 mTLS 提供 **必需** 模式 (所有客户端都必须出示有效证书) 和 **可选** 模式 (允许混合身份验证，在同一分配上接受 mTLS 和非 mTLS 客户端，但仍会拒绝无效证书)。
**信任存储区**
启用查看器 mTLS 身份验证后，选择您先前创建的信任存储区以将其与分配关联。
有两个可选参数，默认值均为 false：
**忽略证书过期日期**：如果此项为 true，则 CloudFront 会接受来自查看器的连接，即使客户端证书链中的一个或多个证书未通过 X509 时间验证 (当前时间早于 NotBefore 或晚于 NotAfter)。其他 X509 证书验证仍会应用。客户端证书必须在链中向上签名至 CA 证书包中的一个受信任证书。
**通告信任存储区 CA 名称**：如果此项为 true，则 CloudFront 会向查看器通告该分配接受的证书颁发机构名称列表。这是信任存储区中证书可分辨名称 (DN) 的列表。
**连接函数** (可选)：
连接函数 (Connection functions) 是对查看器 mTLS 的可选增强。它们使您能够在 mTLS 握手过程中执行自定义验证，从而允许、拒绝或记录有关连接的信息。在后面的部分中，我们将演示一个如何在您的 CloudFront 分配中使用连接函数的示例。
## CloudFront 查看器证书标头
CloudFront 可以从客户端证书中提取信息，并将其作为 HTTP 标头添加到查看器请求中。然后，您可以将这些标头用作缓存键 (cache key) 的一部分和/或将其转发到您的源服务器。您还可以在 CloudFront Functions 或 AWS Lambda@Edge 中处理查看器请求时读取这些标头。
CloudFront 查看器证书标头包括：
- `CloudFront-Viewer-Cert-Serial-Number`
- `CloudFront-Viewer-Cert-Issuer`
- `CloudFront-Viewer-Cert-Subject`
- `CloudFront-Viewer-Cert-Validity`
- `CloudFront-Viewer-Cert-PEM`
- `CloudFront-Viewer-Cert-Present`
- `CloudFront-Viewer-Cert-SHA256`
有关更多详细信息，请参阅 CloudFront 文档。
## 测试 mTLS 身份验证
要测试您的 mTLS 配置，请使用 `curl` 和您的客户端证书。以下是成功和被拒绝场景的示例：
```bash
curl --key my_client.key \
--cert my_client.pem \
https://dxxxxxxxxxxxxx.cloudfront.net
```
- `–key`：指定您的客户端私钥文件。
- `–cert`：指定您的客户端证书文件。
- 将 `dxxxxxxxxxxxxx.cloudfront.net` 替换为您已启用 mTLS 的实际 CloudFront 分配域名。
1. **成功身份验证示例 (使用有效客户端证书)**：
```bash
HTTP/2 200
content-type: text/html; charset=UTF-8
content-length:xxx
date: xxx
...
```
**2. 拒绝身份验证示例 (使用无效或缺失的证书)**：
```bash
* Request completely sent off
* Closing connection
* Recv failure: Connection reset by peer
* Send failure: Broken pipe
curl: (16) Recv failure: Connection reset by peer
```
以下步骤将引导您了解 CloudFront 中 mTLS 身份验证的整个过程，如下图所示。
Amazon CloudFront 中的 mTLS 身份验证
1. 将您的 CA 证书包上传到 S3 存储桶。
2. 创建信任存储区并提供 CA 证书包的 Amazon S3 路径。
3. 客户端与 CloudFront 发起 TLS 会话。在 TLS 握手期间，客户端出示 TLS 证书。
4. CloudFront 验证客户端证书，并建立 mTLS 会话。
4a. (可选) 您可以在 TLS 握手期间通过挂钩运行连接函数。您可以从客户端证书中提取信息，并根据自定义逻辑拒绝来自具有无效证书的客户端的连接。
5. (可选) 可以触发查看器请求边缘函数来执行 CloudFront Functions。您可以通过 `cloudfront-viewer-cert*` 标头从客户端证书中提取信息。
6. 如果您在源请求策略中启用了 `cloudfront-viewer-cert*` 标头，则 CloudFront 会将客户端证书信息转发到您的源服务器。这些标头会根据您配置的源请求策略发送。
CloudFront 通过连接函数 (在 TLS 握手期间执行) 和查看器请求边缘函数 (在握手完成后运行) 来实现自定义身份验证和安全控制，以实施基于证书的验证。有关更多详细信息，请参阅 CloudFront 文档。
## 使用连接日志进行监控
CloudFront 生成详细的连接日志 (connection logs)，捕获有关 TLS 握手的关键信息。
您可以使用连接日志执行以下操作：
- 监控和排查启用了 mTLS 的分配
- 跟踪成功的 mTLS 连接和客户端证书
- 深入了解失败的 TLS 握手
此外，连接函数允许您向连接日志中添加自定义日志数据。要添加自定义数据，请使用连接函数连接对象上可用的 `logCustomData` 辅助方法。您可以将任何最长 800 字节的有效 UTF-8 字符串记录到 `connectionLogCustomData` 字段中。
与访问日志类似，CloudFront 通过 CloudWatch 提供的日志 (CloudWatch vended logs) 交付连接日志，提供以下功能：
- 将连接日志发送到 CloudWatch Logs、Amazon Data Firehose 和 Amazon S3。
- 选择其他输出日志文件格式，例如 JSON、w3c 和 Parquet (仅限 Amazon S3)。
每个 mTLS 连接都会生成一个唯一的标识符 `connectionId`，该标识符会记录在所有 CloudFront 日志类型中：连接日志、标准日志和实时日志 (Real-time logs)。您可以使用此统一标识符来调查和关联连接日志和访问日志中的访问模式。例如，您可以使用 `connectionId` 来跟踪特定请求，从而使故障排除和分析更加高效。有关更多详细信息，请参阅 CloudFront 文档。
## 使用连接函数和 CloudFront KeyValueStore 进行证书吊销验证
在 mTLS 身份验证中，即使证书在其有效期内，也可能因被盗或泄露而被吊销。您可以将 CloudFront 连接函数与 CloudFront KeyValueStore 结合使用，以实现实时的证书吊销检查。
**准备 CloudFront KeyValueStore**
首先，创建一个 KeyValueStore 来存储已吊销证书的序列号。
1. 在 CloudFront 控制台中，选择左侧菜单下的 **函数**。然后，打开顶部的 **KeyValueStores** 选项卡，并选择 **创建 KeyValueStore**。
创建 KeyValueStore
2. 为您的 KeyValueStore 提供一个名称，然后选择 **创建**。如果需要，您还可以从 Amazon S3 导入数据。
3. 选择已创建的 KeyValueStore，然后在 **键值对** 下选择 **编辑**，以输入已吊销证书的序列号。
4. 选择 **保存更改** 以保存您的条目。
**创建连接函数**
创建一个连接函数来检查证书序列号：
1. 在 CloudFront 控制台中，选择左侧菜单下的 **函数**。然后，选择顶部的 **连接函数** 选项卡，并选择 **创建连接函数**。
创建连接函数
2. 为您的函数提供一个名称，然后选择 **创建**。
创建 KeyValueStore
3. 在 **关联的 KeyValueStore** 下，选择 **关联现有 KeyValueStore** 并关联之前创建的 KeyValueStore。
4. 将以下代码粘贴到 **函数代码** 中，然后选择 **保存更改** 按钮。
5. 为您的函数提供一个名称，然后选择 **创建**。
6. 在 **关联的 KeyValueStore** 下，选择 **关联现有 KeyValueStore** 并关联您之前创建的 KeyValueStore。
```javascript
import cf from 'cloudfront';
async function connectionHandler(connection) {
const kvsHandle = cf.kvs();
// 获取证书序列号
const serialNumber = connection.clientCertificate.certificates.leaf.serialNumber.replace(/:/g, "");
// 在 KVS 中检查吊销状态
const isRevoked = await kvsHandle.exists(serialNumber);
if (isRevoked) {
// 拒绝已吊销证书的连接
connection.logCustomData(`Revoked certificate: ${serialNumber}`);
console.log(`Denying connection for revoked certificate: ${serialNumber}`);
return connection.deny();
}
// 允许有效证书的连接
connection.logCustomData(`Valid certificate: ${serialNumber}`);
console.log(`Allowing connection for valid certificate: ${serialNumber}`);
return connection.allow();
}
```
7. 在 **测试** 选项卡中，您可以测试该函数。输入证书信息和您添加到 KeyValueStore 的序列号，如下图所示。然后，选择 **测试函数** 以确认证书已被正确吊销。
测试函数
8. 在 **发布** 选项卡中，选择 **发布连接函数**。
9. 在 **关联的分配** 下，选择 **添加关联**，选择要与该函数关联的分配，然后选择 **关联**。
**测试和验证**
使用已吊销的证书进行测试，以确认连接被拒绝：
`# 使用已吊销的证书进行测试 (连接应被拒绝)
# 注意：请替换为您的实际 CloudFront 分配域名
curl --key revoked_client.key \
--cert revoked_client.pem \
<https://dxxxxxxxxxxxxx.cloudfront.net>
# 使用有效的证书进行测试 (连接应被允许)
curl --key valid_client.key \
--cert valid_client.pem \
https://dxxxxxxxxxxxxx.cloudfront.net`
## 结论
互联网上的安全始终关乎信任。通过 mTLS，每个连接的两端身份都会得到验证。现在，您可以通过 Amazon CloudFront 使用查看器 mTLS 在全球范围内进行部署和运营。您可以精确决定谁或什么可以与您的应用程序通信，而不会降低任何速度。
立即在您的 CloudFront 分配中开启查看器 mTLS，或查看 AWS 文档以了解如何将相互身份验证引入您的边缘。
### Sagar Desarda
Sagar Desarda 是数据、分析和生成式 AI (Generative AI) ISV 的技术客户经理 (TAM) 和业务发展 (BD) 组织负责人。Sagar 的团队与客户合作，优化其 AWS 架构，确保其关键业务应用程序的无缝运行，加速采用，并推动在北美的市场进入成功。此外，Sagar 还担任美洲区边缘网络服务专家团队的负责人，负责推动新业务增长、促进技术交流并撰写面向客户的出版物。
### Tomoya Kudo
Tomoya Kudo 是一名常驻东京的原型工程师。他的主要工作重点是通过提出基于最佳实践的解决方案和开发原型来帮助客户取得成功，以确保项目成功。
### Yutaka Oka
Yutaka Oka 是一名常驻东京的高级边缘专家解决方案架构师。他的主要工作重点是帮助客户使用 AWS 边缘服务优化和保护内容交付。
<!-- AI_TASK_END: AI全文翻译 -->