什么是 API 安全？

API 是 Application Programming Interface（应用程序编程接口）的首字母缩写。与保护个人基本信息（例如社交媒体上与个人用户身份关联的密码）一样，在后端保护 API 的访问也同样重要，可以避免 API 密钥和 API 调用等标识符被滥用。

API 相关的安全风险日益增加并不奇怪，因为几乎任何可用的 Web 应用程序或 Web 服务多少都会由 API 提供支持。从移动应用程序和物联网 (IoT) 设备，到内部应用程序和基于云的客户服务，再到微服务架构，API 使业务通信和交易成为可能。

因此，在您的 IT 团队中，Web API 安全和 API 管理必定是整个 API 生命周期中的关键优先事项。但是，云迁移、现代 DevOps 实践和不断发展的 API 令保护 API 免受安全威胁变成了一项艰巨的挑战。

API 安全防护是企业用来保护支持业务流程运转的 API 的一种系统化方法。这些 API 可能包括：

• 为了让客户或业务合作伙伴轻松访问业务功能和数据而实施的 API
• 业务合作伙伴使用的 API
• 在内部实施和使用的 API，目的是让应用程序功能和数据能够以标准化和可扩展的方式供各种系统和用户界面使用

有效的 API 安全防护策略必须包含具备以下功能的系统化方法：

• 评估风险和潜在影响
• 执行适当的抵御措施

评估风险的第一步是为企业发布和使用的所有经批准和未经批准的 API 建立完整的清单。此清单应包含以下属性：

• 数据分类，至少区分“不敏感”、“敏感”和“非常敏感”的数据
• 风险指标，例如 API 漏洞和配置错误

这些都是评估影响和确定风险抵御工作优先顺序的重要基石。

API 监测和风险抵御措施必须考虑各种潜在的威胁集合，包括：

• 检测并防止使用未经批准的“影子 API”
• 识别并修复攻击者可能利用的 API 漏洞和配置错误
• 防止 API 滥用实例，例如业务逻辑滥用和数据抓取

要想识别这些漏洞和其他 API 安全风险并减轻影响，需要采取足够成熟的安全控制措施来应对这种复杂且快速变化的威胁态势。但同样重要的是想方设法将 API 安全防护实践扩展到影响 API 安全防护态势的非安全工作流（例如软件开发和文档编制）之中。

API（应用程序编程接口）是现代 Web 开发的一个关键部分。但实力越强，责任越大。就 API 而言，这种责任在于确保安全。API 安全防护其实就是保护应用程序之间的接口。如果不采取妥善的 API 安全防护措施，敏感数据可能就会泄露，系统可能会被入侵，而服务也会随之中断。本质上，API 安全防护就是阻止非法活动，同时让合法活动顺利开展。

身份验证和授权是 API 安全防护的两个基本要素。身份验证是验证用户、设备或系统身份的过程。这就像在俱乐部门口检查身份证，目的是要确保进入的人身份相符。而授权是指确定经过验证的用户可以做什么和不能做什么。允许某个人进入俱乐部并不代表这个人可以走到吧台后面给自己倒饮料。在 API 领域，身份验证和授权可能涉及 API 密钥、令牌或 OAuth 等技术。

输入验证是 API 安全防护的另一个重要因素。输入验证是在处理发送到 API 的数据之前检查这些数据是否有效。可以把它想象成在电影院检票，检票员不会让持有另一部电影票的人入场，对吧？同理，输入验证是为了帮助防止恶意数据进入 API 并造成麻烦。

API 安全已经成为企业安全主管日益重视的一项要务。但不可否认的是，许多人对 API 安全知之甚少。API 已从一种实施细节迅速演变成战略性创新推动力。为此，许多安全团队不得不仓促行动，努力完善 API 安全防护策略和实践。API 促进了商业发展，但也带来了敏感数据泄露的风险。

信息安全主管和安全从业人员不妨阅读以下一系列主题内容，巩固对 API 安全防护基础知识的理解。

Web API 是一种编程接口，由已定义的请求响应消息系统的一个或多个开放端点组成，通常以 JSON 或 XML 表示，并通过网络（最常见的是利用基于 HTTP 的 Web 服务器）对外开放。

大多数人听到“API”时想到的都是 Web API。它是端点的集合。端点由资源路径、可对这些资源执行的操作，以及资源数据的定义（JSON、XML、protobuf 或其他格式）组成。

该术语可用于区分 Web API 与其他 API，例如操作系统或库中面向同一计算机上运行的应用程序开放的 API。但在谈到企业数字化转型和 API 安全防护时，我们都认为“API”就是指基于 HTTP (Web) 的 API。

目前常见的 Web API 四种主要类型（基于 HTTP 的 API）如下：

