[譯] 基於角色的訪問控制（RBAC）：演進歷史、設計理念及簡潔實現（Tailscale, 2021）

語言: CN / TW / HK
時間 2021-09-14 20:55:52
主題:

譯者序

本文翻譯自 2021 年的一篇英文部落格： RBAC like it was meant to be 。

很多系統（例如 Kubernetes ）都在使用某種形式的 RBAC 做許可權/訪問控制。

本文基於 access control 的發展歷史，從設計層面分析了 DAC -> MAC -> RBAC -> ABAC 的演進歷程及各模型的優缺點、適用場景等， 然後從實際需求出發，一步一步地設計出一個實用、簡潔、真正符合 RBAC 理念的訪問控制系統。

由於譯者水平有限，本文不免存在遺漏或錯誤之處。如有疑問，請查閱原文。

以下是譯文。

    • 1.1 DAC（自主訪問控制）：各檔案 owner 自主設定檔案許可權
      • 使用場景：普通使用者的檔案許可權控制
    • 1.2 MAC（強制訪問控制）：（強制由）專門的 admin 設定檔案許可權
      • 設計：DAC 基礎上引入專門的 admin 角色
      • 適用場景：文件/系統訪問控制
    • 1.3 MAC 之雙因素登入（two-factor login as MAC）
    • 1.4 圖片分享：DAC/MAC 模型比較
    • 1.5 MAC 概念：限制太多，又好像沒什麼限制
  • 2 第一次嘗試：基於 RBAC/ABAC
    • 2.1 RBAC（基於角色的訪問控制）
    • 2.2 ABAC（基於屬性的訪問控制）
    • 2.3 也許你從未用過真正的 RBAC
      • Windows 檔案安全模型：每個檔案一個 ACL
    • 2.4 存在的問題：ACL 太多，到處重複，批量修改麻煩
  • 3 第二次嘗試：每個 ACL 對應一個使用者組
    • 3.1 仍以 Windows 檔案系統為例
  • 4 第三次嘗試：重拾被忽視的概念：object tags
    • 4.1 根據 user type 而非 file type 建立 user group
    • 4.2 Roles 去扁平化，增強表達力：將 ACL 定義為一組策略規則
    • 4.3 關於策略規則的進一步解釋
    • 4.6 例子：API 訪問控制
    • 5.1 根據 policy rules 和 user groups 自動生成訪問許可權
    • 5.2 Tags 和 roles 各自的適用場景

大部分人都聽說過 基於角色的訪問控制 （role-based access control, RBAC）以及它 的後繼演進版 基於屬性的訪問控制 （attribute-based access control, ABAC）， 但我們經常 遺忘或不懂得欣賞其中的偉大思想 。

大部分如今 常見的 RBAC 系統都經過了某種程度的簡化 ，因此比最初的設計要弱一些。 而本文想要說明，只要 回到 RBAC 最初的設計 ，我們就能構建一個 真正的 RBAC/ABAC 安全模型 ，它比你能見到的那些系統更 簡單而強大 ，而且不管網路規模大還是小，它都能適用。

客戶經常跟我們反饋說，他們如何震驚於如下事實：在 Tailscale 平臺上， 只用如此少的規則就能表達他們的安全策略 。這並非偶然！ 但在解釋為什麼之前，我們先來回顧一些歷史。

1 從 DAC 到 MAC

RBAC/ABAC 的概念和術語都源自幾十年前的 美國軍方 。 Role-Based Access Controls (Ferraiolo and Kuhn, 1992) 是一篇很好的介紹。下面來看一下它們的一些演進過程。

1.1 DAC（自主訪問控制）：各檔案 owner 自主設定檔案許可權

最早出現的是 DAC（Discretionary Access Control），直到 今天仍然很常見 。

設計

如下圖所示，在 DAC 中 object owner 有權 設定該 object 的訪問許可權 。

DAC：通過授予 individuals/groups 以 read/write/execute 許可權， object (file) 的建立者能完全控制該 object 的內容和許可權。

