<!-- AI_TASK_START: AI标题翻译 -->
[解决方案] Glovo 如何通过结合 AWS Edge Services 保护其公共 API
<!-- AI_TASK_END: AI标题翻译 -->
<!-- AI_TASK_START: AI竞争分析 -->
# 解决方案分析
## 解决方案概述
Glovo 采用 AWS Edge Services 的组合,包括 **AWS WAF**、**AWS Shield Advanced** 和 **Amazon CloudFront**,来保护其公共 API 免受外部威胁。该方案针对现代应用程序的 API 暴露问题,提供分布式防护,适用于高流量场景下的电商和配送服务。背景在于,Glovo 作为一家多类别应用平台,需要处理大量用户请求,同时防范 **OWASP Top 10** 中的漏洞(如 SQL 注入)、凭证填充和 DDoS 攻击。核心目标是提升 API 的安全性和可用性,解决初始架构中如 IP 阻塞和观察性不足的痛点。
## 实施步骤
1. **评估初始架构并识别挑战**
首先,Glovo 审视了原有架构,使用 **Application Load Balancer (ALB)** 和第三方 API 网关处理流量,但面临 IP 阻塞困难、观察性不足、速率限制失效和体量攻击等问题。通过日志分析和监控工具,识别了常见攻击如暴力登录和业务逻辑滥用。
2. **重新设计架构**
引入 **CloudFront** 作为全局入口点,配置分布以路由请求,并限制源访问使用共享密钥和 **AWS-managed prefix list**。关联 **AWS WAF** 到 CloudFront 分发,定义规则组处理请求;同时配置 **Shield Advanced** 监控流量并设置健康检查(如使用 **Amazon Route 53**)。
3. **配置和部署服务**
使用 **Terraform** 作为 IaC 框架,定义和部署 **AWS WAF** 规则(如 IP 声誉列表和自定义规则)、**Shield Advanced** 的 DDoS 基线监控,以及 CloudFront 的缓存和转发逻辑。规则按顺序处理,确保先计数再阻塞,并通过标签标记流量以便后续分析。
4. **测试和优化**
监控流量模式,使用 **CloudWatch** 警报跟踪阻塞率和 DDoS 事件。Glovo 遵循最佳实践,如在添加新规则时先设为计数模式,并逐步升级 **AWS Managed Rules** 版本。
## 方案客户价值
- **提升安全性和可用性**:通过 **AWS WAF** 和 **Shield Advanced**,Glovo 有效缓解 DDoS 攻击和应用层威胁,提高 API 响应速度和可靠性,与传统 ALB 架构相比,减少了手动 IP 管理带来的错误风险。
- **改善观察性和效率**:整合日志和指标,提供单一视图识别恶意流量,缩短事件响应时间,避免了原有架构的多工具分析延误。
- **成本优化**:**Shield Advanced** 吸收部分 **AWS WAF** 请求费用(如使用 Managed Rules),帮助 Glovo 在高并发场景下控制成本,但需注意大规模规则管理可能增加运维复杂度。
## 涉及的相关产品
- **AWS WAF**:用于分析 HTTP 请求并应用规则组,作用是过滤恶意流量,如 IP 声誉列表和自定义规则。
- **AWS Shield Advanced**:提供 DDoS 保护(Layers 3–7),通过自动缓解和 SRT 团队支持,监控 CloudFront 流量并响应攻击。
- **Amazon CloudFront**:作为边缘缓存和入口点,分发全球流量,降低延迟并作为 DDoS 防护的第一层。
- **Application Load Balancer (ALB)**:作为后端源,仅接受 CloudFront 请求,确保内部服务隔离。
- **Terraform**:用作 IaC 工具,管理配置变更和部署,确保服务一致性。
## 技术评估
该方案的技术先进性体现在分布式边缘防护上,利用 **CloudFront** 的全球 POP 网络结合 **AWS WAF** 的规则引擎,实现高效流量过滤和 DDoS 自动缓解,可行性高,尤其适用于高流量 API 服务。但在适用范围上,最适合公有云环境下的电商应用,可能的局限性包括规则管理复杂度上升(如频繁更新 JA3 指纹),以及在极端攻击下依赖 SRT 团队协作可能延缓响应。总体上,该方案在安全性和可扩展性上表现出色,但需持续优化以应对新兴威胁。
## 其他信息
Glovo 通过经验教训强调了最佳实践,如限制源访问和规则版本控制。未来计划包括集成 **AWS Bot Control** 以过滤机器人流量,以及探索 **CloudFront VPC Origins** 以进一步隔离公共互联网暴露,展示了方案的扩展潜力。
<!-- AI_TASK_END: AI竞争分析 -->
<!-- AI_TASK_START: AI全文翻译 -->
# Glovo 如何使用 AWS 边缘服务组合保护其公共 API
**原始链接:** [https://aws.amazon.com/blogs/networking-and-content-delivery/how-glovo-is-protecting-their-public-apis-with-a-combination-of-aws-edge-services/](https://aws.amazon.com/blogs/networking-and-content-delivery/how-glovo-is-protecting-their-public-apis-with-a-combination-of-aws-edge-services/)
**发布时间:** 2025-03-10
**厂商:** AWS
**类型:** BLOG
---
现代应用程序经常依赖公共 API 来在受信任的客户端(如移动应用程序或网页浏览器)和服务之间交换信息。使用 Amazon Web Services (AWS) 边缘服务([AWS WAF](https://docs.aws.amazon.com/waf/latest/developerguide/waf-chapter.html)(AWS Web Application Firewall (AWS WAF))、[AWS Shield Advanced](https://docs.aws.amazon.com/shield/?id=docs_gateway) 和 [Amazon CloudFront](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Introduction.html))的组合,Glovo 分享了他们如何保护其面向公众的 API,免受各种外部威胁,如 [OWASP Top 10](https://owasp.org/www-project-top-ten/) 中描述的漏洞、SQL 注入或各种形式的分布式拒绝服务 (DDoS) 攻击。
AWS WAF 是一个网页应用程序防火墙。它分析传入请求,并提供针对常见网页漏洞、流量攻击以及更复杂的威胁(如账户创建欺诈或试图规避检测的机器人)的保护。
Shield Advanced 是一个托管的 DDoS 保护服务,用于保护运行在 AWS 互联网面向资源的应用程序后方的服务。Shield Advanced 为第 3-7 层提供 DDoS 保护。拥有 Business 或 Enterprise 支持的用户还可以 24/7 与 AWS Shield Response Team (SRT) 合作,应对复杂的攻击。
CloudFront 能够以低延迟和高性能安全地交付内容。它充当反向代理,作为应用程序全球的单一入口点。世界各地的用户连接到离他们最近的 [CloudFront 的数百个存在点 (POPs)](https://aws.amazon.com/cloudfront/features/?whats-new-cloudfront.sort-by=item.additionalFields.postDateTime&whats-new-cloudfront.sort-order=desc#Global_Edge_Network)。CloudFront 要么直接从其缓存中响应,要么将请求转发到您的应用程序。由于流量分布在 CloudFront 的边缘位置,这使其成为保护 DDoS 和其他应用程序攻击的理想位置。
[Glovo](https://glovoapp.com/) 是一个开创性的多类别应用程序,将用户与企业和 courier 连接起来,提供从本地餐厅、杂货店和超市以及高街零售店的按需服务。Glovo 的愿景是构建最大的在线市场,让每个人都能在几分钟内访问所在城市的任何东西。该公司于 2015 年在巴塞罗那成立,在欧洲、中亚和非洲的 23 个国家运营。
##
## 初始公共 API 架构和挑战
之前,Glovo 使用 [Application Load Balancer (ALB)](https://aws.amazon.com/elasticloadbalancing/application-load-balancer/) 作为前置,将流量路由到一组第三方 API Gateway 实例。这些实例将流量路由到适当的内部服务。
以下是 Glovo 的初始 API 架构图:

*图 1: Glovo 的初始公共 API 架构*
尽管这种架构在 Glovo 的早期阶段发挥了作用,但它没有为 API 提供必要的保护和可用性水平。以下是发现的挑战:
- 难以阻止恶意外部 IP:尽管 Glovo 依赖子网级别的 Network Access Control Lists (NACLs) 来阻止外部 IP,但这些操作在规模化时变得繁琐且易出错。
- 可观察性:Glovo 使用 ALB 和应用程序日志的组合来识别不良行为者。这效率低下,并延长了事件响应时间,因为需要多个工具和分析来识别不良行为者。
- 速率限制:每个 API 都有一些基本速率限制功能。但在面对流量攻击时,API 已经超载,速率限制无效。
- 流量攻击:无法及时识别和阻止它们。
这些挑战在面对外部不良行为者使用的一些最常见攻击时变得明显:
- 暴力破解登录:一组不同的不良行为者试图通过向 Glovo 的登录端点发送大量登录请求来猜测某些利益相关者的密码。
- 凭证填充:类似于前一项,不良行为者尝试使用从已知外部数据库泄露或暗网获取的凭证。
- 业务逻辑滥用:在这种情况下,不良行为者试图滥用 API 暴露的特定应用程序功能。
- 服务拒绝:这种攻击的影响范围很大,因为它可能导致特定关键 API 崩溃。
在下一节中,我们将观察 Glovo 如何重新设计架构,以应对这些挑战,并有效缓解/阻止不良行为者使用的最常见攻击。
##
## AWS 边缘服务:将攻击者挡在 API 之外
在边缘实施安全意味着使用 CloudFront 网络基础设施来实现分布式保护。与 AWS WAF 和 Shield Advanced 结合使用,只有被视为合法的流量才会到达 API。
以下是 Glovo 的当前 API 架构图:

*图 2: Glovo 基于 AWS 边缘服务的全新架构*
CloudFront 的配置设置通过分发 (distribution) 概念定义,您可以告诉 CloudFront 如何交付内容。将 CloudFront 放置在 API 前面意味着客户端不再直接连接到它们。现在,流量通过 CloudFront 路由。这也是一个最佳实践,通过 [共享密钥 (header)](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/restrict-access-to-load-balancer.html) 和一个 [前缀列表](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/LocationsOfEdgeServers.html#managed-prefix-list)(包含所有 CloudFront IP 地址范围)来限制对源的访问。
AWS WAF 配置与此 CloudFront 分发相关联,因此任何为请求提供服务的 CloudFront POP 都会强制使用 AWS WAF。Shield Advanced 也被配置为监控 CloudFront 分发,并在监控其流量时进行尽职调查。
为了管理这些服务,Glovo 使用 [Terraform](https://www.terraform.io/) 作为基础设施即代码 (IaC) 框架,因此任何配置更改都能得到有效审查、批准并部署。应用于 CloudFront 或 AWS WAF 的配置更改会透明地传播到所有为 API 提供流量的 CloudFront POP。
在定义了新架构后,在下一节中,我们将更深入地探讨 Glovo 在使用每个服务时的一些设计考虑。
##
## AWS WAF 配置和设计原则
AWS WAF 规则是在 [web ACL](https://docs.aws.amazon.com/waf/latest/developerguide/web-acl.html) 的上下文中定义的,它定义了如何检查 HTTP(S) 网页请求,以及当请求匹配检查标准时采取的操作。规则按顺序执行,其处理顺序是可配置的。AWS 提供一组 [AWS Managed Rules](https://docs.aws.amazon.com/waf/latest/developerguide/aws-managed-rule-groups-list.html) 由 AWS 策划和维护,但您也可以创建自己的规则或使用 [AWS Marketplace 中可用的第三方规则](https://docs.aws.amazon.com/waf/latest/developerguide/marketplace-managed-rule-groups.html)。
Glovo 使用 AWS Managed Rules 和自制规则的组合创建了他们的规则结构。
以下是 Glovo 的 AWS WAF 规则结构图,每个圆角矩形代表一个规则组。阻止/允许操作未表示:

*图 3: Glovo 定义的 AWS WAF 规则结构*
每个规则都定义了一个 [action](https://docs.aws.amazon.com/waf/latest/developerguide/web-acl-rule-actions.html),它定义了规则匹配时是终止(阻止/允许,且不再处理其他规则),还是非终止(计数),并继续处理下一个规则。
除了 action,每个规则通常由 AWS Managed Rule 本身、Glovo 创建的自定义标签,或两者的组合(AWS 标签 + 自定义标签)进行标记。 [Labels](https://docs.aws.amazon.com/waf/latest/developerguide/waf-labels.html) 用于标记特定流量,然后应用下游逻辑。它们也在 AWS WAF 日志中可见。大多数 AWS Managed Rules 包含它们自己的标签。
### **业务特定规则**
- 受信任 IP:由业务定义的一组 IP,这些 IP 永不被阻止或限速。这些 IP 是静态的,包括来自受信任第三方或不同提供商的允许机器人。这些 IP 被纳入 [AWS WAF IP Set](https://docs.aws.amazon.com/waf/latest/developerguide/waf-ip-set-managing.html) 以供 AWS WAF 规则进一步引用。
- 恶意 IP:之前的incident 往往会产生特定的一组 IP,您可能希望永久或一段时间内阻止它们。这些 IP 列表也是与 SRT 团队合作产生的。
- 内部逻辑:某些 API 路径不应暴露或公开访问。
- 恶意 JA3 指纹:[JA3 fingerprinting](https://docs.aws.amazon.com/waf/latest/APIReference/API_JA3Fingerprint.html) 是一种强大机制,通过分析 AWS WAF 日志来识别分布式攻击中的相同指纹。
### IP 声誉规则
- AWS IP 声誉列表:这是最受欢迎的 AWS Managed Rules ([AWSManagedRulesAmazonIpReputationList](https://docs.aws.amazon.com/waf/latest/developerguide/aws-managed-rule-groups-ip-rep.html#aws-managed-rule-groups-ip-rep-amazon)) 之一,它包含由 Amazon 内部威胁情报标识为恶意的 IP 组。该组中的一个规则示例是 AWSManagedIPDDoSList,其中包含被标识为主动参与 DDoS 活动的 IP 地址。
- 匿名 IP 列表:另一个 AWS Managed Rule ([AWSManagedRulesAnonymousIpList](https://docs.aws.amazon.com/waf/latest/developerguide/aws-managed-rule-groups-ip-rep.html#aws-managed-rule-groups-ip-rep-amazon))。在此情况下,它尝试识别隐藏查看者身份的请求,如 VPN、代理或网页托管提供商。
### 标记规则
- 其他 AWS Managed Rules:Glovo 使用其他 AWS Managed Rules 的组合来用标签标记特定外部流量。在这个阶段,流量不会被阻止,只被计数和标记。
- 内部逻辑:这些规则使用自定义标签标记流量,以便下游进一步处理,例如特定 HTTP 头或路径的存在。有些规则添加更多头,以便源处的特定 API 基于这些头应用业务逻辑。
### 处理和速率限制规则
- 阻止某些流量:一组新自定义规则使用标签和特定请求信息(头、cookie、路径等)来限速或阻止特定请求。上游规则添加的先前标签有助于应用限速。例如,您可能希望针对带有匿名 IP 列表规则中标记的 IP 的登录路径进行限速。
### 红色按钮
- 遭受攻击:在少数情况下,复杂的分布式攻击需要进一步分析来识别其签名。Glovo 在 web ACL 末尾放置了一个特定规则来阻止特定流量条件。
##
## Shield Advanced 配置和设计原则
以下是 Shield Advanced 当前如何配置以保护 Glovo 的 API 的图:

*图 4: Glovo 定义的 Shield Advanced 配置*
在加入 Shield Advanced 时,Glovo 定义了一个 [Amazon Route 53 health-check](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/health-checks-types.html) 来代表其 API 健康。一般指导是,health-check 可以配置为基于 CloudWatch 警报(例如监控 CloudFront 中的 Origin Latency 指标)评估 API 延迟、特定 HTTP 响应或其他相关服务指标。此 health-check 会通知 SRT 团队何时有针对 Glovo API 的活跃 DDoS。在这种情况下,会向共享电子邮件列表发送电子邮件,以便 Glovo 的值班工程师收到页面通知,并准备加入 SRT 团队主持的会议电话。SRT 团队协助 Glovo 识别攻击向量并在 AWS WAF 中进行适当配置更改以缓解它。
除了直接由 SRT 团队参与,Shield Advanced 在 2021 年发布了 [Automatic Application Layer DDoS Mitigation](https://aws.amazon.com/blogs/aws/aws-shield-advanced-update-automatic-application-layer-ddos-mitigation/),允许 Shield Advanced 背后的威胁情报引擎在检测到 DDoS 事件时,在用户的 web ACL 中放置特定 AWS WAF 规则。为此,Shield Advanced 会为受保护资源(在此为 CloudFront)建立流量基线,以便随着时间了解预期的流量模式。用户可以将此规则组设置为 Block/Count 模式。Glovo 目前将其设置为 Count 模式,并可根据需要翻转规则操作。
除了这些功能,Glovo 分享了在使用 Shield Advanced 时对他们至关重要的其他项目:
- SRT 团队 onboard/post-mortem 分析:SRT 团队在 Glovo 使用边缘服务的早期提供了 onboard 指导,帮助他们构建规则结构。此外,在每个影响较大的 DDoS 事件后,SRT 团队提供了详细的 postmortem 分析和建议,以增强 Glovo 的安全态势。
- AWS WAF 请求费用:当 Glovo 的 API 处理超过一百万请求/分钟时,AWS WAF 的每请求成本变得相关。如果使用 [AWS Managed Rules](https://docs.aws.amazon.com/waf/latest/developerguide/aws-managed-rule-groups-list.html) 中的 Baseline、use-case 或 IP 声誉类别,Shield Advanced 会吸收此成本。它还吸收您创建的规则的成本。在这两种情况下,如果规则是默认 1500 [WCU](https://docs.aws.amazon.com/waf/latest/developerguide/aws-waf-capacity-units.html) 限制 per web ACL 的一部分,则请求费用会被免除。这是 [AWS Shield 的定价页面](https://aws.amazon.com/shield/pricing/),如果您需要更多细节。
在可观察性方面,Glovo 依赖 AWS WAF、Shield Advanced 和 CloudFront 指标来监控流量模式,并定义警报,如每个 AWS WAF 规则的被阻止/计数的请求百分比或 Shield Advanced 检测到的 DDoS 事件。另一方面,AWS WAF 日志充当单一视图窗格,用于详细查看每个请求(以及其标签)。
##
## 操作 AWS 边缘服务的经验教训
与 AWS 最佳实践一致,以下是 Glovo 团队在使用 AWS 边缘服务多年中分享的一些关键经验:
1. 限制对源的访问:您的源(如 ALB)应仅接受来自 CloudFront 分发的请求。通过 [共享密钥](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/restrict-access-to-load-balancer.html#restrict-alb-add-custom-header) 和 [AWS 管理的 prefix list](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/restrict-access-to-load-balancer.html#limit-access-to-origin-using-aws-managed-prefixes)(包含 CloudFront IP 范围)来限制访问。
2. 在添加新 AWS WAF 规则时,先计数、分析,然后阻止:没有人希望阻止合法流量。在添加新 AWS WAF 规则时,确保先将其设置为 Count 模式,然后分析命中规则的流量,并最终根据需要将其设置为 Block。
3. 规则版本控制:大多数 [AWS Managed Rules 是版本化的](https://docs.aws.amazon.com/waf/latest/developerguide/waf-managed-rule-groups-versioning.html)。固定特定规则版本,并以受控方式推出新版本。还有一个 [Amazon Simple Notification Service (Amazon SNS) 主题](https://docs.aws.amazon.com/waf/latest/developerguide/waf-using-managed-rule-groups-sns-topic.html) 用于宣布新版本的发布。
##
## 最终结果和下一步
在本帖中,我们介绍了 Glovo 如何实现 AWS 边缘服务的组合来保护其公共 API,促进外部威胁的识别和缓解,同时改善整体 API 保护和流量可观察性。
根据 Glovo 的指标,Shield Advanced 每月检测平均 12 个 DDoS 事件(主要是由 AWS WAF 阻止的应用程序层事件),平均每秒阻止 200k 请求。
展望未来,Glovo 正在观察新功能并自动化一些规则管理:
- 关于添加新功能,Glovo 感兴趣于添加更多逻辑来过滤不需要的机器人流量。这种机器人过滤通过使用 [AWS Bot Control rules](https://docs.aws.amazon.com/waf/latest/developerguide/aws-managed-rule-groups-bot.html)、向机器人呈现 [CAPTCHA/Challenges](https://aws.amazon.com/blogs/networking-and-content-delivery/protect-against-bots-with-aws-waf-challenge-and-captcha-actions/),或两者的组合实现。虽然不是强制性的,这些方法通常需要与客户端 SDK(Glovo 的情况为移动 SDK)集成来评估攻击者配置文件。这些功能不包含在 Shield Advanced 的定价中。
- Glovo 正在评估的另一个新功能是 [CloudFront VPC Origins](https://aws.amazon.com/blogs/networking-and-content-delivery/introducing-cloudfront-virtual-private-cloud-vpc-origins-shield-your-web-applications-from-public-internet/),它在 re:Invent 2024 上发布,旨在通过仅允许通过用户的 CloudFront 分发访问来消除应用程序暴露在公共互联网的需要。
- 在更新某些 AWS WAF 规则时构建自动化。Glovo 正在评估在分析 JA3 指纹时添加一些智能,以便“坏指纹”自动填充到“恶意 JA3 指纹”规则组中。 [Security Automations for AWS WAF](https://aws.amazon.com/solutions/implementations/security-automations-for-aws-waf/) 是构建这些解决方案的良好起点。
##
## 关于作者

### Pol Valletbo Montfort
Pol Valletbo Montfort 是 Glovo 的资深软件工程师。他是 Glovo Edge 团队的一员,该团队设计和操作任何类型的公共连接到 Glovo 的 AWS 工作负载,并保护这些工作负载免受外部威胁,如 DDoS 和应用程序层攻击。

### Miguel Rodriguez Vazquez
Miguel Rodriguez Vazquez 是 Amazon Web Services (AWS) 的资深解决方案架构师。Miguel 于 2015 年加入 AWS,并拥有 10 多年网络和整体架构经验。作为解决方案架构师,他帮助客户在 AWS 中构建他们的解决方案。
<!-- AI_TASK_END: AI全文翻译 -->