服务器安全监测方法、装置、系统及存储介质与流程

本申请涉及安全技术领域，尤其涉及一种服务器安全监测方法、装置、系统及存储介质。

背景技术：

传统的安全监测方法是由后台监测服务器直接从各个业务服务器中采集相应的数据，然后根据采集的数据进行安全监测。但是，当需要监测的服务器数量较多(例如一个云平台的服务器数量可达到百万级别)时，后台监测服务器每分钟采集数据的量级至少达到tb(terabyte，太字节)，每天采集数据的量级可达pb(petabyte，拍字节)以上，短时间内海量的数据导致后台监测服务器无法实时分析出监测结果，这降低了系统的安全性。

技术实现要素：

本申请实施例提供一种服务器安全监测方法、装置、电子设备及存储介质，利用每台业务服务器的资源对采集的数据进行关联、过滤，以减少上报给后台监测服务器的数据量，从而降低对后台监测服务器的冲击，提高安全监测的实时性。

一方面，本申请一实施例提供了一种服务器安全监测方法，包括：

采集所述业务服务器运行过程中生成的指定数据；

按预设关联方式对采集的指定数据进行关联处理，获得至少一个第一关联数据；

根据预设过滤策略，从所述至少一个第一关联数据中确定出需要上报的第二关联数据；

将所述第二关联数据发送给后台监测服务器，以使所述后台监测服务器根据接收到的关联数据进行安全监测。

一方面，本申请一实施例提供了一种服务器安全监测方法，包括：

接收至少两个业务服务器发送的需要上报的第二关联数据，其中，每个第二关联数据由对应的业务服务器根据预设过滤策略从至少一个第一关联数据中确定出，每个第一关联数据包括按预设关联方式关联的至少一个在业务服务器运行过程中采集的指定数据；

根据接收到的第二关联数据进行安全监测。

一方面，本申请一实施例提供了一种服务器安全监测装置，包括：

采集模块，用于采集所述业务服务器运行过程中生成的指定数据；

关联模块，用于按预设关联方式对采集的指定数据进行关联处理，获得至少一个第一关联数据；

过滤模块，用于根据预设过滤策略，从所述至少一个第一关联数据中确定出需要上报的第二关联数据；

发送模块，用于将所述第二关联数据发送给后台监测服务器，以使所述后台监测服务器根据接收到的关联数据进行安全监测。

可选地，所述关联模块，具体用于：根据各个指定数据所属的进程，将属于同一进程的指定数据进行关联，获得至少一个进程对应的第一关联数据。

可选地，当第一关联数据中包括指示进程连接网络的网络连接数据时，所述预设过滤策略包括以下至少一种：

若所述第一关联数据中包含指示连接外部网络的网络连接数据，且所述指示连接外部网络的网络连接数据的数量超过第一预设数量，则确定所述第一关联数据为需要上报的第二关联数据；

若所述第一关联数据中包含指示连接外部网络的网络连接数据，且所述指示连接外部网络的网络数据的出现频率超过第一预设频次，则确定所述第一关联数据为需要上报的第二关联数据。

可选地，当第一关联数据中包括指示进程打开文件的文件打开数据时，所述预设过滤策略包括以下至少一种：

若所述第一关联数据中的文件打开数据所指示的打开的文件在文件黑名单中，则将所述第一关联数据确定为需要上报的第二关联数据；

若所述第一关联数据中针对同一文件的文件打开数据的数量超过第二预设数量，则确定所述第一关联数据为需要上报的第二关联数据；

若所述第一关联数据中针对同一文件的文件打开数据的出现频率超过第二预设频次，则确定所述第一关联数据为需要上报的第二关联数据。

可选地，所述关联模块还用于：若任一第一关联数据中的多个指定数据之间的相似度超过相似度阈值，则将所述任一第一关联数据中的多个指定数据聚合成一个数据。

可选地，所述采集模块，具体用于：

通过加载在所述业务服务器的内核空间中的内核模块，从所述内核空间中采集所述业务服务器运行过程中生成的指定数据；或者

通过在所述业务服务器的系统库内预加载的库函数，从所述业务服务器的应用层中采集所述业务服务器运行过程中生成的指定数据。

一方面，本申请一实施例提供了一种服务器安全监测装置，包括：

接收模块，用于接收至少两个业务服务器发送的需要上报的第二关联数据，其中，每个第二关联数据由对应的业务服务器根据预设过滤策略从至少一个第一关联数据中确定出，每个第一关联数据包括按预设关联方式关联的至少一个在业务服务器运行过程中采集的指定数据；

分析模块，用于根据接收到的第二关联数据进行安全监测。

一方面，本申请一实施例提供了一种业务服务器，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其中，处理器执行计算机程序时实现上述任一种方法的步骤。

一方面，本申请一实施例提供了一种计算机可读存储介质，其上存储有计算机程序指令，该计算机程序指令被处理器执行时实现上述任一种方法的步骤。

本申请实施例提供的服务器安全监测方法、装置、系统及存储介质，由每台业务服务器先对其采集的数据进行关联处理，以将相关的数据整合到一起，减少数据量同时使得每条数据包含更加丰富全面的信息，提高后续过滤的准确性；然后利用预设过滤策略对关联后的数据进行过滤，确定出风险较高的数据，仅将风险较高的数据上报给后台监测服务器，这样可以大大减少后台监测服务器需要分析的数据量，提高分析速度，从而实时获得安全监测结果。本申请实施例提供的服务器安全监测方法，将部分数据关联和过滤的功能下沉到业务服务器中，利用海量业务服务器的资源进行过滤分析，即实现了分布式的数据预处理，以此减少对后台监测服务器的冲击，降低了对后台监测服务器的性能要求，可利用较低成本实现对百万数量级服务器的实时安全监测。

附图说明

为了更清楚地说明本申请实施例的技术方案，下面将对本申请实施例中所需要使用的附图作简单地介绍，显而易见地，下面所介绍的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本申请实施例提供的服务器安全监测方法的应用场景示意图；

