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

列級安全（RLS）限制特定使用者對 Power BI 語意模型的資料存取。篩選器在列層級限制資料，並且你在角色中定義這些篩選器。在 Power BI 服務中，具有工作區存取權的使用者可以存取該工作區中的語意模型。 RLS 僅限具有檢視人員權限使用者的資料存取。它不適用於工作區 的管理員、成員或貢獻者角色。

要實作 RLS，請遵循以下高層次工作流程：

在 Power BI Desktop 中使用 DAX 濾鏡運算式定義角色和規則。
Publish語意模型並向Power BI 服務報告。
新增成員 至 Power BI 服務中的角色。
請使用 「測試作為角色 」功能來驗證資料過濾是否如預期運作。

你可以在 Power BI Desktop 或 Power BI 服務中設定匯入語意模型的 RLS。你也可以在使用 DirectQuery 的語意模型上設定 RLS，例如 SQL Server。針對 Analysis Services 或 Azure Analysis Services 即時連線，您可以在模型中設定數據列層級安全性，而不是在 Power BI 中設定。即時連線語意模型不會顯示安全性選項。

注意

本文專門針對 Power BI 語意模型討論 RLS。關於其他 Microsoft Fabric 項目的資料安全，請參見 Microsoft Fabric 中的安全性。

注意

在 Microsoft Fabric 的 Direct Lake 語意模型中，RLS 是受支援的。然而，如果 DAX 查詢因不支援的功能而退回 DirectQuery 模式，RLS 過濾器仍然適用，但效能特性可能會改變。在 Fabric 容量指標應用程式中監控查詢備援行為。

在 Power BI Desktop 中定義角色和規則

您可以在 Power BI Desktop 中定義角色和規則。透過此編輯器，您可以在使用預設下拉式介面與使用 DAX 介面之間進行切換。發佈至 Power BI 時，您也會發佈角色定義。

若要定義安全性角色：

將資料匯入 Power BI Desktop 報表，或設定 DirectQuery 連線。

注意

您不能在 Power BI Desktop 中定義 Analysis Services 即時連線的角色。您必須在 Analysis Services 模型中進行此動作。
從模型化索引標籤中，選取 管理角色。
從管理角色視窗中，選擇新增來創建新角色。
在 [角色] 下，提供角色的名稱並選取 [輸入]。

注意

您無法使用逗號定義角色，例如 London,ParisRole。
在選擇表格下，選擇您想要應用行級別安全性篩選器的表格。
在篩選資料下，使用預設編輯器來定義您的角色。建立的運算式會傳回「true」或「false」的值。 DAX 篩選條件會針對每一資料列評估結果是否為 TRUE 或 FALSE。只有回傳 TRUE 的列才會被看到，其他所有資料都被完全移除。

注意

並非所有在 Power BI 中支援的資料列層級安全性篩選條件都可以使用預設編輯器進行定義。限制包括目前只能使用 DAX 定義的運算式，包括 username（） 或 userprincipalname（） 等動態規則。若要使用這些篩選條件定義角色，請切換至使用 DAX 編輯器。
選擇性地選取 [切換至 DAX 編輯器] 以切換至使用 DAX 編輯器來定義您的角色。 DAX 運算式會傳回 true 或 false 值。例如： [Entity ID] = “Value” 。 DAX 編輯器具備公式自動完成功能 (intellisense)。您可以選取運算式方塊上方的核取記號來驗證運算式，也可以選取運算式方塊上方的 X 按鈕來還原變更。

注意

您可以在此運算式中使用username（）。 請注意， username（） 在 Power BI Desktop 中的格式為 DOMAIN\username 。在 Power BI 服務和 Power BI 報表伺服器中，其格式為使用者主體名稱 (UPN)。此外，在此運算式方塊中，即使您使用的地區設定通常會使用分號作為分隔符號（例如法文或德文），仍需使用逗號來分隔 DAX 函式引數。
您可以選取 [切換至預設編輯器]，以切回預設編輯器。在兩個編輯介面中所做的所有更改在切換介面時都會被保留，若有可能。使用無法在預設編輯器中定義的 DAX 編輯器定義角色時，如果您嘗試切換至預設編輯器，系統會提示您切換編輯器可能會導致某些資訊遺失的警告。若要保留此資訊，請選取 [取消]，然後繼續僅在 DAX 編輯器中編輯此角色。

