Power BI 實作規劃：租用戶層級稽核

發行項
03/06/2024

注意

本文構成Power BI實作規劃系列文章的一部分。此系列主要著重於 Microsoft Fabric 內的 Power BI 體驗。如需系列簡介，請參閱 Power BI 實作規劃。

此租用戶層級稽核規劃文章主要針對：

Power BI 系統管理員： 負責監督組織中的 Power BI 的系統管理員。 Power BI 系統管理員可能需要與IT、安全性、內部稽核和其他相關小組共同作業。
卓越中心、IT和 BI 小組： 負責監督 Power BI 的小組。他們可能需要與 Power BI 系統管理員和其他相關小組共同作業。

重要

建議您密切關注 Power BI發行計劃，以瞭解稽核和監視功能的未來增強功能。

租用戶層級稽核解決方案的目的是擷取和分析部署到Power BI 租使用者之所有使用者、活動和解決方案的數據。此租用戶層級的稽核數據對於許多用途都很重要，可讓您分析採用工作、瞭解使用模式、教育使用者、支持使用者、降低風險、改善合規性、管理授權成本，以及監視效能。

建立安全且生產就緒的端對端稽核解決方案，是需要時間的重要專案。將其視為在商業智慧上建置商業智慧（BI on BI）。如需稽核數據為何如此有價值的相關信息，請參閱稽核和監視概觀。

如需以報表建立者為目標的報表層級稽核，請參閱報表層級稽核。

如需以數據建立者為目標的稽核數據資產，請參閱數據層級稽核。

本文的其餘部分著重於租用戶層級稽核。

提示

本文的主要重點是協助您規劃建立端對端稽核解決方案。由於本文中的內容會組織成四個階段，因此您需要跨多個階段的資訊。例如，您會在規劃使用服務主體的階段 1 中找到相關信息，以及階段 2 中有關必要條件和設定的資訊。

因此，建議您先閱讀整篇文章，以便熟悉相關內容。然後，您應該準備好以反覆的方式規劃和建置稽核解決方案。

當您計劃建置租用戶層級的稽核解決方案時，請規劃在下列四個階段上花費時間。

階段 1：規劃和決策
階段 2：必要條件和設定
階段 3：解決方案開發和分析
階段 4：維護、增強和監視

階段 1：規劃和決策

第一階段著重於規劃和決策。需要考慮許多需求和優先順序，因此我們建議您花足夠的時間瞭解本節中介紹的主題。目標是要做出良好的前期決策，讓下游階段順利執行。

描述階段 1 的流程圖，著重於建置租用戶層級稽核解決方案的規劃和決策。

需求和優先順序

在初始階段中，目標是找出最重要的專案。專注於最重要的事項，以及如何衡量組織中的影響。努力定義業務導向的需求，而不是以技術為導向的需求。

以下是您應該回答的一些問題。

您需要回答哪些關鍵問題？ 您可以探索大量的稽核數據。處理稽核的最有效方式是專注於回答特定問題。
您的採用和數據文化特性目標為何？ 例如，您可能有目標可增加組織中的自助 BI 內容建立者數目。在此情況下，您必須測量與建立、編輯和發佈內容相關的用戶活動。
目前有哪些立即風險？ 例如，您可能知道過去已過度共享內容。用戶訓練已增強，您現在想要持續稽核安全性設定和活動。
是否有目前的關鍵效能指標（KPI）或組織目標？ 例如，您可能有一個與數位轉型相關的組織 KPI，或成為更數據驅動的組織。租用戶層級的稽核數據可協助您測量 Power BI 實作是否符合這些目標。

提示

確認稽核需求，併為您的執行贊助者和卓越中心設定優先順序。擷取稽核數據並開始根據許多有趣的數據建立報告很誘人。不過，當稽核解決方案不是由您需要回答的問題和您想要採取的動作所驅動時，您不太可能從稽核解決方案衍生高價值。

如需使用稽核數據方式的詳細資訊，請參閱稽核和監視概觀。

檢查清單 - 識別需求和優先順序時，關鍵決策和動作包括：

識別需求： 收集和記錄稽核 Power BI 租使用者的主要商務需求。
設定需求的優先順序： 設定需求的優先順序，將它們分類為立即、短期、中期和長期（待辦專案）。
立即制定計劃： 就地設定計劃以開始收集數據，以便在您需要時可供使用。
定期重新評估需求： 建立計劃，定期重新評估需求（例如，每年兩次）。確認稽核和監視解決方案是否符合所述的需求。視需要更新計劃上的動作專案。

數據需求

定義需求和優先順序之後（先前所述），即可識別您需要的數據。本節涵蓋四種數據類別。

用戶活動數據
租使用者清查
使用者和群組數據
安全性數據

您所需的大部分數據都來自系統管理員 API，其提供有關 Power BI 租使用者的大量元數據。如需詳細資訊，請參閱本文稍後選擇使用者 API 或系統管理員 API 。

用戶活動數據

成為取得用戶活動相關數據的第一個優先順序。 用戶活動也稱為事件或作業，適用於各種用途。

通常，此數據稱為 活動記錄 檔或 事件記錄檔。從技術上說，有數種方式可以取得用戶活動數據（活動記錄是一種方法）。如需相關決策和活動的詳細資訊，請參閱本文稍後的存取用戶活動數據。

以下是用戶活動數據可以回答的一些常見問題。

尋找熱門使用者和熱門內容
- 最常檢視哪些內容，以及哪些使用者？
- 檢視內容的每日、每周和每月趨勢為何？
- 報表檢視是否呈上升或下降趨勢？
- 有多少用戶處於作用中狀態？
瞭解用戶行為
- 最常使用哪種類型的安全性（應用程式、工作區或個別項目共用）？
- 使用者最常使用瀏覽器或行動應用程式嗎？
- 哪些內容建立者最積極地發佈和更新內容？
- 哪些內容會發佈或更新、何時及由哪些使用者更新？
識別使用者教育和訓練機會
- 誰正在從個人工作區共用（太多）共用？
- 誰正在執行大量匯出？
- 誰會定期下載內容？
- 誰正在發佈許多新的語意模型，先前稱為數據集？
- 誰大量使用訂用帳戶？
改善治理和合規性工作
- 租用戶設定何時變更，以及哪些 Power BI 系統管理員？
- 誰開始了Power BI試用版？
- 外部使用者、誰、何時及如何存取哪些內容？
- 誰新增或更新敏感度標籤？
- 根據認證的語意模型，報表檢視的百分比為何？
- 語意模型支援多個報表的百分比為何？
- 網關或數據源何時建立或更新，以及由哪一位使用者建立或更新？

如需使用此數據方式的詳細資訊，請參閱瞭解使用模式。

重要

如果您尚未擷取和儲存使用者活動數據，請將其設為緊急優先順序。至少，請確定您擷取原始數據，並將其儲存在安全的位置。如此一來，當您準備好分析數據時，就會提供數據。歷程記錄可供 30 天或 90 天使用，視您使用的來源而定。

如需詳細資訊，請參閱本文稍後的存取用戶活動數據。

租使用者清查

通常，第二個優先順序是擷取數據以建立 租使用者清查。有時 稱為工作區清查、 工作區元數據或 租用戶元數據。

租使用者清查是在指定時間點的快照集。它會描述在租用戶中發佈的內容。租使用者清查不包含實際數據或實際報表。而是描述所有工作區及其專案的元數據（例如語意模型和報表）。

以下是租使用者清查可以回答的一些常見問題。

了解您擁有的內容和位置
- 哪些工作區具有最多的內容？
- 每個工作區中發佈哪些類型的內容（特別是當您分隔報表工作區和數據工作區時）？
- 項目之間存在哪些相依性（例如支援許多語意模型的數據流，或是其他複合模型的來源語意模型）？
- 什麼是數據譜系（Power BI 項目之間的相依性，包括外部數據源）？
- 是否有孤立報表（哪些報表與語意模型中斷連線？
瞭解語意模型與報表的比例
- 發生多少語意模型重複使用？
- 是否有重複或高度類似的語意模型？
- 是否有機會合併語意模型？
了解時間點之間的趨勢
- 報表數目會隨著時間增加嗎？
- 語意模型的數量是否隨著時間而增加？
尋找未使用的內容
- 哪些報告未使用（或使用量過低）？
- 哪些語意模型未使用（或未充分利用）？
- 是否有淘汰內容的機會？

租使用者清查可協助您在分析歷程記錄活動時使用目前的名稱。租使用者中專案的快照集包含該時間點的所有項目名稱。使用目前專案名稱進行歷程記錄報告會很有説明。例如，如果報表在三個月前重新命名，則活動記錄檔會記錄舊的報表名稱。使用正確定義的數據模型，您可以使用最新的租使用者清查，依其目前名稱來尋找專案（而非其先前的名稱）。如需詳細資訊，請參閱本文稍後的建立數據模型。

如需使用租使用者清查方式的詳細資訊，請參閱瞭解已發佈的內容。

提示

您通常會使用結合用戶活動事件（如上一節所述）和租使用者清查來產生完整圖片。如此一來，您就會增強所有數據的值。

由於租使用者清查是指定時間點的快照集，因此您必須決定擷取和儲存元數據的頻率。每周快照集有助於在兩個時間點之間進行比較。例如，如果您想要調查工作區的安全性設定，您需要先前的租使用者清查快照集、活動記錄事件，以及目前的租使用者清查快照集。

建置租使用者清查有兩個主要方式。如需相關決策和活動的詳細資訊，請參閱本文稍後的存取租使用者清查數據。

使用者和群組數據

隨著分析需求的增長，您可能會判斷您想要在端對端稽核解決方案中包含使用者和群組的相關數據。若要擷取該數據，您可以使用 Microsoft Graph，這是Microsoft Entra ID（先前稱為 Azure Active Directory）使用者和群組相關信息的權威來源。

從 Power BI REST API 擷取的數據報含描述使用者的電子郵件位址或安全組的名稱。此數據是指定時間點的快照集。

以下是Microsoft Graph 可以回答的一些常見問題。

識別使用者和群組
- 完整的使用者名稱（除了電子郵件位址）、部門或從使用者配置檔來源的位置為何？
- 安全組的成員是誰？
- 安全組的擁有者（管理成員）是誰？
取得其他用戶資訊
- 哪些授權—Power BI Pro 或 Power BI Premium Per User （PPU）— 會指派給使用者？
- 哪些使用者最常登入？
- 哪些使用者最近尚未登入 Power BI 服務？

警告

存取使用者和群組數據的一些較舊方法（已廣泛記載於在線）已被取代，不應使用。盡可能使用 Microsoft Graph 作為使用者和群組數據的權威來源。

如需如何從 Microsoft Graph 存取數據的詳細資訊和建議，請參閱本文稍後的存取使用者和群組數據。

安全性數據

您可能需要執行一般安全性稽核。

以下是 Power BI REST API 可以回答的一些常見問題。

識別人員和應用程式
- 使用者、群組或服務主體可以存取哪些報告？
- 哪些使用者、群組或服務主體是訂閱者，可接收具有電子郵件訂閱的報告？
瞭解內容許可權
- 哪些工作區角色會指派給哪些使用者和群組？
- 哪些使用者和群組會指派給每個 Power BI 應用程式物件？
- 指派哪些個別專案許可權、針對哪些報表，以及哪些使用者？
- 指派哪些個別專案許可權、針對哪些語意模型，以及哪些使用者？
- 哪些語意模型和數據超市已定義數據列層級安全性（RLS？
- 哪些專案會與整個組織中的人員共用？
- 哪些專案會在因特網上公開發佈？
瞭解其他許可權
- 誰有權使用部署管線發佈？
- 誰有權管理網關和數據連線？
- 誰有權管理 Premium 容量？

重要

本文有時是指 Power BI Premium 或其容量訂用帳戶（P SKU）。請注意，Microsoft目前正在合併購買選項，並淘汰每個容量 SKU 的 Power BI Premium。新的和現有的客戶應該考慮改為購買網狀架構容量訂用帳戶（F SKU）。

如需詳細資訊，請參閱 Power BI Premium 授權和 Power BI Premium 常見問題的重要更新。

提示

如需安全性的詳細資訊，請參閱安全性規劃文章。

這些常見問題不是詳盡的清單;有各種不同的Power BI REST API 可供使用。如需詳細資訊，請參閱使用Power BI REST API。

如需使用系統管理員 API 與使用者 API 的詳細資訊（包括它如何影響擷取數據之使用者所需的許可權），請參閱本文稍後選擇使用者 API 或系統管理員 API 。

檢查清單 - 識別稽核所需的數據時，關鍵決策和動作包括：

識別用戶活動數據的特定數據需求： 驗證您收集的需求。識別符合用戶活動數據之每個需求所需的稽核數據。
識別租使用者清查數據的特定數據需求： 驗證您收集的需求。識別編譯租使用者清查所需的稽核數據。
識別使用者和群組數據的特定數據需求： 驗證您收集的需求。識別符合使用者和群組數據之每個需求所需的稽核數據。
識別安全性數據的特定數據需求： 驗證您收集的需求。識別符合安全性數據每個需求所需的稽核數據。
驗證優先順序： 確認優先順序順序，以便您知道要先開發的內容。
決定擷取活動的頻率： 決定擷取活動事件的頻率（例如每天一次）。
決定擷取快照的頻率： 決定擷取快照集數據的間隔，例如租使用者清查或使用者和群組數據。

稽核解決方案的類型

租用戶層級稽核是以手動方式或自動化程式完成。

大部分新的稽核程式會以手動程序開始，特別是在開發期間，以及在測試期間發生。手動稽核程式可能會演變為自動化程式。不過，並非所有稽核程式都必須完全自動化。

手動稽核程式

手動稽核依賴用戶視需要執行的腳本和程式（通常是Power BI系統管理員）。如有需要，使用者會以互動方式執行查詢，以擷取稽核數據。

手動稽核最適合：

正在開發和測試的新腳本。
偶爾會有一次性的稽核需求。
探勘稽核需求。
不需要完整支援的不必要稽核程式。

自動化稽核程式

稽核週期性所需的數據應該自動化。它會依一般排程擷取和處理，也稱為 自動化程式。有時 稱為自動程式。

自動化程序的目標是要減少手動工作、降低錯誤風險、提高一致性，以及消除對個別使用者執行的相依性。

自動化稽核最適合：

稽核在生產環境中執行的程式。
以一般排程執行的自動進程。
已完整測試的腳本。
具有其他報表或相依於其作為數據源之其他程式的基本稽核程式。
記載和支援的稽核程式。

程式類型-手動或自動化-可能會影響您處理驗證的方式。例如，Power BI 系統管理員可能會針對手動稽核程式使用用戶驗證，但對自動化程式使用服務主體。如需詳細資訊，請參閱本文稍後的<判斷驗證方法 >。

提示

如果有一般、週期性，需要取得目前手動處理的稽核數據，請考慮投入時間將其自動化。例如，如果 Power BI 系統管理員每天手動執行腳本，以從 Power BI 活動記錄中擷取數據，則如果該人員在休假時生病或離開，就會有遺失數據的風險。

檢查清單 - 考慮要開發的稽核解決方案類型時，關鍵決策和動作包括：

決定每個新稽核需求的主要用途： 決定是否針對每個新需求使用手動或自動化程式。請考慮該決策是暫時或永久的。
建立如何自動化的計劃： 當它適用於特定稽核需求時，請建立計劃，以瞭解如何自動化、時機和依據誰。

許可權和責任

此時，您應該清楚瞭解您想要完成的工作，以及一開始需要的數據。現在是決定用戶權力以及角色和責任的好時機。

使用者權限

當您打算建置端對端稽核解決方案時，請考慮其他使用者需要存取資料的用戶許可權。具體來說，決定誰將被允許存取和檢視稽核數據。

以下是要考慮的一些考慮。

直接存取稽核數據

您應該決定誰可以直接存取稽核數據。有多種方式可以思考。

誰應該是Power BI系統管理員？ Power BI 系統管理員可以存取所有租用戶元數據，包括系統管理員 API。如需決定誰應該是Power BI系統管理員的詳細資訊，請參閱租用戶層級安全性規劃。
誰可以使用現有的服務主體？ 若要使用服務主體（而不是使用者許可權）來存取稽核數據，必須將密碼提供給授權的使用者，才能執行密碼型驗證。秘密的存取權（和密鑰）應該受到非常嚴格的控制。
存取是否需要嚴格控制？ 某些具有法規和合規性需求的產業必須比其他產業更嚴格地控制存取。
是否有大型活動數據磁碟區？ 若要避免達到 API 節流限制，您可能需要嚴格控制允許的人員直接存取產生稽核數據的 API。在此情況下，請務必確保不會重複或重疊的工作。

存取擷取的原始數據

您應該決定誰可以檢視擷取並寫入記憶體位置的原始數據。最常見的是，原始數據的存取僅限於系統管理員和稽核員。卓越中心（COE）也需要存取權。如需詳細資訊，請參閱本文稍後判斷儲存稽核數據的位置。

存取策劃的分析數據

您應該決定誰可以檢視已策劃和轉換的數據，這些數據已準備好進行分析。此數據一律可供系統管理員和稽核員使用。有時候數據模型可供組織中的其他使用者使用，特別是當您建立具有數據列層級安全性的 Power BI 語意模型時。如需詳細資訊，請參閱本文稍後規劃建立策劃的數據。

角色和責任

一旦您決定使用者權力的運作方式，您就處於開始思考角色和責任的良好位置。我們建議您儘早牽涉到正確的人員，特別是當多個開發人員或小組將參與建置端對端稽核解決方案時。

決定哪些使用者或小組將負責下列活動。

