基于微服务架构的网络安全等级保护实践

白金雪 金旺 马涛 王汝成 商兴男

摘   要：近年来，微服务架构成为最流行的应用软件实现模式之一，它支持将应用的每个模块进行单独部署，将业务功能进行解耦。文章将微服务架构与传统的单体架构应用进行对比，并在安全方面对微服务架构在设计、编码、部署等环节进行详细阐述，从信息安全等级保护角度，提出了提高接口安全性、服务节点内部以及服务节点之间安全性的措施。

关键词：微服务架构;等级保护;令牌环;单体架构

中图分类号：TP309          文献标识码：B

Abstract： The term "Microservice Architecture" has sprung up over the last few years to describe a particular way of designing software applications as suites of independently deployable services. This paper presents advantages of microservices over the monolith services from a security perspective. In the most important section of the article， introduces the security aspect in a microservices architecture during development processes including architecture design， coding and deployment process， summarizes how to improve the interface security， system security， avoiding unsafe node communications under the information security classified protection framework.

Key words： microservice architecture; classified protection; token ring; monolithic

1 引言

微服務架构是一种将单体应用程序作为一套小型服务开发的方法，每种应用程序都在其自己的进程中运行，并通常以HTTP/HTTPS/TCP RPC模式进行主机间或主机内通信。微服务架构早期在一些大型电商系统中应用较为广泛，随着架构的优势逐渐被大众所认可，微服务架构也在很多中小型系统中应用，但随之而来的安全问题逐年增多。本文将微服务与单体应用进行对比和分析，对微服务框架的优缺点及相关的安全问题及在网络等级保护评测的过程中需要关注的技术点进行归纳与总结。

2  单体应用架构

单体应用架构，也称巨石型架构，多用于中小型项目开发。传统的Web应用程序将所有的功能模块打包成为一个应用发布到Web应用服务器中，各个模块之间往往通过开放类的公共方法并进行线程上下文切换来实现本地相互调用。

2.1 单体应用架构的优点

单体应用架构比较适合于小项目，其具备几个优点：第一，开发过程及框架简单，业务逻辑清晰，模块间调用采用方法调用模式，不用考虑调用失败等异常处理的情况;第二，单体架构应用部署简单，应用可以被整体部署在一个Web容器中，各个模块功能都是完全的，不需要考虑模块间依赖的问题，若系统需要进行横向扩展，只需要增加机器，进行整包部署即可;第三，单体架构应用中所有功能模块之间通讯都在本地执行，没有分布式调用的性能及网络开销。

2.2 单体应用架构的缺点

虽然单体应用架构结构简单，适合于大多数应用场景，但是单体应用架构存在几点不足：第一，所有的功能在一个项目上面进行维护，系统依赖资源包多且复杂;第二，模块耦合度过高，一个小问题导致整个应用瘫痪;第三，应用构建时间长，任何小修改必须重新构建整个项目;第四，单体应用的扩展性不高，无法满足高并发情况下的业务需求;即便是需要扩展也要整个应用复制到不同服务器上面，并配置负载均衡;另外，每个业务模块对于硬件资源的利用并不相同，在单体应用中，在业务横向扩展时，整个应用被整体打包部署，无法根据不同的硬件资源消耗进行单独的调配。

3 微服务架构

区别于单体应用架构，微服务架构应用中的每个模块运行在不同的进程中，模块之间的调用采用RPC或HTTP方式进行调用，依靠XML/JSON进行传值，这些服务是围绕业务功能构建的，可以通过全自动部署机制进行独立部署。微服务架构区别于以往的单体式应用，它将各个业务模块进行独立部署，进行解耦。微服务应用中的各个模块可以部署在一台物理机的不同容器中，也可以部署在不同机器上。除了调用方式不同外，大多数微服务架构，如Spring Cloud、Dubbo还提供服务注册发现中心，通过此方式实现负载均衡、动态扩容、自动熔断等功能。

3.1 微服务架构的优势

随着大数据时代的到来，越来越多的互联网公司使用微服务技术并取得了不错的效果，也有一些技术创业公司，帮助一些大型传统企业，利用微服务架构理念解决现有系统架构的问题。微服务架构具有几项特性。第一，微服务架构具有低耦合性。将各个功能模块部署在不同的服务器/容器中，最大程度地分配利用系统资源，区别于单体结构，一台机器做了所有功能，不能充分发挥服务器的性能。第二，每个微服务模块独立存在，拥有各自的实现模式。开发者可以根据需求选择合适的开发技术，各模块之间采用通用的API协议进行数据返回，任何一个微服务模块的功能修改都不影响其他微服务模块功能的使用。第三，对于微服务架构中任何一个节点都可以进行主备切换，便于运维。