注意

在此運算式方塊中，即使您的地區設定通常使用分號作為分隔符號（例如法文或德文），也請使用逗號來分隔 DAX 函數引數。
請選擇儲存。

您無法在 Power BI Desktop 中指派使用者給角色。請在 Power BI 服務中指派他們。您可以使用 username（） 或 userprincipalname（） DAX 函式，並設定適當的關聯性，在 Power BI Desktop 內啟用動態安全性。

適用於 RLS 角色的常見 DAX 篩選模式

以下範例展示了在 Power BI Desktop 中定義 RLS 角色時可以使用的常見 DAX 濾網表達式：

靜態RLS — 限制資料為固定值：
```
[Region] = "West"
```
動態 RLS 搭配 UPN — 根據登入使用者的電子郵件地址限制資料：
```
[UserEmail] = USERPRINCIPALNAME()
```
動態 RLS 搭配使用者名稱 — 根據使用者的網域與使用者名稱限制資料：
```
[UserDomain] = USERNAME()
```
動態 RLS 搭配 CUSTOMDATA — 根據從嵌入應用程式傳遞的自訂字串限制資料：
```
[AppRole] = CUSTOMDATA()
```
注意

CUSTOMDATA() 主要用於嵌入式情境，應用程式透過 Power BI REST API 傳遞自訂有效身份字串。

動態 RLS 是最常見的方法，因為它允許單一角色定義根據資料模型中的使用者映射表，為每位使用者做出不同的過濾。

範例：依地區篩選 Power BI 銷售資料

假設你有一個 Sales 表格，欄位為 Region、 Product、 Amount和。你要限制被分配到「西方」角色的使用者，讓他們只看到區域是「西方」的欄位。

在 DAX 篩選 欄位中，針對「West」角色，輸入以下表達式：

[Region] = "West"

過濾前（所有資料）：

區域	Product	數量
西	小部件 A	500
東	控制項 B	300
西	小工具 C	450
南	小部件 A	200
東	小工具 C	375

篩選後（「West」角色使用者檢視）：

區域	Product	數量
西	小部件 A	500
西	小工具 C	450

DAX 運算式作為列過濾器，評估表格中的每一列。只有欄位 Region 等於「西方」的列，才會被分配給該角色的使用者看到。

小提示

使用「以角色檢視」功能（詳見 Power BI 服務中的「驗證角色」）來驗證你的過濾器是否回傳預期的列，然後再發佈報告。

搭配 RLS 的雙向交叉篩選

根據預設，資料列層級安全性篩選使用單一方向的篩選條件，不論關聯性設定為單向或雙向。

您可以透過選取關聯性並勾選 [在雙向篩選中套用資料列層級安全性] 核取方塊，手動啟用具備資料列層級安全性的雙向交叉篩選功能。當同時在伺服器層級實作動態資料列層級安全性 (其中資料列層級安全性是依據使用者名稱或登入識別碼) 時，請選取此選項。如果一個資料表參與多個雙向關係，你只能為其中一種關係選擇此選項。

注意事項

啟用雙向安全過濾可能會負面影響查詢效能，尤其是在擁有多關係或大型資料集的模型中。部署到生產環境前請徹底測試。

如需詳細資訊，請參閱在 Power BI 中使用 DirectQuery 雙向交叉篩選和保護表格式 BI 語意模型技術文件。

模型關聯圖設定的螢幕擷取畫面，以雙向套用安全性篩選。

管理你的語意模型安全性

要管理語意模型的安全，請在 Microsoft Fabric 中開啟你儲存語意模型的工作區，並執行以下步驟：