• RESTful API——表现层状态转换 (RESTful) 可追溯到Roy Fielding 2000 年的博士论文，是最常见的 Web API 类型，通常使用 JSON（JavaScript 对象表示法）来交换数据。RESTful API 易于供现代前端框架（例如 React 和 React Native）使用，并可促进 Web 应用程序和移动应用程序的开发。这类 API 已成为各种 Web API（包括 B2B API）的实质性标准。
• SOAP API——SOAP使用详细的可扩展标记语言 (XML) 进行远程过程调用 (RPC)。在旧版 API 中仍然可以找到它。
• GraphQL API——Facebook 开发的新标准，通过单个 POST 端点（通常为 /graphql）提供数据库访问功能。GraphQL API 解决了 RESTful API 的一个常见问题（需要多次调用才能填充单个 UI 页面），但引入了其他附加问题。
• gRPC API——Google新开发的 HTTP/2.0 高性能二进制协议，主要用于东西向通信

企业对消费者 (B2C) API 是为 Web 应用程序和移动应用程序提供支持的 API。这些 API 通常由现代前端客户端使用，是为了让最终用户能够访问公司开放的业务功能。

企业对企业 (B2B) API 是公司业务合作伙伴（其他公司）使用的 API，有时用于向合作伙伴提供服务（这些公司作为最终客户），有时用于为共同的客户提供价值 (B2B2C)。

B2B API 是企业数字化转型的基础，因为这些 API 使企业能够简化与供应商、经销商和其他合作伙伴的合作方式，并为企业客户提供更好的体验。

B2B API 的例子包括：

• 开放银行 API
• 供应链管理 API
• 贸易伙伴之间的电子开票和付款

由于 API 的使用者差异巨大（使用 B2C API 的是面向用户的应用程序，而使用 B2B API 的是合作伙伴业务应用程序），因此用于保护这些 API 的安全控制工具也各不相同。

在安全方面，行业的关注点直到最近也仍然仅限于 B2C 应用场景，但即便在这些场景中，关注的重点也不是保护 B2C API，而是保护 Web 应用程序。用于保护 B2C Web 应用程序的安全控制工具很难经过转换来保护 B2C API（例如 WAF/WAAP），甚至完全无法转换（例如大部分爬虫程序防护解决方案）。

保护 B2B API 已经成为一个日益重要的问题。就 B2B API 而言，第一代供应商没有专门的监测和安全解决方案，来针对共享用户的批量数据访问提供安全保障（例如在开放银行业务中，金融科技公司和金融机构双方同意共享客户数据，就属于这种情况）。 

人们在使用“API”这个词时，通常他们真正想说的是单个 API 端点。API 有时称为服务或 API 产品，是为业务功能服务的端点集合。而端点是资源（或资源路径，也称为 URI 或统一资源标识符）和对资源执行的操作（创建、读取、更新或删除，RESTful API 中的操作通常对应 HTTP 方法：POST、GET、PUT 和 DELETE）。

这些 API 是企业对外（主要是业务合作伙伴）开放的 API。例如，支持开放银行业务的银行可能通过 API 向其他金融科技企业或金融服务企业开放其帐户。医疗保健企业可能通过 API 向保险公司和其他医疗企业开放患者记录。酒店企业可能通过 API 向旅行社或旅游信息采集平台开放其预订系统。API 是企业之间的连接纽带。南北向 API 通常被认为是安全的，因为 API 访问已获得授权并已经过身份验证。这些 API 通常增长极快且数量庞大，因此对大多数企业而言是一个很大的攻击面。

这些 API 是企业内部使用的 API，它们将内部应用程序或者业务单位（部门）连接起来。只要无法从企业外部访问，就视为东西向 API。

私有 API 有时也称为内部 API，供公司的开发人员和承包商使用。私有 API 通常是面向服务的架构 (SOA) 计划的一部分，用于支持不同的部门或业务单位相互高效访问彼此的数据，从而简化内部开发流程。

而公共 API 也称为外部 API，面向公司外部的使用者开放。这些 API 作为开放 API，在极端情况下任何人都可以自由使用。但无论如何，这些 API 都需要更严格的管理和完备的文档，这样才能让公司外部的工程师使用。

必须指出的是，可通过互联网访问的私有 API 从严格意义上讲终究不是私有 API。就以 ACME 的 B2C API 为例，这些 API 由 ACME 的工程师在内部开发，仅供 ACME 移动应用程序使用。您可能会认为这是私有 API，但其实该 API 的流量来自互联网（“公司外部”），因此它并不属于私有 API，只是没有记录而已。黑客每天都在攻击此类 API，他们通过拦截流量并对移动应用程序进行逆向工程，来找到对应的 API。

企业安全团队面临的 API 安全风险日益加剧，而随着使用 API 的客户互动和业务流程越来越多，这种挑战只会越来越大。

简言之，API 使用量迅猛增长，许多安全团队正在努力完善他们的 API 安全策略。

