OWASP 十大 API 威胁

您正在查看 Apigee Edge 文档。
前往 Apigee X 文档。 信息

本文档介绍了您可以在 Apigee 中使用各种方法来解决 OWASP 发现的安全漏洞。如需了解针对 Apigee 记录的其他方法，请参阅 Google Cloud 上的 OWASP 十大缓解选项（2021 年）。

简介

OWASP 是一个开放社区，致力于帮助组织开发、购买和维护可信的应用和 API。通过 OWASP API 安全项目，OWASP 发布了 Web 应用和 REST API 的最严重安全风险，并提供了解决这些风险的建议。

本文档将讨论如何防范常见的基于 API 的攻击，这些攻击已在 OWASP 的 2019 年十大 API 安全威胁中列出。最新列表中突出显示的热门威胁有一个共同的主题，即身份验证和授权控制措施放置不当，例如依赖于客户端应用内 API 请求返回的数据过滤，使用依赖于消费客户端应用来执行访问控制的反模式。

随着 API 生态系统继续快速发展，API 滥用和误用导致攻击者窃取数据的情况不幸成为当今最常见的攻击媒介之一。安全性一直是 Apigee 的首要任务，我们推出了许多新功能，例如包含异常检测功能的 Advanced API Ops。不过，正确设计和实现 Apigee 的安全功能对于降低 API 遭受成功攻击的可能性至关重要。

由于您无法控制应用运行的平台，因此应将消费者应用视为不受信任或“公开”的应用。假设任何公共应用都可能被入侵，因此不能信任它们来强制执行访问控制 (API1、API5)、过滤响应数据 (API6) 或安全地存储客户端密钥（例如 API 密钥或访问令牌）(API2)。以下建议来自对 2019 年 OWASP 前 10 名的检查：

  • 确定哪些类型的客户端应用将使用您的 API（SPA、移动应用或基于浏览器的应用），并设计适当的身份验证、授权和安全模式。
  • 始终使用“公共客户端”OAuth 或 OpenID Connect 流程（强烈建议使用 PKCE）
  • 考虑应用的业务逻辑，先定义 OpenAPI 规范，然后设计 API 代理，以过滤 Apigee 中来自后端的所有响应数据。切勿依赖下游应用代码逻辑来执行此操作！
  • 过滤所有包含用户专属 PII 的数据请求，仅允许来自后端且属于请求用户的数据。

API1:2019 对象级授权中断

威胁说明

对对象访问请求的授权验证不足，导致攻击者能够通过重复使用访问令牌来执行未经授权的操作。此威胁是由授权验证配置不当造成的。Apigee 提供 VerifyApiKey、OAuth 和 JSON Web 令牌 (JWT) 政策，这些政策有助于防范此漏洞，但必须正确配置这些政策才能防范此威胁。

为防范这种威胁，应用开发团队和安全团队必须密切协作。授权本身就是一个复杂的主题，而要实现有效的精细化授权，需要深入了解应用的业务逻辑。

从 Apigee 实现的角度来看，需要考虑两个主要方面：

  • 访问令牌完整性
  • 强制执行访问权限控制

访问令牌完整性

务必使用正确的 OAuth 或 OpenID Connect 流程以及适当的凭据验证或签名机制，验证请求客户端提供的令牌是否遭到篡改。Apigee 支持所有常用的 OAuth 流程。

Apigee 访问令牌验证政策包括：

访问权限控制强制执行

验证访问令牌的有效性后，务必要实施访问控制强制执行政策，以根据授权令牌的访问权限评估每个传入的 API 请求。

Apigee 提供了两种主要机制来验证和强制执行授权政策：

  • 内部：使用条件流程根据从授权令牌中提取的声明（作为流变量）评估访问请求
  • 委托：使用服务调用来调用第三方访问权限管理解决方案

如果访问控制模型相对简单，建议采用内部方法（如上图所示）。例如，从访问令牌中提取的声明可用于直接评估和授权 API 对象请求。

使用适用于 OAuth 或 JWT 政策的流变量，通过条件流语句评估访问请求。

