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

此租用戶層級稽核規劃文章的主要目標讀者為：

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

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

建立安全且生產就緒的端對端稽核解決方案，是需要時間的重要專案。 將其視為在商業智慧上建置商業智慧 (BI 上的 BI)。 如需稽核資料為何如此重要的相關資訊，請參閱稽核和監視概觀。

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

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

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

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

• 階段 1：規劃和決策
  • 需求和優先事項
  • 資料需求
  • 稽核解決方案的類型
  • 權限和責任
  • 技術決策
  • 資料來源決策
• 階段 2：必要條件和設定
  • 建立儲存體帳戶
  • 安裝軟體和設定服務
  • 註冊 Microsoft Entra 應用程式
  • 設定 Power BI 租用戶設定
• 階段 3：解決方案制定和分析
  • 擷取和儲存未經處理資料
  • 建立經過策劃的資料
  • 建立資料模型
  • 強化資料模型
  • 建立分析報告
  • 根據資料採取行動
• 階段 4：維護、增強和監視
  • 運作和改善
  • 文件和支援
  • 啟用警示
  • 進行中的管理

階段 1：規劃和決策

第一階段著重於規劃和決策。 有許多需求和優先事項都需要考量，因此我們建議您分配充足的時間，以了解本節中介紹的主題。 此目標是要制定完善的前期決策，讓下游階段能夠順利執行。

需求和優先事項

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

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

• 您需要回答哪些關鍵問題？ 存在您可以探索的大量稽核資料。 最有效的稽核處理方式是專注於回答具體問題。
• 採用和資料文化的目標為何？ 例如，您可以設立目標，以增加組織中的自助 BI 內容建立者的人數。 在該案例中，您必須衡量與建立、編輯和發佈內容相關的使用者活動。
• 目前存在哪些風險？ 例如，您可能知道過去發生的內容過度共用。 使用者訓練已增強，而您現在想要持續稽核安全性設定和活動。
• 是否有目前的關鍵效能指標 (KPI) 或組織目標？ 例如，您可能訂定組織 KPI，該 KPI 與數位轉型或成為更以資料為導向的組織有關。 租用戶層級稽核資料可協助您衡量 Power BI 實作是否與這些目標保持一致。

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

檢查清單：識別需求和優先事項時，關鍵決策和行動包括以下幾項：

資料需求

定義需求和優先事項之後 (先前所述)，即可識別您所需的資料。 本節涵蓋四種資料類別。

• 使用者活動資料
• 租用戶清查
• 使用者和群組資料
• 安全性資料

您所需的大部分資料都來自管理員 API，其提供與 Power BI 租用戶有關的大量中繼資料。 如需詳細資訊，請參閱本文稍後提及的選擇使用者 API 或管理員 API。

使用者活動資料

將其訂定為第一優先事項，以取得使用者活動的相關資料。 使用者活動也稱為事件或作業，適用於各種用途。

此資料通常稱為活動記錄或事件記錄檔。 從技術上來說，使用者活動資料的取得方式有很多種 (活動記錄是一種方法)。 如需相關決策和活動的詳細資訊，請參閱本文稍後提及的存取使用者活動資料。

以下是使用者活動資料可以回答的一些常見問題。

• 尋找常用使用者和熱門內容
  • 最常檢視的內容有哪些，進行檢視的使用者有哪些？
  • 檢視內容的每日、每週和每月趨勢為何？
  • 報告檢視的趨勢是否上升或下降？
  • 活躍的使用者數有多少？
• 了解使用者行為
  • 最常使用哪種安全性 (應用程式、工作區或依項目共用)？
  • 使用者最常使用的是瀏覽器或行動應用程式嗎？
  • 哪些內容建立者最積極發佈和更新內容？
  • 發佈或更新的內容有哪些、時間為何及執行的使用者有哪些？
• 找出使用者教育和訓練機會
  • 正在從個人工作區進行 (過多) 共用的人員是誰？
  • 正在大量匯出內容的人員是誰？
  • 會定期下載內容的人員是誰？
  • 誰正在發佈許多新的語意模型？
  • 正在大量使用訂用帳戶的人員是誰？
• 改善治理和合規性工作
  • 租用戶設定何時變更，以及執行變更的是哪些 Power BI 管理員？
  • 開始 Power BI 試用版的人員是誰？
  • 外部使用者存取哪些內容，以及存取內容的人員、時間及方法分別為何？
  • 新增或更新敏感度標籤的人員是誰？
  • 根據通過認證的語意模型，報告檢視的百分比為何？
  • 支援多個報告的語意模型百分比為何？
  • 閘道和資料來源的建立或更新時間為何，以及執行這些作業的是哪一名使用者？

如需此資料使用方式的詳細資訊，請參閱了解使用模式。

如需詳細資訊，請參閱本文稍後提及的存取使用者活動資料。

租用戶清查

通常，第二優先事項是擷取資料，以建立租用戶清查。 其有時稱為工作區清查、工作區中繼資料或租用戶中繼資料。

租用戶清查是在指定時間點的快照集。 其會描述在租用戶中發佈的內容。 租用戶清查不包含實際資料或實際報告。 而是描述所有工作區及其項目 (例如語意模型和報告) 的中繼資料。

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

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

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

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

由於租用戶清查是指定時間點的快照集，因此您必須決定中繼資料的擷取和儲存頻率。 若要在兩個時間點之間進行比較，則每週快照集很好用。 例如，如果想要調查工作區的安全性設定，您需要先前的租用戶清查快照集、活動記錄事件，以及目前的租用戶清查快照集。

建置租用戶清查的主要方式有兩種。 如需相關決策和活動的詳細資訊，請參閱本文稍後提及的存取租用戶清查資料。

使用者和群組資料

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

從 Power BI REST API 擷取的資料包含描述使用者的電子郵件地址或安全性群組的名稱。 此資料是指定時間點的快照集。

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

• 找出使用者和群組
  • 從使用者設定檔中取得的完整使用者名稱 (除了電子郵件地址)、部門或位置為何？
  • 身為安全性群組的人員是誰？
  • 安全性群組的擁有者 (可管理成員) 的人員是誰？
• 取得其他使用者資訊
  • 會將哪些授權 (Power BI Pro 或 Power BI Premium Per User (PPU)) 指派給使用者？
  • 最常登入的使用者有哪些？
  • 哪些使用者最近尚未登入 Power BI 服務？

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

安全性資料

您可能需要執行定期安全性稽核。

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

• 找出人員和應用程式
  • 使用者、群組或服務主體可以存取哪些報告？
  • 哪些使用者、群組或服務主體是訂閱者，可透過電子郵件訂閱接收報告？
• 了解內容權限
  • 會將哪些工作區角色指派給哪些使用者和群組？
  • 哪些使用者和群組會指派給每個 Power BI 應用程式對象？
  • 會針對哪些報告以及哪些使用者，指派哪些依項目的權限？
  • 會針對哪些語意模型以及哪些使用者，指派哪些依項目的權限？
  • 哪些語意模型和資料超市已定義列層級安全性 (RLS)？
  • 會與整個組織中的人員共用哪些項目？
  • 會在網際網路上公開發佈哪些項目？
• 了解其他權限
  • 有權使用部署管線進行發佈的人員是誰？
  • 有權管理閘道和資料連線的人員是誰？
  • 有權管理 Premium 容量的人員是誰？

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

