一种安全业务提供方法及服务器与流程

本申请涉及电子信息领域，尤其涉及一种安全业务提供及服务器。

背景技术：

安全运营中心(Security Operate Center，SOC)为一种对安全设备进行集中管理(包括集中的运行状态监控、事件采集分析、安全策略下发)的系统。

传统SOC一般作为一个系统来建设，对于传统SOC来说，这个系统是封闭的，系统内包含资产管理、安全日志管理、事件管理、流程管理、风险管理等若干模块，通过对安全日志的分析，产生安全事件，然后通过对安全事件的运营，来驱动安全问题的解决，以期降低安全风险。可见，传统的SOC是一个复杂的系统，其中各个功能间存在各种层面的耦合和调用，从而相互影响和制约，当其功能累计到一定程度后，系统的复杂性可能会超越系统本身所能承受的范围，从而导致无法继续增加新的功能。

可见，传统的SOC存在功能扩展受限的问题。

技术实现要素：

本申请提供了一种安全业务提供方法及服务器，目的在于解决传统的SOC存在的功能扩展受限的问题。

为了实现上述目的，本申请提供了以下技术方案：

一种安全业务提供服务器，包括：

基础平台以及至少一个应用，所述至少一个应用中的每一个应用在运行过程中，均独立于其它的应用；

其中，所述基础平台用于，在接收到用户对于任意一个应用的调用请求后，对所述调用请求进行验证，以及在所述调用请求通过验证后，将所述调用请求转发给其调用的应用，并为所述调用请求调用的应用的运行配置资源；

所述至少一个应用中的每一个应用均用于，接收所述基础平台转发的调用请求，并依据所述调用请求，为所述用户提供安全类的业务。

可选地，所述基础平台用于对所述调用请求进行验证包括：

所述基础平台具体用于，验证所述调用请求的发送方的网络参数是否合法，验证所述调用请求的发送方是否为合法用户以及验证所述调用请求的发送方是否具有调用此应用的权限；

所述基础平台用于在所述调用请求通过验证后，将所述调用请求转发给其调用的应用包括：

所述基础平台具体用于，在所述调用请求的发送方的网络参数合法、所述调用请求的发送方为合法用户、且所述调用请求的发送方具有调用此应用的权限的情况下，将所述调用请求转发给其调用的应用。

可选地，所述调用请求的发送方的网络参数至少包括以下一项：

所述调用请求的发送方的互联网协议IP、统一资源定位符URL以及HTTP请求的参数。

可选地，所述基础平台还用于：

在所述调用请求的发送方为合法用户的情况下，使用所述调用请求的发送方当前的访问数据替换其历史访问数据；

如果所述发送方在预设时间范围内没有进行过访问，则删除所述发送方的历史访问数据，所述预设时间范围的起点为所述发送方最后一次访问的时刻。

可选地，所述基础平台用于为所述调用请求调用的应用的运行配置资源包括：

所述基础平台具体用于，启动所述调用请求调用的应用的底层通信连接、数据库连接池以及缓存连接。

可选地，所述基础平台还用于：

接收所述用户对任意一个应用的修改指令，并依据所述修改指令，对待修改的应用进行更新。

可选地，

所述每一个应用中均包括：此应用的门户、此应用的静态文件、此应用的动态文件以及此应用的主程序；

所述基础平台还用于：通过渲染技术，利用所述静态文件和所述动态文件，生成所述每一个应用的门户，并在所述用户的调用请求通过验证后，向所述用户展示所述调用请求调用的应用的门户。

可选地，还包括：

第一运行控制模块，用于控制每一个应用在各自的、预先设置的最大运行资源规定的范围内运行，所述最大运行资源至少包括以下一项：可连接的数据库的数量、可运行的线程的数量、可占用的内存的申请量以及文件读写的频率。

可选地，还包括：

第二运行控制模块，用于控制每一个应用在各自的、预先设置的访问权限中访问文件或数据，和/或，控制每一个应用在各自的、预先设置的访问权限中访问缓存空间。

可选地，如果运行任意一个应用可实现若干功能，则所述若干功能属于同一个预设领域。

可选地，所述基础平台还用于：

向所述用户展示所述应用及所述应用中包含的功能的列表。

