逆天的H3C Comware V7 RBAC

        學過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、×××實例）的操做權限的控制。例如，定義資源控制策略容許用戶操做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策略以及×××策略，它們分別定義了用戶容許操做的接口、VLAN或者×××實例。對接口/VLAN/×××實例的操做是指建立，並進入接口視圖/VLAN視圖/×××實例視圖、刪除和應用接口/VLAN/×××實例（但在display命令中指定接口/VLAN/×××實例參數並不屬於應用接口/VLAN/×××實例）。沒有明確容許時，則爲禁止。
      「資源控制策略」須要與「用戶角色規則」相配合才能生效，即在用戶執行某命令的過程當中，系統對該命令所涉及的系統資源使用權限進行動態檢測，只有在用戶同時擁有執行該命令的權限和使用該資源的權限時才能執行該命令。例如，若管理員爲某用戶角色定義了一條規則容許用戶執行建立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爲各類應用訪問所作的用戶權限配置方法。