如需使用管理員 API 與使用者 API 的詳細資訊 (包括其如何影響資料擷取使用者所需的權限)，請參閱本文稍後提及的選擇使用者 API 或管理員 API。

檢查清單：找出稽核所需的資料時，關鍵決策和行動包括以下幾項：

稽核解決方案的類型

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

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

手動稽核程序

手動稽核依賴的指令碼和程序，會由使用者 (通常是 Power BI 管理員) 視需要執行。 如有需要，使用者會以互動方式執行查詢，以擷取稽核資料。

手動稽核最適合用於以下項目：

• 開發和測試中的新指令碼。
• 一次性的不定期稽核需求。
• 試探性的稽核需求。
• 不需要完整支援的非必要稽核程序。

自動化稽核程序

對週期性所需的資料進行稽核的程序應自動化。 其也稱為自動化程序，會依定期排程進行擷取和處理。 有時稱為無人參與程序。

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

自動化稽核最適合用於以下項目：

• 稽核在生產環境中執行的程序。
• 以定期排程執行的無人參與程序。
• 已完整測試的指令碼。
• 具有其他報告 (或其他程序) 依賴其作為資料來源的基本稽核程序。
• 記載和支援的稽核程序。

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

檢查清單：考量要制定的稽核解決方案類型時，關鍵決策和行動包括以下幾項：

權限和責任

此時，您應該清楚掌握想要完成的工作，以及一開始所需的資料。 現在是決定使用者權限以及角色和責任的絕佳時機。

使用者權限

當您預計建置端對端稽核解決方案時，請考量其他使用者需要存取資料的使用者權限。 具體來說，也就是決定將允許誰存取和檢視稽核資料。

以下是要納入的幾點考量。

直接存取稽核資料

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

• 誰應該擔任 Power BI 管理員？ Power BI 管理員可以存取所有租用戶中繼資料，包括管理員 API。 如需有關決定誰應該是 Power BI 管理員的詳細資訊，請參閱租用戶層級安全性規劃。
• 可以使用現有服務主體的人員是誰？ 若要使用服務主體 (而不是使用者權限) 以存取稽核資料，則必須將祕密提供給獲授權的使用者，才能執行以密碼為基礎的驗證。 祕密 (和金鑰) 的存取應該嚴格控制。
• 是否需要嚴格控制存取？ 某些具有法規和合規性需求的產業必須比其他產業更嚴格地控制存取。
• 是否有大型活動資料磁碟區？ 若要避免達到 API 節流限制，您可能需要嚴格控制能夠直接存取 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 Entra ID 設定。 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。

本節著重於技術選擇。 如需有關存取特定稽核資料類型之來源的考量，請參閱本文稍後提及的資料來源決策。

平台選項

稽核資料的存取方式有很多，而且各不相同。 視選擇的技術而定，您可能會傾向使用慣用的語言。 您可能也需要針對如何安排指令碼的執行制定具體的決策。 各種技術在學習曲線以及入門的難易程度差異甚大。

以下是您可以使用 Power BI REST API 擷取資料的一些技術。

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

本節的其餘部分會簡短介紹表中所示的每個選項。

管理員監視工作區

管理員監視工作區包含 Power BI 服務中預先定義的報告和語意模型。 這種方法很方便，有助 Fabric 管理員檢視最近的稽核資料並掌握使用者活動。

API 文件中的「試試看」

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

您可以使用「試試看」做到以下幾點：

• 手動將要求傳送至 API，以判斷其傳回的是否是您想要的資訊。
• 在寫指令碼之前，請先了解 URL 的建構方式。
• 以非正式的方式檢查資料。

互動式的「試試看」非常適合用於學習、探索和新的手動稽核程序。

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。 如需有關此技術決策的詳細資訊，請參閱本文稍後提及的選擇 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 Key Vault 或另一個安全地儲存加密值的服務讀取機密值。 全球 Power BI 社群也有各種可用的自訂連接器選項。
  • 使用適用於 Power BI Desktop 的 ApiKeyName 選項。 不過，您無法將金鑰值儲存在 Power BI 服務中。
• 要求類型：您可能會遇到一些限制，規定您可以在 Power BI Desktop 中執行的項目。 例如，Power Query 不支援每種 API 要求。 例如，使用 Web.Contents 函式時，僅支援 GET 和 POST 要求。 針對稽核，您通常會傳送 GET 要求。
• 更新的能力：您必須遵循特定的 Power Query 開發模式，才能在 Power BI 服務中成功更新語意模型。 例如，使用 Web.Contents 時必須存在 RelativePath 選項，讓 Power BI 可以正確驗證資料來源的位置，而不會在 Power BI 服務中產生錯誤。

在大部分案例中，我們建議您只將 Power BI Desktop 用於兩個用途。 您應該將其用於以下用途：

• 根據現有經過策劃的資料建置資料模型 (而不是使用其來初步擷取稽核資料)。
• 根據資料模型建立分析報告。

Power Automate

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

如需有關 Power Automate 使用方法的其他概念，請在 Power Automate 範本中搜尋 Power BI。

慣用的 Azure 服務

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

• Azure Functions
• Azure 自動化
• Azure Data Factory
• Azure Synapse Analytics

在大部分案例中，您可以將處理資料擷取邏輯的計算服務，與儲存未經處理資料 (以及適當時經過策劃的資料) 的儲存體服務相結合。 本文稍後將說明技術結構決策的制定考量。

慣用的工具和/或語言

您可以使用慣用的工具和慣用的語言，將要求傳送至 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 應用程式使用者介面

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

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

Microsoft Sentinel 和 KQL

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

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

平台考量

以下是稽核資料的一些存取考量。

• 您要實作手動或自動化稽核程序嗎？ 部分工具會與手動處理或自動化處理緊密相關。 例如，使用者一律會以互動方式執行「試試看」功能，因此其只適合手動稽核程序。
• 您要如何驗證？ 並非所有選項都支援每個驗證選項。 例如，「試試看」功能僅支援使用者驗證。
• 如何安全地儲存認證？ 不同的技術有不同的認證儲存選項。 如需詳細資訊，請參閱本文稍後提及的判斷驗證方法。
• 團隊原本熟悉的是哪一種技術？ 如果團隊有偏好的工具而且熟知如何使用，請從使用該工具。
• 團隊能夠協助什麼？ 如果不同的團隊將支援部署的解決方案，請考量該團隊是否能夠充分提供支援。 還要考量到內部團隊可協助由顧問完成的開發工作。
• 您取得使用核准的工具為何？ 某些工具和技術可能需要核准。 這可能是成本所致。 也可能是 IT 安全性原則所致。
• 您有何排程偏好？ 某些技術會為您做出決策。 其他時候，這將是另一個您必須做出的決策。 例如，如果您選擇撰寫 PowerShell 指令碼，則有各種能夠安排執行之的方式。 相反地，如果您使用 Azure Data Factory 等雲端服務，則會內建排程功能。

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

檢查清單：決定要用來存取稽核資料的技術時，關鍵決策和行動包括以下幾項：

判斷驗證方法

您預計如何設定驗證是關鍵決策。 當您開始使用稽核和監視時，此決策通常是其中一個最困難的環節。 您應該仔細考量可用的選項，以做出旁徵博引的決定。

