API 网关在 API 安全性中的作用

从单一应用程序切换到微服务时，客户端的行为不能与客户端具有该应用程序的一个入口点的行为相同。简单来说就是微服务上的某一部分功能与单独实现该应用程序时存在不同。

目前在使用微服务时，客户端必须处理微服务体系结构带来的所有复杂性，例如聚合来自各种服务的数据，维护多个端点，客户端和服务器之间的联系增加以及对每个服务进行单独的身份验证等，同时客户端对微服务的依赖性也直接导致了重构服务的困难。一种直观的方法是将这些服务隐藏在新的服务层后面，并提供针对每个客户端量身定制的 API。该聚合器服务层也称为 API 网关，它是解决此问题的常用方法。本文将介绍 API 网关在解决安全性方面的优势，详情请查看全文：

来自客户端的所有请求都首先通过 API 网关，然后网关再将请求转到适当的微服务。

典型的 API 网关包括

安全性（身份验证和潜在的授权）
管理访问配额和限制
缓存（代理语句和缓存）
API 的组成和处理
路由（“中转器”）到“内部” API
API 运行状况监视（性能监视）
版本控制（自动化流程）

API 网关的优势

在统一的位置管理和实施
将大部分问题外部化，因此简化了 API 源代码
提供 API 的管理中心和视图，更方便采用一致的策略

API 网关的缺点

容易出现单点故障或瓶颈
由于所有 API 规则都在一个位置，因此存在复杂性风险
被锁定的风险，日后系统迁移并不简单

API 的增长带来了机会和挑战

为了掌握 API 的飞速增长，人们只需要查看 ProgrammableWeb 的统计数据，该数据库自 2005 年以来一直在收集开放的 API。2005 年仅列出了大约 100 种 API，如今已有超过 10,000 个公共 API，这种增长越来越依赖于用户数据资料库的经济。据报道，Salesforce 通过 API 创造了其 30 亿美元年收入的 50 ％以上，以及 Expedia 20 亿美元年收入的近 90 ％。

公司通过以各种方式计算对 API 及其背后资源的访问来获得 API 收入。例如，Twitter，Facebook 和其他提供基于广告的 API，这些 API 允许基于报告和分析来进行有针对性的广告，但是广告代理商和其他品牌必须为访问这些 API 付费。

API 网关在安全性中的角色：身份验证和访问控制

访问控制是 API 网关技术的第一大安全驱动程序，它充当各种控制者，因此组织可以管理谁能访问 API 并建立有关如何处理数据请求的规则。访问控制几乎能扩展到建立其他策略，包括对某些来源的 API 调用的速率限制，甚至是通过 API 访问所有或某些资源的要求。

API 网关的访问控制功能通常从身份验证机制开始，以确定任何 API 调用的实际来源。当前，最流行的网关是 OAuth，它充当中介程序，用于访问基于 Web 的资源而不向服务公开密码，并且基于身份验证进行保留，在这种情况下企业可以承受丢失数据的麻烦，确保密钥完全保密。

通信安全

网关是一种通过单个通道连接所有 API 服务以评估，转换和保护整个组织中通讯的好方法。当所有流量都通过网关进行转接时，IT 安全专家能够动态到所有的项目动态。

API 网关可以在内部服务之间引入消息安全性，从而使内部服务更加安全，并且在服务之间来回传递的消息经过加密。即便使用传输层加密（ TLS ），忽略正确的身份验证也会导致问题。例如，在 API 请求中使用有效的手机号码，任何人都可以获取个人电子邮件地址和设备标识数据。像 OAuth / OpenIDConnect 这样的行业标准强大的身份验证和授权机制，以及 TLS，都是至关重要的。

威胁防护

没有威胁防护，API 网关，其 API 和集成服务器的本机服务基本上是不安全的。这意味着潜在的黑客，恶意软件或任何匿名的外部人员都可以轻松地尝试传播一系列攻击，例如 DDoS 或 SQL 注入。

