基於角色的訪問控制RBAC是什麼？ - Tailscale

banq發表於2021-09-03
AI

我們大多數人都聽說過基於角色的訪問控制 (RBAC) 及其稍微更新的後繼者，基於屬性的訪問控制 (ABAC)。但我們並不總是欣賞它們包含的所有偉大想法。
當今最常見的“RBAC”系統已被精簡，使其比原始概念弱得多。透過回到最初，我們可以構建一個真正的 RBAC/ABAC 安全模型，它比您之前可能看到的更簡單、更強大，適用於非常小的和非常大的網路。
使用者、角色、物件型別和策略都是 1992 年向世界介紹 RBAC 的論文中的所有內容，儘管使用了不同的術語。
幾乎每個人都已經在使用使用者、組和 ACL。許多人認為他們已經完成並稱其為 RBAC，但事實並非如此。幾乎沒有實現完整的 RBAC 模型：
  • 每個人都是一個使用者（主體）。
  • 每個使用者都有一個或多個角色。
  • 每個物件都有一個或多個標籤。
  • “安全策略”定義了從（角色、標籤）轉換為權利的公式。
  • 執行層編譯​​安全策略併為每個物件生成有效的權利列表 (ACL)。

這個模型其實並不比普通使用者+組模型更難構建……只要我們從一開始就在系統的核心中進行構建。
我們的Tailscale系統管理的物件是裝置和埠而不是檔案，但所有概念的應用方式與它們在檔案系統中的應用方式相同。結果是一種看似簡潔的設計：裝置或容器所有者可以在其中應用標籤；安全團隊可以決定誰擁有哪些標籤以及該標籤授予哪些角色哪些許可權；身份/人力資源團隊可以決定哪些使用者擔任哪些角色。
 

Windows的RBAC系統
讓我們看看一個簡單的檔案系統安全模型，比如在 Windows 上：在 Windows 上，每個檔案（或目錄）都有一個使用者和組列表，以及每個使用者和組可以對該檔案執行的操作。這是一個訪問控制列表 (ACL)。所有者設定 ACL，然後作業系統強制執行它。
在 Windows 檔案系統 ACL 中，您有：

  • 使用者：對檔案進行操作的人。在古老的 RBAC 術語中，使用者被稱為“主體”。
  • 組或角色：管理定義的使用者集合。
  • 檔案：被控制的資源。（也稱為“客體”，就像在語法中一樣。主體作用於客體。）
  • 許可或權利：主體-動作-客體規則。有時我們認為主體“擁有”權利或物件“允許”許可，但從兩個不同的角度來看，這是同一回事。
  • ACL：權利列表。

每個檔案都有一個 ACL（許可權列表）。ACL 可能會從它所在的子目錄的 ACL 繼承一些條目，或者不是，但這現在並不重要。
具有相同 ACL 的檔案可能會在磁碟上對其 ACL 進行重複資料刪除，但這是一個實現細節。
重要的是，每個檔案都有一個 ACL。如果您想更改誰可以訪問該檔案，您必須：
  • 更改 ACL 中組（角色）之一的成員資格；或者
  • 更改 ACL 以新增或刪除許可權。

如果您想一次更改一堆檔案的 ACL，您可以更改組/角色成員資格（簡單），或查詢所有相關檔案併為每個檔案更改 ACL（緩慢且容易出錯）。
幾乎您使用過的每個系統，無論是否使用 RBAC，都可以讓您找到所有有趣的物件並更改它們的 ACL。而且您可能沒有仔細跟蹤所有這些物件。在分散式系統中，這些物件可能遍佈世界各地，儲存在許多不同型別的儲存系統中，都依賴於您的身份系統，如果您意識到給定的許可權是錯誤的，您必須查詢該許可權的每個副本許可並修復每個，否則您會遇到安全問題。
 