因此，API 安全迅速成为 IT 和安全主管的首要任务和一大关注领域。事实上，Gartner 的研究已指出：“到 2022 年，API 滥用将从原本频率较低的攻击类型发展成为导致企业 Web 应用程序数据泄露的最常见攻击媒介。”

虽然 API 安全防护和传统的应用程序安全防护是两个相互关联的领域，但 API 安全防护是一个全然不同的挑战，这主要是因为它有着独特的规模和复杂性。

API 使用量快速增长有三个因素：

1. 微服务（一种强制使用 API 进行服务间通信的架构）的使用日益广泛
2. 在直接用户渠道中，有 React、Angular 和 Vue 等现代前端应用程序框架使用 API，并且正在取代有时不使用 API 的传统 Web 应用程序
3. 除此之外，为了适应全新的渠道（本质上不同的渠道），也会添加 API，以支持合作伙伴、物联网和业务自动化

与 Web 应用程序不同，API 可以在许多不同的场景中以编程方式使用，这使得区分合法使用与攻击和滥用十分困难。

越来越多的企业使用 API 来实现与客户和合作伙伴之间双向的业务流程和数据共享。很多人都知道企业对消费者（有时称为 B2C）API 支持网站或移动应用程序中的数据交换。然而，后台触发的 API 网络也需要确保 API 到 API 的安全。例如，在您访问某个金融科技应用程序来查找财务信息时，便会形成从该应用程序到银行的企业对企业（即 B2B）API 调用，以验证您的用户身份。B2C 到 B2B API 调用形成的网络表明需要采取整体性的方法来保护所有 API 流量。B2C 和 B2B API 调用的复杂网络意味着企业还必须考虑 API 到 API 的安全。

我们建议企业从以下 12 个最佳实践着手来增强 API 安全防护：

• 设法将 API 安全防护标准和实践整合到企业的软件开发生命周期中
• 将 API 文档和自动化安全测试纳入持续集成/持续交付 (CI/CD) 管道
• 确保对 API 应用适当且有效的身份验证和授权控制
• 实施速率限制措施，帮助防止 API 滥用或崩溃
• 使用专用网关和/或内容交付网络增强速率限制和其他应用程序级措施，以抵御分布式拒绝服务 (DDoS) 攻击
• 让 API 安全防护测试成为更大范围的应用程序测试流程中不可或缺的一部分
• 执行持续的 API 发现
• 实施系统化的方法来识别和修复常见 API 漏洞，包括OWASP 十大 API 安全风险
• 使用基于签名的威胁检测和预防，作为针对已知 API 攻击的基准级防护
• 利用 AI 和行为分析来增强基于签名的检测，使 API 威胁检测的扩展性、准确性和业务相关性更强，并且能够抵御新型威胁
• 确保 API 安全监控和分析持续数周并覆盖多个 API 会话
• 作为对 API 安全监控和告警的补充，为威胁搜寻人员、开发人员、DevOps 和支持人员提供对 API 清单和活动数据的按需访问权限

实现 API 安全防护最佳实践的理想方法是使用如下的框架来思考企业成熟度。

API 漏洞是一种软件错误或系统配置错误，可能导致攻击者利用这类错误来访问敏感应用程序功能或数据，或者造成 API 滥用。

 OWASP 十大 API 安全风险清单十分实用，其中概括了一些被广泛滥用的 API 漏洞，企业应该尽力识别和修复这些漏洞。

 OWASP 十大 API 安全风险清单对于希望改善 API 安全态势的企业来说是个很好的起点。清单中的类别涵盖了各种可能的API 风险。但需要注意的是，OWASP 十大 API 安全风险清单包含的类别非常广。因此，重要的是将关注点放在每个类别的子领域进行深度探讨。

还有一些 API 风险完全不在 OWASP 十大 API 安全风险清单中，例如逻辑错误滥用。例如，API 攻击者经常利用授权问题（OWASP 中普遍涉及），同时也尝试滥用逻辑错误（OWASP 完全未涉及）。

API 会受到多种方式的攻击和滥用，以下是其中一些常见的例子：