如果从访问令牌中提取的声明无法直接用于授权对后端对象的 API 请求，或者对于需要单独调用授权服务器才能获取访问令牌的更复杂的 OAuth 流程类型，建议采用委托方法（如上图所示）。

使用 service callout 政策，可以向第三方服务请求授权政策决策，也可以获取有关请求代理的其他声明信息，然后使用条件流做出访问控制决策

API2:2019 用户身份验证中断

威胁说明

如果用户身份验证政策实施不当，攻击者便可利用身份验证实施中的缺陷来冒充合法用户。在实现身份验证方法时，请务必谨记以下身份验证原则：

  • 始终对用户代理（应用）和请求用户进行身份验证
  • 使用委托的身份验证和授权模式，避免在 API 请求中直接传递密码
  • 始终验证访问凭据的签名，并确保所使用的所有访问凭据都具有明确的过期时间
  • 通过设置配额并使用 Apigee Sense 检测和应对由机器人驱动的暴力破解攻击，来防范暴力破解攻击

在自外而内的范式下，API 设计围绕数据使用者的使用情形展开，而不是围绕后端系统中现有数据的结构展开；在为外部使用者设计 API 时，安全性是一个关键要素。传统上，后端系统在构建时并未采用足够强大的身份验证实现来应对公共网络。在这种情况下，Apigee 与身份和访问权限管理解决方案相结合，可提供强大的解决方案来防范此威胁。

这里需要考虑几个主要因素，我们将在后续部分中介绍这些因素：

  • 安全设计：充分利用 Apigee 功能来实现身份验证模式
  • 治理：确保在所有已发布的 API 产品中始终正确使用设计的身份验证模式
  • 运维安全：能够检测可疑或异常行为，以及规避或强行破解经过身份验证的 API 代理的尝试

安全设计

安全设计的目的是正确实现身份验证流程并与第三方身份工具集成。安全设计是一个关键阶段，首先要了解根据将使用您的 API 端点的应用类型，应使用哪种类型的委托身份验证流程。下一步是与身份团队一起确定要通过身份解决方案实现的集成模式。

OpenID Connect 和 OAuth RFC 提供了大量委托身份验证和授权流程，以及参与这些流程的角色。这是一个复杂的主题，因此身份验证失效成为 OWASP API 威胁中的头号威胁也就不足为奇了。全面介绍身份标准正确实现方法不在本文档的讨论范围内，但 Apigee 提供了许多其他资源，可帮助您更好地了解 OAuth 流程，例如这本电子书和网络广播，以及实现示例。

身份验证政策

有助于解决身份和身份验证问题的 Apigee 政策包括：

流量管理

以下 Apigee 流量管理功能有助于防范暴力攻击：

  • SpikeArrest 政策，用于为 API 代理设置总体滚动平均速率限制
  • 配额政策：用于根据应用密钥、开发者或 API 产品配额定义的配额，为 API 代理设置精细的速率限制
  • 缓存政策，用于缓存基于其定义的过期时间存储的访问令牌，以及使缓存的凭据失效（例如，在有效访问令牌遭到入侵的情况下）

治理

安全是一项持续进行的过程，而不是“一劳永逸”的项目，而导致安全事故的最大原因之一就是配置错误。一旦定义了身份验证流程、身份集成模式和与身份验证相关的流量管理政策，就必须正确且一致地实现这些流程、模式和政策。

Apigee 提供了许多功能和工具，可确保实现完整性并防止错误配置。

基于角色的访问权限控制 (RBAC)

无论您是大型企业还是小型初创公司，避免配置错误的第一步都是确保只有合适的人员和团队才能访问和修改 API 代理配置。API 计划由组织内多个学科的团队提供支持。在 API 使用历程中，务必要确保每个团队仅被授予执行作业所需的权限。

Apigee 提供相关功能，让您能够管理基于角色的访问权限，您可以将用户分配给预定义角色，也可以创建自定义角色来满足 API 团队的需求。正确定义和管理角色分配对于安全地扩展 API 计划至关重要。您还可以使用联盟功能与现有公司目录集成，从而减少在 Apigee 中管理第二组管理员凭据的需求。