图2为本申请实施例提供的后台监测服务器的一种结构示意图；

图3为本申请一实施例提供的服务器安全监测方法的流程示意图；

图4为本申请一实施例提供的tlinux系统的部分组成示意图；

图5为本申请一实施例提供的在tlinux系统的业务服务器中执行服务器安全监测方法的示意图；

图6为本申请一实施例提供的服务器安全监测方法的流程示意图；

图7为本申请实施例提供的后台监测服务器的一种结构示意图；

图8为本申请一实施例提供的服务器安全监测装置的结构示意图；

图9为本申请一实施例提供的服务器安全监测装置的结构示意图；

图10为本申请一实施例提供的电子设备的结构示意图。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述。

为了方便理解，下面对本申请实施例中涉及的名词进行解释：

云技术(cloudtechnology)是指在广域网或局域网内将硬件、软件、网络等系列资源统一起来，实现数据的计算、储存、处理和共享的一种托管技术。

云技术(cloudtechnology)基于云计算商业模式应用的网络技术、信息技术、整合技术、管理平台技术、应用技术等的总称，可以组成资源池，按需所用，灵活便利。云计算技术将变成重要支撑。技术网络系统的后台服务需要大量的计算、存储资源，如视频网站、图片类网站和更多的门户网站。伴随着互联网行业的高度发展和应用，将来每个物品都有可能存在自己的识别标志，都需要传输到后台系统进行逻辑处理，不同程度级别的数据将会分开处理，各类行业数据皆需要强大的系统后盾支撑，只能通过云计算来实现。

云安全(cloudsecurity)是指基于云计算商业模式应用的安全软件、硬件、用户、机构、安全云平台的总称。云安全融合了并行处理、网格计算、未知病毒行为判断等新兴技术和概念，通过网状的大量客户端对网络中软件行为的异常监测，获取互联网中木马、恶意程序的最新信息，并发送到服务端进行自动分析和处理，再把病毒和木马的解决方案分发到每一个客户端。

云安全主要研究方向包括：1.云计算安全，主要研究如何保障云自身及云上各种应用的安全，包括云计算机系统安全、用户数据的安全存储与隔离、用户接入认证、信息传输安全、网络攻击防护、合规审计等；2.安全基础设施的云化，主要研究如何采用云计算新建与整合安全基础设施资源，优化安全防护机制，包括通过云计算技术构建超大规模安全事件、信息采集与处理平台，实现对海量信息的采集与关联分析，提升全网安全事件把控能力及风险控制能力；3.云安全服务，主要研究各种基于云计算平台为用户提供的安全服务，如防病毒服务等。

安全监控：安全监控通过实时监控网络或主机活动，监视分析用户和系统的行为，审计系统配置和漏洞，评估敏感系统和数据的完整性，识别攻击行为，对异常行为进行统计和跟踪，识别违反安全法规的。

linux内核：linux是一种开源电脑操作系统内核。它是一个用c语言写成，符合posix标准的类unix操作系统。linux最早是由芬兰linustorvalds为尝试在英特尔x86架构上提供自由的类unix操作系统而开发的。该计划开始于1991年，在计划的早期有一些minix黑客提供了协助，而今天全球无数程序员正在为该计划无偿提供帮助。tencentlinux(简称tlinux)是腾讯针对云的场景研发的linux操作系统，提供了专门的功能特性和性能优化，为云服务器实例中的应用程序提供高性能，且更加安全可靠的运行环境。

网络连接数据：某一设备与其他设备之间建立通信连接时产生的数据。本申请实施例中，网络连接数据可分为连接外部网络的数据和连接内部网络的数据，其中，内部网络是指同一集群或企业内部的各个服务器之间的通信网络，外部网络是相对于内部网络而言的，是指同一集群或企业内部的服务器与第三方的设备之间的通信网络，例如用户终端与企业a提供的业务服务器之间的通信网络，企业a提供的业务服务器与企业b提供的服务器之间通信时使用的通信网络。

文件打开数据：是指为完成某项业务而执行打开业务服务器系统库中存储的文件的操作时生成的数据。例如，用户登录网站账号过程中，需要打开存储用户账号密码的文件，以对用户的账号密码进行验证。

docker：是一个开源的应用容器引擎，让开发者可以打包他们的应用以及依赖包到一个可移植的镜像中，然后发布到任何流行的linux或windows机器上，也可以实现虚拟化。应用容器引擎使用沙箱机制，相互之间不会有任何接口。

虚拟文件系统vfs(virtualfilesystem)的作用就是采用标准的unix系统调用读写位于不同物理介质上的不同文件系统，即为各类文件系统提供了一个统一的操作界面和应用编程接口。vfs是一个可以让open()、read()、write()等系统调用不用关心底层的存储介质和文件系统类型就可以工作的粘合层。

套接字(socket)是一个抽象层，应用程序可以通过它发送或接收数据，可对其进行像对文件一样的打开、读写和关闭等操作。套接字允许应用程序将i/o插入到网络中，并与网络中的其他应用程序进行通信。网络套接字是ip地址与端口的组合。

内核模块，是linux内核向外部提供的一个插口，其全称为动态可加载内核模块(loadablekernelmodule，lkm)。linux内核之所以提供模块机制，是因为它本身是一个单内核(monolithickernel)。单内核的最大优点是效率高，因为所有的内容都集成在一起，但其缺点是可扩展性和可维护性相对较差，模块机制就是为了弥补这一缺陷。内核模块是具有独立功能的程序，它可以被单独编译，但不能独立运行，它在运行时被链接到内核作为内核的一部分在内核空间运行，这与运行在用户空间的进程是不同的。模块通常由一组函数和数据结构组成，用来实现一种文件系统、一个驱动程序或其他内核上层的功能。

