[解决方案] Glovo 如何通过结合 AWS Edge Services 保护其公共 API

<!-- 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全文翻译 -->