共享流

借助共享流，您可以将政策和资源定义为可在多个 API 代理中实现的可重用对象。例如，您可能与安全团队协作设计了多种身份验证设计模式，这些模式基于使用 API 的应用类型。API 开发者无需是身份专家即可重用此共享流，只需知道要使用 Flow callout 政策将哪个共享流添加到现有的 API 代理配置中即可。

图：共享流是可重复使用的政策和条件逻辑捆绑包，可让您维护复合模式。

运营安全

当您的 API 在生产环境中运行时，如果使用了正确的身份验证模式并实施了基准流量管理，您的 SecOps 团队还必须能够监控可疑活动并做出响应，这些活动通常从试图盗用身份验证凭据开始。

Apigee Sense

Apigee Sense 可保护您的 API 免遭不必要的请求流量的侵扰，包括恶意客户端的攻击。Apigee Sense 会分析 API 请求流量，识别可能表示不必要请求的模式。通过此分析，您可以识别发出不必要的请求的客户端，然后采取措施来允许、屏蔽或标记这些请求。Sense 的未来功能将包括自动针对可疑流量启用 reCAPTCHA 验证的功能。

借助 Apigee Sense，您可以保护 API 免受包含以下内容的请求模式的攻击：

  • 与人类行为相融合的自动化行为
  • 来自同一 IP 地址的持续尝试
  • 异常错误率
  • 可疑的客户端请求
  • 数据抓取
  • 密钥窃取和身份验证暴力破解攻击
  • 活动爆发
  • 地理位置模式

Advanced API Ops

虽然 Sense 专门用于检测和应对类似机器人的威胁，但 Advanced API Ops 包含异常检测和高级提醒定义。

异常值检测功能通过将人工智能 (AI) 和机器学习 (ML) 模型应用于历史 API 数据来发挥作用。然后，异常检测功能可以针对您甚至没有想到的场景实时发出提醒，从而提高您的工作效率并缩短 API 问题的平均解决时间 (MTTR)。

高级 API 运维在现有 API Monitoring 提醒机制的基础上，添加了以下高级提醒类型：

  • 异常值提醒。Edge 会检测流量和性能问题，而无需您自行预先确定这些问题。然后，您可以针对这些异常情况发出提醒
  • TLS 过期提醒。在 TLS 证书即将过期时发出通知

API3:2019 过度数据暴露

威胁说明

已发布的 API 可能会公开比必要更多的数据，并依赖客户端应用来执行必要的过滤。如果攻击者直接查询底层 API，则能够访问敏感数据。

Apigee 的 API 设计“由外而内”设计原则之一是数据简约。与您的用户体验设计师和开发者合作，仅通过 API 公开应用界面中所需的数据。后端系统并非为公共使用模式而构建，因此采用 Apigee 的 API 优先设计方法时，首要任务之一就是将公开的数据量减少到最低限度，以便为客户和开发者提供出色的 API 产品。

Apigee 的另一项设计原则是可重用性。除了安全问题之外，如果依赖应用来过滤 API 提供的数据，则需要在您开发应用的每个平台上移植该过滤逻辑。

从安全角度来看，这种威胁源于将授权强制执行委托给应用，但通常是在您无法控制的平台或操作系统上。我们已在 API1 和 API2 中探讨了正确实现身份验证和授权以避免未经授权的数据访问权限的重要性。

以下各部分将探讨如何执行以下操作：

  • 重写对后端服务的请求和响应，以最大限度地减少数据暴露
  • 实现故障处理，以防止详细的错误消息向攻击者泄露有关后端服务的敏感环境信息

重写回答和请求

后端系统通常并非设计用于公共应用或不受信任的公共网络。Apigee Edge 旨在通过保护后端免遭过度的数据暴露，让您能够部署公共 API 产品。

为此，Apigee 使用了以下三项关键政策：

  • 分配消息
  • 代码标注
  • 故障处理

AssignMessage 政策

