安全策略强制系统和安全策略强制方法

摘要

本发明分散用于处理安全措施的负荷并且以适用于大规模系统的方式强制安全策略。在策略存储部中存储指示将针对从客户端向服务器发送的用户信息执行的安全措施的策略信息。在措施布置存储部中存储指示多个策略强制部中的每个策略强制部可以执行的安全措施的措施布置信息。基于策略信息和措施布置信息而从多个策略强制部中选择用于针对用户信息执行安全措施的至少一个策略强制部。至少一个策略强制部中的每个策略强制部针对用户信息执行安全措施。基于选择结果向在策略强制部之中的至少一个其它策略强制部或者向服务器输出用户信息。

权利要求

1.一种安全策略强制系统，包括：

多个策略强制部，被配置用于对从客户端向服务器发送的用户信息执行安全措施；

策略存储部，被配置用于存储策略信息，所述策略信息指示将对所述用户信息执行的所述安全措施；

措施布置存储部，被配置用于存储措施布置信息，所述措施布置信息指示在所述策略强制部中的每个策略强制部中可执行的所述安全措施；以及策略确定部，被配置用于基于所述策略信息和所述措施布置信息而在所述多个策略强制部之中选择对所述用户信息执行所述安全措施的策略强制部中的一个或者多个策略强制部，其中所述一个或者多个策略强制部中的每个策略强制部对所述用户信息执行所述安全措施，并且基于所述策略确定部的选择结果向所述一个或者多个策略强制部之中的其它策略强制部或者向所述服务器输出所述用户信息，并且其中所述多个策略强制部之中的、已经从所述客户端接收到所述用户信息的策略强制部向所述策略确定部发送针对所述一个或者多个策略强制部的选择请求，所述策略确定部响应于所述选择请求而向已经接收到所述用户信息的所述策略强制部发送对所有所述一个或者多个策略强制部的选择结果，并且所述一个或者多个策略强制部之中的、除了已经接收到所述用户信息的所述策略强制部之外的策略强制部不向所述策略确定部发送针对策略强制部的选择请求，并且基于所述选择结果向所述一个或者多个策略强制部之中的其它策略强制部或者向所述服务器输出所述用户信息。

2.根据权利要求1所述的安全策略强制系统，还包括负荷状态存储部，被配置用于存储指示策略强制部的负荷状态的负荷信息，其中所述策略确定部基于所述负荷信息而在能够执行与所述策略信息对应的所述安全措施的策略强制部之中选择具有最小负荷状态的策略强制部。

3.根据权利要求1或者2所述的安全策略强制系统，还包括顺序约束存储部，所述顺序约束存储部被配置用于存储顺序约束信息，所述顺序约束信息指示对多个所述安全措施的执行顺序的约束，其中所述策略确定部基于所述顺序约束信息来选择所述一个或者多个策略强制部，以使得所述安全措施根据所述约束而被执行。

4.根据权利要求1或者2所述的安全策略强制系统，其中

所述服务器包括被配置用于虚拟化硬件的虚拟机监视器，并且

使用由所述虚拟机监视器虚拟化的所述硬件来实现所述多个策略强制部中的一个或者多个策略强制部。

5.根据权利要求1或者2所述的安全策略强制系统，还包括网络状态存储部，被配置用于存储网络信息，所述网络信息指示在所述多个策略强制部之间的网络的状态，其中所述策略确定部基于所述网络状态而在能够执行与所述策略信息对应的所述安全措施的所述策略强制部之中选择用于高效传送所述用户信息的策略强制部。

6.一种安全策略强制方法，包括：

在策略存储部中存储策略信息，所述策略信息指示将对从客户端向服务器发送的用户信息执行的安全措施；

在措施布置存储部中存储措施布置信息，所述措施布置信息指示在多个策略强制部中的每个策略强制部中可执行的所述安全措施；

基于所述策略信息和所述措施布置信息而在所述多个策略强制部之中选择对所述用户信息执行所述安全措施的策略强制部中的一个或者多个策略强制部；以及所述一个或者多个策略强制部中的每个策略强制部对所述用户信息执行所述安全措施，并且基于选择结果向所述一个或者多个策略强制部之中的其它策略强制部或者向所述服务器输出所述用户信息，其中所述多个策略强制部之中的、已经从所述客户端接收到所述用户信息的策略强制部向策略确定部发送针对所述一个或者多个策略强制部的选择请求，所述策略确定部响应于所述选择请求而向已经接收到所述用户信息的所述策略强制部发送对所有所述一个或者多个策略强制部的选择结果，并且所述一个或者多个策略强制部之中的、除了已经接收到所述用户信息的所述策略强制部之外的策略强制部不向所述策略确定部发送针对策略强制部的选择请求，并且基于所述选择结果向所述一个或者多个策略强制部之中的其它策略强制部或者向所述服务器输出所述用户信息。

说明书

安全策略强制系统和安全策略强制方法

技术领域

[0001] 本发明涉及一种安全策略强制系统和安全策略强制方法。

背景技术

[0002] 近年来，称为云的服务提供已普及。云是如下模型，在该模型中，平台提供者向服务提供者提供用于构建服务的平台，并且服务提供者在平台上构建它自己的服务并且向用户提供服务。

[0003] 在这样的环境中，各服务提供者用实施具有安全功能的服务以便保护服务免遭信息泄露和攻击。然而，由于服务提供者独立实施安全功能，所以存在成本高的问题。另外，由于服务的功能和安全功能密切相关，所以存在难以更新安全功能的问题。

[0004] 为了解决这些问题，期望服务的平台具有安全功能而不是相应服务具有安全功能，并且如果服务提供者简单地设置安全策略，则由平台保护服务。出于该目的，已经提出了若干系统。

[0005] 例如，在专利文献1中公开的系统中，在客户端与服务器之间布置的网络设备监视从客户端发送的网络分组并且执行访问控制，由此实施安全措施。

