限制對 Power BI 模型資料的存取

  • 14 分鐘

身為資料建模者，您可以藉由建立一或多個角色來設定 RLS。 角色在模型中具有唯一的名稱，而且通常包含一或多個規則。 規則會使用資料分析運算式 (DAX) 篩選運算式，對模型資料表強制執行篩選。

注意

依預設，資料模型沒有角色。 沒有角色的資料模型表示使用者 (有權查詢資料模型的使用者) 可以存取所有模型資料。

提示

可以定義不含規則的角色。 在此情況下，角色會提供所有模型資料表所有資料列的存取權。 此角色設定適用於允許檢視所有資料的管理使用者。

您可以在 Power BI Desktop 中建立、驗證和管理角色。 針對 Azure Analysis Services 或 SQL Server Analysis Services 模型，您可以使用 SQL Server Data Tools (SSDT) 建立、驗證及管理角色。

您也可以使用 SQL Server Management Studio (SSMS) 或使用協力廠商工具來建立和管理角色，例如表格式編輯器 (英文)。

若要深入了解 RLS 如何限制資料存取，請觀看下列動畫影像。

Animated diagram demonstrates how row-level security works for two users who each have access to specific country data.

套用星型結構描述設計準則

建議您套用星型結構描述設計準則，以產生包含維度和事實資料表的模型。 設定 Power BI 來強制執行篩選維度資料表的規則是很常見的，這可讓模型關聯性 (部分機器翻譯) 有效率地將這些篩選條件傳播到事實資料表。

下圖是 Adventure Works 銷售分析資料模型的模型圖表。 這會顯示星型結構描述設計，其中包含名為 Sales 的單一事實資料表。 其他資料表是維度資料表，可支援依日期、銷售領域、客戶、轉銷商、訂單、產品和銷售人員來分析銷售量值。 請注意連線所有資料表的模型關聯性。 這些關聯性會將篩選 (直接或間接) 傳播至 Sales 資料表。

Screenshot shows a Power B I Desktop model diagram comprising the tables and relationships as described in the previous paragraph.

此模型設計支援本單元中呈現的範例。

定義規則

規則運算式會在資料列內容中進行評估。 資料列內容代表會使用該資料列的資料行值來評估每個資料列的運算式。 當運算式傳回 TRUE 時，使用者可以「看見」資料列。

提示

若要深入瞭解資料列內容，請詳讀將計算的資料表和資料行新增至 Power BI Desktop 模型模組。 雖然此課程模組描述新增模型計算，但其中包含介紹和描述資料列內容的單元。

您可以定義靜態或動態的規則。

靜態規則

靜態規則會使用參考常數的 DAX 運算式。

請考慮以下套用至 [區域] 資料表的規則，其限制對中西部銷售的資料存取。


'Region'[Region] = "Midwest"

下列步驟說明 Power BI 如何強制執行規則。 這麼做可：

  1. 篩選 [區域] 資料表，產生一個可見的資料列 (中西部)。

  2. 使用模型關聯性將 [區域] 資料表篩選傳播至 [州別] 資料表，產生 14 個可見的資料列 (中西部區域包括 14 個州)。

  3. 使用模型關聯性將 [州別] 資料表篩選散佈至 [銷售] 資料表，會產生數千個可見資料列 (屬於中西部區域的州銷售事實)。

可建立的最簡單靜態規則會限制所有資料表資料列的存取權。 請考慮套用至 銷售詳細資料 資料表的下列規則 (模型圖表中未描述)。


FALSE()

此規則可確保使用者無法存取任何資料表資料。 當允許銷售人員 (從 Sales 資料表) 查看匯總的銷售結果時，可能會很有用，但無法查看訂單層級詳細資料。

定義靜態規則很簡單且有效。 當您只需要建立其中幾個 (像是在 Adventure Works 只有六個美國區域的情況) 時，可考慮使用這些規則。 不過，請注意其缺點：靜態規則可能需要耗費相當大的工作量來建立和設定。 當新區域上線時，您也需要更新並重新發佈資料集。

如果有許多規則需設定，且您預期未來會新增新的規則，可以考慮改為建立動態規則。