例如，

  1. 在 Unix 系統中，設定 file permission （“模式”，這也是 chmod change mode 的來歷） 就能授予別人 讀/寫/執行 這個檔案的許可權。
  2. 在 Google Doc 中，點選 share 按鈕能授予許可權。

使用場景：普通使用者的檔案許可權控制

  • 軍方 不怎麼喜歡 DAC，因為這種方式中， 合規性很難保證，機密檔案很容易被惡意 reshare 出去 。
  • 但在 普通使用者 場景中，這種方式還是很常用也很合理的。

1.2 MAC（強制訪問控制）：（強制由）專門的 admin 設定檔案許可權

注意：不要把 MAC (mandatory access control) 與網路術語 “MAC address” 中的 MAC (media access address) 搞混了，二者沒有任何關係，只是碰巧縮寫相同。

設計：DAC 基礎上引入專門的 admin 角色

MAC (Mandatory access control) 對 DAC 做了增強 。如下圖所示， 由 administrator （管理員）或 administrative rule （管理員級別的規則） 來 定義 rules 。

MAC：檔案 owner 只能設定一個檔案 type，這個 type 包含了哪些許可權是由 admin 或 policy 設定的。 使用者能編輯檔案內容，但無法修改檔案許可權。

因此在 MAC 模型中， 一個人做某些事情的 能力是無法再分享給其他人 的，從而避免了檔案被 reshare 的問題。

例子：TCP/UDP 埠號

MAC 很難解釋 ，因為在實際中很少看到它，甚至看到了之後，你都不覺得它是“訪問控制”。

Wikipedia 給了一個很好的例子：TCP 或 UDP 埠號。當你佔用了一個 local port 之後（假設沒設定 SO_REUSEADDR ）， 這臺機器上的其他任何人就都無法再用這個埠號了 —— 不管他們是什麼級別的特權使用者。 這裡， 埠範圍不可重疊這一條件，就是強制性的 （mandatory）。

適用場景：文件/系統訪問控制

之前關於 file locking 的文章中，我討論了 advisory locks 和 mandatory locks 之間的區別：

  • advisory lock： 其他 apps 可以安全地讀 這個檔案；
  • mandatory lock：按照規則，其他 不允許 apps 讀任何內容 。

可以看出，MAC 適用於對 文件或系統的訪問控制 ，這就不難理解為什麼 軍方對 MAC —— 至少在理論上 —— 如此興奮了。理想場景：

  • 一個帶鎖的房間，門口有警衛站崗，
  • 出示門禁卡能進入這個房間，
  • 但警衛 禁止攜帶相機進入房間 。

在這種場景下，你自己有許可權檢視房間內的文件，但無法將其分享給其他人。

這個例子給我們的一個啟示是： 數字系統中，MAC 在理論要比在實際中簡單 （easier in theory than in practice）。

  • 一個功能完整的（full-on）MAC 系統是很難真正實現的。
  • Digital restrictions management (DRM，數字限制管理) 是 MAC 的 一種，在這種模型中，檔案的 接收方無法再將檔案分享給別人 —— 每個 BitTorrent 使用者都能體會到這種方式是如何奏效的。

1.3 MAC 之雙因素登入（two-factor login as MAC）

大家可能沒意識到，另一種 MAC 是 multi-factor authentication ( MFA or 2FA ):

2FA as MAC：密碼可以共享，但硬體 token 不能。密碼是 DAC，而硬體 token 是 MAC。

用 MFA 能允許特定的人登入一臺計算機或服務，如果這個人不是管理員（admin），那他 自己能登入，但將無法進一步將計算機共享給其他人，將密碼告訴他們也不行。

這種 login 是強制性的 （mandatory，單有密碼不行，還必須有硬體 token 才能登入）。 在這個模型中，假設了第二因素（the second factor，即硬體 token）是不可分享的。

1.4 圖片分享：DAC/MAC 模型比較