[0006] 在专利文献2中公开的系统中，在客户端与服务器之间的路由器挂起通信并且向诸如防火墙或者防病毒的安全设备传送分组，由此实施安全措施。

[0007] 另外，一般安全措施包括用于执行分组过滤的防火墙、用于检测入侵的IDS(入侵检测系统)以及用于防止入侵的IPS(入侵防止系统)。

[0008] 专利文献1：专利公开JP-A-2008-141352

[0009] 专利文献2：专利公开JP-A-2007-336220

[0010] 然而，在上文说明的系统中，未假设大型环境并且在具体设备上施加负荷。因此，系统不能应用于大型系统。具体而言，在专利文献1中描述的系统中，一般防火墙和IDS或者IPS，网络流量集中于采取安全措施的设备上。在专利文献2中描述的系统中，虽然分散了采取安全措施的设备，但是网络的流量仍集中于调用(call)这些设备的设备(分配流量的设备)上，并且难以扩展安全措施处理的能力。

发明内容

[0011] 已经鉴于这样的境况而设计本发明，并且本发明的目的是分散安全措施的处理负荷并且强制执行将适用于大型系统的安全策略。

[0012] 根据本发明的一个方面的一种安全策略强制系统包括：多个策略强制部，被配置用于对从客户端向服务器发送的用户信息执行安全措施；策略存储部，被配置用于存储指示将对用户信息执行的安全措施的策略信息；措施布置存储部，被配置用于存储指示在策略强制部中的每个策略强制部中可执行的安全措施的措施布置信息；以及策略确定部，被配置用于基于策略信息和措施布置信息而在多个策略强制部之中选择对用户信息执行安全措施的一个或者多个策略强制部。一个或者多个策略强制部中的每个策略强制部对用户信息执行安全措施，并且基于策略确定部的选择结果向一个或者多个策略强制部之中的其它策略强制部或者向服务器输出用户信息。

[0013] 在本发明中，“部”不是简单地意味着物理装置而是包括由软件实现的“部”的功能。一个“部”或者设备的功能可以由两个或者更多物理装置或者设备实现，或者两个或者更多“部”或者设备的功能可以由一个物理装置或者设备实现。

[0014] 根据本发明，有可能分散安全措施的处理负荷并且强制执行将适用于大型系统的安全策略。

附图说明

[0015] 图1是示出安全策略强制系统的配置示例的图。

[0016] 图2是示出服务器的配置示例的图。

[0017] 图3是示出策略强制部的配置示例的图。

[0018] 图4是示出信息传送部之间的消息格式的示例的图。

[0019] 图5是示出当信息传送部调用措施实施部时使用的消息格式的示例的图。

[0020] 图6是示出在从措施实施部到信息传送部的响应中使用的消息格式的示例的图。

[0021] 图7是示出策略DB的示例的图。

[0022] 图8是示出措施布置DB的示例的图。

[0023] 图9是示出负荷状态DB的示例的图。

[0024] 图10是示出在从信息传送部到策略确定部的查询中使用的消息格式的示例的图。

[0025] 图11是示出在从策略确定部到信息传送部的响应中使用的消息格式的示例的图。

[0026] 图12是示出安全策略强制系统的操作的示例的序列图。

[0027] 图13是用于说明策略确定操作的示例的流程图。

[0028] 图14是用于说明策略确定操作的另一示例的流程图。

[0029] 图15是示出顺序约束DB的示例的图。

[0030] 图16是示出指示依赖关系的定向图的合并的示例的图。

[0031] 图17是示出在向第一策略强制部集中地通知策略强制部的顺序和策略强制部将实施的措施时使用的消息格式的示例的图。

[0032] 图18是示出安全策略强制系统的另一配置示例的图。

[0033] 图19是示出安全策略强制系统的又一配置示例的图。

具体实施方式

[0034] 下文参照附图说明本发明的实施例。

[0035] ＝＝第一实施例＝＝

[0036] 图1是示出根据第一实施例的安全策略强制系统的配置的图。安全策略强制系统10是在客户端12使用从服务器14提供的服务时执行与安全策略对应的安全措施的信息处理系统。与安全策略对应的安全措施的执行被称为安全策略的“强制”。在这一实施例中，也简单地将安全措施表示为“措施”。

[0037] 客户端12是用户使用的信息处理设备。客户端12经由安全策略强制系统10向服务器14发送信息(用户信息)，诸如用户的位置信息、博客的描述以及文档文件和程序文件。客户端12可以例如使用简单对象访问协议(SOAP)向策略强制系统10发送信息。客户端12是例如包括CPU和网络接口卡(NIC)的计算机。客户端12可以执行用于发送信息的应用程序。由于客户端12的配置是一般配置，所以省略该配置的具体说明。

[0038] 服务器14是提供例如博客服务和推荐服务的信息处理设备。服务器14经由安全策略强制系统10接收从客户端12发送的信息并且在服务器14的内部存储该信息。服务器14如图2中所示包括CPU30、存储器32和网络接口卡(NIC)34。用于提供服务的服务器OS/服务器应用40在服务器14上进行操作。由于服务器14的配置是一般配置，所以省略对该配置的具体说明。

[0039] 如图1中所示，安全策略强制系统10包括多个策略强制部20和策略确定部22。

[0040] 策略强制部20是在客户端12与服务器14之间中继信息并且将安全措施应用于将被中继的信息的信息处理设备。在这一实施例中，当有必要区分多个策略强制部20中的每个策略强制部时，向附图标记附加分支编号以这样的方式将策略强制部20表示为策略强制部20-1、策略强制部20-2、...和策略强制部20-N。

[0041] 策略确定部22是基于预先设置的安全策略以及从用户发送的信息来确定应当通过策略强制部20中的哪个策略强制部向服务器14发送信息的信息处理设备。

