附錄A（資料性附錄）功能規范概述

A.1 概述

本附錄提供了對前面章節中為每個組件定義的規范的概述。第6章從元素集﹑關系和管理查詢的角度把RBAC參考模型定義成四個模型組件。本附錄從管理操作﹑會話管理﹑管理查看的功能規范的角度來討論抽象的模型概念。RBAC功能規范描述了對RBAC模型組件進行創建和維護的函數以及支持系統函數的語義。

RBAC功能規范中的函數分為三類：

a) 管理函數：創建和維護模型組件的元素集和關系的函數；

b) 支持系統函數：RBAC實現在用戶和IT系統交互的過程中用來支持RBAC模型構建（例如RBAC會話屬性和訪問決策邏輯）的函數；

c) 查看函數：查看管理操作的執行結果的函數。

第7章中給出了用ISO/IEC 13568-2002中定義的Z記法表示的這些函數的規范，本附錄針對其每個章節給出了概述。

A.2 核心RBAC的功能規范

A.2.1 管理函數

元素集的創建和維護：核心RBAC的基本元素集包括：USERS﹑ROLES﹑OPS﹑OBJS。OPS和OBJS被認為是由部署RBAC的底層系統進行定義的。管理員可以創建和刪除USER以及ROLES的成員，并且建立角色和操作與對象之間的聯系。對USERS進行管理的函數是AddUser和DeleteUser，對ROLES進行管理的函數是AddRole和DeleteRole。

關系的創建與維護：核心RBAC的兩個主要關系是UA和PA。對UA的進行管理的函數是AssignUser和DeassignUser，對PA進行管理的函數是GrantPermission和RevokePermission。

A.2.2 支持系統函數

支持系統函數的主要作用是會話管理和訪問控制決策。創建會話的函數給這個會話指定一組缺省的激活角色,這組缺省激活角色可以由用戶進行增加和刪除。主要的函數包括：

CreateSession：創建會話并給會話指定一組缺省激活角色。

AddActiveRole：向會話的激活角色集中添加一個角色。

DropActiveRole：從會話的激活角色集中刪除一個角色。

CheckAccess：判斷會話主體是否可以對某個對象執行某個操作。

A.2.3 查看函數

當PA和UA實例被建立起來之后，應該可以從用戶和角色的角度去查看它們的內容。例如，對于UA關系，管理員應該可以查看分配了給定角色的用戶和一個用戶分配的角色。此外管理員應該也可以查看支持系統函數的執行結果以確定會話的屬性，如會話的激活角色集和會話的全部權限空間。因為并不是所有的RBAC實現都支持這些查看功能，這些函數分別被指定為可選或強制函數，分別用O和M表示。

AssignedUsers（M）：返回分配了給定角色的用戶。

AssignedRoles（M）：返回分配給了給定用戶的角色。

UserPermission（O）：返回用戶的可用權限。

SessionRoles（O）：返回會話的激活角色集。

SessionPermissions(O)：返回會話可用的權限。

RoleOperationsOnObject(O)：返回給定角色針對給定對象可以執行的操作。

UserOperationsOnObject（O）：返回給定用戶針對給定對象可以執行的操作。

A.3 層次RBAC功能規范

A.3.1 層次管理函數

層次RBAC需要的管理函數包括核心RBAC中的所有管理函數，但是由于角色層次引入了角色授權用戶的概念，DeassignUser函數的語義必須被重新定義。用戶可以從一個他/她沒有被直接分配的角色繼承權限，因此一個很重要的問題是用戶僅僅可以被刪除直接分配給他/她的角色還是可以被刪除他/她被授權的任何角色。本標準認為這是具體實現需要決定的問題，因此沒有做出規定。

層次RBAC需要的額外的管理函數主要涉及到角色間偏序關系的維護。這些包括：(a)創建和刪除現存角色間的直接繼承關系(b)把一個新創建的角色加入到現存的角色層次上。各個函數的說明如下：

AddInheritance：在現存的兩個角色之間創建直接繼承關系。

