在传统的Web安全模型中，HTTPS被认为是对抗中间人攻击的银弹。但现实情况是，数据一旦离开TLS隧道到达源站，就会以明文形式被Web服务器、应用日志、APM监控工具完整记录下来。如果源站被攻破，或者运维人员误将包含表单数据的访问日志上传到公开的存储桶，用户的身份证号、银行卡信息就会直接泄露。AWS CloudFront的Field-Level Encryption（字段级加密）正是为了解决这个信任边界问题而设计的：它在CloudFront边缘节点上，使用你预先上传的RSA公钥，对POST表单中的指定字段进行二次加密，敏感数据在到达源站之前就已经变成了只有持有私钥的一方才能解开的密文。
Field-Level Encryption的工作原理与安全模型
要理解字段级加密的价值，首先要弄清楚它的加密发生在链路的哪个位置。普通的HTTPS加密保护的是“浏览器到CloudFront边缘节点”这一段，字段级加密则更进一步，保护的是“浏览器到最终持有私钥的应用”这一整段。数据到达边缘节点后，CloudFront会解析POST请求体（仅支持application/x-www-form-urlencoded格式），找到配置文件中指定的字段名，用对应的公钥对这些字段的值执行RSA-OAEP加密，然后把加密结果以新的字段名放回请求体，再转发给源站。
整个安全模型基于非对称加密。你生成一个2048位的RSA密钥对，公钥上传给CloudFront，私钥保存在最终需要读取数据的可信系统里（比如支付后台的加密机或KMS）。CloudFront拿到的是公钥，它自己也无法解密数据，这意味着即使AWS内部的转发链路被审计，看到的也只是密文。源站应用收到请求后，提取密文字段，用私钥解密出明文。需要注意的是，一个公钥最多可以配置对同一表单中的多个字段加密，且每个请求体最大支持加密后总体不超过一定的体积限制，超出会导致请求失败。
这个设计的一个隐含前提是：你需要读取敏感数据的系统和接收表单的Web前端可以不是同一台服务器。典型的架构是前端Web服务器只负责收表单，加密字段它自己解不开，只有后端核心业务系统持有私钥。这样即使前端服务器被入侵，攻击者拿到的也只是密文，攻击面被大幅压缩。
生成密钥对并在CloudFront中配置字段级加密Profile
第一步是生成RSA密钥对。使用OpenSSL命令可以快速完成：
# 生成2048位RSA私钥 openssl genrsa -out private_key.pem 2048 # 从私钥导出公钥 openssl rsa -in private_key.pem -pubout -out public_key.pem # 查看公钥内容（上传时需要粘贴这个） cat public_key.pem
私钥务必妥善保管，建议放入AWS KMS加密存储或离线保存，绝对不要提交到代码仓库。拿到公钥后，进入CloudFront控制台，在左侧菜单找到Security下面的Field-level encryption，先创建一个Public key，把public_key.pem的完整内容粘贴进去；接着创建Field-level encryption profile，选择刚创建的公钥，并指定Provider name（这个名称会出现在加密后的数据结构中，便于解密方识别）。最后创建Field-level encryption configuration，在configuration里定义字段匹配规则。
字段匹配规则支持精确匹配和前缀匹配两种模式。比如你的表单里有字段id-card-number、bank-card-number，可以用通配符形式的模式匹配所有以sensitive-开头的字段。配置中还涉及一个重要选项：当请求体中找不到匹配字段时如何处理，是原样转发还是直接拒绝请求（返回4xx错误）。对于合规要求严格的场景，建议设置为强制模式，防止敏感字段因为字段名拼写错误而绕过加密。
创建完成后，需要把configuration关联到Cache Behavior上才会生效。在Distribution的Behavior设置中，找到Field-level encryption Config选项，选择刚才创建的configuration，保存后等待Distribution部署完成。整个过程通常需要几分钟生效。
源站如何用私钥解密加密字段
CloudFront加密后的请求体不再是普通的urlencoded格式，而是一个JSON结构。以PHP为例，解密的核心代码如下：
<?php
// CloudFront加密后转发的Content-Type是application/json
$raw = file_get_contents('php://input');
$data = json_decode($raw, true);
// 遍历加密的字段，结构为 [字段名 => [provider => ..., keyid => ..., oaep-hash-alg => ..., encrypted-data => base64密文]]
$privateKey = openssl_pkey_get_private(file_get_contents('/secure/private_key.pem'));
foreach ($data as $field => $info) {
if (isset($info['encrypted-data'])) {
$cipher = base64_decode($info['encrypted-data']);
// 使用SHA-256作为OAEP的hash算法（与CloudFront配置一致）
openssl_private_decrypt($cipher, $plain, $privateKey, OPENSSL_PKCS1_OAEP_PADDING | OPENSSL_ALGO_SHA256);
echo $field . ' = ' . $plain . PHP_EOL;
}
}
有两个细节容易踩坑。第一，RSA加密的OAEP填充算法必须与CloudFront profile中配置的一致，profile里选的是SHA-256，解密时也要指定SHA-256，否则会解密失败且报错信息并不直观。第二，由于RSA加密后的密文体积会膨胀（2048位密钥加密后单字段密文约256字节，再Base64编码约344字节），如果表单中加密字段很多，要注意源站的post_max_size等配置。对于Java技术栈，可以使用Cipher类的RSA/ECB/OAEPWithSHA-256AndMGF1Padding变换来完成同样的解密操作。
还有一个架构上的实践建议：不要把解密逻辑放在接收请求的Web层，而是封装成独立的内部服务。Web层收到请求后直接把密文投递到消息队列，由持有私钥的下游服务解密处理。这样私钥的暴露范围被限制在最小，符合最小权限原则。
使用限制与典型适用场景分析
字段级加密并非万能方案，它有几个硬性限制需要评估。其一，只支持POST方法且Content-Type必须为application/x-www-form-urlencoded，前后端分离项目中常见的JSON请求体不在支持范围内，这类场景需要改用浏览器端JS加密（比如Web Crypto API）配合服务端解密。其二，加密会增加请求体体积和边缘处理耗时，官方文档建议单请求加密字段的总数据量控制在16KB以内。其三，开启后CloudFront无法再对该请求做正文层面的处理，某些依赖请求体重写的功能会受影响。
它的最佳适用场景是传统的HTML表单提交，尤其是金融、医疗、政务类网站的用户注册、实名认证、支付信息采集等环节。举个例子，一个医疗问诊网站的患者信息表单包含姓名、症状描述和医保卡号，前两项是普通数据需要入库检索，只有医保卡号是高敏数据。通过字段级加密，可以为医保卡号单独配置加密规则，其他字段保持明文，实现精细化的分级保护——这也是“字段级”这个词的真正含义。
从成本角度对比：如果选择全链路的端到端加密方案，需要对前端代码做较大改造；而字段级加密对前端完全透明，开发者不需要修改任何表单代码，只在CloudFront层做配置即可，属于侵入性极低的加固手段。综合来看，当你的系统需要满足PCI-DSS、个人信息保护相关的合规要求，或者希望缩小敏感数据的明文暴露范围时，CloudFront Field-Level Encryption是一个值得纳入方案的安全组件。
CloudFrontField-Level Encryption字段级加密修改时间：2026-09-15 21:56:42