proc文件系统：是一种内核和内核模块用来向进程(process)发送信息的机制(所以叫做proc)。这个伪文件系统让你可以和内核内部数据结构进行交互，获取有关进程的有用信息，在运行中(onthefly)改变设置(通过改变内核参数)。与其他文件系统不同，proc存在于内存之中而不是硬盘上。proc文件系统以文件的形式向用户空间提供了访问接口，这些接口可以用于在运行时获取相关部件的信息或者修改部件的行为，因而它是非常方便的一个接口。

附图中的任何元素数量均用于示例而非限制，以及任何命名都仅用于区分，而不具有任何限制含义。

在具体实践过程中，传统的安全监测方法是由后台监测服务器直接从各个业务服务器中采集相应的数据，然后根据采集的数据进行安全监测。但是，当需要监测的服务器数量较多(例如一个云平台的服务器数量可达到百万级别)时，后台监测服务器每分钟采集数据的量级至少达到tb，每天采集数据的量级可达pb以上，除此以外，黑客攻击行为具有高度隐蔽的特点，因此需要采集业务服务器内执行细微操作时产生的数据，这进一步增加了采集的数据量。因此，短时间内海量的数据导致后台监测服务器无法实时分析出监测结果，降低了系统的安全性，而如果盲目的增加后台监测服务器的算力，例如增加后台监测服务器的数量或更换性能更好的服务器，无疑会大幅度提高监测成本。

为此，本申请提出了一种服务器安全监测方法，由每台业务服务器先对其采集的数据进行关联处理，以将相关的数据整合到一起，减少数据量，然后利用预设过滤策略对关联后的数据进行过滤，确定出风险较高的数据，仅将风险较高的数据上报给后台监测服务器，这样可以大大减少后台监测服务器需要分析的数据量，提高分析速度，从而实时获得安全监测结果。具体的，由每台业务服务器采集其自身运行过程中生成的指定数据，并按预设关联方式对采集的指定数据进行关联处理，获得至少一个第一关联数据，然后，每台业务服务器根据预设过滤策略从其获取到的第一关联数据中确定出需要上报的第二关联数据，将第二关联数据发送给后台监测服务器；最后，由后台监测服务器根据接收到的第二关联数据进行安全监测。上述服务器安全监测方法，将部分数据整合和过滤的功能下沉到业务服务器中，利用海量业务服务器的资源进行过滤分析，以此减少对后台监测服务器的冲击，降低了对后台监测服务器的性能要求，可利用较低成本实现对百万数量级服务器的实时安全监测。

在介绍完本申请实施例的设计思想之后，下面对本申请实施例的技术方案能够适用的应用场景做一些简单介绍，需要说明的是，以下介绍的应用场景仅用于说明本申请实施例而非限定。在具体实施时，可以根据实际需要灵活地应用本申请实施例提供的技术方案。

参考图1，其为本申请实施例提供的服务器安全监测方法的应用场景示意图。该应用场景包括多个业务服务器101和后台监测服务器102。其中，每个业务服务器101和后台监测服务器102之间可通过通信网络连接。业务服务器101的数量可达到百万级甚至更高，当然，业务服务器101的数量也可以小于百万级。多个业务服务器101可构成服务器集群或者分布式系统，还可以组成提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、cdn、以及大数据和人工智能平台等基础云计算服务的云服务器。

后台监测服务器102可以是一台服务器、若干台服务器组成的服务器集群或云计算中心。例如，参考图2，后台监测服务器102可包括接入服务器201、分发服务器202以及多个分析服务器203和工单服务器204，后台监测服务器102通过接入服务器201和业务服务器101进行通信，接入服务器201将业务服务器101发送的数据发送给分发服务器202，分发服务器202将数据分发给分析服务器203，分析服务器203通过分析数据生成风险事件，并将风险事件发送给工单服务器204，由工单服务器204将风险事件推送给相关业务负责人。具体实施时，由于需要分析的数据量较大，分析服务器202可采用了多级分析引擎的形式，以此来加快分析速度，例如，第一级分析引擎需要处理的数据量较大，因此第一级分析引擎中的单个分析服务器主要对单个或少量的几个业务服务器上报的数据进行分析处理，并过滤掉部分无风险事件，然后将风险事件上报给第二级分析引擎中的分析服务器；第二级分析引擎中的业务服务器整合第一级分析引擎中多个业务服务器上报的数据，进一步分析出风险事件。

当然，本申请实施例提供的方法并不限用于图1所示的应用场景中，还可以用于其它可能的应用场景，本申请实施例并不进行限制。对于图1所示的应用场景的各个设备所能实现的功能将在后续的方法实施例中一并进行描述，在此先不过多赘述。

为进一步说明本申请实施例提供的技术方案，下面结合附图以及具体实施方式对此进行详细的说明。虽然本申请实施例提供了如下述实施例或附图所示的方法操作步骤，但基于常规或者无需创造性的劳动在所述方法中可以包括更多或者更少的操作步骤。在逻辑上不存在必要因果关系的步骤中，这些步骤的执行顺序不限于本申请实施例提供的执行顺序。

下面结合图1所示的应用场景，对本申请实施例提供的技术方案进行说明。

参考图3，本申请实施例提供一种服务器安全监测方法，应用于图1所示的业务服务器，包括以下步骤：

s301、采集业务服务器运行过程中生成的指定数据。

具体实施时，不同的业务服务器内执行的业务流程可以相同，也可以不同。具体可根据不同的业务流程，在业务服务器中增加采集数据的采集点，以采集业务服务器运行业务流程时生成的指定数据。例如，执行云存储业务的过程中，需要获取用户账号对应的存储地址，将用户上传的数据存储到存储地址对应的服务器中，或者从存储地址对应的服务器中获取用户存储的数据返回给用户的终端，该过程中可采集的指定数据可包括：访问存储用户账号与存储地址对应关系的文件打开数据、与存储地址对应的服务器建立网络连接的网络连接数据、与用户的终端建立网络连接的网络连接数据等；用户登录网站账号过程中，采集的指定数据可包括：进程创建数据、访问用户账号密码的文件打开数据、与网站服务器建立网络连接的网络连接数据等。实际应用中，根据业务流程的不同以及监测目的的不同，可将业务服务器运行过程中生成的不同数据作为需要采集的指定数据，本申请实施例对指定数据不作限定。