API 是企业与世界进行数字连接的网关。不幸的是，有些恶意用户旨在通过注入“额外”的命令或表达式来删除，更新甚至创建可用于 API 的任意数据来访问后端系统。

例如，2014 年 10 月，Drupal 宣布了一个 SQL 注入漏洞，该漏洞使攻击者可以访问数据库，代码和文件目录。甚至攻击最严重的程度是，攻击者可以将所有数据复制到客户端站点之外，这将对企业造成多大的影响。注入威胁的类型有很多，但最常见的是 SQL 注入、RegExInjection 和 XML 注入。在现实中并不少见，我们已经不止一次地看到 API 在没有威胁防护的情况下上线了。

信息保护

许多 API 开发人员都习惯使用 200 代表成功请求，404 代表所有失败，500 代表内部服务器错误，在某些极端情况下，在详细的堆栈跟踪之上使用 200 代表带有失败消息的主体。当堆栈跟踪以程序包名称，类名称，框架名称，版本，服务器名称和 SQL 查询的形式揭示底层设计或体系结构实现时，可能会向恶意用户泄漏信息。

合适的做法是返回一个“平衡”的错误对象，该对象具有正确的 HTTP 状态代码，所需的最少错误消息，并且在错误情况下不进行堆栈跟踪。这将改善错误处理并保护 API 实施细节免受攻击者的侵害。API 网关可用于将后端错误消息转换为标准化消息，从而使所有错误消息看起来都标准化，这也消除了公开后端代码结构的麻烦和危险。

白名单和允许白名单的方法

考虑 IP 地址级别的 API 流量，应该有设备，服务器，网络和客户端 IP 地址的已知列表。根据网络的紧密程度，此列表的大小会有所不同。

RESTful 服务很常见，它允许多种方法访问该实体上不同操作的给定 URL。例如，GET 请求可能会读取实体，而 PUT 将更新现有实体，POST 将创建新实体，而 DELETE 将删除现有实体。

对于服务来说，适当地限制允许动词很重要，这样只有允许的动词请求才能起作用，而其他所有动词都将返回正确的响应码（例如，403 Forbidden ）。

讯息大小

有消息大小限制是很好的。如果你十分确认知道不会接收大文件消息（例如，超过 2MB ），那限制大小过滤掉大文件消息能尽可能避免一些未知攻击。

SQL 注入

SQL 注入保护使你可以阻止可能导致 SQL 注入攻击的请求。

JSON 威胁防护

JavaScript 对象表示法（ JSON ）容易受到内容级别的攻击。此类攻击试图使用巨大的 JSON 文件淹没解析器，并最终使服务崩溃。

XML 威胁防护

对 XML 应用程序的恶意攻击通常涉及较大的递归有效负载，XPath / XSLT 或 SQL 注入，以及 CData，以淹没解析器并最终使服务崩溃。有关输入验证的更多信息，请访问此处。

限速

需要对所有 API 用户进行身份验证，并记录所有 API 调用，从而使 API 提供程序可以限制所有 API 用户的使用率。许多 API 网关都允许你限制可以对任何单个 API 资源进行 API 调用的数量，以秒，分钟，天或其他相关约束条件来指定消耗量。

API 网关：开源

以下是一些值得使用的产品：

结论

在谈论 API 安全性时，我们必须了解，安全性是公司、组织、机构和政府机构考虑向其 API 基础结构投资更多资源以及保护现有工作的头等大事。同时，在现有 API 提供商投资 API 基础结构方面，它也是最不足的领域。许多公司都在自行构建 API 作为产品，以部署 Web，移动，IoT 和其他应用程序，但是在此过程中的每一步都需要保护信息的安全性，而 API 网关是针对这些应用程序的最受欢迎且最有效的解决方案之一。

参考资料

https://dzone.com/articles/the-role-of-api-gateways-in-api-security