Role	責任類型	角色通常是由執行
與項目關係人溝通	通訊活動和需求收集。	COE 與IT合作。也可能包含來自主要業務單位的選取人員。
決定優先順序，並提供需求方向	與端對端稽核解決方案相關的決策活動，包括如何符合需求。	負責監督組織中Power BI的小組，例如COE。執行贊助者或數據控管指導委員會可能會參與做出重大決策或呈報問題。
擷取和儲存原始數據	建立腳本和程式以存取和擷取數據。也牽涉到將原始數據寫入記憶體。	數據工程人員，通常是在IT中，並與COE合作。
建立策劃的數據	數據清理、轉換，以及在星型架構設計中建立策劃的數據。	數據工程人員，通常是在IT中，並與COE合作。
建立數據模型	根據策劃的數據建立分析數據模型。	Power BI 內容建立者通常位於 IT 或 COE 中。
建立分析報告	建立報表以分析策劃的數據。根據新需求以及新的稽核數據可供使用時，報告的持續變更。	Power BI 報表建立者通常位於 IT 或 COE 中。
分析數據並處理結果	分析數據並採取行動以回應稽核數據。	負責監督組織中 Power BI 的小組，通常是 COE。也可能包含其他小組，視稽核結果和動作而定。其他小組可以包含安全性、合規性、法律、風險管理或變更管理。
測試和驗證	測試以確保符合稽核需求，且呈現的數據正確無誤。	Power BI 內容建立者，與監督組織中的 Power BI 小組合作。
保護數據	設定和管理每個儲存層的安全性，包括原始數據和策劃的數據。管理針對分析數據所建立的語意模型存取。	儲存數據的系統系統管理員，與監督組織中的Power BI小組合作。
排程和自動化	使用選擇的工具操作解決方案並排程程式。	數據工程人員，通常是在IT中，並與COE合作。
支持解決方案	監視稽核解決方案，包括作業執行、錯誤和支援技術問題。	處理 Power BI 系統支援的小組，通常是 IT 或 COE。

如果上述許多角色和責任將由同一個小組或同一人執行，則可以合併這些角色和責任。例如，您的Power BI系統管理員可能會執行其中一些角色。

視情況而定，不同的人員也可以執行不同的角色。動作會視稽核數據和建議的動作而定，內容相關。

請考慮數個範例。

範例 1： 稽核數據顯示某些用戶經常將數據匯出至 Excel。 採取動作： COE 會連絡特定使用者以瞭解其需求，並教導他們更好的替代方案。
範例 2： 稽核數據顯示外部使用者存取會以非預期的方式發生。 採取動作： IT 系統管理員會更新外部使用者存取的相關Microsoft專案標識碼設定。 Power BI 系統管理員會更新與外部使用者存取相關的租用戶設定。 COE 會更新管理安全性的內容建立者的文件和訓練。如需詳細資訊，請參閱外部使用者策略。
範例 3：稽核數據顯示，如果詳細的元數據租用戶設定允許，數個數據模型會以不同的方式定義相同的量值（可從元數據掃描 API 取得）。 採取動作： 數據控管委員會會啟動項目來定義一般定義。 COE 會更新建立數據模型的內容建立者的文件和訓練。 COE 也會與內容建立者合作，視需要更新其模型。如需擷取詳細元數據的詳細資訊，請參閱本文稍後的存取租使用者清查數據。

注意

數據擷取程式的設定通常是偶爾進行增強和疑難解答的一次性工作。分析和處理數據是一項持續的工作，需要持續進行的工作。

檢查清單 - 考慮許可權和責任時，關鍵決策和動作包括：

識別涉及哪些小組： 判斷哪些小組將參與端對端建立和支援稽核解決方案。
決定用戶權力： 決定如何設定用戶權力以存取稽核數據。建立重要決策的檔以供稍後參考。
決定角色和責任： 確保對誰執行哪些工作的期望是清楚的，尤其是在涉及多個小組時。建立角色和責任的檔，其中包括預期的動作。
指派角色和責任： 將特定角色和責任指派給特定人員或小組。適當時，使用人力資源更新個別工作描述。
建立訓練計劃： 在需要新技能時，為訓練人員建立計劃。
建立跨訓練計劃： 確定關鍵角色已備妥跨訓練和備份。

技術決策

當您規劃租用戶層級的稽核解決方案時，您必須做出一些重要的技術決策。若要改善一致性、避免重新作業並改善安全性，建議您儘早做出這些決策。

第一個規劃階段涉及做出下列決策。

選取可存取稽核數據的技術
判斷驗證方法
選擇使用者 API 或系統管理員 API
選擇 API 或 PowerShell Cmdlet
判斷儲存稽核數據的位置
規劃建立策劃的數據

選取可存取稽核數據的技術

您必須先決定如何存取稽核數據。

最簡單的開始使用方式是使用系統管理員監視工作區中可用的預先建置報告。

當您需要直接存取資料並建置自己的解決方案時，您將使用 API（應用程式程式介面）。 API 的設計目的是透過因特網交換數據。 Power BI REST API 支援使用 HTTP 通訊協定的數據要求。任何語言或工具都可以在能夠傳送 HTTP 要求及接收 JSON 回應時叫用 Power BI REST API。

提示

PowerShell Cmdlet 會使用 Power BI REST API 來存取稽核數據。如需詳細資訊，請參閱本文稍後的選擇 API 或 PowerShell Cmdlet 。

本節著重於您的技術選擇。如需存取 特定稽核數據類型 之來源的考慮，請參閱本文稍後的數據源決策。

平台選項

有許多不同的方式可以存取稽核數據。視您選擇的技術而定，您可能會傾向於慣用的語言。您可能也需要針對如何排程腳本的執行做出特定決定。技術在學習曲線上大相徑庭，而且容易開始使用。

以下是您可以使用 Power BI REST API 來擷取數據的一些技術。

技術	手動稽核程式的好選擇	自動稽核程式的好選擇
管理員監視工作區
試用
PowerShell
Power BI Desktop
Power Automate
慣用的 Azure 服務
慣用的工具/語言
Microsoft Purview 稽核記錄搜尋
適用於雲端應用程式的 Defender
Microsoft Sentinel

本節的其餘部分會簡短介紹表格中呈現的每個選項。

管理員監視工作區

系統管理員監視工作區包含 Power BI 服務中預先定義的報表和語意模型。這是網狀架構系統管理員和全域管理員檢視最近稽核數據的便利方式，並協助他們瞭解用戶活動。

在 API 檔中試用

試用是互動式工具，可讓您直接在 Microsoft 檔中體驗 Power BI REST API。這是探索 API 的簡單方式，因為它不需要其他工具或您電腦上的任何設定。

您可以使用 Try-it 來：

手動將要求傳送至 API，以判斷它是否傳回您想要的資訊。
在撰寫腳本之前，請先瞭解URL的建構方式。
以非正式的方式檢查數據。

注意

您必須是授權且已驗證的Power BI使用者，才能使用Try-it。它會遵循標準許可權模型，這表示使用者 API 依賴用戶權力，而系統管理員 API 需要 Power BI 系統管理員許可權。您無法使用服務主體向 Try-it 進行驗證。

因為它是互動式的，試用最適合學習、探索和新的手動稽核程式。

PowerShell 和 Azure Cloud Shell

您可以透過多種方式建立及執行 PowerShell 腳本。

以下是數個常見的選項。

Visual Studio Code： 新式輕量型原始碼編輯器。這是多個平臺上支持的免費開放原始碼工具，包括 Windows、macOS 和 Linux。您可以使用 Visual Studio Code 搭配多種語言，包括 PowerShell （使用 PowerShell 擴充功能）。
Azure Data Studio： 用來建立腳本和筆記本的工具。其建置在Visual Studio Code之上。 Azure Data Studio 可以獨立使用，或使用 SQL Server Management Studio （SSMS）。有許多延伸模組，包括PowerShell的擴充功能。
Azure Cloud Shell： 在本機使用 PowerShell 的替代方案。您可以從瀏覽器存取 Azure Cloud Shell 。
Azure Functions： 在本機使用 PowerShell 的替代方案。 Azure Functions 是一項 Azure 服務，可讓您在無伺服器環境中撰寫和執行程式代碼。 PowerShell 是它支援的數種語言之一。

重要

建議您針對所有新的開發工作使用最新版本的PowerShell（PowerShell Core）。您應該停止使用 Windows PowerShell（無法執行 PowerShell Core），並改用其中一個支援 PowerShell Core 的新式程式代碼編輯器。在參考許多使用 Windows PowerShell（5.1 版）的在線範例時，請小心，因為它們可能不會使用最新的（且較佳）的程式代碼方法。

您可以使用數種不同的方式使用PowerShell。如需此技術決策的詳細資訊，請參閱本文稍後的選擇 API 或 PowerShell Cmdlet 。

有許多在線資源可供使用PowerShell，而且通常可以找到能夠建立及管理PowerShell解決方案的有經驗的開發人員。 PowerShell 是建立手動和自動化稽核程式的絕佳選擇。

Power BI Desktop

因為 Power BI Desktop 可以連線到 API，所以您可能會想要使用它來建置稽核解決方案。不過，有一些顯著的缺點和複雜性。

累積歷程記錄： 因為Power BI活動記錄最多可提供30天的數據，因此建立整個稽核解決方案牽涉到累積一組儲存所有歷程記錄事件的檔案。累積歷程記錄檔比使用其他工具更容易完成。
安全地處理認證和金鑰： 許多從社群部落格作者在線找到的解決方案並不安全，因為它們在 Power Query 查詢中以純文本撰寫硬式認證和密鑰。雖然這種方法很簡單，但不建議這麼做，因為任何取得 Power BI Desktop 檔案的人都可以讀取這些值。除非您：除非下列專案，否則您無法在 Power BI Desktop 中安全地儲存密碼（使用使用者驗證時）或秘密（使用服務主體時）
- 使用使用 Power Query SDK 開發的自訂連接器。例如，自定義連接器可以從 Azure 金鑰保存庫或其他可安全地儲存加密值的服務讀取機密值。全球 Power BI 社群也有各種可用的自訂連接器選項。
- 使用適用於 Power BI Desktop 的 ApiKeyName 選項。不過，您無法將索引鍵值儲存在 Power BI 服務中。
要求類型： 您可以針對Power BI Desktop 中執行的內容，遇到一些限制。例如，Power Query 不支援每種 API 要求類型。例如，使用 Web.Contents 函式時，僅支援 GET 和 POST 要求。針對稽核，您通常會傳送 GET 要求。
重新整理的能力：您必須遵循特定的Power Query開發模式，才能在Power BI 服務中成功重新整理語意模型。例如，RelativePath使用 Web.Contents 時必須有選項，讓 Power BI 可以正確驗證數據源的位置，而不會在 Power BI 服務中產生錯誤。

在大部分情況下，我們建議您只針對兩個用途使用 Power BI Desktop。您應該使用它來：

根據現有的策劃數據來建置您的數據模型（而不是使用它來初步擷取稽核數據）。
根據您的數據模型建立分析報告。

Power Automate

您可以透過多種方式搭配Power BI使用 Power Automate 。在稽核方面，您可以使用Power Automate 將要求傳送至 Power BI REST API，然後將擷取的數據儲存在您選擇的位置。

提示

若要將要求傳送至 Power BI REST API，您可以使用 Power Automate 的自定義連接器安全地驗證和擷取稽核數據。或者，您可以使用 Azure 金鑰保存庫來參考密碼或密碼。這兩個選項都比在Power Automate流程中以純文字儲存密碼和秘密更好。

如需使用Power Automate的其他概念，請在Power Automate 樣本中搜尋 Power BI。

慣用的 Azure 服務

有數個 Azure 服務可將要求傳送至 Power BI REST API。您可以使用慣用的 Azure 服務，例如：

在大部分情況下，您可以結合計算服務來處理數據擷取的邏輯，以及儲存原始數據的記憶體服務（以及適當時策劃的數據）。本文稍後將說明進行技術架構決策的考慮。

慣用的工具和/或語言

您可以使用慣用的工具和慣用的語言，將要求傳送至 Power BI REST API。當您的小組具有特定工具或語言的專業知識時，這是一個很好的方法，例如：

Python
.NET Framework 上的 C#。您可以選擇性地使用 Power BI.NET SDK，其做為Power BI REST API 頂端的包裝函式，以簡化某些程式並提高生產力。
JavaScript

Microsoft Purview 稽核搜尋

Microsoft Purview 合規性入口網站（先前稱為 Microsoft 365 合規性中心）包含使用者介面，可讓您檢視和搜尋稽核記錄。統一稽核記錄包含 Power BI，以及支援 Microsoft 365 統一稽核記錄的其他所有服務。

在整合稽核記錄中擷取的數據與 Power BI 活動記錄中包含的數據完全相同。當您在 Microsoft Purview 合規性入口網站中執行稽核記錄搜尋時，它會將您的要求新增至佇列。可能需要幾分鐘的時間（或更長的時間，視數據量而定）才能準備好數據。

以下是使用稽核記錄搜尋工具的一些常見方式。您可以：

選取 Power BI 工作負載以檢視一系列日期的事件。
尋找一或多個特定活動，例如：
- 已刪除的Power BI報表
- 已新增Power BI中個人工作區的系統管理員存取權
檢視一或多個用戶的活動。

對於具有足夠許可權的系統管理員，Microsoft Purview 合規性入口網站中的稽核記錄搜尋工具是手動稽核程式的絕佳選項。如需詳細資訊，請參閱本文稍後的 Microsoft Purview 合規性入口網站。

適用於雲端的 Defender Apps 使用者介面

適用於雲端的 Defender 應用程式可供 Microsoft Defender 全面偵測回應系統管理員使用（Microsoft 365 入口網站）。其中包含使用者介面，可檢視和搜尋各種雲端服務的活動記錄，包括 Power BI。除了來自 Microsoft Entra ID 的使用者登入活動等其他事件之外，它也會顯示源自 Microsoft Purview 合規性入口網站的相同記錄事件。

適用於雲端的 Defender Apps 中的稽核記錄介面是手動稽核程式的絕佳選項。如需詳細資訊，請參閱本文稍後的適用於雲端的 Defender Apps。

Microsoft Sentinel 和 KQL

Microsoft Sentinel 是一項 Azure 服務，可讓您收集、偵測、調查及回應安全性事件和威脅。 Power BI 可以在 Microsoft Sentinel 中設定為數據連接器，以便將稽核記錄從 Power BI 串流至 Microsoft Sentinel Azure Log Analytics（這是 Azure 監視器服務的元件）。您可以使用 Kusto 查詢語言（KQL）來分析儲存在 Azure Log Analytics 中的活動記錄事件。

使用 KQL 來搜尋 Azure 監視器中的數據是檢視稽核記錄部分的好選項。這也是手動稽核程序的絕佳選項。如需詳細資訊，請參閱本文稍後的 Microsoft Sentinel 。

平台考量

以下是存取稽核數據的一些考慮。

您要實作手動或自動化稽核程式嗎？ 某些工具會與手動處理或自動化處理緊密配合。例如，使用者一律會以互動方式執行 Try-it 功能，因此它只適合手動稽核程式。
您要如何驗證？ 並非所有選項都支援每個驗證選項。例如，Try-it 功能僅支援用戶驗證。
如何安全地儲存認證？ 不同的技術有不同的儲存認證選項。如需詳細資訊，請參閱本文稍後的<判斷驗證方法 >。
您的小組已經熟悉哪一種技術？ 如果您的小組偏好並熟悉使用的工具，請從該處開始。
您的小組支持什麼？ 如果不同的小組將支援已部署的解決方案，請考慮該小組是否能夠充分支援它。也請考慮您的內部小組可能支持顧問所完成的開發。
您有核准要使用的工具為何？ 某些工具和技術可能需要核准。這可能是因為成本。也可能是因為IT安全策略。
您的排程偏好為何？ 某些技術會為您做出決策。其他時候，這將是另一個您必須做出的決定。例如，如果您選擇撰寫PowerShell腳本，有各種方式可以排程執行。相反地，如果您使用 Azure Data Factory 等雲端服務，則會內建排程。

建議您先檢閱本文的其餘部分，再選擇技術來存取稽核數據。

檢查清單 - 決定要用來存取稽核數據的技術時，關鍵決策和動作包括：

與您的IT人員討論： 與IT小組交談，以瞭解是否有某些已核准或偏好的工具。
探索具有小型概念證明的選項（POC）： 使用技術 POC 進行一些實驗。一開始專注於學習。然後專注於您決定未來使用的內容。

判斷驗證方法

您打算如何設定驗證是關鍵決策。當您開始使用稽核和監視時，通常是其中一個最困難的層面。您應該仔細考慮可用的選項，以做出明智的決策。

重要

請洽詢 IT 和安全性小組，以取得此事。花時間瞭解Microsoft Entra ID 安全性運作方式的基本概念。

因特網上的每個 API 都不需要驗證。不過，所有 Power BI REST API 都需要驗證。當您存取租用戶層級稽核數據時，驗證程式是由 Microsoft 身分識別平台管理。它是以業界標準通訊協議為基礎的Microsoft Entra 身分識別服務演進。

提示

詞彙 Microsoft 身分識別平台詞彙是一項資源，可協助您熟悉基本概念。

在擷取稽核數據之前，您必須先 進行驗證，這稱為登入。驗證和授權的概念是分開的，但相關。驗證程式會驗證發出要求的人員身分識別。授權程式會藉由驗證使用者或服務主體有權執行哪些動作，來授與或拒絕系統或資源的存取權。

當使用者或服務主體驗證時，Microsoft Entra 存取令牌會發行至資源伺服器，例如 Power BI REST API 或 Microsoft Graph API。根據預設，存取令牌會在一小時后到期。如有需要，可以要求重新整理令牌。

存取權杖有兩種類型：

使用者令牌： 代表具有已知身分識別的用戶發出。
僅限應用程式令牌： 代表Microsoft Entra 應用程式發行（服務主體）。

如需詳細資訊，請參閱 Microsoft Entra ID 中的應用程式和服務主體物件。

注意

Microsoft Entra 應用程式是一種身分識別設定，可讓自動化程式與 Microsoft Entra 標識符整合。在本文中，稱為 應用程式註冊。本文中也會使用服務主體一詞。本節稍後會更詳細地說明這些詞彙。

提示