Assign Message 政策会在 API 代理流期间更改或创建新的请求和响应消息。 该政策可让您对这些消息执行以下操作：

  • 添加新的表单参数、标头或查询参数到消息
  • 复制现有消息到另一消息
  • 从消息中移除标头、查询参数、表单参数和/或消息载荷
  • 设置消息中现有属性的值

借助“分配消息”，您通常可以添加、更改或移除请求或响应的属性。不过，您也可以使用 Assign Message 来创建自定义请求或响应消息，并将其传递给替代目标，如创建自定义请求消息中所述。

使用自定义代码进行复杂的重写

对于复杂的数据处理和重写规则（其复杂程度超出“分配消息”政策的功能范围），您可以使用过程式语言，例如 JavaScript、Java 或 Python。您可以向 API 代理添加自定义代码，然后从添加到代理流的政策中调用该代码。对过程式代码的支持旨在让您更轻松地实现对流变量、故障以及请求和响应正文的复杂处理。

借助过程化代码，您可以：

  • 创建或操纵复杂的正文值，例如请求和响应值。
  • 重写网址，例如屏蔽目标端点网址。

Apigee Edge 针对支持的语言提供单独的政策：JavaScript 政策、Java Callout 政策和 Python Script 政策。

故障处理

通过 Apigee，您可以使用 Raise Fault 类型政策执行自定义异常处理。Raise Fault 政策是 Assign Message 政策的一种变体，让您可以生成自定义故障响应来响应错误情况。

共享流

共享流可用于强制执行故障消息的标准化。例如，检测到后端返回特定 HTTP 错误代码的同一组配置的政策可用于重写错误响应，以返回通用错误消息。

API4:2019 缺少资源和速率限制

威胁说明

如果不实施速率限制政策，攻击者可能会通过拒绝服务攻击使后端不堪重负。

使用以下 Apigee 功能可以轻松应对此威胁：

  • 配额和 Spike Arrest 政策作为预防性控制措施，用于限制入站 API 请求的流量
  • 使用 Apigee Sense 动态检测和响应由机器人驱动的攻击
  • 高级 API 监控和提醒（作为检测性控制措施），以便在 DDoS 攻击正在进行时收到提醒

使用配额和 Spike Arrest 政策实现速率限制

Apigee 提供了两种用于速率限制的政策：

  • 突增流量拦截提供了一项在 API 代理级别定义的通用政策，用于限制后端收到的入站请求总数
  • 配额提供了一种精细的政策工具，用于在 API 代理或 API 产品级别强制执行配额政策

Spike Arrest

SpikeArrest 政策可防范流量激增。此政策会限制 API 代理处理并发送到后端的请求数，从而避免性能滞后和停机，并使用可在政策中定义的滚动平均值。

配额

借助Quota政策，您可以配置 API 代理在一段时间（例如分钟、小时、日、周或月）内允许的请求消息数量。您可以为所有访问 API 代理的应用设置相同的配额，也可以根据以下项设置配额：

  • 包含 API 代理的产品
  • 请求 API 的应用
  • 应用开发者
  • 许多其他条件

此政策比“峰值流量限制”政策更精细，通常应与“峰值流量限制”政策同时使用。

使用 Apigee Sense 进行机器人检测

借助 Apigee Sense，您可以采取措施来明确允许、屏蔽或标记来自特定客户端、IP 范围或自治系统组织的请求，前提是这些客户端或位置表现出恶意或可疑行为。Apigee Edge 会在 API 代理处理请求之前，对请求执行这些操作。例如，系统可以检测到表现出“暴力猜测”行为的 IP 范围或特定客户端，然后将其屏蔽或标记。

使用 Advanced API Ops Monitoring 进行威胁检测

使用流量提醒可在环境、代理或区域的流量在某个时间范围内变化达到指定百分比时发出通知。此功能可在流量显著偏离预期吞吐量时（例如在 DDoS 攻击期间）动态发出提醒。这些提醒可以轻松发送到第三方日志记录和监控解决方案。

API5:2019 功能级授权中断