另一個例子是分享圖片。

  • 在某些服務中，任何有正確 secret URL 的人都能訪問給定的圖片/訊息/檔案，並且 任何有這個 URL 的人都能繼續分享它，這是 DAC 模式 。

  • 在另一些服務中，單有這個 URL 還不行，必須要 登入有許可權檢視這個檔案的賬號之後 ， 才能 reshare： 這 MAC 模式 。雖然某些人能通過特定的 URL 訪問 這個檔案，但 reshre 這個 URL 並不能讓其他人看到這個檔案。

當然，如果一個人能下載這個檔案，然後傳送副本給別人，那結果還是洩露了這個檔案 。這也是為什麼一些人認為 secret URL 的安全性在數學上與 MAC 是等價的，因為現在 分享 URL 已經和分享檔案一樣難了。但二者有一個區別： 你可以關閉一個 URL 的共享，但無法追回一個已經發送出去的檔案副本。

1.5 MAC 概念：限制太多，又好像沒什麼限制

歷史上，軍方中的 MAC 是圍繞 multi-level security 構建的，這裡的 設計思想 是： 並非只有 admin 和 non-admin 兩種使用者，實際上有很多層的訪問 。 他們最初將其設想為同心圓（“最高機密許可”、“機密許可” 等等），但最後證明 表達力太弱（too unexpressive）。

如今的訪問控制更像是 獨立的 flags 或 subgroups 。例如， SELinux 提供了對 每個程序內的每個許可權 的細粒度控制，而傳統 Unix/Linux 上只有 root 和常規使用者許可權的區分。但最終證明 SELinux 這套東西是 噩夢般的複雜 ， 難以真正實用 —— 除非你在 NSA （發明 SELinux 的機構）工作，但即使 你在 NSA 也不一定會用。

最終來說，MAC 的概念證明是 過於限制又過於模糊 （both too restrictive and too vague）。 當人們談論 MAC 時，我們很難搞清楚他們到底指的是什麼，唯一知道是：這東西 用起來非常讓人抓狂 。

2 第一次嘗試：基於 RBAC/ABAC

2.1 RBAC（基於角色的訪問控制）

RBAC 是 MAC 的一個子集 ，它是一種特殊型別的 MAC，更加具體，因此 在討論及使用上會更加方便。

RBAC 與常見的 users/groups 模型類似 。在 RBAC 中，

  • admin 將某些 user 放到一個 group，然後
  • 可以指定將 某些資源 （檔案、計算機等）共享給 某個 group（role） ；
  • 系統確保只有指定的 role 能訪問指定的資源；
  • 檔案的接收方沒有 reshare 許可權 —— 除非拷貝一份，否則是無法 reshare 的。

2.2 ABAC（基於屬性的訪問控制）

Attribute-based access control (Hu, Kuhn, Ferraiolo, 2015) 是 對 RBAC 的改進，加了一些細節 （屬性，Attributes）。

  • 屬性 可以是位置、客戶端裝置平臺、認證型別、使用者的 http cookies 等。
  • 當系統判斷是否授予某個使用者對某資源的訪問許可權時，ABAC 系統 除了檢查他們的 RBAC role（group） ，還會檢查 這個人攜帶的各種屬性 。

如果你遇到過下面這種情況 —— 登入某個服務時彈出額外的 圖片識別認證 reCAPTCHA ， 而你旁邊的朋友登入時卻不用 —— 就 說明你遇到了 ABAC 。

ABAC 很有用 ，因為這些額外的屬效能給我們帶來很多有用資訊，尤其 是對於那些連線到網際網路的、攻擊向量特別多的系統。但在概念上，ABAC 與 RBAC 類似，只是稍微向前演進了一點。 屬性的解析和認證 工作是 中心式的 ，大部分都實現 在各家的 identity provider 中。有鑑於此，接下來我們的討論重點扔將放在 RBAC。

2.3 也許你從未用過真正的 RBAC

RBAC 與前面提到的 users/groups 模型類似。接下來看一個具體的檔案系統安全模型，例如 Windows。

