使用 Apigee 保护应用和 API 的最佳实践

Last reviewed 2024-03-19 UTC

本文档介绍了使用 Apigee API Management 和以下 Google Cloud 产品帮助您保护应用和 API 的最佳做法：

本文档适用于负责管理应用基础架构并希望公开安全、可扩缩且高性能 API 的 API 架构师、安全架构师和工程主管。

本文档使用一系列示例架构来演示使用 Apigee API Management 的最佳做法。本文档还讨论了使用 Web 应用和 API 防护机制 (WAAP) 的最佳做法，这是一种全面的安全解决方案，可用于帮助您保护应用和 API。

本文档假定您熟悉网络、API 和 Google Cloud。

Apigee API Management

Apigee 是一个用于开发和管理 API 的平台。通过向您的服务添加代理层，Apigee 提供了抽象或表层，帮助您保护后端服务 API。

用户可以使用 OAuth 2.0 和列入许可名单的 IP 地址范围与应用进行交互。如下图所示，用户可以与应用交互，而数据和服务在双向流中公开。

用户与应用和后端交互时的安全点。

安全点如下：

  • 用户：
    • OAuth 2.0
    • IP 地址访问权限控制
  • 应用
    • API 密钥
    • OAuth 2.0
    • TLS
  • 开发者与合作伙伴
    • 单点登录
    • RBAC
  • API
    • OAuth 2.0
    • OpenID Connect
    • 配额
    • SpikeArrest
    • 威胁防护
  • API 团队
    • IAM RBAC
    • 联合逻辑
    • 数据脱敏
    • 审核日志
  • 后端
    • 专用网络
    • 双向 TLS
    • IP 地址访问权限控制

如上图所示，您可以在应用中使用不同的安全机制，例如 API 密钥或采用传输层安全协议 (TLS) 的 OAuth 2.0。您还可以向 API 层的后端添加速率限制和威胁防护政策并配置双向 TLS。

为了帮助您管理 Apigee 平台中 API 团队的访问权限，Apigee 具有基于角色的访问权限控制 (RBAC) 和联合登录。

我们建议您使用 Apigee 默认政策来保护 API。这些政策如下：

  • 流量管理。帮助您配置缓存、控制配额、降低流量高峰的影响以及控制 API 流量。
  • 消息级保护。允许您检查和验证请求载荷，以帮助保护您的后端免受恶意攻击。
  • 安全。帮助您控制对 API 的访问权限。

您可以将一个或多个上述政策附加到代理层。下表列出了每个政策的安全用例（按政策类型分类）。

政策类型 政策名称 安全用例
流量管理 SpikeArrest 政策 将速率限制应用于发送到后端的请求数。
流量管理 配额政策 帮助您的组织为每个使用方实施配额（API 调用次数）。
流量管理 ResponseCache 政策 缓存响应，从而减少发送到后端的请求数量。
消息级保护 OASValidation 政策 根据 OpenAPI 3.0 规范（JSON 或 YAML）验证传入的请求或响应消息。
消息级保护 SOAPMessageValidation 政策 根据首选架构验证 XML 消息。根据 WSDL 验证 SOAP 消息，并确定 JSON 和 XML 消息的格式是否正确。
消息级保护 JSONThreatProtection 政策 通过让您指定对 JSON 结构（如数组和字符串）的限制来降低内容级攻击的风险。
消息级保护 XMLThreatProtection 政策 通过评估消息内容并在解析之前检测消息是否损坏或格式错误，帮助您解决 XML 漏洞并减轻攻击风险。
消息级保护 RegularExpressionPolicy 政策 根据预定义的正则表达式评估内容，如果表达式为 true，则拒绝该内容。
安全 BasicAuthentication 政策 对用户凭据进行 Base64 编码和解码。
安全 VerifyAPIKey 政策 在运行时强制核实和验证 API 密钥。仅允许具有与您的 API 产品相关联的已获批 API 密钥的应用访问您的 API。
安全 OAuthV2 政策 执行 OAuth 2.0 授权类型操作，以生成和验证访问令牌。
安全 JWS 和 JWT 政策 生成、验证并解码 JSON Web 令牌 (JWT) 和 JSON Web 签名 (JWS)。
安全 HMAC 政策 计算并验证基于哈希的消息身份验证代码 (HMAC)，以进行身份验证和应用级的完整性检查。
安全 SAMLAssertion 政策
  • 验证包含经过数字签名的 SAML 断言的传入消息。
  • 为出站 XML 请求生成 SAML 断言。