在 Microsoft Fabric 中，選擇語意模型的「更多選項」選單。當您將滑鼠停留在語意模型名稱上時，即會顯示此功能表。
選取安全性。

安全系統 會帶你到 Row-Level 安全頁面，在那裡你新增成員到你建立的角色。擁有工作空間貢獻者角色或以上的使用者會看到 安全性 選項，並可指派使用者到角色。根據情境，也可能需要語意模型擁有權或建置權限。

注意

你只能針對已在 Power BI Desktop 中定義資料列層級安全性角色的語意模型管理安全性，或在 Power BI 服務中編輯資料模型時管理安全性。如果你的語意模型沒有預先定義角色，你就無法在 Power BI 服務中管理安全。

在 Power BI 服務中管理 RLS 角色成員

新增成員至 RLS 角色

在 Power BI 服務中，您可以輸入使用者或安全群組的電子郵件地址或名稱，將成員加入 RLS 角色。你無法新增在 Power BI 建立的群組。您可以新增組織的外部成員。關於 RLS 如何與外部 B2B 訪客使用者合作的指引，請參閱「外部（B2B 訪客）使用者的考量事項」。

您可以使用以下 Microsoft Entra ID 及啟用電子郵件的群組來設定列級安全：

發佈群組
郵件啟用群組
Microsoft Entra 安全群組 — 若安全群組包含外部 B2B 訪客使用者，請參閱「外部（B2B訪客）使用者的考量」以了解已知限制。

Important

Microsoft 365 群組不被支援，也無法加入任何 RLS 角色。僅上述列出的群組類型支援 RLS 角色成員資格。

顯示如何新增成員的螢幕擷取畫面。

你可以透過角色名稱旁括號內的數字，或在成員旁邊查看該角色的成員數量。

顯示角色中成員的螢幕擷取畫面。

從 RLS 角色中移除成員

你可以選擇名字旁的 X 來移除成員。

顯示如何移除成員的螢幕擷取畫面。

在 Power BI 服務中驗證此角色

你可以透過測試 Power BI 服務來驗證你定義的 RLS 角色是否正確運作。

選取角色旁邊的 更多選項 （...）。
選取 [測試為角色]。

測試角色選項截圖。

注意

儀表板無法使用 [ 測試為角色 ] 選項進行測試。你會被重定向到使用此語意模型從 Power BI Desktop 發布的報告（如果存在）。

報告載入時，請確認以下事項：

報表僅顯示與角色中定義的篩選式相符的資料列。
視覺化、表格和圖表反映的是篩選後的資料，而非完整資料集。
如果你使用動態 RLS，資料對應於 「現在視為 標頭」中顯示的身份。

在頁面標題中，會顯示應用的角色。您可以選取 [目前檢視身分] 來測試其他角色、角色組合或特定人員。在這裡，您會看到與所測試個人或角色相關的重要權限詳細資料。如需權限如何與 RLS 互動的詳細資訊，請參閱 RLS 使用者體驗。

顯示為特定人員的下拉選單的截圖。

測試連線至語意模型的其他報表，方法是選取頁首中的 [檢視]。您只能測試位於與語意模型相同工作區的報表。

檢視的螢幕擷取畫面，以選取要測試的不同報表。

若要返回正常檢視，請選取 [返回資料列層級安全性]。

注意

「 作為角色的測試 」功能無法在啟用單一登入（SSO）的 DirectQuery 語意模型上運作。此外，報告中並非所有層面都能在「以角色測試」功能中驗證，包括 Q&A 視覺效果、快速深入解析視覺效果，以及。

小提示

如果「作為角色測試」未顯示預期的結果，請嘗試以下方法：

請確認 DAX 濾波器的表達式語法正確，且參考了正確的欄位名稱。
務必選對角色來測試。
對於動態 RLS，請確認使用者映射表中是否包含符合 USERPRINCIPALNAME() 或 USERNAME() 的值。
對於啟用 SSO 的 DirectQuery 語意模型，不支援 以角色身份測試 。請以真正的檢視者角色登入以驗證資料過濾。

