学过H3C设备的朋友都知道，在Comware V5及以前版本中，用户权限是由"命令级别"和"用户级别"结合来配置的， 而在最新的Comware V7版本中，却为此引入了一些全新的概念——用户角色、用户线、资源策略等，对以前版本的配置方法进行了彻底颠覆。

其中“用户角色”其实与操作系统中的用户组类似。我们知道，在Windows或Linux操作系统中，不同的用户组可以赋予不同的权限（相当于具有不同角色），只要把用户加入到对应的用户组中，就自动继承所加入的用户组的权限。V7的“用户角色”设计也是基于这种思想的。

【说明】笔者最新出版上市的《Cisco/H3C交换机配置与管理完全手册》（第三版）是目前国内首部，也是唯一一部专门针对Comware V7版本而编写的图书，当然V7与V5版本的区别远不止本文将要向大家介绍的RBAC。可在我的视频课程中心购买本书配套的实战视频课程：http://edu.51cto.com/lecturer/user_id-55153.html

12.8.1 RBAC概述

在Comware V7中的“用户角色”设计的基本思想与操作系统的“用户组”设计思想是一样的，通过为登录用户指定所属的用户角色就可以为不同用户赋予不同的设备访问权限，即用户登录后可以执行哪些命令。这是Comware V7中新引入的RBAC（Role Based Access Control，基于角色的访问控制）。
       RBAC通过建立“权限-角色”的关联实现将权限赋予给角色，并通过建立“角色-用户”的关联实现为用户指定角色，从而使用户获得相应角色所具有的权限。RBAC的基本思想就是给用户指定角色，这些角色中定义了允许用户操作哪些系统功能以及资源对象。所以在配置RBAC时，一要创建所需的用户角色（Comware V7系统也有自带的用户角色，就像操作系统中原来就有的管理员组一样），二是要为对应的用户角色指定对应的访问策略，即为用户配置相应的访问权限。
     相比以前版本的命令级别/用户级别策略，RBAC具有以下优势：

• 权限部署更容易：管理员不需要针对用户去逐一指定权限，只需要预先定义具有相应权限的角色，再将角色赋予用户即可。

• 权限分配更灵活：因为RBAC实现了权限与用户的分离，权限仅与用户角色关联，所以用户可以方便地在需要时选择指派不同的用户角色，以获取不同的权限，提高了用户权限分配的灵活性。就像在操作系统中通过用户组就可以无需为每个用户配置具体的访问权限，只需为对应的用户组配置权限即可。

• 减小用户授权管理的复杂性：由于角色与用户的关系常常会发生变化（管理员可以根据实际需要随时调整用户所赋予的用户角色），但是角色和权限的关系相对稳定（就像操作系统中的每个用户组权限一般是不随意更改的），因此利用这种稳定的关联可减小用户授权管理的复杂性。

12.8.2 权限与角色的关联

在H3C Comware V7版本中，权限与角色的关联是通过为角色赋予权限建立的，具体实现包括以下两个方面：

• 通过用户角色规则实现对系统功能的操作权限的控制。例如，定义用户角色规则允许用户配置A功能，或禁止用户配置B功能。

• 通过资源控制策略实现对系统资源（包括接口、VLAN、VPN实例）的操作权限的控制。例如，定义资源控制策略允许用户操作VLAN 10，禁止用户操作接口Ten-GigabitEthernet1/0/1。

下面具体介绍“用户角色规则”和“资源控制策略”。

1. 用户角色规则

“用户角色规则”定义了允许/禁止用户操作某些功能的权限。一个用户角色中可以包含多条用户角色规则，每条规则定义了是允许，还是禁止用户对某命令、特性、特性组、XML元素或者OID（对象ID）进行操作。
（1）命令：控制用户权限的最小单元。RBAC根据命令的作用，将命令分成以下三类：

• 读类型：本类型的命令仅能查看系统配置信息和维护信息，如查看配置信息的display命令、查看文件信息的dir命令等。