s302、按预设关联方式对采集的指定数据进行关联处理，获得至少一个第一关联数据。

具体实施时，预设关联方式可根据具体监测需求预先设定。例如，预设关联方式可以是将同一用户的指定数据关联成一个第一关联数据，也可以是将属于同一进程的指定数据关联成一个第一关联数据，还可以将同一业务在同一时间段内生成的指定数据关联成一个第一关联数据。也就是说，第一关联数据中包括至少一个指定数据。

具体实施时，若一个业务服务器被划分成多个应用容器引擎(docker)，则分别对从同一应用容器引擎中采集的指定数据进行关联处理，即不同应用容器引擎中的指定数据不进行关联。其中，每个应用容器引擎对应的预设关联方式可相同，也可以不同。

通过步骤s302可以将满足预设关联方式的具有一定关联关系的指定数据整合成一个第一关联数据，减少后续需要处理的数据量，同时基于信息更全面的第一关联数据提高后续过滤、分析的准确度和效率。

s303、根据预设过滤策略，从至少一个第一关联数据中确定出需要上报的第二关联数据。

其中，预设过滤策略用于从第一关联数据中筛选出存在一定风险、需要上报给后台监测服务器的数据。具体实施时，预设过滤策略可结合第一关联数据中指定数据的特性和具体监测需求确定，针对同样的指定数据，监测需求不同，对应的预设过滤策略也可能不同。例如，第一关联数据中包含网络连接数据，可根据网络连接数据确定是否连接了外部网络，若连接了外部网络，则存在被入侵的安全风险，需要上报给后台监测服务器作进一步分析，可将该第一关联数据确定为需要上报的第二关联数据。例如，第一关联数据中包含与同一业务服务器建立网络连接的网络连接数据，且这些网络连接数据生成的频率超出了阈值，则表示某一用户在高频率的访问该业务服务器，很可能是在攻击该业务服务器，可将该第一关联数据确定为需要上报的第二关联数据，并发送给后台监测服务器作进一步分析。例如，第一关联数据中包含文件打开数据，若打开的文件属于隐私文件或重要文件等，可将该第一关联数据确定为需要上报的第二关联数据，并发送给台监测服务器作进一步分析。

s304、将第二关联数据发送给后台监测服务器，以使后台监测服务器根据接收到的关联数据进行安全监测。

具体实施时，对于不需要上报的第一关联数据，可先将这些第一关联数据存储在业务服务器中，等待后续采集到新的指定数据后，将新的指定数据与这些第一关联数据进行进一步的关联，进而得到更加丰富全面的第一关联数据，再对这些第一关联数据进行过滤，确定是否需要上报给后台监测服务器。

例如，针对业务服务器的任一操作，业务服务器首先会创建一个进程process，此时可根据采集到的进程信息创建一个第一关联数据d，但是该第一关联数据d还没达到上报后台监测服务器的条件，先将该第一关联数据d保存在业务服务器中。基于业务服务器采集到的新的指定数据，将属于进程process的指定数据关联到第一关联数据d中，此时如果第一关联数据d仍然没达到上报后台监测服务器的条件，则将第一关联数据d保存在业务服务器中，继续等待新采集到的指定数据，将属于该进程process的指定数据关联到第一关联数据d中，此时如果第一关联数据d达到上报后台监测服务器的条件，则将第一关联数据d上报给后台监测服务器。结合具体应用场景进行说明，假设进程process对应的第一关联数据d中没有连接外部网络的网络连接数据，表示该进程process的风险是较低的，将这类数据上报后台意义并不大，但是当采集到进程process连接外部网络的网络连接数据后，风险随之升高，此时需要将进程process对应的数据上报给后台监测服务器，由后台监测服务器结合更多的数据得出更精准的分析结果。

本申请实施例提供的服务器安全监测方法，由每台业务服务器先对其采集的数据进行关联处理，以将相关的数据整合到一起，减少数据量同时使得每条数据包含更加丰富全面的信息，提高后续过滤的准确性；然后利用预设过滤策略对关联后的数据进行过滤，确定出风险较高的数据，仅将风险较高的数据上报给后台监测服务器，这样可以大大减少后台监测服务器需要分析的数据量，提高分析速度，从而实时获得安全监测结果。此外，本申请实施例提供的服务器安全监测方法将部分数据关联和过滤的功能下沉到业务服务器中，利用海量业务服务器的资源进行过滤分析，即实现了分布式的数据预处理，以此减少对后台监测服务器的冲击，降低了对后台监测服务器的性能要求，可利用较低成本实现对百万数量级服务器的实时安全监测。

在一种可能的实施方式中，步骤s302具体包括：根据各个指定数据所属的进程，将属于同一进程的指定数据进行关联，获得至少一个进程对应的第一关联数据。

实际应用中，用户通过业务服务器执行某一业务时，业务服务器一般都需要先创建一个进程，然后在该进程下执行一系列的操作，如创建网络连接、打开系统库内的文件等。为此，可将属于同一进程的指定数据关联在一起，即一个进程对应一个第一关联数据。

具体实施时，每个进程具有唯一的进程名称和进程id，可根据每个指定数据对应的进程名称或进程id，将属于同一进程的指定数据关联成一个第一关联数据。

具体实施时，若一个业务服务器被划分成多个应用容器引擎(docker)，则将属于同一应用容器引擎且属于同一进程的指定数据关联成一个第一关联数据。

当然，实际应用中也可以基于其他信息对指定数据进行关联，本申请实施例不作限定。

在具体实施过程中，针对第一关联数据中不同的指定数据，可设置不同的预设过滤策略。

在一种可能的实施方式中，当第一关联数据中包括指示进程连接网络的网络连接数据时，预设过滤策略包括以下至少一种：