• 漏洞利用：底层基础架构中的技术漏洞可能会导致服务器受损。此类漏洞的例子很多，从 Apache Struts 漏洞（CVE-2017-9791、CVE-2018-11776 等）到 Log4j 漏洞（CVE-2021-44228 等）都包括在内。
• 业务逻辑滥用：这些可怕的场景时常让首席信息安全官 (CISO) 彻夜难眠，因为传统的安全控制措施对此毫无用处。逻辑滥用是指攻击者利用应用程序设计或实施的缺陷来引发意外行为和未经批准的行为。
• 未经授权的数据访问：API 滥用的另一种常见形式是攻击者利用失效的授权机制来访问其无权访问的数据。这些漏洞有很多名称，例如失效的对象级授权 (BOLA)、不安全的直接对象引用 (IDOR)，以及失效的功能级授权 (BFLA)。最新的漏洞列表可以在OWASP API 安全项目网站上查看。
• 帐户接管：在凭据被盗乃至 XSS 攻击之后，帐户可能会被接管。一旦发生这种情况，即使是编写得最好、安全性最高的 API 也可能被滥用。毕竟，如果不执行行为分析，任何经过身份验证的活动都被视为合法使用。
• 数据抓取：如果企业通过公共 API 提供数据集，攻击者就可能积极查询这些资源，以便批量捕获大体量、有价值的数据集。
• 业务拒绝服务 (DoS)：API 攻击者如果请求后端执行繁重任务，可能引发应用程序层的“服务侵蚀”或完全拒绝服务（GraphQL 中十分常见的一个漏洞，但任何资源密集型 API 端点实施都可能发生这种情况）。

后端 API 使开发人员能够快速、高度可重复地访问核心应用程序服务。这对于通过各种不同的用户界面提供数据的企业来说尤其重要。在保护后端 API 时，必须采取的一个重要措施就是实施健全的身份验证和访问模式。但同样重要的是，不要认为一组经过严格验证的后端 API 永远不会被滥用。

攻击者会利用移动应用程序或 Web 界面中的漏洞，引发用户界面与后端 API 之间的意外交互和未经批准的交互，这方面已经有很多例子。要想保护后端 API 免遭这些类型和其他类型的滥用，最好的办法是持续开展行为分析。建立后端 API 的基准使用模式将能够检测异常并采取主动措施来保护后端 API，阻止在初始开发和实施过程中可能未预料到的攻击媒介。

在不断变化的市场和业务需求推动下，API 也在不断演变。为了满足新的业务需求、修复错误和实现技术改进，企业不断发布新的端点实施，这些端点的旧版本会被弃用。

但管理旧端点的停用过程并非易事。那些本应弃用的端点经常会继续存在而且可以访问，这些端点被称为僵尸 API。

寻找企业范围影子 API 的最佳方法是从覆盖范围最广的源中提取和分析 API 活动日志数据。围绕每个 API 按应用程序部署传感器可以提供关于 API 活动的丰富信息，但显然无法实现大范围覆盖，因为还有遗留 API 或不为人知的影子 API。

API 活动数据日志源的例子包括：

• 内容交付网络 (CDN)
• API 网关
• Web 应用程序防火墙 (WAF)
• Kubernetes 容器编排

收集到所有可用源的原始数据后，可以使用 AI 技术将其转换为人类可理解的清单，其中包含所有 API、端点和参数。在此基础上，可以执行进一步的分析来对这些元素进行分类，并识别应予消除或纳入正式治理流程的影子 API。

说到保护内部 API，其实要看“内部”的定义是什么。我们常听人们将通过互联网向自己企业的 Web 应用程序和移动应用程序开放的 API 称为“内部 API”。虽然这些 API 的文档确实可能只有公司员工和承包商才能访问，但黑客已经非常擅长于分析应用程序并通过应用程序反汇编工具包和代理（例如 Burp Suite）对服务于应用程序的 API 进行逆向工程。

然而，如果“内部 API”是指无法从企业外部访问的东西向 API，则主要威胁就只剩下内部威胁。

保护内部 API（按前一种含义）和企业对企业 (B2B) API 与保护大多数 API 一样：首先是保护安全软件开发生命周期 (SSDLC)，然后是确保 API 的访问经过身份验证和授权；还有管理配额、速率限制和尖峰抑制；以及利用 WAF/WAAP 作为针对已知签名的防护。

对于 B2B API，由于事务具有敏感性且通常为批量处理，因此可考虑添加（如果可能）严格的身份验证机制，例如 mTLS。

对于两种类型的 API，我们都建议采用行为分析的方法，特别是在涉及许多实体时更应该如此，因为这种情况下很难区分合法行为与非法行为。

例如：

• 您如何确定特定合作伙伴的 API 凭据是否已遭到泄露？
• 您如何判断开票 API 是否被合作伙伴滥用，特别是通过枚举发票编号来窃取帐户数据？

保护 B2B API 和内部 API 需要业务上下文，而业务上下文无法通过单独分析 IP 地址和 API 令牌等技术元素来获得。利用 AI 和行为分析来了解业务相关实体，是有效理解并管理 B2B API 和内部 API 风险的唯一方法。有了用户或合作伙伴等特定实体甚至业务流程实体（发票、付款、订单等）正常使用 API 的业务上下文和历史基准，就有可能发现原本无法检测到的异常情况。

许多企业都将 API 网关作为 API 安全防护的战略性措施。例如 Apigee、Kong、MuleSoft、Akamai、AWS API Gateway 和 Azure API Management。

