基于微服务架构的移动应用安全检测系统设计与实现

于炳虎

摘要：本文根据当前移动应用市场现状，以微服务架构为基础，设计实现了一套安全有效的移动应用安全检测系统，该系统使用简单、扩展性强，为应用安全检测领域提供了切实可行的方案。

关键词：移动应用;安全检测;系统漏洞;微服务

中图分类号：TP311.52 文献标识码：A 文章编号：1007-9416（2018）11-0169-03

0 引言

近年来移动互联网的迅猛发展，带动了移动终端设备的智能化、全能化和多样化的发展，与此同时，智能手机的信息安全问题却变得日益严重，手机安全隐患越来越多，尤其是终端应用APP的信息安全问题变得极为突出。据某第三方互联网安全中心数据显示，2017年该中心共截获安卓平台新增恶意程序样本1523万个，新增手机勒索软件18万，180万台手机遭到攻击。截止目前，安卓操作系统手机的市场占有率达到了85.9%，作为智能手机中市场占有率最高的移动操作系统，它关系着众多手机用户的工作与生活的方方面面，随着各种软件缺陷和系统漏洞的不断爆出，现存的安卓智能手机危机重重，虽然手机安全软件能够解决一些安全隐患，但操作系统中的漏洞和应用软件的漏洞仍未能有效修补，攻击大门依旧打开，漏洞一旦被利用，依旧会对用户造成巨大的损失。中国泰尔终端实验室做过一项抽样测试，该实验室现隶属于工业与信息化产业部的电信研究院，此次抽样测试针对目前在市场上销售的77家手机厂商的262款终端，并综合手机应用和系统的漏洞总数、严重程度、漏洞修复比例和漏洞修复延迟时间，对手机终端产品进行了全面的安全水平的评估。最终测试结果显示，安卓手机安全漏洞隐患极为严重。为此，本文立足移动应用市场现状，设计实现一套安卓系统平台的安全有效的移动应用检测系统，旨在解决当下日益严重的信息安全问题。

1 相关技术介绍

1.1 应用检测技术

安卓平台中最为常见的攻击类型主要有：逆向分析、二次打包以及篡改，用户手机一旦受到上述攻击，会导致用户的个人信息和隐私数据等发生泄漏，对用户的切身利益等带来损害。安卓应用以安装包格式发布，程序文件打包成安装文件，安装文件类型是一个压缩包，安装前传输至终端设备上，这个压缩文件里面包含属性文件、配置文件、资源文件、字节码文件等多种类型的文件，软件结构较为简单，只需修改相應配置文件、启动组件或者广播组件等，恶意代码就可以植入进去，当应用正常运行的时候，恶意代码随之运行[1]。

目前，国内外针对移动应用的安全防护主要从三个方面着手，应用安全检测、应用安全加固和应用安全监测。其中，安全检测具有安全预防作用，主要用于检测出应用潜在的安全风险与安全漏洞，自动化检测和人工渗透测试是主要测试方法，通过对移动应用进行全面的检测，扫描出应用代码中潜在的安全风险、系统漏洞等问题，帮助开发者提高其应用开发程序的安全性，有效预防可能存在的安全风险。应用安全加固相当于在原有应用的程序外层加上一个保护壳，此环节是移动应用最为直接有效的安全防护环节，可以做到防逆向、防篡改、防调试和数据保护，有效预防攻击者的恶意行为。应用安全监测以大数据分析为基础，收集各类应用数据进行分析挖掘，识别出有安全隐患或者漏洞的应用，发出预警信息。检测、加固、监测是当前应用安全检测服务的主要技术和实时手段，国内外安全企业都是围绕这三方面来打造自己的安全产品[2]。

1.2 微服务架构

微服务是近几年流行的一种架构思想，或者叫做架构风格，它提供了一种将应用程序进行服务拆分，设计为可独立部署的服务套件的一种方式，最早于2014年提出。微服务架构风格是一种使用多个小服务来开发单体应用的途径，面对当前日益复杂的应用系统，单体应用暴露出来的问题越来越多，复杂性逐渐变高，无法按需伸缩，部署成本高等问题。而在微服务的设计中，服务拆分后，是相互隔离的，每个服务运行在自己的进程中，并使用轻量级HTTP机制进行通信，基于业务功能构建服务是服务拆分的关键，通过自动化部署机制，每个服务独立部署，因为使用的HTTP通信机制，这些服务可以使用不同的编程语言实现，以及不同数据存储技术。资源的有效隔离是微服务设计的主要原则，这个原则类似于进程中资源隔离的概念，每个微服务拥有独立的数据资源，微服务之间的数据请求和调用，都只能调用微服务对外暴露的接口来完成，接口机制有效避免了服务之间争用数据库和系统资源所带来的问题。去中心化、组件化是微服务架构的主要特点，相对于传统的SOA架构和单体架构，微服务架构的服务粒度更小，每个服务是针对一个单一职责的业务逻辑的封装，能够独立被部署并运行在一个进程内。这种运行和部署方式使得系统代码组织方式更加灵活，发布效率更高，使得快速交付产品和应对需求变化成为可能，而且在开发阶段，技术选型更加灵活，不同业务问题选择更加合适的技术，微服务架构是更加面向业务创新的一种架构模式[3]。

