Power BI 實作規劃：報表取用者安全性規劃

此安全性規劃文章將描述適用於唯讀取用者的策略。 重點會放在適用於報表和應用程式的檢視人員權限，以及如何強制執行資料安全性。 本文的主要目標讀者為：

• Power BI 管理員：負責監督組織中 Power BI 的管理員。
• 卓越中心、IT 和 BI 團隊：同時負責監督 Power BI 的團隊。 他們可能需要與 Power BI 管理員、資訊安全小組和其他相關小組共同作業。
• 內容建立者和擁有者：需要建立、發佈、保護及管理其他使用者取用之內容的自助 BI 建立者。

這系列文章旨在擴充 Power BI 安全性技術白皮書中的內容。 雖然 Power BI 安全性技術白皮書著重於驗證、資料落地和網路隔離等重要技術主題，但系列的主要目標是為您提供考量和決策，以協助您規劃安全性和隱私權。

在組織中，許多使用者歸類為取用者。 取用者會檢視其他使用者已建立並發佈的內容。 取用者是此文章的重點。 如需著重於內容建立者和擁有者的安全性規劃，請參閱內容建立者安全性規劃一文。

若要充分利用此文章，了解 Power BI 內容中「共用」和「散發」詞彙的意義會很有幫助。

「共用」是指某位使用者為其他使用者 (或使用者群組) 提供存取特定內容項目的權限。 Power BI 服務中的共用功能範圍限定為某一個項目。 其最常發生在彼此認識且密切合作的個人之間。

「散發」是指將內容傳遞給其他使用者 (也就是所謂的收件者)。 這通常牽涉到多個團隊中的大量使用者。 收件者可能並未明確要求內容，但可辨識出他們需要使用它來執行其角色。 取用已散發內容的收件者不一定知道內容的原始建立者。 因此，將散發當作一種概念，會比共用更有條理。

當您與其他人交談時，請判斷他們是以一般方式使用「共用」一詞，還是以字面意思使用。 有兩種方式可解譯「共用」一詞的用法。

• 「共用」一詞通常會以與同事共用內容相關的一般方式來使用。 此文章將描述數種提供唯讀內容的技術。
• 「共用」也是 Power BI 中的特有功能。 其為針對使用者或群組授與單一項目存取權的功能。 此文章將描述共用連結和直接存取共用。

適用於唯讀取用者的策略

在 Power BI 服務中，若取用者同時擁有進行下列動作的權限，即可檢視報表或儀表板：

• 檢視包含視覺效果的 Power BI 項目 (例如報表或儀表板)。
• 讀取基礎資料 (先前稱為資料集的語意模型或其他來源)。

您可以使用不同的技術，為取用者提供唯讀存取權。 自助內容建立者所使用的常見技術包括：

• 為使用者和群組授與存取 Power BI 應用程式的權限。
• 將使用者和群組新增至 Power BI 工作區檢視人員角色。
• 使用共用連結，為使用者和群組提供每個項目權限。
• 使用直接存取，為使用者和群組提供每個項目權限。

Power BI 應用程式和 Power BI 工作區檢視人員角色選項牽涉到管理一組項目的權限。 這兩種每個項目權限技術牽涉到管理一個個別項目的權限。

檢閱項目的安全性設定時，您可能會看到其權限來自下列其中一項：

• 繼承自工作區或應用程式。
• 直接套用至項目。

在下列螢幕擷取畫面中，已針對報表顯示 [直接存取] 權限。 在此情況中，分別將工作區管理員和成員角色指派給一個群組。 這些角色會針對報表顯示，因為報表層級存取權繼承自工作區。 此外，還有一位使用者具有可直接套用至報表的讀取權限。

您為唯讀取用者選擇的策略可能不同。 其應以個別解決方案、管理解決方案的人員喜好設定或取用者的需求為基礎。 此節的其餘部分將描述何時應考慮使用每個可用的技術。

檢查清單：制定如何將內容提供給唯讀取用者的策略時，關鍵決策與動作包括：

Power BI 應用程式權限

Power BI 應用程式會為取用者提供報表、儀表板及活頁簿的集合。 應用程式可為取用者提供最佳使用者體驗，因為：

