CN104869155B - 数据审计方法及装置 - Google Patents
数据审计方法及装置 Download PDFInfo
- Publication number
- CN104869155B CN104869155B CN201510204742.0A CN201510204742A CN104869155B CN 104869155 B CN104869155 B CN 104869155B CN 201510204742 A CN201510204742 A CN 201510204742A CN 104869155 B CN104869155 B CN 104869155B
- Authority
- CN
- China
- Prior art keywords
- data
- user
- access
- business
- abnormal
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Landscapes
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
Abstract
本发明公开了一种数据审计方法及装置,属于数据处理技术领域。方法包括:收集多个访问请求对应的访问数据,访问数据中至少包括访问请求的发起用户及访问请求对应的业务标识;根据访问数据,统计每个发起用户对每种业务的业务访问次数;根据每个发起用户对每种业务的业务访问次数,确定异常业务及异常用户。本发明通过收集多个访问请求对应的访问数据,根据访问数据,统计每个发起用户对每种业务的业务访问次数,根据每个发起用户对每种业务的业务访问次数,确定异常业务及异常用户。由于数据审计的过程是基于服务器自动收集的访问数据,分析出异常业务及异常用户,从而不需要较多的人工操作,耗费的时间与资源较少。因此,数据的审计效率较高。
Description
技术领域
本发明涉及数据处理技术领域,特别涉及一种数据审计方法及装置。
背景技术
随着互联网的迅速发展,互联网业务越来越多。相应地,针对每项业务的访问请求也越来越多。由于可能会存在对业务的恶意访问,从而造成业务异常,为了防止业务受到恶意访问,通常需要对访问请求对应的访问数据进行审计。
相关技术在审计数据时,所采用的方法为:通过CDC(Change Data Capture,数据变更捕获)方式对访问数据进行初步审计,形成相应的审计数据表,由相关审计人员对审计数据表中的数据进行审计,从而确定异常业务及异常用户。
在实现本发明的过程中,发明人发现相关技术至少存在以下问题:
由于数据的审计过程需要由人工来完成,因此,当面对海量的互联网业务请求时,若采用相关技术对数据进行审计,会耗费较多的时间与资源,从而导致数据的审计效率较低。
发明内容
为了解决现有技术的问题,本发明实施例提供了一种数据审计方法及装置。所述技术方案如下:
一方面,提供了一种数据审计方法,所述方法包括:
收集多个访问请求对应的访问数据,所述访问数据中至少包括访问请求的发起用户及访问请求对应的业务标识;
根据所述访问数据,统计每个发起用户对每种业务的业务访问次数;
根据所述每个发起用户对每种业务的业务访问次数,确定异常业务及异常用户。
另一方面,提供了一种数据审计装置,所述装置包括:
收集模块,用于收集多个访问请求对应的访问数据,所述访问数据中至少包括访问请求的发起用户及访问请求对应的业务标识;
统计模块,用于根据所述访问数据,统计每个发起用户对每种业务的业务访问次数;
确定模块,用于根据所述每个发起用户对每种业务的业务访问次数,确定异常业务及异常用户。
本发明实施例提供的技术方案带来的有益效果是:
通过收集多个访问请求对应的访问数据,根据访问数据,统计每个发起用户对每种业务的业务访问次数,根据每个发起用户对每种业务的业务访问次数,确定异常业务及异常用户。由于数据审计的过程是基于服务器自动收集的访问数据,分析出异常业务及异常用户,从而不需要较多的人工操作,耗费的时间与资源较少。因此,数据的审计效率较高。
附图说明
为了更清楚地说明本发明实施例中的技术方案,下面将对实施例描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本发明的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。
图1是本发明一实施例示出的一种数据审计方法涉及的实施环境示意图;
图2是本发明另一实施例示出的一种数据审计方法流程图;
图3是本发明另一实施例示出的一种数据审计方法流程图;
图4是本发明另一实施例示出的一种数据审计装置的结构示意图;
图5是本发明另一实施例示出的一种数据审计装置的结构示意图;
图6是本发明另一实施例示出的一种服务器的结构示意图。
具体实施方式
为使本发明的目的、技术方案和优点更加清楚,下面将结合附图对本发明实施方式作进一步地详细描述。
图1是本发明一实施例提供的一种数据审计方法所涉及的实施环境示意图。如图1所示,该实施环境包括业务逻辑服务器101、核心数据服务器102、审计数据中转服务器103、审计数据存储服务器104及数据审计服务器105。业务逻辑服务器101,核心数据服务器102、审计数据中转服务器103、审计数据存储服务器104及数据审计服务器105通过网络进行连接。该网络可以为有线网络,也可以为无线网络。
其中,业务逻辑服务器101用于接收终端的访问请求,根据访问请求,向核心数据服务器102请求核心数据。核心数据服务器102能根据业务逻辑服务器101的请求,返回相应的核心数据。在接收到请求时,核心数据服务器102对请求所对应的访问数据进行存储。业务逻辑服务器101根据核心数据服务器102返回的核心数据,按照预设逻辑,向终端返回用户需要访问的数据,从而完成相应的业务。核心数据可以包括用户的个人信息、用户相关联的好友用户信息等,本实施例不对核心数据的内容作具体限定。业务可以为请求用户信息业务、添加好友业务等等,本实施例不对具体涉及到的业务种类及内容作具体限定。
核心数据服务器102在获取到访问数据后,通过与后续的审计数据中转服务器103、审计数据存储服务器104及数据审计服务器105之间的分工协作,完成对访问数据的审计。需要说明的是,上述列举每种服务器都完成了数据审计过程中涉及到的一项至多项步骤,每种服务器可以为单一服务器,也可以为服务器集群,本实施例对此不作具体限定。另外,上述提及五种服务器中任意多种服务器也可以进行合并,即通过一种服务器执行上述多种服务器所涉及到的数据审计步骤,从而可形成不同的服务器架构,本实施例对此也不作具体限定。例如,可通过一种服务器实现审计数据中转服务器103与审计数据存储服务器104的功能。结合上述对于实施环境的描述,数据审计方法的具体内容详见下述各个实施例。
结合上述图1所示的实施环境,本发明实施例提供了一种数据审计方法,该方法应用于服务器。参见图2,本实施例提供的方法流程包括:
201、收集多个访问请求对应的访问数据,访问数据中至少包括访问请求的发起用户及访问请求对应的业务标识。
202、根据访问数据,统计每个发起用户对每种业务的业务访问次数。
203、根据每个发起用户对每种业务的业务访问次数,确定异常业务及异常用户。
本发明实施例提供的方法,通过收集多个访问请求对应的访问数据,根据访问数据,统计每个发起用户对每种业务的业务访问次数,根据每个发起用户对每种业务的业务访问次数,确定异常业务及异常用户。由于数据审计的过程是基于服务器自动收集的访问数据,分析出异常业务及异常用户,从而不需要较多的人工操作,耗费的时间与资源较少。因此,数据的审计效率较高。
作为一种可选实施例,收集多个访问请求对应的访问数据,包括:
当接收到任一访问请求时,将访问请求对应的访问数据存储至数据容器中;
当数据容器中存储的访问数据量达到预设数值,或者访问数据在数据容器中的存储时间达到预设时长时,将数据容器中的访问数据存储至共享内存;
从共享内存中获取所存储的访问数据。
作为一种可选实施例,访问数据中包括访问请求对应的业务接口,根据访问数据,统计每个发起用户对每种业务的业务访问次数之前,还包括:
预先为每种业务接口设置对应的级别信息,级别信息用于表示业务接口的重要程度;
按照业务接口对应的级别信息,为每种业务接口配置相应的采样比例;
根据访问数据中的业务接口,按照每种业务接口相应的采样比例,对访问数据进行筛选;
根据访问数据,统计每个发起用户对每种业务的业务访问次数,包括:
基于筛选后的访问数据执行统计每个发起用户对每种业务的业务访问次数的步骤。
作为一种可选实施例,根据访问数据,统计每个发起用户对每种业务的业务访问次数,包括:
根据访问数据中访问请求的发起用户,将包括相同发起用户的访问数据存储至同一数据库中,每个发起用户对应一个数据库;
对于任一数据库,统计每种业务标识对应的指定访问数据的数量,作为任一数据库对应的发起用户访问每种业务的业务访问次数,每种业务标识对应的指定访问数据为包含相同业务标识的访问数据。
作为一种可选实施例,根据每个发起用户对每种业务的业务访问次数,确定异常业务及异常用户,包括:
对于任一发起用户,当存在业务访问次数大于预设访问阈值时,将满足条件的业务访问次数对应的业务作为异常业务;
按照每个发起用户访问每种异常业务的业务访问次数,对发起用户进行排序,按照排序结果,选择预设数量个发起用户,将选取的预设数量个发起用户作为异常用户。
上述所有可选技术方案,可以采用任意结合形成本发明的可选实施例,在此不再一一赘述。
结合上述图1所示的实施环境,本发明实施例提供了一种数据审计方法,该方法用于服务器。参见图3,本实施例提供的方法流程包括:
301、当接收到任一访问请求时,将访问请求对应的访问数据存储至数据容器中,访问数据中至少包括访问请求的发起用户及访问请求对应的业务标识。
终端可以向服务器发送访问请求,服务器可接收终端发送的业务请求。结合上述图1所提供的实施环境,接收终端发送业务请求的可以为业务逻辑服务器。具体地,业务逻辑服务器可以接收终端发送的访问请求,根据访问请求,向核心数据服务器发送获取核心数据的请求。核心数据服务器根据业务逻辑服务器的请求返回核心数据,由业务逻辑服务器根据核心数据完成相应的业务。与此同时,核心数据服务器获取请求中的访问数据,将访问数据存储在数据容器中。其中,访问数据中可以包括访问请求的发起用户、访问请求发起终端的IP(Internet Protocol,网际互连协议)地址及访问请求对应的业务标识等,本实施例不对访问数据中的内容作具体限定。需要说明的是,访问数据中包括的发起用户可以为发起用户对应的用户标识,本实施例对此不作具体限定。数据容器可以为在核心数据服务器的存储设备上开辟的一块存储空间,该空间大小及位置可以根据需求进行设置,本实施例对此也不作具体限定。
需要说明的是,由于业务逻辑服务器接收到的访问请求通常是海量的,因此,核心数据服务器每当接收到业务逻辑服务器发送的请求时,可将请求对应的访问数据存储至数据容器中,以便后续对访问数据作进一步地处理。
302、当数据容器中存储的访问数据量达到预设数值,或者访问数据在数据容器中的存储时间达到预设时长时,将数据容器中的访问数据存储至共享内存。
通过上述步骤301,核心数据服务器将访问数据存储至数据容器后,可实时检测数据容器中存储的访问数据量是否达到是预设数值,当数据容器中存储的访问数据量达到预设阈值时,将数据容器中的访问数据存储至共享内存。其中,共享内存可以为核心数据服务器中的内存上开辟的一块存储空间,核心数据服务器上所有的线程都可以对该存储空间中的数据进行访问。
或者,还可以为最先存储至数据容器中的访问数据设置一个计时器,当第一个访问数据存储至数据容器时,该计时器开始计时,从而可对第一个访问数据在数据容器中的存储时间进行记录。当检测到该计时器的数值到达预设时长时,将数据容器中的访问数据存储至共享内存中。
由于在将数据容器中的访问数据存储至共享内存中时,若每当数据容器中来到一个新的访问数据,便将访问数据存储至共享内存中,则可能会因为存储过程较为频繁,占用了较多的资源,从而可能会影响核心数据服务器对相关业务进行处理。因此,通过本步骤中提供的方法,每隔一段时间,再将数据容器中的数据转移至共享内存中,从而能保证核心数据服务器的处理性能不受影响。
303、从共享内存中获取所存储的访问数据。
结合上述图1所提供的实施环境,核心数据服务器在将访问数据存储至共享内存中后,可将共享内存中的访问数据传输至审计数据中转服务器,从而审计数据中转服务器能够获取访问数据,并对访问数据作进一步地处理。
由于核心数据服务器需要对业务逻辑服务器发送的请求进行实时处理,因此,为了不影响核心数据服务器对相关业务进行处理,核心数据服务器可通过异步线程,将共享内存中的访问数据上报至审计数据中转服务器,从而审计数据中转服务器能够从共享内存中异步获取所存储的访问数据,本实施例对此不作具体限定。
由于核心数据服务器是通过异步的方式,将共享内存中的访问数据上报至审计数据中转服务器,从而核心数据服务器对相关业务的处理过程不会因上报过程而受到影响,进而能保证核心数据服务器的处理性能。
需要说明的是,通过异步的方式,将共享内存中的访问数据上报至审计数据中转服务器时,每次上报的数据量以及上报时间间隔可以根据实际情况进行调整,以在保证核心数据服务器的业务处理性能的前提下,尽可能减少核心数据服务器在将访问数据上报至审计数据中转服务器时所形成的网络延时,本实施例对此不作具体限定。
304、根据访问数据,统计每个发起用户对每种业务的业务访问次数。
由于访问数据通常是海量的,经过上述步骤303后,若对所有获取到的访问数据进行处理,则会因为访问数据量过大,占用较多的资源与时间,影响后续数据审计的效率。针对上述情况,由于访问请求对应的业务接口通常会有不同的重要程度,从而可根据访问请求对应业务接口的重要程度,对访问数据进行筛选。具体地,对于重要程度较高的业务接口,可对应选取较多的访问数据。对于重要程度较低的业务接口,可对应选取较少的访问数据,从而能在可控范围内,尽量避免出现因对海量访问数据进行审计,导致占用了较多的资源与时间,进而影响数据审计效率的情形。
需要说明的是,业务接口可以为核心数据服务器提供的获取核心数据函数,本实施例对此不作具体限定。通过业务接口,核心数据服务器能够根据业务逻辑服务器的请求,获取相应的核心数据,进而向业务逻辑服务器返回获取到的核心数据。
以上述内容作为基础,访问数据中还可包括访问请求对应的业务接口,在根据访问数据,统计每个发起用户对每种业务的业务访问次数之前,还可以预先为每种业务接口设置对应的级别信息,按照业务接口对应的级别信息,为每种业务接口配置相应的采样比例,根据访问数据中的业务接口,按照每种业务接口相应的采样比例,对访问数据进行筛选,本实施例对此不作具体限定。其中,级别信息用于表示业务接口的重要程度,级别越高对应的重要程度越高,级别越低对应的重要程度也越低。同时,级别越高的业务接口配置的采样比例越高,级别越低的业务接口配置的采样比例也越低。
通过上述对访问数据的筛选过程,除了能尽量减少后续数据审计量,保证审计效率之外,由于针对重要程度较高的业务接口配置了较高的采样比例,从而还使得重要程度较高的业务接口对应的访问数据能够尽可能地被审计,进而能够保证重要业务的业务安全。
例如,以业务接口包括三种为例,分别为第一业务接口、第二业务接口及第三业务接口。若预先为每种业务接口设置对应的级别信息为第一业务接口的重要程度最高、第二业务接口的重要程度次之、第三业务接口的重要程度最低,则按照业务接口对应的级别信息,可以为每种业务接口配置相应的采样比例,如第一业务接口的采样比例为80%,第二业务接口的采样比例为50%,第三业务接口的采样比例为30%。
若在所有的访问数据中,包含第一业务接口的访问数据为200个,包含第二业务接口的访问数据为300个,包含第三业务接口的访问数据为150个,则按照每种业务接口相应的采样比例,可对包含每种业务接口的访问数据进行筛选,最终可筛选出(200×80%=)160个包含第一业务接口的访问数据,(300×50%=)150个包含第二业务接口的访问数据,(150×30%=)45个包含第三业务接口的访问数据。
在对访问数据进行筛选后,在根据访问数据,统计每个发起用户对每种业务的业务访问次数时,可基于筛选后的访问数据统计每个发起用户对每种业务的业务访问次数,本实施例对此不作具体限定。
关于根据访问数据,统计每个发起用户对每种业务的业务访问次数的方式,本实施例对此不作具体限定,包括但不限于:根据访问数据中访问请求的发起用户,将包括相同发起用户的访问数据存储至同一数据库中,每个发起用户对应一个数据库;对于任一数据库,统计每种业务标识对应的指定访问数据的数量,作为任一数据库对应的发起用户访问每种业务的业务访问次数,每种业务标识对应的指定访问数据为包含相同业务标识的访问数据。
结合上述图1所提供的实施环境,审计数据中转服务器在对访问数据进行筛选后,可将筛选后的采样数据传输至审计数据存储服务器。其中,审计数据存储服务器可为一个按照分布式数据库***架构而成的集群,该集群中可包含多个节点,每个节点都拥有各自的数据库、中央处理器等等,本实施例对此不作具体限定。审计数据存储服务器在接收到审计数据中转服务器传输的访问数据后,可根据访问数据中的用户标识,将同一发起用户对应的访问数据存储至同一节点的数据库中。每个节点可统计各自数据库中每种业务标识对应的指定访问数据的数量,并作为任一数据库对应的发起用户访问每种业务的业务访问次数。
需要说明的是,在将包括相同发起用户的访问数据存储至同一数据库中时,多个发起用户可以共用一个数据库,即一个数据库可用于存储多个发起用户的访问数据,本实施例对此不作具体限定。
例如,如图1所示,审计数据存储服务器可将同一发起用户对应的访问数据存储至同一节点的数据库中,从而每个节点可对自身数据库中的数据进行统计。以其中任一数据库为例,数据库中存储的访问数据可以如下表1所示,表1为用户1对应的访问数据。
表1
访问数据 | 包含的业务标识 |
Access_Data1 | Service_ID1 |
Access_Data2 | Service_ID2 |
Access_Data3 | Service_ID1 |
Access_Data4 | Service_ID1 |
Access_Data5 | Service_ID2 |
Access_Data6 | Service_ID1 |
…… | …… |
由上表1中的数据可知,用户1对业务标识为Service_ID1的业务访问次数为4次,对业务标识为Service_ID2的业务访问次数为2次。
305、根据每个发起用户对每种业务的业务访问次数,确定异常业务及异常用户。
结合上述图1所提供的实施环境,具体在根据每个发起用户对每种业务的业务访问次数,确定异常业务及异常用户时,可包括但不限于如下两种实施过程:
第一种实施过程:各个节点在统计每个发起用户对每种业务的业务访问次数之后,可各自根据每个发起用户对每种业务的业务访问次数,确定异常业务,再将确定的结果统一上传至数据审计服务器,由数据审计服务器根据每个发起用户对每种异常业务的业务访问次数,确定异常用户,并作进一步地汇总审计,从而确定最终的异常业务及异常用户。
第二种实施过程:各个节点在统计每个发起用户对每种业务的业务访问次数之后,还可直接将各自统计的业务访问次数统一上传至数据审计服务器,由数据审计服务器进行汇总审计,从而确定异常业务及异常用户。
结合上述第一种实施过程,本实施例不对本实施例不对根据每个发起用户对每种业务的业务访问次数,确定异常业务及异常用户的方式作具体限定,包括但不限于:对于任一发起用户,当存在业务访问次数大于预设访问阈值时,将满足条件的业务访问次数对应的业务作为异常业务;按照每个发起用户访问每种异常业务的业务访问次数,对发起用户进行排序,按照排序结果,选择预设数量个发起用户,将选取的预设数量个发起用户作为异常用户。需要说明的是,上述确定异常业务的过程可由审计数据存储服务器下的各个节点执行,确定异常用户的过程可由数据审计服务器执行。
例如,以发起用户为用户1为例。若用户1对业务1的访问次数为100次,对业务2的访问次数为200次,对业务3的访问次数为300次,预设访问阈值为250,则可确定用户1对业务3的访问次数超过了预设访问阈值,从而可将业务3作为异常业务。
各个节点在确定异常业务后,可将每个发起用户访问每种异常业务的业务访问次数上传至数据审计服务器,数据审计服务器可按照每个发起用户访问每种异常业务的业务访问次数,对发起用户进行排序,按照排序结果,选择预设数量个发起用户,作为异常用户。例如,以异常业务为业务1为例,每个发起用户访问业务1的业务访问次数可如下表2所示:
表2
发起用户 | 业务访问次数 |
用户1 | 100 |
用户2 | 80 |
用户3 | 200 |
用户4 | 250 |
用户5 | 180 |
用户6 | 300 |
…… | …… |
按照业务访问次数从大到小对用户进行排序,排序结果为用户6、用户4、用户3、用户5、用户1及用户2。若预设数量为3个,则可以选取用户6、用户4及用户3作为异常用户。
另外,为了进一步地减少数据的审计量,在确定每种异常业务下的异常用户后,可按照异常业务的业务接口对应的级别信息,对每种业务下的异常用户作进一步地筛选。其中,重要程度较高的业务接口可选取较多的异常用户,重要程度较低的业务接口可选取较少的异常用户,具体过程可参考上述步骤304中的内容,此处不再赘述。通过该方法能够减少审计数据量,从而进一步地提高审计效率。
结合上述第一种实施过程,本实施例不对根据每个发起用户对每种业务的业务访问次数,确定异常业务及异常用户的方式作具体限定,包括但不限于:根据每个发起用户访问每种业务所使用的IP地址,确定异常业务及异常用户。为了实现上述过程,在上述步骤301中,访问数据还可以包括访问请求发起终端的IP地址,本实施例对此不作具体限定。
本实施例不对根据每个发起用户访问每种业务所使用的IP地址,确定异常业务及异常用户的方式作具体限定,包括但不限于:对于任一业务,当存在访问该业务的IP地址对应的发起用户数量超过预设用户阈值时,则将该业务作为异常业务,将满足条件的发起用户作为异常用户。
需要说明的是,上述过程主要适用于用户通过不断更换用户标识,来对同一业务进行访问的场景。由于用户虽然更换了用户标识,但发起访问所使用的IP地址一般没有改变,若存在用户企图通过不断更换用户标识来对业务进行恶意访问,则可根据访问业务的IP地址及对应的用户标识,对恶意用户进行识别。
例如,以业务1为例。访问业务1的IP地址及用户标识可如下表3所示:
表3
用户标识 | IP地址 |
ID1 | 192.168.1.13 |
ID2 | 192.168.1.14 |
ID3 | 192.168.1.13 |
ID4 | 192.168.1.13 |
ID5 | 192.168.1.15 |
ID6 | 192.168.1.13 |
…… | …… |
由上表1可知,IP地址192.168.1.13对应的用户使用了4个用户标识。若预设用户阈值为3,则可确定IP地址192.168.1.13对应的用户为异常用户,业务1为异常业务,从而可对该IP地址对应的用户标识采取措施,以防止该用户通过上述列表中的用户标识对业务进行恶意访问。
需要说明的是,上述两种实施过程对应的审计方式均为主动对访问数据进行审计。在实际应用场景中,还可以通过被动审计方式对数据进行审计。具体地,通过蜜罐技术设置伪业务漏洞,当存在用户恰好通过伪业务漏洞对业务进行恶意访问时,则可将这些用户作为异常用户,将被恶意访问的业务作为异常业务。例如,以即时通讯业务为例。由于用户在进行即时通讯时,通常需要先向即时通讯服务器注册一个帐号,如一串号码,再通过该号码与其它号码的用户进行通讯。因此,即时通讯服务器在向外界开放注册号码时,可预先设置一些不能被注册的伪号码。当存在用户通过伪号码发送业务请求时,由于用户不可能事先注册到这些伪号码,则可确定该业务请求对应的业务为异常业务,发送业务请求的用户为异常用户。
另外,在确定异常业务与异常用户后,可对异常业务最近的业务数据及异常用户最近的行为数据进行分析,从而根据分析结果作相应的处理,保证业务能够正常进行。或者,还可以对异常业务及异常用户进行告警,由工作人员进行人工分析,以作相应的处理,从而保证业务能够正常进行,本实施例对此不作具体限定。具体处理过程可以由实际情况决定,如禁止异常用户继续访问业务等,本实施例对此也不作具体限定。
本发明实施例提供的方法,通过收集多个访问请求对应的访问数据,根据访问数据,统计每个发起用户对每种业务的业务访问次数,根据每个发起用户对每种业务的业务访问次数,确定异常业务及异常用户。由于在审计数据传输过程中,是采用异步的方式,从而不会耽误服务器对业务进行处理,保证了业务处理的效率。另外,数据审计之前对数据进行了筛选,在保证了重要程度较高的数据能被审计的同时,还减少了数据审计量。最后,由于数据审计的过程是基于服务器自动收集的访问数据,分析出异常业务及异常用户,从而不需要较多的人工操作,耗费的时间与资源较少。因此,数据的审计效率较高。
本发明实施例提供了一种数据审计装置,该装置用于执行上述图2或图3对应的实施例所提供的数据审计方法。参见图4,该装置包括:
收集模块401,用于收集多个访问请求对应的访问数据,访问数据中至少包括访问请求的发起用户及访问请求对应的业务标识;
统计模块402,用于根据访问数据,统计每个发起用户对每种业务的业务访问次数;
确定模块403,用于根据每个发起用户对每种业务的业务访问次数,确定异常业务及异常用户。
作为一种可选实施例,收集模块401,用于当接收到任一访问请求时,将访问请求对应的访问数据存储至数据容器中;当数据容器中存储的访问数据量达到预设数值,或者访问数据在数据容器中的存储时间达到预设时长时,将数据容器中的访问数据存储至共享内存;从共享内存中获取所存储的访问数据。
作为一种可选实施例,参见图5,该装置还包括:
设置模块404,用于预先为每种业务接口设置对应的级别信息,级别信息用于表示业务接口的重要程度;
配置模块405,用于按照业务接口对应的级别信息,为每种业务接口配置相应的采样比例;
筛选模块406,用于根据访问数据中的业务接口,按照每种业务接口相应的采样比例,对访问数据进行筛选;
该统计模块402,用于基于筛选后的访问数据执行统计每个发起用户对每种业务的业务访问次数的步骤。
作为一种可选实施例,统计模块402,用于根据访问数据中访问请求的发起用户,将包括相同发起用户的访问数据存储至同一数据库中,每个发起用户对应一个数据库;对于任一数据库,统计每种业务标识对应的指定访问数据的数量,作为任一数据库对应的发起用户访问每种业务的业务访问次数,每种业务标识对应的指定访问数据为包含相同业务标识的访问数据。
作为一种可选实施例,确定模块403,用于对于任一发起用户,当存在业务访问次数大于预设访问阈值时,将满足条件的业务访问次数对应的业务作为异常业务;按照每个发起用户访问每种异常业务的业务访问次数,对发起用户进行排序,按照排序结果,选择预设数量个发起用户,将选取的预设数量个发起用户作为异常用户。
本发明实施例提供的装置,通过收集多个访问请求对应的访问数据,根据访问数据,统计每个发起用户对每种业务的业务访问次数,根据每个发起用户对每种业务的业务访问次数,确定异常业务及异常用户。由于数据审计的过程是基于服务器自动收集的访问数据,分析出异常业务及异常用户,从而不需要较多的人工操作,耗费的时间与资源较少。因此,数据的审计效率较高。
图6是根据一示例性实施例示出的一种服务器600的框图。参照图6,服务器600包括处理组件622,其进一步包括一个或多个处理器,以及由存储器632所代表的存储器资源,用于存储可由处理组件622的执行的指令,例如应用程序。存储器632中存储的应用程序可以包括一个或一个以上的每一个对应于一组指令的模块。此外,处理组件622被配置为执行指令,以执行上述数据审计方法。
服务器600还可以包括一个电源组件626被配置为执行服务器600的电源管理,一个有线或无线网络接口650被配置为将服务器600连接到网络,和一个输入输出(I/O)接口658。服务器600可以操作基于存储在存储器632的操作***,例如Windows ServerTM,MacOS XTM,UnixTM,LinuxTM,FreeBSDTM或类似。
本发明实施例提供的服务器,通过收集多个访问请求对应的访问数据,根据访问数据,统计每个发起用户对每种业务的业务访问次数,根据每个发起用户对每种业务的业务访问次数,确定异常业务及异常用户。由于数据审计的过程是基于服务器自动收集的访问数据,分析出异常业务及异常用户,从而不需要较多的人工操作,耗费的时间与资源较少。因此,数据的审计效率较高。
需要说明的是:上述实施例提供的数据审计装置在审计数据时,仅以上述各功能模块的划分进行举例说明,实际应用中,可以根据需要而将上述功能分配由不同的功能模块完成,即将装置的内部结构划分成不同的功能模块,以完成以上描述的全部或者部分功能。另外,上述实施例提供的数据审计装置与数据审计方法实施例属于同一构思,其具体实现过程详见方法实施例,这里不再赘述。
本领域普通技术人员可以理解实现上述实施例的全部或部分步骤可以通过硬件来完成,也可以通过程序来指令相关的硬件完成,所述的程序可以存储于一种计算机可读存储介质中,上述提到的存储介质可以是只读存储器,磁盘或光盘等。
以上所述仅为本发明的较佳实施例,并不用以限制本发明,凡在本发明的精神和原则之内,所作的任何修改、等同替换、改进等,均应包含在本发明的保护范围之内。
Claims (8)
1.一种数据审计方法,其特征在于,所述方法包括:
收集多个访问请求对应的访问数据,所述访问数据中至少包括访问请求的发起用户、访问请求对应的业务标识及所述访问请求对应的业务接口;
预先为每种业务接口设置对应的级别信息,所述级别信息用于表示业务接口的重要程度;按照业务接口对应的级别信息,为每种业务接口配置相应的采样比例;根据访问数据中的业务接口,按照每种业务接口相应的采样比例,对访问数据进行筛选;
基于筛选后的访问数据,统计每个发起用户对每种业务的业务访问次数;
根据所述每个发起用户对每种业务的业务访问次数,确定异常业务及异常用户。
2.根据权利要求1所述的方法,其特征在于,所述收集多个访问请求对应的访问数据,包括:
当接收到任一访问请求时,将所述访问请求对应的访问数据存储至数据容器中;
当所述数据容器中存储的访问数据量达到预设数值,或者访问数据在所述数据容器中的存储时间达到预设时长时,将所述数据容器中的访问数据存储至共享内存;
从所述共享内存中获取所存储的访问数据。
3.根据权利要求1所述的方法,其特征在于,所述方法,还包括:
根据访问数据中访问请求的发起用户,将包括相同发起用户的访问数据存储至同一数据库中,每个发起用户对应一个数据库;
对于任一数据库,统计每种业务标识对应的指定访问数据的数量,作为所述任一数据库对应的发起用户访问每种业务的业务访问次数,所述每种业务标识对应的指定访问数据为包含相同业务标识的访问数据。
4.根据权利要求1所述的方法,其特征在于,所述根据所述每个发起用户对每种业务的业务访问次数,确定异常业务及异常用户,包括:
对于任一发起用户,当存在业务访问次数大于预设访问阈值时,将满足条件的业务访问次数对应的业务作为异常业务;
按照每个发起用户访问每种异常业务的业务访问次数,对发起用户进行排序,按照排序结果,选择预设数量个发起用户,将选取的预设数量个发起用户作为异常用户。
5.一种数据审计装置,其特征在于,所述装置包括:
收集模块,用于收集多个访问请求对应的访问数据,所述访问数据中至少包括访问请求的发起用户、访问请求对应的业务标识及所述访问请求对应的业务接口;
设置模块,用于预先为每种业务接口设置对应的级别信息,所述级别信息用于表示业务接口的重要程度;配置模块,用于按照业务接口对应的级别信息,为每种业务接口配置相应的采样比例;
筛选模块,用于根据访问数据中的业务接口,按照每种业务接口相应的采样比例,对访问数据进行筛选;
统计模块,用于基于筛选后的访问数据,统计每个发起用户对每种业务的业务访问次数;
确定模块,用于根据所述每个发起用户对每种业务的业务访问次数,确定异常业务及异常用户。
6.根据权利要求5所述的装置,其特征在于,所述收集模块,用于当接收到任一访问请求时,将所述访问请求对应的访问数据存储至数据容器中;当所述数据容器中存储的访问数据量达到预设数值,或者访问数据在所述数据容器中的存储时间达到预设时长时,将所述数据容器中的访问数据存储至共享内存;从所述共享内存中获取所存储的访问数据。
7.根据权利要求5所述的装置,其特征在于,所述统计模块,用于根据访问数据中访问请求的发起用户,将包括相同发起用户的访问数据存储至同一数据库中,每个发起用户对应一个数据库;对于任一数据库,统计每种业务标识对应的指定访问数据的数量,作为所述任一数据库对应的发起用户访问每种业务的业务访问次数,所述每种业务标识对应的指定访问数据为包含相同业务标识的访问数据。
8.根据权利要求5所述的装置,其特征在于,所述确定模块,用于对于任一发起用户,当存在业务访问次数大于预设访问阈值时,将满足条件的业务访问次数对应的业务作为异常业务;按照每个发起用户访问每种异常业务的业务访问次数,对发起用户进行排序,按照排序结果,选择预设数量个发起用户,将选取的预设数量个发起用户作为异常用户。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201510204742.0A CN104869155B (zh) | 2015-04-27 | 2015-04-27 | 数据审计方法及装置 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201510204742.0A CN104869155B (zh) | 2015-04-27 | 2015-04-27 | 数据审计方法及装置 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN104869155A CN104869155A (zh) | 2015-08-26 |
CN104869155B true CN104869155B (zh) | 2018-09-18 |
Family
ID=53914672
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201510204742.0A Active CN104869155B (zh) | 2015-04-27 | 2015-04-27 | 数据审计方法及装置 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN104869155B (zh) |
Families Citing this family (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN106294737A (zh) * | 2016-08-09 | 2017-01-04 | 无锡天脉聚源传媒科技有限公司 | 一种数据处理方法及装置 |
CN108416485B (zh) * | 2017-07-25 | 2021-10-08 | 平安科技(深圳)有限公司 | 用户身份识别方法、电子装置及计算机可读存储介质 |
CN109727027B (zh) * | 2018-06-01 | 2024-05-03 | 深圳市秋雨电子科技有限公司 | 账户识别方法、装置、设备及存储介质 |
CN108881246A (zh) * | 2018-06-27 | 2018-11-23 | 中国联合网络通信集团有限公司 | 一种容器安全防护的方法及装置 |
CN110363014A (zh) * | 2019-07-05 | 2019-10-22 | 上海瀚之友信息技术服务有限公司 | 一种数据库的审计*** |
CN110727727B (zh) * | 2019-10-15 | 2023-01-10 | 深圳前海微众银行股份有限公司 | 一种数据库的统计方法及装置 |
CN111061588A (zh) * | 2019-12-13 | 2020-04-24 | 北京奇艺世纪科技有限公司 | 一种定位数据库异常来源的方法及装置 |
CN113660277B (zh) * | 2021-08-18 | 2023-01-06 | 广州优视云集科技有限公司 | 一种基于复用埋点信息的反爬虫方法及处理终端 |
CN117294529B (zh) * | 2023-11-24 | 2024-01-30 | 成都安美勤信息技术股份有限公司 | 一种智慧医疗平台异常登录检测方法及*** |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101203052A (zh) * | 2007-12-24 | 2008-06-18 | 华为技术有限公司 | 一种防范恶意业务请求的方法和设备 |
CN101442449A (zh) * | 2008-12-18 | 2009-05-27 | ***通信集团浙江有限公司 | 一种集中访问模式下用户行为全面审计的方法 |
CN102083089A (zh) * | 2009-11-27 | 2011-06-01 | ***通信集团山东有限公司 | 一种访问业务监控方法、***及装置 |
-
2015
- 2015-04-27 CN CN201510204742.0A patent/CN104869155B/zh active Active
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101203052A (zh) * | 2007-12-24 | 2008-06-18 | 华为技术有限公司 | 一种防范恶意业务请求的方法和设备 |
CN101442449A (zh) * | 2008-12-18 | 2009-05-27 | ***通信集团浙江有限公司 | 一种集中访问模式下用户行为全面审计的方法 |
CN102083089A (zh) * | 2009-11-27 | 2011-06-01 | ***通信集团山东有限公司 | 一种访问业务监控方法、***及装置 |
Also Published As
Publication number | Publication date |
---|---|
CN104869155A (zh) | 2015-08-26 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN104869155B (zh) | 数据审计方法及装置 | |
US9712415B2 (en) | Method, apparatus and communication network for root cause analysis | |
EP2563062B1 (en) | Long connection management apparatus and link resource management method for long connection communication | |
CN102916854B (zh) | 流量统计方法、装置及代理服务器 | |
EP2661020B1 (en) | Adaptive monitoring of telecommunications networks | |
EP2240854B1 (en) | Method of resolving network address to host names in network flows for network device | |
JP2020521383A5 (zh) | ||
CN110312279A (zh) | 一种网络数据的监测方法及装置 | |
CN107104840A (zh) | 一种日志监控方法、装置及*** | |
CN102142990B (zh) | 业务用量监控方法及设备 | |
CN108259425A (zh) | 攻击请求的确定方法、装置及服务器 | |
Qiao et al. | Characterizing flow, application, and user behavior in mobile networks: A framework for mobile big data | |
CN102929613B (zh) | 操作***的调优装置和方法 | |
CN105550248B (zh) | 用户信息挖掘方法及装置 | |
CN105468619B (zh) | 用于数据库连接池的资源分配方法和装置 | |
CN109067938A (zh) | 一种测试dns服务器的方法及装置 | |
CN109818820A (zh) | 流量数据监控方法、装置、电子设备及存储介质 | |
CN106067879B (zh) | 信息的检测方法及装置 | |
WO2016079046A1 (en) | Diagnostic testing in networks | |
CN108206769A (zh) | 过滤网络质量告警的方法、装置、设备和介质 | |
CN110430070A (zh) | 一种服务状态分析方法、装置、服务器、数据分析设备及介质 | |
CN114124773A (zh) | 一种端口块地址转换的测试***及方法 | |
CN109462617A (zh) | 一种局域网中设备通讯行为检测方法及装置 | |
WO2022001480A1 (zh) | 热门应用识别方法、网络***、网络设备及存储介质 | |
CN110222084B (zh) | 热点设备监控信息的上报方法及装置、存储介质、终端 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant | ||
TR01 | Transfer of patent right | ||
TR01 | Transfer of patent right |
Effective date of registration: 20190731 Address after: Shenzhen Futian District City, Guangdong province 518000 Zhenxing Road, SEG Science Park 2 East Room 403 Co-patentee after: Tencent cloud computing (Beijing) limited liability company Patentee after: Tencent Technology (Shenzhen) Co., Ltd. Address before: Shenzhen Futian District City, Guangdong province 518000 Zhenxing Road, SEG Science Park 2 East Room 403 Patentee before: Tencent Technology (Shenzhen) Co., Ltd. |