一种基于微服务应用的安全防护系统、方法及介质与流程

1.本技术涉及微服务应用技术领域，具体涉及一种基于微服务应用的安全防护系统、方法及介质。


背景技术：

2.近年来，云原生技术快速发展，在各行各业得到广泛应用。云原生技术的应用设计面向微服务架构，将单个应用拆分为多个微服务，每个微服务以容器的形式部署在容器编排平台中。在这种微服务架构下，业界一般通过istio平台对微服务之间的流量进行治理，以保证微服务应用的安全，istio平台是一个适用于云原生场景的服务治理的开放平台。
3.目前，主要通过istio的envoy容器中二次开发的扩展插件实现微服务应用的安全防护，由于二次开发的扩展插件与envoy容器存在适配问题，为了兼顾envoy容器的性能，开发人员编写的扩展插件的功能受到限制，能够检测出的恶意攻击类型依然较少。因此，现有技术中的envoy容器对微服务应用的安全防护能力较低。


技术实现要素：

4.本技术实施例提供一种基于微服务应用的安全防护系统、方法及介质，用于提高微服务应用的安全防护能力。
5.第一方面，提供一种基于微服务应用的安全防护系统，所述系统包括容器集pod，所述pod包括代理envoy容器和安全容器，其中：
6.所述安全容器，用于接收所述envoy容器发送的用户访问微服务应用的请求，从所述请求中提取多种预设参数类型的参数信息，根据所述多种预设参数类型的参数信息中是否存在与预设规则库中的预设规则匹配的参数信息，获得所述请求的检测结果，以及将所述检测结果发送给所述envoy容器，其中，所述预设规则库包括多个预设规则，每个预设规则包括一种恶意攻击的参数信息，所述检测结果用于指示所述请求为正常流量或恶意攻击；
7.所述envoy容器，用于接收所述检测结果，执行与所述检测结果对应的流量策略。
8.在本技术实施例中，安全防护系统单独设置了一个安全容器，envoy容器直接将用户发起的请求发送给安全容器，完全由安全容器对请求进行检测，不需要envoy容器参与，将系统的安全防护能力独立于envoy容器之外，安全容器和envoy容器之间不存在适配性问题，无需依赖envoy的开发模式及固有限制，进而可以对更多的恶意攻击进行检测，从而提高微服务应用的安全防护能力，降低了微服务应用被攻击的风险。
9.在一种可能的实施例中，所述pod还包括业务容器，其中：
10.所述envoy容器，具体用于接收所述检测结果，若所述检测结果指示所述请求属于正常流量类型，则将所述请求发送给所述业务容器；
11.所述业务容器，用于接收所述请求，对所述请求进行响应。
12.在本技术实施例中，envoy容器根据检测结果，确定用户发起的请求属于正常流
量，则将该请求转发给业务容器，以便业务容器正常响应该请求，以满足用户的访问需求。
13.在一种可能的实施例中，所述系统包括多个pod，每个pod包括一个所述envoy容器、一个所述安全容器以及一个所述业务容器，每个pod对应一个微服务应用。
14.在本技术实施例中，每个pod对应一个微服务应用，相当于每个pod的安全容器对应一个微服务应用，即使部分微服务应用对应的安全容器发生故障，也不会影响到其它安全容器对其他微服务应用的安全防护，具有更高的鲁棒性。
15.在一种可能的实施例中，所述envoy容器，具体用于接收所述检测结果，若所述检测结果指示所述请求为恶意攻击，则拦截所述请求。
16.在本技术实施例中，envoy容器根据检测结果，确定用户发起的请求为恶意攻击，则立即拦截该请求，避免该请求对微服务应用的攻击。
17.在一种可能的实施例中，所述系统还包括配置存储模块；
18.所述配置存储模块，用于存储所述多个预设规则；
19.所述安全容器，还用于实时监听所述配置存储模块中存储的所述多个预设规则是否更新，若确定所述多个预设规则中存在更新的预设规则，则获取所述更新的预设规则，更新所述预设规则库。
20.在本技术实施例中，可以对预设规则库进行实时更新，以便能够检测最新类型的恶意攻击。
21.在一种可能的实施例中，所述系统还包括日志收集模块和用户界面模块；
22.所述安全容器，还用于在获得所述检测结果之后，生成系统日志，并将所述系统日志发送给所述日志收集模块；
23.所述日志收集模块，用于接收并存储所述系统日志；
24.所述用户界面模块，用于从所述日志收集模块获取并展示所述系统日志。
25.在本技术实施例中，在获得检测结果之后，生成系统日志，并对系统日志进行可视化展示，方便运维人员查看每个请求的检测结果。
26.第二方面，提供一种基于微服务应用的安全防护方法，所述方法应用于安全防护系统的容器集pod的安全容器中，所述pod还包括代理envoy容器，所述方法包括：
27.接收所述envoy容器发送的用户访问微服务应用的请求，从所述请求中提取多种预设参数类型的参数信息；
28.根据所述多种预设参数类型的参数信息中是否存在与预设规则库中的预设规则匹配的参数信息，获得所述请求的检测结果，其中，所述预设规则库包括多个预设规则，每个预设规则包括一种恶意攻击的参数信息，所述检测结果用于指示所述请求为正常流量或恶意攻击；
29.将所述检测结果发送给所述envoy容器，以使所述envoy容器接收所述检测结果，执行与所述检测结果对应的流量策略。
30.在一种可能的实施例中，所述pod还包括业务容器，根据所述多种预设参数类型的参数信息中是否存在与预设规则库中的预设规则匹配的参数信息，获得检测结果，包括：
31.若所述多种预设参数类型的参数信息中不存在与预设规则库中的预设规则匹配的参数信息，则获得所述请求为正常流量的第一检测结果；
32.将所述检测结果发送给所述envoy容器，包括：
33.将所述第一检测结果发送给所述envoy容器，以使所述envoy容器接收所述第一检测结果，将所述请求发送给业务容器。
34.在一种可能的实施例中，根据所述多种预设参数类型的参数信息中是否存在与预设规则库中的预设规则匹配的参数信息，获得检测结果，包括：
35.若所述多种预设参数类型的参数信息中存在与预设规则库中的预设规则匹配的参数信息，则获得所述请求为恶意攻击的第二检测结果；
36.将所述检测结果发送给所述envoy容器，包括：
37.将所述第一检测结果发送给所述envoy容器，以使所述envoy容器接收所述第二检测结果，拦截所述请求。
38.在一种可能的实施例中，所述方法还包括：
39.若确定所述多个预设规则中存在更新的预设规则，则获取所述更新的预设规则，更新所述预设规则库。
40.在一种可能的实施例中，在获得所述检测结果之后，所述方法还包括：
41.生成系统日志。
42.第三方面，提供一种计算机可读存储介质，所述计算机可读存储介质存储有计算机指令，当所述计算机指令在计算机上运行时，使得计算机执行如第二方面中任一项所述的方法。
附图说明
43.图1为本技术实施例提供的一种基于微服务应用的安全防护系统的pod的结构示意图；
44.图2为本技术实施例提供的一种基于微服务应用的安全防护系统的数据平面的结构示意图；
45.图3为本技术实施例提供的一种基于微服务应用的安全防护系统的结构示意图一；
46.图4为本技术实施例提供的一种基于微服务应用的安全防护系统的结构示意图二；
47.图5为本技术实施例提供的一种基于微服务应用的安全防护系统的结构示意图三；
48.图6为本技术实施例提供的一种基于微服务应用的安全防护方法的流程图。
具体实施方式
49.为使本技术的目的、技术方案和优点更加清楚明白，下面将结合本技术实施例中的附图，对本技术实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本技术一部分实施例，而不是全部的实施例。基于本技术中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本技术保护的范围。在不冲突的情况下，本技术中的实施例及实施例中的特征可以相互任意组合。并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以按不同于此处的顺序执行所示出或描述的步骤。
50.本技术的说明书和权利要求书及上述附图中的术语“第一”和“第二”是用于区别不同对象，而非用于描述特定顺序。此外，术语“包括”以及它们任何变形，意图在于覆盖不排他的保护。例如包含了一系列步骤或单元的过程、方法、系统、产品或设备没有限定于已列出的步骤或单元，而是可选地还包括没有列出的步骤或单元，或可选地还包括对于这些过程、方法、产品或设备固有的其它步骤或单元。本技术中的“多个”可以表示至少两个，例如可以是两个、三个或者更多个，本技术实施例不做限制。
51.在介绍本技术实施例所提供的基于微服务应用的安全防护系统之前，为了便于理解，首先对本技术实施例中所提到的一些概念进行简单介绍。
52.1、微服务(microservices architecture)。
53.微服务是一种用于构建应用的架构方案，将应用程序拆分为多个核心功能，每个核心功能可以称为一项服务，换言之，一个应用程序可以拆分为多个微服务应用。微服务具有高度可维护、松散耦合、独立部署的特点。
54.2、服务网格(service mesh)。
55.服务网格是用于在微服务场景下处理服务间通信的基础设施层，通常实现方式为一组轻量级的网络代理，与应用程序一起部署，对应用程序透明。业界目前一般使用istio平台对微服务应用之间的流量进行治理。
56.3、容器(docker)。
57.容器是一个标准化的软件单元，它是将代码及其所有依赖关系打包，以便应用程序从一个计算环境可靠快速地运行到另一个计算环境的技术。
58.4、容器编排工具。
59.容器编排工具是一种按逻辑单位对应用的容器进行分组，以便管理和调度容器的工具。业界目前最常用的容器编排工具为kubernetes(k8s)。
60.5、sidecar容器。
61.sidecar容器一种单节点、多容器的应用设计形式。sidecar主张以额外的容器来扩展或增强主容器，而这个额外容器被称为sidecar容器。例如istio平台的envoy容器和业务容器。
62.在介绍了对本技术实施例中所涉及的概念之后，下面对本技术实施例的技术背景进行介绍。
63.目前，主要通过istio平台的envoy容器内置的安全插件和二次开发的扩展插件实现微服务应用的安全防护，envoy容器内置的安全插件中设置有多个过滤器，每个过滤器能够识别一种类型的恶意攻击，将用户发起的请求依次经过多个过滤器，可以获得该请求是否为恶意攻击的检测结果，根据该检测结果执行相应的流量策略，以保证微服务应用的安全。但是envoy容器自带的过滤器只能识别出一些简单的恶意攻击，随着网络日益复杂，恶意攻击的类型越来越多。开发人员可以二次开发，编写新的过滤器，集成在envoy容器的扩展插件中，从而检测更多类型的流量攻击。由于新的过滤器是按照envoy容器的标准和协议编写的，扩展插件与envoy容器之间存在适配性问题。因此，为了兼顾sidecar容器的性能，扩展插件能够提供的过滤器的功能也是有限制的，导致微服务应用的安全防护能力较低。
64.为了提高微服务应用的安全防护能力，本技术实施例提供一种基于微服务应用的安全防护系统。在本技术实施例中，首先需要搭建kubernetes集群环境以及istio平台，进
而使得本技术实施例中基于微服务应用的安全防护系统所包括的模块均在kubernetes集群环境下的istio平台中运行。也就是说，本技术实施例中基于微服务应用的安全防护系统是依托于kubernetes集群环境下的istio平台而实施。安全防护系统包括数据平面和控制平面，数据平面和控制平面运行在kubernetes集群中，kubernetes集群包括多个节点，节点分为主节点和从节点，从节点可以接收主节点的调度，并运行相应的微服务应用。例如控制平面可以运行在主(master)节点上，数据平面可以运行在从(worker)节点上。
65.本技术实施例提供的安全防护系统包括容器集(pod)，pod在安全防护系统的数据平面中，具体运行在kubernetes集群中。pod是kubernetes集群最基本的部署调度单元，也就是，微服务应用运行的最小单元，每个pod包括多个容器。
66.请参照图1，为本技术实施例提供的一种基于微服务应用的安全防护系统的pod的结构示意图，该pod包括envoy容器101和安全容器102。下面对envoy容器101和安全容器102的功能进行详细介绍。
67.安全容器102，用于接收envoy容器101发送的用户访问微服务应用的请求，从请求中提取多种预设参数类型的参数信息，根据多种预设参数类型的参数信息中是否存在与预设规则库中的预设规则匹配的参数信息，获得请求的检测结果，以及将检测结果发送给envoy容器101。
68.具体的，envoy容器101可以接收用户发起的访问微服务应用的请求，例如，若用户想要访问微服务应用，输入相应的网址或者点击相应的微服务应用图标，便发起访问微服务应用的请求。envoy容器101直接将该请求发送给安全容器102。
69.安全容器102集成了核心安全引擎及相应插件，为相对轻量级的安全容器。由于恶意攻击的类型有多种，每种恶意攻击的参数信息不同，安全容器102在接收请求之后，可以确定多种预设参数类型，例如安全容器102可以将该请求中携带的所有参数信息对应的参数类型确定为多种预设参数类型，或者例如安全容器102可以将预设规则库中的全部预设规则或部分预设规则对应的参数类型确定为多种预设参数类型。安全容器102中预存有预设规则库，预设规则库包括多个预设规则，每个预设规则对应一种恶意攻击，每个预设规则可以仅包括一种恶意攻击的参数信息，每个预设规则也可以包括一种恶意攻击的参数信息和攻击类型，攻击类型例如sol注入攻击、恶意的webshell上传等。
70.进一步，安全容器102确定多种预设参数类型之后，可以从请求中提取该多种预设参数类型的参数信息，例如请求具体为超文本传送(hypertext transport protocol，http)协议，安全容器102可以提取http协议携带的请求头、请求体、请求载荷等。若多种预设参数类型的参数信息中不存在与预设规则库中的预设规则匹配的参数信息，则获得请求为正常流量的第一检测结果，若多种预设参数类型的参数信息中存在与预设规则库中的预设规则匹配的参数信息，则获得请求为恶意攻击的第二检测结果。安全容器102获得该请求的检测结果之后，将该检测结果发送给envoy容器101，检测结果用于指示该请求为正常流量或恶意攻击。
71.下面以sql注入攻击为例，介绍安全容器102检测请求的过程。
72.例如，某请求的统一资源定位器(uniform resource locator，urlurl)为：“http://192.168.19.195:30012？id％3d-1％27％20union％20select％201％2c2％2c(select％20group_concat(schema_name)％20from％20information_
schema.schemata)％20
‑‑
％2b”。
73.该请求中的参数信息为：
[0074]“id％3d-1％27％20union％20select％201％2c2％2c(select％20group_concat(schema_name)％20from％20information_schema.schemata)％20
‑‑
％2b”。
[0075]
解码后的参数信息如下：
[0076]“id＝-1'union select 1,2,(select group_concat(schema_name)from information_schema.schemata)
‑‑
”。
[0077]
该解码后的参数信息与预设规则库中某条预设规则的参数信息匹配，说明该请求为恶意攻击。若预设规则还包括攻击类型，还可以进一步确定该请求属于恶意攻击中的sql注入攻击。
[0078]
envoy容器101，还用于接收安全容器102发送的检测结果，执行与检测结果对应的流量策略。
[0079]
由于检测结果不同，envoy容器101执行的流量策略不同，下面分别进行介绍。
[0080]
第一种，envoy容器101接收到第一检测结果。
[0081]
请继续参照图1，该pod除了包括envoy容器101和安全容器102，还包括业务容器103，业务容器103包括微服务应用的各种数据，用于对用户发起的请求进行响应。
[0082]
若envoy容器101接收到第一检测结果，即检测结果指示该请求为正常流量，则将该请求发送至业务容器103，业务容器103对该请求进行正常响应。例如，若用户请求访问该微服务应用的某一数据，业务容器103则调用对应的数据给用户。
[0083]
第二种，envoy容器101接收到第二检测结果。
[0084]
若envoy容器101接收到第二检测结果，即检测结果指示该请求为恶意攻击，则拦截该请求，避免该请求被继续转发，以保证微服务应用的安全。
[0085]
本技术实施例中，以非侵入式的方式在envoy容器和业务容器之间部署了一个安全容器，仅由安全容器对用户发起的请求进行检测，将安全防护能力独立于envoy容器之外，对istio自身代码逻辑达到了无侵入的特点，无需依赖envoy的开发模式及固有限制，可以检测更多类型的恶意攻击，从而提高微服务应用的安全防护能力。且，本技术实施例中安全容器一次性提取多种参数类型的参数信息，将多种参数类型的参数信息与预设规则库的多个预设规则进行匹配，相较于现有技术中依次通过多个过滤器的方式，检测效率更高。
[0086]
在一种可能的实施例中，该安全防护系统的数据平面可以包括一个或多个pod，换言之，kubernetes集群中运行着一个或多个pod，每个pod包括一个envoy容器、一个安全容器以及一个业务容器。当安全防护系统包括多个pod时，一个pod可以对应一个或多个微服务应用，下面分别进行介绍。
[0087]
一、一个pod对应一组微服务应用。
[0088]
本技术实施例中，可以对微服务应用进行分组，例如将功能相近的多个微服务应用分为一组，一个pod对应一组微服务应用，可以减少设置的安全容器的数量。
[0089]
二、一个pod对应一个微服务应用。
[0090]
本技术实施例中，一个pod对应一个微服务应用，换言之，一个pod中的安全容器与一个微服务应用对应，即使某微服务应用对应的安全容器发生故障，也不会影响到其它安全容器对其他微服务应用的安全防护，保证其他微服务应用的安全。
[0091]
请参照图2，为本技术实施例提供的一种基于微服务应用的安全防护系统的数据平面的结构示意图，该数据平面100包括多个pod，每个pod包括一个envoy容器101、一个安全容器102和一个业务容器103，poda表示微服务应用a运行的最小单元，podb表示微服务应用b运行的最小单元。
[0092]
应当说明的是，当安全防护系统包括多个pod时，每个pod的安全容器的预设规则库可以相同，这样方便统一管理多个安全容器的预设规则库。每个安全容器的预设规则库也可以不同，这样攻击者使用同一种恶意攻击无法绕过所有的安全容器，从而降低了恶意攻击在多个微服务应用之间传递的风险。
[0093]
在介绍pod的功能之后，其中涉及到安全容器102的预设规则库中的预设规则是如何获取的。预设规则库中的预设规则可以是安全容器102生成的，也可以是其他模块发送给安全容器102的，还可以是安全容器102从其他模块中获取的，其他模块为安全防护系统中除安全容器102之外的模块。
[0094]
在一种可能的实施例中，预设规则库中的预设规则是安全中心平台下发给配置存储模块，再由配置存储模块下发给安全容器102的。请参照图3，为本技术实施例提供的一种基于微服务应用的安全防护系统的结构示意图一。该安全防护系统包括安全中心平台300、以及数据平面100和控制平面200。其中，数据平面100和控制平面200运行在kubernetes集群中，控制平面200包括配置服务模块201和配置存储模块202，安全中心平台300包括用户界面模块301、网页后端模块302和数据库模块303，箭头表示预设规则的流向。
[0095]
下面结合图3所示的安全防护系统，对安全容器102获取预设规则的过程进行介绍。
[0096]
用户界面模块301又可称为网络产品界面设计(website user interface，web ui)模块，可以用于展示安全防护系统中的信息供运维人员查看，例如展示安全容器的数量、每个安全容器的预设规则库中的多个预设规则等。用户界面模块301还可以用于检测运维人员所进行的各种类型的操作，例如运维人员所进行的单击操作、双击操作、滑动操作、轻按操作(例如触控压力小于第一预设压力)的操作、重压操作(例如触控压力大于第二预设压力)的操作等，也就是说，用户界面模块301在本技术实施例中的安全防护系统与运维人员之间建立了操作交互接口，作为运维人员与安全防护系统之间进行动作交互的媒介。
[0097]
用户界面模块301可以接收运维人员输入的多个预设规则，运维人员为专门管理和维护该安全防护系统的人员，运维人员可以直接从网络资源获取多个预设规则，也可以自己根据实际需求编写多个预设规则。用户界面模块301将多个预设规则发送给网页后端模块302，网页后端模块302可以将多个预设规则发送到数据库模块303进行存储，还可以将多个预设规则下发至配置服务模块201，配置服务模块201将多个预设规则发送给配置存储模块202进行实时存储，安全容器102从配置存储模块202获取多个预设规则。
[0098]
现有技术在下发预设规则至微服务应用时，通过应用程序接口(application programming interface，api)网关直接下发，在这种下发预设规则的方式中，api网关可以直接访问到kubernetes集群内部的微服务应用，一旦攻击者有管理员权限，便可对微服务应用进行任意访问，无疑增大了应用安全风险。本技术实施例中的预设规则是通过安全中心平台下发的，再通过控制平面的配置存储模块下发至安全容器，这种采用中间编排层的方式可以有效避免kubernetes集群资源被外部直接访问，从而降低被攻击的风险。
[0099]
在一种可能的实施例中，由于每个pod的预设规则库的预设规则可以不同，因此，安全中心平台300可以根据kubernetes集群中pod的配置情况，为每个pod确定相应的多个预设规则，并以pod为单位将多个预设规则下发给对应的安全容器102，安全容器102将多个预设规则保存在预设规则库中。
[0100]
请参照图4，为本技术实施例提供的一种基于微服务应用的安全防护系统的结构示意图二，该安全防护系统包括安全中心平台300、以及kubernetes集群的数据平面100和控制平面200。其中，控制平面200包括配置服务模块201，安全中心平台300包括网页后端模块302和数据库模块303，其中，箭头表示pod操作事件的流向，pod操作事件包括增加pod、删除pod和更改pod。下面结合图4所示的安全防护系统，对安全中心平台300注册和更新pod的过程进行介绍。
[0101]
配置服务模块201可以实时监听kubernetes集群中是否有pod操作事件发生，若确定kubernetes集群中发生pod操作事件，则及时通知安全中心平台300的网页后端模块302。若pod操作事件为增加pod，则网页后端模块302注册pod，并保存在数据库模块303中。若pod操作事件为删除pod或更改pod，则网页后端模块302对数据库模块303中存储的对应pod进行更新，更新包括删除或更改。
[0102]
在一种可能的实施例中，请继续参照图3，配置存储模块202用于存储多个预设规则。考虑到预设规则可能会更新，例如，运维人员发现了一些新类型的恶意攻击，并编写了检测新类型的恶意攻击的预设规则，通过安全中心平台300下发至控制平面200的配置服务模块201，配置服务模块201再通知配置存储模块202。本技术实施例中，配置存储模块202还提供监听机制，安全容器102可以实时监听配置存储模块202中存储的多个预设规则是否更新，若确定多个预设规则中存在更新的预设规则，则获取更新的预设规则，更新预设规则库。
[0103]
为了方便运维人员查看各个请求的检测结果，在一种可能的实施例中，请参照图5，为本技术实施例提供的一种基于微服务应用的安全防护系统的结构示意图三。该安全防护系统包括安全中心平台300、以及数据平面100和控制平面200。其中，数据平面100和控制平面200运行在kubernetes集群中，控制平面200包括日志收集模块203，安全中心平台300包括用户界面模块301、网页后端模块302和数据库模块303，箭头表示系统日志的流向。下面结合图5所示的安全防护系统，对展示系统日志的过程进行介绍。
[0104]
安全容器102在获得检测结果之后，生成检测结果对应的系统日志，其中，系统日志包括日志事件、日志时间、请求方式中的至少一种，日志事件包括正常流量事件和恶意攻击事件，日志时间表示生成系统日志的本地时间，请求方式包括get请求和post请求，get请求用于从指定服务器请求数据，post请求用于将数据发送到指定服务器以创建或更新资源，指定服务器例如设置有该安全防护系统的服务器。若日志事件为恶意攻击事件，则系统日志还可以包括匹配规则和恶意攻击的类型，匹配规则表示预设规则库的多个预设规则中与该请求的参数信息匹配的预设规则。
[0105]
进一步，安全容器102生成系统日志之后，将系统日志发送给日志收集模块203。日志收集模块203可以将接收的系统日志实时发送给用户界面模块301进行展示，日志收集模块203也可以接收并存储系统日志，用户界面模块301可以响应于运维人员的操作，例如点击操作，从日志收集模块203获取并展示系统日志。
[0106]
本技术实施例以非侵入式的方式在envoy容器和业务容器之间部署了一个安全容器，运维人员可以编写各种检测恶意攻击的规则，放在安全容器的预设规则库中，其安全能力可以覆盖网页服务器防护、http访问控制、爬虫防护、webshell上传防护、非法下载限制、信息泄露防护、盗链防护、跨站请求伪造(cross-site request forgery，csrf)、服务器端请求伪造(server-side request forgery，ssrf)等，能够为微服务应用提供较高的安全防护。且由于istio也是包括入口(ingress)网关和出口(egress)网关，自身具有一定的安全防护能力，因而本技术可以为微服务应用提供全方位的安全防护。
[0107]
基于同一发明构思，本技术实施例提供一种基于微服务应用的安全防护方法，该安全防护方法应用于前文所述的安全防护系统的pod的安全容器中，该pod还包括envoy容器。请参照图6，为本技术实施例提供的一种基于微服务应用的安全防护方法的流程图。
[0108]
s601、接收envoy容器发送的用户访问微服务应用的请求，从请求中提取多种预设参数类型的参数信息。
[0109]
其中，安全容器具体如何获取请求，提取参数信息的过程请参照前文论述的内容，此处不再赘述。
[0110]
s602、根据多种预设参数类型的参数信息中是否存在与预设规则库中的预设规则匹配的参数信息，获得请求的检测结果。
[0111]
其中，预设规则库包括多个预设规则，每个预设规则包括一种恶意攻击的参数信息，检测结果用于指示请求为正常流量或恶意攻击，安全容器具体如何获得检测结果的过程请参照前文论述的内容，此处不再赘述。
[0112]
s603、将检测结果发送给envoy容器。
[0113]
安全容器将检测结果发送给envoy容器，以使envoy容器接收检测结果，执行与检测结果对应的流量策略，其中，envoy容器具体如何执行流量策略的过程请参照前文论述的内容，此处不再赘述。
[0114]
在一种可能的实施例中，pod还包括业务容器，根据多种预设参数类型的参数信息中是否存在与预设规则库中的预设规则匹配的参数信息，获得检测结果，包括：
[0115]
若多种预设参数类型的参数信息中不存在与预设规则库中的预设规则匹配的参数信息，则获得请求为正常流量的第一检测结果；
[0116]
将检测结果发送给envoy容器，包括：
[0117]
将第一检测结果发送给envoy容器，以使envoy容器接收第一检测结果，将请求发送给业务容器。
[0118]
其中，安全容器具体如何获得第一检测结果的过程、以及业务容器如何处理请求的过程请参照前文论述的内容，此处不再赘述。
[0119]
在一种可能的实施例中，根据多种预设参数类型的参数信息中是否存在与预设规则库中的预设规则匹配的参数信息，获得检测结果，包括：
[0120]
若多种预设参数类型的参数信息中存在与预设规则库中的预设规则匹配的参数信息，则获得请求为恶意攻击的第二检测结果；
[0121]
将检测结果发送给envoy容器，包括：
[0122]
将第二检测结果发送给envoy容器，以使envoy容器接收第二检测结果，拦截请求。
[0123]
其中，安全容器具体如何获得第二检测结果的过程请参照前文论述的内容，此处
不再赘述。
[0124]
在一种可能的实施例中，该方法还包括：
[0125]
实时监听多个预设规则是否更新，若确定多个预设规则中存在更新的预设规则，则获取更新的预设规则，更新预设规则库。
[0126]
其中，预设规则库以及预设规则的含义请参照前文论述的内容，此处不再赘述。
[0127]
在一种可能的实施例中，在获得检测结果之后，该方法还包括：生成系统日志。
[0128]
其中，系统日志的含义、以及安全容器具体如何生成系统日志的过程请参照前文论述的内容，此处不再赘述。
[0129]
基于同一发明构思，本技术实施例提供一种计算机可读存储介质，计算机可读存储介质存储有计算机指令，当计算机指令在计算机上运行时，使得计算机执行如前文论述任一的基于微服务应用的安全防护方法。
[0130]
本领域内的技术人员应明白，本技术的实施例可提供为方法、系统、或计算机程序产品。因此，本技术可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本技术可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。
[0131]
本技术是参照根据本技术的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
[0132]
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
[0133]
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
[0134]
显然，本领域的技术人员可以对本技术进行各种改动和变型而不脱离本技术的精神和范围。这样，倘若本技术的这些修改和变型属于本技术权利要求及其等同技术的范围之内，则本技术也意图包含这些改动和变型在内。