• 應用程式的瀏覽窗格提供簡單的直覺式使用者體驗。 相較於直接在工作區中存取內容，這是一種更好的體驗。
• 內容可以邏輯方式組織為應用程式瀏覽窗格中的區段 (例如資料夾)。
• 取用者只能存取應用程式中針對其對象明確包含的特定項目。
• 額外資訊、文件或其他內容的連結均可新增至其對象的瀏覽窗格中。
• 有內建的 [要求存取] 工作流程。

您可以為每個工作區建立一個應用程式，作為散發部分或所有工作區內容的正規方式。 應用程式是在組織內部廣泛散發內容的好方法，尤其是對於您不知道或未密切共同作業的使用者。

您可以與工作區角色分開管理應用程式權限。 分隔權限有兩項優點。 其鼓勵：

• 為內容建立者授與工作區存取權。 其包含針對內容積極共同作業的使用者，例如語意模型建立者、報表建立者及測試人員。
• 為取用者授與應用程式權限。 不同於工作區權限，應用程式權限一律是唯讀的 (或無)。

具有工作區存取權的所有使用者都可自動檢視應用程式 (已針對工作區發佈 Power BI 應用程式時)。 基於此行為，概念上可將工作區角色視為由每個應用程式對象「繼承」。 某些具有工作區存取權的使用者也可更新 Power BI 應用程式，視其獲指派的工作區角色而定。

符合下列情況時，使用應用程式來將內容散發給唯讀取用者會是最佳選擇：

• 您希望使用者只能檢視該對象可見的特定項目 (而不是基礎工作區中的所有項目)。
• 您希望與工作區分開管理應用程式的唯讀權限。
• 相較於每個項目權限，您希望更簡單地管理唯讀使用者的權限。
• 您想要確保會對取用者強制執行資料列層級安全性 (當取用者具有基礎語意模型的唯讀權限時)。
• 您想要確保取用者在重新發佈應用程式之前無法檢視新報表和已變更的報表。

儘管應用程式使用者在應用程式重新發佈之前看不到報表和儀表板的變更，但有兩個考量需要注意。

• 立即語意模型變更：語意模型變更一律會立即生效。 例如，若您對工作區中的語意模型引進中斷性變更，可能會不小心導致報表變得不穩定 (即使尚未在應用程式中重新發佈報表)。 有兩種方式可以降低此風險：首先，在 Power BI Desktop 中執行所有開發工作 (與工作區分開)。 其次，使用個別工作區進行開發和測試，藉以隔離實際執行應用程式。 (或者，您可以使用部署管線，達到將工作區內容從開發部署到測試和實際執行環境的更高層級控制)。
• 將內容和權限一起發佈：當您發佈應用程式時，其權限會與內容同時發佈。 例如，您可能在尚未完成、完整測試或核准的工作區中進行了報表變更。 因此，您無法僅為了更新權限而重新發佈應用程式。 若要降低此風險，將應用程式權限指派給安全性群組，並在授與應用程式權限時，使用安全性群組成員資格 (而不是個別使用者)。 避免僅為了套用權限變更而重新發佈應用程式。

應用程式對象

Power BI 服務中的每個工作區只能有一個 Power BI 應用程式。 不過，在應用程式中，您可以建立一或多個「對象」。 請參考下列案例。

• 您有五份銷售報表，會在您的整個全球銷售組織中散發給許多使用者。
• 應用程式中針對銷售代表定義了一個對象。 此對象可以檢視這五份報表的其中三份。
• 應用程式中針對銷售領導團隊定義了另一個對象。 此對象可以檢視所有五份報表，包括銷售代表無法取得的那兩份報表。

這個「混合與比對」內容和對象的功能具有下列優點。

• 某些報表可供多個對象檢視。 因此，建立多個對象，就不需要跨不同工作區重複內容。
• 某些報表應該只提供給一個對象。 因此，適用於該對象的內容可位於與其他相關內容相同的工作區中。

下列螢幕擷取畫面顯示具有兩個對象的應用程式：銷售領導與銷售代表。 [管理對象存取權] 窗格會為下列兩個安全性群組提供對銷售領導對象群組的存取權：「銷售領導-北美洲」和「銷售領導-歐洲」。 螢幕擷取畫面中針對銷售領導對象群組顯示的 [毛利分析] 報表不適用於銷售代表對象群組。