[0042] 图3是示出策略强制部20的配置示例的图。策略强制部20包括信息传送部50和多个措施实施部52。策略强制部20还包括CPU60和存储器62。例如，CPU60执行存储器62中存储的程序，由此可以实现信息传送部50和措施实施部52。

[0043] 信息传送部50在客户端12、其它策略强制部20和服务器14之间传送信息。当从客户端12或者另一策略强制部20的信息传送部50接收到信息时，信息传送部50向策略确定部22查询将实施的安全措施和信息的传送目的地。信息传送部50根据策略确定部22的指令调用措施实施部52。在措施实施部52中的措施实施完成之后，信息传送部50根据策略确定部
22的指令向其它策略强制部20或者服务器14传送信息。例如，可以使用SOAP作为用于到其它策略强制部20或者服务器14的信息的传送协议。SOAP是示例。只要可以传送信息，传送协议可以是其它协议。例如，可以使用进程间通信作为在信息传送部50调用措施实施部52时使用的协议。信息传送部50可以使用例如重写目的地IP地址而在TCP/IP层中执行信息的传送和调用措施实施部52。类似地，可以执行在以太网(注册商标)层中信息的传送和调用措施实施部52。

[0044] 例如，在图4中所示格式中执行在信息传送部50之间的信息交换。用户ID是可以唯一标识用户的标识符。服务ID是可以唯一标识服务的标识符。信息是从客户端发送的信息，例如位置信息或者博客的描述。在实施的措施项中设置针对从用户发送的信息而实施的措施。

[0045] 例如，当信息传送部50调用措施实施部52时使用图5中所示的格式。用户ID、服务ID和信息与图4中所示的用户ID、服务ID和信息相同。措施参数是为了执行措施而必需的参数。例如，在措施实施部52执行加密时设置加密密钥。在措施实施部52执行匿名化时设置匿名化指示符，诸如K匿名或者L多样性。

[0046] 措施实施部52从信息传送部50接收信息、将预先指定的安全措施处理应用于接收的信息并且向信息传送部50返回处理的信息。在这一实施例中，当有必要区分多个措施实施部52中的各个措施实施部52时，向附图标记附加分支编号以这样的方式将措施实施部52表示为措施实施部52-1、措施实施部52-2、...和措施实施部52-M。各个措施实施部52执行不同种类的措施处理。由策略强制部20实施的措施根据相应策略强制部20中布置的措施实施部52而不同；例如策略强制部20-1执行加密和防病毒，并且策略强制部20-2执行匿名化和日志记录。

[0047] 措施实施部52被配置为能够标识并入的安全措施处理。例如，措施实施部52可以被配置为具有与并入的安全措施处理相同的名称。例如，执行加密的措施实施部52具有名称“加密”。这一名称与在安全策略中描述的措施相同。因此，如果信息传送部50参考来自策略确定部22的通知，则信息传送部50可以唯一指定应当调用哪个措施实施部52。当期望对策略的措施和措施实施部52分配不同名称时，策略确定部22仅需具有用于将策略的措施的描述转换成措施实施部52的名称的数据库。在这一情况下，由于基于数据库转换在策略中描述的措施的名称，所以有可能指定实施措施的措施实施部52。

[0048] 例如，在措施实施部52实施措施并且向信息传送部50返回信息时使用图6中所示的格式。用户ID、服务ID、信息和实施的措施与图4和5中所示户ID、服务ID、信息和实施的措施相同。在措施结果项中记录措施实施部52是否成功实施安全措施。在措施实施部52成功地正常实施措施时设置“成功”。在措施实施部52由于某一原因而在措施中失败时设置“失败”。

[0049] 策略确定部22包括策略DB(策略存储部)，在该策略DB中为每个用户记录指示将实施的安全措施的安全策略(策略信息)。策略确定部22根据安全策略和信息传送目的地确定将实施的安全措施。在图7中示出策略确定部22保持的策略DB的示例。策略DB包括用户ID、服务ID和必要措施列表。作为示例，图7指示当用户A使用推荐服务时匿名化和向临时ID的转换是必需的，并且当用户A使用博客服务时防病毒是必需的。图7指示当用户B使用博客服务时防病毒和日志记录是必需的。在图7中所示示例中，使用诸如推荐服务这样的简单字符串作为服务ID。然而，仅需唯一地标识服务。例如，可以使用URL作为服务ID。策略DB可以包括用于措施的参数。例如，在必要措施列表中包括加密时，可以在必要措施列表中将用于加密的密钥与加密的指定一起设置。例如，作为策略DB，可以使用关系数据库。如果数据量小，则可以将策略DB实施为程序中的数组。

[0050] 此外，策略确定部22包括措施布置DB(措施布置存储部)，在该措施布置DB中记录指示相应策略强制部20保持哪些种类的措施实施部52的措施布置信息作为用于确定信息的传送目的地的信息。在图8中示出由策略确定部22保持的措施布置DB的示例。措施布置DB包括策略强制部20的ID(标识符)和在策略强制部20中布置的措施实施部52的列表(措施列表)。图8中所示示例指示例如在具有ID号1的策略强制部20-1中布置执行匿名化的措施实施部52。图8中所示示例指示例如在具有ID号2的策略强制部20-2中布置执行日志记录的措施实施部52-1和执行防病毒的措施实施部52-2。如同策略DB，可以例如将措施布置DB实施为关系数据库或者程序中的数组。

[0051] 另外，策略确定部22在内部包括负荷状态DB(负荷状态存储部)，在该负荷状态DB中记录指示策略强制部20的负荷状态的负荷信息。在图9中示出由策略确定部22保持的负荷状态DB的示例。负荷状态DB包括策略强制部20的ID和负荷。图9中所示示例指示具有ID号1的策略强制部20-1的负荷是80％。如同策略DB和措施布置DB，可以例如将负荷状态DB实施为关系数据库或者程序中的数组。