並非網際網路上的每個 API 都需要驗證。 不過，所有 Power BI REST API 都需要驗證。 當您存取租用戶層級稽核資料時，驗證程序是由 Microsoft 身分識別平台所管理。 其是 Microsoft Entra 身分識別服務的演進，後者是以業界標準通訊協定為基礎。

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

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

存取權杖有兩種：

• 使用者權杖：代表具有已知身分識別的使用者核發。
• 僅限應用程式權杖：代表 Microsoft Entra 應用程式 (服務主體) 核發。

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

下表描述兩個驗證選項。

驗證的類型	說明	適用於	手動稽核程序的絕佳選擇	自動化稽核程序的絕佳選擇
使用者驗證	透過使用者主體名稱 (電子郵件地址) 和密碼，以使用者身分登入。	不定期互動式使用
服務主體驗證	使用向應用程式註冊指派的祕密 (金鑰)，以服務主體的身分登入。	進行中、排程、無人參與操作

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

使用者驗證

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

• 手動稽核程序：您想要透過使用者權限執行指令碼。 根據 API 要求的類型而定，權限可能位於兩個層級的其中之一：
  • 管理員 API 的管理員權限：您必須使用 Power BI 管理員權限，以將要求傳送給管理員 API。
  • 使用者 API 的使用者權限：您必須使用 Power BI 使用者權限，將要求傳送給使用者 API。 如需詳細資訊，請參閱選擇使用者 API 或管理員 API。
• 互動式登入：建議您以互動方式登入，此方式需要輸入電子郵件地址和密碼。 例如，您必須以互動方式登入，才能使用 Microsoft API 文件中找到的「試試看」體驗。
• 追蹤租用戶中繼資料的存取人員：當個別使用者和管理員傳送 API 要求時，您可能會想要稽核那些人是誰。 當您使用服務主體進行驗證時 (如下所述)，活動記錄所擷取的使用者識別碼就是應用程式識別碼。 如果多個管理員使用相同的服務主體進行驗證，則可能很難知道存取資料的管理員是誰。
• 共用管理員帳戶：某些 IT 團隊會使用共用管理員帳戶。 視實作和控制方式而定，這可能不是最佳做法。 您應該考慮使用 Microsoft Entra Privileged Identity Management (PIM)，以授與使用者不定期和暫時的 Power BI 管理員權限，而不是共用帳戶。
• 僅支援使用者驗證的 API：有時候，您可能需要使用某個 API，但服務主體不支援對其進行驗證。 在文件中每個 API 都會指出服務主體是否可以呼叫之。

服務主體驗證

大部分的組織都有一個 Microsoft Entra 租用戶，因此應用程式註冊和服務主體等詞彙往往可以交替使用。 當您註冊 Microsoft Entra 應用程式時，有兩個元件。

• 應用程式註冊：應用程式註冊是全域唯一。 其是註冊 Microsoft Entra 應用程式的全域定義，可供多個租用戶使用。 應用程式註冊也稱為用戶端應用程式或動作項目。 一般而言，用戶端應用程式一詞用來表示使用者機器。 不過，應用程式註冊的情況並非如此。 在 Azure 入口網站中，Microsoft Entra 應用程式位於 Microsoft Entra ID 的 [應用程式註冊] 頁面。
• 服務主體：服務主體是應用程式註冊的當地表示法，可用於特定租用戶。 此服務主體衍生自註冊的 Microsoft Entra 應用程式。 對於具有多個 Microsoft Entra 租用戶的組織，相同的應用程式註冊都可以由多個服務主體參考。 您可以在 Azure 入口網站中，在 Microsoft Entra ID 的 [企業應用程式] 頁面找到服務主體。

服務主體是當地表示法，因此服務主體驗證一詞是提及登入的最常見方式。

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

• 自動化稽核程序：您想要依排程執行無人參與程序。
• 不需要登入 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 管理員和卓越中心

針對不同用途管理多個應用程式註冊需要投入更多精力。 不過，您可以受益於數個優點。

• 查看應用程式註冊的預期用途以及原因：當您看到來自應用程式註冊的用戶端識別碼在稽核資料中出現時，您將了解其用途和原因。 這是建立個別應用程式註冊 (而不是針對所有用途只使用單一應用程式註冊) 的重要優點。
• 查看應用程式註冊的預計使用對象：當您看到來自應用程式註冊的用戶端識別碼在稽核資料中出現時，您將知道正在使用的人員是誰。
• 避免過度佈建權限：您可以遵循最低權限原則，將不同的應用程式註冊提供給需求不同的一組不同人員。 當不需要寫入權限時，您可以使用唯讀應用程式註冊以避免過度佈建權限。 例如，您可能有一些能力很強的自助使用者想要收集其語意模型的相關資料；他們需要存取具有讀取權限的服務主體。 而財務團隊可能有以程式設計方式管理語意模型的卓越中心附屬成員：他們需要存取具有寫入權限的服務主體。
• 知道誰應該擁有祕密：每個應用程式註冊祕密的共用人員應只限於需要祕密的人員。 輪替祕密時 (本節稍後所述)，當您針對不同需求使用不同的應用程式註冊時影響較小。 當您因為使用者離職或變更角色而需要輪替祕密時，這很好用。

應用程式註冊權限

應用程式註冊可以存取資料和資源的主要方式有兩種。 其中牽涉到權限和同意。

• 僅限應用程式的權限：存取和授權是由服務主體處理，而不需要登入的使用者。 驗證方法在自動化案例很好用。 使用僅限應用程式的權限時，請務必了解在 Microsoft Entra ID 中並未指派權限。 相反地，會以下列兩種方式之一指派權限：
  • 如需執行管理員 API：某些 Power BI 租用戶設定允許對管理員 API 端點 (其會傳回全租用戶的稽核中繼資料) 的存取。 如需詳細資訊，請參閱本文稍後提及的進行 Power BI 租用戶設定。
  • 如需執行使用者 API：Power BI 工作區和項目權限適用。 標準 Power BI 權限可控制在執行使用者 API 時，可以將哪些資料傳回服務主體 (根據叫用 API 之使用者或服務主體的權限傳回稽核資料)。
• 委派的權限：使用以範圍為基礎的權限。 此服務主體會代表目前登入的使用者存取資料。 這表示此服務主體無法存取任何超出登入使用者可存取項目以外的內容。 請注意，這與先前所述的僅限使用者驗證的概念不同。 需要自訂應用程式才能正確處理使用者和應用程式權限的組合，因此委派的權限極少用於稽核案例。 很多人經常誤解這個概念，導致許多應用程式註冊遭到過度佈建 (使用權限)。

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

應用程式註冊祕密

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

您也需要考量祕密的安全儲存位置。 組織密碼保存庫 (例如 Azure Key Vault) 便是絕佳的選擇。

安全地管理認證

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

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

• 盡可能與 Azure Key Vault 或其他組織密碼保存庫系統整合。
• 在 PowerShell 指令碼中使用認證和安全字串。 認證同時適用於使用者驗證和服務主體驗證。 不過，針對使用者帳戶啟用多重要素驗證時，您無法使用認證。
• 在 PowerShell 指令碼中出現輸入密碼的提示，或透過瀏覽器使用互動式驗證。
• 針對 Microsoft 所發佈的 PowerShell 使用祕密管理模組。 此模組可以使用本機保存庫來儲存值。 其也可以與遠端 Azure Key Vault 整合，這對於在組織中有多個使用相同指令碼的管理員時很有用。
• 建立 Power BI Desktop 的自訂連接器，以便安全地處理認證。 社群成員會提供某些自訂連接器 (通常是在 GitHub 上)。

