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

  • 發行項

注意

本文構成Power BI實作規劃系列文章的一部分。 此系列主要著重於 Microsoft Fabric 內的 Power BI 工作負載。 如需系列簡介，請參閱 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 系統管理員 角色已重新命名。 角色的新名稱是 Fabric 系統管理員。

唯讀取用者的策略

在 Power BI 服務 中，取用者可以同時檢視報表或儀錶板：

  • 檢視包含視覺效果的Power BI專案（例如報表或儀錶板）。
  • 讀取基礎數據（語意模型，先前稱為數據集或其他來源）。

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

Power BI 應用程式和 Power BI 工作區查看器角色選項涉及管理一組項目的許可權。 這兩種個別專案許可權技術牽涉到管理一個個別項目的許可權。

提示

一般而言，對大多數取用者使用Power BI應用程式是最佳做法。 有時候，工作區查看器角色也可能是適當的。 Power BI 應用程式和工作區查看器角色都允許管理許多項目的許可權，並應盡可能使用。 管理個別項目的許可權可能很繁瑣、耗時且容易出錯。 相反地，管理一組專案可減少維護和改善精確度。

檢閱專案的安全性設定時，您可能會看到其許可權如下：

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

在下列螢幕快照中， 報表會顯示直接訪問許可權 。 在此實例中，工作區 管理員 和成員角色會分別指派給群組。 報表會顯示這些角色，因為報表層級存取繼承自工作區。 也有一位使用者直接套用至報表的讀取許可權。

Power BI 服務 中報表之直接訪問許可權的螢幕快照。

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

檢查清單 - 建立如何提供內容給唯讀取用者的策略時，關鍵決策和動作包括：

  • 評估您現有的唯讀取用者策略： 確認內容目前如何散發並共用給取用者。 識別是否有改進的機會。
  • 決定只讀取用者的策略： 考慮您的喜好設定是使用應用程式許可權、工作區角色或個別項目許可權。 如果需要變更以符合這些喜好設定，請建立改善計劃。

Power BI 應用程式許可權

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

  • 應用程式的瀏覽窗格提供簡單且直覺的用戶體驗。 相較於直接在工作區中存取內容，這是較好的體驗。
  • 內容可以邏輯方式組織成應用程式瀏覽窗格中的區段（例如資料夾）。
  • 取用者只能存取已針對其 物件明確包含在應用程式中的特定專案。
  • 其他資訊、檔或其他內容的連結可以新增至其物件瀏覽窗格。
  • 有內 建的要求存取 工作流程。

注意

本文中應用程式的所有參考都會參考 Power BI 應用程式。 其概念與 Power Apps 不同。 它與 Power BI 行動應用程式的概念也不同。 在本節中，重點在於組織應用程式，而不是範本應用程式。

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

提示

如需使用Power BI 應用程式進行廣泛內容發佈的詳細資訊，請參閱 企業BI 使用案例。 我們建議需要發佈內容的內容建立者考慮建立應用程式作為其第一選擇。

您可以與工作區角色分開管理應用程式許可權。 許可權的分隔有兩個優點。 它鼓勵：

  • 授與工作區存取權給內容建立者。 它包含積極共同作業內容的使用者，例如語意模型建立者、報表建立者和測試人員。
  • 將應用程式許可權授與取用者。 不同於工作區許可權，應用程式許可權一律是只讀的（或無）。

具有工作區存取權的所有使用者都可以自動檢視應用程式（當 Power BI 應用程式已針對工作區發佈時）。 由於此行為，您可以概念上將工作區角色視為 每個應用程式對象所 繼承。 某些具有工作區存取權的使用者也可以根據其指派的 工作區角色來更新Power BI 應用程式。

提示

如需工作區存取的詳細資訊，請參閱 內容建立者安全性規劃 文章。

使用應用程式將內容發佈至唯讀取用者是最佳選擇：

  • 您希望使用者只能檢視該 物件 可見的特定專案（而不是基礎工作區內的所有專案）。
  • 您想要個別管理應用程式與工作區的唯讀許可權。
  • 您想要比每個項目許可權更簡單的唯讀使用者許可權管理。
  • 您想要確保 針對取用者強制執行數據列層級安全性 （當他們具有基礎語意模型的唯讀許可權時）。
  • 您想要確保取用者在重新發佈應用程式之前，無法檢視新的和已變更的報表。

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

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

應用程式物件

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

  • 您有五份銷售報表，這些報表會散發給整個全球銷售組織的許多使用者。
  • 銷售代表的應用程式會定義一個物件。 此物件可以檢視五份報告中的三個。
  • 另一個物件是在銷售領導小組的應用程式中定義。 此物件可以檢視所有五份報表，包括銷售代表無法使用的兩份報表。