RBAC的前世今生：DAC與MAC
RBAC 和 ABAC 的概念和術語起源於幾十年前的美國軍隊。基於角色的訪問控制（Ferraiolo 和 Kuhn，1992 年）是一個很好的介紹。
我從來沒有當過兵，而且在 1992 年我對訪問控制一無所知，但這裡似乎已經發生了變化。
首先是自主訪問控制 (DAC)，這在今天仍然很常見。使用 DAC，物件的所有者可以為其授予許可權。
因此，如果您在 Unix 中擁有一個檔案，您可以設定檔案許可權（“模式”，因此chmod是“更改模式”）以授予其他人對其的讀、寫或執行訪問許可權。或者，如果您擁有 Google 文件，則可以按共享按鈕並授予訪問許可權，等等。
軍人不太喜歡 DAC，因為超級機密的東西很容易以不符合政策的方式被轉發。但這在普通人中仍然很常見，也很合理。
強制訪問控制 (MAC) 加強了這一點。MAC 很難解釋，因為你不經常看到它。當您這樣做時，您可能不會將其視為“訪問控制”。

[注意：不要將 MAC（強制訪問控制）與網路中使用的“MAC 地址”（媒體訪問控制器地址）混淆。他們沒有關係。]
MAC 是某個管理員或管理規則在某處定義規則。有了 MAC，您做某事的能力不會讓您與他人分享這種能力。
維基百科給出了一個很好的例子：TCP 和 UDP 埠號。如果您繫結到一個本地埠（大概沒有SO_REUSEADDR），則該機器上的其他任何人都不能使用同一埠，無論他們有多特權。埠的非重疊要求是“強制性的”。
在控制對文件或系統的訪問時，您可以看到為什麼軍方對 MAC 感到興奮……理論上。夢想是能夠製作一份“只為您的眼睛”的文件，並防止任何其他眼睛閱讀它，即使您的眼睛想要分享。想象一下一個鎖著的房間，前面有一個保安，你只有出示你的徽章才能進入房間，而警衛阻止你帶相機進來。您可以訪問聊天室中的文件，但無法共享它們。
這個例子應該給我們一個線索，即數字系統中的 MAC 在理論上比在實踐中更容易。一個完整的 MAC 系統很難實際執行。數字限制管理 (DRM) 是一種 MAC，據稱檔案的接收者無法進一步共享它，每個 BitTorrent 使用者都知道它在現實生活中的效果如何。
 非常傳統地，軍隊中的 MAC 是圍繞“多級安全性”構建的，即不僅僅是管理員和非管理員使用者，還可以有不同級別的訪問許可權。他們最初把這個想象成同心圓（“絕密通關”vs“秘密通關”等等），但結果證明這太沒有表現力了。
如今，訪問控制通常更像是單獨的標誌或子組。例如，與舊式“root”與常規使用者許可權相比，SELinux可讓您對每個程式中的每個許可權進行細粒度控制。事實證明，除非您是 NSA（編寫 SELinux），否則實際使用起來會非常複雜。也許即使你是。
總的來說，MAC 概念既過於嚴格又過於模糊。很難確切地知道人們在談論強制訪問控制時指的是什麼，除了一個常數：可以預見的是，它使用起來很煩人。
 

RBAC 和 ABAC
RBAC 是 MAC 的子集。它是一種特殊型別的 MAC，但它更具體，因此更易於討論和使用。
它開始類似於您在許多地方看到的“使用者和組”模型。使用 RBAC，一些管理員將使用者放入組中，其他人可以與組（角色）共享資源（檔案、計算機等），系統會強制這些角色中的哪些角色可以訪問資源。共享的接收者不一定有權重新共享，至少在不製作新副本的情況下不會。

基於屬性的訪問控制（Hu、Kuhn 和 Ferraiolo，2015 年）是對 RBAC 的進一步改進，增加了更多細節。“屬性”可以包括給定使用者的位置、客戶端裝置平臺、身份驗證型別或 http cookie 等內容。當系統決定是否授予使用者訪問資源的許可權時，ABAC 系統不僅會檢查他們的 RBAC 角色（組），還會檢查此人可能具有的各種其他屬性。
如果您在登入服務時遭遇reCAPTCHA驗證，而您旁邊的朋友卻沒有，那麼您就遇到了 ABAC。
ABAC 很有用，您幾乎總是希望使用其中的一些額外屬性，尤其是在具有大量攻擊向量的 Internet 連線系統中。但從概念上講，ABAC 就像一個稍微複雜的 RBAC，並且屬性部分主要在您的身份提供者中集中實現，所以讓我們不管它並堅持使用 RBAC 進行討論。
 
更詳細點選標題
 

相關文章