业务的安全需求可能包括用户信息的机密性、完整性、业务本身的可用性等方面。NGN中不同类型的业务有着不同的安全需求，如会话类业务的主要安全需求是可用性，消息类业务的主要安全需求是完整性。同一类型的业务其安全需求应该也是可以根据业务场景定制的，如普通两方呼叫要求即使在网络中出现入侵的情况下也应保证呼叫的正确路由，并确保语音流的服务质量。而如果用户要求呼叫需被保密，则还需保证信令消息的机密性和语音流的机密性，需要对信令和语音流进行加密处理。不同业务的安全需求是安全特性的组合。利用建模语言，业务所需要的安全特性可以抽象成为安全感知的类来表示。这些类中的功能可以使用安全应用接口提供的安全能力实现，而业务的安全需求则表示为类的组合。为了清晰表达业务的安全需求，并便于业务安全需求的实现，本文将业务的安全需求抽象为细粒度的安全功能类，每个安全功能类表达了业务对其各个组件(如信令、媒体、业务功能等)的不同安全特性(如机密性、完整性、认证等)的需求。
下面以基于SIP的两方会话为例说明如何使用UMLsec描述业务安全需求。假定两方呼叫发生在同一SIPProxy辖域的两个用户之间，要求保证用户UA与SIPProxy之间的信令的完整性，不能被非法入侵者篡改。该场景的用例图和部署图分别如图2、图3所示。
图2 信令完整性用例图
图3 信令完整性保护部署图
图3中的UA代表UserA或UserB的UA，因为两个UA的信令交互需要通过Proxy，且其安全需求是一致的，故在图中只表现出一方。UA和Proxy均是基于通用计算平台的节点，其访问控制需要受到保护，故对其标记上定型《guardedaccess》。UA中除处理信令外，还需处理媒体流的编解码与控制，这个用例中只涉及信令的安全性，故在UA中只关注进行信令控制的组件。UA与Proxy之间的通信基于IP承载，根据表1定义的威胁函数：ThreatA(IP Carrier)={delete，read，insert}，信令的完整性在攻击下可能遭到破坏，需要采用相应的安全机制对信令交互加以保护。
Sender类和Receiver类是通过对通信安全功能的抽象而得出的两个类。这两个类具备保证发送方和接收方之间消息传送的完整性的安全能力。通过在UA的信令控制功能和Proxy的呼叫控制功能中聚合这两个类，可以在高层的需求层面上满足UA和Proxy通信的信令完整性需求。
AccessGuard类是用于隔离对保护对象的访问的类，通过在被保护对象上标识{guard=AccessGuard}标记，所有的对保护对象的访问请求需先提交给AccessGuard类，AccessGuard类根据具体的访问控制机制和访问控制策略进行访问权限的判定后，访问请求才能在被保护对象上执行。
Sender类和Receiver类可以针对业务对安全需求的不同控制粒度进一步细化，通过对send()方法的重载加以实现。如在调用send()方法时可以使用QoP[5，7](QualityofProtection)参数说明业务对安全功能的保护级别的需求。QoP体现了处理安全问题的开销与安全保护需求之间的动态平衡。某一级别的QoP可以对应于某一具体安全机制中所采用的加密算法强度、密钥长度、认证机制强度等。但目前QoP的定义还依赖于具体的安全机制，且具有一定的随意性，没有一个客观的标准。
在更细的粒度上，用户可以在send()方法中指定具体安全机制的相关参数，对所使用的安全机制进行更精确的控制。
图5是对通信机密性进行保护的安全能力抽象类的类图。其send()方法应能保证消息的加密传输。Receiver类的receive()方法用于接收并解密消息。同完整性保护一样，更加细致和更加可控的机密性保护可通过对send()和receive()方法的重载实现。
除了图4和图5中列举的用于保护通信完整性和机密性以及实体访问控制的安全能力抽象类外，还可以根据业务的实际安全需求抽象更多的安全能力抽象类。每个类实现某一特定的安全功能，如可以在多媒体会议中定义群密钥管理功能抽象类，用于满足群密钥生成、分发与认证的功能。
图4 安全功能抽象类图示例
图5 消息机密性安全功能类
二、业务安全的实现机制
基于上述分析，可以将NGN业务的安全需求从安全特性上加以划分并进行抽象，形成一系列细粒度的安全功能抽象类。通过对每一个安全功能抽象类的实现可以满足业务的安全需求。文献[8]提出了一种基于模型驱动的细粒度的访问控制框架AC-PIM，将一个统一的高层的访问控制模型(AC-PIM)映射到多种具体的访问控制机制中，如OASIS的SAML(SecurityAssertionMarkupLanguage)和XACML(eXtensible Access Control Markup Language)，OMG的RAD(Resource Access Decision Facility)以及Java Authentication and Authorization中定义的Java访问控制模型。AC-PIM提供了一个实现图4中的AccessGuard抽象类的途径。
下面说明如何利用GSS-API实现保证通信完整性的安全能力抽象类，通过状态图说明保证通信完整性的Sender类的send()方法及Receiver类的receive()方法的GSS-API实现。本文中给出的是一个示意性的说明，忽略了一些错误处理过程。
图6中，在send()方法被调用后，Sender首先检测是否已有可用的安全上下文，如果可用的安全上下文已经存在，则可以利用该上下文的句柄作为参数之一，调用GSS-API的Get_GetMIC()方法。参数还包括有待进行签名的消息和可选的QoP。如果对消息签名可以正常完成，Sender就可以将消息与签名后生成的token一起送到目的地。如果签名发生异常，则可以通过返回的错误码判断原因。
文章来源于领测软件测试网 https://www.ltesting.net/