使用 username（）或 userprincipalname（） DAX 函式

您可以在資料集內使用 DAX 函式 username() 或 userprincipalname()。您可以在 Power BI Desktop 中將它們用在運算式內。當您發行模型時，它會用在 Power BI 服務中。

在 Power BI Desktop 內，username() 會以「網域\使用者」格式傳回使用者，userprincipalname() 會以 user@contoso.com 格式傳回使用者。

在 Power BI 服務內，username() 和 userprincipalname() 都會傳回使用者的使用者主體名稱 (UPN)。這看起來類似電子郵件地址。

在 Power BI 裡用 RLS 搭配工作區

如果你將 Power BI Desktop 報告發佈到 Power BI 服務中的工作區，RLS 角色會套用到工作區中被分配為 Viewer 角色的成員。即使 Viewers 獲得語意模型的建置權限，RLS 仍然適用。例如，若擁有建置權限的檢視者使用 Excel 中的分析，他們對資料的檢視會受到 RLS 限制。被指定 為 Admin、 Member 或 Contributor 的工作區成員擁有語意模型的編輯權限，因此 RLS 不適用於他們。如果您希望在工作區內對人員套用 RLS，您只能為他們指派檢視者角色。欲了解更多資訊，請參閱工作區中的角色。

外部（B2B）訪客用戶的考量

如果你透過Microsoft Entra B2B與外部用戶分享Power BI內容，請注意以下關於RLS的考量。

具有外部成員的 Microsoft Entra 安全性群組

包含外部 B2B 訪客使用者的 Microsoft Entra 安全群組，在使用 RLS 角色成員時可能無法如預期運作。在某些配置中——尤其是外部使用者擁有訪客型帳號（而非成員型帳號）時，Power BI 服務在強制執行 RLS 篩選時，訪客的群組成員資格無法被正確評估。

建議的解決方法：與其透過 Microsoft Entra 安全群組將外部使用者加入 RLS 角色，不如直接透過電子郵件地址將他們加入角色。電子郵件地址會被解析到使用者的 B2B 帳戶。這確保在套用 RLS 濾波器時，他們的身份能正確匹配。欲了解更多資訊，請參閱 Power BI 服務中的 RLS 角色成員管理。

對於外部使用者眾多的組織，建議考慮使用動態 USERPRINCIPALNAME() RLS，取代基於群組的角色成員制。此方法會個別評估每位使用者的身分，並完全避免群組成員資格解析問題。

Important

如果你目前使用 Microsoft Entra 的安全群組來管理 RLS 角色成員，且這些群組包含 B2B 訪客使用者，請確認訪客用戶看到的是正確的篩選資料。如果沒有，就直接透過電子郵件地址將外部使用者加入 RLS 角色。

注意

此限制的具體範圍可能會依您的 Microsoft Entra ID 設定及所使用的 B2B 訪客邀請類型而有所不同。在依賴群組式 RLS 進行外部存取前，務必先用真正的訪客帳號測試。

如果問題在應用解決方法後依舊存在，請參考「故障排除：外部 B2B 訪客在 Power BI 報告中看不到資料，以取得更多診斷步驟。

Power BI RLS 中 B2B 訪客的 UPN 解析

當外部 B2B 訪客使用者存取 Power BI 報告時，USERPRINCIPALNAME() DAX 函式通常會回傳類似電子郵件的識別碼（例如 user@partner.com）。在某些配置中，可能會回傳格式為 #EXT# 的訪客 UPN（例如，user_partner.com#EXT#@yourtenant.onmicrosoft.com）。

這個區別對於動態行等式非常重要。如果你的使用者映射表儲存的識別碼格式與 USERPRINCIPALNAME() 回傳的格式不同，過濾器表達式就不匹配，訪客使用者可能看不到資料或資料錯誤。

Power BI RLS 中 B2B 訪客的 USERNAME（）行為