大多数 API 网关都具有丰富的集成安全功能，其中第一个是身份验证（如果可以利用 OpenID Connect，还有授权功能），企业应对这些功能加以利用。

然而，仅仅在 API 网关进行身份验证、授权和配额管理并不够，原因如下：

• API 网关的发现缺口：API 网关只能监测和控制在网关配置中可以管理的 API，无法有效检测影子 API 和端点
• API 网关的安全缺口：API 网关可以执行身份验证，并在某种程度上执行授权方案，但不检查有效负载（WAF 和 WAAP 也是如此），也不会通过分析行为来检测滥用

鉴于 API 的使用方式多种多样，可能的 API 配置错误几乎数不胜数。但常见的主题不外乎以下几种：

身份验证是保护通过 API 公开的敏感数据的基础。第一步是确保所有承载敏感数据的 API 都预先设置了身份验证。但保护身份验证机制也很重要，可通过速率限制降低暴力破解攻击和撞库攻击的风险，并防止攻击者使用窃取的身份验证令牌。

有时，配置错误可能会导致 API 使用者绕过身份验证机制，这类错误通常与令牌管理相关（例如有些众所周知的 JWT 验证问题，或不检查令牌范围）。

API 最常见的一个用途是允许使用者访问数据或内容，包括敏感信息。而授权是在公开数据之前验证 API 使用者是否有权限访问这些数据的过程。授权可以在对象级或资源级进行（例如，您可以访问您的订单，但不能访问其他人的订单），也可以在功能级进行（管理功能就是常见的例子）。

由于存在大量的边缘情况和条件，而且微服务之间可以有各种各样的 API 调用流，因此很难确保授权不出错。如果没有集中式授权引擎，API 实施可能会包含其中一些漏洞，例如 BOLA（对象级授权失效）和 BFLA（功能级授权失效）。

除了上面提及的身份验证和授权问题外，安全配置错误还有很多可能的类型，包括不安全的通信（例如，未使用 SSL/TLS 或者使用了易受攻击的密码套件）、不受保护的云存储，以及过度宽松的跨域资源共享策略。

如果 API 的实施对 API 使用者可以进行的调用次数没有任何限制，攻击者可能会将系统资源耗尽，导致服务降级或完全拒绝服务 (DoS)。至少必须对任何未经身份验证的端点的访问实施速率限制（其中身份验证端点至关重要），否则必然会发生暴力破解攻击、 撞库攻击和凭据验证攻击。

API 攻击指的是企图将 API 用于恶意或其他未经批准的目的。API 攻击有多种形式，包括：

• 利用 API 实施中的技术漏洞
• 使用窃取的凭据和其他帐户接管技术伪装成合法用户
• 滥用业务逻辑，从而以无法预料的方式使用 API

网站和 SaaS 平台泄露用户 ID 和密码信息已经成为一种常态。通常，这些事件会导致大量凭据在网上大范围共享。

撞库是黑客使用以前入侵的网站泄露的身份验证凭据，对其他网站执行自动登录的做法。这种方法的前提是有一定比例的用户在多个网站上使用相同的凭据。

攻击者不通过前端（无论是 Web 应用程序还是移动应用程序）而直接对 API 发起这种攻击的现象越来越多。这样做可以更轻松地执行自动攻击，因为 API 毕竟是为了便于使用而创建的。

数据外泄是 API 攻击和滥用得手后的常见后果。在某些情况下，这是指攻击者通过 API 攻击和滥用窃取高度敏感的非公开信息。不过，也可能指的是不太严重的 API 滥用类型，包括对公开可用数据进行侵略性数据搜索，以汇总有价值的大型数据集。

开发实践。以下是安全主管在制定 API 安全防护策略时应考虑的重要趋势。

行为分析和异常检测：除了尝试预测可能的攻击和依靠基于签名的检测及预定义策略（例如 WAF）来降低风险，企业还越来越多地采用 AI 和行为分析方法，在业务上下文中查看 API 活动并检测异常。

从本地部署过渡到软件即服务：许多第一代 API 安全防护产品都部署在本地，但软件即服务 (SaaS) 方法因速度快、易于部署并且能够大规模利用 AI 和机器学习而越来越受欢迎。

分析的时间范围更大：企业逐渐摒弃分析单个 API 调用或短期会话活动的 API 安全防护方法，转而采用能分析几天甚至几周 API 活动的平台，利用这些平台完成基本的自动化 WAF 策略优化以及执行行为分析和检测异常等多方面的操作。

DevSecOps——考虑非安全利益相关者：为降低 API 风险，企业可以加强 API 安全防护策略和工具与参与创建、实施和配置 API 的开发人员和系统之间的联系，这是一种非常好的方法。

API 赋能的 API 安全防护策略：虽然检测和抵御活跃 API 攻击和滥用实例至关重要，但有远见的企业正在想方设法对 API 安全防护数据和见解使用按需访问策略，以改进威胁搜寻、事件响应和 API。

