資料來源和工作簿的 RLS 最佳做法


Tableau 中的資料列層級安全性 (RLS) 可限制特定使用者可以在工作簿中查看的資料列。這與 Tableau 權限不同，後者可控制對內容和功能的存取。例如，權限可控制使用者是否可以對工作簿新增註解或編輯工作簿，而資料列層級安全性則可讓檢視相同儀表板的兩位使用者只能查看允許他們查看的資料。

在 Tableau 中實作 RLS 有多種方法。例如，可以在資料來源或工作簿層級設定 RLS，或者可以使用具有資料原則的虛擬連線在連線層級設定 RLS（需要 資料管理）。有關備選方案的詳細資訊，請參閱 Tableau 中的列層級安全性選項概觀。

附註：本主題重點介紹資料來源和工作簿的 RLS 最佳做法。有關本主題中概述的概念之更多深入範例，請參閱 Tableau and Behold 部落格中的運用權利表的列層級安全性最佳作法(連結在新視窗開啟)白皮書，或是如何針對 Tableau 中的資料列層級安全性設定資料庫(連結在新視窗開啟)。

RLS 工作流程

對於即時連線和多表資料擷取，基本的 RLS 工作流程是：

  1. 藉由登入 Tableau Server 或 Tableau Cloud 來識別使用者
    • 這需要每位使用者都採用不重複的使用者名稱，以及安全的單一登入 (SSO)
    • Active Directory、LDAP 或 Tableau REST API 可用於同步使用者名稱以及建立權限
  2. 從所有可能的資料權利中擷取使用者的資料權利的集合
    • 這需可以將權利連結至 Tableau 使用者名稱的資料結構
  3. 資料是按照該使用者的權利進行篩選
    • 這通常需要在導出欄位中運用使用者函數
  4. 已發佈、篩選的資料是用於建立內容
    • 使用具有資料來源篩選條件的已發佈（而不是嵌入的）資料來源，可確保無法藉由下載或 Web 編輯工作簿的方式來修改 RLS

聯結、導出欄位和篩選條件的設定方式，取決於資料的結構以及管理使用者的方式。

權利表

可以篩選資料的任何唯一屬性組合都是一項權利。最常見的情況是，有單獨的表用於指定權利本身，並將此等權利對應至使用者或使用者角色。從效能的觀點來看，由於聯結作業成本高昂，因此建議取消正規化。

權利檢視（包括對應至使用者或角色的權利）與資料聯結。然後套用以使用者為基礎的的資料來源篩選條件，其作用如同 WHERE 子句，僅在於為相關使用者導入權利，從而導入適當的資料列。（查詢最佳化應確保在聯結處理查詢之前進行篩選，以儘量減少資料重複。請參閱作業的效能和處理順序以瞭解詳情)。

授權表模式

通常，表示權利有兩種模式：

充分對應至最深層的粒度

  • 針對每個欄充分定義權利。
  • 對應表中有一列適用於使用者具有的每一項可能的權利。
  • 此模式需要較少的聯結子句。

稀疏權利

  • 針對階層的每個層級定義權利，並使用 NULL 來表示「全部」狀態。
  • 權利階層的特定層級在對應表中各有一列，因此大幅減少了階層中高階使用者的權利列的數量。
  • 此模式需要更複雜的聯結和篩選條件。

使用者和角色

權利組合通常以角色表示，然後連結至多對多對應表中的使用者。這可讓使用者輕鬆地進行變更或從角色中刪除使用者，同時仍保留角色及其權利的記錄。

或者，使用者也可以建立多對多對應表，將使用者直接指派至權利，而不是透過加入角色表達到目的。這將需要以更直接的方式來管理表中的值，不過確實消除了聯結。

附註：與角色或權利關聯的使用者值需要與 Tableau 網站上的使用者名稱或全名相符，方可使用 Tableau Desktop 中的使用者函數。

聯結

無論用於表示權利的模式如何，建議將權利聯結起來，並將表對應至單一非正規化的權利檢視。起初，這將導致權利版本的「爆發」（高度重複），但使用者的資料來源篩選條件將減少其數量。如果計畫使用擷取，則您還需要此檢視。

若一切都屬於階層式，則最深層的粒度方法便具有效能優勢；您只需在階層的最深層級執行單一聯結即可。這只有在最低層級的所有屬性都各不相同時才有效。如果存在重複的機會（例如，多個區域中的中央子區域），則需要聯結所有欄，以實現不同機碼值的效果。

實際的詳細資訊及其效能特徵取決於資料系統，並且需要進行測試。例如，使用單一機碼或許可能會提高效能，因為聯結僅在一欄上執行；但在考慮其他因素時，正確地為所有列編制索引可能會提供相同的效能。

實作資料列層級安全性

最深層的粒度

建立對應的權利之非正規化檢視後，在 Tableau 資料連線對話方塊中的內部連結就會在檢視與資料間建立。資料可以保留在傳統的星型結構描述中。或者，維度表和事實資料表可以一併在兩個檢視中實現。多表資料擷取將建立擷取表以配合聯結，因此建立兩個檢視將簡化所產生的擷取。SQL 將遵循以下基本模式：