USERNAME() DAX 函式會傳回使用者的 domain\username 識別碼。對於 B2B 訪客使用者，USERNAME() 通常會回傳類似 USERPRINCIPALNAME() 的 UPN 形式識別碼，視設定而定（例如 user@partner.com），而不是 domain\username 格式。因為 USERNAME() 且 USERPRINCIPALNAME() 通常對 B2B 訪客回傳相同的值，大多數實作會採用 USERPRINCIPALNAME() 一致性。

小提示

如果你的現有動態 RLS 使用 USERNAME()，請先確認它在環境中為訪客用戶返回的結果，然後再對外分享內容。你可以在測試報告中加入卡片視覺顯示 USERNAME() 來檢查。

建議的做法： 在使用者映射表中儲存並一致使用與回傳 USERPRINCIPALNAME()的值相同的識別碼格式。在大多數情況下，使用電子郵件地址可以簡化管理：

[UserEmail] = USERPRINCIPALNAME()

欄 UserEmail 包含像 user@partner.com 的內部和外部使用者電子郵件地址。

注意

回傳 USERPRINCIPALNAME() 的值是使用者的登入識別碼（UPN），不一定是電子郵件地址。對大多數使用者來說，這些名稱相同，但可能會有所不同（例如，當使用者的電子郵件是別名時）。建立使用者映射表時，請使用 USERPRINCIPALNAME() 回傳的值，而非 Microsoft Entra ID 的 mail 屬性。

Important

如果你使用 Dynamic RLS 並搭配 USERPRINCIPALNAME()，務必與實際的外部訪客用戶測試。「以角色身份測試」功能會使用你自己的身份，不會揭露外部使用者 UPN 解析問題。

注意

B2B 訪客的 UPN 解析行為會依據你的 Microsoft Entra ID 設定而異，例如跨租戶存取設定和訪客使用者類型。務必在你所處的環境中驗證該行為。

故障排除：外部 B2B 訪客在 Power BI 報告中看不到任何資料

如果 B2B 訪客用戶看到空白報告或收到「無資料」訊息，請依照以下步驟操作：

驗證傳回的 UPN 格式 — 使用 USERPRINCIPALNAME() 建立測試量值，並將其顯示在卡片視覺效果中。讓訪客使用者查看報告，看看實際回傳的值。
檢查使用者映射表 — 確認映射表中有一列值與該訪客回傳的值完全一致 USERPRINCIPALNAME() 。
檢查大小寫敏感性 — DAX 字串比較預設不區分大小寫，但請確認你的資料來源沒有引入大小寫區分值。
檢視跨租戶存取設定 — 如果您的組織使用跨租戶存取政策，可能會影響 Power BI 呈現的 UPN 格式。
使用實際訪客使用者進行測試 — 「以角色身分測試」功能會使用你自己的身分。一定要用真實的外部訪客帳號驗證。
驗證角色指派 — 如果訪客用戶看到的資料比預期多，請確認他們被指派到RLS角色。未被指派任何 RLS 角色的使用者通常看不到資料（結果為空白），因為 RLS 是強制執行的，但沒有套用對應角色。 DAX 篩選條件會針對每一資料列評估結果是否為 TRUE 或 FALSE。只有回傳 TRUE 的列才會被看到。其他所有東西都被完全移除了。

欲了解更多關於與外部使用者分享Power BI內容的資訊，請參見Distribute Power BI content to external guest user with Microsoft Entra B2B。

考量與限制

您可以在這裡看到雲端模型目前的資料列層級安全性限制：