混合和比對內容和物件的功能具有下列優點。

  • 某些報表可供多個物件檢視。 因此，建立多個物件會移除跨不同工作區重複內容的需求。
  • 某些報表只能供一個物件使用。 因此，該物件的內容可以與其他相關內容位於相同的工作區中。

下列螢幕快照顯示具有兩個對象的應用程式： Sales Leadership 和 Sales Reps。 [管理物件存取] 窗格提供兩個安全組的銷售領導階層物件群組的存取權：Sales Leadership-北美洲 和 Sales Leadership-Europe。 銷售主管物件群組的螢幕快照中顯示的毛利率分析報告不適用於銷售代表物件群組。

Power BI 服務 中應用程式物件設定的螢幕快照。

注意

有時候會使用物件群組一詞。 這不是使用安全組的直接參考。 其中包含目標對象的成員，他們將在Power BI 應用程式內看到內容集合。 雖然您可以將個別使用者指派給物件，但最好盡可能指派安全組、Microsoft 365 群組或通訊群組。 如需詳細資訊，請參閱租用戶層級安全性規劃一文中的使用群組策略。

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

提示

使用應用程式物件的主要使用案例是定義不同使用者集合的特定許可權。 不過，使用物件時，您可以稍微有創意。 使用者可以是多個對象的成員，而且每個物件都會以次要功能表集的形式向應用程式的檢視者顯示。 例如，您可以建立名為 Start Here 的物件，其中包含如何使用應用程式、聯繫人人員、如何提供意見反應以及如何取得協助的相關信息。 或者，您可以建立名為 KPI 定義的 物件，其中包含數據字典。 提供這類資訊可協助新使用者，並改善 解決方案採用 工作。

應用程式許可權選項

當您建立 （或重新發佈） 應用程式時，每個物件都有 [ 管理物件存取 ] 窗格。 在該窗格中，有下列許可權可供使用。

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

在發佈應用程式時，新增語意模型重新共用或建置許可權的功能很方便。 不過，我們建議您考慮個別管理應用程式許可權和語意模型許可權。 以下是原因。

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

提示

如需何時使用個別數據工作區和報告工作區的詳細資訊，請參閱 工作區層級規劃 一文。

應用程式預安裝許可權

發佈 Power BI 應用程式之後，使用者通常需要 安裝 它，讓他們可以開啟它。 使用者可以從 Power BI 服務 的 [應用程式] 頁面，或使用他們從其他使用者收到的連結來安裝應用程式。 當應用程式至少包含一個物件時，他們就能夠找到應用程式（並安裝）。

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

將 應用程式推送至使用者租使用者 設定可控制可自動安裝應用程式的人員。 建議您使用這項功能，因為使用者很方便。 不過，我們也建議您在何時使用內容建立者上教育內容建立者，使其不會過度使用。

提示

發佈應用程式時，如果您選取自動安裝應用程式的選項，則無法將物件設定為整個組織（如果[ 推送應用程式至終端使用者租使用者 ] 設定已啟用）。

檢查清單 - 為內容檢視器使用應用程式建立策略時，關鍵決策和動作包括：

  • 決定使用應用程式的策略： 定義您如何使用應用程式的喜好設定。 請確定它符合唯讀取用者的整體策略。
  • 決定誰可以將應用程式發佈至整個組織： 決定哪些報表建立者能夠發佈至整個組織。 將 [ 將應用程式發佈至整個組織 租使用者] 設定，以配合此決策。
  • 決定誰可以將應用程式推送給用戶： 決定哪些 Power BI 報表建立者可以預先安裝應用程式。 將 [ 推送應用程式] 設定為終端使用者租用戶 設定，以配合此決策。
  • 為內容建立者建立和發佈指引： 提供內容建立者的文件和訓練。 包含最有效率地使用應用程式的需求和喜好設定。
  • 決定如何處理應用程式存取要求： 確定程式已就緒以指派聯繫人，並及時處理應用程式存取要求。

工作區查看器角色

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

您可以將工作區查看器角色指派給取用者。 允許取用者直接在工作區中存取內容，對於密切合作的小型小組和非正式小組來說，是有意義的。

允許取用者直接存取工作區內容是一個很好的選擇：

  • 應用程式具有個別許可權的正式性並非必要。
  • 檢視者可以檢視儲存在工作區內的所有專案。
  • 您想要比每個項目許可權更簡單的許可權管理。
  • 工作區使用者也可能檢視應用程式（當應用程式針對工作區發佈時）。
  • 其目的是讓檢視者在應用程式發佈內容之前先檢閱內容。