這裡也可以拿 Unix 作為例子，但經典 Unix 檔案安全與常見的安全模型不同， 它只支援單個 owner、單個 group，以及 self/group/other 檔案模式。 如今 Linux 也支援 facls ， 這算是 RBAC，但 沒人知道怎麼用 ，因此這個也不算數。

Windows 檔案安全模型：每個檔案一個 ACL

在 Windows 中，

  1. 每個檔案 （或目錄）都有一個 users 和 groups 列表 ，以及
  2. 每個 列表中的成員可以對這個檔案做什麼操作 。

這是一種訪問控制列表（access control list，ACL）。 owner 設定 ACL，操作系 統執行 ACL。這是 MAC，對吧？

對的 —— 大部分情況下。想一下，任何有檔案讀許可權的人，都可以拷貝一份，然後在副本上 設定許可權，因此這是 某種形式的 DAC ，或者說在執行上充滿漏洞的 MAC。 但 在真實檔案上 （而非 API 上） 執行 MAC 非常難 。 我們將這個難題留給軍方，現在把關注點放在 ACL 語義 上。

在一個 Windows filesystem ACL 中，有如下概念：

  1. User ：在這個檔案上執行操作的使用者。在經典 RBAC 術語中，稱為 subject 。
  2. Group 或 Role ：由管理員定義的一組 user。
  3. File ：需要做訪問控制的資源（ resource ）。也稱為 object 。subject 對 object 進行操作。
  4. Permission 或 Entitlement ： 一條 subject-action-object （使用者-動作-目標檔案） 規則 。 有時會說某個 subject 有 一條 entitlement，或者說某個 object 允許 某個 permission，這兩種表達方式本質上是一樣的，只是從不同的角度描述。
  5. ACL ：一個 entitlements 列表 。

控制誰能訪問哪個檔案

每個檔案都有一個 ACL （permission 列表）。

  • 每個檔案都有一個 ACL。該 ACL 可能從檔案所在子目錄的 ACL中繼承某些 entry，也 可能不會，這些對我們目前的討論來說不重要。
  • ACL 相同的檔案，它們的 ACL 可能在磁碟上是分別儲存的，這些是實現細節，我們這裡 也不關心。

如果想 控制誰能訪問這些檔案 ，可通過以下任一種方式：

  1. 找到 ACL 對應的 groups/roles，在其中新增或刪除 user（稱為修改 group/role 的 membership）；或者，
  2. 直接修改 ACL，新增或刪除 permissions。

如果想 一次修改一組檔案的 ACL ，可以

  1. 修改 group/role membership（簡單），或者
  2. 找到所有相關檔案，逐個修改對應的 ACL（慢且易出錯）。

檔案多了之後，逐個修改 ACL 就不切實際了。

2.4 存在的問題：ACL 太多，到處重複，批量修改麻煩

最後一點，也是訪問控制開始出現漏洞的地方。

  • 幾乎所有系統，不管是不是 RBAC，都支援 尋找檔案系統中的 objects，然後修改它們的 ACL ， 但配套的 object 管理系統可能做的很差。
  • 在分散式系統中，這些 objects 可能分散在世界各地，放在各種不同的儲存系統中，而 它們的共同之處就是 都依賴你的 identity 系統 。
  • 如果某天發現一個 permission 給錯了，就必須找到這個 permission 的所有副本並解 決之，否則就遺留了一個安全問題。但如果 objects 管理系統做得比較糟糕，這裡做起 來就會很麻煩。

3 第二次嘗試：每個 ACL 對應一個使用者組

被以上問題折磨多次之後，你可能會嘗試一些新東西：

  • 將盡量多的資訊從 ACL（分散在各處）中移出 ，
  • 將盡量多的東西移入 user groups（集中式儲存，而且能審計） 。

3.1 仍以 Windows 檔案系統為例

仍然以 Windows 檔案系統為例，如下圖所示，你可能會建立兩個 group report-readers 和 report-writers ：

