CloudFront是AWS最常用的全球CDN服务，它把内容缓存到全球数百个边缘节点，用户请求会在离自己最近的PoP被处理。这个架构带来了性能优势，同时也意味着分发域名直接暴露在公网，成为攻击流量的第一道入口。如果只做默认配置就上线，很容易被CC攻击打穿回源，或者被恶意扫描器摸清源站地址。这篇文章从WAF规则、Shield防护和日志监控三个维度，结合一些容易被忽视的配置细节，聊聊CloudFront的安全加固该怎么做。
一、用AWS WAF为CloudFront构建应用层防线
WAF应该挂在CloudFront分发上，而不是挂在源站的负载均衡器上。原因是WAF for CloudFront按请求次数计费且在全球边缘执行，攻击流量在边缘就被拦截，根本不会消耗源站的计算资源和回源带宽。如果WAF挂在ALB上，攻击请求虽然也会被拦，但流量已经穿过了CloudFront到源站VPC的链路，回源带宽费用照样产生。
配置WAF时建议先启用AWS托管规则组（Managed Rule Groups），这是性价比最高的起步方案。核心规则组（CoreRuleSet）覆盖了OWASP Top 10的常见攻击，包括SQL注入、XSS、路径遍历、LFI等；已知恶意IP规则组（KnownMaliciousIPList）会自动更新威胁情报；机器人控制规则组（BotControl）则能识别验证过的爬虫和自动化工具。托管规则的优点是不需要自己维护特征库，AWS安全团队持续更新规则内容。
{
"Name": "CloudFront-WebACL",
"DefaultAction": { "Allow": {} },
"Rules": [
{
"Name": "AWS-AWSManagedRulesCommonRuleSet",
"Priority": 0,
"Statement": {
"ManagedRuleGroupStatement": {
"VendorName": "AWS",
"Name": "AWSManagedRulesCommonRuleSet",
"ExcludedRules": [
{ "Name": "SizeRestrictions_QUERYSTRING" }
]
}
},
"OverrideAction": { "None": {} },
"VisibilityConfig": {
"SampledRequestsEnabled": true,
"CloudWatchMetricsEnabled": true,
"MetricName": "CoreRuleSet"
}
},
{
"Name": "RateLimit-Per-IP",
"Priority": 1,
"Statement": {
"RateBasedStatement": {
"Limit": 2000,
"AggregateKeyType": "IP"
}
},
"Action": { "Block": {} },
"VisibilityConfig": {
"SampledRequestsEnabled": true,
"CloudWatchMetricsEnabled": true,
"MetricName": "RateLimitPerIP"
}
}
],
"VisibilityConfig": {
"SampledRequestsEnabled": true,
"CloudWatchMetricsEnabled": true,
"MetricName": "CloudFrontWebACL"
}
}上面的JSON定义了一个Web ACL，包含托管核心规则组和一条基于IP的速率限制规则。RateBasedStatement中的Limit设为2000，表示任意单个IP在五分钟窗口内超过2000次请求就触发拦截。这个阈值要根据业务实际流量来定，电商大促场景可能要放宽到5000以上，否则会误伤共用出口IP的企业用户。
托管规则不是万能的，误报是常见问题。比如某些业务参数里合法包含HTML片段，会被XSS规则命中。处理方式是先用Count模式上线观察，通过WAF控制台的Sampled Requests确认误报情况，再用ExcludedRules排除特定规则，或者用ScopeDownStatement缩小规则匹配范围。切忌一发现误报就整个关掉规则组，这样会留下大片防护真空。
自定义规则方面，有几条实践值得做：限制请求的URI前缀只允许已知路径、拒绝没有合法Host头的请求、对后台路径（比如/admin）按源IP做白名单。还可以结合WAF的BotControl和CAPTCHA Action，对可疑的自动化流量弹出验证码，在人机识别和用户体验之间取得平衡。
二、Shield Standard与Advanced：免费的兜底和付费的精细化
AWS Shield是针对DDoS的托管防护服务，分为Standard和Advanced两层。Shield Standard对所有CloudFront分发自动启用，免费提供L3/L4层的基础防护，依托AWS全球网络的流量清洗能力，常见的SYN Flood、UDP反射攻击在边缘就被吸收掉。对大多数业务来说，这一层已经够用。
Shield Advanced是付费选项，每月3000美元起加上数据传输费，换来的是三样关键能力：第一，针对L7攻击的自动缓解，可以和WAF联动自动插入缓解规则；第二，DDoS响应团队（SRT）的支持，遭遇大规模攻击时AWS专家直接介入；第三，DDoS成本保护，攻击导致的弹性IP、CloudFront费用飙升可以申请费用豁免。此外还有健康的费用报销，攻击期间为了缓解而扩容的资源开销也在保障范围内。
什么场景值得买Advanced？判断标准不是流量大小，而是业务对可用性的敏感度和攻击面暴露程度。在线游戏、金融交易、SaaS核心API这类一旦被攻击就有直接营收损失的业务，Advanced的保费是划算的。而普通的官网、内容站，Standard配合WAF速率限制通常足够。购买Advanced后记得配置Health Checks，把关键端点纳入自动缓解的检测范围，否则Advanced的部分能力不会主动触发。
还有一个细节需要注意：Shield Advanced要求保护对象关联到WAF Web ACL才能获得完整的L7防护，所以即便买了Advanced，WAF配置仍然不能省。两者的关系是Shield管体积流量型攻击，WAF管应用层内容型攻击，缺一不可。
三、日志与监控：没有可观测性就没有安全
安全配置做完不等于万事大吉，你需要知道每天有哪些请求被拦截、拦截规则是否误伤、有没有绕过CloudFront直连源站的请求。CloudFront相关日志有三条链路，各自承担不同角色。
第一条是标准日志（Standard Logs），在CloudFront分发配置里开启后，日志以gzip压缩格式投递到指定的S3桶。日志不是实时的，通常延迟几十分钟到几小时，适合做离线分析和长期审计。日志记录包含客户端IP、请求URI、状态码、边缘节点位置、缓存命中状态等几十个字段，是分析攻击来源的基础数据。注意要给日志桶配置合理的生命周期策略，比如热数据保留90天，之后归档到Glacier，避免存储费用失控。
第二条是实时日志（Real-Time Logs），日志流直接推送到Kinesis Data Streams，延迟控制在秒级。对于需要实时响应的场景，比如检测到恶意IP后立刻通过Lambda更新WAF规则形成自动封禁闭环，实时日志是唯一选择。代价是成本明显高于标准日志，建议只对关键分发或关键路径开启，并且用Fields参数指定只采集需要的字段，而不是全量字段。
aws cloudfront create-realtime-log-config \
--name "cloudfront-rt-log" \
--sampling-rate 100 \
--fields '[{"Name":"timestamp"},{"Name":"c-ip"},{"Name":"cs-method"},{"Name":"cs-uri-stem"},{"Name":"sc-status"}]' \
--endpoints '[{"StreamType":"Kinesis","KinesisStreamConfig":{"RoleARN":"arn:aws:iam::123456789012:role/CloudFrontRealtimeLogRole","StreamARN":"arn:aws:kinesis:us-east-1:123456789012:stream/cloudfront-logs"}}]' \
--region us-east-1第三条是CloudTrail，记录的是API操作而不是用户请求，比如谁修改了分发配置、谁改了WAF规则。安全审计和变更追溯依赖这条链路。建议开启CloudTrail的数据事件记录，覆盖CloudFront的分发资源，同时把Trail指向集中管理的日志账号。
监控告警层面，CloudWatch有几个关键指标要配报警：ErrorRate（5xx占比异常升高可能意味着源站故障或被攻击）、CacheHitRate（命中率骤降警惕缓存穿透式攻击）、WAF的BlockedRequests指标。更进阶的做法是在实时日志流上接Lambda或OpenSearch，对单IP高频404扫描、异常User-Agent分布做实时检测，检测到威胁后调用WAF API注入临时封禁规则IP Set，实现攻击自动处置。
四、容易被忽视的配置细节
除了WAF和Shield，CloudFront本身还有一些安全开关值得逐项检查。首先是源站保护，用Origin Access Control（OAC）替代旧的OAI，把S3源站设置为只允许CloudFront访问，桶策略显式拒绝其他来源，防止有人拿到桶的URL直接绕过CDN。对于ALB源站，配合AWS WAF或者安全组里放行CloudFront的托管前缀列表，避免源站IP被扫出来直接打。
其次是TLS配置。Viewer端建议只保留TLSv1.2及以上，禁用旧的TLSv1.0和1.1，安全策略选择SecurityPolicyAll（对应TLSv1.2的全套套件）而不是包含弱加密套件的默认值。Origin端如果源站支持，走HTTPS回源并开启Origin SSL。再配合Default Behavior里的Viewer Protocol Policy设为Redirect HTTP to HTTPS，强制全站加密。
然后是响应头和缓存控制。通过Response Headers Policy注入严格的安全头，包括Content-Security-Policy、Strict-Transport-Security、X-Content-Type-Options。对于API类行为，一定要在Cache Policy里禁用QueryString和Cookie的透传缓存，或者干脆对API路径用CachingDisabled策略，避免敏感数据被缓存在边缘节点上被别人取走。涉及特别敏感的字段（如API Key），可以用Field-Level Encryption在边缘就用公钥加密，源站只有拿到私钥才能解密。
最后是压缩和签名URL的使用。私有内容用Signed URL或Signed Cookies做访问控制，注意轮换密钥对，并设置合理的过期时间。公网完全公开的静态资源则应该确保Bucket List权限关闭，配合WAF拦截常见的路径探测请求。
总结
CloudFront的安全不是单一产品能解决的，而是分层的组合拳：Shield Standard在L3/L4吸收体积型攻击，WAF在L7拦截应用层威胁，日志链路提供可观测性和自动响应能力，再加上OAC、TLS策略、安全头这些细节配置兜底。落地顺序上建议先开WAF的Count模式观察一周，同时把标准日志和CloudWatch告警跑起来，有了数据支撑再逐步收紧规则、引入实时日志和自动封禁闭环，最后根据业务重要性评估是否需要Shield Advanced。安全是持续运营的过程，定期回看拦截数据和误报样本，比一次性配置到位更重要。
AWS CloudFrontCloudFront安全AWS WAF修改时间：2026-09-04 16:25:07