當您管理應用程式的權限時，可在 [直接存取] 頁面上檢視每個對象的成員。 您也可以看到「所有」對象底下列出具有工作區角色的使用者。 您無法從 [直接存取] 頁面更新應用程式權限。 相反地，您必須重新發佈應用程式。 不過，如果有針對應用程式開啟的存取要求時，您可以從 [擱置] 頁面更新應用程式權限。

應用程式權限選項

當您建立 (或重新發佈) 應用程式時，每個對象都有 [管理對象存取權] 窗格。 在該窗格中，有下列權限可供使用。

• 授與存取權給：針對每個對象，您可以授與對個別使用者和群組的存取權。 透過 [將應用程式發佈至整個組織] 租用戶設定啟用時，可將應用程式發佈至整個組織，且不會自動安裝該應用程式。 建議您盡可能將群組指派給對象，因為新增或移除使用者牽涉到重新發佈應用程式。 具有工作區存取權的每個人都自動擁有檢視或更新應用程式的權限，視其工作區角色而定。
• 語意模型權限：可在發佈應用程式時授與兩種類型的語意模型權限：
  • 語意模型再次共用：啟用時，會將與其他人共用基礎語意模型的再次共用權限授與應用程式使用者。 當基礎語意模型可輕易地與任何人共用時，啟用此選項是有意義的。 建議您先獲得語意模型擁有者的核准，然後將再次共用權限授與應用程式對象。
  • 語意模型建置：啟用時，會將語意模型的建置權限授與應用程式使用者。 建置權限讓使用者能夠建立新報表、從報表匯出基礎資料等等。 建議您先獲得語意模型擁有者的核准，然後將建置權限權授與應用程式對象。

發佈應用程式時新增語意模型再次共用或建置權限的功能很方便。 不過，建議您考慮個別管理應用程式權限和語意模型權限。 原因如下。

• 共用語意模型可能位於不同的工作區：如果將語意模型發佈至與應用程式不同的工作區，您必須直接管理其權限。 發佈應用程式時新增讀取、建置或再次共用權限的功能，僅適用於與應用程式位於相同工作區的語意模型。 基於這個理由，建議您習慣獨立管理語意模型權限。
• 個別管理語意模型權限：如果您移除或變更應用程式的權限，該動作只會對應用程式產生影響。 其不會自動移除先前指派的任何語意模型權限。 如此一來，您可以將應用程式權限和語意模型權限視為「分離」。 當語意模型權限變更或需要移除時，您必須與應用程式分開直接管理語意模型。
• 語意模型權限應受到控制：透過應用程式授與語意模型權限，即會脫離語意模型擁有者的控制。 授與再次共用權限，依賴選擇再次共用語意模型的使用者所做的良好判斷。 允許再次共用時，您的內部治理或安全性指引可能會變得更難管理。
• 取用者和建立者的目標不同：一般而言，組織中的內容取用者會比建立者多很多。 根據最低權限的原則，取用者只需要適用於基礎語意模型的讀取權限。 除非他們想要建立新報表，否則不需要建置權限。

應用程式預先安裝權限

當您發佈 Power BI 應用程式之後，使用者通常需要安裝該應用程式之後才能加以開啟。 使用者可以從 Power BI 服務的 [應用程式] 頁面，或使用他們從其他使用者處接收到的連結來安裝應用程式。 當其包含於應用程式的至少一個對象中時，其將能夠找到 (並安裝) 該應用程式。

安裝應用程式的替代方法是將應用程式「推送」給應用程式取用者。 這會導致應用程式的預先安裝，使其自動顯示在 Power BI 服務的 [應用程式] 頁面中。 此方法對取用者而言非常方便，因為他們不需要尋找並安裝應用程式。 不過，預先安裝的應用程式可能會為使用者帶來煩惱，因為他們可能因為太多與其無關的應用程式而感到不知所措。

[將應用程式推送給終端使用者] 租用戶設定會控制允許自動安裝應用程式的人員。 建議您使用此功能，因為其對使用者而言非常方便。 但是，還建議您教育內容建立者使用它的時機，使其不會過度使用。

檢查清單：為內容檢視人員制定使用應用程式的策略時，關鍵決策和動作包括：