驗證最簡單的方式是從 Power BI 管理模組使用 Connect-PowerBIServiceAccount Cmdlet。您可能會在線上文章和部落格文章中看到其他與驗證相關的 Cmdlet。例如，有 Login-PowerBI 和 Login-PowerBIServiceAccount Cmdlet 是 Cmdlet 的 Connect-PowerBIServiceAccount 別名。此外還有 Disconnect-PowerBIServiceAccount Cmdlet，可用來在處理程式結尾明確註銷。

下表描述兩個驗證選項。

驗證類型	說明	適用於	手動稽核程式的好選擇	自動稽核程式的好選擇
使用者驗證	使用使用者主體名稱（電子郵件位址）和密碼，以使用者身分登入。	偶爾使用互動式
服務主體驗證	使用指派給應用程式註冊的秘密（金鑰）以服務主體身分登入。	進行中、排程、自動操作

下一節會詳細說明每個驗證選項。

使用者驗證

在下列情況下，用戶驗證很有用。

手動稽核程式： 您想要使用您的用戶權力來執行腳本。根據 API 要求的類型而定，許可權可能位於兩個層級的其中一個：
- 系統管理員 API 的系統管理員許可權： 您必須使用 Power BI 系統管理員許可權，將要求傳送給 系統管理員 API。
- 使用者 API 的使用者許可權： 您必須使用 Power BI 用戶權力，將要求傳送給 使用者 API。如需詳細資訊，請參閱選擇使用者 API 或系統管理員 API。
互動式登入： 您想要以互動方式登入，這需要您輸入電子郵件地址和密碼。例如，您必須以互動方式登入，才能使用 Microsoft API 檔中找到的 Try-it 體驗。
追蹤存取租使用者元數據的人員： 當個別使用者和系統管理員傳送 API 要求時，您可能會想要稽核這些人是誰。當您使用服務主體進行驗證時（如下所述），活動記錄所擷取的使用者標識碼是應用程式標識碼。如果多個系統管理員使用相同的服務主體進行驗證，可能很難知道哪些系統管理員存取了數據。
共享系統管理員帳戶： 某些IT小組會使用共享系統管理員帳戶。視實作和控制方式而定，它可能不是最佳做法。您應該考慮使用 Microsoft Entra Privileged Identity Management （PIM），以授與用戶偶爾和暫時的 Power BI 系統管理員許可權，而不是共用帳戶。
僅支援使用者驗證的 API： 有時候，您可能需要使用不支援服務主體驗證的 API。在檔中，每個 API 都會指出服務主體是否可以呼叫它。

重要

建議您盡可能使用服務主體驗證來進行自動化程式。

服務主體驗證

大部分的組織都有一個Microsoft Entra 租使用者，因此應用程式註冊和服務主體的條款通常會交替使用。當您註冊 Microsoft Entra 應用程式時，有兩個元件。

應用程式註冊：應用程式註冊是全域唯一的。它是註冊Microsoft Entra 應用程式的全域定義，可供多個租使用者使用。應用程式註冊也稱為 用戶端應用程式 或 動作專案。一般而言，用戶端應用程式一詞表示用戶計算機。不過，這不是應用程式註冊的情況。在 Azure 入口網站中，Microsoft Entra 應用程式可在 Microsoft Entra 識別碼的 [應用程式註冊] 頁面上找到。
服務主體：服務主體是應用程式註冊的本機表示法，以用於您的特定租使用者。服務主體衍生自已註冊的 Microsoft Entra 應用程式。對於具有多個Microsoft Entra 租用戶的組織，多個服務主體可以參考相同的應用程式註冊。在 Azure 入口網站中，您可以在 [企業應用程式] 頁面上找到服務主體，Microsoft Entra ID。

因為服務主體是本機表示法，因此服務主體驗證一詞是參考登入的最常見方式。

提示

您的Microsoft Entra 系統管理員可以告訴您誰允許在組織中建立及同意應用程式註冊。

在下列情況下，服務主體驗證很有用。

自動化稽核程式： 您想要依排程執行自動程式。
不需要登入 Power BI 服務：您只需要連線及擷取數據。服務主體無法登入 Power BI 服務。
共用數據存取權： 您（個人而言）不是 Power BI 系統管理員，但已獲授權使用服務主體。服務主體有權執行系統管理員 API 來擷取租用戶層級數據（或其他特定許可權）。
由多個系統管理員使用： 您想要允許多個系統管理員或使用者使用相同的服務主體。
技術封鎖程式： 有一個技術封鎖程式可防止使用用戶驗證。常見的技術封鎖程式包括：
- 多重要素驗證（MFA）： 啟用多重要素驗證時，無法使用使用者帳戶進行自動化稽核程式（自動執行）。
- 密碼哈希同步處理： Microsoft Entra ID 需要使用者帳戶進行密碼哈希同步處理才能進行驗證。有時候，IT 或網路安全小組可能會停用此功能。

應用程式註冊用途和命名慣例

每個應用程式註冊都應該有清楚的名稱，描述其用途和目標物件（誰可以使用應用程式註冊）。

請考慮實作命名慣例，例如：<工作負載> - 目的> - <<目標物件> - <對象類型>

以下是命名慣例的部分。

工作負載： 通常相當於數據源（例如 Power BI 數據或Microsoft Graph 數據）。
目的： 類似於許可權層級（例如，讀取與 ReadWrite）。如下所述，當您建立只能讀取數據的個別應用程式註冊時，目的可協助您遵循最低許可權原則。
目標物件： 選擇性。視工作負載和用途而定，目標物件可讓您判斷應用程式註冊的預期使用者。
為了清楚起見，包含物件類型：EntraApp 。

當您有多個租使用者或多個環境（例如開發和生產環境）時，命名慣例可以更具體。

下表顯示可用來擷取租用戶層級稽核數據的應用程式註冊範例：

應用程式註冊名稱	用途	目標受眾
PowerBIData-Read-AdminAPIs-EntraApp	擷取全租用戶元數據，以稽核和管理 Power BI。系統管理 API 一律為唯讀，而且可能沒有Microsoft Entra ID 中授與的許可權（僅限 Power BI 租用戶設定）。	Power BI 系統管理員和卓越中心
PowerBIData-ReadWrite-PowerBIAdministrators-EntraApp	管理 Power BI 租使用者。需要讀取/寫入許可權才能建立或更新資源。	Power BI 系統管理員和卓越中心
GraphData-Read-PowerBIAdministrators-EntraApp	擷取使用者和群組數據，以進行Power BI的稽核和管理。需要讀取許可權。	Power BI 系統管理員和卓越中心

針對不同用途管理多個應用程式註冊牽涉到更多工作。不過，您可以受益於數個優點。

查看應用程式註冊的用途，以及原因：當您看到來自應用程式註冊的用戶端標識碼顯示在稽核數據中時，您將瞭解其用途和原因。這是建立個別應用程式註冊的重要優點（而不是只針對所有用途使用一個註冊）。
查看應用程式註冊的用途：當您看到來自應用程式註冊的用戶端識別符顯示在稽核數據中時，您將瞭解誰正在使用它。
避免過度布建許可權：您可以遵循最低許可權原則， 將不同的應用程式註冊提供給不同需求的不同人員集。當不需要寫入許可權時，您可以使用唯讀應用程式註冊來避免過度布建許可權。例如，您可能有一些高度可用的自助使用者想要收集其語意模型的相關數據;他們需要具有讀取許可權的服務主體存取權。而財務團隊可能有以程序設計方式管理語意模型的卓越中心附屬成員：他們需要具有寫入許可權的服務主體存取權。
知道誰應該擁有秘密： 每個應用程式註冊的秘密應該只與需要秘密的人員共用。輪替秘密時（本節稍後所述），當您針對不同需求使用不同的應用程式註冊時，影響較小。當您需要輪替秘密時，這很有説明，因為使用者離開組織或變更角色。

應用程式註冊許可權

應用程式註冊有兩種主要方式可以存取數據和資源。它牽涉到許可權和同意。

僅限應用程式的許可權： 存取權和授權是由服務主體處理，而不需要登入的使用者。驗證方法對自動化案例很有説明。使用僅限應用程式的許可權時，請務必瞭解在 entra 標識碼 Microsoft中未指派許可權。相反地，許可權會以下列兩種方式之一指派：
- 執行系統管理員 API： 某些 Power BI 租使用者設定允許存取系統管理員 API 的端點（傳回整個租使用者的稽核元數據）。如需詳細資訊，請參閱本文稍後的設定Power BI租用戶設定。
- 針對執行使用者 API： 適用於 Power BI 工作區和項目許可權。標準 Power BI 許可權可控制在執行使用者 API 時，哪些數據可以傳回至服務主體（根據叫用 API 之使用者或服務主體的許可權傳回稽核數據）。
委派的許可權： 使用範圍型許可權。服務主體會代表目前登入的使用者存取數據。這表示服務主體無法存取任何超過登入用戶可存取的專案。請注意，這與先前所述的僅限用戶驗證不同。由於需要自定義應用程式才能正確處理使用者和應用程式許可權的組合，因此委派的許可權很少用於稽核案例。這個概念通常被誤解，導致許多過度布建許可權的應用程式註冊。

重要

在本文中，焦點僅限於使用者驗證或僅限應用程式驗證。委派的許可權（具有互動式使用者和服務主體）可以在以程序設計方式內嵌 Power BI 內容時扮演重要角色。不過，我們強烈建議您不要設定委派的許可權來擷取稽核數據。每個 API 都會限制它可以執行的頻率（就地進行節流），因此讓不同的使用者直接存取原始稽核數據並不實用。相反地，我們建議您擷取原始稽核數據一次（使用集中式程式），然後讓策劃的稽核數據可供下游授權的使用者使用。

如需詳細資訊，請參閱本文稍後的註冊Microsoft Entra 應用程式。

應用程式註冊秘密

應用程式註冊通常會 將秘密 指派給它。秘密會作為驗證的金鑰，而且有到期日。因此，您必須規劃如何定期輪替密鑰，以及如何將新金鑰傳達給授權的使用者。

您也需要擔心要安全地儲存秘密的位置。組織密碼保存庫，例如 Azure 金鑰保存庫，是絕佳的選擇。

提示

作為使用秘密的替代方法，您可以使用受控識別。受控識別不需要管理認證。如果您想要使用 Azure Functions 或 Azure Data Factory 等服務來擷取數據，受控識別是調查的好選項。

安全地管理認證

無論您使用使用者驗證或服務主體驗證，其中一個最大的挑戰是如何安全地管理密碼、秘密和密鑰。

警告

第一個規則是許多人違反的規則：密碼和密鑰不應該以純文字出現在腳本中。在線的許多文章、部落格和範例都為了簡單起見而這樣做。然而，這是一個糟糕的做法，應該避免。任何取得腳本（或檔案）的人都可以存取作者有權存取的相同數據。

以下是數個可用來管理密碼、秘密和金鑰的安全方法。

盡可能與 Azure 金鑰保存庫或其他組織密碼保存庫系統整合。
在 PowerShell 腳本中使用認證和安全字串。認證適用於使用者驗證和服務主體驗證。不過，針對使用者帳戶啟用多重要素驗證時，您無法使用認證。
在 PowerShell 腳本中提示輸入密碼，或搭配瀏覽器使用互動式驗證。
針對Microsoft所發行的 PowerShell 使用秘密管理模組。它可以使用本機保存庫來儲存值。它也可與遠端 Azure 金鑰保存庫整合，這在組織中有多個使用相同腳本的系統管理員時很有用。
建立 Power BI Desktop 的自定義連接器，以便安全地處理認證。某些自定義連接器可從社群成員取得（通常是在 GitHub 上）。

提示

建議您洽詢 IT 和安全性小組，以協助選擇最佳方法，或驗證您的解決方案以安全的方式管理認證。

Microsoft 驗證資源庫

Azure AD 驗證連結庫的支援已於 2022 年 12 月結束。接下來，您應該使用 Microsoft 驗證連結庫（MSAL）。您組織中的安全性小組應該熟悉這項重大變更。

雖然 Power BI 專業人員對深入了解轉換至 MSAL 並不重要，但您應該遵守下列建議。

當您使用 Connect-PowerBIServiceAccount PowerShell Cmdlet 進行驗證時，請使用最新版的 Power BI 管理模組。它在 1.0.946 版中從 ADAL 切換至 MSAL（2021 年 2 月 26 日）。
當您直接在腳本中驗證時，請使用 Microsoft Entra V2 端點。 Microsoft Entra V2 端點使用 MSAL，而 Microsoft Entra V1 端點則使用 ADAL。
停止使用已被取代的 API 和模組。如需詳細資訊，請參閱本文稍後已淘汰的 API 和模組。
如果您在在線找到社群解決方案，請確定其使用 MSAL 進行驗證，而不是 ADAL。

檢查清單 – 決定如何管理驗證時，金鑰決策和動作包括：

決定要使用的驗證類型： 根據您計劃建立的稽核解決方案類型，判斷使用者驗證或服務主體驗證是否最適合。
規劃您需要的應用程式註冊： 考慮您的需求、工作負載和目標物件（每個應用程式註冊的使用者）。規劃您需要建立多少應用程式註冊以支持這些需求。
建立應用程式註冊的命名慣例： 設定命名慣例，讓您輕鬆瞭解每個應用程式註冊的預期用途和預定使用者。
規劃如何安全地管理認證： 請考慮安全地管理密碼、秘密和密鑰的方法。請考慮可能需要哪些文件和訓練。
確認 MSAL 的使用： 判斷是否有任何依賴 ADAL 的現有手動或自動化稽核解決方案。如有必要，請建立計劃來重寫這些解決方案，以使用較新的 MSAL 驗證連結庫。

選擇使用者 API 或系統管理員 API

規劃擷取稽核數據時，請務必使用正確的 API 類型。

需要考慮兩種類型的 API。

使用者 API： 依賴登入使用者的許可權（或服務主體）將要求傳送至 API。例如，傳回工作區中語意模型清單的其中一種方式是使用使用者 API。讀取語意模型的許可權可由工作區角色或個別項目許可權授與。有兩種方式可執行使用者 API：
- 用戶驗證： 登入的用戶必須具有存取工作區或項目的許可權。
- 服務主體驗證： 服務主體必須具有存取工作區或項目的許可權。
系統管理員 API： 從租用戶擷取元數據。有時稱為 組織範圍。例如，若要傳回租使用者中所有語意模型的清單，您可以使用系統管理 API。有兩種方式可執行系統管理員 API：
- 用戶驗證： 登入的用戶必須是Power BI系統管理員，才能執行系統管理員 API。
- 服務主體驗證： 服務主體必須具有執行系統管理員 API 的許可權（不需要依賴使用者 API 之類的安全性許可權）。

提示

所有系統管理員 API 都屬於管理作業群組。任何具有 「系統管理員 後綴」的 API 都是系統管理員 API;其餘所有 API 都是使用者 API。

請考慮您需要取得語意模型清單的範例。下表顯示可用來執行此作業的六個 API 選項。四個選項是使用者 API，兩個選項是系統管理員 API。傳回的專案範圍和數目會根據您選擇的 API 而有所不同。

API 名稱	API 的類型	Scope	語意模型數目
取得數據集	User	個人工作區	一
取得數據集	User	個人工作區	全部
在群組中取得數據集	User	一個工作區	一，前提是已登入的用戶有權讀取語意模型
在群組中取得數據集	User	一個工作區	只要登入的使用者具有讀取每個語意模型的許可權，則全部都已登入
以系統管理員身分取得群組中的數據集	管理	一個工作區	全部
以系統管理員身分取得數據集	管理	整個租使用者	全部

注意

某些 API 名稱包含群組一詞作為工作區的參考。該詞彙源自原始的Power BI安全性模型，該模型依賴Microsoft 365個群組。雖然 Power BI 安全性模型多年來已大幅發展，但現有的 API 名稱會保持不變，以避免中斷現有的解決方案。

如需租用戶設定的相關信息，請參閱本文稍後的設定Power BI租用戶設定。

檢查清單 - 選擇使用使用者 API 或系統管理 API 時，關鍵決策和動作包括：

請參閱數據需求： 收集和記錄稽核解決方案的主要商務需求。根據所需的數據類型，判斷使用者範圍或組織範圍是否適當。
測試結果： 進行一些實驗。測試不同 API 所傳回結果的正確性。
檢閱許可權： 針對任何現有的稽核解決方案，請確認已為Power BI系統管理員和服務主體正確指派許可權。針對新的稽核解決方案，請確認將使用哪一種驗證方法。

選擇 API 或 PowerShell Cmdlet

要做出的關鍵決策是，當 PowerShell Cmdlet 可供您想要擷取的特定數據使用時，是否要使用 PowerShell Cmdlet。如果您決定PowerShell是用來存取稽核數據的技術之一，則此決策很重要。

PowerShell 是工作自動化解決方案。 PowerShell 一詞是參考腳本語言、命令行殼層應用程式和組態管理架構的集體詞彙。 PowerShell Core 是最新版的 PowerShell，可在 Windows、Linux 和 macOS 上執行。

PowerShell Cmdlet 是執行動作的命令。 PowerShell 模組是包含 PowerShell 成員的套件，例如 Cmdlet、提供者、函式、工作流程、變數和別名。您下載並安裝模組。

PowerShell 模組會透過 API 建立抽象層。例如， Get-PowerBIActivityEvent Cmdlet 會擷取 Power BI 租使用者的稽核事件（或取得）。此 PowerShell Cmdlet 會從取得活動事件 REST API 擷取其數據。一般而言，使用 Cmdlet 較簡單，因為它可簡化基礎 API 的存取。

只有一部分 API 可用為 PowerShell Cmdlet。當您繼續擴充整個稽核解決方案時，您可能會使用 Cmdlet 和 API 的組合。本節的其餘部分可協助您決定存取數據的方式。

PowerShell 模組

Microsoft已發佈兩個 PowerShell 模組，其中包含與 Power BI 相關的 Cmdlet。它們是 Power BI 管理模組和數據閘道模組。這些 PowerShell 模組可作為 基礎 Power BI REST API 之上的 API 包裝函 式。使用這些 PowerShell 模組可讓您更輕鬆地撰寫腳本。

提示