预设过滤策略一：若第一关联数据中包含指示连接外部网络的网络连接数据，则确定该第一关联数据为需要上报的第二关联数据。

当某一进程连接了外部网络时，存在被入侵的安全风险，如通过与外部网络建立的连接向外部网络发送从内部网络窃取的数据，或者向内部网络植入病毒或监控程序包，此时需要上报给后台监测服务器作进一步分析。

预设过滤策略二：若第一关联数据中包含指示连接外部网络的网络连接数据，且指示连接外部网络的网络连接数据的数量超过第一预设数量，则确定该第一关联数据为需要上报的第二关联数据。

其中，第一预设数量可根据业务服务器具体执行的业务确定。例如，业务服务器执行某一业务时不需要连接外部网络，则第一预设数量可设置为0，即一但该业务的进程对应的第一关联数据中出现指示连接外部网络的网络连接数据时，立即将该第一关联数据上报给后台监测服务器。例如，业务服务器执行某一业务时仅需要连接n次外部网络，则第一预设数量可设置为n或者略大于n的数值。具体实施时，针对每个业务服务器，可设置不同的第一预设数量。

预设过滤策略三：若第一关联数据中包含指示连接外部网络的网络连接数据，且指示连接外部网络的网络数据的出现频率超过第一预设频次，则确定该第一关联数据为需要上报的第二关联数据。

其中，第一预设频次可根据业务服务器具体执行的业务通常需要连接外部网络的频率确定。例如，业务服务器执行某一业务时需要连接外部网络的频率较低时，第一预设频次可设置为较小的数值，而如果需要频繁连接外部网络时，第一预设频次可设置为较大的数值。具体实施时，针对每个业务服务器，可设置不同的第一预设频次。

预设过滤策略四：若第一关联数据中包含指示连接内部网络的网络连接数据的出现频率超过第三预设频次，或者第一关联数据中包含指示连接内部网络的网络连接数据的数量超过第三预设数量，则表示某一进程在频繁地访问内部网络的业务服务器，很可能是在攻击内部网络的业务服务器，则确定该第一关联数据为需要上报的第二关联数据。

其中，第三预设数量可根据业务服务器具体执行的业务确定。例如，业务服务器执行某一业务时不需要访问内部网络中的其他业务服务器，则第三预设数量可设置为0，即一但该业务的进程对应的第一关联数据中出现指示连接外内部网络的网络连接数据时，立即将该第一关联数据上报给后台监测服务器。例如，业务服务器执行某一业务时仅需要连接n次外部网络，则第三预设数量可设置为n或者略大于n的数值。第三预设频次可根据业务服务器具体执行的业务通常需要连接内部网络的其他业务服务器的频率确定，例如，业务服务器执行某一业务时需要连接其他业务服务器的频率较低时，第三预设频次可设置为较小的数值，而如果需要频繁连接其他业务服务器时，第三预设频次可设置为较大的数值。

具体实施时，针对每个业务服务器，可设置不同的第三预设数量和第三预设频次。

在另一种可能的实施方式中，当第一关联数据中包括指示进程打开文件的文件打开数据时，预设过滤策略包括以下至少一种：

预设过滤策略五：若第一关联数据中的文件打开数据所指示的打开的文件在文件黑名单中，则将第一关联数据确定为需要上报的第二关联数据。

具体实施时，可预先设置一个文件黑名单，将涉及隐私信息、敏感信息的文件添加到黑名单中。当文件黑名单中的文件被打开时，表示存在信息泄露的风险，需要将对应的第一关联数据上报给后台监测服务器进行进一步分析。

具体实施时，还可以设置文件白名单，将所有用户均可访问的文件添加到该文件白名单中。当第一关联数据中的所有文件开打数据所打开的文件均来自文件白名单时，表示不存在信息泄露的风险，无需要将该第一关联数据上报给后台监测服务器，以此过滤掉不存在安全风险的数据。

预设过滤策略六：若第一关联数据中针对同一文件的文件打开数据的数量超过第二预设数量，则确定第一关联数据为需要上报的第二关联数据。

其中，预设过滤策略六中所指的文件可以是文件黑名单中的文件、也可以是文件白名单中的文件，或者是业务服务器中的任一文件。

其中，第二预设数量可根据业务服务器具体执行的业务确定。例如，业务服务器执行某一业务时不需要打开业务服务器内的任何文件，则第二预设数量可设置为0，即一但该业务的进程对应的第一关联数据中出现文件打开数据时，立即将该第二关联数据上报给后台监测服务器。例如，业务服务器执行某一业务时最多需要打开n次文件，则第二预设数量可设置为n或者略大于n的数值。具体实施时，针对每个业务服务器，可设置不同的第二预设数量。

预设过滤策略七：若第一关联数据中针对同一文件的文件打开数据的出现频率超过第二预设频次，则确定第一关联数据为需要上报的第二关联数据。

其中，预设过滤策略七中所指的文件可以是文件黑名单中的文件、也可以是文件白名单中的文件，或者是业务服务器中的任一文件。

其中，第二预设频次可根据业务服务器具体执行的业务通常需要打开文件的频率确定。例如，业务服务器执行某一业务时需要打开文件的频率较低时，第二预设频次可设置为较小的数值，而如果需要频繁打开文件时，第二预设频次可设置为较大的数值。具体实施时，针对每个业务服务器，可设置不同的第二预设频次。

在上述任一实施方式的基础上，本申请实施例的方法还包括以下步骤：若任一第一关联数据中的多个指定数据之间的相似度超过相似度阈值，则将任一第一关联数据中的多个指定数据聚合成一个数据。

具体实施时，在将第一关联数据上传给后台监测服务器之前，业务服务器可对第一关联数据中重复的指定数据或相似度较高的数据聚合成一条数据，以此减少每一个关联数据中包含的数据量，减少对后台监测服务器的冲击。

