目录:
☆ SNMPv3视图访问控制模型
☆ SNMPv3报文格式
☆ VACM参数
☆ Context Table
☆ Security To Group Table
☆ Access Table
☆ View Tree Family Table
☆ Overall Picture
☆ 小结
☆ 参考资源
--------------------------------------------------------------------------
☆ SNMPv3视图访问控制模型
本文是介绍SNMPv3新安全特性的第二篇。前面我们介绍了基于用户的安全模型USM以
及如何完成SNMPv3报文的鉴别、加密、解密。这次我们介绍基于视图的访问控制模型
VACM(View-based Access Control Model)，RFC 2575定义了VACM，它提供对MIB的访
问控制。
一个SNMP实体的访问控制子系统负责检查对指定MIB的某种类型的访问是否被允许。
你将会看到，VACM引入的概念相当复杂、混乱。SNMPv1和SNMPv2c采用community
string来划分MIB范围、确定访问权限等等。而VACM允许更加严谨的动态的访问控制
模型，易于管理员配置。
☆ SNMPv3报文格式
SNMPv3的报文格式变得适合使用USM这样的安全模型以及VACM这样的访问控制模型。
msgVersion
报文的SNMP版本号，比如1、2或3
msgID
msgID用于在manager和agent之间对应请求和响应消息。响应报文中的msgID必须
与请求报文中的msgID一致。
msgMaxSize
msgMaxSize指明了"发送者"所能接收的来自其它SNMP engine的最大消息长度。
msgFlags
msgFlags就一个字节，指明如何处理消息。比如，msgFlags中有两个bits用于指
明报文是否需要验证、加密。
msgSecurityModel
SNMPv3被设计成多种安全模型并存。msgSecurityModel指明该消息使用的安全模
型。这样接收实体就知道该采用哪种安全模型。
msgSecurityParameters
这是一个字节数组，对应安全模型相关数据。这些数据仅由msgSecurityModel指
定的安全模型定义、使用。介绍USM时，已经看到如何利用这个域对SNMPv3报文
进行鉴别、加密、解密。
scopedPDU
scopedPDU包含常规PDU以及一些鉴别信息，这些鉴别信息指明处理PDU时的唯一
上下文，上下文是可配置的。
☆ VACM参数
VACM在进行访问控制时会用到msgFlags、msgSecurityModel以及scopedPDU域。
msgFlags用于确定消息的安全级别，比如noAuthNoPriv、authNoPriv或authPriv。
msgSecurityModel指明消息所用安全模型。scopedPDU包含上下文以及被管理对象的
OIDs，具体有如下域:
contextEngineID
contextEngineID唯一标识一个SNMP实体，该实体在特定上下文内可以访问一个
被管理对象的实例。
contextName
PDU数据所属上下文的唯一名字，这个是可配置的。
PDU(数据)
SNMP协议数据单元。参看RFC 1905了解SNMP PDUs更多信息。
这三个参数被传递给isAccessAllowed()函数，该函数是VACM的唯一入口点，在此决
定访问是否被允许。PDU中每一个变量都要接受检查，如果其中一个变量不可访问，
就向主调者返回错误，处理将终止。VACM定义了四个表，每个表负责不同方面的访问
控制，它们均可通过VACM MIB远程修改。
☆ Context Table
这里所谓的上下文实际定义了一个SNMP实体所能访问的被管理对象集合。换言之，用
一个名字代表被管理对象子集。可能一个对象位于多个上下文中，可能一个SNMP实体
被允许访问多个上下文。vacmContextTable用于存放所有本地可访问上下文，其关键
字为contextName，每个表项含有:
vacmContextName
一个唯一的可读字符串，用于命名一个上下文。会在vacmContextTable中搜索
scopedPDU里的contextName。如未找到匹配，拒绝访问并返回noSuchContext。
反之继续访问控制检查。
☆ Security To Group Table ----user和group的关系
groupName针对一组principals定义一种访问控制策略。principal是对SNMP实体的细
化，代表来自SNMP实体的一个具体用户操作。组中可有零个或多个元素(principal)。
securityName与msgSecurityModel构成复合关键字，至多确定一个组。于是，一个通
信受特定securityModel保护的特定principal只能属于一个组。
vacmSecurityToGroupTable用于存放组信息，其复合关键字为securityModel和
securityName，每个表项含有:
vacmSecurityModel
指定SNMPv3安全模型，比如USM
vacmSecurityName
代表一个principal的名字，格式与安全模型无关。对于USM，securityName就是
userName。
vacmGroupName
一个可读字符串，标识该表项所属组。
首先根据msgSecurityModel对SNMPv3报文进行鉴别、解密，获取securityName。然后
securityName与msgSecurityModel构成复合关键字，在表中匹配搜索。如果没有找到
匹配表项，拒绝访问并返回noSuchGroupName。否则返回相应的groupName，继续访问
控制检查。
☆ Access Table ------group和view的关系
vacmAccessTable存放各组的访问权限。为了确定是否允许访问，必须从表中选取表
项，根据其中相应的viewName进行后续访问控制检查。一个组可能对应着多种访问权
限，最终只选取最大安全化的那个表项。就是说，最高安全、最长contextPrefix匹
配的表项被选中。参看vacmAccessTable MIB描述了解更多信息。该表靠groupName、
contextPrefix、securityModel以及securityLevel进行索引，每个表项含有:
vacmGroupName
组名，有访问权限对应之。
vacmAccessContextMatch
如果设置为exact，contextName必须与vacmAccessContextPrefix精确匹配。如
果设置为prefix，contextName只需与vacmAccessContextPrefix前面几个字符匹
配即可。
vacmAccessContextPrefix
contextName将与之做比较
vacmAccessSecurityModel
为了获取这种访问权限而必须使用的securityModel
vacmAccessSecurityLevel
为了获取这种访问权限而必须使用的最小securityLevel。安全级别的顺序是
noAuthNoPriv < authNoPriv < authPriv
vacmAccessReadViewName
读访问所用的权威MIB viewName。如果该值为空串，表示没有任何活动视图被配
置成可读的。
vacmAccessWriteViewName
写访问所用的权威MIB viewName。如果该值为空串，表示没有任何活动视图被配
置成可写的。
vacmAccessNotifyViewName
notify访问所用的权威MIB viewName。如果该值为空串，表示没有任何活动视图
被配置成允许notify访问的。
检查该表时所用contextName是通过vacmContextTable检查的有效contextName。所用
groupName来自检查vacmSecurityToGroupTable时的返回值。securityModel来自消息
中的msgSecurityModel，securityLevel来自msgFlags。如果最终未匹配出一个访问
权限，则拒绝访问并返回noAccessEntry。
一旦匹配出一个访问权限，与之对应的适当的viewName将被选取出来，使用哪个
viewName根据PDU中SNMP操作决定。GET和NEXT操作使用vacmAccessReadViewName，
SET操作使用vacmAccessWriteViewName。TRAP操作使用vacmAccessNotifyViewName。
如果相应viewName未被配置，拒绝访问并返回noSuchView。
最后，如果匹配出一个访问权限也选取了适当的viewName，访问控制检查继续进行。
☆ View Tree Family Table ---view表
vacmViewTreeFamilyTable存放MIB views。一个MIB view由一颗OID子树和一个掩码
共同定义。
对于每个给定OID，当下列两点同时满足时，被认为属于一个特定MIB view:
1) OID至少与OID子树一样长
2) OID & 掩码 == OID子树 & 掩码
掩码是可配置的，如果它在测试中比OID或OID子树短，隐式认为不足部分为均为1。
所以，如果一个view subtree family的掩码为空(长度为零)，意味着这个掩码为全
1，对应一颗单一的OID子树。
例如，假设定义了如下一些MIB视图
(A) subtree: 1.3.6.1.2.1
mask: 1 1 1 1 1 1
(B) subtree: 1.3.6.1.2.1.1.1
mask: 1 1 1
(C) subtree: 1.3.6.1.2.1.2
mask: none
(D) subtree: 1.3.6.1.2.1.1
mask: 1 1 0 1 0 1 1
(E) subtree: 1.3.6.1.2.1.2
mask: 1 1 0 1 0
(F) subtree: 1.3.6.1.2.1
mask: 1 1 0 1 0 1
根据如上MIB view检查来自如下一些OID，以确定这些OID是否是否属于某个MIB视图。
由于掩码的存在，一个OID可能位于多个MIB视图，也可能不属于任何视图。
1.3.6.1.2.1 belongs to: A, F
1.2.6.1.2.1.1 belongs to: none of them
1.3.6.1.3.1 belongs to: F
1.3.4.1.4.1.2 belongs to: E, F
1.3.6.1.2.1.1.1.0 belongs to: A, B, D, F
1.3.6.1.2 belongs to: none of them
所有的MIB views都保存在vacmViewTreeFamilyTable中，该表靠viewName和OID子树
索引。注意，VACM MIB定义了一个旋锁vacmViewSpinLock，当多个SNMP Manager通过
VACM MIB修改该表时，就会用到vacmViewSpinLock。其用法与usmUserSpinLock的用
法是一样的，参看<<SNMP/MIB系列(12)--SNMPv3用户安全模型>>。该表中每个表项包
含:
vacmViewTreeFamilyViewName
一个字符串，MIB视图名
vacmViewTreeFamilySubtree
一颗OID子树，与vacmViewTreeFamilyMask一道定义一颗或多颗MIB视图子树
vacmViewTreeFamilyMask
掩码，与vacmViewTreeFamilySubtree一道定义一颗或多颗MIB视图子树
vacmViewTreeFamilyType
指明vacmViewTreeFamilySubtree与vacmViewTreeFamilyMask一道定义的MIB视图
子树是包含在MIB view内，还是排除在MIB view外。
这里用来索引vacmViewTreeFamilyTable的viewName来自vacmAccessTable中的权威视
图名。根据MIB view检查来自PDU的OID。如果OID不属于任何MIB view，拒绝访问并
返回notInView。反之，允许访问并返回accessAllowed。
☆ Overall Picture
VACM定义的访问控制算法稍微有点复杂、难于理解。下面这张流程图演示了前述四张
表各自的输入输出。securityModel与securityName决定who，contextName决定where，
securityModel与securityLevel决定how，viewType(比如read、write或notify)决定
why。被管理对象的OID决定what，被管理对象实例决定which。
--------------------------------------------------------------------------
☆ 小结
VACM概览使你理解如何针对SNMPv3报文进行访问控制管理。
配置每个VACM表时应该特别小心。一点微小的错误配置可能导致一个巨大的安全漏洞，
比如潜在允许对敏感数据进行非法访问。应该先在一个测试用网络环境中测试你的配
置，确认无误后再应用到实际网络环境中去。
SNMPv3框架确保了安全子系统和访问控制子系统的模块化，虽然目前USM与VACM分别
被用做安全模块以及访问控制模块，但你可以实现自己的安全模块以及访问控制模块。
将来IETF可能会更新这些模块。无论如何，SNMPv3框架确保新旧模块之间可以平滑过
渡。