如果先前已在 Power BI 服務中定義了角色與規則，就必須在 Power BI Desktop 中重新建立。
您只能在使用 Power BI Desktop 建立的語意模型上定義 RLS。如果您想要針對以 Excel 建立的語意模型啟用 RLS，必須先將檔案轉換成 Power BI Desktop (PBIX) 檔案。深入了解。
無法將服務主體新增至RLS角色中。因此，RLS 不適用於使用服務主體作為最終有效身分識別的應用程式。
只支援匯入和 DirectQuery 連線。 Analysis Services 的即時連線會在內部部署模型中處理。
啟用 RLS 時，使用 DAX 查詢與度量中的 USERELATIONSHIP（）函式可能會產生意想不到的錯誤。為了解決這個問題，請重新設計你的 DAX 表達式，避免使用 USERELATIONSHIP（）並改用模型層級的關係或其他 DAX 模式。
[以角色測試/以角色檢視] 功能不適用於已啟用單一登入 (SSO) 的 DirectQuery 模型。
[ 測試角色/檢視角色 ] 功能僅顯示來自語意模型工作區的報告。
「以角色身分測試」/「以角色身分檢視」功能不適用於編頁報表。
權杖型身分識別僅適用於連線至 Azure SQL Database 容量上的 DirectQuery 模型，其設定為允許 Microsoft Entra 驗證。欲了解更多資訊，請參閱「嵌入基於代幣身份的報告」
'IdentityBlob' 參數是 Azure SQL 的 OAuth 2.0 存取權杖，僅支援與 Azure SQL 有 DirectQuery 連線的資料集。機制本身是 Azure-SQL 專屬的：blob is是一個範圍為 https://database.windows.net/.default 的 Microsoft Entra 存取權杖。 App-owns-data 嵌入中，其他資料來源沒有類似的標記傳遞機制。欲了解更多資訊，請參閱 GenerateToken 的 REST API 參考。

動態RLS的考量與限制

使用搭配 DAX 函式（例如 USERPRINCIPALNAME()、USERNAME() 或 CUSTOMDATA()）的動態資料列層級安全性 (RLS) 時，請注意下列事項。

B2B 跨租用戶案例

在 B2B 情境中，USERPRINCIPALNAME() 會回傳由Power BI 服務解析的身份，這會依租戶配置而有所不同。它可以表現為以下兩種形式：

外部使用者的電子郵件地址（），user@partner.com或
租戶解決的價值如 user_partner.com#EXT#@tenant.onmicrosoft.com

確切格式無法保證，必須在你的環境中驗證。

如果你的使用者映射表儲存的識別碼格式與 USERPRINCIPALNAME() 訪客使用者回傳的格式不同，RLS 濾波表式就無法匹配，訪客將看不到任何資料或錯誤資料。務必確認外部使用者在環境中回 USERPRINCIPALNAME() 傳的精確數值。

小提示

使用 USERPRINCIPALNAME() 建立測試度量值，並將其顯示在卡片視覺效果中。請讓外部訪客用戶查看報告，以確認回傳的值是否符合你的使用者映射表。這個簡單的測試可以避免花費數小時除錯不符的身份值。

在動態 RLS 中以角色限制進行測試

Power BI 服務中的 Test as role 功能在評估動態 RLS 運算式時，會使用您自己的身分識別。這表示 USERPRINCIPALNAME() 回傳 的是你的 UPN，而不是你想模擬的使用者。你不能用 Test 作為角色 來查看特定的 B2B 訪客用戶或服務主體會看到什麼。

角色測試 模擬角色成員身份，但無法完全複製其他使用者的認證情境，尤其是對 B2B 訪客或嵌入式情境。

若要驗證外部使用者的動態 RLS，請以實際訪客使用者身份登入並直接查看報告。這是唯一能確認 USERPRINCIPALNAME() 會回傳預期值，且 RLS 篩選條件會針對該使用者正確套用的方法。

包含服務主體的嵌入式情境

當透過使用服務主體進行驗證的內嵌應用程式存取報告時，USERPRINCIPALNAME() 和 USERNAME() 會傳回服務主體的應用程式 ID 或空字串，而非終端使用者的身分。

這些函式不會回傳最終使用者身份，因此無法用於服務主體嵌入場景中的逐用戶過濾。這表示基於這些功能的動態 RLS 過濾器在嵌入式場景中不會針對每位使用者進行資料過濾。

若要在嵌入式情境中應用每使用者 RLS，請使用 Power BI REST API 中的 有效身份功能。產生內嵌權杖時，傳遞具有適當使用者名稱和角色的 EffectiveIdentity 物件。如果你的 RLS 規則使用 CUSTOMDATA()，請將自訂資料字串傳遞 EffectiveIdentity.CustomData。

