組織為每個(gè)員工分配基于角色的訪(fǎng)問(wèn)控制角色;該角色確定系統授予用戶(hù)的權限。例如，您可以指定用戶(hù)是管理員、專(zhuān)家還是最終用戶(hù)，并限制對特定資源或任務(wù)的訪(fǎng)問(wèn)。組織可能允許某些個(gè)人創(chuàng )建或修改文件，而僅向其他人提供查看權限。

一個(gè)基于角色的訪(fǎng)問(wèn)控制示例是一組允許用戶(hù)在寫(xiě)入應用程序中讀取、編輯或刪除文章的權限。有兩個(gè)角色：“編寫(xiě)者”和“讀取者”，它們各自的權限級別在此真值表中顯示。使用此表，您可以為每個(gè)用戶(hù)分配權限。

權限/角色作家讀者編輯是的不 刪除是的不 讀是的是的

在某些情況下，組織會(huì )向不同的角色授予不同級別的權限，或者其權限級別可能會(huì )重疊。在上面的示例中，一個(gè)角色（讀取者）是另一個(gè)具有更多權限的角色（編寫(xiě)者）的子集。

訪(fǎng)問(wèn)控制的類(lèi)型：補充控制機制

訪(fǎng)問(wèn)控制措施控制誰(shuí)可以查看或使用計算系統中的資源，通常依賴(lài)于基于登錄憑據的身份驗證或授權。它們對于最大限度地降低業(yè)務(wù)風(fēng)險至關(guān)重要。門(mén)禁系統可以是物理的，限制對建筑物，房間或服務(wù)器的訪(fǎng)問(wèn)，也可以是邏輯的，控制對數據，文件或網(wǎng)絡(luò )的數字訪(fǎng)問(wèn)。

角色企業(yè)網(wǎng)絡(luò )電子郵件客戶(hù)關(guān)系管理客戶(hù)數據庫Unix員工信息用戶(hù)是的是的不 不 不 不 IT 系統管理員是的是的是的是的是的是的開(kāi)發(fā) 人員是的是的不 不是的不 銷(xiāo)售顧問(wèn) 不是的是的是的不 不 人力資源是的是的不 不 不是的

基于角色的訪(fǎng)問(wèn)控制可以通過(guò)其他訪(fǎng)問(wèn)控制技術(shù)進(jìn)行補充。此類(lèi)訪(fǎng)問(wèn)控制的示例包括：

隨機訪(fǎng)問(wèn)控制 （DAC）

受保護系統或資源的所有者設置策略，定義誰(shuí)可以訪(fǎng)問(wèn)它。DAC可以涉及物理或數字措施，并且比其他訪(fǎng)問(wèn)控制系統的限制更少，因為它使個(gè)人可以完全控制他們擁有的資源。但是，它也不太安全，因為關(guān)聯(lián)的程序繼承安全設置并允許惡意軟件在最終用戶(hù)不知情的情況下利用它們?？梢允褂?RBAC 實(shí)現 DAC。

強制訪(fǎng)問(wèn)控制 （MAC）

中央機構根據多個(gè)安全級別來(lái)調節訪(fǎng)問(wèn)權限。MAC 涉及將分類(lèi)分配給系統資源和安全內核或操作系統。只有具有所需信息安全許可的用戶(hù)或設備才能訪(fǎng)問(wèn)受保護的資源。具有不同數據分類(lèi)級別的組織（如政府和軍事機構）通常使用 MAC 對所有最終用戶(hù)進(jìn)行分類(lèi)。您可以使用基于角色的訪(fǎng)問(wèn)控制來(lái)實(shí)現 MAC。

RBAC 替代/升級方案

其他訪(fǎng)問(wèn)控制機制可以作為基于角色的訪(fǎng)問(wèn)控制的替代方案。

訪(fǎng)問(wèn)控制列表 （ACL）

訪(fǎng)問(wèn)控制列表 （ACL） 是一個(gè)表，其中列出了附加到計算資源的權限。它告訴操作系統哪些用戶(hù)可以訪(fǎng)問(wèn)對象，以及他們可以執行哪些操作。每個(gè)用戶(hù)都有一個(gè)條目，該條目鏈接到每個(gè)對象的安全屬性。ACL通常用于傳統的DAC系統。