工作區檢視人員角色

如工作區規劃一文所述，工作區的主要用途是共同作業。 工作區共同作業者 (例如，語意模型建立者、報表建立者及測試人員) 應指派給下列三個角色之一：參與者、成員或管理員。內容建立者安全性規劃一文將描述這些角色。

您可以將工作區檢視人員角色指派給取用者。 允許取用者直接存取工作區中的內容，對於密切合作的小型團隊和非正式團隊來說頗具意義。

符合下列情況時，允許取用者直接存取工作區內容是個很好的選擇：

• 應用程式及其個別權限的正式形式並非必要。
• 檢視人員可以檢視儲存於工作區內的所有項目。
• 相較於每個項目權限，您希望更簡單地管理權限。
• 工作區使用者可能也會檢視應用程式 (已針對工作區發佈應用程式時)。
• 其目的是讓檢視人員在應用程式發佈內容之前先行檢閱。

以下是支援工作區檢視人員的一些建議。

• 組織每個工作區中的內容，讓報表取用者能夠輕鬆找到項目，並使其能夠與安全性完全保持一致。 工作區組織主題領域或專案通常運作良好。
• 將開發和測試內容與實際執行內容分開，讓檢視人員無法存取進行中的工作項目。
• 當您預期要處理許多存取要求時，則使用應用程式 (或每個項目權限)。 沒有適用於工作區的 [要求存取] 工作流程。

檢查清單：為內容檢視人員制定使用工作區的策略時，關鍵決策和動作包括：

每個項目權限

個別項目共用會為單一項目授與權限。 經驗較少的內容建立者通常會使用此技術作為主要共用技術，因為共用命令會醒目顯示在 Power BI 服務中。 基於這個理由，務必教育您的內容建立者，使其能夠了解各種共用選項，包括何時使用應用程式權限，而不是工作區角色。

符合下列情況時，每個項目權限就是個不錯的選擇：

• 您想要提供對某一個項目 (報表或儀表板) 的唯讀存取權。
• 您不希望取用者檢視發佈至某個工作區的所有內容。
• 您不希望取用者檢視發佈至某個應用程式對象的所有內容。

請謹慎使用每個項目權限，因為共用會為單一項目授與讀取權限。 在某種程度上，您可以將每個項目權限視為工作區角色或應用程式權限的覆寫。

使用每個項目權限來共用許多項目可能很繁瑣且容易發生錯誤，尤其是在與個別使用者 (而不是群組) 共用時。 請考慮下列案例：您具有 40 份報表，且已藉由使用同事的個別使用者帳戶來與之共用。 當某位同事調任到其他部門時，您必須撤銷其存取權，這將牽涉到編輯適用於所有 40 份報表的權限。

當您共用個別項目時，有數個權限選項。

• 再次共用權限：啟用時，使用者可以與其他使用者共用項目，包括其基礎語意模型。 當項目可以輕易地與任何人共用時，授與此權限是有意義的。 這樣會脫離管理該項目之個人或團隊的控制。 因此，其依賴獲授與再次共用權限的使用者所進行的良好判斷。 但是，允許再次共用時，您的內部治理或安全性指引可能會變得更難管理。
• 建置權限：啟用時，即會將基礎語意模型的建置權限授與使用者。 建置權限讓使用者能夠建立以語意模型為基礎的新內容。 此外，還允許他們從報表匯出基礎資料等等。 如需授與建置權限的考量，請參閱內容建立者安全性規劃一文。

與少數使用者共用內容時，適用於報表和儀表板的每個項目權限對於非正式案例來說可能很有意義。 最好改為教育使用者管理應用程式與工作區的權限，特別是當他們與大量使用者或團隊以外的使用者共用內容時。 請務必強調下列幾點。