[0052] 在从策略强制部20的信息传送部50接收到查询时，除了将由查询源处的策略强制部20实施的措施和措施的参数之外，策略确定部22还向查询源处的策略强制部50通知接下来将向哪个策略强制部20传送信息。下文说明用于确定将实施的措施和信息传送目的地的算法。例如，图10中所示格式可以用于从策略强制部20的信息传送部50到策略确定部22的查询。用户ID、服务ID和实施的措施与图4和图5中所示的用户ID、服务ID和实施的措施相同。因此，省略用户ID、服务ID和实施的措施的说明。例如，图11中所示的格式可以用于从策略确定部22到策略强制部20的信息传送部50的答复。措施和措施的参数例如是加密和用于加密的密钥。在信息传送目的地中设置用于标识策略强制部20或者服务(服务器14)的ID。

[0053] 说明安全策略强制系统10的操作。如上文说明的那样，安全策略强制系统10包括多个策略强制部20。从客户端12发送的信息通过多个策略强制部20最终到达服务器14。当信息通过相应策略强制部20时对信息实施安全措施。参照图12的序列图具体说明安全策略强制系统10的操作的示例。

[0054] 首先，用户使用的客户端12向策略强制部20-1的信息传送部50发送信息(S01)。除了用户希望向服务器14发送的信息(位置信息、博客描述等)之外，待发送的信息还包括用户ID和用户希望使用的服务的标识符(服务ID)。

[0055] 在接收到信息时，信息传送部50向策略确定部22查询将实施的措施和接下来信息将被传送到的目的地(S02)。如图10中所示，该查询包括策略强制部ID、用户ID和服务ID。还向查询添加关于实施措施的信息。由于尚未实施措施，所以在实施的措施中示出“无”。

[0056] 策略确定部22基于用户ID和服务ID从策略DB中检索策略并且确定必要措施(S03)。策略确定部22使用措施布置DB来指定在其中布置了必要措施实施部52的策略强制部20。最后，策略确定部22例如使用图11中所示格式来向策略强制部20-1通知将实施的措施、措施的参数和在信息的传送目的地处的策略强制部20的ID或者服务ID。下文说明策略确定的具体操作。

[0057] 在从策略确定部22接收到将实施的措施和信息的传送目的地时，关于所指令的措施，信息传送部50按顺序调用措施实施部52并且使措施实施部52执行用于信息的措施处理(S04至S07)。

[0058] 例如，在策略确定部22指令调用措施实施部52-1和52-M时，信息传送部50首先调用措施实施部52-1并且向措施实施部52-1传递信息和用于实施措施的参数(S04)。如上文说明的那样，在信息传送部50调用措施实施部52时，可以使用图5中所示的格式。

[0059] 措施实施部52-1接收信息并且使用措施的参数来执行预先确定的措施算法以由此对信息执行安全措施处理并且向信息传送部50返回处理的信息(S05)。如图6中所示，措施实施部52向在调用源处的信息传送部50通知除了处理的信息之外的指示措施的处理是否成功的信息。

[0060] 如果措施实施部52-1在步骤S05中由于某一原因而在安全措施的处理中失败(如果图6中的措施结果项是“失败”)，则策略强制部20向客户端12通知错误并且结束处理。如果措施的处理在步骤S05中成功，则如在步骤S04中那样，信息传送部50调用措施实施部52-M(S06)。措施实施部52-M将措施应用于信息并且向信息传送部50返回信息(S07)。

[0061] 信息传送部50向策略确定部22指明的策略强制部20(更准确为策略强制部20的信息传送部50)传送信息(S08)。如果指明服务器14而不是策略强制部20，则信息传送部50向服务器14发送信息。

[0062] 如同前述的策略强制部20-1，接收到信息的下一策略强制部20-N向策略确定部22查询必要措施和传送目的地、调用措施实施部52以实施措施并且最终传送信息(S09和S10)。在图12中所示示例中，策略强制部20-N接收用于从策略确定部22向服务器14传送信息的指令并且向服务器14传送信息。

[0063] 最后，服务器14从策略强制部20-N接收信息并且在服务器14的内部存储信息(S11)。

[0064] 说明策略确定部22中的策略确定操作的细节。图13是示出策略确定操作的示例的流程图。首先，策略确定部22基于用户ID和服务ID在策略DB内搜索并且获取必要措施列表(S1301)。

[0065] 随后，策略确定部22使用指示查询源的策略强制部ID在措施布置DB内搜索并且指定在查询源处的策略强制部20中布置哪些种类的措施实施部52。策略确定部22确定在策略的必要措施列表中包括的并且被布置在查询源处的策略强制部20中的措施作为查询源处的策略强制部20将实施的措施(S1302)。在这一点，策略确定部22参考查询格式中的实施的措施项(图4)以从将实施的措施中排除已经实施的措施。

[0066] 随后，策略确定部22确定信息的传送目的地(下一策略强制部20或者服务器14)(S1303至S1305)。详细地说明相应步骤。

[0067] 在策略的措施列表中，策略确定部22从未对信息实施的并且在查询源处的策略强制部20不应实施的措施之中选择接下来将实施的一个措施(S1303)。选择措施的方法可以是在策略中写入的顺序或者可以随机。当不能选择措施、即由于在查询源处的策略强制部20实施措施而完成在策略中指明的所有措施的实施时，策略确定部22设置服务器14作为信息的传送目的地并且结束处理。

[0068] 策略确定部22从策略布置DB中检索其中布置了在S1303中选择的措施的策略强制部20(步骤S1304)。

[0069] 在仅一个策略强制部52中布置在步骤S1303中选择的措施时，策略确定部22确定策略强制部52作为传送目的地。在多个策略强制部52中布置在步骤S1303中选择的措施时，策略确定部22参考负荷状态DB确定具有最小负荷的策略强制部52作为接下来信息将被传送到的策略强制部52(S1305)。

[0070] 如上文说明的那样，根据这一实施例的安全策略强制系统10被配置为分散和强制安全策略。因此，有可能将安全策略强制系统10应用于大型系统。

