使用 RBAC 搭配 ABAC

Important

RBAC 目前已公開預覽。 ABAC 是普遍可用的。 本頁說明兩者如何協同運作。

Unity 目錄中的基於角色的存取控制（RBAC）與 屬性基礎存取控制（ABAC） 是互補的控制，設計上可協同運作。 它們回答了不同的問題：

  • RBAC 控制使用者在會話中扮演 哪個身份 。 使用者扮演角色，會以該角色的權限行事，而非自己權限。 使用 RBAC 讓使用者擁有多個不同的權限集，讓他們明確切換——例如，將存取權限分隔於臨床試驗、專案或敏感度層級。
  • ABAC 控制主動身份可逐列或逐欄看到 的資料 。 政策會透過 受控標籤 附加到資料上，並套用到執行查詢的身份。 使用 ABAC，根據資料屬性在多個資料表間一致地套用過濾或遮蔽。

RBAC 會設定該會話的主動身份，ABAC 則根據該身份評估其政策。 本頁涵蓋該互動在實務中的表現、身份相關 SQL 函式的行為，以及組合使用模式。

身份函數在擔任角色時的行為

Unity 目錄中與身份相關的 SQL 函式是針對會話的主動身份來解析，而非底層的認證使用者。 當使用者承擔角色時，目前的工作階段身分會成為該角色：

功能 當使用者以其使用者身分進行操作時 當使用者擔任角色時
current_user() 回傳使用者的使用者名稱 返回所扮演角色的名稱
is_member(group) 若使用者是群組成員（工作空間本地群組，或分配至工作區的帳號群組），則回傳true 只有當所假設的角色本身是 的true成員時，才會回傳group。 對於基礎使用者所屬但已承擔的角色不屬於的群組，會傳回 false。
is_account_group_member(group) 若使用者是帳號層級群組成員，則回傳true 與 is_member 相同：true 的傳回結果僅根據所承擔角色的群組成員資格，而非基礎使用者的群組成員資格。

參考這些功能的 ABAC 政策會根據 假設的角色來評估，而非使用者。 其預設角色為ABAC政策評估、Unity Catalog補助決議及審計歸屬的主動身份。 因此，承擔角色會改變現有原則與檢視的行為，而這些原則與檢視原本是根據個別使用者身分所建立的。

Note

角色不會自動成為自身的成員。 當使用者採用角色 G 時，current_user() 會傳回 G，但 is_member('G') 和 is_account_group_member('G') 會傳回 false，除非明確將 G 新增為其自身的成員。 若要在政策中比對假設角色，請比對 current_user()，而不要使用 is_member 或 is_account_group_member 來測試成員資格。

常見陷阱：建立在資料列層級的安全視圖上 current_user()

ABAC 與 資料表層級的列篩選 之間常見的一種模式，是透過與 佈建表（也稱為對應表或存取控制清單）進行連接來篩選資料列，而該表是以 current_user() 傳回的使用者名稱作為鍵。 例如：

CREATE OR REPLACE FUNCTION facility_filter(facility_id STRING)
RETURN EXISTS (
  SELECT 1
  FROM governance.user_facility_provisioning p
  WHERE p.user = current_user()
    AND p.facility_id = facility_id
);

當同一個使用者接任角色時， current_user() 就不再回傳他們的使用者名稱。 它會回傳角色名稱。 由於該角色不在配置表中，過濾器不會回傳任何列，使用者似乎失去了對他們被授權資料的存取權。

將角色加入配置表

將角色視為配置資料中的另一個主體：每個角色插入一列，列出該角色應該看到的功能（或其他屬性）。 篩選器接著會比對主動身份是使用者還是假定的角色。

複合用途模式

以下是客戶如何結合 RBAC 與 ABAC 來解決實際存取控制問題的範例。 這些只是起點，不是完整的食譜。

以假設的角色為依據的各專案資料列篩選器

按專案篩選資料列，是臨床試驗研究、合約行銷、客戶顧問服務，以及其他由同一團隊同時處理多個彼此獨立專案的情境中的常見需求。 以下範例使用臨床試驗，但此模式可推廣至任何專案資料隔離。

臨床研究組織同時執行多項試驗，而每項試驗各自使用不同的存取角色。 為每個資料表標註專案識別碼。 使用者僅會看到其目前所承擔角色對應之專案的資料列。

設定：

  • clinical_trials.* 下方的表格有一個 project_id 欄，且該欄已使用 governed tag 鍵 project 加上標記。
  • 每個專案都有對應的存取權角色，名為 role-<project> （例如， role-alpha， role-beta）。
  • 使用者只能對他們所參與專案的角色擁有「假設權限」。

列濾波器 UDF：

CREATE FUNCTION project_match(project_id STRING) RETURNS BOOLEAN
DETERMINISTIC
RETURN current_user() = CONCAT('role-', project_id);

政策：

CREATE POLICY per_project_row_filter
ON CATALOG clinical_trials
ROW FILTER project_match
TO `account users`
FOR TABLES
MATCH COLUMNS has_tag('project') AS project
USING COLUMNS (project);

這個 UDF 會將主動身份與每列的 project 標籤值相關聯，因此主體目標子句 TO / EXCEPT 無法表達——這些目標是主體，而非列內容。 正如 主體目標指引 所解釋的，對於像這樣單一規則同時依賴主動身份與列內容的情況，UDF 內的簡單主控範圍與保留身份函式，優先使用 TO / EXCEPT 。

單一政策涵蓋所有專案： USING COLUMNS (project) 將每列的 project 標籤值傳入 UDF，因此不需要每個專案獨立的政策。 關於此技術的一般形式——從查找表驅動列存取而非角色名稱匹配——請參見 使用映射表進行動態存取控制。