基于签名的 API 安全防护技术会监控已知的攻击特征和模式，并在观察到匹配项时生成安全告警并做出其他自动响应。但由于许多 API 攻击和滥用技术并没有签名，所以基于签名的检测价值有限（就 API 安全防护的一般情况而言）。

基于签名的检测整个前提是单个数据包或请求中存在某种警示标志。由于不必关注上下文（这个用户是谁？他/她上个月访问了多少个端点？），签名匹配引擎能够以极高的速度工作。但是，这也导致它完全没有检测到大多数 API 攻击。

API 安全防护需要上下文，通过用户发出请求的上下文来了解每个 API 请求、他们以前的请求以及所有用户的总体请求模式。因此，应使用基于行为分析和机器学习的 API 安全防护技术来检测异常使用。

API 检测和响应是 API 安全防护的新兴类别，它更注重对历史数据进行深入分析，以便：

• 建立所有 API 使用者的行为基准
• 检测预示潜在 API 滥用和误用的攻击和异常

由于资源密集型 AI 和机器学习技术需要大型数据集作为支持，所以只有在软件即服务 (SaaS) 模式下才能实现有效的大规模 API 检测和响应。

高级 API 威胁防护是基于 SaaS 的 API 安全方法，这种方法将行为分析与威胁搜寻结合在一起，以便：

• 发现企业使用的所有 API，包括影子 API 或僵尸 API
• 将机器学习运用到业务上下文，从中了解 API 的使用和滥用情况
• 将行为分析和威胁搜寻运用到 API 和存储时间较长的 API 活动数据

API 安全平台是一种基于 SaaS 的产品，经过特别设计，能够：

• 为整个企业内使用的所有 API（无论是否经过批准）创建持续更新的清单
• 利用 AI 和机器学习技术分析 API 及其使用情况，以发现业务上下文并建立预期行为的基准
• 检测 API 使用中的异常情况，并在必要时向安全信息和事件管理 (SIEM) 以及安全编排、自动化和响应 (SOAR) 工作流提供告警和支持数据
• 允许安全利益相关者和非安全利益相关者按需访问 API 清单、活动和威胁信息

企业使用许多不同类型的 API 安全防护技术来保护应用程序和敏感数据，避免发生滥用和其他类型的攻击。常见的 API 安全防护技术类型包括：

• 在开发和测试期间扫描 API 代码是否存在缺陷和漏洞
• 建立 API 威胁模型并实施输入验证等对策
• 在实施 API 时采用最佳实践，包括 TLS 加密、可靠且可扩展的身份验证和授权等
• 在 API 前面部署专门的工具，例如 Web 应用程序防火墙、爬虫程序抵御平台和 API 网关
• 定期进行漏洞评估，以识别任何配置错误或其他实施缺陷
• 执行持续的 API 发现，确保所有使用中的 API 都受到保护，或者在必要时停用
• 使用签名监控已知的 API 攻击技术
• 使用行为分析和异常检测来监控更复杂的 API 滥用形式
• 开展持续的威胁搜寻活动，尽早识别和抵御风险，并为开发和运营团队提供主动安全防护指导

所有这些类型的 API 安全防护技术都可以在整体安全策略中发挥作用，但重要的是采用综合实施方法，并将重点放在企业的具体风险状况上。

现在，IT 和安全领导者正以更具战略性的方法使用 API，他们可能需要专业 API 合作伙伴的支持。最常见的两种 API 公司是：

• API 网关公司，提供集中接受 API 调用并将调用发送到适当的后端资源和微服务的技术
• API 安全平台公司，确保企业了解所有活跃 API，检测攻击和滥用实例，并提供有关 API 使用情况的丰富数据

为了提早识别可能的威胁并采取响应措施，许多安全团队会开展主动威胁搜寻活动。很多第一代 API 安全产品为威胁搜寻团队提供的价值很有限，因为这些产品侧重于告警，根本不存储 API 活动数据，这意味着没有数据可供查询和搜寻。而更先进的 API 安全机制可以帮助公司存储上下文丰富的大型 API 活动数据集，并通过 GUI 和 API 将这些数据提供给威胁搜寻者加以利用。

Web 应用程序和 API 保护 (WAAP)是市场调研公司 Gartner 对新兴 Web 和 API 威胁划分行业覆盖范围时使用的一种分类。它是从 Web 应用程序防火墙 (WAF) 市场的早期行业覆盖范围发展而来的。随着 API 安全防护在战略上变得越来越重要，并且 WAF 平台以托管 SaaS 的形式迁移到云，WAAP 应运而生。

