微服务：API网关在API安全中的作用

当从单体应用程序切换到微服务时，来自客户端的行为不能与以前一样，单体架构客户端只有一个入口点到应用程序。

现在，在使用微服务时，客户端必须处理来自微服务体系结构的所有复杂性，比如从各种服务聚合数据、维护多个端点、客户端和服务器之间增加的动态性以及对每个服务进行单独的身份验证。

客户端对微服务的依赖直接使重构服务变得困难。一种直观的方法是将这些服务隐藏在一个新的服务层后面，并提供针对每个客户端的APIs。

这个聚合器服务层也称为API网关，它是解决这个问题的一种常见方法。

基于API网关的微服务体系架构模式

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

典型的API网关包括:

1、安全性(身份验证和潜在的授权)

2、管理访问配额和节流

3、缓存(代理语句和缓存)

4、API组成和处理

5、路由(可能是处理)到“内部”API

6、API健康监测(性能监测)

7、版本控制(可能自动化)

API 网关的优势

1、在单独一个地方实现

2、简化了API源代码本身，因为这些关注点是外部化的

3、提供API的中心和独特视图，因此更可能允许一致的策略

API 网关的不足

1、可能的单点故障或瓶颈

2、复杂性风险，因为所有API规则都在一个地方

3、锁定和迁移的风险可能并不简单

API 增长创造了机会

要了解APIs的飞速增长，只需看看 ProgrammableWeb的统计数据即可，该网站自2005年以来一直在跟踪公开发布的APIs。当时，只列出了大约100个APIs。今天，有超过10000个公开的APIs。

这种增长正日益支撑着一个依赖于用户数据宝库的经济体。据报道，Salesforce.com每年30亿美元的营收中有50%以上是通过其api实现的，而Expedia每年20亿美元的营收中有近90%是通过其api实现的。

公司通过以各种方式计量API及其背后的资源获取API收益。例如，Twitter、Facebook和其他公司提供基于广告的API，允许基于报告和分析的定向广告，但广告代理和其他品牌必须为访问这些API付费。

API网关在安全性中的角色:Identity and Access

访问控制是API网关技术的头号安全驱动程序，它充当各种各样的管理器，以便组织可以管理谁可以访问API，并建立关于如何处理数据请求的规则。

访问控制几乎总是扩展到建立其他政策，包括对来自某些来源的API调用的费率限制，甚至通过API访问所有或某些资源的付费要求。

When all traffic is routed through a gateway, IT security experts feel more confident that they have their finger on the pulse of an organization.

API网关的访问控制功能通常从身份验证机制开始，以确定任何API调用的实际源。目前，最流行的网关是OAuth，它充当访问基于web的资源的中介，而不向服务公开密码，并保留了基于键的身份验证，以供企业承担丢失数据的风险，因为很难保证密钥的完全机密性。

Message Security

网关是将所有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网关可用于将后端错误消息转换为标准化消息，使所有错误消息看起来相似;这也消除了后端代码结构的暴露。

白名单和Whitelist-Allowable方法

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

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

对于服务来说，适当地限制允许的谓词是很重要的，这样只有允许的谓词才能工作，而所有其他的谓词将返回适当的响应代码(例如，a403 Forbidden)。

数据输入验证

利用松散的输入验证，黑客可以找到系统中的漏洞。使用现有的输入，攻击者将探索接受或拒绝的内容，并将可能的内容推送到API中，直到他们找到一种方法，破坏系统的完整性。

消息大小限制

有消息大小限制机制是合理额，如果你100%确定你不会收到大的消息(例如，超过2MB)，为什么不过滤掉呢?

SQL 注入攻击

SQL注入保护允许您阻止可能导致SQL注入攻击的请求。

JSON 攻击

JavaScript Object Notation (JSON) 容易受到内容级攻击。这种攻击试图使用巨大的JSON文件来压倒解析器，并最终导致服务崩溃。

XML威胁保护

对XML应用程序的恶意攻击通常涉及大量的递归有效负载、XPath/XSLT或SQL注入和CData，以压倒解析器并最终导致服务崩溃。

更多相关信息请访问这里.

限速

需要对所有API用户进行身份验证，以及对所有API调用的日志记录允许API提供者限制所有API用户的使用率。许多API网关允许您对任何一个API资源可以进行的API调用的数量设置上限，以指定秒、分钟、天或其他相关约束的消耗量。

开发源码的API 网关:

以下是一些值得一看的产品:

• Tyk
• WSO2 API Manager
• Kong Community Edition

结论

在谈到API安全性时，我们必须明白，安全性是公司、组织、机构和政府机构考虑向其API基础设施投入更多资源的首要问题，也是那些正在加大现有努力的公司的首要问题。与此同时，就现有API供应商在API基础设施方面的投资而言，这也是最欠缺的领域。许多公司都将API作为自己的产品来构建，部署web、移动、物联网和其他应用程序，但很少在开发过程中的每一步都停下来适当地保护东西，但是API网关是解决您将面临的许多安全问题的最流行和最有效的解决方案之一。