具体实施时，针对同一第一关联数据中的多个指定数据，若多个指定数据包含的多个指定信息值均相同，或超过预设数量个信息值相同，则确定这多个指定数据之间的相似度超过相似度阈值，将这多个指定数据合并成一条数据。合并多个指定数据时，多个指定数据之间相同的信息值可只保留一个，不同的信息值可均保留下来。例如，多个指定数据的均为网络连接数据，且连接的均是同一服务器，则可确定这多个指定数据的相似度超过相似度阈值，将这多个指定数据合并成一条数据，合并后的数据中可包括：数据类型为网络连接数据、接连的服务器的ip地址、每个网络连接数据对应的建立网络连接的时间、每个网络连接数据对应的是否连接成功的标识信息等。此外，合并后的数据中还可以包括合并指定数据的数目，这相当于承担了后台监测服务器一部分统计的功能，例如，后台监测服务器可直接根据合并后的数据中的合并指定数据的数目，并结合其他数据进一步判断是否存在安全风险，比如合并后的数据中连接外部网络的网络连接数据的数据超过预设值，则确定存在安全风险。

基于上述方法可将第一关联数据中重复或相似的指定数据聚合成一条数据，降低第一关联数据的数据量，同时承担了后台监测服务器部分的统计功能，减少对后台监测服务器的冲击。

在上述任一实施方式的基础上，步骤s301具体包括如下步骤：通过加载在业务服务器的内核空间(kernelspace)中的内核模块，从内核空间中采集业务服务器运行过程中生成的指定数据；或者，通过在业务服务器的系统库内预加载(preload)的库函数，从业务服务器的应用层中采集业务服务器运行过程中生成的指定数据。

本申请实施例中，内核模块具备从内核空间中采集业务服务器运行过程中生成的指定数据的功能，预加载的库函数是用于从业务服务器的应用层中采集业务服务器运行过程中生成的指定数据的函数。

图4为tlinux系统的部分组成，包括应用层(application)、内核提供的系统调用接口(systemcallinterface)、内核(kernel)以及硬件层(hardware)，应用层中预加载有系统库(systemlibraries)，内核中的主要模块(组件)包括虚拟文件系统(vfs，virtualfilesystem)、文件系统(filesystem)、卷管理器(volumemanagers)、块设备接口(blockdeviceinterface)、套接字(socket)、传输协议(tcp/udp)、ip地址、以太网(ethernet)、调度程序(scheduler)、虚拟内存(virtualmemory)和进程管理(processmanagement)等。系统在应用层中运行应用程序，并通过内核提供的系统调用接口调用内核中的模块完成具体的业务流程。参考图4，对使用tlinux内核的业务服务器，可直接在业务服务器的内核空间中加载内核模块，通过内核模块在系统的相关业务流程中加入采集指定数据的采集点，从而在业务服务器运行过程中，基于内核模块从业务服务器的内核空间中采集业务服务器运行过程中生成的指定数据，如从虚拟文件系统(vfs，virtualfilesystem)、文件系统(filesystem)、卷管理器(volumemanagers)和块设备接口(blockdeviceinterface)中采集的相关数据作为文件打开数据，采集套接字(socket)、传输协议(tcp/udp)、ip地址、以太网(ethernet)等相关数据作为网络连接数据，从进程管理(processmanagement)中采集到进程信息。

实际应用中，由于内核模块和内核绑定关系较为紧密，因此通过内核模块采集指定数据的方式更适用于使用了tlinux内核的系统。对使用非tlinux内核的系统，可通过在应用层的系统库(systemlibraries)内预加载的库函数来采集指定数据，其中，预加载的库函数是用于从业务服务器的应用层中采集业务服务器运行过程中生成的指定数据的函数。

由于内核模块的性能会影响业务服务器的性能(包括cpu、内存占用等)，因此，不适合在内核空间中做过重的分析关联动作，同样对于在系统库中预加载库函数的方式也会影响系统整体性能。为此，内核模块只在系统调用的相关路径中加入采集点，并将采集的数据返回给用户空间，在用户空间中做相关数据的关联分析，比如内核模块会采集系统进程创建、文件打开、创建网络连接、docker等信息，并返回给用户空间，在用户空间中对内核模块进行关联过滤后，再发送到后台监测服务器。同样，预加载的库函数也会将采集的指定数据返回给用户空间，在用户空间中做相关数据的关联分析。

参考图5，对于tlinux系统，为内核空间(kernelspace)中的每个cpu(centralprocessingunit，中央处理器)都分配一个缓存区域(buf，buffer)，内核模块将采集的数据存放到各个cpu的buf中，并通过proc文件的形式返回到用户空间(userspace)。对于非tlinux系统，则通过在系统库中预加载库函数的方式在应用层中采集指定数据，以图5为例，库函数中规定了采集的指定数据包括文件打开数据(open)和网络连接数据(net)等，库函数中还规定了以proc文件的形式将采集的指定数据返回到用户空间。可通过在用户空间内增加插件的方式植入关联数据、过滤数据的程序，可通过插件中的receiver进程将采集的指定数据存储到用户空间中的缓存区域中，然后，对采集的指定数据进行关联，得到每个被创建的进程对应的第一关联数据，接着利用预设过滤策略对第一关联数据进行过滤，确定出需要上报的第二关联数据，将第二关联数据上报给后台监测服务器。

当然，对于tlinux系统，也可以采用预加载函数库的方式采集指定数据，对于非tlinux系统，也可以采用内核模块的方式采集指定数据，本申请实施例不作限定。

上述服务器安全监测方法，通过内核模块或在系统库内预加载(preload)函数库的方式采集指定数据，可采集到更细微的动作所产生的数据，从而实现对细微的入侵行为的监控。

参考图6，本申请实施例提供了一种服务器安全监测方法，应用于图1所示的后台监测服务器，具体包括以下步骤：

s601、接收至少两个业务服务器发送的需要上报的第二关联数据，其中，每个第二关联数据由对应的业务服务器根据预设过滤策略从至少一个第一关联数据中确定出，每个第一关联数据包括按预设关联方式关联的至少一个在业务服务器运行过程中采集的指定数据。