除了Microsoft所發行的模組之外，Power BI 社群成員、合作夥伴和Microsoft最具價值專業人員（MVP）也免費發行了 PowerShell 模組和腳本（通常是在 GitHub 上）。

從社群解決方案開始，可以在建置端對端稽核解決方案方面扮演重要角色。如果您選擇使用免費可用的解決方案，請務必完整測試它。熟悉其運作方式，以便一段時間后有效地管理您的解決方案。您的IT部門可能有使用公開可用社群解決方案的準則。

Power BI 管理模組

Power BI 管理模組是匯總模組，其中包含用於管理、容量、工作區等的特定 Power BI 模組。您可以選擇安裝匯總模組以取得所有模組，也可以安裝特定模組。 Windows PowerShell 和 PowerShell Core 都支援所有 Power BI 管理模組。

重要

建議您停止使用 Windows PowerShell（無法執行 PowerShell Core）。請改用其中一個支援PowerShell Core的新式程式代碼編輯器。 Windows PowerShell ISE（整合式腳本環境）只能執行不再更新的 PowerShell 5.1 版。 Windows PowerShell 現在已被取代，因此我們建議您針對所有新的開發工作使用 PowerShell Core。

以下是數個常用的 Cmdlet，可用來擷取稽核數據。

管理模組	指令程式	用途
設定檔	Connect-PowerBIServiceAccount	驗證 Power BI 使用者或服務主體。
管理	Get-PowerBIActivityEvent	檢視或擷取租使用者的Power BI活動記錄事件。
工作區	Get-PowerBIWorkspace	編譯工作區清單。
報表	Get-PowerBIReport	編譯工作區或租用戶的報表清單。
資料	Get-PowerBIDataset	編譯工作區或租用戶的語意模型清單。
設定檔	Invoke-PowerBIRestMethod	傳送 REST API 要求（命令）。此 Cmdlet 是很好的選項，因為它可以叫用任何 Power BI REST API。當您想要使用 `Connect-PowerBIServiceAccount` 更簡單的驗證形式時，使用 Cmdlet 並能夠叫用沒有對應 PowerShell Cmdlet 的 API 時，這也是不錯的選擇。如需詳細資訊，請參閱本節稍後使用 PowerShell Cmdlet 的考慮。

提示

還有其他 Cmdlet 可用於管理和發佈內容。不過，本文的重點在於擷取稽核數據。

您可以從 PowerShell 資源庫下載 Power BI 管理模組。安裝模組最簡單的方式是使用 PowerShellGet。

建議您安裝Power BI管理匯總模組。如此一來，您可能需要的所有 Cmdlet 都可以使用。您至少需要配置檔模組（用於驗證），以及包含您想要使用之 Cmdlet 的任何特定模組。

警告

請務必在您使用PowerShell的每個伺服器、使用者電腦和雲端服務上，讓模組保持最新狀態（例如 Azure 自動化）。如果模組未定期更新，可能會發生無法預測的錯誤或問題。某些工具（例如 Visual Studio Code）可協助您保持模組更新。此外，請注意，當您安裝或更新較新版本時，PowerShellGet 不會自動卸載較舊的模組版本。它會與較舊的版本一起安裝較新版本。建議您檢查已安裝的版本，並定期卸載舊版。

數據閘道模組

數據閘道模組包含 Cmdlet，可從內部部署數據閘道及其數據源擷取數據。只有 PowerShell Core 才支援數據閘道模組。 Windows PowerShell 不支援它。

不同於 Power BI 管理模組（先前所述），數據閘道模組不包含任何系統管理員 Cmdlet。許多 Cmdlet（以及對應的閘道 API），要求使用者具有閘道系統管理員許可權。

警告

您無法將服務主體指派為閘道管理員（即使服務主體是安全組的成員也一樣）。因此，規劃在擷取數據閘道的相關信息時使用用戶認證。

以下是數據閘道模組中的數個 Cmdlet，可用來擷取稽核數據。

指令程式	用途
Connect-DataGatewayServiceAccount	驗證 Power BI 使用者（通常需要使用者屬於閘道管理員角色）。
Get-DataGatewayCluster	編譯網關叢集的清單。
Get-DataGatewayClusterDataSource	編譯網關叢集的數據源清單。
Get-DataGatewayInstaller	確認組織中允許哪些使用者安裝及註冊閘道。

您可以從 PowerShell 資源庫下載數據閘道模組。

使用 PowerShell 的技術

您可以使用數種不同的方式使用PowerShell。您做出的決定很重要。

下表說明三種不同的使用PowerShell技術。

技術	說明	範例
使用 PowerShell Cmdlet 來簡化驗證，以及直接呼叫 API。建議的方法	透過這項技術，有簡單性和彈性的平衡。 Invoke-PowerBIRestMethod Cmdlet 可從 Power BI 管理配置檔模組取得。此 Cmdlet 通常稱為瑞士陸軍刀，因為您可以使用它來呼叫任何 Power BI REST API。使用這項技術的優點是您可以簡化驗證，然後呼叫任何 Power BI REST API。強烈建議您使用這項技術。	使用 Connect-PowerBIServiceAccount Cmdlet 進行驗證之後，請使用 Invoke-PowerBIRestMethod Cmdlet 從您慣用的 API 擷取數據（例如，以系統管理員身分取得管線使用者）。
盡可能使用 PowerShell 中的 Cmdlet 進行驗證和擷取數據。	透過這項技術，PowerShell 會廣泛使用。 PowerShell 可用來協調執行腳本，並盡可能使用 PowerShell 模組來存取數據。這會從多個層面建立對 PowerShell 的更大相依性。	使用 Connect-PowerBIServiceAccount Cmdlet 進行驗證之後，請使用 Cmdlet （例如 Get-PowerBIActivityEvent）來擷取數據。
僅使用PowerShell協調執行進程。 PowerShell 模組會盡可能少地使用。	透過這項技術，PowerShell 作為工具的相依性較少，因為它的主要用途是協調叫用 API 呼叫。只有一個泛型 PowerShell 模組可用來存取 API（未使用 Power BI 管理模組的模組）。	使用 Microsoft 驗證連結庫進行驗證之後，請使用一般 Invoke-RestMethod Cmdlet 來擷取數據，呼叫您慣用的 API（例如，取得管線使用者身分管理員）。

在上述表格中，第一種技術描述一種平衡使用方式與彈性的方法。這種方法為大部分組織的需求提供最佳平衡，這就是為什麼建議這麼做的原因。某些組織可能有現有的 IT 原則和員工喜好設定，會影響您決定使用 PowerShell 的方式。

提示

您可以使用 Invoke-ASCmd PowerShell Cmdlet 來建立和執行 DAX、 XMLA 和 TMSL 腳本。不過，這些使用案例已超過本文的範圍。如需查詢動態管理檢視（DMV）的詳細資訊，請參閱數據層級稽核。

技術使用者（和系統管理員）可以使用Power BI管理模組來擷取數據或自動化內容管理的某些層面。

針對系統管理員：將參數設定-Scope為 Organization ，以存取整個租使用者中的實體（例如，擷取所有工作區的清單）。
對於技術使用者：將 -Scope 參數設定為 Individual （或省略參數）以存取屬於使用者的實體（例如，擷取使用者有權存取的工作區清單）。

請考慮您需要取得語意模型清單的案例。如果您選擇直接使用 API，則必須指定要呼叫的 API。不過，如果您選擇使用 Get-PowerBIDataset Cmdlet，您可以設定 -Scope 參數來擷取使用者特定的或全租用戶語意模型清單。您所做的選擇取決於您決定如何使用PowerShell（上表所述）。

下表描述 PowerShell Cmdlet 中使用的參數如何轉譯為 API PowerShell 呼叫。

Cmdlet 參數	Cmdlet 使用的 API	API 的類型	Scope	擷取的專案
`-DatasetID {DatasetID}` `-Scope Individual`	取得數據集	User	個人工作區	一個語意模型
`-Scope Individual`	取得數據集	User	個人工作區	所有語意模型
`-DatasetID {DatasetID}` `-GroupID {WorkspaceID}`	在群組中取得數據集	User	一個工作區	一個語意模型，前提是已登入的使用者有權讀取語意模型
`-GroupID {WorkspaceID}`	在群組中取得數據集	User	一個工作區	所有語意模型，前提是已登入的用戶有權存取工作區並讀取語意模型
`-GroupID {WorkspaceID}` `-Scope Organization`	以系統管理員身分取得群組中的數據集	管理	一個工作區	所有語意模型
`-Scope Organization`	以系統管理員身分取得數據集	管理	整個租使用者	所有語意模型

使用 PowerShell Cmdlet 的考慮

Power BI PowerShell Cmdlet 較容易使用，因為它們會抽象化 REST API 呼叫的某些複雜度。

以下是 Cmdlet 簡化存取稽核數據的一些方式。

驗證： 在 PowerShell 腳本中驗證最簡單的方式是使用 Connect-PowerBIServiceAccount Cmdlet。
簡單性： 因為擷取稽核數據的技巧很簡單，所以開始比較簡單。請考慮當您使用 Get-PowerBIActivityEvent Cmdlet 時，您會擷取 一天的 稽核數據。不過，當您直接呼叫取得活動事件 REST API 時，您會擷取 一小時的 稽核數據。因此，當您使用 REST API 擷取一天的稽核數據時，您必須使用迴圈呼叫 API 24 次，以擷取一天中的每一小時。
大型結果集的分頁：分頁可有效率地擷取大型結果集。分頁牽涉到一次擷取一個區塊的結果。 Cmdlet 會自動為您管理分頁。不過，當您直接使用 REST API 時，腳本必須檢查接續令牌，以判斷是否有更多結果要來。腳本應該會繼續擷取結果區塊，直到未收到接續令牌為止。如需使用接續令牌的範例，請參閱活動事件 REST API。
存取令牌到期： 驗證時，會傳回存取令牌。根據預設，它會在一小時後到期。 Cmdlet 會為您處理存取令牌到期。如此一來，您就不需要撰寫邏輯來要求重新整理令牌。
格式化： Cmdlet 所傳回的數據會比 REST API 傳回的數據稍微好一些。輸出更容易使用。針對自動化稽核程式，這不太可能是個問題。不過，針對手動稽核程式，較好的格式設定可能會很有説明。

直接使用 REST API 的考慮

有時候，直接呼叫 Power BI REST API 有優點。

可用的 API 更多： 有比 PowerShell Cmdlet 更多的 REST API 可用。不過，請勿忽略 Invoke-PowerBIRestMethod Cmdlet 的彈性，您可以使用此 Cmdlet 來呼叫任何 Power BI REST API。
更新的頻率： Microsoft更新 REST API 的頻率會比更新 PowerShell 模組更頻繁。例如，如果將新的屬性新增至取得數據集 API 回應，可能需要一些時間，才能在 Get-PowerBIDataset Cmdlet 的結果中使用。
較少語言/工具相依性： 當您直接使用 REST API 時（而不是 Cmdlet），您不需要使用 PowerShell。或者，您可以選擇只使用PowerShell來協調在腳本中呼叫許多 API。藉由移除 PowerShell 的任何相依性，未來一段時間，您可以使用不同的語言重寫邏輯。當您的IT或開發人員小組具有工具和語言的強式喜好設定時，較少相依性是考慮的重要考慮。

無論您選擇使用哪種方法，REST API 都會隨著時間而變更。當技術發展時，API（和 PowerShell 模組）可能會遭到取代和取代。因此，我們建議您有目的地建立容易維護和復原變更的腳本。

檢查清單 - 選擇是否要直接存取 REST API 或使用 PowerShell Cmdlet 時，關鍵決策和動作包括：

請洽詢 IT 以瞭解如何使用 PowerShell： 請連絡相關的 IT 小組，以判斷 PowerShell 的使用方式是否有現有的內部需求或喜好設定。
決定要使用PowerShell的方式： 決定要使用的PowerShell技術，以及您想要刻意增加或減少對PowerShell的相依性。請考慮是否需要內部通訊或訓練。
升級至 PowerShell Core： 使用 PowerShell Core 研究。判斷系統管理員機器是否需要更新。請考慮需要測試哪些現有的腳本。判斷系統管理員或開發人員是否需要額外的訓練來升級其技能。
判斷要使用的PowerShell模組： 請考慮要使用Power BI管理模組和/或數據閘道模組。
決定是否允許社群項目： 判斷您是否被允許（甚至鼓勵）使用在線可用的PowerShell模組（與Microsoft發佈的模組）。請洽詢 IT，以判斷是否有在線取得之社群專案的準則。
釐清如何支援社群專案： 如果允許PowerShell社群專案，請考慮誰將在內部使用後負責支援這些專案。
完成一個小概念證明（POC）： 試驗技術 POC。確認您慣用的用戶端工具和存取資料的方法。
決定如何支援進階使用者： 請考慮如何使用使用者 API 支援自行建立自動化的技術人員。

判斷儲存稽核數據的位置

當您計劃建置端對端稽核解決方案時，您必須決定儲存原始數據的位置（以及下一節涵蓋的策劃數據）。您對於數據儲存的決策與如何處理 數據整合的喜好設定有關。

當您擷取原始稽核數據時，請保持簡單。建議您在一開始擷取數據時，不要選取特定屬性、執行轉換，或套用任何格式設定。相反地，擷取所有可用的屬性，並將數據儲存在其原始狀態。

以下是將原始數據儲存在其原始狀態是最佳做法的幾個原因。

歷程記錄中可用的所有數據： 新的屬性和新的事件類型將會隨著時間而變成可用。儲存所有原始數據是一個很好的方法，以確保您一律可以存取擷取數據時可用的任何數據。即使您需要數周或數月的時間才能意識到新的數據屬性可供使用，您還是有可能在歷史上分析它們，因為您在原始數據中擷取了這些屬性。
復原變更： 如果原始數據格式變更，擷取數據的進程不會受到影響。由於某些稽核數據具有時效性，因此請務必確定您設計的數據擷取程式在來源發生變更時不會失敗。
角色和責任： 不同的小組成員（例如數據工程師或全域管理員）可能負責建立程式來存取、擷取及儲存原始稽核數據。簡化數據擷取程式，可讓多個小組更輕鬆地共同作業。

以下是儲存原始數據的一些選項。

Data Lake 或物件記憶體： 雲端服務，例如專門儲存任何結構的檔案的 OneLake 。這是儲存原始稽核數據的理想選擇。在數據湖架構中，原始數據應該儲存在銅層中。
文件系統： 文件系統（例如 Windows 或 Linux）是儲存原始稽核數據的常見選擇。
資料庫：可以將 JSON 資料儲存在關係資料庫中，例如 Azure SQL 資料庫。不過，它不如將數據儲存在 Data Lake 或文件系統中。這是因為查詢和維護 JSON 數據可能會變得具有挑戰性且昂貴，特別是隨著數據磁碟區成長。

提示

當您使用 Data Lake、物件記憶體或檔案系統時，建議您以容易組織和保護的方式儲存數據。此外，請務必清楚數據是否包含事件（通常是附加的），還是時間點快照集（需要選取要分析的日期）。

假設有一個範例涉及 Data Lake 的原始數據區域。區域有儲存活動記錄數據的資料夾階層：Raw > ActivityLog > YYYY > MM。資料夾會依年份和月份進行分割。儲存在 month 資料夾中的檔案會使用下列格式:PBIActivityLog-YYYYMMDD-YYYYMMDDTTTT.json。 YYYYMMDD 代表實際數據， 而YYYYMMDDTT 代表擷取時間戳。藉由包含擷取時間戳，您可以判斷哪一個檔案是最新的（如果您需要再次擷取數據）。例如，如果您在 2023 年 4 月 25 日上午 9 點擷取活動的數據，則檔名會是 PBIActivityLog-20230523-202305250900。

強烈建議您使用可讓您將原始數據 寫入不可變記憶體的技術。固定記憶體保證一旦寫入數據，就無法覆寫或刪除。這種區別對稽核員很重要，而且可讓您信任原始數據是可靠的。

您也需要考慮如何安全地儲存原始數據。一般而言，很少有使用者需要存取原始數據。原始數據的存取通常會以需求為基礎提供，通常是針對數據工程師和系統管理員。您的內部稽核員可能需要存取權。負責建立策劃數據的小組成員（如下所述）也需要存取原始數據。

以下是一些可協助您選擇原始數據記憶體的考慮。

這是手動或自動化的稽核程式嗎？ 自動化稽核程式通常具有更嚴格的數據儲存方式和位置需求。
主題區域特別敏感嗎？ 根據數據類型及其敏感性，您的組織可能會有儲存方式和位置的需求。 Power BI 稽核數據包含識別使用者資訊和 IP 位址，因此應該儲存在安全區域中。
是否有慣用的儲存技術？ 組織內可能有使用的現有儲存技術，因此這是一個邏輯選擇。
使用者是否會直接存取記憶體？ 安全性模型是重要的考慮。通常，很少使用者會被授與原始數據的存取權。對於策劃數據的存取，通常會提供給負責建立集中式數據模型的Power BI內容建立者使用（作為報告層的語意模型）。
您是否有數據落地需求？ 某些組織有法律或法規數據落地需求，可將數據儲存在特定數據區域中。
如何組織數據？ 使用獎章架構是常見的做法，特別是在 Data Lake 和 Lakehouse 實作中。目標是將數據儲存在銅級、銀級和金級數據層中。銅層包含原始的原始數據。銀層包含用於轉換的已驗證和重複數據刪除數據。金層包含精心策劃、高度精簡的數據，可供分析。

檢查清單 - 規劃儲存原始資料的位置時，關鍵決策和動作包括：

請洽詢 IT： 請連絡相關的 IT 小組，以判斷是否有現有的程式正在執行以擷取原始稽核數據。如果是，請找出您是否可以存取現有的數據。如果需要新的數據擷取程式，請判斷應該儲存數據的喜好設定或需求。
決定儲存原始數據的位置： 決定儲存原始數據的最佳儲存位置和結構。
判斷數據落地需求： 了解數據儲存位置是否有法律或法規需求。
建立資料夾結構和命名慣例： 決定要用於原始資料檔的命名慣例，包括資料夾結構。在您的技術檔中包含這些詳細數據。
請考慮原始數據的安全性如何運作： 當您設計原始資料儲存位置時，請考慮誰需要存取數據，以及如何授與存取權。