[0071] 在上文说明中提供一个服务器14。然而，可以提供多个服务器14。在这一情况下，在措施布置DB中，不仅管理措施实施部52的布置状态而且管理指示在哪个服务器14中布置哪个服务的信息。类似地，在负荷状态DB中管理指示服务器的负荷的信息。在选择服务器14时，策略确定部22在其中布置了服务的服务器14之中选择具有最小负荷的服务器14并且向信息传送部50通知服务器14作为信息的传送目的地。因而，有可能不仅执行安全策略强制的负荷分散而且执行服务器的负荷分散。

[0072] 在上文说明书中，在策略的必要措施列表中包括的并且在查询源处的策略强制部20中布置的措施被确定为在请求源处的策略强制部20将实施的措施。也就是说，策略确定部22指令一次实施多个措施。然而，策略确定部22可以指令一个措施的实施而不是多个措施的实施。当由相同策略强制部20连续执行其它措施的处理时，策略确定部22仅需指明相同策略强制部20作为传送目的地。当策略强制部20的传送目的地是策略强制部20本身时，策略强制部20仅需执行措施而不执行信息传送。一个措施的实施是示例。可以指令实施两个或者三个措施。

[0073] 例如，由于实施多个措施需要时间，所以可能的是策略强制部20的负荷状态在该时间期间改变并且不能高效使用计算机资源。由于一个措施的实施时间比多个措施的实施更短，所以在对策略确定部22的下一查询之前的时间减少。因此，有可能更灵活应对策略强制部20的负荷波动这样的效果。这一操作具有的缺点为，从策略强制部20到策略确定部22的策略确定请求的次数和在策略强制部20之间的数据传送的次数增加。然而，可以在高速网络环境中忽略该缺点。

[0074] 在该说明中，策略强制部20一次查询策略强制部20将实施的措施和传送目的地。然而，策略强制部20可以单独查询措施和传送目的地。具体而言，在接收到信息时，策略强制部20向策略确定部22查询将实施的措施并且实施措施。在实施措施之后，策略强制部20向策略确定部22查询信息的传送目的地并且根据策略确定部22的指令传送信息。在这一操作中，由于策略强制部20紧接在传送信息之前查询传送目的地，所以存在有可能根据最新负荷状态确定传送目的地的效果。

[0075] ＝＝第二实施例＝＝

[0076] 说明其中考虑安全措施实施顺序的第二实施例。安全措施有时在措施的实施顺序上有限制。例如，在考虑加密和防病毒时，由于防病毒检查是否在信息中包括病毒的模式，所以防病毒不可以应用于加密的信息。因此，必须比加密更早实施防病毒。因此，在图13中所示的策略确定部22的操作中，由于不能指明用于实施措施的顺序，所以可能的是不能根据顺序实施措施。

[0077] 因此，策略确定部22可以在内部包括顺序约束DB(顺序约束存储部)，在该顺序约束DB中记录指示关于措施执行顺序的约束的顺序约束信息。具体而言，仅需针对在策略强制部20中布置的所有措施指定优先级。策略确定部22仅需在图13中所示的处理中的步骤S1302和S1303中根据优先级选择措施。

[0078] 例如，假设在策略强制部20中布置了措施，即日志记录、防病毒和加密。假设以下两个要求(1)和(2)。(1)期望在日志中记录在由防病毒删除病毒之前的信息。(2)如果信息被加密，则不能执行防病毒的处理。在这一情况下，策略确定部22仅需在内部保持优先级“日志记录→防病毒→加密”。

[0079] 例如，将图13中的步骤S1302至S1305中的处理改变成图14中所示处理，从而使得基于优先级来确定传送信息的策略强制部20。

[0080] 策略确定部22查询源处的策略强制部20可以实施的措施之中具有最高优先级的措施(S1401)添加到查询源处的策略强制部20将要实施的措施的列表。

[0081] 随后，策略确定部22选择在尚未针对信息实施的并且在列表中未包括的措施之中具有最高优先级的措施(S1402)。

[0082] 策略确定部22参考措施布置DB确定在查询源处的策略强制部20是否可以实施选择的措施(S1403)。

[0083] 在查询源处的策略强制部20可以实施选择的措施(在S1403中为是)时，策略确定部22向在查询源处的策略强制部20将实施的措施列表添加所选择的措施(S1404)并且返回到步骤S1402。

[0084] 当查询源处的策略实施部20不能实施所选择的措施(在S1403中为负)时，策略确定部22完成在查询源处的策略强制部20将实施的措施列表的创建。策略确定部22将在可以实施选择的措施的策略强制部20之中具有最小负荷的策略强制部20确定为信息的传送目的的(S1405)。

[0085] 由于以这一方式为措施提供优先级，所以有可能确切地实施具有依赖关系的措施。

[0086] ＝＝第三实施例＝＝

[0087] 说明其中考虑安全措施实施顺序的第三实施例。在第二实施例中，存储所有措施的优先级。然而，在措施数目增加时，有时难以指明优先级。

[0088] 因此，策略确定部22可以包括顺序约束DB，在该顺序约束DB中记录图15中所示的指示部分顺序约束的顺序约束信息。在顺序约束DB中，记录指示关于措施顺序的约束的信息，诸如“必须比措施B更早执行措施A”(在图中示出为A→B)。在图15中所示的示例中，指示必须比向临时ID的转换的处理更早实施日志记录并且必须比加密更早实施防病毒。

[0089] 在这一实施例中，策略确定部22重新布置措施顺序以满足顺序约束并且选择接下来将实施的措施。具体而言，策略确定部22将关于措施的顺序约束视为定向图、合并代表相应顺序约束的定向图并且创建指示在措施之间的依赖关系的定向图。策略确定部22从指示依赖关系的定向图所指示的最高位序的措施开始按顺序选择措施。