Microsoft 驗證資源庫

Azure AD 驗證程式庫 (ADAL) 的支援已於 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)。

檢查清單：決定如何管理驗證時，關鍵決策和行動包括以下幾項：

選擇使用者 API 或管理員 API

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

要考量的 API 有兩種類型。

• 使用者 API：依賴登入使用者 (或服務主體) 的權限以將要求傳送至 API。 例如，傳回工作區中語意模型清單的其中一種方式是透過使用者 API。 可由工作區角色或依項目權限授與讀取語意模型的權限。 執行使用者 API 的方式有兩種：
  • 使用者驗證：登入的使用者必須具有工作區或項目的存取權限。
  • 服務主體驗證：服務主體必須具有工作區或項目的存取權限。
• 管理員 API：從租用戶擷取中繼資料。 其有時稱為組織範圍。 例如，若要傳回租用戶中所有語意模型的清單，您可以使用管理員 API。 執行管理員 API 的方式有兩種：
  • 使用者驗證：登入的使用者必須是 Power BI 管理員，才能執行管理員 API。
  • 服務主體驗證：服務主體必須具有執行管理員 API 的權限 (而不需像使用者 API 那樣依賴安全性權限)。

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

API 名稱	API 的類型	Scope	語意模型數目
取得資料集	User	個人工作區	一
取得資料集	User	個人工作區	全部
在群組中取得資料集	User	一個工作區	只要登入的使用者具有讀取語意模型的權限，則為一個
在群組中取得資料集	User	一個工作區	只要登入的使用者具有讀取每個語意模型的權限，則為全部
以管理員身分在群組中取得資料集	管理	一個工作區	全部
以管理員身分取得資料集	管理	整個租用戶	全部

如需租用戶設定的相關資訊，請參閱本文稍後提及的進行 Power BI 租用戶設定。

檢查清單：選擇使用的是使用者 API 或管理員 API 時，關鍵決策和行動包括以下幾項：

選擇 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 模組可讓指令碼的撰寫過程更輕鬆。

Power BI 管理模組

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

以下是數個常用的 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 的考量。

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

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

資料閘道模組

資料閘道模組包含 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。 建議的方法	透過這項技巧，就能在簡單和彈性之間取得平衡。 您可從 Power BI 管理設定檔模組取得 Invoke-PowerBIRestMethod Cmdlet。 此 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 驗證程式庫 (MSAL) 進行驗證之後，請使用泛型 Invoke-RestMethod Cmdlet 擷取資料，以呼叫您慣用的 API (例如，以管理員身分取得管線使用者)。

在上表中，第一種技巧描述的是一種在輕鬆使用與彈性之間取得平衡的方法。 這種方法為大部分組織的需求提供最佳平衡，這就是為何建議這麼做的原因。 某些組織可能有現有的 IT 原則和員工偏好，這些都會影響您決定如何使用 PowerShell。

技術使用者 (和管理員) 可以使用 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 時，關鍵決策和行動包括以下幾項：

判斷稽核資料的儲存位置

當您預計建置端對端稽核解決方案時，您必須決定未經處理資料的儲存位置 (以及下一節涵蓋之經過策劃的資料)。 您對於資料儲存的決策與如何處理資料整合的偏好有關。

當您擷取未經處理稽核資料時，請盡可能保持簡單。 建議您在一開始擷取資料時，不要選取特定屬性、執行轉換，或套用任何格式化。 相反地，擷取所有可用的屬性，並以原始狀態儲存資料。

以下幾個原因，說明為何以原始狀態儲存未經處理資料是最佳做法。

• 歷程記錄中可用的所有資料：新的屬性和新的事件類型將會隨著時間而可供使用。 儲存所有未經處理資料是絕佳方法，以確保您一律可以存取擷取資料時可用的任何資料。 即使您需要數週或數月的時間才能意識到新的資料屬性是可供使用的，您還是能夠對其進行歷史分析，因為您是在未經處理資料中擷取到那些屬性。
• 適應變更：如果未經處理資料格式有所變更，則擷取資料的程序不會受到影響。 由於某些稽核資料具有時效性，因此請務必確保您設計的資料擷取程序在來源發生變更時不會失敗。
• 角色和責任：不同的小組成員 (例如資料工程師或 Fabric 管理員) 可能會負責程序的建立，以存取、擷取及儲存未經處理的稽核資料。 簡化資料擷取程序，讓多個小組的共同作業變得更輕鬆。

以下是未經處理資料的一些儲存選項。

• 資料湖或物件儲存體：雲端服務，例如專門儲存任何結構之檔案的 OneLake。 這是儲存未經處理稽核資料的理想選擇。 在資料湖結構中，未經處理資料應該儲存在銅級層。
• 檔案系統：檔案系統 (例如 Windows 或 Linux) 是儲存未經處理稽核資料的常見選擇。
• 資料庫：可以將 JSON 資料儲存在關聯式資料庫中，例如 Azure SQL Database。 不過，其不像將資料儲存在資料湖或檔案系統中那樣常見。 那是因為查詢和維護 JSON 資料可能會變得更具挑戰性且昂貴，特別是在資料量不斷增長的情況。

請考量涉及資料湖未經處理資料區域的範例。 該區域有儲存活動記錄資料的資料夾階層：Raw > ActivityLog > YYYY > MM。 會依年份和月份分割這些資料夾。 儲存在月份資料夾中的檔案會使用下列格式：PBIActivityLog-YYYYMMDD-YYYYMMDDTTTT.json。 YYYYMMDD 代表實際資料，而 YYYYMMDDTTTT 代表擷取時間戳記。 藉由包含擷取時間戳記，您可以判斷哪一個是最新檔案 (以防您需要再次擷取資料)。 例如，如果您在 2023 年 4 月 25 日上午 9 點 (UTC) 擷取 2023 年 4 月 23 日活動的資料，則檔案名稱會是 PBIActivityLog-20230523-202305250900。

強烈建議您使用的技術，可讓您將未經處理資料寫入不可變儲存體。 不可變儲存體保證一旦寫入資料，就無法覆寫或刪除。 這種區別對稽核人員很重要，而且可讓您相信未經處理資料是可靠的。

您也需要考量如何安全地儲存未經處理資料。 一般而言，很少數使用者需要存取未經處理資料。 未經處理資料的存取通常會視需求提供，通常是提供給資料工程師和系統管理員。 內部稽核人員也可能需要存取。 負責建立經過策劃資料的小組成員 (如下所述) 也需要存取未經處理資料。

以下是一些考量，可協助您選擇未經處理資料儲存體。

