上一個

下一個

設定資料列層級安全性

已完成

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

注意

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

提示

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

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

此外，您可以使用 SQL Server Management Studio 或使用表格式編輯器等外部工具來建立及管理角色。

套用星型結構描述設計主體

若要達成有效 RLS 解決方案，第一個步驟是開發設計良好的模型。 我們建議您套用星型結構描述設計主體，以產生包含維度和事實資料表的模型。 通常，Power BI 會強制執行規則來篩選維度資料表，而模型關聯性會有效率地將這些篩選傳播至事實資料表。

下圖是Tailspin Toys銷售分析數據模型圖表。 這會顯示星型結構描述設計，其中包含名為 Sales 的單一事實資料表。 其他四個資料表是支援依日期、狀態、區域和產品分析銷售量值的維度資料表。 模型關聯性會連接所有資料表。 這些關聯性會將篩選 (直接或間接) 傳播至 Sales 資料表。

此模型設計支援本課程模組中呈現的範例。

定義規則

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

提示

若要深入了解資料列內容，請參閱將計算的資料表和資料行新增至 Power BI Desktop 模型模組。 此課程模組描述新增模型計算的程式，但也包含一個介紹和描述數據列內容的單元。

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

靜態規則

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

請考慮套用至 Region 資料表的下列規則，以限制對新英國銷售的數據存取：

'Region'[Region] = "New England"

下列步驟說明強制執行規則的Power BI程式。

1. 篩選 Region 資料表，產生一個可見的資料列 (新英格蘭)。

2. 使用模型關聯性將 Region 資料表篩選傳播至 State 資料表，產生六個可見的資料列 (新英格蘭區域包括六個州)。

3. 使用模型關聯性將 State 資料表篩選傳播至 Sales 資料表，產生數千個可見資料列 (屬於新英格蘭區域的州銷售事實)。

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

FALSE()

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

定義靜態規則很簡單且有效。 當您只需要建立少數規則時 (像是在 Tailspin Toys 只有六個區域的情況下)，可考慮使用靜態規則。 不過，請注意一些缺點：設定靜態規則可能涉及建立和設定的重要工作。 靜態規則也需要在引進新區域時更新和重新發佈數據集。

如果有多個設定規則，且您預期未來將會新增新的規則，請考慮改用動態規則。

動態規則

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

• USERNAME 或 USERPRINCIPALNAME：當您使用 適用於貴組織的 案例時，這些函式會傳回描述已驗證使用者的文字值。 在使用適用於您的客戶案例時，這些函式會傳回您的應用程式所傳遞的文字值。

• CUSTOMDATA：當您使用組織案例時，此函式會傳回傳入 連接字串 的 CustomData 屬性。 在使用適用於您的客戶案例時，這會傳回您的應用程式所傳遞的文字值。

注意

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

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

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

'AppUser'[UserName] = USERPRINCIPALNAME()

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

重要

當您使用 適用於客戶的 案例時， USERNAME 和 USERPRINCIPALNAME 函式不需要傳回實際的用戶名稱。 相反地，您的應用程式可以傳遞任何文字值來篩選模型。

驗證角色

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

設定角色對應

角色對應會根據內嵌案例而有所不同。

使用適用於您的組織案例時，您必須先在存取 Power BI 內容的使用者之前設定角色對應。 角色對應牽涉到將 Microsoft Azure Active Directory 安全性物件指派給角色。 安全性物件可以是使用者帳戶或安全性群組。

提示

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

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

當您使用 「 適用於您的客戶 」案例時，應用程式會在運行時間執行角色對應。 您的應用程式邏輯會設定一或多個有效的身分識別，以強制執行 RLS。 本課程模組稍後會說明設定有效的身分識別。

如需設定 RLS 的詳細資訊，請參閱下列文章：

• Power BI 的資料列層級安全性 (RLS)

• Power BI Desktop 中的資料列層級安全性 (RLS) 指導方針

繼續