SELECT * 
FROM data d INNER JOIN entitlements e ON
d.attribute_a = e.attribute_a AND 
d.attribute_b = e.attribute_b AND ... 
WHERE e.username = USERNAME()

稀疏權利

如果您的權利更類似於稀疏授權模式，則由於 Null 值的緣故，將資料聯結至權利的自訂 SQL 將稍微複雜一些。就概念而言，這類似於以下方式： 

SELECT *
FROM data d 
INNER JOIN entitlements e ON
(e.region_id = d.region_id OR ISNULL(e.region_id) AND
(e.sub_region_id = d.sub_region_id OR ISNULL(e.sub_region_id) AND
(e.country_id = d.country_id OR ISNULL(e.country_id)

無需使用自訂 SQL，即可在 Tableau Desktop 中使用交叉聯結和其他篩選條件來完成此操作。在聯結對話方塊的兩側建立聯結計算，該計算僅由整數 1 組成，並將其設定為相等。這將資料表中的每一列與權利表中的每一列聯結。

然後，您需要計算（或個別計算），以便將階層中的層級納入考量。例如，您可以進行採用以下格式的幾種計算：[region_id] = [region_id (Entitlements View)] OR ISNULL([region_id (Entitlements View)]

或者，您可以各種層級的計算合併成單一計算：

([region_id] = [region_id (Entitlements View)] OR ISNULL([region_id (Entitlements View)])
AND
([sub_region_id] = [sub_region_id (Entitlements View)] OR ISNULL([sub_region_id (Entitlements View)])
AND
([country_id] = [country_id (Entitlements View)] OR ISNULL([country_id (Entitlements View)])

ISNULL 函數會將任何權利欄與其他欄中的所有項目進行比對。一如既往使用 RLS 的方式，這些計算應新增為資料來源篩選條件。

資料來源篩選條件

對於這兩種方法，一旦權利與資料正確聯結，就需要設定篩選條件以限制特定使用者的資料。應藉由使用者函數建立導出欄位。例如，對使用者名稱欄位中列出的使用者是否與登入 Tableau 網站之人員的使用者名進行簡單的布林比較：[Username] = USERNAME()

此計算應用作資料來源篩選條件（選取 TRUE）。

如果資料來源已嵌入，並且使用者具有 Web 編輯或下載工作簿的權限，則 RLS 不存在，因為強制執行該資料來源的篩選條件可以輕鬆刪除。Tableau 資料來源應單獨發佈，而不是嵌入工作簿中。

具有最深層粒度的所有存取

還有一種常見情況，即組織內有兩個存取層級：能夠查看所有內容（「所有存取」）的人員或具有某種可合理定義的權利子集的人員。這種情況在嵌入式應用程式中最為常見 — 託管資料的組織可以檢視所有內容，但每個用戶端只能檢視自己的資料。在這種情況下，您需要一種方法來傳回「所有存取」使用者的完整資料，同時為所有其他使用者保留最深層的粒度聯結。

對於此技巧，您將使用 Tableau 群組運用聯結條件中的計算來建立覆寫。

  1. 為應檢視所有資料的使用者建立群組（此處稱為「所有存取」） 
  2. 透過事實檢視建立具有兩個聯結條件的左側聯結
    • 第一個聯結條件應位於表示最深層粒度的欄
    • 第二個聯結條件應為兩個計算：
      • 在左側（事實檢視），針對計算，輸入 True
      • 在右側（權利檢視），計算應為：IF ISMEMBEROF('All Access') THEN False ELSE True END
  3. 在工作表上，按照以下方式建立一個計算結構：[Username] = USERNAME() OR ISMEMBEROF(['All Access'] ([Entitlements View)])
  4. 在使用者名稱計算上建立資料來源篩選條件

如果使用者是「所有存取」群組的成員，則聯結將成為 True = False 上的左側聯結。這表示權利檢視中根本沒有相符的項目，因此整個事實檢視將針對權利檢視的欄（零重複）傳回 NULL。如果使用者不是「所有存取」群組的成員，則 True = True 聯結條件不會變更任何內容，並且聯結將按預期的方式正常運作。

當群組複寫正常運作時，用作資料來源篩選條件的使用者計算對所有列皆為 True，否則使用者計算會僅篩選到階層中使用者的最深粒度。

作業的效能和處理順序

在 Tableau Desktop、Tableau Server 或 Tableau Cloud 中檢視視覺化效果時，Tableau 會向 RDBMS 發送最佳化的查詢，然後 RDBMS 會處理查詢並將結果傳送回 Tableau，以藉由結果資料呈現視覺化效果。執行聯結、計算和篩選條件的作業順序取決於查詢最佳化工具以及執行查詢的方式。

即時連線

在 Tableau 中使用資料來源的即時連線時，查詢執行的效能取決於查詢最佳化工具，該最佳化工具會將傳入的 SQL 轉譯為檢索資料的有效方案。

處理查詢的方法有兩種：

  1. 將權利列篩選至使用者，然後加入事實資料表
  2. 將權利加入事實資料表，然後篩選至使用者的列

在理想情況下，查詢最佳化工具將確保資料庫藉由篩選然後聯結的方式來處理查詢。如果使用者擁有一切權利，即表示所處理的最大列數將是資料表中的列數。

如果資料庫藉由聯結然後篩選的方式來處理查詢，則資料可能會重複。所處理的最大列數就是資料表中使用者有權檢視之每列的特定列的次數。

很明顯，如果是第二種情況：您的查詢就需要很長的時間才能完成，您會因此收到錯誤訊息，或者資料庫中會出現效能問題的跡象。您的資料總量將以指數方式大幅增加，這可能導致後端系統負荷過度緊俏。

擷取

若 Tableau 中的資料來源是即時連線，Tableau 會向 RDBMS 傳送呈現特定視覺效果或儀表板窗格所需的每個查詢。若資料來源是擷取，從基礎資料來源查詢資料的過程，僅會在資料擷取建立和重新整理時發生。所有視覺化的個別查詢都由擷取檔中的擷取引擎回答。

建立單一表擷取時現相同的操作順序問題。但是，「爆發」將發生在基礎資料來源以及所產生的資料擷取本身中。

擷取的注意事項

從 Tableau 2018.3 開始，資料引擎可以建立多表擷取，並且可以如上所述實作 RLS。使用多表擷取減少了產生具有多對多關係的擷取所需的時間，因為它並未實現聯結。

資料擷取應藉由資料物件與權利物件來建立。這是資料擷取中最簡單的儲存，可實現最佳效能。

  • 資料物件屬於表、檢視或自訂 SQL 查詢，代表事實資料表和必要維度表的非正規化組合
  • 權利物件是非正規化的表、檢視或自訂 SQL 查詢，是將資料按照最精細的層級進行篩選所需的任何權利，這需要：
    • 與 Tableau Server 或 Tableau Cloud 中的確切使用者名相符的使用者名稱欄
    • 資料物件每個最精細之權利的列

此格式以上述最深層粒度方式佈局。多表擷取使用相同的方法，唯需符合以下條件：在物件中僅聯結兩個資料物件，並且已套用任何欄位專用的篩選條件。

由於多表擷取停用了擷取篩選條件，因此您可以在資料來源中連接的檢視或表中進行篩選，或在 Tableau 資料連線對話方塊中定義自訂 SQL 物件中的篩選條件。

附註：如同使用即時連線一樣，如果資料來源已嵌入，並且使用者具有 Web 編輯或下載工作簿的權限，則 RLS 不存在，因為強制執行該資料來源的篩選條件可以輕鬆刪除。資料擷取應單獨發佈，而不是嵌入工作簿中。

單一表格擷取

唯有在使用 2018.3 之前的 Tableau 版本時，才建議使用以下方法：若是可以，則最好使用多表擷取。

單表擷取會在建構 Tableau 資料來源並將一切內容透過單一查詢儲存起來時，實現您建立的任何聯結，其結果會在擷取檔的單一表中進行轉換。這種非正規化有造成大量資料重複的風險，因為分配給多項權利或多位使用者的每一列都會由於多對多關係而重複。

若要防止這種重複：

  1. 請建立針對該權利建立包含使用者名稱的安全使用者欄位
    • 例如，值可以是 “bhowell|mosterheld|rdugger”
  2. 使用 Tableau 中的 CONTAINS() 函數正確識別個別使用者
    • 例如，CONTAINS([Security Users Field], USERNAME())

這種方法顯然有一些條件限制。這需要您從列的權利移至使用 SQL 正確分隔的單一欄，並且該欄只能包含這麼多字元。部分相符可能會有問題，您需要使用分隔符號，而這些分隔符號在 ID 本身中，始終是無效的。儘管這種方式在 Tableau Data Engine 中仍屬有效能的作法，但作為字串計算，對於大多數資料庫來說，速度會很慢。這將限制您切換回即時連線的能力。

或者，您可以根據「角色」或權利層級採用不同的擷取，以便擷取中僅包含適合該人員或層級的資料，不過，在 Tableau Server 中，這需要程序以適當的權限和利用範本發佈，通常通過 API 進行。

在資料庫中使用內建的資料列層級安全性

許多資料庫都有內建的 RLS 機制。若您的組織已著手在資料庫中建立資料列層級安全性，您或許能夠利用現有的 RLS。與使用 Tableau 組建內建 RLS 模型的想法相比，實作一個內建 RLS 模型不一定會更輕鬆或更好；當組織已經對這些技術進行投資並且想利用這些投資時，通常會利用這些技術。使用內建 RLS 的主要優點是管理員可在單一位置（即其資料庫中）實作和控制其資料安全性原則。有關詳細資訊，請參閱資料庫中的資料列層級安全性。

返回頂端
感謝您的意見反應！已成功提交您的意見回饋。謝謝！