如何保护 API 安全

本文介绍: 断路器 – 限制和配额 — 一个好的做法是强制执行每个应用程序的数据使用配额，以便后端在发生 DoS、DDoS 攻击时不会受到影响，或防止未经授权的用户不当使用 API。检查授权是否正确的方法有多种，包括基于内容的访问控制 (CBAC)、基于角色的访问控制 (RBAC) 或基于策略的访问控制 (PBAC) — 这些方法可确保业务数据得到充分保护，免受未经批准的访问。当客户端向 JWT 提供其 API 请求时，API 网关会验证 JWT 并验证其中的声明是否与您为客户端请求的资源设置的访问策略相匹配。

为了收集有关 API 管理当前和未来状态的见解，我们邀请来自 18 家公司的 IT 专业人士分享他们的想法。我们问他们：“哪些技术和工具对于保护 API 最有效？” 他们告诉我们的是：

验证
我们经常向已知的 B2B 合作伙伴提供 API 访问权限。在这种情况下，将 API 访问限制为仅合作伙伴 IP 地址（白名单）的功能非常强大。您仍然需要进行身份验证和速率限制，但您已将流量减少到仅已知的合作伙伴。这消除了向更广泛的互联网开放的 API 上出现的大量恶意流量，例如暴力尝试获取访问权限和拒绝服务攻击。
即使设置了 IP 白名单，设置 API 网关仍然是最佳实践。这有助于身份验证并确保后端仅接收格式正确的 API 调用。
最常见的是 OAuth 和OAuth2，用于 API 之间的通信和安全通信。下面是基于令牌和基于声明的身份验证，其中 API 来回传递数字签名的令牌，以验证令牌是否代表调用者。
提供商实施的身份验证不均衡。即使使用 OAuth，其他人保留令牌的方式也可能是一个问题。代币的生命周期是如何管理的？令牌会刷新吗？在我们自己的基础设施中，我们使用一次性令牌，其范围主要限于我们想要执行的操作类型。它归结为安全令牌管理和基于证书的身份验证。
始终在授权之前对 API 进行身份验证 — 进行 API 身份验证的方法有很多，但多因素身份验证是通常推荐的方法。对于 API，使用外部进程（例如通过 OAuth 协议）获取访问令牌是很常见的。身份验证密钥最为敏感，必须妥善保管；但是，建议使用管理存储来自动化整个过程。
也就是说，仅凭身份验证不足以授予对 API 的访问权限，应该有一个授权步骤来确定哪些资源可以访问 API。检查授权是否正确的方法有多种，包括基于内容的访问控制 (CBAC)、基于角色的访问控制 (RBAC) 或基于策略的访问控制 (PBAC) — 这些方法可确保业务数据得到充分保护，免受未经批准的访问。
速率限制
确保 API 环境的安全涉及每个 API 接触点——对 API 客户端（第三方应用程序和开发人员或微服务）进行身份验证和授权、限制 API 调用速率以减轻分布式拒绝服务 (DDoS) 攻击以及保护处理处理请求的后端应用程序。 API 调用。
用于保护 API 的一些技术和工具包括：
1) 使用 JSON Web 令牌 (JWT) 来验证和授权 API 客户端 – 这些令牌包括有关客户端的信息，例如管理权限或到期日期。当客户端向 JWT 提供其 API 请求时，API 网关会验证 JWT 并验证其中的声明是否与您为客户端请求的资源设置的访问策略相匹配。
2)定义和实施访问控制策略，仅允许某些类型的客户端执行写入操作或访问定价等敏感数据。
3) 定义基于角色的访问控制，仅允许某些用户（例如特定组织内的开发人员）发布暴露敏感信息（例如定价或库存水平）的 API。
4) 通过应用速率限制策略来保护 API 本身，该策略为 API 网关每秒（或其他时间段）从指定源（例如客户端 IP 地址）接受的请求数量设置阈值。
5) 使用 HTTPS 保护后端应用程序 — API 网关和处理 API 请求的后端系统之间的流量应使用 HTTPS 协议。
断路器 – 限制和配额 — 一个好的做法是强制执行每个应用程序的数据使用配额，以便后端在发生 DoS、DDoS 攻击时不会受到影响，或防止未经授权的用户不当使用 API。每个资源的限制和配额不仅可以起到断路器的作用，还可以防止在不必要的使用激增期间对下游系统产生负面影响。具有配额和限制等策略的复杂 API 管理平台可以提供此功能。
更广泛的
我们的 API 安全方法中的三个关键领域：
1) 采用规范性方法
2) 仔细考虑应用程序身份如何与用户身份相关联
3) 从身份验证之外的最广泛意义上考虑 API 安全性，以减少入侵尝试。
规范模型：客户转向 OAuth 2 并覆盖 Open ID Connect。OAuth 2 有很多选择，Open ID 限制了选择并指导人们采用最佳实践。最终，最好实施一个清晰易懂的标准。类似于存储领域，考虑安全性、可用性和可扩展性之间的平衡。
应用程序和用户身份的角色：有许多 API 管理供应商尝试同时做到这两点。它只是不可扩展。身份管理是如此强大，以至于您无法跟上变革和新标准的步伐。我们与外部身份管理解决方案集成，并具有完全开箱即用的集成或 OAuth2 和 Open ID 用例。我们有开放的接口供客户根据需要将我们替换为他们自己的实现。
对于更广泛的安全问题：我们采取分布式实施安全的方法。默认情况下，API 管理的重点是提供 API 网关。我们采取的方法是 API 网关应该专注于流量的身份验证和授权。我们建议采用多层方法，并在具有 Apa che Mod Security 的单独层中包含 Web 应用程序防火墙。当部署额外的安全性时要部署到网络边缘。最后是使用启发式或机器学习来监控流量行为并确定流量是否是恶意的。
其他
API 管理安全仍然是人们苦苦挣扎的领域之一。我们需要认识到 API 本质上是不安全的。我们需要重新学习 API 的安全性，并了解正在遭受攻击的互联网脆弱性。云提供商更加成熟。AWS 和 Azure API 管理工具提供了额外的安全层。考虑用户名、密码、密钥的安全性，并了解谁在使用您的 API。想想现在的数据，API 暴露的遗留系统在保护现有数据方面具有相同的思维方式。更多 API 消耗更多用户数据 — 如何存储以及在何处存储？
API 可能在两个主要方面构成安全风险。首先，依赖关系就像一组俄罗斯娃娃。在您的依赖项内部是依赖项的依赖项……在它们内部是您的依赖项、依赖项’、依赖项’等等。从功能角度来看，这使得每个开发组织都可以专注于为其添加最大价值的代码。
然而，从安全角度来看，作为最终消费者，您继承了整个漏洞链。应用程序安全专业人士必须超越基本的软件组成分析，将已知的 CVE 与版本字符串进行匹配，因为它们只深入一层。例如，Jackson-data bind 是一个流行的开源库，在许多第三方通信SDK 中得到利用。
困扰该库许多版本的“jacksploit”反序列化漏洞可供某些 SDK 用户利用，但 Jackson-data bind 的易受攻击版本已被混淆且无法被传统 SCA 识别。因此，安全专业人员必须寻找能够评估源代码如何工作的工具，而不是依赖于查找 CVE 数据库。
其次，由于 API 经常在外部传递数据，因此映射关键数据流以确保关键数据不会无意中泄漏到 API 中非常重要。这意味着要确定哪些变量至关重要，并绘制它们从源头到汇点的旅程以及途中的所有转换。这样，在将泄漏的路线投入生产之前，可以在开发过程中捕获未加密或未编辑的关键数据。
您需要拥有良好的 API 管理平台。它将强制执行您制定的规则和角色，以控制谁有权访问哪些数据。您可以使用带有选项的网关或平台，或者使用内置的身份验证和授权工具。能够以友好、易于配置的方式控制访问。Web 界面是执行和控制谁有权访问的最佳方式，无需部署或深入服务器并更新复杂的配置或文件。在网关级别进行控制，然后就可以轻松配置或管理。