3.2 微服务架构的缺点及可能出现的安全隐患

微服务的目的是分布式、去中心化的，通过对应用进行有效的拆分，实现敏捷开发和部署。但为了实现这个目的，架构由此带来了一定的复杂性。开发者需要将应用逻辑在模块间进行进程间通讯，从而实现特定的业务逻辑。进程间通讯或主机间通讯过程中请求超时或者服务不可用等问题经常出现，相对于单体式应用中通过语言层级的方法或者进程调用，微服务应用架构在业务逻辑实现及数据流转、异常处理方面显得非常复杂。表1描述了单体架构与微服务架构之间的区别。

4 微服务环境在等保测评工作中可能出现的问题及解决方案

从安全角度讲，微服务架构是一个开放的架构，系统攻击面增加、开放的端口更多导致系统的安全性降低。另外，由于对服务接口的公开，使得安全保护策略变得更复杂。在信息安全等级保护工作进行过程中，需要对服务部署的主机环境、网络环境、主机间安全、微服务部署环境、接口安全进行安全检测。

4.1 主机间信任安全

微服务部署模式多种多样，其中最为广泛的是容器技术，如当今比较流行的Docker。在安全检测过程中需要对容器层面的安全进行关注，保证各容器之间得到有效的隔离，容器与主机操作系统之间采取怎样的保护措施将是要考虑的问题。和传统的主机信任机制一样，身份及访问管理在减小数据泄露风险上的作用。对容器环境的安全加固注意事项包括几个方面。

（1）小心使用镜像仓库，对于从远端下载的镜像要检查其各项安全配置，一定要非常熟悉镜像的项目发布者，避免内置安全漏洞，时刻注意Docker服务的官方发布版本，进行安全升级。

（2）对Docker宿主机按照等保级别要求进行安全加固，务必保证Docker宿主机的安全，主机加固方法可以参考相关级别的安全Checklist及相关主机安全规范。

（3）限制同一主机内部不同容器之间的网络流量，每个容器都有可能访问同一主机内部的不同容器资源，可能会导致意外泄露信息。

（4）用Root或超级权限启动Docker容器，会将默认的Docker守护程序更改为绑定到TCP端口或任何其他Unix套接字，那么任何有权访问该端口或套接字的人都可以完全访问Docker守护程序。建议创建Docker用户组用户，用Docker組用户启动，降低系统风险。如果使用Root身份运行的容器，需要映射为Docker主机特定用户。

（5）容器默认使用主机的所有内存，可以使用内存限制机制来防止一个容器消耗所有主机资源的拒绝服务攻击。

（6）编排工具及平台的安全性监测。越来越多的使用容器进行部署的开发者使用编排工具进行自动化部署及运维，编排工具及平台的安全防护措施也是需要特别注意。

4.2 服务验证及授权安全

微服务架构为软件应用带来许多好处，包括小型开发团队，更短的开发周期，语言选择的灵活性和增强的服务可扩展性，同时也存在一些问题，其中的一个挑战就是如何在微服务架构中实现灵活、安全和有效的身份验证和授权方案。

区别于单体式架构中使用Session和Cookie在浏览器方与服务器端进行安全验证的方式，在微服务架构下，应用程序被分成多个微服务进程，每个微服务器在原始单个应用程序中实现一个模块的业务逻辑，每个微服务的访问请求需要进行身份验证和授权。微服务模块之间安全认证的解决方案如下。

（1）启用安全套接层

使用超文本传输协议HTTP，以明文的形式传输数据，将会把数据暴露给黑客，因此为保证各模块间数据的安全性，建议采用SSL加密传输。

（2）启用水平流量审计

除了来自用户和第三方的垂直流量之外，微服务之间还存在大量的水平流量，这些流量可能位于同一局域网中，也可能位于不同的数据中心内，第三方存在这些微服务之间的流量，通过启用流量审计及SSL对微服务之间的数据传输进行加密。

（3）使用微服务认证框架

1） 具有API网关的客户端令牌