DeleteInheritance：刪除兩個現存的角色之間的直接繼承關系。

AddAsendant：創建一個新角色，并把它指定為一個現存角色的直接祖先。

AddDescendant：創建一個角色，并把它指定為一個現存角色的直接后代。

本標準支持通用角色層次和受限角色層次。通用角色層次允許多重繼承，受限角色層次從本質上講是棵樹。對受限角色層次，AddInheritance函數需要保證每個角色只有一個直接后代。

DeleteInheritance函數的結果可能存在多種情況。假設針對角色A和角色B調用該函數，實現系統需要考慮實現下面兩種選擇中的一種：（1）系統保持角色A和角色B各自原來的隱含繼承關系。也就說，如果原來角色A通過角色B繼承了角色C和D，則角色A在與角色B之間的直接繼承關系被刪除后，仍然繼承角色C和角色D。（2）系統打破上述隱含繼承關系。函數DeleteInheritance應該采用哪種語義取決于實現系統，本標準沒有做出要求。

A.3.2 支持系統函數

層次RBAC需要的支持系統函數與核心RBAC相同。但是由于角色層次的存在，CreateSession和AddActiveRole函數需要重新定義。CreateSession函數創建的激活角色集不僅可以包括直接分配給用戶的角色還可以包含這些角色繼承的角色。與此類似，通過AddActiveRole函數，用戶不僅可以激活其直接分配的角色也可以激活這些角色繼承的角色。當一個角色被激活時，該角色繼承的那些角色被自動激活還是必須被顯式地激活是一個實現需要考慮的問題，這里不作明確的要求。

A.3.3 查看函數

核心RBAC中的查看函數保持有效。由于角色層次帶來用戶成員的繼承，這里定義了如下函數：

AuthorizedUser：返回分配了給定角色或該角色繼承的角色的用戶（給定角色的授權用戶）。

AuthorizedRoles：返回給定用戶被直接分配的角色和繼承這些角色的角色（給定用戶的授權角色）。

由于角色層次帶來了權限的繼承，這里還定義下列可選（高級）函數：

RolePermissions：返回給定角色直接分配或繼承來的權限。

UserPermissions：返回給定用戶通過直接分配的角色或者這些角色繼承的其它角色獲得的權限。

RoleOperationsOnObject：返回給定角色擁有的（直接分配或繼承來的）針對給定對象執行的操作。

UserOperationsOnObject：返回給定用戶可以執行的針對給定對象的操作（通過直接分配的角色或這些角色繼承的角色）。

A.4 靜態職責分離關系功能規范

A.4.1 管理函數

非角色層次SSD RBAC的管理函數包含核心RBAC的所有管理函數。但是由于SSD限制用戶同時可以被分配的角色，AssignUser函數應該保證不違反任何SSD約束。

一個SSD關系由一個形如(SSD_Set_Name, role_set, SSD_Card)的三元組構成。SSD_Set_Name指示了要限制用戶/角色分配以貫徹利益沖突策略的事務或商業過程的名稱。role_set是SSD_Set_Name對應的角色集。SSD_Card給出了閾值。因此，創建和維護SSD關系的管理函數包括創建和刪除SSD關系﹑添加和刪除SSD關系中角色集的成員﹑設置SSD_Card參數。下面是相關的管理函數：

CreateSSDSet：創建一個命名的SSD關系。

DeleteSSDSet：刪除一個現存的SSD關系。

AddSSDRoleMember：添加一個角色到給定SSD角色集。

DeleteSSDRoleMember：從一個給定SSD角色集刪除一個角色。

SetSSDCardinality：為給定的SSD角色集設定閾值。

對于角色層次（通用角色層次和受限角色層次）RBAC下的SSD，上面的函數基本上產生同樣的結果。唯一的例外是：這些函數在執行時，針對角色層次的組合約束和SSD約束都應該被滿足，例如同一角色層次鏈上的角色不能被包含在同一SSD角色集中。

A.4.2 支持系統函數