安全 CORS 政策 允许您为 Web 应用所使用的 API 设置跨域资源共享 (CORS) 标头。

我们建议您使用 Google Cloud Armor 进行基于 IP 地址和基于地理位置的访问权限控制。但如果无法实现，您可以使用 AccessControl 政策。为了帮助您保护从 Apigee 到后端的连接，Apigee 还提供密钥库管理，让您可以为 TLS 握手配置密钥库和信任库。

您可以使用 Apigee 创建 API 产品，将 API 操作捆绑在一起以供应用开发者使用。一个 API 产品捆绑了一项或多项操作。操作指定可以在相应代理上访问的 API 代理和资源路径。操作还可以按 HTTP 方法和配额来限制访问。

您可以使用 API 产品来控制对 API 的访问权限。通过在开发者应用中定义一个或多个 API 产品，您可以使用 API 密钥限制对代理的访问。例如，客户使用的移动应用只能对 /v1/payments 端点（在本例中为 https://$DOMAIN/v1/payments）执行 POST 操作。在另一个示例中，呼叫中心员工使用的呼叫中心应用可以对 /payments 端点（例如 https://$DOMAIN/v1/payments/1234）执行 PUT 或 DELETE 等操作，以还原或逆转付款。

初始架构

本部分介绍将服务部署在数据中心和云服务商的示例微服务架构。以下架构最佳做法演示了如何迭代和改进初始架构。

将服务部署在数据中心和云服务商的示例微服务架构。

初始架构如下所示：

  • 付款和账号服务托管在数据中心，而转账服务托管在 Google Cloud。
  • 外部应用负载均衡器控制和配置服务的入站流量。
  • 外部应用负载均衡器将请求转发到相应的后端或第三方服务，然后处理 TLS 握手。

示例架构在初始状态下具有以下限制：

  • 不太可能扩缩。
  • 不太可能保护系统免受恶意攻击
  • 在安全性和日志记录方面不会体现出一致的最佳做法，因为这些服务由组织内的不同团队开发和维护。

架构最佳做法

通过在所有 API 中实施一套标准的安全政策，Apigee 可以带来更多价值，并让您更轻松地向使用方公开您的服务。本部分讨论使用 Apigee 帮助保护 API 的最佳做法。

使用 Apigee 作为代理层

下图显示了添加 Apigee 作为代理层 (Facade) 的初始架构：

Apigee 作为代理层。

Apigee 在 Google Cloud 项目中预配，而运行时在租户项目中使用 VPC 网络对等互连进行预配和对等互连。为了帮助保护系统，而不是通过互联网发送数据，您可以使用 Apigee 作为代理层，通过 Cloud Interconnect 与数据中心建立直接（专用）连接。

请求流程如下所示：

  1. 客户端使用应用的凭据（例如密钥、令牌或证书）将请求发送到外部应用负载均衡器。
  2. 负载均衡器将请求路由到 Apigee。
  3. Apigee 处理请求，执行安全政策（如 Apigee API Management 中所述），然后允许或拒绝请求。Apigee 还可用于根据客户端和/或请求将请求路由到不同的后端。
  4. Apigee 直接通过内部 IP 地址将请求转发到 GKE 后端。Apigee 和转账服务之间的通信可以通过 RFC 1918 地址（内部 IP 地址）进行，因为它们位于对等互连的网络中。
  5. Apigee 通过 Cloud Interconnect 将请求发送到私有数据中心后端。
  6. Apigee 通过 Apigee NAT IP 地址预配将请求发送到第三方服务。