API网关是外部请求的唯一入口，所有请求都通过API网关，可以有效地隐藏微服务，分离各种API和内部组件，以减少暴露的被攻击面。API网关认证方式如图1所示。

2） 使用JWT（Json Web Token）等第三方安全服务框架进行微服务认证。

3） 令牌由用户自己持有，并且通常以Cookie的形式存储在浏览器中。令牌保存用户的身份信息，并且每次将请求发送到服务器时，服务器因此可以确定访问者的身份并确定其是否可以访问所请求的资源。

4） 使用OAuth2.0规范，对于用户授权访问的管控方面推荐使用Spring的OAuth2规范进行用户授权访问管控。

4.3 微服务API开发安全

潜在的黑客、恶意软件或任何匿名的局外人都可能轻易地尝试一系列攻击，如XSS、SSRF或SQL注入。为保障微服务API的安全，可以通过几个方面来防范。

（1）使用HTTPS安全协议，或使用非对称加密算法的安全签名。

（2）确保API请求使用时间参数，防止重复请求以及恶意伪造请求攻击。

（3）存储敏感数据应该使用加密算法，不要采用明文或者纯文本形式存储，选用比较成熟稳定的加密算法，不要使用处于测试阶段的加密算法，他们可能存在未知漏洞。

（4）采用链路监控组件，及时发现业务逻辑调用过程中执行慢速的接口模块，如Spring Cloud体系中的Sleuth组件。

（5）分离各种API和内部组件，以减少暴露的被攻击面。

（6）优化微服务API参数，避免缓慢HTTP拒绝服务攻击，XSS跨站脚本注入等安全漏洞。关注每年更新的OWASP Top 10，审查自身有无类似安全漏洞，特别注意RCE（远程命令执行）漏洞，例如Struts2框架漏洞、反序列化漏洞等。

（7）注意API接口的返回值中是否有多余字段，可能涉及敏感信息，应遵循最小化原则只返回必须的字段。这些信息可能会在某些情况下暴露在应用程序的日志中，或是被其他服务无意中访问到，从而带来安全隐患。

4.4 服务高可用性监测

微服务的分布式处理固然有相应的好处，但是考虑到单点处理、集中管理、负载均衡、备份、容灾、热备等方式的同时，也带来了新的问题点。单点处理故障，分布式处理的高可用性如何处理;还有其高可用性安全如何去保证，因此在微服务处理便捷的同时，也会出现新应用、新技术面临的新的安全风险点。

（1）从网络层面分析双机热备，解决了单点故障造成的风险，而双机设备之间的通讯采用生成树的方式和加密技术的方法，来实现网络中双机热备的高可用性的安全。

（2）从应用层面分析得出服务器双机热备、异地双活、容灾、负载均衡、集群等方式，消除了磁盘的单点故障、软件的单点故障、系统运行时的单点故障。主服务器故障时，备份服務器能够自动接管主服务器的工作，并及时切换过去，以实现对用户的不间断服务，既而这之间采用一些加密技术来解决这些方式带来的高可用性安全。

5 结束语

本文内容提出了在信息系统安全等级保护测评过程中对微服务架构进行测评的注意事项。为规范微服务架构安全应用标准，在等保测评工作中，除对所测评系统进行最基本的系统级别测评外，建议在建设初期从架构安全方面进行全方面规划。通过对微服务的部署环境安全、接口认证安全、API安全及审计、高可用性监测安全方面制定有效的安全架构方案，并在开发过程中，对开发人员进行程序级别的安全培训，在系统实施过程中增强运维人员关于系统安全方面的安全意识，从而提高微服务应用整体的可用性及安全性。

参考文献

[1] GB/T 22239-2008，信息系统安全等级保护基本要求[S].

[2] 潘孝阳，黄晓芳.微服务框架的安全管控机制的设计[J].西南科技大学学报，2018， 33（4）：74-78.

[3] 常艳，王冠.网络安全渗透测试研究[J].信息网络安全，2012（11）：3-4.

[4] 白璐.信息系统安全等级保护物理安全测评方法研究[J].信息网络安全， 2011（12）：89-92.

[5] 马力，毕马宁，任卫红.安全保护模型与等级保护安全要求关系的研究[J].信息网络安全，2011（6）：1-4.

[6] 肖国煜.信息系统等级保护测评实践[J].信息网络安全，2011，36（7）：86-88.