規劃建立策劃的數據

策展數據支援分析，並設計為方便使用者使用。您必須決定如何及在哪裡建立策展數據。您選擇儲存策劃數據的技術可能是上一節所列的任何技術。

策劃數據的目標是將數據轉換成更易記的格式，以針對分析和報告進行優化。它會形成 Power BI 數據模型的數據源，這表示您使用 Power BI 數據模型來分析組織中 Power BI 的使用方式。基本數據模型指引適用：您應該採用星型架構設計，其已針對效能和可用性優化。

您可以選擇以不同方式建立策劃的數據。您必須決定如何進行 數據整合 ，以及上游如何套用轉換，以準備數據以載入星型架構。

資料湖

您可以在 Data Lake 中套用轉換並建立策劃的數據檔。您應該針對策劃的數據使用金層，使其在邏輯上與儲存在銅層的原始數據分開。分隔層中的數據也會簡化設定不同的使用者訪問許可權。

使用 Data Lake 在下列情況下轉換及策劃資料：

您預期會有多個提供報告的Power BI數據模型（這可證明建立中繼銀層是正當的）。
您需要支援需要存取租用戶層級稽核數據的多個自助內容建立者。
您有想要用來轉換和載入資料的現有工具和程式。
您想要將需要在一或多個 Power BI 數據模型中完成且可能重複的數據準備降到最低。

Power BI 數據模型

您可以在 Power BI 中完成所有轉換工作。使用 Power Query 來存取數據，並將其從原始狀態轉換成策展格式。

在下列情況下使用 Power BI 數據模型：

您想要簡化端對端架構，並直接從原始數據載入數據模型。（累加式重新整理可協助減少重新整理持續時間。
您的喜好設定是在載入數據模型時執行所有轉換工作。
您預期租用戶層級稽核數據會有一個集中式數據模型。所有報表（或其他數據模型）都可以使用集中式 Power BI 語意模型作為其來源。
您想要只提供使用者對集中式 Power BI 語意模型的存取權（而不是任何源數據）。

提示

當您建立策劃的數據時，請以某種方式進行設定，以便您輕鬆地針對較早的日期範圍重新執行程式。例如，如果您發現新屬性出現在三個月前的稽核記錄中，您將想要能夠分析它，因為它第一次出現。重載策展數據歷程記錄的能力，是將原始數據儲存在其原始狀態很重要的原因之一（本文稍早所述）。

如需有關您可能包含在星型架構中的維度數據表和事實數據表的詳細資訊，請參閱本文稍後的建立數據模型。

檢查清單 - 規劃如何建立策劃的數據時，關鍵決策和動作包括：

決定應該執行轉換的位置： 考慮應該在上游完成轉換工作，以及符合整個架構規劃的位置。
決定要將數據轉換成星型架構所使用的工具： 確認哪些工具和服務將原始數據轉換成策劃的數據。
決定應該儲存策劃數據的位置： 決定儲存已轉換成星型架構格式的原始數據的最佳選擇。決定中繼銀層在端對端架構中是否有用。
建立命名慣例： 決定要用於策劃數據檔和資料夾的命名慣例（如果適用）。在您的技術檔中包含詳細數據。
請考慮策劃數據的安全性如何運作： 在設計策劃的數據儲存位置時，請考慮誰需要存取數據，以及如何指派安全性。

數據源決策

此時，您應該清楚瞭解需求、數據需求和許可權。已做出關鍵技術決策。您現在需要針對如何取得特定數據類型的方法做出一些決策。

存取用戶活動數據

Power BI 使用者活動數據有時稱為 活動記錄 或 稽核記錄，包含豐富的資訊，可協助您瞭解 Power BI 租使用者中發生的情況。如需識別數據需求的詳細資訊，請參閱本文稍早的用戶活動數據。

Power BI 會將其記錄與 Microsoft Purview 統一稽核記錄整合（先前稱為 Microsoft 365 統一稽核記錄）。這項整合是一項優點，因為它表示Microsoft 365 內的每項服務都不需要實作自己的唯一記錄方式。此項目預設為啟用。

重要

如果您尚未擷取使用者活動數據，請將該優先順序設為緊急。用戶活動數據適用於最近的 30 或 90 天（視來源而定）。即使您尚未準備好進行深入分析，也請務必儘快開始擷取和儲存數據。如此一來，寶貴的歷史將可供分析。

您有數個選項可擷取使用者活動數據。

技術	說明	可用的預設歷程記錄天數
手動（使用者介面）	Microsoft Purview 合規性入口網站	90
手動（使用者介面）	適用於雲端應用程式的 Defender	30
程式設計	Power BI 活動記錄檔（API 或 PowerShell Cmdlet）	30
程式設計	Office 365 管理活動 API	7
程式設計	Microsoft Sentinel （Azure 監視器）	30

本節的其餘部分會介紹表格中呈現的每個技術。

Microsoft Purview 合規性入口網站

Microsoft Purview 合規性入口網站中的稽核搜尋工具（先前稱為 Microsoft 365 合規性中心）是檢視活動和警示的便利位置。此工具不需要您建立腳本來擷取和下載數據。您可以選擇 Power BI 工作負載，以檢視一段時間的所有稽核記錄檔記錄。您也可以選取特定活動和用戶來縮小結果範圍。例如，經理要求您找出當天早些時候刪除工作區的人員，以便他們快速連絡人員討論情況。

稽核（標準）提供最近90天的歷程記錄。使用稽核（Premium）時，長期保留可讓您（選擇性地）保留稽核記錄更長的時間。由於長期保留僅適用於授權的 E5 使用者，因此它會排除非 E5 使用者和來賓使用者的稽核記錄。因此，我們建議您只依賴預設的90天歷程記錄，以確保擷取所有活動。

有存取 Microsoft Purview 合規性入口網站稽核記錄的授權需求。也需要提高 Exchange Online 許可權，才能存取稽核記錄。

提示

根據預設，Power BI 系統管理員無權存取 Microsoft Purview 合規性入口網站中的統一稽核記錄搜尋。因為它包含許多Microsoft 365 服務的數據，所以它是高許可權角色。在大部分組織中，這些許可權會保留給少數IT系統管理員。 Power BI 系統管理員有其他可用的選項，本節稍後會說明。

Microsoft Purview 合規性入口網站中的使用者介面適用於手動稽核程式，以及偶爾調查用戶活動。

適用於雲端應用程式的 Defender

適用於雲端的 Defender Apps 中的入口網站是一個方便的地方，可用來檢視活動和警示，而不需要建立腳本來擷取和下載數據。它也可讓您檢視來自Power BI活動記錄和使用者登入的數據。

適用於雲端的 Defender Apps 包含使用者介面，可檢視和搜尋各種雲端服務的活動記錄，包括 Power BI。它會顯示源自 Microsoft Purview 統一稽核記錄檔的相同記錄事件，並包含來自 Microsoft Entra ID 的使用者登入活動等其他事件。

如同上一節所述的 Microsoft Purview 合規性入口網站，適用於雲端的 Defender Apps 具有可搜尋的使用者介面。不過，篩選選項不同。除了標準 30 天歷程記錄之外，您還可以使用適用於雲端的 Defender Apps 來檢視最多六個月的活動記錄歷程記錄（以七天增量為單位）。

有存取適用於雲端的 Defender Apps 的授權需求。也需要個別的許可權。

提示

根據預設，Power BI 系統管理員沒有存取適用於雲端的 Defender Apps 的許可權。適用於雲端的 Defender Apps 中有 Power BI 角色。將 Power BI 系統管理員新增至此角色是授與他們存取有限數據集的好方法。

適用於雲端的 Defender Apps 中的使用者介面對於手動稽核程式和用戶活動的一次性調查很有用。

Power BI 活動記錄

Power BI 活動記錄源自統一稽核記錄。它只包含與 Power BI 服務相關的用戶活動。

提示

對於計劃擷取用戶活動的組織，建議您從Power BI活動記錄開始。這是以程式設計方式存取的最簡單來源。

您有兩個選項可存取 Power BI 活動記錄。

使用您選擇的工具來呼叫取得活動事件 REST API。
使用 Get-PowerBIActivityEvent PowerShell Cmdlet。您可以從 Power BI 管理管理模組取得。

如需要使用哪一個選項的相關信息，請參閱本文稍早選擇 API 或 PowerShell Cmdlet 。

提示

如需如何使用PowerShell存取Power BI活動記錄的範例，請參閱存取Power BI活動記錄。

Power BI 活動記錄數據可供所有 Power BI 系統管理員、Power Platform 系統管理員和全域管理員使用。您可以從統一稽核記錄存取數據，這些記錄可供特定 Exchange Online 角色使用。如需詳細資訊，請參閱在Power BI中追蹤用戶活動。

當您打算只擷取 Power BI 稽核記錄檔時，建議您使用 Power BI 活動記錄。

注意

在稽核記錄數據中，工作區稱為 資料夾。在 Power BI REST API 中，工作區稱為群組。

Office 365 管理活動 API

您可以從其他服務的統一稽核記錄中擷取數據，例如 SharePoint Online、Teams、Exchange Online、Dynamics 365 和 Power BI。當您的目標是實作多個服務的稽核和監視解決方案時，建議您使用 Office 365 管理活動 API。由於此 API 會從許多服務傳回數據，因此 稱為「統一稽核 API 」（或 統一稽核記錄）。這是 Office 365 管理 API 之一。

在建置新的解決方案之前，建議您連絡 IT 部門，以判斷是否有現有的 Power BI 稽核記錄可供使用。進程可能已經擷取並儲存數據。您也可以取得存取此數據的許可權，而不是建置新的解決方案。

您可以存取兩種方式之一的數據。

使用您選擇的工具，直接呼叫 Office 365 管理活動 API。根據預設，API 會傳回 24 小時的數據。您可以擷取最多七天的歷程記錄。
使用 Search-UnifiedAuditLog PowerShell Cmdlet。這是 Exchange Online PowerShell Cmdlet。您可以擷取最多 90 天的歷程記錄。

重要

Cmdlet Search-UnifiedAuditLog 無法正常調整，而且需要您實作迴圈策略，以克服其 5,000 個數據列限制。基於這些原因，它適合偶爾進行查詢，或適用於體驗低活動的小組織。當您只需要 Power BI 數據時，建議您改用 Get-PowerBIActivityEvent Cmdlet。

一般而言，開始使用 Office 365 管理活動 API 比使用 Power BI 活動記錄更具挑戰性（先前所述）。這是因為 API 會傳回內容 Blob，而每個內容 Blob 都包含個別的稽核記錄。針對大型組織，每天可能會有數千個內容 Blob。由於客戶和第三方應用程式大量使用此 API，因此Microsoft實作節流以確保其使用服務不會對其他人造成負面影響（稱為 嘈雜的鄰近 問題）。因此，擷取大量的歷程記錄，在較大的組織中可能會是一項挑戰。如需詳細資訊，請參閱此疑難解答文章。

若要使用此 API，您必須向已授與許可權的服務主體進行驗證，以從 Office 365 管理活動 API 擷取數據。

提示

根據預設，Power BI 系統管理員沒有存取 Office 365 管理活動 API 的許可權。因為它包含許多Microsoft 365 服務的數據，因此存取需要高許可權系統管理員或稽核角色。在大部分組織中，這些角色會保留給少數IT系統管理員。 Power BI 活動記錄僅供 Power BI 系統管理員使用。

從 Office 365 管理活動 API 以程式設計方式擷取稽核數據是當 IT 需要從各種服務擷取和儲存稽核記錄（超越 Power BI）時，不錯的選擇。

Microsoft Sentinel

Microsoft Sentinel 是一項 Azure 服務，可讓您收集、偵測、調查及回應安全性事件和威脅。您可以在 Microsoft Sentinel 中將 Power BI 設定為 數據連接器。線上時，稽核記錄（包含數據子集）會從Power BI串流至 Azure Log Analytics，這是 Azure 監視器的功能。

提示

Azure Log Analytics 是以工作區層級語意模型事件記錄所使用的相同架構為基礎。如需語意模型事件記錄的詳細資訊，請參閱數據層級稽核。

因為它是個別的 Azure 服務，所以您想要執行 Kusto 查詢語言（KQL）查詢的任何系統管理員或使用者都必須在 Azure Log Analytics （Azure 監視器）中授與許可權。當他們有許可權時，他們可以查詢儲存在PowerBIActivity資料表中的稽核數據。不過，請記住，在大部分情況下，您會將黃金層中策展數據的存取權授與使用者，而不是銅層中的原始數據。

您可以使用 KQL 來分析儲存在 Azure Log Analytics 中的活動記錄事件。如果您有 SQL 體驗，您會發現 KQL 有許多相似之處。

有數種方式可以存取儲存至 Azure Log Analytics 的事件。您可以使用：

適用於Power BI語意模型範本應用程式的預建Log Analytics。
適用於 Azure 數據總管的 Power BI Desktop 連接器（Kusto）。
Azure 數據總管中的 Web 查詢體驗。
可傳送 KQL 查詢的任何查詢工具。

警告

請注意，只有 Power BI 活動記錄數據的子集會儲存在 Azure 監視器中。當您計劃對組織中的 Power BI 使用量和採用進行全面分析時，建議您使用其他選項（本節稍早所述）來擷取活動數據。

您可以擷取的歷程記錄期間取決於 Azure Log Analytics 工作區的數據保留原則。決定要保留多少數據時，請考慮原始數據的成本和存取權。

當 IT 已透過 Microsoft Sentinel 進行投資、所擷取的詳細數據層級符合您的需求，以及威脅偵測之類的活動優先時，Microsoft Sentinel 和 Azure 監視器是不錯的選擇。不過，由於Microsoft Sentinel 不會擷取所有 Power BI 活動數據，因此不支持執行 Power BI 使用量和採用的全面分析。

用戶活動數據考慮

以下是協助您選擇用戶活動數據來源的一些考慮。

這是手動或自動化的稽核程式嗎？ 使用者介面選項適用於手動稽核程式和偶爾的一次性查詢，特別是當您需要調查特定活動時。自動稽核程式，依排程擷取用戶活動數據，也需要支援歷程記錄數據分析。
您需要使用者活動數據的頻率為何？ 針對自動化稽核程式，請規劃使用國際標準時間（UTC）擷取目前日期前至少一天的數據，而不是您的當地時間。例如，如果您的程式在星期五早上（UTC 時間）執行，您應該從星期三擷取數據。您應該使用一天延遲擷取數據的原因有很多。
- 當您一次一律擷取整整 24 小時時，檔案會更容易使用，以避免部分日結果。
- 您將盡可能降低遺漏某些稽核事件的風險。稽核事件通常會在 30 分鐘內送達。有時候，某些事件最多可能需要 24 小時才能到達統一的稽核記錄。
您是否需要 Power BI 資料？ 請考慮最有效率的方式來存取您需要的內容。
- 當您只需要Power BI使用者活動資料時，請使用 Power BI活動記錄。
- 當您需要來自多個服務的稽核記錄時，請使用 Office 365 管理活動 API 來存取統一的稽核記錄。
誰會開發解決方案？ 規劃投資一些時間來建置解決方案。產生生產就緒腳本可能需要大量精力。

檢查清單 - 規劃如何存取使用者活動數據時，關鍵決策和動作包括：

釐清需求範圍： 判斷您是否只需要存取 Power BI 稽核記錄，或針對多個服務稽核數據。
請洽詢 IT： 瞭解 IT 目前是否會擷取稽核記錄，以及是否可以取得原始數據的存取權，讓您不需要建置新的解決方案。
決定數據源： 決定用來存取用戶活動數據的最佳來源。
完成概念證明： 規劃完成小型技術概念證明（POC）。使用它來驗證決定如何建置最終解決方案。
追蹤其他數據需求： 您可以將活動記錄數據與其他來源相互關聯，以增強數據的價值。請追蹤這些商機的出現，以便將其新增至您的項目範圍。

存取租使用者清查數據

租使用者清查是成熟稽核和監視解決方案中寶貴的必要部分。它可協助您瞭解Power BI 中存在哪些工作區和內容（語意模型、報表和其他專案），而且是使用者活動數據的絕佳補充（如上一節所述）。如需識別數據需求的詳細資訊，請參閱本文稍早的租使用者清查。

用戶活動（先前所述）是稽核事件;它們是使用者在特定日期和時間採取的動作記錄。不過，租使用者清查不同。租使用者清查是 指定時間點的快照 集。它會描述您擷取 Power BI 服務中所有已發佈專案的目前狀態。

注意

Power BI REST API 檔將已發佈的項目 稱為成品。

提示

許多組織發現，每周同時擷取租使用者清查會很有説明。

若要正確分析 Power BI 租使用者中發生的情況，您需要使用者活動數據和租使用者清查。結合它們可讓您瞭解您擁有的內容和其所在位置。它也可讓您尋找未使用或未使用的內容（因為活動記錄中不會有任何事件）。租使用者清查也可協助您編譯所有專案的目前名稱清單，這在專案名稱變更時很有説明。

如需租使用者清查值的詳細資訊，請參閱本文稍早的租使用者清查。

提示

您可以使用 [取得未使用的成品] 作為系統管理員 API，搜尋過去 30 天內沒有任何用戶活動的專案。不過，您無法自定義該時段。例如，您可能只有每季使用的重要內容。藉由結合租使用者清查與用戶活動數據，您可以透過您可以自定義的方式找到未使用的專案。

您可以透過兩種不同的方式取得租使用者清查數據。

技術	說明	最適合	手動稽核程式的好選擇	自動稽核程式的好選擇
程式設計	`Get Groups as Admin` API 或 `Get-PowerBIWorkspace` PowerShell Cmdlet 可以提供整個租使用者的工作區清單。您可以選擇性地包含每個工作區的個別專案（例如語意模型和報表）。	較小的組織或低數據量
程式設計	一組異步管理員 API，統稱為元數據掃描 API 或掃描器 API，可以傳回工作區和個別項目的清單。您也可以選擇性地包含詳細的元資料（例如數據表、數據行和量值表示式）。	具有大量數據和/或需要取得詳細結果的組織

