1. 公网业务防护工程导入
当业务系统通过公网向用户提供服务时，它面对的并不是“稳定的互联网”，而是一条持续被扫描、探测、试探和攻击的暴露面。一个典型的公网入口通常由 DNS、CDN、负载均衡、API 网关、源站应用和数据库组成，攻击者会从域名解析、HTTP 请求、TLS 握手、参数构造、访问频率等多个层面寻找突破口。AWS WAF 的位置，正是在这条链路的 HTTP/HTTPS 层：它不替代网络层防护，也不替代主机和代码安全，而是把“哪些请求可以到达后端”这件事变成可编排、可观测、可回滚的规则决策。
理解 AWS WAF 的定位，可以用一个简单的请求路径来说明。用户请求先到达 Amazon CloudFront、Application Load Balancer、API Gateway 或 AppSync 等入口，WAF Web ACL 在这些入口上对请求做检查，命中规则后执行 Allow、Block、Count 或 CAPTCHA 等动作，再决定是否转发给源站。也就是说，WAF 是“入口处的 HTTP 检查站”，而不是源站内部的补丁。它的核心价值体现在三方面：第一，把常见 Web 攻击（SQL 注入、XSS、路径穿越、恶意 Bot、异常高频访问）在到达应用之前拦截；第二，通过速率限制和 IP 信誉降低资源消耗型攻击的影响；第三，通过日志和指标让防护效果可度量、可调优，而不是“配完就忘”。
从工程视角看，AWS WAF 的防护体系不是“买一个托管规则就结束”。一个可落地的 Web ACL 通常包含四类规则：第一类是托管规则组，例如 AWSManagedRulesCommonRuleSet、AWSManagedRulesSQLiRuleSet、AWSManagedRulesKnownBadInputsRuleSet，用于覆盖 OWASP 常见风险；第二类是速率限制规则，按源 IP 或自定义聚合键在 5 分钟窗口内统计请求数，超过阈值后执行 Block 或 CAPTCHA；第三类是自定义规则，针对业务特有的登录、下单、查询接口做参数、路径、方法、Header 的匹配；第四类是 IP 信誉与地理规则，用于处理已知恶意来源或业务只面向特定区域的场景。规则优先级从上到下执行，命中终止动作后不再继续匹配，因此顺序本身就是防护策略的一部分。
学习路径建议按“先看清链路，再动手配置，最后用数据验证”推进。第一步，识别公网入口：确认业务是走 CloudFront、ALB、API Gateway 还是 AppSync，因为不同入口支持的 WAF 能力、日志字段和关联方式不同。第二步，建立最小可用防护：先开启托管规则组的 Count 模式，观察一周命中情况，避免直接 Block 导致误伤。第三步，加入速率限制：例如对登录接口设置 5 分钟 2000 次/IP 的阈值，先 Count 再 Block。第四步，编写自定义规则：针对 /api/login 的 POST 请求，检查 Content-Type、Body 大小、User-Agent 和 Referer。第五步，接入日志与指标：把 WAF 日志投递到 CloudWatch Logs 或 S3，用采样请求分析命中规则和误杀情况。第六步，做灰度与回滚：新规则先 Count，确认无误后再切 Block，并保留快速回滚路径。
实战目标可以拆成可检查的成果。完成本课程后，你应该能够独立完成以下任务：为一个真实的公网业务设计 Web ACL 规则结构；配置托管规则组、速率限制和至少两条自定义规则；把 WAF 日志接入可查询的存储；用 CloudWatch 指标观察 AllowedRequests、BlockedRequests、CountedRequests 的变化；针对一次模拟攻击（例如高频请求登录接口或携带 SQL 注入特征的查询参数）验证拦截效果；并在出现误杀时，通过日志中的 terminatingRuleId、action 和 request 字段定位原因，调整规则后重新验证。下面给出一个最小可用的规则顺序示例，便于在实验环境中对照操作：
Web ACL 规则顺序（示例）
1. AWSManagedRulesCommonRuleSet → Count（观察期）
2. AWSManagedRulesSQLiRuleSet → Block
3. RateLimit-Login → Block（5 分钟 / 2000 次 / IP）
4. Custom-Login-POST-Check → Count（检查 Content-Type 与 Body 大小）
5. AllowAll → Allow（默认放行）需要强调的是，上述阈值、规则顺序和动作都属于教学示例，实际项目中必须结合业务流量基线、接口重要性和误杀容忍度重新评估。WAF 的防护效果不取决于规则数量，而取决于“规则是否匹配真实攻击面、动作是否与业务风险匹配、日志是否足以支撑调优”。把这三件事做好，AWS WAF 才能从“一个安全组件”变成公网业务防护体系中真正可运营的一层。