• 這是手動或自動化的稽核程序嗎？ 自動化稽核程序通常會有更嚴格的要求，會要求資料的儲存方式和位置。
• 主題領域是否特別敏感？ 根據資料類型及其敏感性，組織可能會有儲存方式和位置的要求。 Power BI 稽核資料包含識別使用者資訊和 IP 位址，因此應將其儲存在安全的區域中。
• 是否有慣用的儲存技術？ 組織內可能有使用中的現有儲存技術，因此這是合理的選擇。
• 使用者是否會直接存取儲存體？ 安全性模型是重要的考量。 通常，很少數使用者會獲得未經處理資料的存取權。 通常會將經過策劃資料的存取權，提供給 Power BI 內容建立者使用，這類建立者會負責建立集中式的資料模型 (即作為報告層的語意模型)。
• 您是否有資料落地需求？ 某些組織有法律或法規資料落地需求，需要將資料儲存在特定資料區域。
• 會如何整理資料？ 使用獎章架構是常見的做法，特別是在資料湖和湖存放庫實作中也是如此。 目標是將資料儲存在銅級、銀級和金級資料層中。 銅級層包含原始的未經處理資料。 銀級層包含用於轉換的已驗證和重複資料刪除資料。 金級層包含經過策劃、高度精簡且可供分析的資料。

檢查清單：規劃未經處理資料的儲存位置時，關鍵決策和行動包括以下幾項：

規劃以建立經過策劃的資料

經過策劃的資料可協助分析，也是為方便使用所設計。 您必須決定如何及在何處建立經過策劃的資料。 您選擇用來儲存經過策劃資料的技術，可能是上一節所列的任何技術。

經過策劃資料的目標是將資料轉換成更好記的格式，且針對分析和報告進行最佳化。 其會形成 Power BI 資料模型的資料來源，這表示您會使用 Power BI 資料模型，以分析組織中 Power BI 的使用方式。 基本資料模型指導適用：您應該採用星狀結構描述設計，其已針對效能和可用性進行最佳化。

您可以選擇以不同方式建立經過策劃的資料。 您必須決定如何進行資料整合，以及在上游多遠的位置套用轉換，為將資料載入星狀描述架構做準備。

資料湖

您可以在資料湖中套用轉換並建立經過策劃的資料檔案。 您應該針對經過策劃的資料使用金級層，使其在邏輯上與在銅級層的未經處理資料分開。 將各層中的資料分隔，也會簡化不同的使用者存取權限的設定。

使用資料湖，在下列情況下轉換及策畫資料：

• 您預期會有多個提供報告的 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 內的每項服務都不需要實作自己的唯一記錄方式。 此項目預設為啟用。

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

技巧	說明	歷程記錄可用的預設天數	手動稽核程序的絕佳選擇	自動化稽核程序的絕佳選擇	設定警示的絕佳選擇	快速入門的絕佳選擇
手動 (使用者介面)	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 天的歷程記錄。 透過稽核 (進階)，長期保留可讓您 (選擇性地) 將稽核記錄保留更長的時間。 由於長期保留僅適用於授權的 E5 使用者，因此其會排除非 E5 使用者和來賓使用者的稽核記錄。 因此，我們建議您僅使用預設的 90 天歷程記錄，以確保擷取所有活動。

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

Microsoft Purview 合規性入口網站中的使用者介面，對於手動稽核程序和不定期調查使用者活動很有用。

適用於雲端應用程式的 Defender

適用於雲端的 Defender 應用程式入口網站是一個好用的地方，可用來檢視活動和警示，而不需建立指令碼以擷取和下載資料。 此入口網站也可讓您檢視來自 Power BI 活動記錄和使用者登入的資料。

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

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

有存取適用於雲端的 Defender 應用程式的授權需求。 也需要個別的權限。

適用於雲端的 Defender 應用程式中的使用者介面適用於手動稽核程序，以及使用者活動的一次性調查。

Power BI 活動記錄

Power BI 活動記錄源整合的稽核記錄。 其只包含與 Power BI 服務相關的使用者活動。

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

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

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

Power BI 活動記錄資料可供所有 Fabric 管理員和 Power Platform 管理員使用。 您可以從整合稽核記錄存取資料，這些記錄皆可供特定 Exchange Online 角色使用。 如需詳細資訊，請參閱追蹤 Power BI 中的使用者活動。

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

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 天的歷程記錄。

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

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

從 Office 365 管理活動 API 以程式設計方式擷取稽核資料，是當 IT 需要從各種服務 (Power BI 之外) 擷取和儲存稽核記錄時的絕佳選擇。

Microsoft Sentinel

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

因為其是個別的 Azure 服務，所以您想要執行 Kusto 查詢語言 (KQL) 查詢的任何管理員或使用者，都必須在 Azure Log Analytics (Azure 監視器) 中獲得權限。 擁有權限時，他們就可以查詢在 PowerBIActivity 資料表中儲存的稽核資料。 不過，請記住，在大部分案例中，您會將金級層中經過策劃資料 (而不是銅級層中的未經處理資料) 的存取權授與使用者。

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

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

• 預先建置適用於 Power BI 語意模型的 Log Analytics 範本應用程式。
• 適用於 Azure 資料總管 (Kusto) 的 Power BI Desktop 連接器。
• Azure 資料總管中的 Web 型查詢體驗。
• 可傳送 KQL 查詢的任何查詢工具。

您可以擷取的歷程記錄期間取決於 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 中存在哪些工作區和內容 (語意模型、報告和其他項目)，而且能夠與使用者活動資料相輔相成 (如上一節所述)。 如需識別資料需求的詳細資訊，請參閱本文稍早提及的租用戶清查。

使用者活動 (先前所述) 是稽核事件；其是使用者在特定日期和時間採取的行動記錄。 但租用戶清查不同。 租用戶清查是指定時間點的快照集。 其會描述您擷取 Power BI 服務時，其中所有已發佈項目的目前狀態。

若要正確分析 Power BI 租用戶中發生的情況，您需要使用者活動資料和租用戶清查。 將兩者結合可讓您了解所擁有的內容多寡和這些內容的位置。 這麼做也可讓您尋找未使用或使用量過低的內容 (因為活動記錄中沒有任何事件)。 租用戶清查也可協助您編譯所有項目目前名稱的清單，這在項目名稱有所變更時很有用。

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

您可以透過兩種不同的方式取得租用戶清查資料。

技巧	說明	最適合以下項目	手動稽核程序的絕佳選擇	自動化稽核程序的絕佳選擇
程式設計	Get Groups as Admin API 或 Get-PowerBIWorkspace PowerShell Cmdlet 可以提供適用於整個租用戶的工作區清單。 您可以選擇性地包含每個工作區的個別項目 (例如語意模型和報告)。	較小型的組織或較少的資料量
程式設計	一組非同步管理員 API (統稱為中繼資料掃描 API 或掃描程式 API)，可以傳回工作區和個別項目的清單。 您也可以選擇性地包含詳細的中繼資料 (例如資料表、資料行和量值運算式)。	具有大量資料和/或需要取得詳細結果的組織

本節的其餘部分會介紹表中列出的每個技巧。

群組 API 或工作區 Cmdlet

若要擷取工作區清單，您可以使用數個 REST API 的其中一個，例如「以管理員身分取得群組」API (使用您選擇的工具)。 結果包含額外的中繼資料，例如描述，以及是否將工作區儲存在 Premium 容量。

Get Groups as Admin REST API 包含實用的 $expand 參數。 此參數可讓您選擇性地擴大結果範圍，使其包含在工作區中發佈的項目清單 (例如語意模型和報告)。 您也可以將 users 資料類型傳遞至 $expand 參數，以包含向工作區角色指派的使用者。