• 判斷已與哪些使用者共用哪些內容會變得更困難，因為必須個別檢視每個報表和儀表板的權限。
• 在許多情況下，會設定再次共用權限，因為使用者體驗預設會啟用此選項。 因此，存在要將內容與一組比預期還要更廣泛的使用者共用的風險。 共用時取消核取 [允許收件者共用此報表] 選項，即可防止發生此結果。 使用此方式來將過度共用降至最低是一個使用者訓練問題。 設定共用權限的內容建立者每次都應考慮這個選項。
• 其他人可立即檢視針對報表和儀表板進行的所有變更，當內容修改正在進行時，這可能讓使用者感到混淆。 透過在應用程式中散發內容，或使用個別工作區來隔離開發、測試和實際執行內容，即可減緩此顧慮。 如需詳細資訊，請參閱自助內容發佈使用案例。
• 當使用者會從其個人工作區共用內容但其離開組織之後，IT 通常會停用其使用者帳戶。 在此情況下，共用內容的所有收件者都將立即失去對該內容的存取權。

共用有三種特定類型：共用連結、直接存取共用及共用的檢視。

每個項目權限連結

當您共用個別項目時，預設體驗會導致共用連結。 共用連結有三種類型。

• 組織中的人員：在您的 Power BI 租用戶設定中啟用時，這種類型的共用連結是為組織內每個人提供唯讀存取權的直接方式。 不過，共用連結不適用於外部使用者。 當所有人都可檢視內容時最適合使用此選項，而且整個組織都可自由共用該連結。 除非已透過 [允許可共用的連結授與您組織中所有人員的存取權] 租用戶設定停用，否則此類型的共用為預設值。
• 已有存取權的人員：此選項不會建立新的共用連結。 而是讓您能夠擷取 URL，以將其傳送給已有存取權的人員。
• 特定人員：此選項會針對特定使用者或群組產生共用連結。 建議您在大多數情況下使用此選項，因為它提供特定的存取權。 如果您通常會與外部使用者合作，則可針對已存在於 Microsoft Entra ID (先前稱為 Azure Active Directory) 中的來賓使用者使用這種類型的連結。 如需已規劃建立來賓使用者之邀請流程的詳細資訊，請參閱租用戶層級安全性規劃一文。

共用連結會將讀取權限新增至項目。 預設會選取再次共用權限。 您也可以在建立共用連結的同時，將建置權限新增至基礎語意模型。

共用連結比直接存取共用更容易維護，特別是當您需要進行大量變更時。 當個別使用者獲授與共用權限時，這是一個相當顯著的優勢，比群組更重要 (這通常發生在自助使用者負責管理權限時)。 請考慮下列比較。

• 共用連結：20 位個別使用者均獲授與共用連結的存取權。 透過對連結進行單一變更，其會對所有 20 位使用者產生影響。
• 直接存取：20 位人員均獲授與對項目的直接存取權。 若要進行變更，必須修改所有 20 個使用者權限。

每個項目直接存取權限

您也可以使用「直接存取」來實現每個項目權限。 直接存取牽涉到設定單一項目的權限。 您也可以判斷衍生自工作區角色的任何繼承權限。

當您為使用者授與直接存取時，他們也會獲授與項目的讀取權限。 預設會選取再次共用權限，如同適用於基礎語意模型的建置權限。 建議您教導內容建立者，只有在此報表的取用者也是可能需要從基礎語意模型建立報表、匯出資料或建立複合模型的內容建立者時，才啟用建置權限。

共用的檢視

使用共用檢視，與其他使用者共用報表的已篩選檢視方塊。 您可以使用共用連結或直接存取來發佈共用檢視。

共用檢視是一種暫時性概念。 其會在 180 天後自動過期。 基於這個理由，共用檢視最適合非正式和暫時性共用案例。 請確定您的使用者知道此限制。

檢查清單：制定使用每個項目權限的策略時，關鍵決策和動作包括：

其他取用者查詢技術

取用者與 Power BI 互動最常見的方式是透過應用程式、工作區及每個項目權限 (此文章先前所述)。

此外，還有其他技術可供取用者用來查詢 Power BI 資料。 下列每個查詢技術都需要語意模型或資料超市建置權限。

