Power BI 的資料列層級安全性 (RLS)
Power BI 的資料列層級安全性 (RLS) 可用以限制指定使用者的資料存取。 篩選會限制資料列層級的資料存取，您可以在角色中定義篩選。 在 Power BI 服務中，工作區的成員具有工作區中資料集的存取權。 RLS 不會限制這項資料存取權。
您可以使用 Power BI Desktop 為匯入 Power BI 的資料模型設定 RLS。 您也可以針對使用 DirectQuery (如 SQL Server) 的資料集設定 RLS。 對於 Analysis Services 或 Azure Analysis Services 即時連線，您應在模型中設定資料列層級安全性，而不是在 Power BI Desktop 中設定。 即時連線資料集不會顯示安全性選項。
在 Power BI Desktop 中定義角色和規則
您可以在 Power BI Desktop 中定義角色和規則。 當發佈到 Power BI 時，也會發佈角色定義。
若要定義安全性角色，請遵循這些步驟。
將資料匯入 Power BI Desktop 報表，或設定 DirectQuery 連線。
注意
您不能在 Power BI Desktop 中定義 Analysis Services 即時連線的角色。 您必須在 Analysis Services 模型中進行此動作。
在 [模型] 索引標籤中，選取 [管理角色]。
從 [管理角色] 視窗中，選取 [建立]。
在 [角色] 下提供角色名稱。
注意
您無法使用逗號定義角色，例如
London,ParisRole。在 [資料表] 下選取要套用 DAX 規則的資料表。
在 [資料表篩選 DAX 運算式] 方塊中，輸入 DAX 運算式。 這個運算式會傳回 true 或 false 的值。 例如：
[Entity ID] = “Value”。
注意
這個運算式中可以使用 username() 。 請注意，username() 在 Power BI Desktop 中的格式為「網域\使用者名稱」。 在 Power BI 服務和 Power BI 報表伺服器中，格式則為使用者的使用者主體名稱 (UPN)。 或者，您可以使用 userprincipalname()，這一律會以使用者主體名稱的格式傳回使用者：username@contoso.com。
建立 DAX 運算式之後，請選取運算式方塊上方的核取記號，以驗證運算式。
注意
在此運算式方塊中，即使您使用的地區設定慣用分號分隔字元 (例如法文或德文)，您仍須使用逗號分隔 DAX 函式的引數。
選取 [儲存]。
您無法在 Power BI Desktop 中指派使用者給角色。 請在 Power BI 服務中指派他們。 在 Power BI Desktop 內，您可以使用 username() 或 userprincipalname() DAX 函式，並設定合適的關聯性，以啟用動態安全性。
根據預設，資料列層級安全性篩選使用單一方向的篩選條件，不論關聯性設定為單向或雙向。 您可以手動啟用雙向交叉篩選與資料列層級安全性，方法是選取關聯性，並核取 [雙向套用安全性篩選] 核取方塊。 當同時在伺服器層級實作動態資料列層級安全性 (其中資料列層級安全性是依據使用者名稱或登入識別碼) 時，請選取此選項。
如需詳細資訊，請參閱在 Power BI Desktop 中使用 DirectQuery 雙向交叉篩選和保護表格式 BI 語意模型技術文件。
在 Power BI Desktop 中驗證角色
在建立角色之後，於 Power BI Desktop 中測試角色的結果。
從 [ 模型] 索引標籤中，選取 [ 檢視身分]。
隨即顯示 [以角色身分檢視] 視窗，您會在此看到您已建立的角色。
選取您建立的角色，然後選取 [確定] 來套用該角色。
報表會呈現該角色的相關資料。
您也可以選取 [其他使用者] 並提供指定的使用者。
建議提供使用者主體名稱 (UPN)，原因是 Power BI 服務和 Power BI 報表伺服器都會用到。
在 Power BI Desktop 中，只有當您使用以 DAX 運算式為基礎的動態安全性時，[其他使用者] 才會顯示不同的結果。
選取 [確定]。
報表就會呈現該使用者可以看到的內容。
注意
[檢視為角色] 功能不適用於已啟用單Sign-On (SSO) 的 DirectQuery 模型。
既然您已完成驗證Power BI Desktop中的角色，請繼續將報表發佈至Power BI 服務。
管理模型的安全性
若要管理資料模型的安全性，請開啟您在Power BI 服務中儲存報表的工作區，然後執行下列步驟：
在 Power BI 服務中，在資料集選取 [更多選項] 功能表。 當您將游標懸停在資料集名稱上方時 (不論在導覽功能表還是工作區頁面選取)，都會出現此功能表。
選取 [安全性]。
安全性會帶您前往 [Role-Level 安全性] 頁面，您可以在其中將成員新增至您在 Power BI Desktop 中建立的角色。 參與者 (和更高的工作區角色) 將會看到 安全性 ，並可指派使用者給角色。
您只能在 Power BI Desktop 中建立或修改角色。
使用成員
新增成員
在Power BI 服務中，您可以輸入使用者或安全性群組的電子郵件地址或名稱，將成員新增至角色。 您無法新增在 Power BI 中建立的群組。 您可以新增組織的外部成員。
您可以使用下列群組來設定資料列層級安全性。
- 通訊群組
- 啟用郵件功能的群組
- 安全性群組
不過請注意，不支援Office 365群組，而且無法新增至任何角色。
您也可以根據角色名稱或 [成員] 旁括弧內的數字，知道有多少成員屬於該角色。
移除成員
您可以選取成員名稱旁的 X 來移除成員。
在 Power BI 服務中驗證角色
您可以藉由測試角色，驗證您所定義的角色在Power BI 服務中正常運作。
- 選取角色旁邊的 [更多選項] (...)。
- 選取 [測試資料] 作為角色。
您會看到這個角色可以使用的報表。 儀表板不會顯示在此檢視畫面中。 在頁首中，會顯示目前套用的角色。
您可以選取 [目前檢視身分] 來測試其他角色或角色組合。
您可以選擇以特定人員身分檢視資料，或者選取可用的角色組合來驗證是否能正常運作。
若要返回正常檢視，請選取 [返回資料列層級安全性]。
注意
已啟用單一Sign-On (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 角色會套用至指派給工作區中檢視者角色的成員。 即使 檢視者 獲得資料集的建置許可權，RLS 仍適用。 例如，如果具有建置許可權的檢視者使用[在 Excel 中進行分析]，其資料檢視將會受到 RLS 的保護。 指派管理員、成員或參與者的工作區成員具有資料集的編輯許可權，因此 RLS 不適用於這些成員。 如果您想要將 RLS 套用至工作區中的人員，您只能指派 檢視器 角色。 深入了解新的工作區中的角色。
考量與限制
雲端模型上資料列層級安全性的目前限制如下：
- 如果先前已在 Power BI 服務中定義了角色與規則，就必須在 Power BI Desktop 中重新建立。
- 您只能在使用 Power BI Desktop 建立的資料集上定義 RLS。 如果您想要針對以 Excel 建立的資料集啟用 RLS，必須先將檔案轉換成 Power BI Desktop (PBIX) 檔案。 深入了解。
- 服務主體無法新增至 RLS 角色。 因此，RLS 不會套用至使用服務主體作為最終有效身分識別的應用程式。
- 只支援匯入和 DirectQuery 連線。 Analysis Services 即時連接是在內部部署模型中處理。
- [以角色身分測試/檢視為角色] 功能不適用於已啟用單一Sign-On (SSO) 的 DirectQuery 模型。
問題：設定 RLS 時重新發佈
如果您嘗試從Power BI Desktop發佈先前發行的報表，就會收到錯誤訊息。 案例如下：
Anna 有個已發佈到 Power BI 服務的資料集，且已設定了 RLS。
Anna 在 Power BI Desktop 中更新了報表，然後重新發行。
Anna 收到錯誤。
因應措施
從 Power BI 服務重新發佈 Power BI Desktop 檔案，直到此問題解決為止。 您可以選取 [取得資料檔案> ] 來執行此動作。
問題：多個角色和有限的關聯性
如果您屬於多個 RLS 角色，而且至少有一個角色依賴 有限的關聯性，您會收到錯誤訊息。
請考慮下列資料模型：
在此簡化的資料模型中，結合來自兩個Power BI資料集的資料，存在兩個關聯性：
- Sales 與 Product 之間的一般關聯性。
- Sales 與 Customer 之間的有限關聯性。 此關聯性有限，因為客戶位於不同的來源群組中。 這不是關聯性可以限制的唯一原因。 如需詳細資訊，請參閱 有限的關聯性。
此外，此資料模型中已定義兩個 RLS 角色：
- RLS_Product，其定義于 [產品] 上，並限制對產品資訊的存取。
- RLS_Customer，這是在客戶上定義的，並限制存取客戶資訊。
使用者 A 同時屬於RLS_Product和RLS_Customer。 當使用者 A 存取報表中的資料時，會同時評估RLS_Product和RLS_Customer。 若要評估RLS_Customer，必須在 Sales 與 Customer 之間的有限關聯性之間共用資料。 此共用可能會意外地揭露產品的潛在資訊。 因此，Power BI不允許發生此共用，而是會產生下列錯誤：
「使用者屬於具有安全性篩選的多個角色 「RLS_Product，RLS_Customer」，當其中一個角色具有影響安全性篩選的資料表 'Sales' 與 SecurityFilteringBehavior=Both 關聯性時，不支援此篩選。」
因應措施
採用下列其中一個因應措施，以避免發生此錯誤：
- 如果可行，請勿將任何使用者放入多個 RLS 角色。 在上述案例中，我們可以建立另一個 RLS 角色，例如RLS_Product_Customer，這會結合在 RLS_Product 和 RLS_Customer 中設定的 RLS 篩選準則。 接下來，我們可以將使用者 A 指派給RLS_Product_Customer，並從RLS_Product和RLS_Customer中移除使用者。
- 只在一個來源群組上定義 RLS 角色。 如果使用者必須屬於多個 RLS 角色，請確定角色中設定的所有 RLS 篩選準則都是在單一來源群組的資料表上定義。 在上述案例中，如果我們可以在包含 Sales 和 Product 的來源群組上定義RLS_Customer，我們可以避免錯誤。
注意
我們注意到，在許多情況下，Power BI太嚴格，而且可以在涉及的來源之間安全地共用資訊。 雖然我們正努力發行此情況的解決方案，但請考慮採用上述其中一個因應措施。
常見問題集
問題︰如果先前曾在 Power BI 服務中建立了資料集的角色與規則會如何？ 如果什麼都不做，它們還可以運作嗎？
回答： 否，視覺效果將不會正確轉譯。 您必須在 Power BI Desktop 內重新建立角色與規則，然後將其發行至 Power BI 服務。
問題︰我可以為 Analysis Services 資料來源建立這些角色嗎？
回答︰如果已將資料匯入 Power BI Desktop 就可以。 如果您使用的是即時連線，就無法在 Power BI 服務中設定 RLS。 這定義在內部部署 Analysis Services 模型中。
問題：我可以使用 RLS 來限制使用者能夠存取的資料行或量值嗎？
回答： 否，如果使用者可以存取特定資料列，他們可以看到該資料列的所有資料行。
問題：RLS 是否可讓我隱藏詳細資料，但允許存取以視覺效果摘要的資料？
回答：否，您可以保護個別資料列，但使用者一律可以查看詳細資料或摘要的資料。
問題：我的資料來源已定義安全性角色 (，例如SQL Server角色或 SAP BW 角色) 。 這些與 RLS 之間有何關聯性？
回答： 答案取決於您要匯入資料或使用 DirectQuery。 若您是將資料匯入 Power BI 資料集，便不會使用資料來源中的安全性角色。 此時您應定義 RLS，對 Power BI 中的連線使用者施行安全性規則。 若您是使用 DirectQuery，將會使用資料來源中的安全性角色。 當使用者開啟報表時，Power BI 會傳送查詢給基礎資料來源，而基礎資料來源將會依據使用者的認證對資料套用安全性規則。