将 Google Cloud Armor 作为 WAF 层与 Apigee 搭配使用

您可以将 Google Cloud Armor 添加到架构以增加安全边界。Google Cloud Armor 是 Google Cloud 全局负载均衡基础架构的一部分。它提供 Web 应用防火墙 (WAF) 功能，有助于防止分布式拒绝服务 (DDoS) 攻击。此外，它还有助于减轻 OWASP 十大风险中所列风险对应用的威胁。

您可以在 Google Cloud Armor 中配置规则和政策，以评估命中外部应用负载均衡器的客户端所进行的每项调用。此外，您还可以自动配置 Google Cloud Armor 政策。如需详细了解如何在 Google Cloud Armor 中配置规则，请参阅 Google Cloud Armor 方法指南。

下图展示了同时拥有 Apigee 和 Google Cloud Armor 的示例架构：

拥有 Google Cloud Armor 的架构。

此架构中的事件流程与本文档前面使用 Apigee 作为代理层中介绍的流程类似。请求流程如下所示：

  1. 客户端使用应用的凭据（例如密钥、令牌或证书）将请求发送到外部应用负载均衡器。
  2. Google Cloud Armor 会过滤请求，因为外部应用负载均衡器已启用该请求。它会强制执行并评估所有配置的规则和政策。如果违反了任何规则，Google Cloud Armor 会拒绝请求并向您提供错误消息和状态代码。
  3. 如果没有违反 Google Cloud Armor 规则，外部应用负载均衡器会将请求路由到 Apigee。
  4. Apigee 处理请求，执行安全政策，然后允许或拒绝请求。它还可用于根据客户端和/或请求将请求路由到不同的后端。
  5. Apigee 直接通过内部 IP 地址将请求转发到 GKE 后端。Apigee 和转账服务之间的通信可以通过 RFC 1918 地址（内部 IP 地址）进行，因为它们位于对等互连的网络中。
  6. Apigee 通过 Cloud Interconnect 将请求发送到私有数据中心后端。
  7. Apigee 通过 Apigee NAT IP 地址预配将请求发送到第三方服务。

使用 WAAP

为了进一步增强您的安全配置文件，您还可以使用 WAAP，它汇聚了 Google Cloud Armor、reCAPTCHA 和 Apigee，以帮助保护您的系统免受 DDoS 攻击和机器人攻击。它还提供 WAF 和 API 保护。

对于从网站和移动应用进行 API 调用的企业用例，我们建议使用 WAAP。您可以将应用设置为加载 reCAPTCHA 库，以生成 reCAPTCHA 令牌并在发出请求时发送该令牌。

下图展示了该工作流：

WAAP 的请求流程。

上图中的请求流程如下所示：

  • (1) 客户和 API 使用方的所有 HTTP(S) 请求都将发送到外部应用负载均衡器。
  • (2) WAAP 解决方案的第一个联系对象是 Google Cloud Armor。
  • (2a) 如果 Google Cloud Armor 政策未触发这些规则，则系统会向 reCAPTCHA API 发送请求，以评估传入流量是否为合法请求。
  • (3a) 如果它是合法请求，则系统将请求转发给后端。
  • (2b) 如果请求不合法，Google Cloud Armor 可以拒绝该请求并向用户发送 403 响应代码。
  • (3b) 对于任何 API 请求，在评估 Google Cloud Armor OWASP 规则和 DDoS 保护之后，系统都会将请求转发到 Apigee，以检查 API 请求的有效性。
  • (4) Apigee 判定请求中使用的 API 密钥或访问令牌是否有效。如果 Apigee 判定请求非法，则 Apigee 可以发送 403 响应代码。
  • (5) 如果请求合法，Apigee 将请求转发到后端。

下图展示了使用 Google Cloud Armor、reCAPTCHA 和 Apigee 处理 API 请求的 WAAP 的架构。

包含 Google Cloud Armor、reCAPTCHA 和 Apigee 的 WAAP 的请求流程。