• 在 Excel 中進行分析：慣用 Excel 的取用者可以使用 [在 Excel 中進行分析] 來查詢 Power BI 語意模型。 此功能是將資料匯出到 Excel 的絕佳替代方案，因為資料不會重複。 透過與語意模型的即時連線，使用者可以建立樞紐分析表、圖表及交叉分析篩選器。 然後，他們可以將活頁簿發佈至 Power BI 服務中的工作區，讓取用者能夠開啟活頁簿並與其互動。
• XMLA 端點：取用者可以藉由連線到 XMLA 端點來查詢語意模型。 符合 XMLA 規範的應用程式可以連線到、查詢及取用儲存在 Premium 工作區中的語意模型。 當取用者想要使用 Power BI 語意模型作為 Microsoft 生態系統外部資料視覺效果工具的資料來源時，此功能很實用。
• 資料超市編輯器：取用者可以使用資料超市編輯器來查詢 Power BI 資料超市。 其是 Web 型視覺效果查詢編輯器，可用於建立無程式碼查詢。 當取用者偏好撰寫 SQL 查詢時，也有 Web 型 SQL 編輯器可供使用。 這兩個編輯器都會查詢受控的 Azure SQL Database，其以 Power BI 資料超市 (而不是內建語意模型) 為基礎。
• SQL 端點：取用者可以使用 SQL 端點來查詢 Power BI 資料超市。 他們可以使用 Azure Data Studio 或 SQL Server Management Studio (SSMS) 等工具來執行 SQL 查詢。 SQL 端點會將查詢導向到受控的 Azure SQL Database，其以 Power BI 資料超市 (而不是內建語意模型) 為基礎。

如需建置權限的詳細資訊，請參閱內容建立者安全性規劃一文。

檢查清單：規劃取用者將使用哪些查詢技術時，關鍵決策和動作包括：

為取用者要求存取工作流程

共用內容時，某位使用者將連結 (URL) 轉寄給另一位使用者的情況很常見。 當收件者嘗試檢視內容且發現其沒有存取權時，可選取 [要求存取] 按鈕。 此動作會起始 [要求存取] 工作流程。 然後要求使用者提供訊息，以說明他們想要存取的原因。

[要求存取] 工作流程因下列目的而存在：

• 存取 Power BI 應用程式。
• 存取報表或儀表板等項目。
• 存取語意模型。 如需可探索語意模型時 [要求存取] 工作流程的詳細資訊，請參閱內容建立者安全性規劃一文。

應用程式存取要求

有兩種方式可了解已針對應用程式提交的擱置存取要求。

• 電子郵件：應用程式的連絡人會收到電子郵件通知。 根據預設，此連絡人是應用程式發行者。 為了對重要應用程式提供更好的支援，建議您將連絡人設定為能夠快速回應存取要求的群組。
• 管理權限功能表：工作區管理員和成員可以檢視、核准或拒絕存取要求。 [管理權限] 頁面位於 [應用程式] 頁面上，可針對每個應用程式開啟。 啟用 [允許參與者更新此工作區的應用程式] 設定時，工作區參與者也可以使用此功能。

對應用程式的擱置存取要求會顯示使用者所提供的訊息。 每個擱置的要求都可能獲核准或遭到拒絕。 選擇核准要求時，必須選取應用程式對象。

下列螢幕擷取畫面顯示來自使用者的擱置存取要求。 若要核准要求，就必須選取下列兩個應用程式對象之一：「銷售代表」或「銷售領導」。

當您發佈應用程式時，會同時發佈內容和權限。 如先前所述，也不可能只發佈應用程式權限而不變更內容。 不過，有一個例外狀況：當您核准擱置存取要求時 (例如，上一個螢幕擷取畫面所示的存取要求)，會發生權限變更，而不會在工作區中發佈最新內容。

工作區存取要求

隸屬於管理員角色或成員角色的使用者會獲授與工作區存取權。

若嘗試檢視工作區的使用者不是工作區角色的成員，就會收到 [存取遭拒] 訊息。 由於工作區沒有內建的 [要求存取] 工作流程，因此最適合用來與小型團隊和非正式團隊密切合作。 這就是為什麼 Power BI 應用程式更適合較大型團隊和更廣泛的內容發佈案例的原因之一。

每個項目存取要求

有兩種方式可了解已針對個別項目 (例如報表) 提交的擱置存取要求。

• 電子郵件：該項目的連絡人會收到電子郵件通知。 為了對重要報表提供更好的支援，建議您將連絡人設定為能夠快速回應存取要求的群組。
• [管理權限] 功能表：工作區管理員和成員可以存取每個項目的 [管理權限] 頁面。 他們可以檢視、核准或拒絕存取擱置要求。

使用群組管理存取要求