[0090] 可以通过将共同措施合并成一个措施来执行图的合并。例如，在存在措施B→措施C的图和措施A→措施C的图时，可以如图16A中所示合并这些图。在存在措施A→措施B的图和措施A→措施C的图时，可以如图16B中所示合并这些图。另外，在存在措施B→措施A的图和措施C→措施A的图时，可以如图16C中所示合并这些图。

[0091] 策略确定部22从合并的定向图的最高位序的措施开始按顺序选择措施并且重新布置策略的必要措施列表。例如，仅需使用拓扑排序来确定选择的顺序。由于拓扑排序是一般技术，所以省略拓扑排序的详细说明。

[0092] 在各图不能被合并成一个图时，例如在各图被合并成措施A→措施B→措施C和措施D→措施E→措施F的两个图时，相同措施未出现在相应图中并且不存在措施的依赖关系，仅需为每个图确定措施顺序。

[0093] 如上文说明的那样根据以这一方式确定的措施顺序实施措施。

[0094] 当定向图中存在闭合回路，例如“A→B→C→A”时，依赖关系循环。无论实施措施的顺序如何都不能满足约束。因此，在这一情况下，策略确定部22向管理员或者客户端12通知错误。

[0095] 在这样的配置中，平台管理员无需描述在所有措施之间的依赖关系。因此有可能简化管理。

[0096] 当存在措施之间有依赖关系的两个或者更多图时，策略确定部22可以被配置为提取如下策略强制部20，在该策略强制部中布置可以接下来在图中实施的措施中的任一个措施。策略确定部22可以指令向在策略强制部20之中具有最小负荷的策略强制部20传送信息。

[0097] 例如，当存在措施A→措施B→措施C和措施D→措施E→措施F的两个图，并且通过在查询源处的策略强制部20由策略强制部已经实施或者实施的措施A和措施D时，可以由下一策略强制部20实施措施B和措施E。例如，在这一情况下假设存在两个其中布置了措施B的策略强制部20，并且该策略强制部20的负荷分别是50％和60％，并且存在两个其中布置了措施E的策略强制部20，并且该策略强制部20的负荷分别是10％和90％。在这一情况下，策略确定部22指令向具有最小负荷(10％)的策略强制部20进行传送。

[0098] 在即使存在依赖关系的一个图、例如图16C中所示的图中存在措施B和措施C仍然可以实施多个措施时，可以选择可以实施措施中的任一个措施的策略强制部20之中具有最小负荷的策略强制部20作为信息的传送目的地。

[0099] 即使如在第一实施例中那样无顺序约束，仍然可以在相同过程中选择信息的传送目的地。

[0100] 根据这样的操作，向具有最小负荷的策略强制部20传送信息。因此有可能高效使用计算机资源。

[0101] ＝＝第四实施例＝＝

[0102] 说明其中考虑向策略确定部22查询的次数的第四实施例。在上文说明的实施例中，相应策略强制部20向策略确定部22发送查询。因此，当信息发送次数根据用户数目增加而增加时或者当使用大量策略强制部20时，对策略确定部22查询的次数增加，这可能是瓶颈。

[0103] 因此，为了防止对策略确定部22的查询增加，策略确定部22可以响应于第一策略强制部20的查询来集中地不仅向第一策略强制部20执行通知而且向在第一策略强制部20之后的策略强制部20执行通知。因而，有可能减少查询次数。

[0104] 具体说明操作。策略确定部22重复图13中的步骤S1303至S1305并且确定在哪个策略强制部20中实施所有措施。策略确定部22向第一策略强制部20集中地通知策略强制部20的顺序和相应策略强制部20实施的措施。

[0105] 图17示出在集中地通知顺序和措施时的格式的示例。图17中所示示例指示在具有ID“2”的策略强制部20-2中匿名信息并且在具有ID“3”的策略强制部20-3中执行防病毒处理。

[0106] 相应的策略强制部20将收集的通知与信息一起向下一策略强制部20传送。策略强制部20基于从前一策略强制部20接收的通知来调用指明的措施并且向下一策略强制部20或者服务器14传送信息，而不是向策略确定部22查询措施。

[0107] 例如当策略强制部20-1首先从客户端12接收到信息并且图17中所示的通知是从策略确定部22发送的时，策略强制部20-1参考策略强制部20-1的ID字段来参考措施项。在这一示例的情况下，由于在措施中示出“无”，所以策略强制部20-1向下一策略强制部20、即具有ID号2的策略强制部20-2传送信息。

[0108] 策略强制部20-2参考策略强制部20-2的ID字段来参考措施项并且实施措施。在这一示例的情况下实施加密。接下来，策略强制部20-2向下一策略强制部20、在这一示例中为具有ID号3的策略强制部20-3传送信息。

[0109] 策略强制部20-3参考策略强制部20-3的ID的措施项来执行防病毒处理。由于图17中所示通知内容是最新的通知内容，所以策略强制部20-3向服务器14传送信息。

[0110] 由于以这一方式集中地执行通知，所以有可能减少对策略确定部22查询的次数。

[0111] 策略强制部20可以高速缓存策略确定部22的通知持续固定时段，而不是向第一策略强制部20集中地通知将由策略强制部20实施的措施以由此减少查询的次数。

[0112] 在上文说明书中，每当从策略强制部20接收到查询时，从策略确定部22经由信息传送部50向措施实施部52传递用于措施的参数。当参数的大小为小时无问题出现。然而在参数的大小为大时，参数消耗网络频带。因此可能出现性能下降。因此向措施实施部52预先通知措施参数。当策略确定部22对来自策略强制部20的查询做出响应时，可以省略措施参数的通知。

[0113] ＝＝第五实施例＝＝

[0114] 说明其中考虑措施实施部52的动态布置的第五实施例。在上文说明的实施例中，在策略强制部20中预先布置措施实施部52。然而，可以根据负荷状态执行措施实施部52的布置和删除。在该情况下，仅需更新措施布置DB。