威胁说明

此威胁是 API1 的变体，也是一种授权漏洞。在这种威胁下，攻击者能够通过向他们未经授权访问的函数发送请求来执行操作。例如，如果 API 端点不验证 HTTP 请求谓词，攻击者可能会通过将 GET 替换为 PUT 或 DELETE 来修改或删除他们仅有权读取的数据。或者，如果未对 API 资源 URI 路径实施足够严格的访问权限控制，API 端点可能会允许攻击者通过简单地更改请求中的路径来查看其他用户的数据。

此类威胁凸显了使用 Apigee 作为中介和抽象层的价值，因为许多后端系统（并非为公开访问而设计）默认情况下可能会提供单个端点来执行多个业务逻辑功能，甚至包括高风险的管理功能。

为降低此威胁的可能性，概念性要素通常分为以下几类：

  • 保护哪些内容？考虑您的 API 产品策略，并在使用 RESTful 最佳实践设计 Apigee API 代理、产品和应用功能公开的路径和资源时，实现功能的逻辑分段。
  • 谁在访问您的 API 资源？定义高级别角色，并使用 Apigee 的一些身份验证和授权功能（如 API1 和 API2 中所述）实现“最低权限”默认访问权限。
  • Google 如何强制执行访问权限政策？使用条件流和故障来验证所有 API 请求的网址路径和动词。

图：此图演示了如何在 Apigee 中强制执行函数级授权，使用访问令牌中提供的范围作为授权。

使用 API 代理、产品和应用进行逻辑分段

Apigee 提供了一个高度灵活的工具包，可用于对 API 资源进行逻辑分段，从而将 API 代理捆绑到任意数量的 API 产品中，而这些 API 产品又可供应用开发者使用，应用开发者能够注册使用您的 API 产品的应用。可以在上述任何级别定义访问权限政策。

不过，为了实现有效的功能授权和细分，定义 API 产品策略至关重要。这一重要且持续进行的过程的一部分是定义 API 产品的“谁”和“什么”，即从客户和开发者的角度查看 API 资源，然后精确定义允许哪些类型的请求，细化到路径资源和 HTTP 动词级别。

图：捆绑到 API 产品中的 API 资源可以来自一个或多个 API，因此您可以混搭资源来创建消费层级和授权边界。

使用 OAuth 范围和 JWT 声明实现函数级访问权限控制

虽然上述针对 API1:2019 损坏的对象授权考虑的授权方法可在对象级实现精细的访问权限控制，但在函数级实现粗略的访问权限控制同样重要。请求用户是否允许请求此网址路径？此类政策通常是针对每种用户角色（客户、员工、管理员、内部或第三方开发者）定义的。

为降低配置错误的风险，建议您与安全团队合作，确保访问令牌中包含有关请求用户的断言，无论是通过使用 OAuth 范围还是 JWT 声明。

使用条件流程进行请求验证

从基础层面来看，REST API 调用包含以下内容：

  • 端点
  • 资源
  • 动作动词
  • 任意数量的其他请求属性，例如查询参数

此威胁中所述的攻击类型通常是由 API 请求的过滤不足引起的，因此攻击者可以执行未经授权的操作或访问受保护的资源。除了允许您根据访问令牌或声明过滤请求的条件逻辑之外，Apigee 还允许您根据请求本身实现过滤逻辑。

在清楚了解并定义 API 产品的业务逻辑、API 允许的功能后，下一步是通过以下 Apigee 产品功能来限制超出此范围的任何请求：

  • 条件逻辑和 Raise Fault 政策，用于在代理流配置的任何步骤中限制资源路径或动词
  • JSON 和 XML 威胁防护政策，用于防范使用畸形 JSON 或 XML 请求载荷发起的基于内容的攻击

API6:2019 大规模分配

威胁说明

通过 API 提供给客户端应用的不加过滤的数据，使攻击者能够通过请求猜测对象属性，或者使用端点命名惯例来寻找线索，以便在后端存储的数据对象上执行未经授权的修改或访问属性。