當使用者針對 Power BI 項目 (例如，報表或語意模型) 或 Power BI 應用程式提交 [要求存取] 表單時，即會針對個別使用者提交要求。 不過，許多大型組織都需要使用群組來符合其內部安全性原則。

建議您在可行的情況下，使用群組 (而不是個人) 來保護內容。 如需規劃群組的詳細資訊，請參閱租用戶層級安全性規劃一文。

如果您想要向群組 (而非個別使用者) 提供存取權，處理存取要求的內容擁有者或管理員將需在多個步驟中完成要求：

1. 拒絕 Power BI 中的擱置要求 (因為其與個別使用者相關聯)。
2. 根據您目前的流程，將要求者新增至正確的群組。
3. 通知要求者他們現在具有存取權。

檢查清單：規劃 [要求存取] 工作流程時，關鍵決策和動作包括：

根據取用者身分識別強制執行資料安全性

您可以藉由強制執行資料安全性，規劃建立較少的語意模型和報表。 目標是根據正在檢視內容之使用者的身分識別來強制執行資料安全性。

例如，假設您可以與所有銷售人員 (取用者) 共用單一銷售報表，因為您知道每個銷售人員將只會看到自己區域的銷售結果。 透過此方法，您可以避免在「每個區域」建立個別報表 (需要與該銷售區域的銷售人員共用) 的複雜度。

某些組織對已認可 (經認證或推廣) 的語意模型或資料超市有特定需求。 對於將廣泛使用的資料，可能需要使用資料安全性。

您可以透過多種方式來實現資料安全性。

• Power BI 語意模型：身為 Power BI 資料建立者，您可以強制執行資料列層級安全性 (RLS) 和物件層級安全性 (OLS)。 RLS 牽涉到定義角色和篩選資料模型資料列的規則，而 OLS 會限制對特定資料表或資料行的存取。 這些定義的 RLS 和 OLS 規則不適用儲存於語意模型外部的參考，例如交叉分析篩選器和篩選選取項目。 此節稍後將進一步描述 RLS 和 OLS 技術。
• Analysis Services：即時連線語意模型可以連線到遠端資料模型，該模型由 Azure Analysis Services (AAS) 或 SQL Server Analysis Services (SSAS) 所裝載。 遠端模型可以根據取用者身分識別強制執行 RLS 或 OLS。
• 資料來源：某些資料來源 (例如 Azure SQL Database) 可以強制執行 RLS。 在此情況下，Power BI 模型可以利用現有的安全性，而不是重新定義它。 當來源中定義的 RLS 很複雜時，該方法可能是一個顯著的優點。 您可以開發並發佈 DirectQuery 模型，且在 Power BI 服務中設定語意模型的資料來源認證，以啟用單一登入 (SSO)。 當報表取用者開啟報表時，Power BI 會將其身分識別傳遞至資料來源。 然後，資料來源會根據報表取用者的身分識別來強制執行 RLS。 如需 Azure SQL Database RLS 的詳細資訊，請參閱這篇文章。

資料列層級安全性

資料列層級安全性 (RLS) 可讓資料建模者限制對資料子集的存取。 其通常用來確保某些報表取用者看不到特定資料，例如其他銷售區域的銷售結果。

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

設定 RLS 有兩個步驟：規則和角色對應。

RLS 規則

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

規則運算式會在資料列內容中進行評估。 資料列內容表示使用該資料列的資料行值來評估每個資料列的運算式。 當運算式傳回 TRUE 時，使用者就能看到該資料列。 您可以定義靜態或動態的規則。

• 靜態規則：使用參考常數的 DAX 運算式，例如 [Region] = "Midwest"。
• 動態規則：使用傳回環境值 (而不是常數) 的特定 DAX 函式。 環境值會從三個特定的 DAX 函式傳回：USERNAME、USERPRINCIPALNAME 和 CUSTOMDATA。 當模型資料表儲存使用者名稱值時，定義動態規則很簡單且有效。 這些規則可讓您強制執行資料驅動 RLS 設計。

RLS 角色對應

將模型發佈至 Power BI 服務之後，您必須在使用者存取相關報表之前設定角色對應。 角色對應涉及將 Microsoft Entra 安全性物件指派給角色。 安全性物件可以是使用者帳戶或安全性群組。