[0115] 例如，在具有小负荷的策略强制部20-4中布置执行措施a的措施实施部52时，对图8中所示的措施布置DB添加行(4，措施a)。在根据策略实施“措施a”时，向具有ID“4”的策略强制部20-4传送信息，并且实施“措施a”。

[0116] 以这一方式在具有低负荷的策略强制部20中布置措施实施部52，有可能分散负荷。在上文描述的示例中，依次重新布置措施实施部52以分散负荷。然而，可以布置措施实施部52以便增加策略强制部20可以实施的措施。

[0117] 在执行措施实施部52的布置时，可以考虑网络的状态来确定布置目的地。具体而言，策略确定部22包括指示用于在策略强制部20之中传送信息的时间的传送时间数据库(传送时间DB)。策略确定部22确定将在哪个策略强制部20中布置某一措施A以使传送时间最少。

[0118] 例如，假设用户向策略强制部20-1发送信息。例如，假设从策略强制部20-1到策略强制部20-2的信息传送时间是一秒，从策略强制部20-2到服务器14的信息传送时间是一秒，从策略强制部20-1到策略强制部20-3的信息传送时间是两秒，从策略强制部20-3到服务器14的信息传送时间是两秒。

[0119] 当策略强制部20-2中布置实施措施A的措施实施部52时，信息传送需要一秒+一秒、即总计两秒。当策略强制部20-3中布置措施实施部52时，信息传送需要两秒+两秒、即总计四秒。因此，策略确定部22确定仅需在策略强制部20-2中布置措施实施部52。

[0120] 在上文说明中，使用在策略强制部20之间的信息传送时间作为指示网络状态的信息。然而，指示网络状态的信息不限于此。例如可以使用诸如网络的速度或者频带的使用率的信息作为指示网络状态的信息。

[0121] 可以考虑网络的状态和策略强制部20的负荷二者来确定措施实施部52的布置目的地。具体而言，仅需将即将布置的措施实施部52在策略强制部20中处理信息的时间添加至信息传送时间。仅需在其中总时间最短的策略强制部20中布置措施实施部52。

[0122] 例如，考虑布置当负荷是0％时占用一秒的措施。在上述示例中，当假设策略强制部20-2具有80％的负荷并且策略强制部20-3具有50％的负荷时，策略强制部20-2和策略强制部20-3分别需要五秒和两秒作为用于措施的处理时间。因此，如果与路径的传送时间相加，则在策略强制部20-2中布置措施实施部52时，处理时间是一秒+一秒+五秒、即总计七秒，并且在策略强制部20-3中布置措施实施部52时，处理时间是两秒+两秒+两秒、即总计六秒。因此，策略确定部22确定仅需在策略强制部20-3中布置措施实施部52。

[0123] 当有多个用户时或者当有多个服务器时，仅需计算关于用户与服务器的所有组合的时间。仅需在其中总时间最短的策略强制部20中布置措施实施部52。

[0124] 与上文相反，当期望删除措施实施部52时，仅需删除在其中总时间长的路径中布置的措施实施部52。

[0125] ＝＝第六实施例＝＝

[0126] 说明其中考虑虚拟机的第六实施例。省略关于与第一实施例中的部件相同的部件的说明。

[0127] 图18是示出根据这一实施例的安全策略强制系统的配置的图。如图18中所示，安全策略强制系统与第一实施例不同在于，第一实施例中的服务器14仅包括提供服务的服务器OS/服务器应用40，而在该实施例中的服务器110包括虚拟机监视器(VMM)120、虚拟策略强制部122和服务器OS/服务器应用124。

[0128] VMM120是如下程序，该程序可以虚拟化诸如CPU130和存储器132的硬件、然后使多个OS操作。由于VMM120是一般技术，所以省略VMM120的详细说明。例如可以使用VMWare(注册商标)和Xen(注册商标)作为VMM120。

[0129] 如同第一实施例中的策略强制部20，虚拟策略强制部122执行安全措施的实施。第一实施例中的策略强制部20包括物理上独立的计算机。然而，在该实施例中的虚拟策略强制部122的不同在于虚拟策略强制部122在由VMM120虚拟化的计算机上操作。

[0130] 如同第一实施例中的服务器14，服务器OS/服务器应用124提供服务。服务器OS/服务器应用124与第一实施例不同在于服务器OS/服务器应用124在由VMM120虚拟化的计算机上操作。

[0131] 说明这一实施例中的整个操作。整个操作与第一实施例中的整个操作基本上相同。客户端12向由服务器110-1提供的虚拟策略强制部122发送信息。如第一实施例中那样，虚拟策略强制部122向策略确定部22查询将实施的措施和传送目的地。在实施措施之后，虚拟策略强制部122向服务器OS/服务器应用124发送信息。最后，服务器OS/服务器应用124在内部存储信息。

[0132] 在这一实施例中，虚拟策略强制部122和服务器OS/服务器应用124共享相同CPU和相同存储器。因此，在服务器OS/服务器124长时间不使用CPU和存储器时，虚拟策略强制部122使用空闲时间。因此有可能提高CPU和存储器的使用效率。

[0133] ＝＝第七实施例＝＝

[0134] 说明其中考虑包括虚拟机的混合配置的第七实施例。图19是示出根据这一实施例的安全策略强制系统的配置的图。如图19中所示，作为这一实施例的特征，安全策略强制系统包括在第一实施例中说明的策略强制部20和在第六实施例中说明的虚拟策略强制部122二者。

[0135] 策略强制部20基本上执行与第一实施例中的操作相同的操作。然而这一实施例与第一实施例的不同在于，在第一实施例中向策略强制部20或者服务器14发送信息，而在这一实施例中向虚拟策略强制部122或者服务器OS/服务器应用124发送信息。

[0136] 策略强制部20和虚拟策略强制部122的操作与第一和第六实施例中的操作相同。因此省略操作的说明。

[0137] 在这一实施例中，根据策略强制部20和服务器110的负荷布置措施实施部52，并且使用具有小负荷的策略强制部20的措施实施部52和服务器110，由此有可能更高效使用计算机资源。