以下是支援工作區查看器的一些建議。

  • 組織每個工作區中的內容，讓報表取用者輕鬆找到專案，使其與安全性保持一致。 依主旨區域或項目進行工作區組織 通常運作良好。
  • 將開發和測試內容與生產內容分開，讓檢視者無法存取進行中的工作專案。
  • 當您預期要處理許多存取要求時，請使用應用程式（或個別項目許可權）。 工作區沒有 要求存取 工作流程。

檢查清單 - 為內容檢視器建立使用工作區的策略時，關鍵決策和動作包括：

  • 決定使用工作區查看器角色的策略： 定義您的喜好設定如何針對取用者使用工作區。 請確定它符合唯讀取用者的整體策略。
  • 為內容建立者建立和發佈指引： 提供內容建立者的文件和訓練。 包含如何更有效地使用工作區許可權的需求和喜好設定。

個別項目許可權

個別 項目共用 會將許可權授與單一專案。 較不有經驗的內容建立者通常會使用這項技術作為主要共用技術，因為共用命令會以醒目方式顯示在 Power BI 服務 中。 基於這個理由，請務必讓內容建立者瞭解不同的共享選項，包括何時使用應用程式許可權，而不是工作區角色。

當下列情況下，個別專案許可權是不錯的選擇：

  • 您想要提供一個專案（報表或儀錶板）的唯讀存取權。
  • 您不希望取用者檢視發佈至工作區的所有內容。
  • 您不希望取用者檢視發佈至應用程式物件的所有內容。

請謹慎使用個別專案許可權，因為共用會將讀取許可權授與單一專案。 有一種方式，您可以將個別專案許可權視為工作區角色或應用程式許可權的覆寫。

提示

建議您盡可能使用應用程式許可權。 接下來，請考慮使用工作區角色來啟用直接工作區存取。 最後，當每個項目的許可權符合上述準則時，請使用它們。 應用程式許可權和工作區角色都會指定內容集合的安全性（而不是個別專案），這是較佳的安全性做法。

使用個別專案許可權來共用許多專案可能會很繁瑣且容易出錯，尤其是在與個別用戶共用而不是 群組時。 請考慮此案例：您有 40 份報告，您已使用其個別使用者帳戶共用給同事。 當一位同事轉移至不同的部門時，您必須撤銷其存取權，這牽涉到編輯所有 40 份報告的許可權。

重要

從個人工作區共用內容應該不常完成。 個人工作區最適合非重要、非正式或暫時性的內容。 如果您有內容建立者經常從其個人工作區共用重要或重要內容的情況，您應該採取適當的動作，將內容移至標準工作區。 如需詳細資訊，請參閱 個人 BI 使用案例。

當您共用個別專案時，您有數個許可權選項。

  • 重新共用許可權： 啟用時，使用者可以與其他使用者共享專案，包括其基礎語意模型。 當專案可立即與任何人共用時，授與此許可權是有道理的。 它會從管理項目的個人或小組中移除控制項。 因此，它依賴獲得重新共用許可權的使用者的良好判斷。 不過，當允許重新共享時，您的內部治理或安全性指導方針可能會變得更加難以管理。
  • 建置許可權：啟用時，系統會將基礎語意模型的建置許可權授與使用者。 建置許可權可讓使用者建立以語意模型為基礎的新內容。 它也允許它們從報表匯出基礎數據等等。 授與組建許可權的考慮， 請參閱內容建立者安全性規劃 一文。

當與少數使用者共享內容時，報表和儀錶板的個別專案許可權對於非正式案例來說可能有意義。 最好改為教育使用者管理應用程式與工作區的許可權，特別是當他們將內容分享給小組外部的大量用戶或使用者時。 請務必強調下列幾點。

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

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

當您共用個別專案時，預設體驗會產生 共享連結。 共用連結有三種類型。

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

重要

建議您考慮限制 [允許共享連結] 將貴組織 租用戶設定中每個人的存取權授與群組成員。 您可以建立群組名稱，例如 Power BI共用至整個組織，然後新增少數瞭解整個組織共用含意的使用者。 如果您擔心現有的全組織連結，您可以使用 系統管理 API 來尋找已與整個組織共用的所有專案。

共用連結會將讀取許可權新增至專案。 預設會選取 [重新共用] 許可權。 您也可以在建立共用連結的同時，將建置許可權新增至基礎語意模型。

提示

