【云原生应用安全】微服务架构下API业务安全分析概述

摘要

随着微服务架构的普及，微服务系统所面临的安全问题受到越来越多的关注。而API安全是微服务系统安全的重要组成部分。本文从业务安全层面介绍微服务架构中API所面临的安全问题和解决思路。

一、背景

随着微服务架构的普及，微服务系统所面临的安全问题越来越多的被业界提及和关注。在微服务架构中，各个微服务之间采用API进行互相通信。因此，API安全是微服务系统安全的重要组成部分。API所面临的安全威胁多种多样。OWASP（Open Web Application Security Project）提出了窃取隐私数据，未授权访问，注入攻击等威胁场景。除此之外，API也面临着许多业务层面的安全威胁，例如调用参数异常，调用频率异常，调用逻辑异常等。业务层面的安全问题往往没有明显的网络攻击特征，例如SQL注入，XSS等。因此对业务层面的安全分析也要采用与网络层面安全问题所不同的分析方法。本文接下来对微服务系统中API业务层面安全问题和分析方法做一个简要介绍。

二、API所面临的安全威胁

在微服务架构中，一个大的应用被拆分成为多个小的服务系统。这些小的系统自成体系，可以拥有自己的数据库，框架甚至语言等。例如，对于一个电商系统，其提供的主要功能如下：

• 买家侧：商品信息，购物车，订单管理，物流管理，评价反馈，咨询与投诉等。
• 卖家测：商品上架，库存管理，订单管理，物流管理等。

与传统的单体架构相比，采用微服务架构实现电商系统具有很多优势，尤其是它让敏捷开发和复杂的企业应用交付成为可能。在微服务架构中，电商系统的每一项功能可以作为一个微服务。微服务之间采用轻量级的通信机制相互沟通，例如基于HTTP的Restful API。API能够起到连接服务的功能，同时又可以用来传输数据。API为微服务架构的设计提供了便利，但是也为系统带来了新的风险。如果API被攻击或者存在漏洞，将会给相应的业务系统带来损失。例如2019年Instagram因API接口漏洞导致用户数据以及照片被泄露。因此针对API的安全防护非常重要。在微服务架构中，API同时面临着网络层面和业务层面的安全威胁。业务层面的威胁往往以从业务系统中获得经济利益为目的。下面以电商系统为例，介绍API所面临的业务层面的安全威胁。

• 调用参数异常：API调用过程中往往会传递相关的参数。参数的取值根据业务场景的不同会有不同的取值范围。例如商品数量必须为非负整数，价格必须大于0等。如果API对相应参数的监测机制不完善，那么攻击者往往可以通过输入异常参数导致业务系统受到损失。
• 调用频率异常：针对一个或者一组API的频繁调用，可能是有攻击者对系统进行拒绝服务攻击，或者是进行机器刷单，薅羊毛的操作。
• 调用逻辑异常：相比于前两类异常，这类异常一般较为隐蔽。攻击者采用某些方法使API调用的逻辑顺序出现异常，包括关键调用步骤缺失，颠倒等。例如在电商系统中，买家在购买商品的过程中需要按顺序调用一系列的API。而恶意的买家可以利用漏洞绕过交费的步骤直接提交订单。这样在API调用序列中就会出现缺失关键步骤的情况。

业务层面的威胁一般不具备网络攻击的特征，尤其是业务逻辑异常，其出现的往往很隐蔽。因此需要全新的方法来检测业务层面的API的异常，保障API的安全运行。

三、API的业务安全异常检测

针对API所面临的业务层面的安全威胁，不同的异常场景需要不同的异常检测机制。在上述提到的三种异常场景中，调用参数异常和调用频率异常的检测相对比较容易。可以通过人工设置参数类型，参数范围，调用频率的范围来检测这些异常。对于调用逻辑异常同样需要针对每一项业务建立API调用序列的基线。不同的业务对应着不同的调用序列基线。在一个复杂的业务系统中会包含多种业务。一个业务会调用多个API，而一个API也可能会被多个业务所调用。随着业务系统的规模越来越庞大，调用逻辑也越来越复杂。这样由人工维护调用序列基线的工作量就会非常大。同时，如果业务发生改变，例如新业务上线，业务逻辑变更等，对应的API调用序列都会发生变化。由人工维护调用基线的方法无法有效满足实时性。而基于数据分析的方法为这个问题提供了一个新的思路。通过对业务系统中历史的API调用序列进行追踪来建立API调用序列的基线。

四、API调用序列追踪

API调用序列追踪主要应用在对系统进行调试的过程中，用于监控多个微服务之间的调用关系和状态。根据追踪到的序列，可以确定每一种业务中API的调用关系。目前已经有一些开源的微服务架构下的API调用序列追踪框架，例如Jaeger，Skywalking等。不同的追踪框架对业务系统的侵入程度不同，因此追踪到的信息也会有所差别。以github上的一个开源电商系统mall[2]为例，通过部署Skywalking[1]对其API调用进行追踪，可以得到这个电商系统的服务拓扑图，如图 1所示。

图 1. 服务拓扑图

从图 1中的拓扑图可以看出，该电商系统包含三个主要的服务，即mall-portal，mall-search，mall-admin。在每个服务内部还有很多更加细致的API调用关系，如图 2所示。

图 2. API调用的树形结构

图 2中的树形结构标识了相应的API调用序列和底层的数据库操作。根据追踪到的API调用序列可以建立业务层面的API调用序列的安全基线。为了达到这个目的，在实际的业务安全场景中，需要对追踪的API序列进行进一步的聚合。根据业务场景的需求，聚合的维度也包括多种。例如在电商系统中，根据商品进行聚合可以对商品的库存状态进行跟踪，根据用户进行聚合可以对用户行为进行画像，根据会话进行聚合可以对每一次连续操作进行画像等。每一种聚合的方式都需要数据中具有特定的标识字段。这些字段不能被当前API追踪的开源项目全部采集到。其主要原因在于采集这些标识字段的过程中需要在目标微服务系统的源代码中进行埋点。这样就涉及到业务系统本身的业务种类和设计架构。为了能够准确地进行数据采集，需要对业务系统有深入的了解，并针对相应的业务系统定制化设计调用序列追踪方案。因此，微服务框架下的API业务安全与业务本身是强相关的。

五、总结

API业务安全是API安全的一个重要组成部分。业务方面的异常会给相应的业务系统带来巨大的损失。而由于API业务安全与业务场景的强耦合性，需要在系统设计之初就考虑各种业务场景下的API安全问题。一方面加强API的安全监测机制，例如鉴权，参数校验等；另一方面要加入必要的数据采集功能，为后续业务异常场景的分析提供支撑。

参考文献：

[1] https://github.com/apache/skywalking

[2] https://github.com/macrozheng