当未经过滤的数据（通常为 JSON 或 XML 格式）发送到客户端时，就会出现这种威胁，从而使攻击者能够猜测后端系统的底层实现细节以及机密数据元素的属性名称。此类攻击的结果可能会让攻击者能够读取或操纵不当数据，或者在最糟糕的情况下，可能会导致远程代码执行漏洞。

通常，允许此类威胁涉及两个方面：

  • API 设计视角。切勿依赖应用逻辑来执行客户端数据过滤，因为应用可能会被攻击者利用，并被视为可信应用。 在设计 API 数据架构时，请务必仅公开最少量的必要数据，以启用 API 服务
  • API 实现视角。实现数据过滤和架构验证，以防止机密数据意外暴露给客户端应用

从 Apigee 产品的角度来看，我们提供了多项实用功能，可确保您的 API 实现强大的数据过滤。

OpenAPI 规范过滤政策

借助 OASValidation（OpenAPI 规范验证）政策，您可以根据 OpenAPI 3.0 规范（JSON 或 YAML）验证传入的请求或响应消息。此政策允许您：

  1. 通过创建 OpenAPI 规范 (OAS) 来设计 API
  2. 使用 Apigee 实现必要的中介、安全和缓存逻辑，以安全地公开后端中的 API 产品
  3. 根据 OAS 规范中定义的数据架构验证传入的请求，包括 basepath、verb、request message policy 和参数

SOAP 消息验证政策

借助 SOAP 消息验证政策，您可以验证基于 XML 的请求，方法是根据 XSD 架构验证 XML 消息，或根据 WSDL 定义验证 SOAP 消息。此外，您还可以使用“消息验证”政策来确认 JSON 或 XML 消息载荷的格式是否正确，包括验证 XML 或 JSON 消息中的以下内容：

  • 存在单个根元素
  • 内容中没有非法字符
  • 对象和标记正确嵌套
  • 开始标记和结束标记相一致

API7:2019 安全配置错误

威胁说明

安全配置错误通常是不安全的默认配置、不完整或临时配置、开放的云存储、配置错误的 HTTP 标头、不必要的 HTTP 方法、宽松的跨源资源共享 (CORS) 以及包含敏感信息的详细错误消息所致。攻击者通常会尝试查找未修补的缺陷、常见端点或未受保护的文件和目录，以便未经授权访问或了解他们想要攻击的系统。 安全配置错误不仅会泄露敏感的用户数据，还会泄露可能导致服务器完全受损的系统详细信息。此外，安全配置错误漏洞的一些其他应用场景可能包括：

  • TLS 配置有误
  • 包含堆栈轨迹的错误消息
  • 未修补的系统
  • 公开的存储或服务器管理面板

组织可以采取各种措施来解决和缓解与安全错误配置相关的挑战，包括：

  1. 建立并标准化安全加固和补丁流程
  2. 围绕 API 生态系统制定治理策略
  3. 限制管理员访问权限并启用审核和提醒

共享流和流程钩子

Apigee 支持共享流的概念，借助该概念，API 开发者可以将政策和资源组合成一个可重复使用的组。通过将可重复使用的功能集中到一个地方，共享流有助于确保一致性、缩短开发时间以及更轻松地管理代码。您可以在各个 API 代理中添加共享流，也可以更进一步，将共享流放入流钩子，以便为部署在与共享流相同的环境中的每个 API 代理自动执行共享流逻辑。

API Monitoring

Apigee 提供了一个全面的 API 监控平台。借助 API Monitoring，组织可以主动检测 API 流量和性能问题。Apigee API Monitoring 可与 Apigee Edge for Public Cloud 搭配使用，以提供有关 API 性能的实时情境化数据洞见，帮助您快速诊断问题，并促进采取补救措施以确保业务连续性。

图：Apigee API Monitoring 提供各种工具来监控、调查和处理问题。它利用了 Google Cloud Platform 的一流智能功能。

Apigee Sense

Apigee Sense 可帮助保护 API 免受不必要的请求流量的侵扰，包括来自恶意客户端的攻击。Apigee Sense 会分析 API 请求流量，识别可能表示不必要请求的模式。