可选地，所述基础平台还用于：

在所述用户为登陆用户的情况下，向所述用户展示与所述用户的使用习惯相关的个性列表。

一种安全业务提供方法，包括：

安全业务提供服务器在接收到用户对于至少一个应用中的任意一个应用的调用请求后，对所述调用请求进行验证；

在所述调用请求通过验证后，将所述调用请求转发给其调用的应用，并为所述调用请求调用的应用的运行配置资源；

通过运行所述调用请求调用的应用，为所述用户提供安全类的业务。

可选地，所述安全业务提供服务器对所述调用请求进行验证包括：

所述安全业务提供服务器验证所述调用请求的发送方的网络参数是否合法，验证所述调用请求的发送方是否为合法用户以及验证所述调用请求的发送方是否具有调用此应用的权限；

所述安全业务提供服务器在所述调用请求通过验证后，将所述调用请求转发给其调用的应用包括：

在所述调用请求的发送方的网络参数合法、所述调用请求的发送方为合法用户、且所述调用请求的发送方具有调用此应用的权限的情况下，所述安全业务提供服务器将所述调用请求转发给其调用的应用。

可选地，还包括：

所述安全业务提供服务器控制每一个应用在各自的、预先设置的最大运行资源规定的范围内运行，所述最大运行资源至少包括以下一项：可连接的数据库的数量、可运行的线程的数量、可占用的内存的申请量以及文件读写的频率。

可选地，还包括：

所述安全业务提供服务器控制每一个应用在各自的、预先设置的访问权限中访问文件或数据，和/或，控制每一个应用在各自的、预先设置的访问权限中访问缓存空间。

可选地，还包括：

所述安全业务提供服务器向所述用户展示所述应用及所述应用中包含的功能的列表，并且，在所述用户为登陆用户的情况下，向所述用户展示与所述用户的使用习惯相关的个性列表。

本申请所述的安全业务提供服务器包括基础平台以及至少一个应用，其中，基础平台用于在接收到用户对于任意一个应用的调用请求后，对所述调用请求进行验证，以及在所述调用请求通过验证后，将调用请求转发给其调用的应用，并为其调用的应用的运行配置资源，每一个应用均用于接收所述 基础平台转发的调用请求，并依据调用请求，为所述用户提供安全类的业务，可见，在任意一个应用被调用的过程中，由基础平台完成对于调用请求的验证过程及为应用配置资源的过程，因此，对于每一个应用，只需关注于安全类业务本身即可，而将请求验证以及资源配置的过程均集中在基础平台上，也就是说，由基础平台统一为所有应用提供请求验证以及资源配置的服务，又因为每一个应用在运行过程中，均独立于其它的应用，因此，本申请所述的安全业务提供服务器具有技术与业务的分离的架构，在这种架构的基础上，因为各个应用运行过程中相互之间无需嵌套及调用，所以，基于基础平台，理论上可以构建无数个应用，从而能够提高安全业务提供服务器的可扩展性。

附图说明

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

图1为本申请实施例公开的一种安全业务提供服务器的结构示意图；

图2为本申请实施例公开的安全业务提供服务器中的基础平台功能实现的流程图；

图3为本申请实施例公开的安全业务提供服务器中的基础平台的逻辑结构示意图；

图4为本申请实施例公开的又一种安全业务提供服务器的结构示意图；

图5为本申请实施例公开的安全业务提供服务器中的APP的结构示意图；

图6为本申请实施例公开的安全运行门户的示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而 不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

本申请实施例公开了一种安全业务提供服务器，如图1所示，包括：基础平台101以及至少一个应用102(Application，APP)。本实施例中，以APP-1、APP-2、……APP-N为例。

其中，基础平台101的功能主要集中在为各个应用提供公共功能或服务，即基础平台用于在接收到用户对于任意一个应用的调用请求后，对调用请求进行验证，以及在所述调用请求通过验证后，将所述调用请求转发给其调用的应用，并为所述调用请求调用的应用的运行配置资源。

具体地，基础平台101实现以上功能的具体实现方式如图2所示，包括以下步骤：

S201：接收到用户对于任意一个应用的调用请求；