本節的其餘部分會介紹表格中呈現的每個技術。

群組 API 或工作區 Cmdlet

若要擷取工作區清單，您可以使用數個 REST API 的其中一個，例如取得群組作為系統管理 API（使用您選擇的工具）。結果包含額外的元數據，例如描述，以及工作區是否儲存在 Premium 容量中。

注意

名為的 API 包含字詞群組作為工作區的參考。該詞彙源自原始的Power BI安全性模型，該模型依賴Microsoft 365個群組。雖然 Power BI 安全性模型多年來已大幅發展，但現有的 API 名稱會保持不變，以避免中斷現有的解決方案。

Get Groups as Admin REST API 包含實用的$expand參數。此參數可讓您選擇性地展開結果，使其包含發佈至工作區的專案清單（例如語意模型和報表）。您也可以將 users 數據類型傳遞至 $expand 參數，以包含指派給工作區角色的使用者。

您也可以使用 Get-PowerBIWorkspace PowerShell Cmdlet。其來自 Power BI 管理工作區模組。當您設定 -Scope 參數 organization時，它會像 API 一樣運作 Get Groups as Admin 。 Cmdlet 也接受 -Include 參數（這相當於 $expand REST API 中的參數），以包含工作區中發佈的專案（例如語意模型和報表）。

提示

藉由傳入參數，您可以使用不同方式使用 Cmdlet。本節著重於擷取整個租使用者的清查。如需使用 -Scope 參數的詳細資訊，請參閱本文稍早選擇使用者 API 或系統管理員 API 。

若要協助您選擇要使用的選項，請參閱本文稍早選擇 API 或 PowerShell Cmdlet 。

Get Groups as Admin REST API 或 Get-PowerBIWorkspace PowerShell Cmdlet 最適合手動稽核程式和一次性調查。具有大量數據的大型組織通常會發現這些選項難以使用。 REST API 和 Cmdlet 一律會擷取一組完整的數據，因此可能需要很長的時間才能執行。因此，大型組織可能會對每小時允許的要求數目造成限制（稱為節流，這是為了保護服務的健康情況所完成）。元數據掃描 API（如下所述）提供更可靠且可調整的替代方案。

元數據掃描 API

通常稱為掃描器 API 的元數據掃描 API 是一組 API，可傳回工作區及其 Power BI 專案清單（語意模型、報表和其他專案）。就概念上講，它們會提供與群組 API 或工作區 Cmdlet 相同的數據（以及更多數據），如上一節所述。不過，您用來擷取數據的方法不同，而且更適合擷取租使用者清查。

注意

請注意，有些人如何使用掃描器 API 一詞或片語掃描租使用者。 他們通常會使用這些詞彙來表示 編譯租使用者清查，將其與用戶活動事件區別開來。它們可能或可能不會以字面方式參考元數據掃描 API 的使用。

您應該考慮使用元數據掃描 API 而不是 Get Groups as Admin REST API 或 Get-PowerBIWorkspace Cmdlet（先前所述）的原因有兩個主要原因。

累加式數據擷取： 掃描器 API 只會擷取自上次執行后變更的數據。相反地， Get Groups as Admin REST API 和 Get-PowerBIWorkspace Cmdlet 是同步作業，會在每次執行時擷取完整的數據集。
更細微的詳細層級： 掃描器 API 可以擷取細微的詳細數據（例如數據表、數據行和量值表達式），並提供兩個租用戶設定授與詳細元數據的許可權。相反地，REST API 和 Get Groups as Admin Get-PowerBIWorkspace Cmdlet 可用的詳細數據層級最低層級是依專案類型（例如工作區中的報表清單）。

使用掃描器 API 牽涉到更多工作，因為您需要呼叫一系列 API。此外，它們會以異步進程的形式執行。異步進程會在背景執行，因此您不需要等待它完成。在建立即將排程的生產就緒腳本時，您可能需要與IT或開發人員共同作業。

以下是您在使用掃描器 API 時應遵循的步驟順序。

登入：使用具有執行系統管理員 API 許可權的 Power BI 系統管理員帳戶或服務主體登入 Power BI 服務。如需詳細資訊，請參閱本文稍早判斷驗證方法。
取得工作區標識碼： 傳送要求以擷取工作區標識符清單。第一次執行時，您就不會有修改的日期，因此它會傳回完整的工作區清單。通常，您將傳遞修改日期，只擷取自該時間點以來已變更的工作區。修改日期必須在過去 30 天內。
起始元數據掃描： 藉由傳入步驟 2 中擷取的工作區標識碼，起始呼叫以要求掃描工作區資訊。請注意，這是 POST API（而不是 GET API，在擷取稽核數據時更為常見）。 POST API 是 HTTP 要求，可建立或寫入指定資源的數據。此查詢會指定要擷取的詳細數據層級，例如數據源詳細數據、語意模型架構、語意模型表達式或使用者。提交時，API 會傳回掃描的標識碼。它也會傳回掃描的日期和時間，您應該將其記錄為快照集日期。
檢查掃描狀態： 使用步驟 3 中取得的掃描標識碼來取得掃描狀態。您可能需要多次呼叫此 API。當傳回的狀態為 [成功] 時，可以繼續進行下一個步驟。掃描所需的時間取決於您要求的數據量。
取得結果： 使用步驟 3 中取得的掃描標識碼來取得掃描結果並擷取數據。您必須在完成步驟 4 的 24 小時內執行此步驟。請記住，快照時間戳應該與步驟 3 相互關聯，而不是步驟 5（當有重大延遲時）。如此一來，您就會有精確的快照集時間戳。將結果儲存在慣用的數據儲存位置。如本文所述，建議您將其原始數據儲存在其原始狀態。
準備下一個程式： 記錄步驟 3 掃描的時間戳，以便在下一次執行程式時，在步驟 2 中使用。如此一來，您只會擷取自該時間點以來變更的數據。接下來，所有後續的數據擷取都會是累加變更，而不是完整快照集。

檢查清單 - 規劃存取租使用者清查數據時，關鍵決策和動作包括：

確認需求： 釐清編譯租使用者清查的需求，以及數據的分析需求。
決定擷取租使用者清查的頻率： 確認您需要新租使用者清查的頻率（例如每周）。
決定如何擷取租使用者清查： 確認您將用來取得租使用者清查數據的方法（API、Cmdlet 或元數據掃描 API）。
完成概念證明： 規劃完成小型技術概念證明（POC）。使用它來驗證決定如何建置最終解決方案。

存取使用者和群組數據

除了用戶活動數據中包含的識別資訊（例如電子郵件位址）之外，擷取位置或組織詳細數據等其他資訊是有價值的。您可以使用 Microsoft Graph 來擷取使用者、群組、服務主體和授權的相關數據。 Microsoft Graph 包含一組 API 和用戶端連結庫，可讓您從各種不同的服務擷取稽核數據。

以下是您可以存取之Microsoft Entra 物件的一些詳細數據。

使用者： Microsoft Entra ID 中存在的身分識別，作為公司、學校或Microsoft帳戶。網域使用者一詞通常用來描述組織使用者，而正式詞彙是用戶主體名稱（UPN）。 UPN 通常與使用者的電子郵件位址值相同（不過，如果電子郵件地址變更，UPN 不會因為不可變而變更）。每個使用者也有唯一的Microsoft圖形標識碼。用戶帳戶通常與一個人相關聯。某些組織會建立使用者，這些使用者是 用於自動化活動或系統管理工作的服務帳戶 。
服務主體： 當您建立應用程式註冊時，會布建不同類型的身分識別。服務主體適用於自動自動活動。如需詳細資訊，請參閱本文稍早判斷驗證方法。
群組： 用戶和服務主體的集合。有數種類型的群組可用來簡化許可權管理。如需詳細資訊，請參閱使用群組的策略。

注意

當本文參考 使用者和群組時，此詞彙也包含服務主體。這個較短的詞彙用於簡潔。

您擷取的使用者和群組數據是 描述指定時間點目前狀態的快照 集。

提示

如需使用者、服務主體和群組的詳細資訊，請參閱與 Microsoft Entra 識別元整合。

分析屬性

針對 Power BI 租使用者層級稽核，您可以從 Microsoft Graph 擷取並儲存下列屬性。

使用者的完整名稱： 許多數據源只會包含執行活動或指派給角色之使用者的電子郵件位址。當您想要在分析報表中顯示完整名稱（顯示名稱）時，請使用此屬性。使用完整名稱可讓報表更方便使用。
其他用戶屬性： 在 entra 識別碼 Microsoft中，可能會提供使用者的其他描述性屬性。具有分析值的內建使用者配置檔屬性範例包括職稱、部門、經理、區域和辦公室位置。
安全組的成員： 大部分的數據源都會提供群組的名稱（例如，安全組已指派給工作區角色的Power BI活動記錄檔記錄檔）。擷取群組成員資格可改善您完整分析個別使用者執行或存取權的能力。
用戶授權： 分析哪些使用者授權-免費、Power BI Pro 或 Power BI Premium Per User （PPU）—會指派給使用者。此數據可協助您識別未使用其授權的人員。它也可協助您分析所有使用者（具有授權的不同使用者）與使用中使用者（使用最近的活動）。如果您考慮新增或擴充 Power BI Premium 授權，建議您分析使用者授權數據與用戶活動數據，以執行成本分析。
系統管理員角色的成員： 您可以編譯 Power BI 系統管理員清單（包括 Power Platform 系統管理員和全域管理員）。

如需您可以從 Microsoft Graph 在稽核數據中找到的 Power BI 授權資訊的授權參考，請參閱授權的產品名稱和服務方案標識碼。

提示

從群組擷取成員可以是取得稽核數據最具挑戰性的層面之一。您必須進行 可轉移的搜尋 ，以壓平所有巢狀成員和巢狀群組。您可以對群組成員執行可轉移的搜尋。當您組織中有數千個群組時，這種類型的搜尋尤其具有挑戰性。在此情況下，可能會考慮更好的替代方案來擷取數據。其中一個選項是從 Microsoft Graph 擷取所有群組和群組成員。不過，當只有少數群組用於Power BI安全性時，這可能並不實用。另一個選項是預先建置任何類型的 Power BI 安全性所使用的群組參考清單（工作區角色、應用程式許可權、每個專案共用、數據列層級安全性等等）。然後，您可以迴圈查看參考清單，以從 Microsoft Graph 擷取群組成員。

以下是您可能會擷取和儲存的一些其他屬性。

使用者類型： 用戶為成員或來賓。最常見的是成員是內部使用者，而來賓是外部使用者（B2B）使用者。當您需要分析外部用戶的活動時，儲存使用者類型很有用。
角色變更： 當您執行安全性稽核時，瞭解使用者何時變更組織中的角色（例如，當他們轉移至不同部門時）會很有用。如此一來，您可以確認其Power BI安全性設定是否已更新或應該更新。
停用的使用者： 當使用者離開組織時，系統管理員通常會停用其帳戶。您可以建立程式來檢查已停用的使用者是工作區系統管理員或語意模型擁有者。

提示

Power BI 活動記錄包含當用戶註冊試用版授權時所記錄的事件。您可以將該事件與使用者授權數據結合（來源為 Microsoft Entra ID），以產生完整的圖片。

擷取使用者和群組數據

您可以透過不同方式擷取使用者和群組的相關數據。

技術	說明	手動稽核程式的好選擇	自動稽核程式的好選擇
手動	Graph 總管 (英文)
程式設計	Microsoft圖形 API 和 SDK
程式設計	Az PowerShell 模組

本節的其餘部分會介紹表格中呈現的每個技術。本節結尾會說明其他已被取代且不應用於新解決方案的技術。

注意

當您在線閱讀資訊時請小心，因為許多工具名稱都類似。 Microsoft生態系統中的一些工具包括其名稱中的 Graph 一詞，例如 Azure Resource Graph、GraphQL 和 Microsoft Security Graph API。這些工具與 Microsoft Graph 無關，而且不在本文的範圍內。

Microsoft Graph 總管

Microsoft Graph 總管是開發人員工具，可讓您瞭解 Microsoft Graph API。這是一種簡單的入門方式，因為它不需要其他工具或在計算機上進行設定。您可以登入以從租用戶擷取數據，或從預設租用戶擷取範例數據。

您可以使用 Graph 總管來：

手動將要求傳送至 Microsoft Graph API，以檢查它是否傳回您想要的資訊。
在您撰寫腳本之前，請參閱如何建構 URL、標頭和本文。
以非正式的方式檢查數據。
判斷每個 API 所需的許可權。您也可以提供新許可權的同意。
取得建立腳本時要使用的代碼段。

使用此連結開啟 Graph 總管。

Microsoft圖形 API 和 SDK

使用 Microsoft Graph API 來擷取使用者和群組數據。您也可以使用它，從Microsoft Entra ID、SharePoint Online、Teams、Exchange、Outlook 等服務擷取數據。

Microsoft Graph SDK 可作為 基礎Microsoft圖形 API 之上的 API 包裝函 式。 SDK 是一種軟體開發工具包，將工具和功能組合在一起。 Microsoft Graph SDK 會公開整個一組Microsoft Graph API。

您可以選擇將要求直接傳送至 API。或者，您可以使用慣用的語言和其中一個 SDK 來新增一層簡化。如需詳細資訊，請參閱本文稍早選擇 API 或 PowerShell Cmdlet 。

Microsoft Graph SDK 支援數種語言，也有 Microsoft Graph PowerShell 模組。其他 SDK 適用於 Python、C# 和其他語言。

重要

Microsoft Graph PowerShell 模組會取代已淘汰的 Azure AD PowerShell 模組和 MSOnline （MSOL）模組。您不應該使用已被取代的模組來建立新的解決方案。 Microsoft Graph PowerShell 模組有許多功能和優點。如需詳細資訊，請參閱從 Azure AD PowerShell 升級至 Microsoft Graph PowerShell。

您可以從 PowerShell 資源庫安裝 Microsoft Graph PowerShell 模組。由於 Microsoft Graph 適用於許多Microsoft 365 服務，因此您安裝的許多 PowerShell 模組。

針對 Power BI 租用戶層級稽核，以下是您需要安裝的最常見 PowerShell 模組。

驗證（用於登入）
使用者
群組
應用程式（和服務主體）
目錄物件（和授權詳細資料）

提示

Microsoft會定期更新 Microsoft Graph PowerShell 模組。有時候，預覽模組會以發行前版本或 Beta 端點為基礎提供。您可能會想要指定安裝及更新模組時感興趣的版本。此外，當您檢閱在線檔時，請注意，目前的版本號碼會自動附加至URL結尾（因此在儲存或共用URL時請小心）。

Az PowerShell 模組

您也可以使用 Az PowerShell 模組來擷取使用者和群組數據。其著重於 Azure 資源。

重要

Az PowerShell 模組會取代已被取代的 AzureRM PowerShell 模組。您不應該使用已被取代的模組來建立新的解決方案。

當 API 沒有對應的 Cmdlet 時，您可以使用 Invoke-AzRestMethod Cmdlet。這是一種彈性的方法，可讓您使用 Az PowerShell 模組，將要求傳送至任何Microsoft圖形 API。

從 Az 7 版開始，Az Cmdlet 現在會參考 Microsoft Graph API。因此，Az 模組會作為 Microsoft Graph 頂端的 API 包裝函 式。 Az 模組具有包含在 Microsoft Graph API 和 PowerShell 模組中的功能子集。針對新的解決方案，建議您使用 Microsoft Graph PowerShell SDK。

已被取代的 API 和模組

您可能會在在線找到文章和部落格文章，以建議本節中未呈現的替代選項。強烈建議您不要使用下列任何 API 或模組來建立新的解決方案（和/或移轉現有的解決方案）。

AzureRM PowerShell 模組： 已淘汰且即將淘汰。它們已取代為 Az PowerShell 模組。
Azure AD Graph API 和 Azure AD PowerShell 模組： 已淘汰且即將淘汰。這項變更是從 Azure AD Graph 移轉至 Microsoft Graph 的結果（請注意，Graph 會顯示在兩個名稱中，但 Microsoft Graph 是未來的方向）。所有未來的PowerShell投資都將在 Microsoft Graph PowerShell SDK 中進行。（Microsoft Entra ID 現在稱為 Microsoft Entra ID。
MS Online （MSOL） PowerShell 模組： 已淘汰且即將淘汰。所有未來的PowerShell投資都將在 Microsoft Graph PowerShell SDK 中進行。

警告

請務必確認您目前使用的任何已淘汰 API 或模塊狀態。如需 AzureRM 淘汰的詳細資訊，請參閱此公告。

如需Microsoft Entra ID 和 MSOL 的詳細資訊，請參閱此淘汰公告文章。

如果您有問題或需要釐清程式設計數據存取的未來方向，請連絡您的Microsoft帳戶小組。

檢查清單 - 規劃存取使用者和群組數據時，關鍵決策和動作包括：

確認需求： 釐清編譯使用者、群組和授權相關數據的需求。
排定需求優先順序： 確認最優先的優先順序，讓您知道要先花點什麼時間。
決定擷取數據的頻率： 決定您需要使用者和群組數據的新快照集的頻率（例如每周或每個月）。
決定如何使用 Microsoft Graph 擷取數據： 決定您將用來擷取數據的方法。
完成概念證明： 規劃完成小型技術概念證明（POC），以擷取使用者和群組數據。使用它來驗證決定如何建置最終解決方案。

從 Power BI REST API 存取數據

或許作為較低優先順序，您也可以使用 Power BI REST API 來擷取其他數據。

例如，您可以擷取有關下列項目的數據：

組織中的所有應用程式。
組織中所有匯入的語意模型。
組織中的所有部署管線。
組織中的所有 Premium 容量。

在安全性稽核期間，您可能會想要識別：

已廣泛與整個組織共享的專案。
使用發佈至 Web 在公用因特網上提供的專案。

如需其他類型的 API 的詳細資訊，請參閱本文稍早選擇使用者 API 或系統管理員 API 。

