一种处理业务请求的方法及装置与流程

本发明涉及计算机
技术领域：
，尤其涉及一种处理业务请求的方法及装置。
背景技术：
：在计算机技术飞速发展和广泛应用的今天，信息安全变得越来越重要。在繁荣的互联网背后隐藏着大量的信息安全风险，常常有恶意用户通过网络对包括服务器在内的计算机设备进行攻击，这些攻击可能导致服务器无法正常工作，甚至造成信息泄露。例如，一种常见的攻击方式是恶意用户向服务器发送包含攻击信息的业务请求。目前，一般通过应用防火墙对传输至服务器的业务请求的数据包进行筛选和过滤，以尽量避免包含恶意信息的数据包传送至服务器而导致服务器遭到攻击，从而保证网络和信息安全。应用防火墙中一般设置有风险规则库，风险规则库中包括多种风险规则，应用防火墙可以将接收到的每个业务请求与风险规则库中的风险规则进行匹配比较，进而可以将认为是危险的应用请求直接丢弃。可见，在对业务请求进行筛选的过程中，应用防火墙只是简单地将业务请求划分为安全或者危险，在确定为危险时则直接将对应的业务请求丢弃，然而，由于风险规则库的限制，应用防火墙可能将安全的业务请求误判为是危险的业务请求，而导致业务请求的误丢弃，或者也可能将危险的业务请求误判为是安全的业务请求而导致安全隐患，也就是说，现有技术中的应用防火墙只能对业务请求进行安全或危险的简单划分，判定方式比较单一，在对业务请求的安全性进行判定时存在误判的可能，进而可能导致业务请求的误丢或者可能导致安全问题的产生。技术实现要素：本发明实施例提供一种处理业务请求的方法及装置，用于解决应用防火墙对业务请求的安全性的判断方式比较单一，进而导致对业务请求的安全性存在误判的技术问题。一方面，提供一种处理业务请求的方法，所述方法包括：应用防火墙接收与业务请求对应的业务请求信息；所述应用防火墙根据所述业务请求信息，确定用于表征所述业务请求的风险等级的风险等级信息；所述应用防火墙将所述业务请求信息和所述风险等级信息发送给业务服务器，其中，所述业务服务器用于根据所述风险等级信息确定如何处理所述业务请求。可选的，所述应用防火墙将所述业务请求信息和所述风险等级信息发送给业务服务器，包括：所述应用防火墙将所述业务请求信息和所述风险等级信息分别发送给所述业务服务器；或，所述应用防火墙将所述业务请求信息和所述风险等级信息合并为一条信息，并将所述一条信息发送给所述业务服务器。可选的，所述应用防火墙将所述业务请求信息和所述风险等级信息合并为一条信息，包括：所述应用防火墙将所述风险等级信息添加到所述业务请求信息的超文本传输协议(HyperTextTransferProtocol，HTTP)消息头中，获得包括所述风险等级信息的业务请求信息；所述应用防火墙确定所述包括所述风险等级信息的业务请求信息为所述一条信息。可选的，所述应用防火墙根据所述业务请求信息，确定用于表征所述业务请求的风险等级的风险等级信息，包括：所述应用防火墙解析所述业务请求信息，获得解析结果；所述应用防火墙将所述解析结果与风险规则库进行风险规则匹配，获得风险匹配结果；其中，所述风险规则库是基于所述应用防火墙所执行的更新操作而获得的更新后的风险规则库；所述应用防火墙根据所述风险匹配结果，确定所述风险等级信息。可选的，所述应用防火墙将所述业务请求信息和所述风险等级信息发送给所述业务服务器，包括：所述应用防火墙从与所述应用防火墙连接的至少一个业务服务器中确定满足预定条件的业务服务器；其中，所述满足预定条件的业务服务器为所述至少一个业务服务器中物理上距离所述业务请求的发送端最近的业务服务器，或，所述满足预定条件的服务器为所述至少一个业务服务器中当前传输流量最少的业务服务器；所述应用防火墙将所述业务请求信息和所述风险等级信息发送给所述满足预定条件的业务服务器。另一方面，提供一种处理业务请求的装置，所述装置包括：接收单元，用于接收与业务请求对应的业务请求信息；风险等级确定单元，用于根据所述业务请求信息，确定用于表征所述业务请求的风险等级的风险等级信息；发送单元，用于将所述业务请求信息和所述风险等级信息发送给业务服务器，其中，所述业务服务器用于根据所述风险等级信息确定如何处理所述业务请求。可选的，所述发送单元用于：将所述业务请求信息和所述风险等级信息分别发送给所述业务服务器；或，将所述业务请求信息和所述风险等级信息合并为一条信息，并将所述一条信息发送给所述业务服务器。可选的，所述发送单元用于：将所述风险等级信息添加到所述业务请求信息的HTTP消息头中，获得包括所述风险等级信息的业务请求信息；确定所述包括所述风险等级信息的业务请求信息为所述一条信息。可选的，所述装置还包括风险规则库；所述风险等级确定单元用于：解析所述业务请求信息，获得解析结果；将所述解析结果与所述风险规则库进行风险规则匹配，获得风险匹配结果；其中，所述风险规则库是基于所述应用防火墙所执行的更新操作而获得的更新后的风险规则库；根据所述风险匹配结果，确定所述风险等级信息。可选的，所述发送单元用于：从与所述装置连接的至少一个业务服务器中确定满足预定条件的业务服务器；其中，所述满足预定条件的业务服务器为所述至少一个业务服务器中物理上距离所述业务请求的发送端最近的业务服务器，或，所述满足预定条件的服务器为所述至少一个业务服务器中当前传输流量最少的业务服务器；将所述业务请求信息和所述风险等级信息发送给所述满足预定条件的业务服务器。本发明实施例中，当接收到包含业务请求的业务请求信息后，应用防火墙可以根据该业务请求信息对业务请求的风险进行分级，进而确定出该业务请求所对应的风险等级，例如可以划分为优质业务请求、安全业务请求，较危险业务请求，特别危险业务请求，等等，可见，本发明实施例对业务请求的风险等级划分更为详细，而非简单地将业务请求判定为是安全的或是危险的，相当于，通过更大力度和更细致的风险评估方式，使得对业务请求的风险评估更加的精细和客观，进而可以提高对业务请求的安全性进行评估的准确性。进一步地，应用防火墙将业务请求信息和该业务请求的风险等级信息一同发送给业务服务器，再由业务服务器根据风险等级信息对该业务请求进行处理，例如由业务服务器对业务请求进行丢弃、转发或者响应的处理，而无需由应用防火墙自身进行处理，这样可以避免由于应用防火墙对业务请求的安全性误判而导致的误丢或者导致一些安全问题的发生。此外，由于应用防火墙是将业务请求信息本身和风险等级信息一同发送给业务服务器，这样可以使得业务服务器能够根据不同的风险等级灵活、并行地对对应的业务请求进行处理，例如当确定风险等级为5时，表明业务请求是非常危险的，那么业务服务器可以直接丢弃该业务请求，或者，当确定风险等级为3时，表明业务请求存在一定的危险性，但是为了避免误丢，此时可以由用户再进行筛选以确定到底是否需要丢弃，等等，这样既可以保证风险的防范，也可以达到高效利用业务服务器资源的目的。附图说明为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据提供的附图获得其他的附图。图1为本发明实施例中的处理业务请求的方法的流程图；图2为本发明实施例中的确定业务请求的风险等级的流程图；图3为本发明实施例中风险规则库更新的示意图；图4为本发明实施例中HTTP消息的结构示意图；图5为本发明实施例中应用防火墙与多个业务服务器连接的示意图；图6为本发明实施例中的装置的结构框图。具体实施方式为使本发明的目的、技术方案和优点更加清楚明白，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。在不冲突的情况下，本发明中的实施例及实施例中的特征可以相互任意组合。并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。另外，本文中术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，本文中字符“/”，在不做特别说明的情况下，一般表示前后关联对象是一种“或”的关系。为了更好的理解上述技术方案，下面将结合说明书附图以及具体的实施方式对上述技术方案进行详细的说明。请参考图1，本发明实施例提供一种处理业务请求的方法，该方法可以应用于应用防火墙，即该方法中各步骤的执行主体可以是应用防火墙。该方法的流程描述如下。步骤101：接收与业务请求对应的业务请求信息。其中，业务请求例如可以是通讯请求、交易请求、支付请求、或者其他的业务请求，例如用户需要通过支付宝进行付款时，则可以向支付宝对应的业务服务器发起支付请求，等等。步骤102：根据业务请求信息，确定用于表征业务请求的风险等级的风险等级信息。在该步骤中对步骤101中接收到的业务请求信息进行处理，进而可以确定出业务请求的风险等级，其中，业务请求的风险等级可以用于指示业务请求存在风险的可能性，当存在风险的可能性越大时，表明对应的业务请求越危险。在具体实施过程中，可以设置多个风险等级，例如可以设置至少三个风险等级，当设置的风险等级的级别越多时，那么对于业务请求的划分也就可以更加精细，例如设置5个风险等级，那么应用防火墙则可以按照具体的风险等级划分方式将所接收到的业务请求划分为5个风险等级，即可以将接收到的所有的业务请求按照风险等级的不同而划分为5类。其中，风险等级信息可以通过多种能够表示风险等级的方式进行标识，例如由阿拉伯数字、罗马数字、字母等字符或由预先设定的代码、字段进行标识，等等。例如表1所示，可以将20％存在风险的业务请求划分到风险等级2的一类业务请求中，以及可以将43％存在风险的业务请求划分到风险等级3的一类业务请求中，等等。表1存在风险的可能性风险等级[0，10％)风险等级1[10％-30％)风险等级2[30％-60％)风险等级3[60％-80％)风险等级4[60％-100％]风险等级5例如可以依据用于发送业务请求的网际协议(InternetProtocol，IP)地址对业务请求进行风险等级的划分，或者，可以依据业务请求的发起时间对业务请求的风险等级进行划分，或者当业务请求为交易请求时，还可以依据所请求的交易金额对交易请求的风险等级进行划分，等等，在具体实施过程中，可以依据业务请求类型的不同设置不同的风险等级划分方式，或者可以对风险规则进行匹配的匹配结果设置不同的风险等级划分方式，或者还可以有其它的方式对业务请求的风险等级进行划分，本发明实施例不做限制。可选的，请参见图2，本发明实施例提供一种确定业务请求的风险等级的方式，具体可以包括以下步骤：步骤201：解析业务请求信息，获得解析结果；步骤202：将解析结果与风险规则库进行风险规则匹配，获得风险匹配结果；其中，风险规则库是基于应用防火墙所执行的更新操作而获得的更新后的风险规则库；步骤203：根据风险匹配结果，确定风险等级信息。其中，在步骤201中解析的内容可以是业务请求信息的所有内容，也可以根据实际需要对解析内容的范围进行预先设定，例如，解析的内容包含但不限于域名，IP地址，用户名，密码，业务规则，等等，在对业务请求信息进行解析之后可以获得针对业务请求信息的解析结果。其中，业务规则可以是指业务请求所对应的规则，例如当业务请求为交易请求时，业务规则可以为交易金额、交易数量、交易方式等等，再例如当业务请求为数据访问请求时，业务规则可以为访问内容的编码方式、业务请求发送端的设备类型等等，又例如当业务请求为数据更改请求时，业务规则可以为请求更改的数据类型、更改的方式、更改的生效时间等等。应用防火墙中可以预先保存有风险规则库，风险规则库可以是指包含多种风险规则的集合，可以将风险规则库理解为是包括多种风险规则数据的数据库，例如是指包括多种规则数据和逻辑判断规则的集合。其中，规则数据例如可以包括IP地址，域名，网络接入方式，安全类型、业务规则，等等，而其中的安全类型里可以包括结构化查询语言(StructuredQueryLanguage，SQL)注入或跨站脚本注入，等等。进一步地，应用防火墙可以将针对业务请求信息的解析结果与前述的风险规则库进行风险规则匹配，进而获得风险匹配结果。例如，当业务请求为交易请求且风险规则库中的业务规则表明交易金额不超过1000元，那么当解析结果表明交易金额为300元时，则可以认为该请求为安全的，例如将其风险等级确定为如表1中的风险等级1，而当解析结果表明交易金额为20000元时，则可以认为该请求具有风险并且由于请求的交易金额与预定的交易金额之间差距较多，那么可以将其风险等级确定为如表1中的风险等级4，等等。在具体实施实施过程中，在接收到一个业务请求时，可以同时将其解析结果与风险规则库中的一种或多种风险规则进行匹配比较，当只与一种风险规则进行匹配比较时可以在较短时间内即完成匹配过程，确定风险等级的效率较高，当与多种风险规则同时或先后进行匹配比较的话，可以利用决策树法或规则引擎或专家调查法等方法进行匹配以获得匹配结果，通过多种风险规则的匹配可以提高对风险等级确定的准确性，并且还可以获得更加精细的风险等级划分结果。另外，风险规则库可以为静态的，即风险规则库是保持不变的，或者也可以为动态可更新的，即可以对风险规则库进行动态的更新，以使得风险规则库中的风险规则可以随着更新操作而发生相应的变化，例如增加风险规则库所包括的风险规则的种类，例如可以采用如图3所示的方式对风险规则库进行更新以获得更新后的风险规则库，即针对原始的风险规则库进行更新操作，原始的风险规则库在对更新操作进行响应之后，即可以完成更新以获得更新后的风险规则库。风险规则库更新的方式有多种，例如可以对已有的规则数据进行数据更新，或者也可以根据实际需要增加或者减少规则数据的类型。可行的一种实施方式，根据实际使用的规则数据类型调整解析单元的解析内容范围，同理，也可以根据解析单元能够解析的内容范围确定所需的规则数据类型。另外，可以在任意时刻对风险规则库进行更新，例如可以在步骤201之前，或者可以在步骤201之后，或者还可以在步骤203之后，等等，也就是说，可以在任意时刻对风险规则库进行更新，这样以便可以动态、及时的获得更新后的风险规则库。在具体实施过程中，对于风险规则库的调整，可以采用规则引擎进行自动的数据库收集、下载以完成更新，即应用防火墙对风险规则库进行自动更新，可选的，可以按照预定的更新周期自动定时更新，例如每隔一天更新一次，或者每隔两天更新一次，等等，或者也可以通过人工调整的方式对风险规则库中的规则数据和/或规则进行增删等更新操作，该调整的过程时时生效，以确保更新后的风险规则库能够及时地被应用防火墙使用，这样可以便于应用防火墙根据更新后的风险规则库对业务请求类型的划分可以更加精细、准确。另外，由于将风险规则库单独作为应用防火墙中的一个模块，比如采用规则引擎，能够在更新风险规则库的过程中，可以不需要关闭服务器或者暂停服务器，以确保服务器的持续正常运行。风险规则库更新的方式包括，动态采集用户的业务请求数据，更新风险规则。例如某用户历史上每周的交易业务请求数量均为5次，风险规则库则设定该用户每周的交易业务请求在5次及以下时为安全，并确定该用户每周的前5次交易业务请求的风险等级为如表1中的风险等级1。又例如该用户在某一周的交易业务请求数量达到了6次，风险规则库对该用户的第6次交易业务请求进行风险规则匹配时，则会确认该次交易业务请求具有一定的风险，并进一步确认该次交易业务请求的风险等级，如确认为表1中的风险等级3。但若该用户连续5周的交易业务请求数量均达到了6次，则风险规则库则调整该用户每周的交易业务请求在6次及以下时为安全。风险规则库的规则数据来源可以是互联网上公开的信息，例如危险IP地址名单、域名黑白名单，或者也可以是通过分析已知数据得到的新的规则数据，例如分析日志数据获得规则数据，或者也可以是业务服务器自身的业务规则，或者还可以是其它的能够获得数据的来源，等等，本发明实施例不做限制。进一步地，通过匹配结果确定业务请求的风险等级，即确定风险等级信息，该风险等级信息表征了业务请求的风险情况。例如当风险等级信息通过阿拉伯数字进行标识时，可采用如风险等级1表示安全，风险等级2表示较安全，风险等级3表示可能有危险，风险等级4表示危险程度低，风险等级5表示非常危险，即如表1所示。步骤103：根据业务请求信息，将业务请求信息和风险等级信息发送给业务服务器。在确定出了风险等级信息后，便可以将业务请求信息和风险等级信息发送给业务服务器进行处理，以便业务服务器可以根据风险等级对业务请求进行对应的处理，例如进行丢弃、响应或转发等处理。本发明实施例中，业务服务器可以对同一类型或者同一风险等级的多个业务请求进行分组处理，便于提高处理效率，同时，业务服务器可以直接为用户提供交互操作接口，便于用户直接与业务服务器进行交互操作，这样可以便于对一些业务请求进行人工处理，例如，当业务服务器接收到风险等级如表1中的风险等级3的业务请求时，此时为了能够对该业务请求是否丢弃进行准确的判断，用户可以直接判断该业务请求到底是否具有危险，如果用户确定其确实是危险则可以通过业务服务器将其丢弃，如果用户确定其是安全的则可以由业务服务器进行下一步处理，例如将其进行转发或者存储，等等，也就是说，基于业务服务器的可交互性，用户可以根据自己的实际使用需求或者对业务请求进行人为上的安全性判断以确定是否需要丢弃，所以在一定程度上可以提高对业务请求进行处理的准确性，这样可以满足用户在某些情况下的安全且具有差异化的业务请求。在具体实施过程中，例如可以采用以下两种方式中的任意一种将业务请求信息和风险等级信息发送给业务服务器，当然，本发明实施例中只是举例说明，并不限于以下两种方式，只要能够将业务请求信息和风险等级信息能够同时发送给业务服务器的方式均应在本发明的保护范围之内。第一种方式：将业务请求信息和风险等级信息分别发送给业务服务器。在第一种方式中，也就是说，对业务请求信息和风险等级信息并不做进一步的加工处理，而是直接将这两条信息单独发送给业务服务器，相当于是向同一业务服务器发送了两条不同的信息，在该业务服务器接收到这两条信息后，可以再对这两条信息进行进一步的处理。进一步地，业务服务器可以按照一定的顺序对接收到的业务请求信息和风险等级信息进行处理。例如可以在接收到某条业务请求信息以及该条业务请求信息对应的风险等级信息后，先处理该风险等级信息，紧接着处理该业务请求信息，此时风险等级信息和业务请求信息仍然保持对应。在这种处理顺序下，业务服务器可以先确定业务请求的风险等级，进而再根据业务请求的风险等级确定是否需要继续对业务请求信息进行处理，例如当确定风险等级为如表1中的风险等级5时，表明该业务请求是特别危险的请求，为了避免对业务服务器造成损坏，则可以直接删除业务请求信息，同时也可以减少业务服务器的无效操作，减少业务服务器的处理负荷，或者例如，当确定风险等级为如表1中的风险等级1时，表明业务请求是比较安全的，此时则可以再对业务请求进行处理，等等。也就是说，可以对不同等级的风险等级信息采取对应的有针对性的处理策略或者对不同风险等级的业务请求作进一步的分发，这样既可以提高业务服务器的安全性能，也能够提高业务服务器整体的工作效率。或者，因为在传输两条信息的时候，由于传输资源的限制，业务服务器可能会一前一后先后接收到风险等级信息和业务请求信息，那么业务服务器可以对先接收到的信息进行存储，待另一条信息接收到后，对两条信息进行一并处理。例如，业务服务器先接收到一条业务请求信息，但尚未接收到该条业务请求信息对应的风险等级信息，则业务服务器先对该业务请求信息进行存储，待接收到该条业务请求信息对应的风险等级信息后，再对该条业务请求和该条业务请求信息对应的风险等级信息进行处理。按照该种处理方式，可以保证对同一业务请求的业务请求信息和风险等级信息进行处理，避免由于其它业务请求对应的其它业务请求信息和其它风险等级信息再传输至该业务服务器后导致的处理顺序的混乱，也可以尽量按照先进先出的顺序对所接收到的信息有序地进行处理。第二种方式：将业务请求信息和风险等级信息合并为一条信息，再将该条合并信息发送给业务服务器。也就是说，可以先将业务请求信息和风险等级信息这两条信息合并为一条信息，再将该一条信息发送给业务服务器，相当于是发送给业务服务器的实际只有一条信息且该一条信息中包括业务请求信息和风险等级信息。采用第二何种方式中的发送方式，信息传输的数量减少了一半，所以可以在一定程度上减轻数据传输的压力，提高传输资源利用率。同时，还可以降低因为数据传输错误而导致重传的概率。此外，业务服务器在处理业务请求时只需调用一条信息，提高了业务服务器在处理业务请求时的整体效率。可选的，本发明实施例中将业务请求信息和风险等级信息合并为一条信息的方式，可以包括：先将风险等级信息添加到业务请求信息的HTTP消息头中以获得包括风险等级信息的业务请求信息，进而再将包括风险等级信息的业务请求信息确定为该一条信息。当采用HTTP协议进行通信而发起业务请求时，业务请求信息则为HTTP消息，请参见图4，HTTP消息在结构上一般可以分为消息头和消息体，其中消息头通常包括如请求方式、请求资源的主机和端口号、统一资源定位符(UniformResourceLocator，URL)、HTTP协议类型和缓存机制等等在内的内容，当业务服务器处理HTTP消息时，可以先读取HTTP消息头的内容并对HTTP消息头的内容进行响应。本发明实施例中，将风险等级信息添加到HTTP消息头中可以不影响业务服务器正常读取以及响应HTTP消息头的内容，例如在消息头的尾部写入表征风险信息的特征码，或者将表征风险等级信息的特征码写入URL的尾部，当业务服务器处理HTTP消息头时，首先提取HTTP消息头中表征风险等级信息的特征码，通过该特征码即可确定出该业务请求的风险等级。另外，可以保持HTTP消息的消息体保持不变，消息体中可以用于存储业务请求信息本身所对应的消息体的内容，这样在不改变数据结构的前提下将两条信息进行合并，并且业务服务器还可以能够快速地获得两条信息分别对应的内容。可选的，将业务请求信息和风险等级信息发送给业务服务器，包括：从与应用防火墙连接的至少一个业务服务器中确定满足预定条件的业务服务器；其中，满足预定条件的业务服务器为至少一个业务服务器中物理上距离业务请求的发送端最近的业务服务器，或，满足预定条件的服务器为至少一个业务服务器中当前传输流量最少的业务服务器；应用防火墙将业务请求信息和风险等级信息发送给满足预定条件的业务服务器。在实际中，配置用于接收业务请求信息和风险等级信息的业务服务器可以包括一个或多个，为了保证业务请求信息和风险等级信息处理的单一性，以避免多个业务服务器对同一业务请求信息和风险等级信息的重复处理而导致响应混乱，同时也是为了提高每个业务服务器的利用效率，在发送业务请求信息和风险等级信息之前，应用防火墙可以从与其连接的至少一个业务服务器中确定出一个满足预定条件的业务服务器，通过该业务服务器对该请求信息和该风险等级信息进行处理。可以将与应用防火墙连接的至少一个业务服务器中物理上距离业务请求的发送端最近的业务服务器，确定为接收该业务请求信息和该风险等级信息的业务服务器，这样可以缩短信息的传输时间，以便业务服务器能尽快对业务请求进行处理，提高处理效率；可替换的，还可以将至少一个业务服务器中当前传输流量最少的业务服务器，确定为接收该业务请求信息和该风险等级信息的业务服务器，这样可以尽量考虑业务服务器负载均衡，避免将业务请求传输到传输流量较大的业务服务器处而导致等待排队的发生，以尽量提高业务请求的处理效率，同时均衡各个业务服务器的处理负荷。如图5所示，图5为应用防火墙与其连接的多个业务服务器间的连接关系示意图，可见此时与应用防火墙相连的业务服务器个数为6，例如当前传输流量最少的业务服务器为业务服务器3，则确定业务服务器3为接收该业务请求信息和该风险等级信息的业务服务器。当然，还可以将与应用防火墙连接的至少一个业务服务器中随机选择一个作为接收该业务请求信息和该风险等级信息的业务服务器，或者可以综合其它因素从与应用防火墙连接的至少一个业务服务器中确定接收该业务请求信息和该风险等级信息的业务服务器，等等，对此本发明实施例不做具体限制。请参见图6，本发明实施例提供了一种处理业务请求的装置，该装置包括接收单元601、风险等级确定单元602和发送单元603，而且接收单元601、风险等级确定单元602和发送单元603可以通过硬件处理器来实现相关功能单元。其中：接收单元601，用于接收与业务请求对应的业务请求信息；风险等级确定单元602，用于根据业务请求信息，确定用于表征业务请求的风险等级的风险等级信息；发送单元603，用于将业务请求信息和风险等级信息发送给业务服务器，其中，业务服务器用于根据风险等级信息确定如何处理业务请求。可选的，发送单元603用于：将业务请求信息和风险等级信息分别发送给业务服务器；或，将业务请求信息和风险等级信息合并为一条信息，并将一条信息发送给业务服务器。可选的，发送单元603用于：将风险等级信息添加到业务请求信息的HTTP消息头中，获得包括风险等级信息的业务请求信息；确定包括风险等级信息的业务请求信息为一条信息。可选的，装置还包括风险规则库；风险等级确定单元602用于：解析业务请求信息，获得解析结果；将解析结果与风险规则库进行风险规则匹配，获得风险匹配结果；其中，风险规则库是基于应用防火墙所执行的更新操作而获得的更新后的风险规则库；根据风险匹配结果，确定风险等级信息。可选的，发送单元603用于：从与装置连接的至少一个业务服务器中确定满足预定条件的业务服务器；其中，满足预定条件的业务服务器为至少一个业务服务器中物理上距离业务请求的发送端最近的业务服务器，或，满足预定条件的服务器为至少一个业务服务器中当前传输流量最少的业务服务器；将业务请求信息和风险等级信息发送给满足预定条件的业务服务器。由于本发明实施例中的装置与上述处理业务请求的方法解决问题的原理相似，因此本发明实施例中装置的实施可以参见上述处理业务请求的方法的实施，在此不再赘述。本发明实施例中，当接收到包含业务请求的业务请求信息后，装置可以根据该业务请求信息对业务请求的风险进行分级，进而确定出该业务请求所对应的风险等级，例如可以划分为优质业务请求、安全业务请求，较危险业务请求，特别危险业务请求，等等，可见，本发明实施例对业务请求的风险等级划分更为详细，而非简单地将业务请求判定为是安全的或是危险的，相当于，通过更大力度和更细致的风险评估方式，使得对业务请求的风险评估更加的精细和客观，进而可以提高对业务请求的安全性进行评估的准确性。进一步地，装置将业务请求信息和该业务请求的风险等级信息一同发送给业务服务器，再由业务服务器根据风险等级信息对该业务请求进行处理，例如由业务服务器对业务请求进行丢弃、转发或者响应的处理，而无需由装置自身进行处理，这样可以避免由于装置对业务请求的安全性误判而导致的误丢或者导致一些安全问题的发生。此外，由于装置是将业务请求信息本身和风险等级信息一同发送给业务服务器，这样可以使得业务服务器能够根据不同的风险等级灵活、并行地对对应的业务请求进行处理，例如当确定风险等级为5时，表明业务请求是非常危险的，那么业务服务器可以直接丢弃该业务请求，或者，当确定风险等级为3时，表明业务请求存在一定的危险性，但是为了避免误丢，此时可以由用户再进行筛选以确定到底是否需要丢弃，等等，这样既可以保证风险的防范，也可以达到高效利用业务服务器资源的目的。以上所描述的装置实施例仅仅是示意性的，其中作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性的劳动的情况下，即可以理解并实施。通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到各实施方式可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件。基于这样的理解，上述技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在计算机可读存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行各个实施例或者实施例的某些部分所述的方法。最后应说明的是：以上实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。当前第1页1 2 3