建議您只有在報表取用者也是可能需要建立報表、匯出數據或從基礎語意模型建立複合模型的內容建立者時，才教內容建立者啟用建置許可權選項。

共用連結比直接存取共用更容易維護，特別是當您需要進行大量變更時。 當個別用戶獲授與共用許可權時，這一點相當重要（通常發生在自助用戶負責管理許可權時）。 請考慮下列比較。

  • 共享連結： 20 個個別用戶獲授與共享連結的存取權。 透過連結的單一變更，它會影響所有20位使用者。
  • 直接存取： 20 個人員會被授與專案的直接存取權。 若要進行變更，必須修改所有 20 個用戶權力。

個別專案直接訪問許可權

您也可以使用 直接存取來達成個別項目許可權。 直接存取牽涉到設定單一項目的許可權。 您也可以判斷任何衍生自 工作區角色的繼承許可權。

當您授與使用者直接存取權時，系統會將該專案的讀取許可權授與使用者。 默認會選取 [重新共用] 許可權，如同基礎語意模型的 [建置] 許可權。 建議您只有在此報表的取用者也是可能需要從基礎語意模型建立報表、匯出數據或建立複合模型的內容建立者時，才教導內容建立者啟用建置許可權。

提示

用戶體驗讓授與重新共用和建置許可權非常直接，但執行共用的用戶應該一律確認是否需要這些許可權。

共用的檢視

使用共享檢視來與另一位用戶共享報表的篩選檢視方塊。 您可以使用共享連結或直接存取來發佈共享檢視。

共用檢視是暫時的概念。 它們會在 180 天后自動到期。 因此，共用檢視最適合非正式和暫時共用案例。 請確定您的使用者知道這項限制。

檢查清單 - 建立使用個別項目許可權的策略時，關鍵決策和動作包括：

  • 決定使用共用功能的策略： 定義您的喜好設定，以瞭解如何使用個別項目許可權。 請確定它符合唯讀取用者的整體策略。
  • 決定誰可以發佈整個組織的連結： 決定哪些報表建立者能夠發佈整個組織的連結。 設定 [ 允許可共用連結] 以授與貴組織 租用戶設定中每個人的存取權，以配合此決策。
  • 為內容建立者建立和發佈指引： 為內容建立者提供文件和訓練，其中包含如何有效使用個別項目許可權的需求和喜好設定。 請確定它們清楚瞭解每個專案許可權的優點和缺點。 包含何時使用共用連結，以及何時使用直接存取共用的指引。

其他取用者查詢技術

取用者與 Power BI 互動的最常見方式是應用程式、工作區和個別項目許可權（本文先前所述）。

還有其他技術可供取用者用來查詢Power BI數據。 下列每個查詢技術都需要語意模型或 Datamart 組建許可權。

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

如需組建許可權的詳細資訊，請參閱 內容建立者安全性規劃 文章。

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

  • 為使用者使用使用 [在 Excel 中進行分析] 建立指引： 為取用者提供檔與訓練，以最佳方式重複使用現有的語意模型與 Excel。
  • 為使用者使用 XMLA 端點建立指引： 為取用者提供文件和訓練，以最佳方式重複使用 XMLA 端點的現有語意模型。
  • 為數據超市查詢的使用者建立指引： 針對取用者提供查詢 Power BI Datamarts 的可用技術的文件和訓練。

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

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

要求存取工作流程存在：

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

應用程式存取要求

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

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

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

下列螢幕快照顯示來自使用者的擱置存取要求。 若要核准它，必須選取兩個應用程式物件 之一 Sales Reps 或 Sales Leadership。

Power BI 服務 中 Power BI 應用程式的擱置要求螢幕快照。

當您發佈應用程式時，內容和許可權會同時發佈。 如先前所述，不需變更內容，就不可能只發佈應用程式許可權。 不過，有一個例外狀況：當您核准擱置的存取要求時（例如上一個螢幕快照所示的存取要求），許可權變更會在未發佈工作區中的最新內容的情況下發生。

工作區存取要求

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

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

每個專案存取要求

有兩種方式可以瞭解已針對個別專案提交的擱置存取要求，例如報表。

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

使用群組管理存取要求

當使用者提交 Power BI專案的要求存取 表單（例如報表或語意模型）或Power BI 應用程式時，會針對個別使用者提交要求。 不過，許多大型組織都需要使用群組來符合其內部安全策略。

建議您使用群組，而不是個人，隨時保護內容。 如需規劃群組的詳細資訊，請參閱 租用戶層級安全性規劃 一文。

如果您要提供群組而非個別使用者的存取權，處理存取要求的內容擁有者或系統管理員必須在多個步驟中完成要求：

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