態度：

  • 使用者以其使用者身分執行時，在任何 clinical_trials 資料表中都看不到任何資料列。 current_user() 回傳他們的用戶名，但這個名稱完全不符合 role-* 命名模式。 這就是預期的預設否認。
  • 假設為 role-alpha 的使用者，只會看到 project_id 等於 alpha 的資料列。 切換到 role-beta 會切換顯示的資料，而不必重新查詢其他任何資料。

針對扮演指定角色的使用者放寬個人身份資訊掩蔽

預設情況下，PII 欄位（社會安全號碼、電子郵件、電話）對所有人都顯示為遮蔽狀態。 若要查看原始值，使用者必須明確地承擔已獲准存取 PII 的指定角色。 稽核日誌會記錄角色切換事件，因此「我需要查看真實的個人識別資訊」會變成可稽核的主動啟用，而不是一種預設權限。

設定：

  • 敏感欄位會使用 governed tag 索引鍵 pii 進行標記（允許的值包括 ssn、email、phone）。
  • 一個名為 role-pii-cleared 的存取角色，其 Assume 權限會授予給已獲准檢視原始個人資訊（PII）的使用者。

欄位遮罩 UDF（靜態——政策指定要遮蔽哪些主體）：

CREATE FUNCTION mask_pii(val STRING) RETURNS STRING
DETERMINISTIC
RETURN '***';

政策：

CREATE POLICY pii_default_mask
ON CATALOG customer_data
COLUMN MASK mask_pii
TO `account users`
EXCEPT `role-pii-cleared`
FOR TABLES
MATCH COLUMNS has_tag('pii') AS pii_col
ON COLUMN pii_col;

EXCEPT 條款會將 role-pii-cleared 完全排除在原則之外，因此當該角色是作用中的身分時，系統永遠不會呼叫 UDF。 如需透過 TO / EXCEPT 進行主體目標指定的一般指引，請參閱 主體目標指定請優先使用 TO/EXCEPT。

態度：

  • 以自身使用者身分執行操作的使用者，會在每個 PII 欄位中看到 ***。 這是所有人的預設狀態，包括對 role-pii-cleared 具有 Assume 權限的使用者。
  • 假設 role-pii-cleared後，該政策不再適用於該會話，且同一位使用者會看到原始值。
  • 會話記錄 identity_metadata.run_as = role-pii-cleared的審計日誌條目，讓審查者能精確看到個人識別資訊何時被揭露，以及由誰揭露。

依假設角色而異的敏感層級政策

資料被分類為敏感度層級（internal， confidential， restricted）。 每個層級都有對應的存取角色，其中 restricted 表示也同時擁有 confidential 和 internal 的存取權限。 單一資料列過濾 UDF 會透過比較每一資料列的層級與使用者所採用的角色，來控制資料列的可見性。

設定：

  • 資料表有一sensitivity_level欄標註有受控標籤鍵sensitivity（允許的值：internal， ， confidentialrestricted）。
  • 三個存取角色：role-sens-internal、、role-sens-confidentialrole-sens-restricted。

列濾波器 UDF：

CREATE FUNCTION sensitivity_allowed(row_sensitivity STRING) RETURNS BOOLEAN
DETERMINISTIC
RETURN CASE
  WHEN current_user() = 'role-sens-restricted' THEN TRUE
  WHEN current_user() = 'role-sens-confidential' THEN row_sensitivity IN ('internal', 'confidential')
  WHEN current_user() = 'role-sens-internal' THEN row_sensitivity = 'internal'
  ELSE FALSE
END;

政策：

CREATE POLICY sensitivity_filter
ON CATALOG corp_data
ROW FILTER sensitivity_allowed
TO `account users`
FOR TABLES
MATCH COLUMNS has_tag('sensitivity') AS sens
USING COLUMNS (sens);

由於角色不是其自身的成員，因此此 UDF 會將 current_user() 與每個角色名稱逐一比較，而不是使用 is_account_group_member() 來測試成員資格。 請參見 上方說明 ，說明為何會員測驗與假定角色不符。 關於 UDF 中身份函數的效能特性，請參見「 列過濾器與欄位遮罩策略的效能考量 」。

態度：

  • 以使用者身份行事的使用者不會看到 任何列。 這個 ELSE FALSE 分支與非三個角色中的任何職務相符。 如同上述按專案設定的範例，這就是預期的預設拒絕行為。
  • 假設 role-sens-internal 只顯示 internal 列。
  • 假設 role-sens-confidential 會顯示 internal 和 confidential 列。
  • 假設 role-sens-restricted 顯示所有列。

使用者假設該會話所需的最高層級;過濾器會自動排除該層以上的所有資料，且使用者不必知道哪些表包含哪些分類。

審計歸因

ABAC 的政策評估及其底層查詢均尊重 RBAC run_as / run_by 歸屬。 審計日誌記錄會記錄 identity_metadata.run_by 為驗證使用者及 identity_metadata.run_as 假定角色，無論評估時採用哪種 ABAC 政策。 完整審計日誌結構請參閱 稽核日誌系統表參考 。

下一步

  • 模型專用存取：套用模式來設定專用存取，方法是使用帳戶本機群組，或使用從 Microsoft Entra ID 同步的群組。 請參閱 Model 獨家存取權。
  • 切換角色：使用角色切換器、專用存取模式叢集、CLI、API 或第三方 BI 工具扮演角色。 請參見 「切換角色」。
  • 管理 承擔權限：授予或撤銷群組的 Assume 權限，讓使用者能擔任相應角色。 請參見 「管理群組權限」。
  • 複習 ABAC 核心概念：了解受規範標籤、政策與政策評估的運作方式。 請參閱 Unity 目錄中的屬性基礎存取控制。
  • Last updated on