您也可以使用 Get-PowerBIWorkspace PowerShell Cmdlet。 其來自 Power BI 管理工作區模組。 當您設定 -Scope 參數 organization 時，其運作方式就跟 Get Groups as Admin API 一樣。 Cmdlet 也接受 -Include 參數 (這相當於 REST API 中的 $expand 參數)，以包含在工作區中發佈的項目 (例如語意模型和報告)。

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

Get Groups as Admin REST API 或 Get-PowerBIWorkspace PowerShell Cmdlet 是手動稽核程序和一次性調查的絕佳選項。 具有大量資料的大型組織通常會覺得這些選項難以使用。 REST API 和 Cmdlet 一律會擷取一組完整的資料，因此可能需要很長的時間才能執行。 因此，大型組織可能會遇到對每小時允許之要求數目的限制 (稱為節流，這麼做是為了保護服務的健康情況)。 中繼資料掃描 API (如下所述) 提供更可靠且可調整的替代方案。

中繼資料掃描 API

通常稱為掃描程式 API 的中繼資料掃描 API 是一組 API，可傳回工作區及其 Power BI 項目 (語意模型、報告和其他項目) 的清單。 就概念上來說，這些 API 會如上一節所述，提供與群組 API 或工作區 Cmdlet 相同的資料 (等等)。 不過，您用來擷取資料的方法有所不同，而且更適合用來擷取租用戶清查。

您應該考量使用中繼資料掃描 API 而不是 Get Groups as Admin REST API 或 Get-PowerBIWorkspace Cmdlet (先前所述) 的主要原因有兩個。

• 增量資料擷取：掃描程式 API 只會擷取自上次執行後發生變更的資料。 相反地，Get Groups as Admin REST API 和 Get-PowerBIWorkspace Cmdlet 是同步作業，會在每次執行時擷取完整的資料集。
• 更細微的詳細資料層級：掃描程式 API 可以擷取細微的詳細資料 (例如資料表、資料行和量值運算式)，前提是兩個租用戶設定已授與詳細中繼資料的權限。 相反地，Get Groups as Admin REST API 和 Get-PowerBIWorkspace Cmdlet 可用的詳細資料最低層級是依項目類型 (例如工作區中的報告清單)。

使用掃描程式 API 牽涉到更多工作，因為您需要呼叫一連串 API。 此外，其會以非同步程序的形式執行。 非同步程序會在背景執行，因此您不需要等待其完成。 在建立即將排入排程的生產就緒指令碼時，您可能需要與 IT 或開發人員共同作業。

以下是您在使用掃描程式 API 時應遵循的一連串步驟。

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

檢查清單：規劃以存取租用戶清查資料時，關鍵決策和行動包括以下幾項：

存取使用者和群組資料

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

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

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

您擷取的使用者和群組資料是快照集，其會描述在指定時間點的目前狀態。

分析屬性

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

• 使用者的完整名稱：許多資料來源只會包含使用者的電子郵件地址，該使用者是活動的執行者或是指派給角色的人員。 當您想要在分析報告中顯示全名 (顯示名稱) 時，請使用此屬性。 使用全名可讓報告更方便使用。
• 其他使用者屬性：在 Microsoft Entra ID 中，可能會提供有關使用者的其他描述性屬性。 具有分析值的內建使用者設定檔屬性某些範例包括職稱、部門、經理、區域和辦公室位置。
• 安全性群組的成員：大部資料來源都會提供群組的名稱 (例如，Power BI 活動記錄了已將安全性群組指派給工作區角色)。 擷取群組成員資格可改善您完整分析個別使用者執行事項或存取項目的能力。
• 使用者授權：分析將哪些使用者授權 (免費、Power BI Pro 或 Power BI Premium Per User (PPU)) 指派給使用者時很有用。 此資料可協助您識別未使用其授權的人員。 其也可協助您分析所有使用者 (具有授權的不同使用者) 與作用中的使用者 (具有最近的活動)。 如果您考慮新增或擴充 Power BI Premium 授權，建議您一起分析使用者授權資料與使用者活動資料，以執行成本分析。
• 管理員角色的成員：可以編譯一份 Power BI 管理員清單 (包括 Power Platform 管理員)。

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

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

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

擷取使用者和群組資料

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

技巧	說明	手動稽核程序的絕佳選擇	自動化稽核程序的絕佳選擇
手動	Graph 總管 (英文)
程式設計	Microsoft Graph API 和 SDK
程式設計	Az PowerShell 模組

本節的其餘部分會介紹表中列出的每個技巧。 本節結尾會說明其他已遭取代且不應用於新解決方案的技巧。

Microsoft Graph 總管

Microsoft Graph 總管是開發人員工具，可讓您了解 Microsoft Graph API 的相關資訊。 這個入門方式相當簡單，因為不需要其他工具或在機器上進行設定。 您可以登入以從租用戶擷取資料，或從預設租用戶擷取範例資料。

您可以使用 Graph 總管來執行以下動作：

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

使用此連結開啟 Graph 總管。

Microsoft Graph API 和 SDK

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

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

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

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

您可以從 PowerShell 資源庫安裝 Microsoft Graph PowerShell 模組。 由於 Microsoft Graph 可與許多 Microsoft 365 服務搭配運作，因此有許多您安裝的 PowerShell 模組。

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

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

Az PowerShell 模組

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

當 API 沒有對應的 Cmdlet 時，您可以使用 Invoke-AzRestMethod Cmdlet。 這個彈性的方法可讓您使用 Az PowerShell 模組，將要求傳送至任何Microsoft Graph 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 是未來的方向)。 將在 Microsoft Graph PowerShell SDK 中進行所有未來的 PowerShell 投資。
• MS Online (MSOL) PowerShell 模組：已遭取代且即將淘汰。 將在 Microsoft Graph PowerShell SDK 中進行所有未來的 PowerShell 投資。

檢查清單：規劃以存取使用者和群組資料時，關鍵決策和行動包括以下幾項：

從 Power BI REST API 存取資料

或許作為優先順序較低的事項，您也可以使用 Power BI REST API 來擷取其他資料。

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

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

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

• 已廣泛與整個組織共用的項目。
• 使用「發佈至 Web」，在公用網際網路上提供的項目。

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

檢查清單：規劃從 Power BI API 存取資料時，關鍵決策和行動包括以下幾項：

階段 2：必要條件和設定

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

建立儲存體帳戶

此時，您已決定未經處理資料的儲存位置，以及如何建立經過策劃的資料。 根據這些決策，您現在已做好準備，可建立儲存體帳戶。 視組織的程序而定，其中可能涉及將要求提交給 IT 人員。

如先前所述，我們建議使用可讓您將未經處理資料寫入不可變儲存體的技術。 寫入資料之後，就無法將其變更或刪除。 接著，您就可以放心處理未經處理資料，因為您知道具有存取權的管理員無法以任何方式改變這些資料。 不過，經過策劃的資料 (通常) 不需要儲存在不可變儲存體中。 經過策劃的資料可能會變更或可能重新產生。

檢查清單：建立儲存體帳戶時，關鍵決策和行動包括以下幾項：

安裝軟體和設定服務

此時，您已決定要使用哪個技術來存取稽核資料。 根據那些決策，您現在已做好準備，可安裝軟體和設定服務。