本实施例中，具体地，基础平台的逻辑结构可以如图3所示，即：基础平台提供Web服务能力，用户可以通过基于超文本传输协议(HyperText Transfer Protocol，http)的调用请求(Request)访问基础平台。基础平台通过统一资源定位符(Uniform Resource Locator，URL)映射，将调用请求(Request)转给相应的类(class)来处理。同时，在“Request钩子”里面，会拦截所有的调用请求，并将调用请求进行以下步骤所述的处理过程。

S202：验证调用请求的发送方的网络参数是否合法，如果是，执行S203，如果否，则结束流程；

本实施例中，网络参数可以包括调用请求的发送方的互联网协议IP、统一资源定位符URL以及HTTP请求的参数(例如http://127.0.0.1/test/abc？a＝1&b＝2，其中a和b就是HTTP请求的参数)中的一项或多项。具体地，可以根据预先设置的IP白名单和/或黑名单验证IP是否合法，可以依据HTTP请求的参数来验证URL请求是否包含攻击，例如，如果参数中包含<script>之类的字符，就可能存在XSS攻击(XSS攻击是指Cross Site Scripting，恶意攻击者往Web页面里插入恶意html代码，当用户浏览该 页之时，嵌入其中Web里面的html代码会被执行，从而达到恶意攻击用户的特殊目的)。其中，可以将IP白名单和/或黑名单、合法URL及参数打包在安全包里，以插件的方式设置在基础平台上，并可以依据实际需求对其进行修改或更新，比如增加CSRF(Cross-site request forgery，跨站请求伪造，是一种对网站的恶意利用。它通过伪装来自受信任用户的请求来利用受信任的网站。)的攻击过滤插件来防止CSRF攻击等。

S203：验证调用请求的发送方是否为合法用户，如果是，执行S204，如果否，返回登陆界面，当用户登陆后再次执行S203；

具体地，可以将已登陆用户确定为合法用户，将未登录的用户作为不合法用户。

S204：验证调用请求的发送方是否具有调用此应用的权限，如果是，执行S205，如果否，提醒用户无调用权限；

S205：将所述调用请求转发给其调用的应用；

S206：启动调用请求调用的应用的底层通信连接、数据库连接池以及缓存连接。

其中，底层通信连接是指最基础的socket(网络上的两个程序通过一个双向的通信连接实现数据的交换，这个连接的一端称为一个socket)连接。

除了上述步骤外，可选地，本实施例中，在S203中，如果验证调用请求的发送方是否为合法用户，则在S203之后，基础平台还可以执行以下步骤：

S207：使用调用请求的发送方当前的访问数据替换其历史访问数据；

S208：如果所述发送方在预设时间范围内没有进行过访问，则删除所述发送方的历史访问数据，所述预设时间范围的起点为所述发送方最后一次访问的时刻。

具体地，访问数据可以包括发送方的用户名及登陆时间。也就是说，用户每次登陆后，使用当前登陆时间代替之前的登陆时间，目的在于记录用户的访问情况，如果用户长期未访问，则需要其重新登陆，如果在预设时间范围内再次访问，则可以免登陆，从而方便用户的使用。

以上为本实施例中基础平台的功能，可见，本实施例中，基础平台能够为各个APP的提供统一的验证服务和资源配置，而APP只需关注业务本身即可。

本实施例中，每一个APP102用于：接收基础平台转发的调用请求，并依据所述调用请求，为用户提供安全类的业务。例如，APP可以为安全漏洞运营平台、入侵检测运营平台等。

并且，每一个APP在运行过程中，均独立于其它的应用，也就是说，每一个APP都是彼此独立的个体，相互之间没有逻辑上的耦合关系，每一个APP的发布上线或者下线，不会影响其它APP，这样就形成一个个垂直化的独立系统。APP内部的功能也可自成体系，可以按业务特点自行设计。

从上述说明可以看出，本实施例中所述的安全业务提供服务器，采用“平台+APP”的模式进行构建，与传统的安全运营系统(系统是指由相互作用、相互依赖的若干组成部分结合而成的具有特定功能的有机整体)相比，架构上进行了根本性地变革，因为基础平台承担了每个APP的调用请求验证和资源配置的公共服务，并且每个APP独立运行，因此，基于基础平台，可添加的APP的数量从理论上而言，是没有上限的，因此，能够大大提高安全业务提供服务器的可扩展性，并且，因为各个APP均由基础平台提供服务，所以，每个APP产生的数据之间具有天然的亲近性和关联的便捷性，因此，能够提高安全业务提供服务器开发的效率。

本申请实施例公开的又一种安全业务提供服务器，与上述实施例相比，本实施例增加了APP运行的控制模块，以提高APP运行的安全性。

如图4所示，本实施例所述的安全业务提供服务器包括：基础平台101、至少一个APP 102、第一运行控制模块103以及第二运行控制模块104。

其中，基础平台101和APP的功能与上述实施例相同，这里不再赘述。

下面重点说明第一运行控制模块103以及第二运行控制模块104的功能：

其中，第一运行控制模块103，用于控制每一个应用在各自的、预先设置的最大运行资源规定的范围内运行，其中，最大运行资源至少包括以下一项：可连接的数据库的数量、可运行的线程的数量、可占用的内存的申请量以及文件读写的频率。例如，某个APP最大可连接的数据库的数量为5，则在此APP的运行过程中，当其连接的数据库的数量达到5个后，则第一运行模块可以通过某种方式(例如，禁止此APP再连接数据库)使其连接的数据库的数量不超过5个。

本实施例中，最大运行资源可以由用户预先设定，也可以由第一运行控制模块依据系统的状况自行设定。

第二运行控制模块104，用于控制每一个应用在各自的、预先设置的访问权限中访问文件或数据，和/或，控制每一个应用在各自的、预先设置的访问权限中访问缓存空间。

也就是说，第二运行控制模块可以限制每一个APP对重要数据、文件的访问，还可以限制每一个APP对缓存空间的访问，防止任意一个APP非法越界访问其它APP的敏感数据或文件。这些敏感数据或文件，既包括存放在数据库中的数据或文件、也包括文件中的数据或文件、还包括缓存中的数据或文件。可以通过黑和/或白名单的方式来实现敏感数据的或文件管控，黑和/或白名单可在线更新。

同样地，访问权限也可以由用户预先设定，或者由第一运行控制模块依据系统的状况自行设定。

本实施例中，第一运行控制模块和第二运行控制模块可以看作“APP沙箱”，其目的在于给每一个APP营造相对独立的运行环境，避免不同的APP在同一个平台上彼此干扰或资源竞争，既能够保证APP的高效运行，又能保证APP的安全运行。

需要说明的是，在实际应用中，第一运行控制模块和第二运行控制模块可以视需求灵活配置，既可以使用其一，也可以两者均选。

本申请实施例公开的又一种安全业务提供服务器，在上述实施例的基础上，本实施例中，重点在于改善用户的使用体验。

本实施例所述的安全运行中心的结构与图4所示相同，与上述实施例不同的是，本实施例中，如果运行任意一个APP可实现若干功能，则所述若干功能属于同一个预设领域。也就是说，本实施例中，将领域相同的功能组合在一起，形成一个APP。

与传统的SOC中相似功能堆砌在各级菜单中相比，一个APP代表一个领域的方式，方便用户快速找到感兴趣的APP，用户可以只关注此APP，从而提高效率。

本实施例中，如图5所示，每一个APP均可以包括：此APP的门户、此APP的静态文件、此APP的动态文件以及此APP的主程序。其中，门户类似APP的首页或入口，提供功能导航以及重要功能的快捷菜单、图形、表格等。静态文件主要包括静态页面、样式、图片等。模板文件用于提供动态页面能力和动态的显示效果。主程序提供APP中包含的功能的后台实现与接口实现。在以上部分中，只有APP门户为用户可见。

本实施例中，基础平台除了上述实施例中所述的功能之外，还可以具有展示APP及修改APP的功能：

具体地，基础平台可以通过渲染技术，利用所述静态文件和所述动态文件，生成每一个APP的门户。

进一步地，基础平台还可以将所有APP以及每个APP中包含的功能向用户集中显示，形成安全运行门户，如图6所示，安全运行门户中包括每个APP，每个APP中包括各项功能，并且，在用户为登陆用户的情况下，基础平台还可以向登录用户展示与此用户的使用习惯相关的个性列表。例如，如图6中所示，个性列表为代办事项、我的关注、安全公告以及常用功能的快捷区等。其中，待办事项用于融合当前用户在各APP(运营平台)的运营工单，方便快捷的直通各运营平台处理工单；我的关注用于融合当前用户在各APP(运营平台)的运营数据，包括感兴趣的数据、图表、报告、告警；安全公告用 于融合各APP(运营平台)的热点信息，如漏洞公告，安全事件公告等；常用功能用于融合当前用户在各APP(运营平台)中最常用的功能菜单，提供快捷通道，支持自定义(下个版本)。

对于用户而言，图6所示的各项共同组成安全业务提供服务器的安全运行门户。用户可以在安全运营门户中选择某个APP，在用户选择(例如点击)某个APP之后，基础平台接收到用户对此APP的调用请求，并对此调用请求进行验证，如果验证通过，用户可进入此APP的门户中，并进行相应的操作(例如选择某项功能)，APP的主程序响应用户的操作。基础平台为此APP的运行配置资源。。

基础平台还可以接收用户对任意一个APP的修改指令，并依据所述修改指令，对待修改的应用进行更新。即：基础平台提供各APP在线修改自身配置的能力，并实现配置的实时更新。

本实施例中所述的安全业务提供服务器，能够向用户展示以领域划分的APP，并且，能够通过安全运营门户与用户进行良好的交互，方便用户的使用，从而提高用户的体验。

上述实施例所述的安全业务提供服务器，可以设置在安全运营中心中，即：安全运营中心包括安全业务提供服务器和客户端，客户端向安全业务提供服务器发送应用调用请求，以申请安全业务，安全业务提供服务器按照上述功能，响应调用请求，以向客户端提供安全业务。

本申请实施例还公开了一种安全业务提供方法，可以应用在上述实施例所述的安全业务提供服务器中，包括以下步骤：

A：安全业务提供服务器在接收到用户对于至少一个应用中的任意一个应用的调用请求后，对所述调用请求进行验证；

B：安全业务提供服务器在所述调用请求通过验证后，将所述调用请求转发给其调用的应用，并为所述调用请求调用的应用的运行配置资源；

C：安全业务提供服务器通过运行所述调用请求调用的应用，为所述用户提供安全类的业务。

具体地，安全业务提供服务器对所述调用请求进行验证的具体实现方式可以为：验证所述调用请求的发送方的网络参数是否合法，验证所述调用请求的发送方是否为合法用户以及验证所述调用请求的发送方是否具有调用此应用的权限。在此情况下，安全业务提供服务器在所述调用请求通过验证后，将所述调用请求转发给其调用的应用的具体实现方式可以为：在所述调用请求的发送方的网络参数合法、所述调用请求的发送方为合法用户、且所述调用请求的发送方具有调用此应用的权限的情况下，所述安全业务提供服务器将所述调用请求转发给其调用的应用。

可选地，本实施例中还可以包括以下步骤：

D：安全业务提供服务器控制每一个应用在各自的、预先设置的最大运行资源规定的范围内运行，所述最大运行资源至少包括以下一项：可连接的数据库的数量、可运行的线程的数量、可占用的内存的申请量以及文件读写的频率。

E：安全业务提供服务器控制每一个应用在各自的、预先设置的访问权限中访问文件或数据，和/或，控制每一个应用在各自的、预先设置的访问权限中访问缓存空间。

F：安全业务提供服务器向所述用户展示所述应用及所述应用中包含的功能的列表，并且，在所述用户为登陆用户的情况下，向所述用户展示与所述用户的使用习惯相关的个性列表。

本实施例中所述方法能够提高安全业务提供服务器的可扩展性。

本申请实施例方法所述的功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算设备可读取存储介质中。基于这样的理解，本申请实施例对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该软件产品存储在一个存储介质中，包 括若干指令用以使得一台计算设备(可以是个人计算机，服务器，移动计算设备或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其它实施例的不同之处，各个实施例之间相同或相似部分互相参见即可。

对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本申请。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本申请的精神或范围的情况下，在其它实施例中实现。因此，本申请将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。