s602、根据接收到的第二关联数据进行安全监测。

具体实施时，后台监测服务器可以是一台服务器、若干台服务器组成的服务器集群或云计算中心。后台监测服务器根据接受到的第二关联数据进行安全监测，生成安全监测结果，并可以根据安全监测结果将确定出的风险事件推送给相关业务负责人。

具体实施时，参考图7，后台监测服务器可包括：分发服务器和至少两级分析引擎，每一级分析引擎包括至少两个分析服务器。为此，步骤s602具体可通过如下方式实现：分发服务器按第一分发策略，将每个业务服务器发送的第二关联数据分发给第一级分析引擎中对应的分析服务器；除最后一级分析引擎以外的每一级分析引擎中的每个分析服务器根据接收到的数据确定出存在安全风险的数据，按每一级分析引擎对应的第二分发策略，将存在安全风险的数据分发给下一级分析引擎中对应的分析服务器；最后一级分析引擎中的每个分析服务器根据接收到的数据确定出安全风险事件。

具体实施时，第一分发策略可以是：根据业务服务器和第一级分析引擎中的分析服务器的对应关系，将业务服务器发送的第二关联数据分发给第一级分析引擎中对应的分析服务器。其中，业务服务器和第一级分析引擎中的分析服务器之间的对应关系可预先设定好，并将对应关系存储在分发服务器中，例如，业务服务器1、业务服务器2、业务服务器3和第一级分析服务器中的1号分析服务器对应的，则分发服务器将业务服务器1、业务服务器2和业务服务器3上报的第二关联数据发送给1号分析服务器。

具体实施时，可为每一级分析引擎分别设置对应的第二分发策略，并存储在每一级分析引擎的每个分析服务器中，每个分析服务器确定出存在安全风险的数据后，按照存储的第二分发策略将存在安全风险的数据分发给下一级分析引擎中对应的分析服务器。

具体实施时，第二分发策略可以是：根据存在安全风险的数据的风险类型，将存在安全风险的数据分发给下一级分析引擎中风险类型对应的分析服务器。即为每种风险类型设置专用的分析服务器，同时整合同类型更全面的数据可更准确的分析出风险事件。例如，可将病毒植入的事件整合到一起，将网络监听的事件整合到一起，将窃取信息的事件整合到一起。

具体实施时，第二分发策略也可以是：根据存在安全风险的数据所针对的业务服务器的业务类型，将存在安全风险的数据分发给与业务类型对应的分析服务器。即为每种业务设置专用的分析服务器，将相同业务下的安全风险数据整合到一起，基于业务流程的特点，配置不同的监测策略，从而更全面且有针对性的分析出风险事件。例如，有些业务流程下执行某一操作是存在风险的，而另一些业务流程下执行该操作是不存在风险的。

当然，第一分发策略和第二分发策略不限于上述列举的方式，本申请实施例不作限定。

参考图7，后台监测服务器还可以包括工单服务器，工单服务器与最后一级分析引擎中的各个分析服务器连接，最后一级分析引擎中的每个分析服务器根据接收到的数据确定出安全风险事件后，将安全风险事件发送给工单服务器，由工单服务器将安全风险事件推送给相关业务负责人。

由于后台监测服务器需要分析数据量较大，因此，本申请实施例的服务器安全监测方法，在后台监测服务器中采用了多级分析引擎的形式，通过逐级关联整合过滤，来逐级缩减数据量，以此来加快分析速度。例如，第一级分析引擎面对的数据量较大，主要可以对单个业务服务器上传的数据进行风险的关联分析，并过滤掉部分无风险事件，将存在风险的数据分发给下一级引擎中对应的分析服务器；第二级引擎将第一级分析引擎分析关联的数据进行整合，进一步分析出风险事件，并分发给下一级引擎中对应的分析服务器，以此类推，由最后一级分析引擎的分析服务器确定出最终的风险事件，并通过工单服务器推送给相关业务负责人。

如图8所示，基于与上述服务器安全监测方法相同的发明构思，本申请实施例还提供了一种服务器安全监测装置80，包括：采集模块801、关联模块802、过滤模块803和发送模块804。

采集模块801，用于采集业务服务器运行过程中生成的指定数据。

关联模块802，用于按预设关联方式对采集的指定数据进行关联处理，获得至少一个第一关联数据。

过滤模块803，用于根据预设过滤策略，从至少一个第一关联数据中确定出需要上报的第二关联数据。

发送模块804，用于将第二关联数据发送给后台监测服务器，以使后台监测服务器根据接收到的关联数据进行安全监测。

可选地，关联模块802具体用于：根据各个指定数据所属的进程，将属于同一进程的指定数据进行关联，获得至少一个进程对应的第一关联数据。

可选地，当第一关联数据中包括指示进程连接网络的网络连接数据时，预设过滤策略包括以下至少一种：

第一种预设过滤策略、若第一关联数据中包含指示连接外部网络的网络连接数据，且指示连接外部网络的网络连接数据的数量超过第一预设数量，则确定第一关联数据为需要上报的第二关联数据；

第二种预设过滤策略、若第一关联数据中包含指示连接外部网络的网络连接数据，且指示连接外部网络的网络数据的出现频率超过第一预设频次，则确定第一关联数据为需要上报的第二关联数据。

可选地，当第一关联数据中包括指示进程打开文件的文件打开数据时，预设过滤策略包括以下至少一种：

第一种预设过滤策略、若第一关联数据中的文件打开数据所指示的打开的文件在文件黑名单中，则将第一关联数据确定为需要上报的第二关联数据；

第二种预设过滤策略、若第一关联数据中针对同一文件的文件打开数据的数量超过第二预设数量，则确定第一关联数据为需要上报的第二关联数据；

第三种预设过滤策略、若第一关联数据中针对同一文件的文件打开数据的出现频率超过第二预设频次，则确定第一关联数据为需要上报的第二关联数据。