[0138] 实施例旨在于有助于理解本发明并且不限制性地解释本发明。可以改变或者改进本发明而不脱离本发明的精神。本发明包括本发明的等效物。

[0139] 例如在上文描述的实施例中，策略强制部20中的每个策略强制部包括多个措施实施部52。然而，策略强制部20中的每个策略强制部可以包括仅一个措施实施部52。在这一情况下，策略确定部22仅需向策略强制部52发送信息传送目的地。这是因为由于策略强制部20包括仅一个措施实施部52，所以不言而喻，策略强制部20调用措施实施部52并且可以省略指示将实施的措施的信息。

[0140] 利用这样的配置，有可能减少用于从策略确定部22到策略强制部20的响应的消息大小。由于策略强制部20包括仅一个措施实施部52，所以措施实施部52可以在策略强制部20等待来自策略确定部22的关于传送目的地的响应之时执行措施。也就是说，由于可以并行执行图12中的步骤S02和S04，所以更高速操作是可能的。

[0141] 例如在上文说明的实施例中，信息传送部50和措施实施部52在相同计算机上操作。然而信息传送部50和措施实施部52可以在不同计算机上操作。在该情况下，信息传送部50仅需通过网络调用措施实施部52。

[0142] 本申请要求基于于2011年1月25日提交的日本专利申请号2011-013392的优先权，其全部公开内容被结合于此。

[0143] 上文参照实施例说明本发明。然而本发明不限于实施例。可以在本发明的范围内对本发明的配置和细节进行本领域技术人员可理解的各种修改。

[0144] 可以如以下备注所指示的那样描述实施例的部分或者全部。然而本发明不限于以下描述。

[0145] (备注1)一种安全策略强制系统，包括：多个策略强制部，被配置为对从客户端向服务器发送的用户信息执行安全措施；策略存储部，被配置用于存储指示将对所述用户信息执行的所述安全措施的策略信息；措施布置存储部，被配置用于存储指示在所述策略强制部中的每个策略强制部中可执行的所述安全措施的措施布置信息；以及策略确定部，被配置用于基于所述策略信息和所述措施布置信息而在所述多个策略强制部之中选择对所述用户信息执行所述安全措施的所述策略强制部中的一个或者多个策略强制部，其中所述一个或者多个策略强制部中的每个策略强制部对所述用户信息执行所述安全措施并且基于所述策略确定部的选择结果向在所述一个或者多个策略强制部之中的其它策略强制部或者向所述服务器输出所述用户信息。

[0146] (备注2)根据备注1所述的安全策略强制系统，进一步包括：负荷状态存储部，被配置用于存储指示所述策略强制部的负荷状态的负荷信息，其中所述策略确定部基于所述负荷信息选择可以执行与所述策略信息对应的所述安全措施的所述策略强制部之中具有最小负荷状态的策略强制部。

[0147] (备注3)根据备注1或者2所述的安全策略强制系统，进一步包括：顺序约束存储部，被配置用于存储指示对多个所述安全措施的执行顺序的约束的顺序约束信息，其中所述策略确定部基于所述顺序约束信息来选择所述一个或者多个策略强制部，从而根据所述约束执行所述安全措施。

[0148] (备注4)根据备注1至3中的任一备注所述的安全策略强制系统，其中所述服务器包括被配置用于虚拟化硬件的虚拟机监视器，并且使用由所述虚拟机监视器虚拟化的所述硬件来实现所述多个策略强制部中的一个或者多个策略强制部。

[0149] (备注5)根据备注1至4中的任一备注所述的安全策略强制系统，其中在所述多个策略强制部之中的、已经从所述客户端接收到所述用户信息的所述策略强制部向所述策略确定部发送针对所述一个或者多个策略强制部的选择请求，所述策略确定部响应于所述选择请求而向已经接收到所述用户信息的所述策略强制部发送对所有所述一个或者多个策略强制部的选择结果，并且在所述一个或者多个策略强制部之中的、除了已经接收到所述用户信息的所述策略强制部之外的所述策略强制部不向所述策略确定部发送针对所述策略强制部的所述选择请求，并且基于所述选择结果向在所述一个或者多个策略强制部之中的其它策略强制部或者向所述服务器发送所述用户信息。

[0150] (备注6)根据备注1至备注5中的任一备注所述的安全策略强制系统，进一步包括：网络状态存储部，被配置用于存储指示在所述多个策略强制部之间的网络的状态的网络信息，其中所述策略确定部基于所述网络状态而在能够执行与所述策略信息对应的所述安全措施的所述策略强制部之中选择高效用于传送所述用户信息的所述策略强制部。

[0151] (备注7)一种安全策略强制方法，包括：在策略存储部中存储指示将对从客户端向服务器发送的用户信息执行的安全措施的策略信息；在措施布置存储部中存储指示在多个策略强制部中的每个策略强制部中可执行的所述安全措施的措施布置信息；基于所述策略信息和所述措施布置信息而在所述多个策略强制部之中选择对所述用户信息执行所述安全措施的所述策略强制部中的一个或者多个策略强制部；并且所述一个或者多个策略强制部中的每个策略强制部对所述用户信息执行所述安全措施并且基于选择结果向在所述一个或者多个策略强制部之中的其它策略强制部或者向所述服务器输出所述用户信息。

[0152] (备注8)一种用于使计算机实现以下功能的程序，所述功能基于指示将对从客户端向服务器发送的用户信息执行的安全措施的策略信息和指示在多个策略强制部中的每个策略强制部中可执行的所述安全措施的措施布置信息而在所述多个策略强制部之中选择对所述用户信息执行所述安全措施的所述策略强制部中的一个或者多个策略强制部。

[0153] 10  安全策略强制系统

[0154] 12  客户端

[0155] 14  服务器

[0156] 20  策略强制部

[0157] 22  策略确定部