• 写类型：本类型的命令用于对系统进行配置，如使能信息中心功能的info-center enable命令、配置调试信息开关的debugging命令等。

• 执行类型：本类型的命令用于执行特定的功能，如ping命令、与FTP服务器建立连接的ftp命令等。

（2）特性：“特性”也就是通常所说的“功能”，是与一个特定功能相关的所有命令的集合，例如NTP特性包含了所有NTP的配置、显示及调试命令。系统中的所有特性及其包含的命令都是系统预定义的，不允许用户自定义。
（3）特性组：是指一个或者多个特性的集合。其主要目的是为了方便管理员对用户权限进行权限的批量配置。系统预定义了两个特性组L2（二层）和L3（三层）。L2中包含了所有的二层协议相关功能的命令，L3中包含了所有三层协议相关功能的命令。管理员可以根据需要自定义特性组，但不能修改和删除系统预定义的特性组L2和L3。各个特性组之间包含的特性允许重叠。
（4）XML元素：对于配置对象的组织呈现树状结构，是一个表单，如查看某个配置信息时所列出的各个参数及对应值就是一个表单，类似于SNMP协议中的MIB（管理信息库）结构，每一个XML元素代表XML配置中的一个XML节点。
（5）OID：Object Identifier，对象标识符，SNMP协议通过OID唯一标识一个被管理对象。

正因为用户角色规则可以是以上五种不同的类型，所以根据权限控制范围的不同，可以将用户角色规则（规则操作是“允许”，或者“禁止”）分为如下五类：

• 基于命令的规则：用来控制一条命令或者与指定命令关键字相匹配的一类命令（通过加通配符*来指定）是否允许被执行。

• 基于特性的规则：用来控制特性包含的命令是否允许被执行。因为特性中的每条命令都属于读类型、写类型或执行类型，所以在定义基于特性的规则时，可以精细地控制特性所包含的读、写或执行类型的命令能否被执行。

• 基于特性组的规则：此规则和基于特性的规则类似，区别是一条基于特性组的规则中可同时对多个特性包含的命令进行控制。

• 基于XML元素的规则：用来控制指定的XML元素是否允许被执行。XML元素也具有读、写或执行属性。

• 基于OID的规则：用来控制指定的OID是否允许被SNMP访问。OID也具有读、写和执行属性。

一个用户角色中可以定义多条规则，各规则以创建时指定的规则编号来进行唯一标识，被授权该角色的用户可以执行的命令为这些规则中定义的可执行命令的合集。若这些规则定义的权限内容有冲突，则规则编号大的有效。例如，规则1允许执行命令A，规则2允许执行命令B，规则3禁止执行命令A，则最终规则2和规则3生效，即禁止执行命令A，允许执行命令B。

2. 资源控制策略

Comware V7中的“资源控制策略”规定了用户对系统资源的操作权限。在用户角色中可定义三种类型的资源控制策略：接口策略、VLAN策略以及VPN策略，它们分别定义了用户允许操作的接口、VLAN或者VPN实例。对接口/VLAN/VPN实例的操作是指创建，并进入接口视图/VLAN视图/VPN实例视图、删除和应用接口/VLAN/VPN实例（但在display命令中指定接口/VLAN/VPN实例参数并不属于应用接口/VLAN/VPN实例）。没有明确允许时，则为禁止。
      “资源控制策略”需要与“用户角色规则”相配合才能生效，即在用户执行某命令的过程中，系统对该命令所涉及的系统资源使用权限进行动态检测，只有在用户同时拥有执行该命令的权限和使用该资源的权限时才能执行该命令。例如，若管理员为某用户角色定义了一条规则允许用户执行创建VLAN的命令vlan，且同时定义了一条VLAN策略允许用户操作VLAN 10，则当用户被授权此用户角色并试图创建VLAN 10时，操作会被允许，但试图创建其它VLAN时，操作会被禁止。同理，如果若管理员并没有为该用户角色定义规则允许用户执行创建VLAN命令，则用户即便拥有该VLAN资源的操作权限，也无法执行相关的命令。
       这个就相当于在Windows或Linux操作系统中，我们可能为某个用户赋予了管理员权限，但是在对具体文件夹的访问时我们又禁止了该用户或者该用户所在的用户组的访问权限，则最终该用户还是不能访问该文件夹。只有两者同时允许才能最终使该用户具有访问该文件夹的权限。