组织可以根据此分析结果识别发出不必要的请求的客户端，然后采取措施来允许、屏蔽或标记这些请求。借助 Apigee Sense，您可以保护 API 免受包含以下内容的请求模式的攻击：

  • 与人类行为相融合的自动化行为
  • 来自同一 IP 地址的持续尝试
  • 异常错误率
  • 可疑的客户端请求
  • 数据抓取
  • 密钥收集
  • 活动爆发
  • 地理位置模式

API8:2019 注入

威胁说明

将不受信任的数据（例如 SQL、NoSQL、XML 解析器、ORM、LDAP、操作系统命令和 JavaScript）注入到 API 请求中可能会导致执行非预期命令或未经授权的数据访问权限。攻击者会通过任何可用的注入向量（例如直接输入、参数、集成服务等）向 API 提供恶意数据，并期望这些数据被发送到解释器。攻击者在使用漏洞扫描器和模糊测试器查看源代码时，可以轻松发现这些缺陷。成功注入可能会导致信息泄露，从而影响保密性并导致数据丢失，在某些情况下，还可能会导致 DoS。

为缓解注入错误/攻击，最佳实践包括严格定义输入数据（例如架构、类型、字符串模式）、执行输入验证、限制检查并在运行时强制执行这些措施。Apigee 平台允许使用过滤器验证传入的数据，以仅允许每个输入参数使用有效值。

Apigee Edge 充当传入 API 请求的服务器，用于检查以确保载荷结构在可接受的范围内，也称为限制检查。您可以配置 API 代理，以便输入验证例程转换输入，从而移除有风险的字符序列，然后将它们替换为安全值。

RegularExpressionProtection 政策

RegularExpressionProtection 政策会从消息中提取信息（例如 URI 路径、查询参数、标头、表单参数、变量、XML 载荷或 JSON 载荷），并根据预定义的正则表达式评估这些内容。如果任何指定的正则表达式的评估结果为 true，则消息被视为威胁并遭到拒绝。正则表达式（简称 regex）是一组用于指定字符串中模式的字符串。正则表达式使得可以通过编程方式针对模式评估内容。例如，正则表达式可用于评估电子邮件地址，以确保其结构正确无误。

RegularExpressionProtection 最常见的用途是评估 JSON 和 XML 载荷中是否存在恶意内容。

没有任何正则表达式可以消除所有基于内容的攻击，因此应结合使用多种机制来实现纵深防御。本部分介绍了一些用于防止访问内容的推荐模式。

借助 Apigee 平台，您还可以通过下列几种方法来验证输入：

验证内容类型

内容类型是指通过 HTTP 传输的文件内容，并根据两部分结构进行分类。Apigee 建议使用条件逻辑验证请求和响应的内容类型，如下所述。

API9:2019 资产管理不当

威胁说明

环境管理和环境隔离不足，导致攻击者可以访问安全性较低的 API 端点。缺乏治理保障措施也会导致已弃用的资源不必要地暴露。

您可以利用 Apigee 成熟的功能来管理整个 API 生命周期，从而应对此威胁。这样一来，您就可以创建一个全面的治理模型，让团队之间能够协作，同时在安全利益相关者和 API 开发者之间实现责任分离。您可以使用以下方式配置和维护边界和控制措施：

组织、环境和修订版本：通过运行时上下文保证隔离和安全升级流程的虚拟和物理护栏。

基于角色的访问控制：只有 API 团队中必要的人员才有权管理配置更改和升级流程。

API 文档的受众群体管理：在开发者门户中发布 API 后，您可以通过管理目标受众群体来限制文档的公开范围。

流程钩子：您可以强制执行全局政策和模式，这些政策和模式可作为特权防护栏进行管理，API 开发者无法修改。

组织和环境

Apigee 中的配置制品、用户和功能可以限定到特定组织和/或环境。这意味着平台具有预构建的防护措施，可围绕 API 及其支持配置进行部署。

