CloudFront与WAF集成后，ACL规则在边缘节点对请求进行判定，只有通过规则的流量才会继续回源或命中缓存。这种架构让防御措施不再依赖应用服务器逐一处理恶意请求，尤其适合应对OWASP Top 10中依赖高频探测或畸形Payload的攻击类型。无论是针对SQL注入的联合查询片段，还是利用路径穿越读取敏感文件，WAF都可以在请求到达源站前将其拦截。
CloudFront与WAF集成的架构基础：边缘节点上的ACL
要在CloudFront上启用WAF，首先需要理解Web ACL的作用域。AWS WAF v2将Web ACL分为区域性资源与全球资源，CloudFront对应的作用域固定为 CLOUDFRONT，这意味着Web ACL必须创建在美东一区弗吉尼亚北部，但规则会自动同步到所有边缘站点。关联方式也很简单，既可以通过CloudFront分配的AWS WAF配置项选择已有Web ACL，也可以通过API或CloudFormation把Web ACL的ARN绑定到CloudFront分配。一旦关联成功，每个请求都会先经过WAF规则评估，再进入CloudFront的缓存逻辑或回源流程。
ACL规则在WAF中的执行顺序由优先级数字决定，数字越小越先评估。如果请求命中某条规则的Action为Block，后续规则不会再执行；如果Action为Count，则只计数不拦截，适合灰度观察。Web ACL的默认动作可以是Allow或Block，当没有任何规则命中时按默认动作处理。每条规则会消耗Web ACL容量单元，CloudFront作用域的Web ACL默认容量上限为1500 WCU，托管规则组和速率规则会占用较多容量，设计规则时需要提前规划。
{
"Name": "cloudfront-owasp-acl",
"Scope": "CLOUDFRONT",
"DefaultAction": { "Allow": {} },
"Rules": [
{
"Name": "block-sql-injection",
"Priority": 1,
"Statement": {
"SqliMatchStatement": {
"FieldToMatch": { "UriPath": {} },
"TextTransformations": [
{ "Priority": 0, "Type": "URL_DECODE" }
],
"SensitivityLevel": "HIGH"
}
},
"Action": { "Block": {} },
"VisibilityConfig": {
"SampledRequestsEnabled": true,
"CloudWatchMetricsEnabled": true,
"MetricName": "block-sql-injection"
}
}
]
}
上述JSON片段展示了一条最低限度的SQL注入阻断规则，实际生产环境还会叠加XSS检测、路径遍历过滤与IP信誉规则。另一类重要的ACL规则是IP集合和地理限制，它们用于实现粗粒度的访问控制。例如，如果业务只允许中国和新加坡用户访问，可以创建GeoMatchStatement，将其他国家请求直接Block或Challenge。对于后台管理路径，则可以使用IPSet仅允许公司出口IP访问，并配合基于速率的规则限制登录接口的尝试次数。
针对OWASP Top 10的ACL规则设计：从注入到访问控制缺失
OWASP Top 10并不是一份可以直接翻译成规则的清单，它描述的是风险类别，而WAF的ACL需要针对具体的攻击特征来设计。以A03注入为例，SQL注入的常见特征包括URL参数或请求体中出现 union select、information_schema、sleep( 等片段。托管规则组中的SQL数据库规则已经内置大量签名，但自定义规则仍然有必要，因为业务可能使用特殊参数名或编码方式，托管规则不一定覆盖。攻击者也会利用 <script> 标签注入恶意JavaScript，XSS检测规则需要同时覆盖URI、查询字符串和请求体。
针对A01访问控制缺失，WAF的ACL无法替代应用层的对象级授权，但可以阻断对敏感路径的未授权扫描。例如，可以对 /admin、/backup、/.git 等路径设置字符串匹配规则，配合IP集合实现第一道防线。对于A07身份认证失败，基于速率的规则按客户端IP统计请求次数，若某IP在5分钟内请求登录接口超过10次，则触发Block或Challenge。这样能够显著降低暴力破解和凭据填充的成功率。
{
"Name": "rate-limit-login",
"Priority": 10,
"Statement": {
"RateBasedStatement": {
"Limit": 100,
"AggregateKeyType": "IP",
"ScopeDownStatement": {
"ByteMatchStatement": {
"FieldToMatch": { "UriPath": {} },
"PositionalConstraint": "CONTAINS",
"SearchString": "/login",
"TextTransformations": [
{ "Priority": 0, "Type": "LOWERCASE" }
]
}
}
}
},
"Action": { "Challenge": {} },
"VisibilityConfig": {
"SampledRequestsEnabled": true,
"CloudWatchMetricsEnabled": true,
"MetricName": "rate-limit-login"
}
}
上面的规则将触发条件限制在URI包含 /login 的请求上，窗口为默认5分钟，Limit为100。实际阈值应根据业务正常登录流量调整，可以先使用Count动作观察一段时间，再切换为Challenge或Block。除了速率限制，还可以针对扫描器特征设置User-Agent匹配、HTTP方法限制等规则。例如，只允许GET、POST、HEAD方法，拒绝PUT、DELETE、TRACE等未使用的方法，能减少一部分自动化攻击面。
A10服务端请求伪造在WAF层面的防护通常不是靠单一签名，而是在请求参数中检测内网地址、云元数据地址和非常规协议头。对于CloudFront源站是S3或API Gateway的场景，WAF可以阻断带有 169.254.169.254 或 localhost 的可疑回源参数。对于A02加密失败和A06易受攻击组件，WAF无法修复系统漏洞，但可以配合CloudFront的TLS策略、安全头响应和源站补丁管理来降低暴露面。
WAF ACL规则配置实践：托管规则与自定义规则组合
在实际部署中，完全依赖自定义规则维护成本较高，建议先启用AWS托管规则组作为基线。CloudFront作用域可用的托管规则组包括核心规则集、SQL数据库、已知恶意输入、管理员保护和IP信誉等。托管规则组的内容由AWS持续更新，能够覆盖大量已知漏洞利用和通用攻击模式。但托管规则也可能误伤正常请求，因此需要针对业务特征设置规则覆盖或使用Count模式先行观察。
ACL规则的调优通常遵循从Count到Block的渐进流程。新规则上线时，先把Action设为Count，通过WAF日志和CloudWatch指标观察命中情况。如果发现某条规则频繁拦截正常业务请求，可以通过规则组内部的规则覆盖机制降低敏感度或排除特定路径。对于误报严重的规则，建议在Web ACL的规则组配置中添加ExcludedRules，而不是直接删除整条规则组，这样可以在保留其他防护能力的同时精准排除误报源。
{
"Name": "aws-managed-core-rule-set",
"Priority": 0,
"OverrideAction": { "None": {} },
"Statement": {
"ManagedRuleGroupStatement": {
"VendorName": "AWS",
"Name": "AWSManagedRulesCommonRuleSet",
"ExcludedRules": [
{ "Name": "SizeRestrictions_BODY" }
]
}
},
"VisibilityConfig": {
"SampledRequestsEnabled": true,
"CloudWatchMetricsEnabled": true,
"MetricName": "managed-core-rule-set"
}
}
此配置启用了AWS核心规则集，但排除了对请求体大小限制的检测，因为某些上传接口可能会因正常大文件请求触发误报。除了AWS托管规则，第三方托管规则组也可以从WAF市场中订阅，但需要注意第三方规则组的更新频率和匹配逻辑是否适合自身业务。所有规则组和自定义规则最终都汇总在同一个Web ACL中，按Priority顺序执行。
如果使用基础设施即代码管理WAF，Terraform的 aws_wafv2_web_acl 资源可以完整声明所有规则。自定义规则、托管规则组和IP集合都可以在HCL中表达，并通过模块化方式复用。不同环境建议使用独立的Web ACL，但规则定义可以抽象为模块变量，避免测试环境与生产环境的规则漂移。CloudFront分配与WAF的关联在Terraform中通过 aws_cloudfront_distribution 的 web_acl_id 参数完成，修改关联时AWS会在后台异步传播到所有边缘节点。
监控、日志分析与误报处理
WAF规则上线后，不能只依赖拦截数量判断效果，还需要分析被拦截请求的具体内容。开启WAF日志后，可以将日志投递到CloudWatch Logs、S3或Kinesis Data Firehose。日志中的 terminatingRuleId 字段表示最终处理请求的规则ID，action 字段表示允许或拦截动作。通过Athena对S3中的日志进行即席查询，可以按规则ID聚合拦截次数、查看被拦截URI的分布，以及判断是否存在针对特定路径的集中攻击。
误报处理是WAF运维的核心环节。攻击签名难免存在过宽匹配，例如核心规则集中的某些正则可能将包含 select 的普通文本误判为SQL注入。此时可以通过日志中的规则ID和请求样本复现，在规则组中排除对应规则，或者使用更精确的 ByteMatchStatement 替换内置签名。排查误报时还要区分CloudFront自己的缓存行为和WAF阻断：如果某个请求被CloudFront返回403而不是WAF Block页面，需要检查CloudFront分配的默认根对象、OAC或签名设置，避免混淆。
除了规则级调优，CloudWatch指标可以跟踪允许、拦截、Challenge和CAPTCHA请求的数量变化。如果拦截数量突增，通常意味着自动化攻击正在发生，此时可以临时提高速率规则的敏感度或启用更严格的托管规则组。长期来看，应定期回顾ACL规则是否仍然符合业务需求，删除不再使用的IP集合和过期规则，确保Web ACL容量保持在合理水平。
通过将WAF Web ACL关联到CloudFront，并在边缘节点部署针对OWASP Top 10的ACL规则，组织可以在不修改应用代码的情况下获得显著的攻击面收敛。但WAF不是应用安全的全部，访问控制、加密传输、日志审计和补丁管理仍然需要在应用层持续投入。将WAF的规则命中数据反馈到安全运营流程中，才能形成持续改进的防护体系。
AWS WAFCloudFrontOWASP Top 10修改时间：2026-09-21 09:00:44