3.业务的安全需求分析
业务的安全需求可能包括用户信息的机密性、完整性、业务本身的可用性等方面。NGN中不同类型的业务有着不同的安全需求，如会话类业务的主要安全需求是可用性，消息类业务的主要安全需求是完整性。同一类型的业务其安全需求应该也是可以根据业务场景定制的，如普通两方呼叫要求即使在网络中出现入侵的情况下也应保证呼叫的正确路由，并确保语音流的服务质量。而如果用户要求呼叫需被保密，则还需保证信令消息的机密性和语音流的机密性，需要对信令和语音流进行加密处理。不同业务的安全需求是安全特性的组合。利用建模语言，业务所需要的安全特性可以抽象成为安全感知的类来表示。这些类中的功能可以使用安全应用接口提供的安全能力实现，而业务的安全需求则表示为类的组合。为了清晰表达业务的安全需求，并便于业务安全需求的实现，本文将业务的安全需求抽象为细粒度的安全功能类，每个安全功能类表达了业务对其各个组件(如信令、媒体、业务功能等)的不同安全特性(如机密性、完整性、认证等)的需求。
下面以基于SIP的两方会话为例说明如何使用UMLsec描述业务安全需求。假定两方呼叫发生在同一SIPProxy辖域的两个用户之间，要求保证用户UA与SIPProxy之间的信令的完整性，不能被非法入侵者篡改。该场景的用例图和部署图分别如图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的定义还依赖于具体的安全机制，且具有一定的随意性，没有一个客观的标准。