將盡量多的東西從 ACL 中移出，將盡量多的東西移入 groups 中。

效果是：所有 reports 檔案能被 report-readers 組內的使用者讀，能被 report-writers 組內的使用者寫。

經驗不足的人在這裡會犯的一個錯誤是：只建立一個名為 report 的 group，然後給 予這個 group read/write 許可權。通常來說， 需要檔案讀許可權的使用者，要比需要 寫許可權的使用者更多 。甚至在某些情況下，writer 和 reader 使用者之間都 沒有重疊 （例如審計日誌場景）。

這種 per-file-type group（每種檔案訪問型別一個單獨的 user group）結構是 Don't Repeat Yourself (DRY) 原則在實際應用中的一個例子： 上一節 RBAC/ABAC 模型中，根源問題是 每個檔案都有自己的 ACL ， 這些 ACL 到處重複，因此這裡 提取出了重複部分放到了一個公共的地方 。

3.2 存在的問題

這個改進比較合理，尤其是在有很多 objects 的大公司中工作良好，但也有幾個問題：

  1. 現在 需要有某種形式的 IAM admin 訪問控制 ，也就是對 使用者組的增刪查改 做控制。

    上一節的 RBAC/ABAC 模型中無需這種功能，因為它直接修改檔案的 ACL。IAM admin 管控帶來的一個新問題是：

    • 如果管控太鬆，會導致很多人都有 IAM 的訪問許可權，存在風險；
    • 如果管控太緊，大部分都無權修改 group membership，又會使得這種模型的好處大打折扣。

  2. End users 仍然能四處遊蕩，在需要時 能修改每個 report 檔案的 ACL （“Alice 真的真的需要檢視這個檔案”），破壞了你精心設計的系統 —— 而你自己都 無法察覺 。

  3. 現在需要 為每個 ACL 組合建立一個 user group 。

    最後會發現，公司的每個工程師都屬於 975 個 group，每個 group 都需要定義 read/write 兩種型別。你必須 review 每個 group 的 membership。這種方式雖然比 老的 ad-hoc 檔案許可權方式審計性要好，但也好不了太多。

4 第三次嘗試：重拾被忽視的概念：object tags

至此，我們決定 放棄檔案系統的 ACL ，原因是：檔案系統已經設計成這樣了， 基於檔案系統的 ACL 我們只能做到目前這樣。你大概率無法解決現有的檔案系統和作業系統中這些問題。

但接下來的好訊息是： 如今的服務都執行在無狀態容器內 ， 大部分 VM 都無需密碼就能執行 sudo ， 因此我們不用再對檔案系統進行控制，而是對 web 應用和 NoSQL 的 API 做控制。 這也許不是巧合，因為 對細粒度分散式安全 （fine-grained distributed security） 的需求一直在增長，而檔案系統還停留在 1980s 年代 。

那麼，接下來就開始設計我們想要的 permission 系統！

4.1 根據 user type 而非 file type 建立 user group

首先，注意到，前面兩節的檔案系統 ACL 方案其實 並不是真正意義上基於角色的（role-based）訪問控制 。 為什麼呢？它把 user groups 作為 roles —— 這沒有問題 —— 但如果你有 975 個像 report-readers 和 report-writers 一樣的 group，那這些就不算不上是真正的 human-relevant roles 。HR 並不知道 你的新員工是否應該是 report-reader，這個決策太底層了（low-level）。

因此我們得到的第一個啟示就是：應該根據 使用者型別 （user types）而非 檔案型別 （file types）來建立 user groups。如下圖所示：

4.2 Roles 去扁平化，增強表達力：將 ACL 定義為一組策略規則

以上 group-per-user-type 格式還是 過於扁平 了（too flat）：它已經丟失了 “ 為什麼 某人會在某 group” 的語義含義（semantic meaning）。如果 Bob 離職了，我們必須修改所有可能包含 Bob 的 groups。這雖然已經比跟蹤每個 report 型別的檔案 然後 double check 它的 permissions 是否還正確要好，但仍然 很容易出錯 。