檢查清單 - 規劃從 Power BI API 存取數據時，關鍵決策和動作包括：

取得需求： 在發生分析需求時編譯分析需求。在您的待辦項目中追蹤它們。
設定需求優先順序： 設定新需求的優先順序。

階段 2：必要條件和設定

規劃和實作租用戶層級稽核解決方案的第二個階段著重於開始開發解決方案之前必須完成的必要條件和設定。

描述階段 2 的流程圖，著重於建置租用戶層級稽核解決方案的必要條件和設定。

建立儲存體帳戶

此時，您已決定儲存原始數據的位置，以及如何建立策劃的數據。根據這些決策，您現在已準備好建立記憶體帳戶。視您組織的程式而定，它可能涉及提交要求給IT。

如先前所述，我們建議使用可讓您將原始數據寫入不可變記憶體的技術。寫入數據之後，就無法變更或刪除數據。接著，您可以對原始數據有信心，因為您知道具有存取權的系統管理員無法以任何方式改變數據。不過，策劃的數據不需要儲存在不可變的記憶體中。策劃的數據可能會變更或重新產生。

檢查清單 – 建立記憶體帳戶時，關鍵決策和動作包括：

建立記憶體帳戶： 建立或提交建立記憶體帳戶的要求。盡可能針對原始數據使用不可變的記憶體設定。
設定許可權： 決定應為記憶體帳戶設定哪些許可權。
測試存取： 執行小型測試，以確保您可以讀取和寫入記憶體帳戶。
確認責任： 請確定您清楚瞭解誰會持續管理記憶體帳戶。

安裝軟體和設定服務

此時，您已決定要用於存取稽核數據的技術。根據這些決策，您現在已準備好安裝軟體和設定服務。

為每個系統管理員設定慣用的開發環境。開發環境可讓他們撰寫及測試腳本。 Visual Studio Code 是開發腳本的新式工具，因此是不錯的選擇。此外，許多擴充功能都可以使用Visual StudioCode。

如果您已決定使用 PowerShell，您應該在下列項目上安裝 PowerShell Core 和必要的 PowerShell 模組：

每個將撰寫或測試稽核腳本之系統管理員/開發人員的計算機。
將執行排程文本的每個虛擬機或伺服器。
每個在線服務（例如 Azure Functions 或 Azure 自動化）。

如果您選擇使用任何 Azure 服務（例如 Azure Functions、Azure 自動化、Azure Data Factory 或 Azure Synapse Analytics），您也應該布建和設定它們。

檢查清單 – 安裝軟體和設定服務時，關鍵決策和動作包括：

設定系統管理員/開發人員機器： 如果適用，請安裝將用於開發的必要工具。
設定伺服器： 如果適用，請在您架構中存在的任何伺服器或虛擬機上安裝必要的工具。
設定 Azure 服務： 如果適用，請布建並設定每個 Azure 服務。為每個將執行開發工作的系統管理員/開發人員指派許可權。

註冊Microsoft Entra 應用程式

此時，您已決定如何進行驗證。建議您註冊Microsoft Entra 應用程式（服務主體）。通常稱為 應用程式註冊，它應該用於您將自動化的自動作業。

如需如何建立應用程式註冊以擷取租用戶層級稽核數據的詳細資訊，請參閱啟用唯讀系統管理員 API 的服務主體驗證。

檢查清單 - 註冊Microsoft Entra 應用程式時，關鍵決策和動作包括：

檢查現有的應用程式註冊是否存在： 請向IT確認現有應用程式註冊是否可用於執行系統管理員 API。如果是，請判斷是否應該使用現有的，還是應該建立新的。
建立新的應用程式註冊： 適當時建立應用程式註冊。請考慮使用應用程式名稱，例如 PowerBI-AdminAPIs-EntraApp，其清楚描述其用途。
建立應用程式註冊的秘密： 一旦應用程式註冊存在，請為其建立秘密。根據您想要輪替秘密的頻率設定到期日。
安全地儲存值： 儲存秘密、應用程式標識碼（用戶端標識符）和租用戶標識元，因為您需要他們向服務主體進行驗證。使用安全的位置，例如組織密碼保存庫。（如果您需要要求從 IT 建立應用程式註冊，請指定您需要傳回這些值。
建立安全組： 建立將用於Power BI的安全組（或要求）。請考慮使用組名，例如 Power BI 管理服務主體，這表示群組將用來存取整個租使用者的元數據。
將服務主體新增為安全組的成員： 使用應用程式識別碼（用戶端標識符）將新的（或現有的）服務主體新增為新安全組的成員。
在 Power BI 中更新系統管理員 API 租使用者設定： 在 Power BI 管理入口網站中，將安全組新增至 [允許服務主體使用只讀 Power BI 系統管理員 API 租使用者設定]。
略過在 Azure 中指派許可權：不要將任何許可權委派給應用程式註冊（它會透過 Power BI 允許服務主體使用只讀 Power BI 系統管理員 API 租使用者設定來存取 Power BI 租用戶層級稽核數據）。
決定應用程式註冊是否應該存取詳細的元數據： 判斷您是否要在建置租使用者清查時擷取語意模型數據表、數據行和量值表達式的詳細資訊。
更新 Power BI 中的詳細元數據租使用者設定：選擇性地，在 Power BI 管理入口網站中，使用詳細的元數據租使用者設定將安全組新增至增強系統管理員 API 回應，以及使用 DAX 增強管理員 API 回應和混搭表達式租用戶設定。
測試服務主體： 使用服務主體建立簡單的腳本來登入，並測試它是否可以從系統管理 API 擷取數據。
建立管理應用程式註冊秘密的程式： 建立檔和定期輪替秘密的程式。決定您將如何安全地將新秘密傳達給任何需要密碼的系統管理員和開發人員。

設定 Power BI 租用戶設定

Power BI 管理入口網站中有數個與擷取租用戶層級稽核數據相關的租用戶設定。

系統管理員 API

有三個與執行系統管理員 API 相關的租用戶設定。

重要

由於這些設定會授與整個租使用者的元數據存取權（而不指派直接 Power BI 許可權），因此您應該嚴格控制它們。

允許服務主體使用只讀 Power BI 系統管理員 API 租使用者設定，可讓您設定哪些服務主體可以呼叫管理員 API。此設定也允許Microsoft Purview 掃描整個Power BI 租使用者，以便填入資料目錄。

注意

您不需要將其他 Power BI 系統管理員明確指派給 [允許服務主體使用只讀 Power BI 系統管理員 API 租使用者] 設定，因為它們已經擁有全租使用者元數據的存取權。

使用詳細元數據租用戶設定增強系統管理員 API 回應可讓您設定哪些使用者和服務主體可以擷取詳細的元數據。元數據是使用元數據掃描 API 來擷取，其中包含數據表、數據行等等。此設定也允許Microsoft Purview 存取 Power BI 語意模型的相關架構層級資訊，以便將其儲存在數據目錄中。

使用 DAX 和混搭運算式租使用者設定增強系統管理員 API 回應可讓您設定哪些使用者和服務主體可以擷取詳細的元數據。元數據是從元數據掃描 API 擷取而來，它可以包含查詢和語意模型量值表達式。

注意

允許服務主體使用只讀 Power BI 系統管理員 API 租使用者設定，特別關於存取系統管理員 API。其名稱與用於存取 使用者 API 的租用戶設定非常類似（如下所述）。如需有關系統管理員 API 與使用者 API 之間差異的詳細資訊，請參閱本文稍早選擇使用者 API 或系統管理員 API 。

使用者 API

有一個適用於呼叫使用者 API 的租用戶設定。在此情況下，服務主體也需要Power BI許可權（例如工作區角色）。

[允許服務主體使用 Power BI API 租使用者設定] 可讓您設定哪些服務主體有權執行 REST API（不包括由不同租用戶設定授與的管理 API，如上所述）。

還有其他與 API 相關的租使用者設定，可存取內嵌 API、串流 API、匯出 API，以及 執行查詢 API。不過，這些 API 已脫離本文的範圍。

如需使用計量之租用戶設定的詳細資訊，請參閱報告層級稽核。

檢查清單 - 設定 Power BI 租使用者設定時，關鍵決策和動作包括：

確認每個服務主體都位於正確的群組中： 確認 Power BI 管理服務主體 群組包含正確的服務主體。
更新 Power BI 中的系統管理員 API 租使用者設定： 將安全組新增至 [允許服務主體使用唯讀的 Power BI 系統管理員 API 租使用者] 設定，以允許使用系統管理員 API 來擷取整個租使用者的元數據。
更新 Power BI 中的詳細元數據租用戶設定：如有必要，請使用詳細的元數據租用戶設定，將安全組新增至增強管理員 API 回應，並使用 DAX 增強管理員 API 回應和混搭表達式租用戶設定。
確認將存取哪些使用者 API： 確認是否需要一或多個使用者 API（此外使用系統管理員 API）。
更新 Power BI 中的使用者 API 租使用者設定： 將安全組新增至 [允許服務主體使用 Power BI API 租使用者] 設定，其適用於使用者 API。

階段 3：解決方案開發和分析

規劃和實作租用戶層級稽核解決方案的第三個階段著重於解決方案開發和分析。此時，所有規劃和決策都已發生，且您已符合必要條件並完成設定。您現在已準備好開始進行解決方案開發，以便執行分析，並從稽核數據取得見解。

描述階段 3 的流程圖，其著重於租用戶層級稽核解決方案的解決方案開發和分析。

擷取和儲存原始數據

此時，您的需求和優先順序應該清楚。關於如何存取稽核數據和儲存稽核數據的位置，已做出重要技術決策。已選取慣用的工具，並已設定必要條件和設定。在前兩個階段中，您可能已完成一或多個小型專案（概念證明），以證明可行性。下一個步驟是設定程式來擷取和儲存原始稽核數據。

如同大部分Microsoft API 所傳回的數據，稽核數據會格式化為 JSON。 JSON 格式的數據是自我描述，因為它是包含結構和數據的人類可讀取文字。

JSON 代表由屬性值組和數位所組成的數據物件。例如，"state": "Active"是狀態屬性值為Active的範例。 JSON 陣列包含以逗號分隔的已排序專案清單，並以方括弧（[ ]）括住。在 JSON 結果中尋找巢狀數位很常見。一旦您熟悉 JSON 結果的階層式結構，即可直接了解數據結構，例如工作區中的語意模型清單（陣列）。

以下是擷取和儲存從 API 擷取和儲存原始數據的一些考慮。

將使用哪些命名慣例？ 針對檔案型系統，檔案、資料夾和數據湖區域需要命名慣例。對於資料庫，數據表和數據行都需要命名慣例。
將使用何種格式來儲存原始數據？ 隨著 Power BI 持續引進新功能，目前不會出現新的活動。基於這個理由，我們建議您擷取並保留原始 JSON 結果。請勿在擷取數據時剖析、篩選或格式化數據。如此一來，您就可以使用原始原始數據重新產生策劃的稽核數據。
將使用哪些儲存位置？ Data Lake 或 Blob 記憶體通常用來儲存原始數據。如需詳細資訊，請參閱決定本文稍早儲存稽核數據的位置。
您將儲存多少歷程記錄？ 將稽核數據匯出至您可以儲存歷程記錄的位置。計劃至少積累兩年的歷史。如此一來，您就可以分析超過預設 30 天保留期間的趨勢和變更。您可以選擇無限期地儲存數據，或視組織的數據保留原則而定，決定較短的期間。
您如何追蹤程式上次執行的時間？ 設定組態檔或對等專案，以在進程啟動和完成時記錄時間戳。下一次進程執行時，它可以擷取這些時間戳。當您使用元數據掃描 API 來擷取數據時，儲存時間戳特別重要。
您如何處理節流？ 某些 Power BI REST API 和 Microsoft Graph API 會實作節流。如果您的 API 要求受到節流，您會收到 429 錯誤（太多要求）。對於需要擷取大量數據的大型組織來說，節流可能是常見的問題。如何避免因為節流而失敗的嘗試，視您用來存取和擷取數據的技術而定。其中一個選項是在腳本中開發邏輯，以在等候期間後重試以回應 429 個「太多要求」錯誤。
合規性所需的稽核數據嗎？ 許多組織會使用原始稽核記錄來執行合規性稽核，或回應安全性調查。在這些情況下，強烈建議您將原始數據儲存在不可變的記憶體中。如此一來，一旦寫入數據，系統管理員或其他使用者就無法變更或刪除數據。
支援需求所需的儲存層為何？ 儲存原始數據的最佳位置是 Data Lake（例如 Azure Data Lake Storage Gen2）或物件記憶體（例如 Azure Blob 儲存體）。如果雲端服務不是選項，也可以使用文件系統。

檢查清單 - 擷取和儲存原始資料時，關鍵決策和動作包括：

確認需求和優先順序： 釐清要先擷取之數據的需求和優先順序。
確認要擷取的數據源： 確認您需要之每種數據類型的來源。
設定程式以擷取數據並將其載入原始數據區域： 建立初始程式以擷取和載入原始數據的原始狀態，而不需要任何轉換。測試程式如預期般運作。
建立執行程式的排程： 設定週期性排程以執行擷取、載入和轉換程式。
確認認證受到安全管理： 確認密碼、秘密和金鑰會以安全的方式儲存和通訊。
確認安全性已正確設定： 確認已針對原始數據正確設定訪問許可權。請確定系統管理員和稽核員可以存取原始數據。

如需稽核和監視解決方案如何隨著時間成長的詳細資訊，請參閱本文稍後的操作和改善。

建立策劃的數據

此時，會擷取並儲存原始數據。下一個步驟是為策劃的數據建立個別的黃金數據層。其目標是轉換數據檔，並將其儲存在星狀架構中。星型架構包含維度數據表和事實數據表，而且會刻意針對分析和報告進行優化。策劃數據層中的檔案會成為Power BI數據模型的來源（下一個主題所述）。

提示

當您預期會有一個以上的數據模型時，投資集中式策劃的數據層特別有用。

檢查清單 - 建立策劃的數據層時，關鍵決策和動作包括：

確認需求和優先順序： 如果您想要針對轉換的數據使用中繼銀層，請釐清您需要完成之工作的需求和目標。
設定程式以轉換原始數據，並將其載入策劃的數據區域： 建立程式以轉換數據，並將數據載入星狀架構。測試程式如預期般運作。
建立排程以執行程序： 設定週期性排程以填入策劃的數據層。
確認安全性已正確設定： 確認已針對策劃的數據正確設定訪問許可權。請確定數據模型的開發人員可以存取策劃的數據。

建立數據模型

本主題是關於設定分析 數據模型。數據模型是針對分析優化的可查詢數據資源。有時稱為語意模型，或只是模型。針對稽核和監視解決方案，數據模型可能會實作為Power BI語意模型。

在稽核和監視的內容中，數據模型會從策劃的（金）數據層源數據。如果您選擇不建立策劃的數據層，則數據模型會直接從原始數據產生其數據。

我們建議您的Power BI數據模型實作星型架構設計。當源數據是策劃的數據層時，Power BI 數據模型星型架構應該會鏡像策劃的數據層星型架構。

提示

如需星型架構設計的概觀，請參閱瞭解星型架構和PowerBI的重要性。

如同任何 Power BI 專案，建立數據模型是反覆的程式。您可以視需要新增量值。您也可以新增數據表和數據行，因為新的稽核事件可供使用。在時間中，您甚至可以整合新的數據源。

以下是您可以包含在數據模型中的一些實用維度數據表。

日期： 一組日期屬性，可依日、周、月、季、年和其他相關時間週期來啟用數據的分析（切割和分割）。
時間： 如果您需要依一天的時間進行分析，而且您有大量的稽核數據，請考慮將時間部分與日期分開儲存。這種方法有助於改善查詢效能。
使用者： 描述用戶的屬性（例如部門和地理區域）可篩選許多稽核數據主體。目標是從事實數據表中移除所有使用者詳細數據，並將其儲存在此維度數據表中，以便篩選許多事實數據表。您也可以在此數據表中儲存服務主體。
活動事件： 群組和描述活動事件的屬性（作業）。若要增強報告，您可以建立描述每個活動事件的數據字典。您也可以建立階層來分組並分類類似的活動事件。例如，您可以將所有專案建立事件、刪除事件等等分組。
工作區： 租使用者和工作區屬性中的工作區清單，例如類型（個人或標準）和描述。有些組織會記錄更多有關工作區的詳細數據（可能使用 SharePoint 清單）。您可以將這些詳細資料整合到此維度數據表。您必須決定此維度數據表是否只儲存工作區的目前狀態，或是否儲存版本化數據，以反映一段時間的重大工作區變更。例如，當工作區名稱變更時，歷程記錄報告是否會顯示目前工作區名稱或當時目前的工作區名稱？如需版本設定的詳細資訊，請參閱緩時變維度。
項目類型： Power BI 專案類型清單（語意模型、報表和其他專案）。
容量： 租使用者中的 Premium 容量清單。
網關： 租用戶中的數據網關清單。
數據源： 任何語意模型、數據流或 Datamart 所使用的數據源清單。

以下是您可以包含在數據模型中的一些實用事實數據表（主旨）。

用戶活動： 源自原始 JSON 數據的事實數據。拿掉任何沒有分析值的屬性。任何屬於維度數據表的屬性（上圖）也會移除。
租使用者清查： 租用戶中發佈之所有項目的時間點快照集。如需詳細資訊，請參閱本文稍早的租使用者清查。
語意模型： 包含涉及語意模型的用戶活動（例如語意模型變更），或相關的數據源。
語意模型重新整理： 儲存數據重新整理作業，包括類型的詳細數據（已排程或隨選）、持續時間、狀態，以及使用者起始作業的詳細數據。
工作區角色： 工作區角色指派的時間點快照集。
使用者授權： 使用者授權的時間點快照集。雖然您可能想要將使用者授權儲存在Users維度數據表中，但該方法不支援一段時間的授權變更和趨勢分析。
使用者群組成員資格： 指派給安全組之使用者（和服務主體）的時間點快照集。
社群活動： 包括與社群相關的事實，例如訓練活動。例如，相較於訓練出席，您可以分析 Power BI 用戶活動。這項數據可以説明卓越中心找出潛在的新冠軍。