RBAC vs ACL

對于大多數業(yè)務(wù)應用程序，RBAC 在安全性和管理開(kāi)銷(xiāo)方面優(yōu)于 ACL。ACL 更適合于在單個(gè)用戶(hù)級別實(shí)現安全性以及低級別數據，而 RBAC 則更好地為具有監督管理員的公司范圍的安全系統提供服務(wù)。例如，ACL 可以授予對特定文件的寫(xiě)入訪(fǎng)問(wèn)權限，但它無(wú)法確定用戶(hù)如何更改該文件。

基于屬性的訪(fǎng)問(wèn)控制 （ABAC）

ABAC 評估一組規則和策略，以根據特定屬性（如環(huán)境、系統、對象或用戶(hù)信息）管理訪(fǎng)問(wèn)權限。它應用布爾邏輯，根據對原子或集值屬性及其之間關(guān)系的復雜評估，向用戶(hù)授予或拒絕訪(fǎng)問(wèn)權限。

實(shí)際上，這允許您使用可擴展訪(fǎng)問(wèn)控制標記語(yǔ)言 （XACML） 編寫(xiě)規則，使用鍵值對（如角色=管理器和類(lèi)別=財務(wù)）。

RBAC vs ABAC

雖然 RBAC 依賴(lài)于預定義的角色，但 ABAC 更具動(dòng)態(tài)性，并使用基于關(guān)系的訪(fǎng)問(wèn)控制?？梢允褂?RBAC 通過(guò)寬筆畫(huà)確定訪(fǎng)問(wèn)控制，而 ABAC 則提供更精細的粒度。例如，RBAC 系統向所有經(jīng)理授予訪(fǎng)問(wèn)權限，但 ABAC 策略?xún)H向財務(wù)部門(mén)的經(jīng)理授予訪(fǎng)問(wèn)權限。ABAC 執行更復雜的搜索，這需要更多的處理能力和時(shí)間，因此您應僅在 RBAC 不足時(shí)才求助于 ABAC。

實(shí)現基于角色的訪(fǎng)問(wèn)控制

基于角色的訪(fǎng)問(wèn)控制使組織能夠改善其安全狀況并遵守安全法規。但是，在整個(gè)組織中實(shí)施基于角色的訪(fǎng)問(wèn)控制可能很復雜，并可能導致利益相關(guān)者的阻力。若要成功遷移到 RBAC，應將實(shí)現過(guò)程視為一系列步驟：

• 了解業(yè)務(wù)需求 - 在遷移到 RBAC 之前，應運行全面的需求分析來(lái)檢查工作職能、支持業(yè)務(wù)流程和技術(shù)。您還應考慮任何法規或審核要求，并評估組織的當前安全狀況。您還可以從其他類(lèi)型的訪(fǎng)問(wèn)控制中受益。
• 規劃實(shí)施范圍 - 確定 RBAC 要求的范圍，并規劃實(shí)施以符合組織的需求?？s小范圍，將重點(diǎn)放在存儲敏感數據的系統或應用程序上。這也將幫助您的組織管理過(guò)渡。
• 定義角色 - 一旦您執行了需求分析并了解了個(gè)人如何執行其任務(wù)，定義角色將變得更加容易。請注意常見(jiàn)的角色設計陷阱，例如粒度過(guò)多或不足、角色重疊以及為 RBAC 權限授予過(guò)多的異常。
• 實(shí)現 - 最后階段涉及推出 RBAC。分階段執行此操作，以避免繁重的工作負載并減少對業(yè)務(wù)的中斷。首先，解決核心用戶(hù)組的問(wèn)題。從粗粒度訪(fǎng)問(wèn)控制開(kāi)始，然后再增加粒度。收集用戶(hù)的反饋并監視您的環(huán)境，以規劃下一階段的實(shí)施。

• 上一篇：數據治理包括哪幾個(gè)方面
• 下一篇：選擇 EAM (資產(chǎn)管理系統)時(shí)的 7個(gè)關(guān)鍵因素