提示

如需響應來自內容建立者之建置存取要求的資訊，請參閱 為建立者 要求存取工作流程。 它也包含使用表單進行存取要求的建議。

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

  • 判斷誰應該處理應用程式存取要求： 確定程式已就緒，以便及時處理應用程式存取要求。 請確定已將應用程式聯繫人指派給支援程式。
  • 判斷誰應該處理每個專案要求： 請確定進程已就緒，以便及時處理存取要求。 請確定已將聯繫人指派給每個專案以支援程式。
  • 包含在內容建立者的文件和訓練中： 確保內容建立者瞭解如何及時處理存取要求。 讓他們知道應該使用群組而不是個別使用者時如何處理要求。
  • 包含在文件和訓練中： 包含內容建立者如何有效管理存取要求的指引。 也包含取用者在其存取要求訊息中要包含哪些資訊的指引。

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

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

例如，假設您可以與所有銷售人員共用單一銷售報表（取用者），知道每個銷售人員只會看到其區域的銷售結果。 這種方法可讓您避免為每個區域建立個別報表的複雜度，這些報表需要與該銷售區域的銷售人員共用。

某些組織有經過背書（認證或升階）語意模型或 Datamarts 的特定需求。 對於將廣泛使用的資料，可能需要使用數據安全性。

您可以透過多種方式完成資料安全性。

  • 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 資料庫，可以強制執行 RLS。 在此情況下，Power BI 模型可以利用現有的安全性，而不是重新定義它。 當來源中定義的 RLS 很複雜時，這種方法可能會是一個顯著的優點。 您可以開發和發佈 DirectQuery 模型，並在 Power BI 服務 中設定語意模型的數據源認證，以啟用單一登錄 （SSO）。 當報表取用者開啟報表時，Power BI 會將其身分識別傳遞至數據源。 然後，資料來源會根據報表取用者的身分識別來強制執行 RLS。 如需 Azure SQL 資料庫 RLS 的詳細資訊，請參閱這篇文章。

注意

來源系統，例如 Azure SQL 資料庫，也可以使用檢視等技術來縮小使用者可以看到的內容。 雖然這是有效的技術，但與本節的重點無關。

資料列層級安全性

數據列層級安全性 （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。
  • 使用者具有語意模型的寫入許可權： 不會對用戶強制執行 RLS，這表示他們可以看到語意模型中的所有數據。 寫入許可權可讓您編輯語意模型。 其可透過下列兩種方式之一授與：

提示

如需如何使用個別工作區以讓 RLS 適用於內容建立者的詳細資訊，請參閱 受控自助 BI 使用案例。

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

適用於 datamarts 的 RLS

Power BI Datamarts 也可以強制執行 RLS。 不過，實作不同。

主要差異在於 datamarts 的 RLS 是在 Power BI 服務 中設定，而不是在 Power BI Desktop 中設定。

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

如需詳細資訊，請參閱 datamarts 的 RLS。

物件層級安全性

物件層級安全性 （OLS） 可讓數據模型器限制存取特定數據表和數據行及其元數據。 您通常會使用 OLS 來確保特定使用者看不到敏感性數據行，例如員工工資。 雖然無法限制對量值的存取，但參考受限制數據行的任何量值本身都會受到限制。

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

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

注意

您也可以在數據模型中定義 檢視方塊 。 檢視方塊會定義模型物件的可檢視子集，以協助為報表建立者提供特定的焦點。 檢視方塊不適合限制對模型物件的存取。 使用者仍然可以查詢數據表或數據行，即使看不到數據表或數據行。 因此，請考慮將檢視方塊視為使用者便利性，而不是安全性功能。

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

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

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

  • 決定使用 RLS 的策略： 請考慮您想要使用資料列層級安全性的使用案例和用途。
  • 決定 OLS 使用策略： 請考慮您想要使用物件層級安全性的使用案例和用途。
  • 請考慮認證內容的需求： 如果您有認證語意模型所需的程式，請決定是否要包含使用 RLS 或 OLS 的任何特定需求。
  • 建立和發佈使用者指引： 為使用者建立檔，其中包含使用 RLS 和 OLS 的需求和喜好設定。 描述如何在集中式位置中取得用戶對應資訊。
  • 更新訓練教材： 在用戶訓練教材中包含 RLS 和 OLS 需求和喜好設定的重要資訊。 提供範例讓使用者瞭解何時適合使用任一種數據安全性技術。

相關內容

在本系列中的下一篇文章中，瞭解負責建立語意模型、數據流、Datamarts、報表或儀錶板的內容建立者的安全性規劃。