RESTful API（最常见的 Web API 类型）的 API 文档最常见的形式是基于 OpenAPI 规范的 Swagger 文件集合。理想情况下，API 文档由开发人员在设计或实施 API 时创建。但在现实中，API 文档经常失去时效，导致实际的 API 使用情况与文档不相符。为了解决此问题，有些 API 安全平台可以从实际 API 活动生成 Swagger 文件，突出文档记录与实际部署之间的差距，而这恰恰是任何 API 风险评估中不可或缺的部分。

有效的 API 安全防护需要许多详细的步骤和持续的实践。不过，在转用更复杂的 API 安全方法时，安全团队可从如下 API 检查清单入手：

• 企业 API 安全方法是否包含持续发现企业范围 API 的机制？
• 企业是否利用云/SaaS 来获取 AI 和机器学习技术，并避免不必要的部署复杂性？
• 企业的 API 安全防护方法是否会分析足够长时间（理想情况下为 30 天或更久）的数据？
• 企业的安全方法能否为团队提供他们需要的业务上下文，帮助他们真正理解 API 活动和观察到的潜在风险？
• 企业是否设有 API 安全平台与其他相关业务流程（例如 SIEM/SOAR、威胁搜寻、文档、DevOps 工具等）之间的双向自动化策略？
• 企业是否采取了措施将非安全利益相关者（例如开发人员）纳入 API 安全防护工具和流程的考量？

以下是安全语境中可能出现的 API 常见分类和说明。

熟悉以下术语对安全团队会有帮助，这些术语涉及 API 实施的不同使用模式和技术方法。

API 安全防护解决方案是指保护应用程序编程接口 (API) 以免发生恶意攻击和数据泄露的一套工具和实践。企业和机构普遍使用 API 来支持应用程序之间的通信和数据共享，以及执行各种功能。

然而，随着 API 的使用日益广泛，相关的安全风险也随之增加。API 可能面临一系列安全威胁，包括未经授权的访问、拒绝服务攻击和注入攻击。为了抵御这些风险，企业需要实施可靠的 API 安全防护解决方案。

API 安全防护解决方案包括：

• 身份验证和授权： API 安全防护解决方案涉及对访问 API 的用户进行身份验证和授权，确保只有已获得授权的用户才能访问和操作数据。身份验证方法包括多重身份验证、OAuth、OpenID Connect 和 API 密钥，而授权方法包括基于角色的访问控制和基于属性的访问控制。
• API 网关： API 网关作为所有 API 请求的入口点，是综合性 API 安全防护解决方案的组成部分。网关可以执行多种功能，包括身份验证、速率限制、流量管理和缓存，并且有助于防止分布式拒绝服务 (DDoS) 等攻击。
• 加密： API 安全防护解决方案还涉及加密，用于保护通过 API 传输的数据的安全，确保攻击者无法拦截数据。加密技术包括 SSL、TLS 和 AES 加密，可用于加密 API 请求、响应和静态数据。
• 速率限制： 速率限制是 API 安全防护解决方案的一项功能，通过限制用户在指定时间段内可以发出的请求数量，来帮助防止拒绝服务攻击。速率限制可以按不同的 IP 地址、用户帐户或其他参数来设置，有助于防止攻击者用大量请求淹没 API。
• 审计和日志记录： API 安全防护解决方案还应包括审计和日志记录，通过监测 API 活动来帮助检测和抵御安全威胁。审计涉及跟踪 API 请求和响应，而日志记录涉及用安全、防篡改的方式记录 API 事件和活动。
• API 测试： API 安全防护解决方案还涉及对 API 进行测试，以识别漏洞和潜在的安全风险。API 测试可以手动执行或使用自动化工具执行，有助于确保 API 安全无虞和按预期运行。
• API 监控和运行时保护： API 安全防护解决方案必须对 API 行为进行监控。了解正常行为与异常滥用的区别是保护 API 免遭恶意攻击的重要部分。
• 漏洞管理： API 安全防护解决方案还涉及漏洞管理，这包括识别和解决 API 中的安全漏洞。漏洞管理可以包括漏洞扫描、修补和修复，可帮助防止攻击者利用 API 中的已知漏洞。

API 安全防护解决方案对于确保 API 的安全性和完整性至关重要。通过实施身份验证和授权、API 网关、加密、速率限制、审计和日志记录、API 测试、监控、运行时保护和漏洞管理，企业可以确保 API 安全无虞并且免受各种安全威胁。

随着 API 日益成为企业运营中不可或缺的一部分，企业必须投资于可靠的 API 安全防护解决方案，以此来保护敏感数据和知识产权。

行为分析是一种使用机器学习和数据分析来识别用户行为异常和模式的安全方法。这种方法用于检测和防止内部威胁、帐户接管和欺诈等安全威胁。

随着 API 的使用越来越广泛，它们也日渐成为网络犯罪分子攻击的主要目标，这使得行为分析在 API 安全防护领域变得愈发重要。