可选地，关联模块802还用于：若任一第一关联数据中的多个指定数据之间的相似度超过相似度阈值，则将任一第一关联数据中的多个指定数据聚合成一个数据。

可选地，采集模块801具体用于：通过加载在业务服务器的内核空间中的内核模块，从内核空间中采集业务服务器运行过程中生成的指定数据；或者通过在业务服务器的系统库内预加载的库函数，从业务服务器的应用层中采集业务服务器运行过程中生成的指定数据。

本申请实施例提的服务器安全监测装置与上述服务器安全监测方法采用了相同的发明构思，能够取得相同的有益效果，在此不再赘述。

如图9所示，基于与上述服务器安全监测方法相同的发明构思，本申请实施例还提供了一种服务器安全监测装置90，包括：接收模块901和分析模块902。

接收模块901，用于接收至少两个业务服务器发送的需要上报的第二关联数据，其中，每个第二关联数据由对应的业务服务器根据预设过滤策略从至少一个第一关联数据中确定出，每个第一关联数据包括按预设关联方式关联的至少一个在业务服务器运行过程中采集的指定数据。

分析模块902，用于根据接收到的第二关联数据进行安全监测。

可选地，后台监测服务器包括至少两级分析引擎，每一级分析引擎包括至少两个分析服务器。

分析模块，具体包括分发子模块、多个第一分析子模块和多个第二分析子模块。

分发子模块用于按第一分发策略，将每个业务服务器发送的第二关联数据分发给第一级分析引擎中对应的分析服务器。实际应用中，分发子模块可设置在分发服务器内。

每个第一分析子模块可设置在除最后一级分析引擎以外的每一级分析引擎中的每个分析服务器内。每个第一分析子模块用于：根据接收到的数据确定出存在安全风险的数据，按每一级分析引擎对应的第二分发策略，将存在安全风险的数据分发给下一级分析引擎中对应的分析服务器。

每个第二分析子模块可设置在最后一级分析引擎中的每个分析服务器内，每个第二分析子模块用于：根据接收到的数据确定出安全风险事件。

本申请实施例提的服务器安全监测装置与上述服务器安全监测方法采用了相同的发明构思，能够取得相同的有益效果，在此不再赘述。

基于与上述服务器安全监测方法相同的发明构思，本申请实施例还提供了一种业务服务器，如图10所示，该业务服务器100可以包括处理器1001和存储器1002。

处理器1001可以是通用处理器，例如中央处理器(cpu)、数字信号处理器(digitalsignalprocessor，dsp)、专用集成电路(applicationspecificintegratedcircuit，asic)、现场可编程门阵列(fieldprogrammablegatearray，fpga)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件，可以实现或者执行本申请实施例中公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者任何常规的处理器等。结合本申请实施例所公开的方法的步骤可以直接体现为硬件处理器执行完成，或者用处理器中的硬件及软件模块组合执行完成。

存储器1002作为一种非易失性计算机可读存储介质，可用于存储非易失性软件程序、非易失性计算机可执行程序以及模块。存储器可以包括至少一种类型的存储介质，例如可以包括闪存、硬盘、多媒体卡、卡型存储器、随机访问存储器(randomaccessmemory，ram)、静态随机访问存储器(staticrandomaccessmemory，sram)、可编程只读存储器(programmablereadonlymemory，prom)、只读存储器(readonlymemory，rom)、带电可擦除可编程只读存储器(electricallyerasableprogrammableread-onlymemory，eeprom)、磁性存储器、磁盘、光盘等等。存储器是能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。本申请实施例中的存储器1002还可以是电路或者其它任意能够实现存储功能的装置，用于存储程序指令和/或数据。

基于与上述服务器安全监测方法相同的发明构思，本申请实施例还提供了一种服务器安全监测系统，参考图2，该服务器安全监测系统包括多个业务服务器和一个后台监测服务器。

其中，多个业务服务器中的每个业务服务器用于执行上述任一实施方式中的服务器安全监测方法的步骤。

其中，后台监测服务器用于接收每个业务服务器发送的需要上报的第二关联数据，根据接收到的第二关联数据进行安全监测。

具体实施时，参考图2和图7，后台监测服务器包括一个分发服务器和至少两级分析引擎，每一级分析引擎包括至少两个分析服务器。

其中，分发服务器用于按第一分发策略，将每个业务服务器发送的第二关联数据分发给第一级分析引擎中对应的分析服务器。

除最后一级分析引擎以外的每一级分析引擎中的每个分析服务器，用于根据接收到的数据确定出存在安全风险的数据，按每一级分析引擎对应的第二分发策略，将存在安全风险的数据分发给下一级分析引擎中对应的分析服务器；

最后一级分析引擎中的每个分析服务器，用于根据接收到的数据确定出安全风险事件。

后台监测服务器中还可以包括接入服务器，通过接入服务器和业务服务器进行通信，接入服务器将业务服务器发送的数据发送给分发服务器。

后台监测服务器中还可以包括工单服务器，最后一级分析引擎中的分析服务器将确定出的风险事件发送给工单服务器，由工单服务器将风险事件推送给相关业务负责人。

本申请实施例提供了一种计算机可读存储介质，用于储存为上述电子设备所用的计算机程序指令，其包含用于执行上述服务器安全监测方法的程序。

上述计算机存储介质可以是计算机能够存取的任何可用介质或数据存储设备，包括但不限于磁性存储器(例如软盘、硬盘、磁带、磁光盘(mo)等)、光学存储器(例如cd、dvd、bd、hvd等)、以及半导体存储器(例如rom、eprom、eeprom、非易失性存储器(nandflash)、固态硬盘(ssd))等。

以上，以上实施例仅用以对本申请的技术方案进行了详细介绍，但以上实施例的说明只是用于帮助理解本申请实施例的方法，不应理解为对本申请实施例的限制。本技术领域的技术人员可轻易想到的变化或替换，都应涵盖在本申请实施例的保护范围之内。