本文主要是介绍SNMPv3基于视图的访问控制模型VACM，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
转载：http://blog.csdn.net/fw0124/article/details/8557777
SNMPv3使用了基于视图的访问控制模型VACM, 它提供对MIB的访问控制。
- RFC 3411 Architecture for SNMP Frameworks http://www.ietf.org/rfc/rfc3411.txt
- RFC 3415 View Access Control Model (VACM) http://www.ietf.org/rfc/rfc3415.txt
VACM引入的元素
1) Groups
A group is a set of zero or more <securityModel, securityName> tuples on whose behalf SNMP management objects can be accessed. A group defines the access rights afforded to all securityNames which belong to that group. The combination of a securityModel and a securityName maps to at most one group. A group is identified by a groupName.
一个VCAM Group包含多个<securityModel, securityName>的组合。一个<securityModel, securityName>的组合最多只能属于一个Group.
在Group上可以定义访问控制策略。
securityModel定义如下：
0 reserved for 'any'
1 reserved for SNMPv1
2 reserved for SNMPv2c
3 User-Based Security Model (USM)
对于USM，securityName就是userName。
2) securityLevel
Different access rights for members of a group can be defined for different levels of security.
在一个Group内可以为不同的securityLevel定义不同的访问权限。securityLevel包括
noAuthNoPriv(1), --无认证无加密
authNoPriv(2), --有认证无加密
authPriv(3) --有认证有加密
3) Contexts
一个SNMP context可以看作是管理信息的一个集合。
一个SNMP entity里面可以访问多个SNMP context。
4) MIB View
一个MIB View在一个Context里面定义了管理信息的一个子集。
由于MIB是定义为树形结构，所以一个MIB View也可以看作是一个view subtree或者多个view subtree的集合。
5) Access Policy
For a particular context, identified by contextName, to which a group, identified by groupName, has access using a particular securityModel and securityLevel, that group's access rights are given by a read-view, a write-view and a notify-view.
Access Policy定义在一个特定的context, group, securityModel, securityLevel上。包括read-view, a write-view and a notify-view，分别代表读，写，发送Notification权限。
VACM MIB
RFC3415为VACM定义了4张MIB Table，包含在SNMP-VIEW-BASED-ACM-MIB中。
1) Context Table
vacmContextTable存放了所有的Context.
表的index为contextName, 只包含1列vacmContextName。
VACM在进行访问控制时首先会在vacmContextTable中搜索scopedPDU里的contextName。
如未找到匹配，拒绝访问并返回noSuchContext，否则继续访问控制检查。
2) Security To Group Table
vacmSecurityToGroupTable存放了Group信息。
表格的index为
1: vacmSecurityModel
2: vacmSecurityName
包含3列
1: vacmGroupName - SnmpAdminString(4 - octets)
2: vacmSecurityToGroupStorageType - StorageType(2 - integer (32 bit))
3: vacmSecurityToGroupStatus - RowStatus(2 - integer (32 bit))
*StorageType包含other, volatile,nonVolatile,permanent,readOnly。
根据SNMP消息中msgSecurityModel和msgUserName，在表中匹配搜索的Group。
如果没有找到匹配表项，拒绝访问并返回noSuchGroupName。
否则返回相应的groupName，继续访问控制检查。
3) Access Table
vacmAccessTable存放各组的访问权限。
表格的index为
1: vacmGroupName
2: vacmAccessContextPrefix
3: vacmAccessSecurityModel
4: vacmAccessSecurityLevel
包含6列
1: vacmAccessContextMatch - INTEGER(2 - integer (32 bit))
2: vacmAccessReadViewName - SnmpAdminString(4 - octets)
3: vacmAccessWriteViewName - SnmpAdminString(4 - octets)
4: vacmAccessNotifyViewName - SnmpAdminString(4 - octets)
5: vacmAccessStorageType - StorageType(2 - integer (32 bit))
6: vacmAccessStatus - RowStatus(2 - integer (32 bit))
* vacmAccessContextMatch可以为exact或prefix.
* exact说明contextName必须与vacmAccessContextPrefix精确匹配。
* 如果设置为prefix，contextName只需与vacmAccessContextPrefix前面几个字符匹配即可。
VCAM从表中选取相应的viewName进行后续访问控制检查。
检查该表时所用contextName是通过vacmContextTable检查的有效contextName。
所用groupName来自检查vacmSecurityToGroupTable时的返回值。
securityModel来自消息中的msgSecurityModel，securityLevel来自msgFlags。
如果最终未匹配出一个访问权限，则拒绝访问并返回noAccessEntry。
一个组可能对应着多种访问权限，最终只选取最高securityLevel、最长contextPrefix匹配的表项。
一旦匹配出一个访问权限，与之对应的适当的viewName将被选取出来如果相应viewName未被配置，拒绝访问并返回noSuchView。
如果匹配出一个访问权限也选取了适当的viewName，访问控制检查继续进行。
4) View Tree Family Table
vacmViewTreeFamilyTable存放MIB views。
表格的index为
1: vacmViewTreeFamilyViewName
2: vacmViewTreeFamilySubtree
包含4列
1: vacmViewTreeFamilyMask - OCTET STRING(4 - octets)
2: vacmViewTreeFamilyType - INTEGER(2 - integer (32 bit))
3: vacmViewTreeFamilyStorageType - StorageType(2 - integer (32 bit))
4: vacmViewTreeFamilyStatus - RowStatus(2 - integer (32 bit))
* vacmViewTreeFamilyType可以为included或者excluded。
对于每个给定OID，当下列两点同时满足时，被认为属于一个特定MIB view:
1) OID长度大于或等于OID子树长度
2) OID子树&掩码 的结果完全和 OID & 掩码 的结果相同，
如果OID长度大于OID子数长度，前者完全是后者的前缀。
掩码是可配置的，如果它比OID或OID子树短，隐式认为不足部分为均为1。
所以，如果掩码为空(长度为零)，意味着这个掩码为全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
VACM访问控制流程
statusInformation = -- success or errorIndication
isAccessAllowed(
securityModel -- Security Model in use
securityName -- principal who wants access
securityLevel -- Level of Security
viewType -- read, write, or notify view
contextName -- context containing variableName
variableName -- OID for the managed object
)
statusInformation - one of the following:
accessAllowed - a MIB view was found and access is granted.
notInView - a MIB view was found but access is denied.
The variableName is not in the configured
MIB view for the specified viewType (e.g., in
the relevant entry in the vacmAccessTable).
noSuchView - no MIB view found because no view has been
configured for specified viewType (e.g., in
the relevant entry in the vacmAccessTable).
noSuchContext - no MIB view found because of no entry in the
vacmContextTable for specified contextName.
noGroupName - no MIB view found because no entry has been
configured in the vacmSecurityToGroupTable
for the specified combination of
securityModel and securityName.
noAccessEntry - no MIB view found because no entry has been
configured in the vacmAccessTable for the
specified combination of contextName,
groupName (from vacmSecurityToGroupTable),
securityModel and securityLevel.
otherError - failure, an undefined error occurred.
这篇关于SNMPv3基于视图的访问控制模型VACM的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