企业使用 API 来支持应用程序之间的通信和数据共享以及各种功能的执行。然而，随着 API 的使用日益广泛，相关的安全风险也随之增加。

API 可能面临一系列安全威胁，包括未经授权的访问、拒绝服务攻击和注入攻击。通过采用行为分析技术来分析用户行为，并识别可能表明发生攻击的异常模式，可以帮助检测这些威胁。

行为分析 是 API 安全防护的关键组成部分，因为网络犯罪分子可能将 API 作为目标，以试图未经授权地访问敏感数据或扰乱业务运营。通过采用行为分析技术来分析用户行为，并识别可能表明发生攻击的异常模式，可以帮助检测这些威胁。

API 安全防护解决方案与行为分析相结合，有助于识别和防止以下类型的攻击：

帐户接管： 帐户接管是指攻击者获得合法用户帐户的访问权限，并使用这种权限来访问敏感数据或执行恶意操作。通过采用行为分析技术来分析用户行为，并识别可能表明攻击者已获得用户帐户访问权限的异常模式，可以帮助检测帐户是否已泄露。

内部威胁： 内部威胁是指有权访问 API 的受信任用户将访问权限用于恶意目的。通过采用行为分析技术来分析用户行为，并识别可能表明用户存在可疑或恶意行为的异常模式，可以帮助检测内部威胁。

注入攻击： 注入攻击是指攻击者将恶意代码或命令注入 API 请求中，以便利用漏洞并获得对敏感数据的非授权访问权限。通过采用行为分析技术来分析用户行为，并识别可能表明攻击者正在尝试利用 API 漏洞的异常模式，可以帮助检测注入攻击。

拒绝服务攻击： 拒绝服务 (DoS) 攻击是指攻击者用请求淹没 API 以图扰乱业务运营。通过采用行为分析技术来分析用户行为，并识别可能表明攻击者正在尝试用请求淹没 API 的异常模式，可以帮助检测 DoS 攻击。

随着 API 的使用越来越广泛，它们也日渐成为网络犯罪分子攻击的主要目标，因此企业必须投资于具备行为分析功能的可靠 API 安全防护解决方案，以保护其敏感数据和知识产权。

托管式威胁搜寻是一种主动安全方法，涉及使用先进的工具和技术来识别和抵御潜在的安全威胁，避免造成损害。

托管式威胁搜寻是少数 API 安全防护公司提供的一种服务。企业会向第三方提供商付费购买此类服务，让第三方代表企业管理和执行威胁搜寻。这种服务让企业可以受益于专业安全团队的专业技能和资源，而无需投资于建设内部威胁搜寻能力。

托管式威胁搜寻的托管性质意味着企业需要向 API 安全防护公司支付费用，然后让后者为企业执行威胁搜寻。这包括 API 安全防护公司对企业的 API 基础架构进行主动监控，分析日志和其他数据源，并使用机器学习和行为分析等先进技术来识别潜在的安全威胁。

然后，API 安全防护公司与企业合作，对任何已发现的威胁进行补救，并提供改善企业安全态势的建议。

托管式威胁搜寻在 API 安全防护领域尤其重要，因为 API 可能面临一系列安全威胁，包括注入攻击、帐户接管和拒绝服务攻击。

托管式威胁搜寻可以帮助识别和抵御这些威胁，避免给企业造成损害，从而保护企业的敏感数据和知识产权。

托管式威胁搜寻的关键组成部分包括：

• 主动监控和调查： 托管式威胁搜寻涉及主动监控企业的 API 以识别潜在的安全威胁。这可以包括监控所有 API 活动数据（包括系统日志和其他数据源），或者调查检测到的告警。
• API 历史数据的存储： 必须存储所有 API 数据，以便能够执行调查和威胁搜寻。数据访问权限是托管式威胁搜寻的前提条件。
• 高级检测技术： 托管式威胁搜寻使用机器学习和行为分析等先进技术来识别潜在的安全威胁。这些技术可以帮助识别基于签名的传统方法可能无法检测到的威胁。
• 威胁搜寻团队： 托管式威胁搜寻由专门的安全专业人员团队执行，他们在识别和抵御潜在安全威胁方面接受过专业培训而且经验丰富。API 安全防护公司在提供此类服务时，通常会组建一支具备 API 安全防护威胁领域专业知识的专家团队。
• 补救措施和建议： 托管式威胁搜寻涉及与企业进行合作，补救任何已发现的威胁并提供改善企业安全态势的建议。这可能包括修补漏洞、改进访问控制或在 WAF、CDN 或其他代理工具中实施其他安全控制。

在 API 安全防护方面，托管式威胁搜寻可帮助识别和抵御一系列威胁，包括注入攻击、帐户接管和拒绝服务攻击。

企业投资于托管式威胁搜寻可以确保 API 安全无虞并阻止各种安全威胁。