動態規則

動態規則會使用傳回環境值的特定 DAX 函式 (而不是常數)。 環境值會從三個特定的 DAX 函式傳回：

  • USERNAME 或 USERPRINCIPALNAME – 傳回 Power BI 驗證的使用者為文字值。

  • CUSTOMDATA - 傳回連接字串中傳遞的 CustomData 屬性。 使用連接字串連線到資料集的非 Power BI 報表工具可以設定此屬性，例如 Microsoft Excel。

注意

請注意，USERNAME 函式會在 Power BI Desktop 中使用時，以 DOMAIN\username 的格式傳回使用者。 不過，在 Power BI 服務中使用時，會傳回使用者的使用者主體名稱格式 (UPN)，例如 username@adventureworks.com。 或者，您可以使用 USERPRINCIPALNAME 函式，這一律會以使用者主體名稱的格式傳回使用者。

請考慮修訂的模型設計，現在包含 (隱藏) AppUser 資料表。 AppUser 資料表的每個資料列都會描述使用者名稱和區域。 Region 資料表的模型關聯性會從 AppUser 資料表傳播篩選。

Image shows a revised model diagram that now includes the AppUser table. This table has two columns: Region and User Name.

下列套用至 AppUser 資料表的規則會限制已驗證使用者區域的資料存取。


'AppUser'[UserName] = USERPRINCIPALNAME()

當模型資料表儲存使用者名稱值時，定義動態規則很簡單且有效。 這些規則可讓您強制執行資料驅動的 RLS 設計。 例如，將銷售人員新增至 [AppUser] 資料表或從中移除 (或指派給不同區域) 時，此設計方法便十分有效。

驗證角色

當您建立角色時，請務必測試這些角色，以確保其套用正確的篩選。 針對在 Power BI Desktop 中建立的資料模型，有一個檢視身分功能可讓您在強制執行不同角色時查看報表，並傳遞不同的使用者名稱值。

Screenshot shows the Power B I Desktop Modeling ribbon. The “View as” command is highlighted.

設定角色對應

必須在使用者存取 Power BI 內容之前先設定角色對應。 角色對應涉及將 Microsoft Entra 安全性物件指派給角色。 安全性物件可以是使用者帳戶或安全性群組。

提示

可能的話，最好將角色對應至安全性群組。 如此一來，將較少的對應，您可以將群組成員資格管理委派給網路系統管理員。

針對 Power BI Desktop 開發的模型，角色對應通常會在 Power BI 服務中完成。 對於 Azure Analysis Services 或 SQL Server Analysis Services 模型，角色對應通常會在 SSMS 中完成。

如需設定 RLS 的詳細資訊，請參閱：

使用 DirectQuery 來源的單一登入 (SSO)

當您的資料模型有 DirectQuery 資料表及其資料來源支援 SSO 時，資料來源可以強制執行資料使用權限。 如此一來，資料庫會強制執行 RLS，而 Power BI 資料集和報表可接受資料來源的安全性。

假設 Adventure Works 有一個 Azure SQL Database 用於其銷售作業，其與 Power BI 位於相同的租用戶中。 資料庫會強制執行 RLS 來控制對各種資料庫資料表中資料列的存取權。 您可以建立 DirectQuery 模型，以無角色的方式連線到此資料庫，並將其發佈至 Power BI 服務。 當您在 Power BI 服務中設定資料來源認證時，您可啟用 SSO (部分機器翻譯)。 當報表取用者開啟 Power BI 報表時，Power BI 會將其身分識別傳遞至資料來源。 然後，資料來源會根據報表取用者的身分識別來強制執行 RLS。

Screenshot shows the data source credentials window with the S O option enabled.

如需 Azure SQL Database RLS 的相關資訊，請參閱資料列層級安全性 (部分機器翻譯)。

注意

在 Power BI 服務中，若導出資料表與計算結果欄所參考的 DirectQuery 資料表來自具有 SSO 驗證的資料來源，則不提供支援。

如需支援 SSO 的資料來源詳細資訊，請參閱 DirectQuery 來源的單一登入 (SSO) (部分機器翻譯)。