為每名管理員設定慣用的開發環境。 此開發環境可讓他們撰寫及測試指令碼。 Visual Studio Code 是開發指令碼的新型工具，因此是不錯的選擇。 此外，許多擴充功能都可以與 Visual Studio Code 搭配使用。

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

• 每名管理員/開發人員的機器，這些管理員/開發人員會將撰寫或測試稽核指令碼。
• 將執行排程指令碼的每部虛擬機器或伺服器。
• 每個線上服務 (例如 Azure Functions 或 Azure 自動化)。

如果您選擇使用任何 Azure 服務 (例如 Azure Functions、Azure 自動化、Azure Data Factory 或 Azure Synapse Analytics)，您也應該加以佈建和設定。

檢查清單：安裝軟體和設定服務時，關鍵決策和行動包括以下幾項：

註冊 Microsoft Entra 應用程式

此時，您已決定如何進行驗證。 建議您註冊 Microsoft Entra 應用程式 (服務主體)。 其通常稱為應用程式註冊，應用於您將自動化的無人參與作業。

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

檢查清單：註冊 Microsoft Entra 應用程式時，關鍵決策和行動包括以下幾項：

設定 Power BI 租用戶設定

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

管理員 API

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

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

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

「使用 DAX 和混搭運算式增強管理員 API 回應」租用戶設定可讓您設定哪些使用者和服務主體可以擷取詳細的中繼資料。 中繼資料是從中繼資料掃描 API 擷取而得，其中可能包含查詢和語意模型量值運算式。

使用者 API

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

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

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

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

檢查清單：進行 Power BI 租用戶設定時，關鍵決策和行動包括以下幾項：

階段 3：解決方案制定和分析

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

擷取和儲存未經處理資料

此時，您應清楚了解自己的需求和優先事項。 已制定重要技術決策，這些決策與如何存取稽核資料和稽核資料的儲存位置有關。 已選取慣用的工具，並已設定必要條件和進行設定。 在前兩個階段中，您可能已完成一或多個小型專案 (概念證明)，以證明可行性。 下一步是設定程序，以擷取和儲存未經處理的稽核資料。

如同大部分 Microsoft API 所傳回的資料，稽核資料會格式化為 JSON。 JSON 格式化的資料一看就懂，因為其是包含結構和資料的人類可閱讀文字。

JSON 代表由屬性值組和陣列所組成的資料物件。 例如，"state": "Active" 是狀態屬性值為 Active 的範例。 JSON 陣列包含以逗號分隔並以方括弧 ([ ]) 括住的元素排序清單。 在 JSON 結果中尋找巢狀陣列很常見。 一旦您熟悉 JSON 結果的階層式結構，即可輕鬆理解資料結構，例如工作區中的語意模型清單 (陣列)。

以下是擷取和儲存從 API 擷取之未經處理資料的一些考量。

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

檢查清單：擷取和儲存未經處理資料時，關鍵決策和行動包括以下幾項：

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

建立經過策劃的資料

此時，會擷取並儲存未經處理資料。 下一步是為經過策劃的資料建立個別的金級資料圖層。 其目標是轉換資料檔，並將其儲存在星狀結構描述中。 星狀結構描述包含維度資料表和事實資料表，而且針對分析和報告特地進行最佳化。 經過策劃的資料圖層中的檔案會成為 Power BI 資料模型的來源 (下一個主題所述)。

檢查清單：建立經過策劃的資料圖層時，關鍵決策和行動包括以下幾項：

建立資料模型

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

在稽核和監視的內容中，資料模型源自於經過策劃的 (金級) 資料圖層中的資料。 如果您選擇不建立經過策劃的資料圖層，則資料模型會直接從未經處理資料取得資料。

我們建議 Power BI 資料模型實作星狀結構描述設計。 當資料來源是經過策劃的資料圖層時，Power BI 資料模型星狀結構描述應會鏡像經過策劃的資料圖層星狀結構描述。

如同任何 Power BI 專案，建立資料模型是不斷反覆的程序。 您可以視需要新增量值。 您也可以在新的稽核事件可供使用新增資料表和資料行。 您甚至可以在未來整合新的資料來源。

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

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

以下是您可以在資料模型中包含的一些實用事實資料表 (主題)。

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

事實資料表不應包含報告建立者將篩選的資料行。 相反地，這些資料行皆屬於相關的維度資料表。 此設計不僅提高查詢效率，而且會藉由多個事實 (稱為鑽研)，提升維度資料表的重複使用。 最後一點對於產生實用且方便使用的資料模型很重要，該模型在您新增事實資料表 (主題) 時是可延伸的。

例如，使用者維度資料表會與每個事實資料表有關。 其應該與使用者活動事實資料表 (執行該活動的人員)、租用戶清查事實資料表 (建立已發佈項目的人員) 和其他所有事實資料表有關。 當報告根據在使用者維度資料表中的使用者篩選時，該報告中的視覺效果可以從任何相關事實資料表顯示該使用者的事實。

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

建議您建立與報告不同的資料模型。 取消語意模型及其報告的結合後，集中化語意模型就能夠為許多報告提供服務。 如需使用共用語意模型的詳細資訊，請參閱受控自助 BI 使用案例。

請考慮設定列層級安全性 (RLS)，讓卓越中心、稽核人員和管理員以外的其他使用者都能夠分析和報告稽核資料。 例如，您可以使用 RLS 規則，允許內容建立者和取用者報告自己的使用者活動或開發工作。

檢查清單：建立資料模型時，關鍵決策和行動包括以下幾項：

增強資料模型

若要有效地分析內容使用方式和使用者活動，建議您擴充資料模型。 隨著您探索商機和新需求時，就可以逐漸反覆地完成資料模型增強。

建立分類

增強模型以及提高資料價值的其中一種方法，就是將分類新增至資料模型。 請確定報告會一致地使用這些分類。

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

使用者使用方式分類

請考慮將下列分類用於使用者使用方式。

• 常見使用者：過去一週記錄的活動，以及過去 12 個月中九個月的記錄。
• 活躍使用者：過去一個月記錄的活動。
• 非經常性使用者：過去九個月記錄的活動，但在過去一個月內沒有活動。
• 閒置中使用者：過去九個月沒有記錄的活動。

內容使用方式分類

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

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

使用者類型分類

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

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

考量新近程度與趨勢

您應該決定使用者或內容的使用方式分類，是否應以活動的發生時間有多近為基礎。 您可能也想要考慮將一段時間的平均使用量或使用量趨勢納入考量。

請考量一些範例，其中示範簡單分類邏輯可能如何扭曲現實。

• 有位經理本週檢視了一份報告。 然而，在那週之前，該經理在過去六個月內未曾檢視任何報告。 僅根據最近的使用方式，您不應該將此經理視為常見的使用者。
• 報告建立者每週都會發佈新的報告。 當您分析常見使用者的使用方式時，報告建立者的定期活動似乎是積極的。 不過，在進一步調查時，您發現每次編輯報告時，這名使用者都會重新發佈新報告 (使用新的報告名稱)。 報告建立者若能接受更多訓練會很有幫助。
• 主管會偶爾檢視報告，因此其使用方式分類會經常變更。 您可能需要以不同的方式分析特定類型的使用者，例如主管。
• 內部稽核人員每年會檢視一次重要報告。 因為不常使用，可能會將內部稽核人員視為閒置中使用者。 人員可能會採取步驟來移除其 Pro 或 PPU 授權。 或者，因為不常使用，人員可能認為應將報告淘汰。

