一个基本的Web服务租借者对服务是有要求的,它要求服务可以通过多种多样的中间环节被传播,这可能是通过不同公司的不同服务范围服务器安全策略。
因此,从安全的角度来看,对一个有多种多样的中间环节(传播)的信任不信任,是从一个基于客户端/服务器(C/S)范例的安全模型,来移动到一个Web服务体系架构。令很多人惊讶的是,事实上像安全套接字层(SSL)、Kerberos协议(基于私钥体系)这样的传统传输水平级安全协议,解释信息在每一个终点,这样就会在不恰当的时机暴露信息。如果所有的中间环节都危险的话,那么所有的信息是危险的。Web服务的第二个方面是发出的请求是机器到机器的,并且必须全部都是自动完成的,在为多样的中间节点发挥最大效率时没有人为干涉。
就像一个典型的特定规定的例子,让它来检查一个购买定单的请求。这个请求首先会来到特定的部门,这需要去核实顾客的信用。如果这家公司已经将信用检查(这项工作)做了外包,这里有几家公司有这项业务,这样请求就会进入其他的公司。这是确定在PO中的信息,从第二家公司来时,可以被屏蔽,并且确定这个是第二家公司必需要的信息。传统的模式不具有这样支持这种微小划分的保护功能的尺度。然而,这种类型的尺度是需要被像WS安全和被OASIS指定的SAML的比较新的安全范例支持的。使用这些范例单独的部分或者完全的信息可以从中间过程处被保护。
另外,这些所有的结果不得不被其上标注的,有关效率的自动策略来设置。另一方面,产品做那些必需的自动策略处理并不是能用得上的,尽管规格说明已经有所发展。因此,贾以时日策略处理将会被习惯应用处理。
就像请求移动通过服务公司的不同部门,像定单执行(部门)、制造和运输(部门),每一个(部门)应该有数字签名或信息中相关的部分,这样下一个部门就会知道这个请求在上一个部门中被执行的满意度。这也服务于订单的一览无余的记录中。譬如,除非顾客已经通过了信用检查,产品是合格的或者已经被生产出来,等等经过地这样的步骤,否则运输部门是不会将产品作发货的。确认无误的数字签名是作出这些令人满意先决条件的重要证明。
每一家公司都有他自己特定的工作流要求,这样每一个安全策略必须是经过个别地设计。然而,除了最简单的特定情节,所有的都包括以多种多样的中间环节和没有争议的签名作出的细小的保护这样的需求是需要通过可靠的先决条件和不同实体与最初需求者的鉴定,就像需求通过了一系列的中间环节。
关于安全过程的另一个重要方面是防护水平应该和被保护的资源的价值相匹配。安全的成本会是非常多样的(成本),从几百到数百万美金不等。这样看来,为一个不具有很高价值的资源作与它不相匹配的很高的安全防护级别花费是很不必要的开支,同样,为一个具有相当价值的资源作太低级别的安全防护评估也是很不充分的。所以,作很妥帖的风险管理评估对于做安全策略是一项很重要的必备条件。