盡可能將角色對應至安全性群組是最佳做法。 如此一來，對應將會減少，而群組的擁有者就能處理群組成員資格管理。

建議您為內容建立者提供來自 Microsoft Entra 的安全性帳戶資訊。 選項之一是建立資料流程，且資料會與 Microsoft Entra ID 保持同步。 如此一來，內容建立者就可以整合資料流程資料來產生資料驅動的語意模型。

RLS 使用者體驗

有些組織除了標準 Power BI 權限之外，還會選擇刻意使用 RLS 作為第二層安全性。 請考慮下列案例：您與整個組織共用報表的連結。 檢視報表的任何使用者都必須對應至 RLS 角色，才能看見報表中的資料。 如果其未對應至 RLS 角色，則看不到任何資料。

RLS 的存在會變更取用者的預設體驗。

• 未針對語意模型定義 RLS 時：語意模型上「至少」具備讀取權限的建立者和取用者，可以檢視語意模型中的「所有資料」。
• 在語意模型上定義 RLS 時：語意模型上「僅」具備讀取權限的建立者和取用者，只能檢視允許其查看的資料 (根據其 RLS 角色對應)。

當使用者在工作區或應用程式中檢視報表時，RLS 可能會或可能不會根據其語意模型權限強制執行。 基於這個理由，在必須強制執行 RLS 時，內容取用者和建立者「只能」擁有基礎語意模型上的讀取權限，這一點至關重要。

以下是判斷是否要強制執行 RLS 的權限規則。

• 使用者具有語意模型上的讀取權限：針對使用者強制執行 RLS。
• 使用者具有語意模型上的讀取和建置權限：針對使用者強制執行 RLS。
• 使用者具有語意模型上的寫入權限：不會針對使用者強制執行 RLS，這表示他們可以看到語意模型中的所有資料。 寫入權限讓您能夠編輯語意模型。 其可透過下列兩種方式之一來授與：
  • 使用參與者、成員或管理員工作區角色 (適用於儲存語意模型所在的工作區)。
  • 使用每個項目寫入語意模型權限。

如需 RLS 的詳細資訊，請參閱限制對 Power BI 模型資料的存取。

適用於資料超市的 RLS

Power BI 資料超市也可以強制執行 RLS。 不過，實作則不同。

主要差異為適用於資料超市的 RLS 是在 Power BI 服務中設定，而不是在 Power BI Desktop 中設定。

另一個差異在於，資料超市會在語意模型及與該資料超市相關聯的受控 Azure SQL Database 上強制執行 RLS。 在這兩個層級上強制執行 RLS 可提供一致性和彈性。 不論使用者如何查詢資料、是否連線到語意模型或受控 Azure SQL Database，都會套用相同的 RLS 篩選。

如需詳細資訊，請參閱適用於資料超市的 RLS。

物件層級安全性

物件層級安全性 (OLS) 可讓資料建模者限制存取特定資料表和資料行及其中繼資料。 您通常會使用 OLS 來確保特定使用者看不到敏感性資料行 (例如員工薪資)。 儘管無法限制存取量值，但參考受限制資料行的任何量值本身都將受到限制。

請考慮員工資料表的範例。 其包含儲存員工名稱和電話號碼及薪資的資料行。 您可以使用 OLS 來確保只有某些使用者 (例如資深人力資源人員) 才能看到薪資值。 對於那些看不到薪資值的使用者，就好像該資料行不存在。

請小心，因為如果 Power BI 報表視覺效果包含薪資，則無法存取該欄位的使用者將收到錯誤訊息。 該訊息將通知他們物件不存在。 對這些使用者來說，報表看似已毀損。

Power BI Desktop 中目前沒有介面可設定 OLS。 您可以使用表格式編輯器，這是第三方工具，可用來建立、維護及管理模型。 如需詳細資訊，請參閱進階資料模型管理使用案例。

如需 OLS 的詳細資訊，請參閱限制對 Power BI 模型物件的存取。

檢查清單：規劃 RLS 和 OLS 時，關鍵決策和動作包括：

相關內容

在此系列的下一篇文章中，了解針對負責建立語意模型、資料流程、資料超市、報表或儀表板之內容建立者規劃的安全性。