欲了解更多資訊，請參閱適用於 ISV 的內嵌案例 RLS。

Important

嵌入服務主體時，務必使用包含 EffectiveIdentity 的實際嵌入標記測試，以驗證 RLS 濾波器是否正確套用。 Power BI 服務中的 以角色身分測試 功能不會模擬內嵌驗證流程。

請記住，如果 Power BI 報表參考已設定 RLS 的資料列，則會針對已刪除或不存在的欄位顯示相同訊息。對這些使用者來說，報表看似已毀損。

FAQ

問題：如果先前曾在 Power BI 服務中建立了資料集的角色與規則會如何？如果什麼都不做，它們還可以運作嗎？
回答：否，畫面不會正確呈現。您必須在 Power BI Desktop 內重新建立角色與規則，然後將其發佈至 Power BI 服務。

問題︰我可以為 Analysis Services 資料來源建立這些角色嗎？
回答：是，如果已將資料匯入 Power BI Desktop。如果您目前使用即時連線，就無法在 Power BI 服務中設定 RLS。你在本地的 Analysis Services 模型中定義 RLS。

問題：我可以使用 RLS 來限制使用者能夠存取的資料行或量值嗎？
回答：否，如果使用者具有特定資料列的存取權，就可以查看該資料列的所有資料行。若要限制對資料行和資料列中繼資料的存取，請考慮使用物件層級安全性。

問題：RLS 是否可讓我隱藏詳細資料，但允許存取以視覺效果摘要的資料？
回答：否，您可以保護個別資料列，但使用者一律可以查看詳細資料或摘要的資料。

回答：我的資料來源已定義了安全性角色 (例如 SQL Server 角色或 SAP BW 角色)。這些角色與 RLS 之間有何關聯性？
回答：答案取決於您是匯入資料，或是使用 DirectQuery。若您是將資料匯入 Power BI 資料集，便不會使用資料來源中的安全性角色。此時您應定義 RLS，對 Power BI 中的連線使用者施行安全性規則。如果您使用 DirectQuery，會使用資料來源所設定的安全性角色。當使用者開啟報表時，Power BI 會傳送查詢給基礎資料來源，而基礎資料來源將會依據使用者的認證對資料套用安全性規則。

問題：使用者可以屬於一個以上的角色嗎？
答案：使用者可以屬於多個角色，這些角色是可以疊加的。例如，如果使用者同時屬於「銷售」和「行銷」角色，他們可以看到這兩個角色的資料。

有任何問題嗎？請嘗試詢問 Power BI 社群建議？貢獻想法來改善 Power BI

意見反應

此頁面對您有幫助嗎？

上次更新時間： 2026-07-08

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

在 Power BI Desktop 中定義角色和規則

適用於 RLS 角色的常見 DAX 篩選模式

範例：依地區篩選 Power BI 銷售資料

搭配 RLS 的雙向交叉篩選

管理你的語意模型安全性

在 Power BI 服務中管理 RLS 角色成員

新增成員至 RLS 角色

從 RLS 角色中移除成員

在 Power BI 服務中驗證此角色

使用 username（） 或 userprincipalname（） DAX 函式

在 Power BI 裡用 RLS 搭配工作區

外部（B2B）訪客用戶的考量

具有外部成員的 Microsoft Entra 安全性群組

Power BI RLS 中 B2B 訪客的 UPN 解析

Power BI RLS 中 B2B 訪客的 USERNAME（） 行為

故障排除：外部 B2B 訪客在 Power BI 報告中看不到任何資料

考量與限制

動態RLS的考量與限制

B2B 跨租用戶案例

在動態 RLS 中以角色限制進行測試

包含服務主體的嵌入式情境

FAQ

相關內容

意見反應

其他資源

使用 username（）或 userprincipalname（） DAX 函式

Power BI RLS 中 B2B 訪客的 USERNAME（）行為