我們假設有如下角色（roles）：Accounting（審計人員）、DevOps（研發運維人員）、Engineering（工程師）、Executive（高管）。

然後我們就可以 將 ACL 定義為一組策略規則 （a set of policy rules）：

這種模型與最初的 flat 模型 表達的東西是一樣的 ，但通過增加一個間接層（indirection）， 它表達了我們 一直想表達（而沒有表達出來）的東西 。有了這個模型， 接下來就可以討論：

  • 由 HR 部門定義的 human-relevant roles，以及
  • 由安全部門定義的標籤（tags），以及
  • 二者是如何聯絡到一起的。

4.3 關於策略規則的進一步解釋

我們正在設計一個新的許可權系統。

現在，先將剛才設計的 能轉換成的 roles 的 policy rules 進一步表示為：

有了這樣一種格式的描述之後，當我們需要滿足 SOC2 合規性要求時，只需將 database 的 readers 改為，例如 [DevOps, Prod] ，這將會立即鎖定所有資料庫相關的物件。

4.4 其他特性

最後，我們來加兩個其他特性：

首先，與檔案只有一種 type（讀或寫）不同，一個物件可以有零或 多個 tags 。 因此，與資料庫相關的原始檔可以打上 database 和 sourcefile 兩個 tag，對應地， 它獲得的是兩種 permission set 的交集 。

第二， 只有 tag 的 owner 有許可權增加或刪除 任何物件上的 該 tag 。 例如在下圖中，只有 Engineering 可以在某個物件打 sourcefile tag。 這能夠避免意外將物件分享給應該完全隔離的人，或在不期望的地方錯誤地應用已有策略。

4.5 MAC 歸來

至此，我們看到了 MAC 迴歸的身影 。但是，現在它，

  1. 不需要一個針對 security policy 的 global admin access control。
  2. 每個 tag owner 能直接對他們的 objects 進行授權，但他們能授予哪些訪問許可權，是 由整體上的安全策略（the overall security policy，即 roles ）控制的。

4.6 例子：API 訪問控制

在類似 Tailscale 的網路系統中，我們其實並不會用 readers和 writers 這樣的檔案系統術語。 我們 定義node 和 port，以及允許誰連線到這些 node 和 port 。 例如可能會如下規則：

有了以上規則，

  1. Engineering 中的任何人都可以啟動一個 dev-api-server node，
  2. 該 node 能接受從任何 dev-api-client node 來的非加密連線（TLS 太難了！開發環境就放行非加密連線吧），但反之並不亦然。
  3. 只有 Ops 中的人能啟動 prod-api-server 和 prod-api-client nodes，它們只處理 https 流量，拒絕非加密 http。

下面是效果：

這裡注意：我們遞迴地用一些 tag names 來定義 permissions for other tags。Ops 中的某個人可以啟動一個 node 並打上 prod-api-server tag， 這個 node 就會獲得與 prod-api-server 而不是 Ops 相關聯的 permissions 和 entitlements（ 這很重要，因為 prod-api-server instance 無法像 Ops 一樣啟動更多 instance）。

真實的 Tailscale ACLs 和 tags 與此很像，但更加具體。

5 職責分離

5.1 根據 policy rules 和 user groups 自動生成訪問許可權

如果試圖將這個模型反向適配到 legacy-style filesystem permissions， 我們就會發現 roles 和 tag definitions 其實是相同型別的物件 （都是 lists of users）， 二者之間通過一個（“安全策略”）演算法進行單向轉換：

將 roles 擴充套件成 tags，然後適配到傳統檔案系統的許可權控制模型。

你可以類似地寫一些指令碼，將給定的 roles 和 group membership rules 自動生成你的 /etc/group 內容 ，我知道有些公司就是這樣做的。 這不是標準方式，維護很痛苦，而且通常用定時任務來批量執行，這意味著當修改 一個 tag 或 group membership 之後，必須要等上一段時間才能生效。但本質上來說，這 種方式是能工作的，而且比典型的作業系統預設值要好多了。