事實數據表不應包含報表建立者將篩選的數據行。相反地，這些數據行屬於相關的維度數據表。此設計不僅對查詢更有效率，而且會藉由多個事實來提升維度數據表的重複使用（稱為鑽研）。最後一點對於產生實用且方便用戶的數據模型很重要，當您新增事實數據表（主旨）時，這個模型是可延伸的。

例如， Users 維度數據表會與每個事實數據表相關。它應該與 用戶活動事實數據表（執行活動 的人員）、 租使用者清查 事實數據表（誰建立已發佈的專案）和其他所有事實數據表有關。當使用者在Users維度數據表中依使用者篩選報表時，該報表中的視覺效果可以從任何相關事實數據表顯示該用戶的事實。

當您設計模型時，請確定屬性在模型中只顯示一次，而且只顯示一次。例如，使用者電子郵件地址應該只會顯示在 [使用者] 維度數據表中。它也會存在於其他事實數據表中（作為支援模型關聯性的維度索引鍵）。不過，您應該在每個事實數據表中隱藏它。

建議您建立與報表不同的數據模型。語意模型的分離及其報表會導致集中式語意模型提供許多報表。如需使用共用語意模型的詳細資訊，請參閱受控自助 BI 使用案例。

請考慮設定數據列層級安全性（RLS），讓其他用戶能夠分析和報告稽核數據，而超越卓越中心、稽核員和系統管理員。例如，您可以使用 RLS 規則，允許內容建立者和取用者報告自己的使用者活動或開發工作。

檢查清單 - 建立數據模型時，關鍵決策和動作包括：

規劃和建立數據模型： 將數據模型設計為星型架構。驗證關聯性如預期般運作。當您開發模型時，反覆建立量值，並根據分析需求新增其他數據。視需要納入待辦項目的未來改進。
設定 RLS： 如果您想要讓其他一般使用者使用數據模型，請設定資料列層級安全性來限制數據存取。驗證 RLS 角色傳回正確的數據。

增強資料模型

若要有效地分析內容使用量和用戶活動，建議您擴充數據模型。當您探索商機和新需求時，數據模型增強功能可以逐漸反覆地完成。

建立分類

增強模型並增加數據值的其中一種方法，就是將數據模型新增分類。請確定報表會一致地使用這些分類。

您可以選擇根據使用者的使用量層級來分類 使用者 ，或根據其使用層級來分類內容。

使用者使用分類

請考慮下列分類來使用使用者。

頻繁用戶： 過去 12 個月中記錄的活動，以及過去 12 個月中的 9 筆記錄。
作用中用戶： 過去一個月記錄的活動。
偶爾使用者： 過去9個月記錄的活動，但在過去一個月內沒有活動。
非使用中用戶： 過去9個月沒有記錄的活動。

提示

瞭解您的偶爾或非使用中用戶是誰，尤其是當他們擁有 Pro 或 PPU 授權時，這很有説明（這牽涉到成本）。也有助於知道您經常和最活躍的用戶是誰。請考慮邀請他們加入上班時間或參加訓練。您最活躍的內容建立者可能是加入您冠軍網路的候選專案。

內容使用分類

請考慮下列內容使用方式的分類。

常用內容： 過去一周記錄的活動，在過去12個月中有9個記錄。
主動使用的內容： 過去一個月記錄的活動。
偶爾使用的內容： 過去九個月記錄的活動，但在過去一個月內沒有活動。
未使用的內容： 過去9個月沒有記錄的活動。

使用者類型分類

請考慮下列使用者類型的分類。

內容建立者： 在過去六個月中建立、發佈或編輯內容的活動。
內容查看器： 在過去六個月中記錄的活動，可檢視內容，但沒有任何內容建立活動。

考慮重新存取與趨勢

您應該決定使用者或內容的使用分類是否只根據最近發生的活動。 您可能也想要考慮將一段時間的平均或趨勢使用量納入考慮。

請考慮一些示範簡單分類邏輯可能歪曲實境的範例。

一位經理本周檢視了一份報告。然而，在那周之前，經理在過去六個月里沒有看到任何報告。您不應該將此管理員視為根據最近使用方式而頻繁使用的使用者。
報表建立者每周都會發佈新的報表。當您分析經常使用者的使用量時，報表建立者的一般活動似乎是正面的。不過，在進一步調查時，您發現每次編輯報表時，此使用者已重新發佈新報表（具有新的報表名稱）。報表建立者擁有更多訓練會很有用。
主管會偶爾檢視報表，因此其使用分類經常變更。您可能需要以不同的方式分析特定類型的使用者，例如主管。
內部稽核員每年檢視重要報告一次。內部稽核員可能是非使用中用戶，因為其不常使用。有人可能會採取步驟來移除其 Pro 或 PPU 授權。或者，有人可能認為報告應該退休，因為它不常使用。

提示

您可以使用 DAX 時間智慧函式來計算平均值和趨勢。若要瞭解如何使用這些函式，請透過在Power BI Desktop 模型學習課程模組中使用DAX時間智慧函式。

檢查清單 – 建立分類使用方式數據時，關鍵決策和動作包括：

取得分類定義的共識： 與相關專案關係人討論分類定義。請確定做出決策時有協定。
建立檔： 請確定內容建立者和取用者的檔中包含分類定義。
建立意見反應迴圈： 確定使用者有辦法詢問問題或建議對分類定義進行變更。

建立分析報告

此時，稽核數據已擷取並儲存，而且您已發行數據模型。下一個步驟是建立分析報告。

專注於每個物件最相關的重要資訊。您的稽核報告可能有數個物件。每個物件都會對不同的資訊感興趣，並針對不同的用途。您可以隨報表提供的物件包括：

主管贊助人
卓越中心
Power BI 系統管理員
工作區系統管理員
進階容量管理員
閘道系統管理員
Power BI 開發人員和內容建立者
稽核員

以下是建立稽核報告時，您可能想要開始使用的一些最常見分析需求。

熱門內容檢視： 您的主管贊助者和領導小組可能主要對一段時間的摘要資訊和趨勢感興趣。您的工作區系統管理員、開發人員和內容建立者對詳細數據更感興趣。
頂級用戶活動： 您的卓越中心將有興趣誰使用Power BI、做法和時機。您的 Premium 容量系統管理員會有興趣誰使用容量來確保其健康情況和穩定性。
租使用者清查： 您的Power BI系統管理員、工作區系統管理員和稽核員會有興趣了解內容存在的位置、歷程及其安全性設定。

此清單並非全含。其旨在提供您如何建立以特定需求為目標的分析報告的想法。如需更多考慮，請參閱本文稍早的數據需求和稽核和監視概觀。這些資源包含許多概念，說明如何使用稽核數據，以及您可以選擇在報表中呈現的信息類型。

提示

雖然呈現大量數據很誘人，但只包含您準備採取行動的資訊。請確定每個報表頁面都清楚說明其用途、應該採取哪些動作，以及由誰採取哪些動作。

若要瞭解如何建立分析報表，請透過 Power BI 學習路徑中的設計有效報表。

檢查清單 - 規劃分析稽核報告時，關鍵決策和動作包括：

檢閱需求： 根據已知需求和應回答的特定問題，排定建立報表的優先順序。
確認您的物件： 釐清誰將使用稽核報告，以及其用途為何。
建立和部署報表： 開發第一組核心報表。隨著時間逐漸擴充和增強它們。
在應用程式中散發報表： 請考慮建立包含所有稽核和監視報告的應用程式。
確認誰可以存取報表： 請確定報表（或應用程式）可供正確的使用者使用。
建立意見反應迴圈： 請確定報表取用者有辦法提供意見反應或建議，或報告問題。

根據數據採取動作

稽核數據很實用，因為它可協助您瞭解 Power BI 租用戶中發生的情況。雖然看起來很明顯，但可以輕易地忽略您從稽核數據中學到的內容。基於這個理由，我們建議您指派負責追蹤可測量改善的人員，而不只是檢閱稽核報告。如此一來，您就可以在採用和 Power BI 的成熟程度上取得漸進、可測量的進步。

您可以根據目標以及從稽核數據中學到的內容，採取許多不同的動作。本節的其餘部分提供數個想法。

內容使用方式

以下是一些您可能根據內容使用方式採取的動作。

內容經常使用（每日或每周）： 確認任何重要內容都經過認證。確認擁有權是清楚的，且解決方案已得到充分支援。
大量工作區檢視： 發生大量工作區檢視時，請調查Power BI 應用程式未使用的原因。
很少使用內容： 請連絡目標使用者，以判斷解決方案是否符合其需求，或其需求是否已變更。
重新整理活動比檢視更頻繁： 請連絡內容擁有者，以了解為什麼語意模型會定期重新整理，而不需要最近使用語意模型或相關報表。

使用者活動

以下是您可能根據用戶活動採取的一些動作。

新使用者的第一次發佈動作： 識別使用者類型何時從取用者變更為建立者，您可以在使用者第一次發佈內容時加以識別。傳送標準電子郵件，提供實用資源的指引和連結，是絕佳的機會。
與最常見的內容建立者互動： 邀請您最活躍的建立者加入您的擁護者網路，或參與您的練習社群。
授權管理： 確認非使用中的建立者是否需要 Pro 或 PPU 授權。
使用者試用版啟用： 試用版授權啟用可以提示您在試用結束之前，將永久授權指派給使用者。

用戶訓練機會

以下是您可能會從稽核數據識別的一些用戶訓練機會。

相同內容建立者發佈的大量語意模型： 教導用戶共用語意模型，以及避免建立重複語意模型很重要的原因。
從個人工作區過度共用： 請連絡從個人工作區進行大量共享的使用者。教導他們關於標準工作區。
個人工作區的重要報表檢視： 連絡擁有大量報表檢視內容的使用者。教導他們標準工作區如何優於個人工作區。

提示

您也可以檢閱內部 Power BI 社群所回答的問題，以及提交至技術支援中心的問題，以改善訓練內容或檔。

安全性

以下是您可能想要主動監視的一些安全性情況。

指派給高許可權網狀架構系統管理員角色的使用者太多。
太多工作區系統管理員（當成員、參與者或查看器工作區角色足夠時）。
指派給語意模型的過度建置許可權（當讀取許可權足夠時）。
當 Power BI 應用程式許可權或工作區查看器角色對內容取用者而言，高使用率的個別項目許可權。
內容如何與外部用戶共用。

如需詳細資訊，請參閱安全性規劃文章。

治理和風險降低

以下是您可能會遇到的一些情況。請考慮在稽核報告中明確尋找這些類型的情況，因此您已準備好快速採取行動。

未背書之報表（和基礎語意模型）的大量檢視。
大量使用未知或未經批准的數據源。
不符合來源檔案所在位置治理指導方針的檔案位置。
工作區名稱不符合治理需求。
敏感度標籤用於信息保護。
一致的數據重新整理失敗。
列印的重大和週期性使用。
非預期或過度使用訂用帳戶。
非預期的個人閘道使用。

每個情況中要採取的特定動作將取決於您的治理原則。如需詳細資訊，請參閱網狀架構採用藍圖中的治理。

檢查清單 - 根據稽核數據規劃潛在動作時，關鍵決策和動作包括：

釐清預期： 建立稽核報告，並清楚預期哪些動作。
釐清誰將負責動作： 請確定已指派角色和責任。
建立自動化： 可能的話，將可重複的已知動作自動化。
使用追蹤系統： 使用系統來追蹤觀察到的情況，包括聯繫人、下一個計劃性動作、負責的人員、解決和狀態。

階段 4：維護、增強和監視

規劃和實作租用戶層級稽核解決方案的第四個階段著重於維護、增強功能及監視。此時，您的稽核解決方案正在使用生產環境。您現在主要關心維護、增強及監視解決方案。

描述階段 4 的流程圖，其著重於維護、增強及監視租用戶層級的稽核解決方案。

運作和改善

當初始開發和測試完成且您已自動化程式時，稽核程式通常會被視為在生產環境中執行。在生產環境中執行的自動化稽核程式對於品質、可靠性、穩定性和支援的期望值（比手動程序還要高。

生產層級的稽核程式已運作。 運作化解決方案通常包含下列許多特性。

安全： 認證會安全地儲存和管理。文本不包含純文字的密碼或金鑰。
排程： 可靠的排程系統已就緒。
變更管理： 使用變更管理做法和多個環境，以確保保護生產環境。您也可以使用開發和測試環境，或只是開發環境。
支援： 已明確定義支援解決方案的小組。小組成員已經過訓練，他們了解作業期望。已識別備份成員，並在適當時進行交叉訓練。
警示： 發生錯誤時，警示會自動通知支援小組。最好是警示同時包含記錄和電子郵件（而非僅限電子郵件）。記錄對於分析記錄的錯誤和警告很有用。
記錄： 系統會記錄進程，以便在稽核數據更新時有記錄。記錄的信息應該記錄開始時間、結束時間，以及執行進程之使用者或應用程式的身分識別。
錯誤處理： 腳本和處理程式會正常處理和記錄錯誤（例如是否要立即結束、繼續或等候，然後再試一次）。發生錯誤時，警示通知會傳送給支援小組。
編碼標準： 使用良好效能的編碼技術。例如，迴圈是有目的地避免的，但在必要時除外。使用一致的編碼標準、批注、格式和語法，讓解決方案更容易維護和支援。
重複使用和模組化：若要將重複專案最小化，程式代碼和組態值（例如通知的連接字串或電子郵件位址）會模組化，讓其他腳本和程式可以重複使用它們。

提示

您不必一次執行所有列出的一切。當您獲得經驗時，可以累加改善解決方案，使其變得完整且健全。請注意，您在在線找到的大多數範例都是簡單、一次性的腳本代碼段，可能不是生產品質。

檢查清單 - 規劃運作並改善稽核解決方案時，關鍵決策和動作包括：

評估現有解決方案層級： 判斷是否有機會改善和穩定自動化的現有稽核解決方案。
建立生產層級標準： 決定您想要針對自動化稽核程序擁有哪些標準。您可以實事求是地增加一段時間的改進因素。
建立改進計劃： 規劃改善生產稽核解決方案的質量和穩定性。
判斷是否需要個別的開發環境： 評估風險層級，並依賴生產數據。決定何時建立個別的開發與生產環境（和測試）環境。
請考慮數據保留策略： 判斷您是否需要實作數據保留程式，以在一段時間后或要求時清除數據。

檔和支援

對於任何生產層級解決方案而言，檔和支援都很重要。根據目標物件和用途，建立數種類型的檔很有説明。

技術文件

技術檔是以建置解決方案的技術小組為目標，以及隨著時間逐漸改善和擴充解決方案的人員。這也是支援小組的實用資源。

技術檔應包含：

架構元件和必要條件的摘要。
誰擁有和管理解決方案。
支援解決方案的人員。
架構圖表。
設計決策，包括目標、做出某些技術選擇的原因，以及限制式（例如成本或技能）。
安全性決策和選擇。
使用的命名慣例。
編碼和技術標準和指導方針。
變更管理需求。
部署、安裝和安裝指示。
技術債務的已知領域（如果有機會的話，可以改善的領域）。

支援文件

視稽核解決方案的關鍵程度而定，如果發生緊急問題，您可能有技術支援中心或支援小組。它們可能每天都有提供。

支援文件有時稱為 知識庫 或 Runbook。本檔是以技術支援中心或支援小組為目標，且應該包含：

發生問題時的疑難解答指引。例如，當數據重新整理失敗時。
要持續採取的動作。例如，有人可能需要定期執行一些手動步驟，直到問題解決為止。

內容建立者檔

您可以藉由將使用量和採用分析提供給整個組織的其他小組，從稽核解決方案衍生更多價值（必要時強制執行數據列層級安全性）。

內容建立者檔是以自助內容建立者為目標，這些建立者會建立產生策劃稽核數據的報表和數據模型。其中包含數據模型的相關信息，包括一般數據定義。

檢查清單 – 規劃稽核解決方案的檔和支援時，關鍵決策和動作包括：

確認誰預期支持解決方案： 判斷誰將支援被視為生產層級的稽核解決方案（或具有下游報表相依性）。
確定支援小組整備： 確認支援小組已準備好支援稽核解決方案。識別是否有任何需要解決的整備差距。
安排跨訓練： 為支援小組進行知識轉移課程或跨訓練課程。
釐清支援小組的期望： 請確定已清楚記載並傳達響應和解決的期望。決定是否需要有人待命，才能快速解決與稽核解決方案相關的問題。
建立技術檔： 建立有關技術架構和設計決策的檔。
建立支援檔： 更新技術支援中心知識庫，以包含如何支援解決方案的相關信息。
建立內容建立者的檔： 建立文件以協助自助建立者使用數據模型。描述常見的數據定義，以改善其用法的一致性。

啟用警示

您可能會想要根據稽核數據中的特定條件引發警示。例如，當有人刪除閘道或 Power BI 系統管理員變更租使用者設定時，您可以引發警示。

如需詳細資訊，請參閱租用戶層級監視。

進行中的管理

您必須執行整個稽核解決方案的持續管理。您可能需要在下列情況下擴充或變更稽核解決方案：

組織會探索新的數據需求。
新的稽核事件會出現在您從 Power BI REST API 取得的原始數據中。
Microsoft對 Power BI REST API 進行變更。
員工會識別改善解決方案的方法。

重要

重大變更很少見，但可能會發生。請務必有人員可以在需要時快速疑難解答問題或更新稽核解決方案。

檢查清單 - 規劃持續管理稽核解決方案時，關鍵決策和動作包括：

指派技術擁有者： 確定整個稽核解決方案具有明確的擁有權和責任。
確認備份存在： 如果發生無法解決支持的緊急問題，請確定有備份技術擁有者可以參與其中。
保留追蹤系統： 請確定您有辦法擷取新的要求，以及優先處理立即優先順序的方法，以及短期、中期和長期（待辦專案）優先順序。

在此系列中的下一篇文章中，瞭解租用戶層級監視。

共用方式為