檢查清單：建立分類使用方式資料時，關鍵決策和行動包括以下幾項：

建立分析報告

此時稽核資料的擷取和儲存都已完成，而且您已發佈資料模型。 下一步是建立分析報告。

專注於對每個對象最相關的重要資訊。 稽核報告可能有數個對象。 每個對象會對不同的資訊感興趣，目的也有所不同。 您可以透過報告提供服務的對象包括：

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

以下是一些最常見的分析需求，建議您在建立稽核報告時從這些需求開始著手。

• 熱門內容檢視：執行發起人和領導團隊可能會隨著時間主要對摘要資訊和趨勢感興趣。 工作區管理員、開發人員和內容建立者對細節更感興趣。
• 熱門使用者活動：卓越中心將對誰使用 Power BI、其使用方式和時間感興趣。 Premium 容量管理員感興趣的是，誰會使用該容量來確保其健康情況和穩定性。
• 租用戶清查：Power BI 管理員、工作區管理員和稽核人員會對於了解何種內容存在、位置、譜系及其安全性設定感興趣。

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

檢查清單：規劃分析稽核報告時，關鍵決策和行動包括以下幾項：

根據資料採取行動

稽核資料很重要，因為其可協助您了解 Power BI 租用戶中發生的情況。 雖然看起來顯而易見，但若要根據從稽核資料中學到的經驗明確地採取行動，卻很容易就遭到忽略。 基於這個理由，我們建議您指派負責追蹤可衡量改善 (而不只是檢閱稽核報告) 的人員。 如此一來，您就可以在 Power BI 的採用和成熟程度取得漸進、可衡量的進步。

您可以根據目標以及從稽核資料中學到的經驗，採取許多不同的行動。 本節的其餘部分提供幾個想法。

內容使用方式

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

• 頻繁使用的內容 (每日或每週)：確認任何重要內容都經過確認。 確認擁有權清楚明瞭，且解決方案獲得充分的支援。
• 大量工作區檢視：發生大量工作區檢視時，請調查 Power BI 應用程式未使用的原因。
• 極少使用的內容：請連絡目標使用者，以判斷該解決方案是否符合其需求，或其需求是否已變更。
• 重新整理活動比檢視更頻繁發生：請連絡內容擁有者，以了解在近期沒有使用語意模型或相關報告的情況下，為何語意模型會定期重新整理。

使用者活動

以下是您可能根據使用者活動採取的一些行動。

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

使用者訓練機會

以下是您可以從稽核資料識別的一些使用者訓練機會。

• 相同內容建立者發佈的大量語意模型：教導使用者與共用語意模型相關的資訊，以及為何避免建立重複語意模型很重要的原因。
• 從個人工作區過度共用：請連絡透過個人工作區進行大量共用的使用者。 向其教導與標準工作區有關的資訊。
• 來自個人工作區的重要報告檢視：連絡使用者，其擁有的內容擁有大量的報告檢視。 教導他們標準工作區較個人工作區更好的原因。

安全性

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

• 指派給具有較高權限 Fabric 管理員角色的使用者過多。
• 工作區管理員過多 (當成員、參與者或檢視人員工作區角色已足夠時)。
• 指派給語意模型的建置權限過多 (當讀取權限已足夠時)。
• 當 Power BI 應用程式權限或工作區檢視人員角色對內容取用者而言是更佳的選擇，大量使用的依項目權限。
• 內容如何與外部使用者共用。

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

治理和風險降低

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

• 大量檢視未獲認可之報告 (和基礎語意模型)。
• 大量使用未知或未經批准的資料來源。
• 檔案位置與來源檔案位置的治理指導方針不一致。
• 工作區名稱不符合治理需求。
• 敏感度標籤會用於資訊保護。
• 一致的資料重新整理發生失敗。
• 大量和週期性使用列印。
• 非預期或過度使用訂用帳戶。
• 非預期的個人閘道使用。

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

檢查清單：根據稽核資料規劃可能的行動時，關鍵決策和行動包括以下幾項：

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

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

運作和改善

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

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

• 安全：會安全地儲存和管理認證。 指令碼中不包含純文字的密碼或金鑰。
• 排程：可靠的排程系統已就緒。
• 變更管理：使用變更管理實務和多個環境，以確保生產環境得到完善的保護。 您也可以使用開發和測試環境，或僅僅使用開發環境。
• 支援：已明確定義為解決方案提供支援的團隊。 小組成員已經過訓練，了解運作期望。 已識別後備成員，並適時進行交叉訓練。
• 警示：發生錯誤時，警示會自動通知支援小組。 警示最好同時包含記錄和電子郵件 (而非僅包含電子郵件)。 記錄對於分析記錄的錯誤和警告很有用。
• 記錄：系統會記錄程序，因此存在稽核資料更新時間的歷程記錄。 記錄的資訊應該記錄開始時間、結束時間，以及執行程序之使用者或應用程式的身分識別。
• 錯誤處理：指令碼和程序會正常處理和記錄錯誤 (例如是否要立即結束、繼續或等候，然後再試一次)。 發生錯誤時，會將警示通知傳送給支援小組。
• 編碼標準：使用效果良好的編碼技術。 例如，除非有必要，否則應刻意避免迴圈。 使用一致的編碼標準、註解、格式化和語法，簡化解決方案的維護和支援。
• 重複使用和模組化：若要盡可能減少重複項目，會將程式碼和設定值 (例如通知的連接字串或電子郵件地址) 模組化，讓其他指令碼和程序都可以重複使用這些項目。

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

文件和支援

對於任何生產層級解決方案而言，文件和支援都很重要。 根據目標對象和用途，建立數種文件是有助益的。

技術文件

技術文件的目標讀者是建置解決方案的技術小組，這類人員會隨著時間逐漸改善和擴充解決方案。 這對於支援小組也是實用的資源。

技術文件應包含：

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

支援文件

視稽核解決方案的關鍵程度而定，如果發生緊急問題，您可能需要向技術支援中心或支援小組尋求協助。 技術支援中心或支援小組全天候都能提供協助。

支援文件有時稱為知識庫或 Runbook。 本文件的目標讀者是技術支援中心或支援小組，內容應該包含：

• 發生問題時的疑難排解指導。 例如，當發生資料重新整理失敗時。
• 要持續採取的行動。 例如，在問題解決前，可能會有一些人員需要定期執行的手動步驟。

內容建立者文件

您可以藉由將使用方式和採用分析提供給整個組織的其他團隊，發揮稽核解決方案中的更多價值 (必要時強制執行列層級安全性)。

內容建立者文件的目標讀者是自助內容建立者，這類建立者會建立源自經過策劃稽核資料的報告和資料模型。 其中包含資料模型的相關資訊，包括常見的資料定義。

檢查清單：為稽核解決方案的文件和支援做規劃時，關鍵決策和行動包括以下幾項：

啟用警示

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

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

持續管理

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

• 此組織會探索新的資料需求。
• 新的稽核事件會出現在您從 Power BI REST API 擷取的未經處理資料中。
• Microsoft 會對 Power BI REST API 進行變更。
• 員工會找出此解決方案的改善方法。

檢查清單：為持續管理稽核解決方案做規劃時，關鍵決策和行動包括以下幾項：

相關內容

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