5.2 Tags 和 roles 各自的適用場景

前面說 tags（用於 ACL 目的） 和 roles（用於 user management 目的） 都是“使用者列表”（lists of users），其實這種說法有誤導性。二者用於不同場景。最重要的是， 不同的人 負責系統的不同部分：

  1. Roles 描述的是 identity system (authentication) 中的人 。 Roles 變化很少 ，通常在入職、晉升或轉崗時由 HR 部門設定。
  2. Object types (tags) 由 object owner 在這個 object 建立時設定。
  3. Entitlements 用 (Role, Tag) 描述，由簡單的程式（安全策略）來定義，由 安全團隊設定 。

在這個架構中，這三種類型的人只有很少時候才需要互動：

  1. Accounting 部門中的財報 writer 並不關心誰是 Executive，也不關心 Executive 是否 有權檢視或編輯財報。他們只需知道 要給 report 檔案打上 financial-report tag 。

  2. 安全團隊並不關心哪個檔案打了 financial-report （討論一般情況下），也不關心誰是Executive。 他們需要的是

    • 能讀、寫對應的安全策略，以及確保策略生效 ：
    • 確保 financial-report tag 只能被 Accounting 部門打 ，對應的檔案只能被 Executives 和 Accounting 讀（read only）。
  3. HR 團隊不知道也不關心檔案或安全策略，他們只關心 這周招了一個 Accounting role 的人 。

5.3 小結

回到 network permissions 場景：在大公司中，正確地圍繞這些概念設計你的模型，就能避免大量摩擦。

我們在實際工作中可能會遇到如下類似的例子：工程師建立了一個新的開發（ dev ）集群后， 還要去提個工單，讓安全團隊給他開防火牆埠 。為什麼會這樣？ 因為在這些公司中，安全團隊維護的策略並不規範，沒有收斂到以上模型：

  1. 允許 Engineers 執行 dev API servers，接受來自本機或 dev API clients 的 incoming 連線 —— 這個沒問題；
  2. 通常不允許建立 outgoing connections —— 這個也沒問題；
  3. 噢對了，Carol 的 dev API server 需要主動訪問資料庫伺服器，只能開單獨策略了 —— 問題來了。

如果安全團隊能將這些安全規則固化成程式碼片段，結果將會更好，能確保它們在整張 網路上得到一致執行。

6 結束語

以上提到的所有東西，users、roles、object types、policies 都不是新概念 ， 它們都來自 1992 提出 RBAC 模型的那篇論文，只是術語稍有不同。

如今，幾乎每個人都在使用 users、groups、ACLs 了。一些人認為，我們實現的東西已經 是 RBAC，但事實告訴我們：並不是。 還沒有誰實現過完整的 RBAC 模型 ：

  1. 每個人都是一個 User (subject)。
  2. 每個 user 都有一個或多個 Roles。
  3. 每個 object 都有一個或多個 Tags。
  4. 一條 “security policy” 定義一個 將 (Role, Tag) 轉換成 Entitlements 的 公式 。
  5. 一個執行層（enforcement layer）負責 enforce security policy，併為每個 object 生成有效 entitlements 列表（ACL）。

但另一方面，實現這樣一個模型比實現常見的 users+groups 模型 並沒有複雜多少 —— 只要 從一開始就將其放到系統的核心 。

最後回到文初，這就是為什麼 Tailscale RBAC、ABAC 和 security policy 不同尋常的地方 。 Tailscale objects 都是裝置和埠（devices and ports），而非檔案，但所有概念在使用上與在檔案系統中是一樣的。 最終的產品在 理念設計上很簡潔 ：

  1. Device 或 container 的 owner 可以設定 tag；
  2. 安全團隊決定誰 own 哪些 tag、每個 tag 關聯了哪些 permissions、tags 會授權給哪些 roles；
  3. Identity/HR 團隊決定哪些 users 應該屬於哪些 roles。
「」