上图中的请求流程如下所示：

  1. 客户端使用应用的凭据（例如密钥、令牌或证书）将请求发送到外部应用负载均衡器。
  2. 由于外部应用负载均衡器启用了 Google Cloud Armor，因此 Google Cloud Armor 会选择该请求。它会强制执行并评估所有配置的规则和政策。如果违反了任何规则，Google Cloud Armor 将拒绝请求并显示错误消息和状态代码。
  3. 对于网站调用（例如登录页面的表单提交），Google Cloud Armor 与 reCAPTCHA 集成。reCAPTCHA 评估传入流量，并为合法流量增加风险评分。对于不合法的流量，Google Cloud Armor 可以拒绝请求。
  4. 如果没有违反 Google Cloud Armor 规则，外部应用负载均衡器会将 API 请求路由到 Apigee。
  5. Apigee 处理请求，执行安全政策，然后允许或拒绝请求。Apigee 还可用于根据客户端和/或请求将请求路由到不同的后端。
  6. Apigee 直接通过内部 IP 地址将请求转发到 GKE 后端。Apigee 和转账服务之间的通信可以通过 RFC 1918 地址（内部 IP 地址）进行，因为它们都在对等互连网络中。
  7. Apigee 通过 Cloud Interconnect 将请求发送到私有数据中心后端。
  8. Apigee 通过 Apigee NAT IP 地址预配将请求发送到第三方服务。

使用 Cloud CDN 进行缓存

Cloud CDN 使用 Google 全球网络在更靠近用户的位置提供内容，从而缩短您的网站和应用的响应时间。Cloud CDN 还提供缓存功能，通过从缓存返回响应来帮助保护后端的安全。通过在位于 Google 网络边缘的 Google Front End (GFE) 缓存经常访问的数据，使数据尽可能地接近用户并实现尽可能快速的访问。

Cloud CDN 还可帮助组织无缝处理季节性流量高峰（例如，在节假日或返校季可能出现的流量高峰）。这种缓存方法有助于改善生态系统的可靠性和用户体验。它还有助于最大限度地减少网络服务器的负载、计算和网络使用。如需实现此架构，您必须在为 Apigee 处理流量的负载均衡器上启用 Cloud CDN。

Cloud CDN 可与本文档讨论的任何选项搭配使用。下图展示了添加了 Cloud CDN 的 WAAP 的初始示例架构。

使用 Cloud CDN 的请求流。

上图中显示的请求流程如下所示：

  1. 客户端使用 reCAPTCHA 库获取令牌并使用应用凭据（例如密钥、令牌或证书）向外部应用负载均衡器发送请求。
  2. Cloud CDN 使用缓存键检查缓存，并在缓存命中为 true 时返回响应。
  3. 如果缓存命中为 false，则 Google Cloud Armor 会过滤请求，因为外部应用负载均衡器已启用 Google Cloud Armor。Google Cloud Armor 会强制执行并评估所有配置的规则和政策。如果违反了任何规则，它将拒绝请求并显示错误消息和状态代码。
  4. Google Cloud Armor 与 reCAPTCHA 集成，后者使用风险评分来评估合法传入流量。对于不合法的流量，Google Cloud Armor 可以拒绝请求。
  5. 如果没有违反 Google Cloud Armor 规则，外部应用负载均衡器会将请求路由到 Apigee。
  6. Apigee 处理请求，执行安全政策（如 Apigee API Management 中所述），然后允许或拒绝请求。它还可用于根据客户端和/或请求将请求路由到不同的后端。
  7. Apigee 直接通过内部 IP 地址将请求转发到 GKE 后端。Apigee 和转账服务之间的通信可以通过 RFC 1918 地址（内部 IP 地址）进行，因为它们都在对等互连网络中。
  8. Apigee 通过 Cloud Interconnect 将请求发送到私有数据中心后端。
  9. Apigee 通过 Apigee NAT IP 地址预配将请求发送到第三方服务。
  10. 当响应流回客户端时，Cloud CDN 会将其缓存，以便从缓存中返回响应，以用于将来的调用。

后续步骤