组织：组织是 Apigee 中的顶级租户。这样一来，您就可以完全隔离流量、配置和用户。作为治理方面的最佳实践，您应考虑分别设置生产组织和非生产组织。这种做法可有效避免将生产数据、用户和流量与较低环境混用。

环境：Apigee 中的 API 可以通过多个部署状态进行升级；每个状态都与一个执行上下文相关联。在升级过程中，不会携带环境上下文，因此避免向无特权用户公开敏感配置。

修订版本： 借助修订版本，API 和各项功能可以无缝地在各个环境中进行升级。

基于角色的访问控制

为了缓解 API9，必须明确定义安全利益相关方和 API 开发者之间的职责，并明确职责分离。如本文档前面所述，Apigee 具有灵活的基于角色的访问权限控制功能，可让您为自定义角色分配权限。对于此特定威胁，可以限定角色范围，使其在组织、环境或更精细的配置权限方面具有有限的权限。作为首选做法，请考虑限制通过环境更改 API 部署状态的权限，并确保开发者无法访问或修改全局安全库（流程钩子）。这些受限角色将防止对全球安全政策进行未经请求的更改，这些政策对旧版和当前已发布的端点具有广泛的覆盖范围。

API 文档的受众群体管理

开发者门户是 API 策略取得成功的关键组成部分；借助它，您可以全面记录与 API 相关的所有文档，包括主机/端点、资源、操作、载荷架构等。在 Apigee 中，您可以使用 API 产品结构对 API 进行分组。API 产品由属于同一业务和安全上下文（例如服务方案、业务网域、类别、公司层次结构等）的资源和操作捆绑包定义。

借助 Apigee 的集成式开发者门户，您可以发布 API 产品，并通过管理目标受众群体来限制已发布内容的公开范围。此功能符合与业务和安全要求相符的内容分段策略。

Flow Hooks

API 的推广和发布流程必须始终包含安全合规性和认证流程。为了提高效率，使用适当工具的 API 团队应能够创建安全护栏，以确保职责分离，同时保持敏捷的发布周期。

Apigee 可让您通过流程钩子强制执行全局政策，从而提升安全治理职责。这些全局政策可以作为特权防护栏进行管理，API 开发者无法修改，因此可保证职责分离，并通过应用默认安全设置来提高灵活性，进而为在给定执行环境中部署的所有 API 提供安全合规性。

图：可以在 Apigee 中通过流钩子和共享流配置特权防护栏。 安全利益相关方负责维护与安全相关的全局政策。这些功能可确保职责分离，并促进敏捷开发生命周期。

API10:2019 日志记录和监控权限不足

威胁说明

如果日志记录、监控和提醒功能不足，正在进行的攻击就可能无法被检测到，因此必须制定策略，以便深入了解对业务有影响的关键事件。

API 的事件和日志记录管理策略应考虑以下最佳实践：

  • 日志管理政策：记录并强制执行相关规则，以标准化和控制日志详细程度、日志级别、日志完整性、集中式代码库等
  • 事件管理政策：保证每个事件都应可追溯到其来源。此外，事件应能够按严重程度和业务影响进行分类
  • 报告和审核：安全和运营利益相关者应能够实时访问日志和事件并做出反应。此外，利益相关方可以执行强化周期，根据历史数据调整检测模式

Apigee 提供了必要的工具来制定全面的事件和日志记录管理策略。这些工具包括：

消息日志记录政策：根据 API 流量中的路况数据或元数据创建日志流。您可以灵活地利用条件逻辑和消息模板来决定流的详细程度。

Google 的 Cloud Operation Suite：利用与 Google 的高度可扩缩监控和日志记录工具的开箱即用型集成。

服务回调政策：添加了对需要 HTTP 端点来发送事件的日志流的支持。

Google Analytics： 通过开箱即用型报告和/或自定义报告访问和分析历史流量元数据。 根据趋势创建和管理提醒，并了解流量异常情况。

API 监控：如前所述，此工具提供提醒功能，可根据严重事件触发提醒。您可以进一步分析流量日志并采取相应措施。