2 系统需求分析

为了实现功能的系统化、自动化和网络化，移动应用安全检测系统主要提供两项核心功能，应用检测和应用签名。考虑到平台的管理功能，本系统设计的用户角色有两类，前端普通用户与后台管理员，前端普通用户指的是使用此系统申请应用检测和申请应用签名操作，目标获取检测报告和签名应用的用户，管理员主要负责检测与签名操作的管理，以及用户、检测报告、系统平台等管理。系统功能模块如图1所示，详细功能需求描述如下：

（1）普通用户。系统注册和登录，用户可以注册平台账户，并且使用已注册的账户登录系统，在登录状态下可以注销账户，退出系统。创建和管理应用，用户可以创建应用，包括上传应用，填写应用属性信息。用户可对所属应用进行管理操作，包括删除和查看详情。申请应用检测，用户可以申请应用检测，等待管理员审核。查看和下载检测报告，审核通过，检测完成，管理员发布报告后，用户可以查看应用检测报告，并且可以下载报告文件。申请应用签名，应用检测完成后，用户可以申请应用签名，等待管理员审核。下载签名应用，审核通过，签名完成后，用户可以下载已签名的应用。

（2）管理员。系统后台登录和退出，管理员使用已分配的账户可以登录系统后台，在登录状态下管理员可以注销账户，退出系统。应用检测管理，管理员可以查看所有创建应用的信息和应用状态，可以查询应用，可以查看应用详情、删除应用、下载应用。用户申请应用检测，管理员可以审核通过和驳回申请，通过后，管理员可以向检测引擎提交检测请求，开始签名操作。已完成检测的应用，管理员可以发布/关闭检测报告，发布后普通用户可以登录系统查看，关闭后用户不可以查看报告。应用签名管理，管理员可以查看所有已创建应用的信息，应用状态和签名状态，可以查询应用，可以查看应用详情、下载应用、进行应用签名操作。用户申请应用签名，管理员可以审核通过或驳回申请，审核通过后，管理员可以生成签名应用，用户可以下载签名后应用。用户未申请签名的状态下，管理员可以授权签名，签名后用户不可下载，只有管理员可下载。检测报告管理，管理员可以查看所有已生成的检测报告，可以根据报告编号或者应用名称查询具体的检测报告，可以预览报告详情，下载检测报告。用户管理，管理员可以查看所有已注册平台的用户，可以根据用户名和手机号查询具体的用户，可以删除用户账户，可以启用或停用某一用户，停用后，此用户无法登录系统平台。

3 系统架构设计

移动应用安全检测系统基于微服务架构设计开发，微服务架构按照业务的功能进行服务拆分，服务粒度要合适，并不是越小越好，应以业务功能为拆分基础，微服务是去中心化的分布式架构，各服务是有功能意义的服务，无论是在开发阶段或部署阶段都是独立的。本系统按业务功能拆分为以下5个服务，用户服务、应用服务、检测服务、签名服务和检测报告服务，系统架构如图2所示。

4 系统实现

系统基于微服务架构设计实现，在微服务框架的选用上，本系统使用了SpringCloud，它是基于SpringBoot的一整套实现微服务的框架，提供了微服务开发所需的整套组件，包括服务注册发现组件、负载均衡组件、断路器组件、API网关组件、配置管理、控制总线、分布式会话和集群状态管理等组件。具体实现中，以系统架构设计中的服务拆分和微服务架构为基础，从以下6点描述。

（1）服务注册中心。首先搭建服务注册中心，SpringCloud提供了服务注册和发现组件Eureka，利用Eureka组件可以很方便地实现服务注册和服务发现的功能，创建appcheck-center-server工程，添加依赖，引入Eureka组件，编写配置文件，在配置文件中增加端口号、实体名称等信息。

（2）注冊服务。搭建完服务注册中心后，开始创建各个服务，系统已拆分为5个服务，以应用服务为例，创建appcheck-subservice-apk工程，添加依赖引入Eureka组件，编写配置文件，在配置文件中添加服务实例的端口号，和注册中心地址等信息，修改客户端代码，在项目的引导类上添加注解@EnableEurekaClient，该注解用于声明标注类是一个Eureka客户端组件，编写服务的实体层，DAO层，逻辑层，控制器层等代码，实体层与数据库映射，每个服务连接独立的数据库服务，服务之间使用rest接口交互。完成上述配置后，分别启动服务注册中心和应用服务，此时，在服务注册中心处可查看到，应用服务已注册进来，可以提供服务了。