靜態職責分離RBAC模型的支持系統函數與核心RBAC相同。

A.4.3 查看函數

這里包含核心RBAC的所有查看函數。此外，7.4.1條列出的查看管理函數執行結果的查看函數在這里也是需要的。這些包括：(a)一個查看已創建的SSD關系的函數(b)一個返回命名的角色集包含的所有角色的函數（c）一個返回與命名角色集關聯的閾值的函數。

SSDRoleSets：返回SSD RBAC中的命名SSD關系。

SSDRoleSetRoles：返回與給定的命名角色集關聯的角色。

SSDRoleSetCardinality:返回與命名的給定角色集關聯的閾值。

A.5 動態職責分離關系功能規范

A.5.1 管理功能

創建一個DSD實例的語義和創建SSD實例的語義相同。SSD約束在用戶角色/分配時實施，而DSD約束在用戶會話激活角色時實施。下面是DSD RBAC需要的管理函數：

CreateDSDSet：創建DSD關系的一個命名實例。

DeleteDSDSet：刪除一個現存的DSD關系。

AddDSDRoleMember：添加一個角色到命名DSD角色集。

DeleteDSDRoleMember：從命名的DSD角色集刪除一個角色。

SetDSDCardinality：設定與命名DSD角色集關聯的閾值。

A.5.2 支持系統函數

7.2.2條定義了核心RBAC的支持系統函數：CreateSession﹑AddActiveRole﹑DeleteActiveRole。對于非角色層次動態職責分離RBAC而言，這些都是可用的。不過需要對它們做出額外的要求：不能違反任何DSD約束。例如，在CreateSession執行時，創建的激活角色集不能違反任何DSD約束。同樣的，AddActiveRole函數必須確保添加角色后不違反任何DSD約束。

角色層次RBAC動態職責分離的支持系統函數的語義與7.3.2條相應的函數相同。

CreateSession：創建一個會話并指定缺省的激活角色集。

AddActiveRole：給會話的激活角色集增加一個激活角色。

DropActiveRole：從會話的激活角色集中刪除一個角色。

A.5.3 查看函數

這里需要包含核心RBAC的所有查看函數。此外，7.4.1條列出的查看管理函數執行結果的查看函數在這里都是需要的。這些包括：(a)一個查看已創建的命名的DSD關系的函數(b)一個返回與命名的角色集所有角色的函數（c）一個返回與命名角色集關聯的閾值的函數。

DSDRoleSets：返回DSD RBAC中命名的DSD關系。

DSDRoleSetRoles：返回與給定的命名角色集關聯的角色。

DSDRoleSetCardinality：返回與給定的命名角色集關聯的閾值

A.6 功能規范包

RBAC是一項提供諸多訪問控制管理特征的技術。第6章定義了一個功能組件族：核心RBAC﹑層次RBAC﹑靜態職責分離關系﹑動態職責分離關系。每個功能組件包含三個部分：創建和維護RBAC元素集和關系的管理操作﹑管理查看函數﹑系統級別的用于會話管理和訪問控制決策的函數。

該部分描述了定義功能組件包的邏輯方法，每個組件包可能適用于不同的威脅環境和市場需求。除了核心RBAC必須被包含在每個組件包中，其它任何組件可以被可選地包含在任何組件包中。在選擇組件的時候，可以參考附錄B中給出了每個組件的原理。圖A.1給出了構建組件包的方法學的概述。

層次RBAC包含兩個子組件—通用角色層次和受限角色層次。因此如果一個組件包需要包含角色層次RBAC，它必須決定選擇哪一個子組件。層次RBAC的高級查看功能也是可選的。

靜態職責分離關系組件也包括兩個子組件：無角色層次下的靜態職責分離和角色層次下的靜態職責分離。如果在一個組件包中需要選擇靜態職責分離關系組件，就需要遵循依賴關系。也就是說，如果該組件包選擇了角色層次RBAC，則就要選擇角色層次下的靜態職責分離，否則只能選擇靜態職責分離關系。