3. 缺省用户角色

系统预定义了多种用户角色，用户角色名和对应的权限说明如表12-9所示（此处 略）。这些用户角色缺省均具有操作所有系统资源的权限，但具有不同的系统功能操作权限。如果系统预定义的用户角色无法满足权限管理需求，管理员还可以自定义用户角色来对用户权限做进一步控制。
      在Comware V5及以前版本中，用户的访问权限是由命令级别和用户级别来决定的，在Comware V7版本中，引入了新的概念——用户角色。其实这与操作系统中的用户组类似。我们知道，在Windows或Linux操作系统中，不同的用户组可以赋予不同的权限，只要把用户加入到对应的用户组中，就自动继承所加入的用户组的权限。

12.8.3 角色与用户的关联

角色与用户的关联是通过为用户赋予角色建立的，就相当于Windows系统中的用户与用户组之间的关系是通过把用户加入到对应的用户组面是建立的一样。将有效的用户角色成功授权给用户后，登录设备的用户才能以所赋予的角色的权限来配置、管理或者监控设备。
       根据用户登录设备时采用的不同认证方式，可以将为用户授权角色分为AAA（Authentication、Authorization、Accounting，认证、授权、计费）方式和非AAA方式。
（1）AAA方式：用户登录时使用的认证方式为scheme，用户登录设备后所拥有的用户角色由AAA功能进行授权。

• 若用户通过的是本地授权，则由设备的本地配置为用户进行授权，即授权的用户角色是在本地用户中设置的。

• 若用户通过了远程授权，则由远程AAA服务器为其授权用户角色，即授权的用户角色是在远程AAA服务器（RADIUS或HWTACACS服务器）上设置的。

（2）非AAA方式：用户登录时使用的认证方式为none或者password，用户登录后所拥有的用户角色是由该用户登录时所使用的用户线所配置的用户角色。
       以上两种方式均支持对一个用户同时授权多个用户角色。拥有多个角色的用户可获得这些角色中被允许执行的功能以及被允许操作的资源的集合。例如，某用户拥有角色A，它禁止用户执行qos apply policy命令，且仅允许操作接口2。同时，该用户拥有角色B，它允许用户执行qos apply policy命令，且允许用户操作所有接口。这种情况下该用户将能够在所有接口下执行qos apply policy命令，以及可以操作所有的接口资源。这也就相当于Windows操作系统中一个用户可以加入多个用户组，最终具有的权限是所加入用户组的权限合集。
       在以上两类用户角色授权方式下，用户最终获得的用户角色如下：

• 对于none和password认证方式，登录用户的角色由用户线下的用户角色配置决定。

• 对于scheme认证方式，且用户通过SSH的publickey或password-publickey方式登录设备时，登录用户将被授予同名的设备管理类本地用户视图下配置的授权用户角色。

• 对于scheme认证方式，非SSH登录以及用户通过SSH的password方式登录设备时，登录用户使用AAA认证用户的角色配置。尤其对于远程AAA认证用户，如果AAA服务器没有下发用户角色，且缺省用户角色授权功能处于关闭状态时，用户将不能登录设备。

从以上的介绍可以看出，基于RBAC的用户权限配置方法与以前版本中基于命令级别和用户级别的配置方法完全不一样。将在后面的文章中介绍几个利用RBAC为各种应用访问所做的用户权限配置方法。

本文转自王达博客51CTO博客，原文链接http://blog.51cto.com/winda/1902822如需转载请自行联系原作者

茶乡浪子