（3）负载均衡。应用服务等各服务之间相互调用是通过HTTP通信协议来实现的，为了保证服务的高可用，同一个服务被部署在了多个应用上，SpringCloud提供了负载均衡组件Ribbon来实现此功能，Ribbon会利用从Eureka读取到的服务信息列表，在调用服务实例时，以合理的方式进行负载。在本系统的服务实现中，考虑到迭代成本，未使用Feign组件，在通信方式上，使用的是RestTemplate，实现负载均衡，以应用服务为例，在appcheck-subservice-apk工程的引导类的restTemplate（）方法上添加注解@LoadBalanced，在用户服务实例的查询方法中，使用服务提供者的实例名称来执行已注册服务列表中实例的方法。例如检测服务调用应用服务的查询应用信息的方法，请求地址http：//appcheck-subservice-apk，URI中使用的已经不是主机地址+端口号的形式了。

（4）断路器组件。本系统的5个服务中，应用服务是基础服务，在整个业务逻辑中被调用次数最多，如果基础服务出现故障可能会级联传递，导致整个服务链上的服务不可用，SpringCloud提供了Hystrix组件来实现断路器、线程隔离等服务保护功能。断路器是可以实现弹性容错，在一定条件下能够自动打开和关闭。具体实现，在appcheck-subservice-apk工程的引导类中开启断路器功能，添加注解@EnableCircuitBreaker，修改控制器类，在逻辑方法上使用注解@HystrixCommand标注，此注解用于指定当前方法调用异常时回调的方法，该方法是通过其属性fallbackMethod的值来指定的，回调方法的参数类型以及返回值必须要和员方法保持一致。

（5）API网关服务。微服务系统通过将资源以API接口的形式暴露给外界提供服务，在微服务系统中API接口资源通常是使用路由网关统一暴露，内部服务不直接对外提供API资源的暴露。SpringCloud提供了组件Zuul来实现API网关服务，Zuul属于边缘服务，可以用来执行认证、动态路由、服务迁移、负载均衡、安全和动态响应处理等操作。在本系统的实现中，创建API网关工程appcheck-gateway-zuul，添加依赖，编写配置文件，在配置文件中指定Zuul的唯一标识，在工程主类Application中使用@Enable ZuulProxy注解开启Zuul的API网关功能。

（6）配置中心服务。本系统从开发到实际部署运行，经历多个周期，每个周期的配置文件不同，所以此处使用了微服务的统一配置管理，SpringCloud提供了Config组件，具体实现，搭建分布式配置中心工程appcheck-config-server，它是一个独立的微服务应用，主要用于集中管理应用程序的各个环境下的配置，默认使用Git存储配置文件的内容，本系统已搭建Git服务器，创建好工程后，添加依赖，编写配置文件，添加服务端口号和存储属性等信息，其中需配置config.server.git.uri，此属性用来指定Git仓库的网络地址。以应用服务为例，在使用具体配置文件时，添加cloud.config.label和cloud.config.uti属性，指定配置文件属性即可。

5 结语

本文主要介绍了基于微服务架构的移動应用安全检测系统的设计与实现，所设计的移动应用安全检测系统可以实时在线完成应用的安全检测，包括漏洞扫描、恶意代码检测和仿冒应用检测，用户可查看并下载检测报告，在完成应用检测后，可以继续进行应用签名操作。本系统的实现是从用户的实际需求出发，有效提高了应用的安全等级，可以在一定程度上帮助净化移动应用市场，促进移动互联网的长期健康发展。

参考文献

[1] 蔡晓燕.可扩展的跨平台移动应用开发框架的研究与实现[D].复旦大学，2012.

[2] 张振南.对计算机信息传输安全及防护技术分析[J].自动化与仪器仪表，2013（6）：126-127.

[3] 邓杰文，曹彩凤.微服务若干关键问题研究[J].五邑大学学报：（自然科学版）2016（2）：49-54.

Design and Implementation of Mobile Application Security Detection System Based on Microsoft Service Architecture

YU Bing-hu

（the First Research Institute of the Ministry of Public Security，Beijing  100048）

Abstract：Based on the current situation of mobile application market and on the basis of micro-service architecture， this paper designs and implements a secure and effective mobile application security detection system， which is simple to use and scalable， and provides a feasible scheme for the application security detection field.

Key words：mobile applications; security detection; system vulnerabilities; micro-services