共用方式為

Power BI 實作規劃：租用戶管理

  • 發行項

注意

本文是 Power BI 實作規劃系列文章的其中一篇。 此系列主要著重於 Microsoft Fabric 中的 Power BI 體驗。 如需有關此系列的簡介，請參閱 Power BI 實作規劃。

本文介紹管理 Fabric 租用戶的重要考量。 本文的目標讀者為：

  • Fabric 管理員：負責監督組織中 Fabric 的管理員。
  • IT 和系統管理員：與 Fabric 管理員共同監督和整合組織內之系統的其他管理員。
  • 卓越中心 (COE) 和 BI 團隊：這類團隊負責監督組織中的 Power BI 並支援組織中的 Power BI 使用者。 這些團隊會做出重要決策，並與 Fabric 管理員共同作業。

管理 Power BI 服務是系統監督的重要層面之一。 如需詳細資訊，請參閱系統監督。 與系統監督相關聯的例行活動，通常稱為系統管理。 要確保內容取用者和內容建立者持續擁有良好的 Power BI 體驗，系統管理活動至關重要。

如 Fabric 採用成熟度層級一文所述，組織採用是指為了支援及啟用企業 BI 和受控自助 BI 而施行控管與資料管理做法的有效性。 因此，管理分析和 BI 平台的管理員對於分析採用工作的成敗可能會有可觀且直接的影響。

注意

管理 Fabric 容量 (或 Premium 容量) 與管理 Power BI 服務是不同的概念。 雖然大部分的組織只有一個 Power BI 租用戶，但組織可以為不同的工作負載或業務單位佈建多個容量。

重要

此文章有時會提及 Power BI Premium 或其容量訂用帳戶 (P SKU)。 請注意，Microsoft 目前正在整合購買選項，並按容量 SKU 淘汰 Power BI Premium。 新客戶和現有客戶應考慮改為購買 Fabric 容量訂用帳戶 (F SKU)。

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

定義責任範圍

Fabric 管理員角色沒有單一定義，意即 Fabric 管理員的角色和例行責任可能隨著組織而有所不同。 不變的是，角色可以 (且應) 隨著組織優先順序和目標的變化而與時俱進。

從策略觀點來看，Fabric 管理員應專注於：

  • 控管：制定控管指導方針和原則，以支援企業 BI 和受控自助 BI。
  • 使用者賦能：輔助和支援盡可能為內部使用者社群賦能的內部程序與系統，同時遵守組織的法規和需求。
  • 採用：允許以有效的控管和資料管理做法，更廣泛而有組織地採用 Fabric。

試圖在控管、使用者賦能與採用目標間取得平衡，必然會導致優先順序的競爭。 理想情況下，這會引發具建設性的優先順序相關辯論。 釐清並傳達您對各種角色和責任的期望，有助於避免出現不可接受的摩擦和衝突。

請考量以下三個 Fabric 管理員範例。

  • 高度關注使用者能力培養：Riley 是一名任職於大型全球性組織的 Fabric 管理員，該組織在受控自助 BI 方面進行了大量投資。 為了對整個組織的使用者啟用自助 BI 功能，Riley 投注了大量時間與卓越中心 (COE) 和其他管理員協調決策和動作。 必要時，Riley 也會涉入支援現有的 BI 解決方案。
  • 高度關注控管和合規性：Parker 是在一家受到嚴格監管的組織工作的 Fabric 管理員。 在此組織中，大部分的 BI 開發是由集中式企業 BI 小組內的 BI 開發人員負責處理。 Parker 的職責主要著重於稽核、資訊保護和安全性等領域。
  • 高度參與內容建立：Morgan 是一名 Fabric 管理員，任職於一家剛開始建立其資料文化的小型組織。 目前，組織只有幾名內容建立者。 除了肩負系統監督職責，Morgan 也是 BI 開發人員，會定期建立和發佈內容。 有時，Morgan 會參與共同開發專案為同事提供指導，這有助於拓展組織的 BI 專業知識。

檢查清單 - 規劃責任範圍時的重要決策和動作包括：

  • 確立策略重點：確認 Fabric 管理員的策略重點為何。 釐清需要做出決策 (和取捨) 時應有的目標與優先順序。
  • 識別特定角色和責任：確認對於 Fabric 管理員的具體期望。 請明確記錄其角色和責任，並適時透過人力資源部門更新工作描述。

指定管理員

Fabric 管理員的動作會對使用者體驗、資料文化工作、控管工作、擁有和管理內容的人員以及組織採用工作產生重大影響。 因此，請務必指定適當的人員擔任管理員角色。

以下是選取管理員時應考量的一些重點。

  • 別忘了這是個權限很高的角色。 管理員角色屬於高權限角色，因其有權管理多種不同的租用戶設定、工作區存取、個人工作區存取，且可以檢視所有租用戶中繼資料。 如需詳細資訊，請參閱 Power BI 管理。
  • 慎選適合擔任管理員的人員。 管理員常需與使用者和 COE 共同作業。 因此，他們應了解商業智慧概念，以及使用者想要達成的目標。 個性太強勢或傾向於嚴格限制使用者能做些什麼的人，可能不適合管理自助 BI 平台。
  • 選擇 2 到 4 名管理員。 因為是高權限角色，請指定幾名管理員即可。 請取得適當平衡：設置太多管理員會增加未經核准即進行變更的風險，但管理員太少則會增加系統無法獲得充分支援的風險。
  • 允許設置暫時性的管理員。 如果您有偶爾需要 Fabric 管理員權限的使用者，請考慮實作 Privileged Identity Management (PIM)。 PIM 可讓您指派會在幾個小時後到期的 Just-In-Time 角色權限。 此程序可讓您有效平衡風險 (設置過多全職管理員) 與可用性 (能夠取得進展)。 在較大的分散式組織中，尤其如此。 使用 PIM 時，會記錄管理員角色的委派，並且可以選擇用核准工作流程來授與權限。
  • 使 Fabric 管理成為優先事項。 管理 BI 平台往往只是眾多職責之一。 請考量如何確保使用者能獲得妥善的支援，並且充分管理系統。
  • 定期檢閱所有獲派相關角色的人員。 有兩個角色可以管理 Power BI 服務：Fabric 管理員和 Power Platform 管理員。 請務必定期稽核這些角色的成員資格。

如需詳細資訊，請參閱關於 Microsoft 365 系統管理中心中的管理員角色。

檢查清單 – 指定管理員時的重要決策和動作包括：

  • 識別目前的 Fabric 管理員：檢閱目前獲派 Fabric 管理員角色的人員。 在此檢閱中，也請考量 Power Platform 管理員和全域管理員角色。
  • 指定 Fabric 管理員：若要降低風險，請指定 2 到 4 人擔任 Fabric 管理員角色。 如果目前已指派超過四人，請減少指派給 Fabric 管理員角色的人數。
  • 對暫時性管理員使用 PIM：識別是否有合法、但偶爾需要 Fabric 管理員權限的人員。 請實作 PIM，以指派會在幾個小時後到期的 Just-In-Time 角色權限。 記錄並傳達程序的運作方式，其中可能包含核准工作流程。
  • 指派職務代理人並進行交叉訓練：檢查交叉訓練的狀態，並確認已有處理 Fabric 管理職責的文件。 請確實訓練職務代理人，以便能及時且一致地因應優先使用者的需求。
  • 定期稽核管理員：定期確認指派給 Fabric 管理員角色的人員。

與其他管理員共同作業

雖然 Fabric 管理員是高權限角色，但僅限於管理 Fabric。 因此，有時您必須與其他管理員共同作業。

以下是 Fabric 管理員與其他系統管理員共同作業的一些常見原因。

  • 裝置設定和安裝：您可能需要與 IT 人員、基礎結構小組或桌面支援小組合作，才能安裝、更新或管理使用者裝置。
  • 訂用帳戶和授權購買：需要 Microsoft 365 中的計費管理員角色，才能管理訂用帳戶和購買授權。 計費管理員也可能負責成本分析和管理。 若要深入了解集中式和分散式 (自助) 的授權管理，請參閱使用者授權。
  • 授權指派和使用者管理：Microsoft 365 中的授權管理員角色必須指派授權 (已購買的) 給特定使用者。 需要使用者管理員角色，才能管理使用者的屬性。 當您打算根據使用者屬性實作自動化 (例如，自動授權指派或自動群組指派) 時，與使用者管理員合作會很有幫助。 如需詳細資訊，請參閱常用的 Microsoft 365 系統管理中心角色。
  • Microsoft Entra 系統管理員：您需要與 Microsoft Entra 系統管理員合作的原因有很多。 原因通常包括需要設定或管理使用者、群組和服務主體。 如需詳細資訊，請參閱租用戶層級安全性規劃。
  • 來源資料存取：您可能需要與系統管理員或資料庫管理員合作，才能代表內容建立者存取資料。 有時候，當語意模型 根據內容取用者的身分識別 強制執行數據安全性時，可能也需要代表內容取用者要求存取權。
  • 資料外洩防護和資料分類：您可能需要與 Microsoft Purview 管理員共同作業，以進行控管和資訊保護。
  • Teams 整合：將 Power BI 與 Microsoft Teams 整合時，您可能需要與 Teams 管理員共同作業。
  • OneDrive 與 SharePoint 整合：在整合 Power BI 與 OneDrive 或 SharePoint 時，您可能需要與其他管理員共同作業。
  • 工作區管理：您可能需要與 Fabric 工作區管理員共同作業，以規劃、組織或保護特定工作區內的內容。
  • 生命週期管理：部署和管理內容變更時，您可能需要與部署管線管理員或 Azure DevOps 管理員共同作業。
  • Premium 容量管理：管理 Premium 容量時，您可能需要與容量管理員共同作業。
  • 資料閘道管理：您可能需要與閘道管理員共同作業，才能管理及保護內部部署資料閘道。 如需詳細資訊，請參閱管理閘道。
  • Power Platform 管理：您可能需要在 Power BI 與其他 Power Platform 應用程式 (例如 Power Automate 或 Power Apps) 之間整合解決方案。
  • Azure 管理：您可能需要與 Azure 管理員合作，以設定、存取及保護要與 Power BI 整合的其他 Azure 服務。
  • 安全性管理和稽核：您的組織可能會有特定的合規性、安全性或隱私權需求。 在此情況下，您可能需要與安全性小組共同作業，以識別並降低風險。
  • 網路：連線至不同的資料來源和系統時，您可能需要與網路管理員合作以維護效能和安全性。
  • 行動裝置管理：您可能需要與 Intune 管理員共同作業，才能管理行動裝置的原則和安全性。

重要

Fabric 管理員不應自行做出決策或執行動作 (例如變更租用戶設定)。 所有重要決策都應經過討論、規劃並記載於文件。 除了與其他管理員共同作業外，請務必讓 COE 和 BI 策略工作小組充分參與。 此外可能也應讓執行發起人參與策略性決策。

檢查清單 – 與其他管理員共同作業時的重要決策和動作包括：

  • 確認裝置設定和安裝將由誰管理：請確定您知道組織的裝置由誰管理。 請熟悉其程序和需求。 做好必要時與他們合作的準備。
  • 識別誰將管理訂用帳戶和授權：請確定您知道組織的訂用帳戶和授權由誰管理。 請熟悉其程序和需求。 做好必要時與他們合作的準備。
  • 識別誰將指派授權及管理使用者、群組和服務主體：請確定您知道組織的使用者、群組和服務主體由誰管理。 請熟悉其程序和需求。 做好必要時與他們合作的準備。
  • 確認任何其他要諮詢的管理員：當您完成實作規劃程序時，請識別其他相關管理員。 邀請他們參加相關的會議，並參與相關的決策程序。 視需要更新文件和程序。

控管 Power BI 服務

控管及管理 Power BI 服務，是 Fabric 管理員的重要職責之一。 本節說明如何在 Fabric 管理入口網站中控管及管理許多常見的設定和功能。

控管租用戶設定

租用戶設定是控制有哪些 Power BI 功能已啟用，以及要提供給組織中的哪些使用者使用的重要途徑。 管理租用戶設定是 Fabric 管理員最重要的職責之一。

由於內容建立者和內容取用者可輕易了解 Power BI 中可用的特性和功能 (透過文件)，因此當他們無法執行預期的作業時，可能會感到挫折。 此外也可能導致使用者不滿，以及組織採用、使用者採用和解決方案採用的效率不佳。

以下是讓使用者感到困惑和沮喪的一些常見問題。

  • 為何我無法建立工作區？
  • 為何我無法匯出資料？
  • 為何我的自訂視覺效果無法運作？
  • 為何我無法認證語意模型？
  • 為何我無法指派敏感度標籤？
  • 為何我無法將應用程式推送給特定使用者？

重要

每個租用戶設定都應符合您組織中的控管指導方針和原則。 當 Fabric 管理員自行決定啟用或停用設定時，這通常是您需要改善和精簡控管程序的明確指標。

本節的其餘部分說明下列用來管理租用戶設定的程序。

  1. 檢閱租用戶設定
  2. 決定租用戶設定
  3. 更新租用戶設定
  4. 記錄租用戶設定
  5. 管理租用戶設定
  6. 稽核租用戶設定

步驟 1：檢閱租用戶設定

請務必檢閱每項租用戶設定，以清楚了解您的租用戶目前的狀態。 雖然您應檢閱所有租用戶設定，但您可以排定要根據風險評估優先檢閱的特定重要設定。

以下是檢閱的過程中應考量的一些因素。

  • 設定：特定租用戶設定目前是啟用還是停用？
  • 權限：特定租用戶設定是否適用於整個組織？ 或者，是適用於特定安全性群組，還是遭到拒絕？

注意

有些租用戶設定預設為啟用，有些則預設為停用。

您可以用下列兩種方式之一來編譯租用戶設定的目前狀態。

下表說明如何記錄租用戶設定的目前狀態。

上次檢閱日期 租用戶設定 目前的值 允許的安全性群組 不允許安全性群組 委派給其他管理員的租用戶設定
2023 年 10 月 15 日 建立工作區 為特定安全性群組啟用 Power BI 工作區建立者、Power BI 管理員、Power BI COE、Power BI 支援 N/A N/A
2023 年 10 月 15 日 匯出至 Excel 為整個組織啟用，但特定安全性群組除外 N/A 銷售小組 - 歐洲 N/A
2023 年 11 月 1 日 跨工作區使用語意模型 允許整個組織使用 N/A N/A N/A
2023 年 11 月 1 日 認證 為特定安全性群組啟用 Power BI 認證 SME N/A 定義域管理員可以啟用/停用
2023 年 11 月 5 日 允許特定使用者啟用外部資料共用 為特定安全性群組啟用 Power BI 外部資料共用 N/A N/A

如需安全性群組的其他考量，請參閱規劃 Power BI 群組。

若要深入了解允許的租用戶設定狀態，請參閱如何使用租用戶設定。

警告

有時，管理員在監視租用戶時會發現不理想的情況。 例如，他們可能會在使用者活動資料中看到太多資料匯出。 在此實例中，管理員可能想要停用相關的租用戶設定。 不過，在完全停用功能之前，請務必先了解使用者依賴特定技術的原因。 這是因為禁止功能可能會引發使用者沮喪，進而誘使使用者建立因應措施。 您應考量解決方案是否需要重新設計，或進一步教育和訓練使用者是否可減輕疑慮。

步驟 2：決定租用戶設定

檢閱目前的租用戶設定後，接著應檢查決策程序。 對於每項租用戶設定，請舉辦研討會主動討論並確認應允許或不允許哪些特性和功能，以及要對哪些使用者施行。

請記住，每個租用戶設定分別代表一個控管決策。 因此，必須與其他人共同作業，才能做出正確的決定。 根據您所處的情況，決策程序可能涉及與 COE、執行發起人、安全性小組、BI 小組或其他人員 (例如專案關係人或擁護者) 共同作業。

提示

其中一個最大的挑戰，是在現有租用戶設定與目標和制定的決策之間出現不一致的情況時，決定該怎麼做。 請做好準備，在遇到這些衝突時加以解決。

以下是決策的過程中應考量的一些因素。

  • 哪些控管決策已存在？ 可能的話，請參閱您所做的現有決策。 力求一致且有效率。 此外，您必須注意內部或外部合規性需求。 如果適用，租用戶設定應與更廣泛的控管原則保持一致。 例如，目前可能有一個控管原則會指定在組織外部共用資料的時機、人員及方式。
  • 誰做出新的控管決策？ 需要做出租用戶設定的相關決策時，請讓所有利害關係人參與交談。 通常，單憑 Fabric 管理員是無法做出租用戶設定相關決策的。 如需組建工作小組和舉辦研討會的相關資訊，請參閱 BI 策略性規劃。
  • 決定是暫時的嗎？ 有時，租用戶設定只會短期設定。 此舉通常是為了讓 COE、BI 和 IT 小組在新功能更廣泛地發行至整個組織之前，能有時間先加以熟悉。 如此，您即可確認是否符合控管指導方針，且使用者社群會受到良好支援。
  • 不同的業務單位或小組是否會以不同的方式處理？ 在較大的組織中，很難單憑一種方法運作。 為了因應不同小組的需求和技能，有時您可能需要為不同的對象設定不同的租用戶設定。 力求讓有能力的團隊盡可能在控管指導方針內靈活地運作。
  • 是否有核准程序？ 視具體主題而定，可能需要核准。 當租用戶設定與安全性或合規性有關時，尤其如此。
  • 重新檢閱每個決策的排程為何？ 定期排程每個租用戶設定決策的檢閱。 就此目的而言，一年兩次是適當的排程。

下表說明您可以如何記錄決策。

決策日期 決策內容 參與的決策者 決策核准者 受影響的租用戶設定 擱置動作
2023 年 10 月 15 日 COE 會就建立及管理工作區的最佳做法，對核准的內容建立者進行訓練。 核准的建立者可來自任何業務單位。 COE 和專案關係人 Ellis Turner (執行發起人) 和 Taylor Phillips (COE 負責人) 建立工作區 檢閱 Power BI 工作區建立者群組的現有成員
2023 年 10 月 15 日 將允許匯出至 Excel。 COE 會追蹤活動記錄中的動作，並連絡過度使用該動作的使用者。 「銷售小組 - 歐洲」因目前正在調查的問題而受到暫時性的限制。 COE 和安全性 Ellis Turner (執行發起人) 和 Jessie Irwin (技術長) 匯出至 Excel 60 天內追蹤歐洲問題
2023 年 11 月 1 日 我們強烈建議使用共用語意模型來促進資料重複使用、盡可能避免資料孤島，並減少資料重複。 COE Ellis Turner (執行發起人) 跨工作區使用語意模型 N/A
2023 年 11 月 1 日 COE 會就認證報表和資料資產的程序與需求，對核准的內容建立者進行訓練。 核准的建立者可來自任何業務單位。 COE 和專案關係人 Ellis Turner (執行發起人) 和 Taylor Phillips (COE 負責人) 認證 檢閱 Power BI 認證 SME 群組的現有成員
2023 年 11 月 5 日 組織的資料共用原則列載了如何在組織外部共用資料。 所有使用者都必須每年檢閱並認可此原則。 來自 COE 的訓練可協助使用者在使用 Power BI 時符合規範。 COE、安全性與合規性 Jessie Irwin (技術長) 允許特定使用者啟用外部資料共用 檢閱 Power BI 外部資料共用群組的現有成員

請考慮納入其他內容資訊，以說明決策的原因。 此外，也請納入現有相關文件或原則所在位置的連結。

注意

表格中顯示的範例專門用來示範如何在使用者賦能、合規性與內部需求間取得平衡。 若要了解其他考量，請參閱控管。

步驟 3：更新租用戶設定

現在，您現有的租用戶設定和制定的決策已可供使用，您可以更新租用戶設定了。

更新過程中的考量包括：

  • 誰會處理更新？ 如果您有數個 Fabric 管理員，最好是由一或兩個 Fabric 管理員主要負責更新租用戶設定。 目標是要確保程序是一致的，且受到充分了解及妥善控制。
  • 哪些測試程序已就緒？ 視租用戶設定而定，設定變更時可能會有其他影響。 在進行廣泛變更之前先行測試。 如需範例，請參閱控制跨工作區語意模型的使用。
  • 是否有變更管理程序？ 請考量如何避免決策、文件與產生的更新之間出現差異。 小組之間的溝通是變更管理成功與否的關鍵因素。 根據您的稽核需求，您可以選擇維護內部變更記錄檔，以追蹤誰做了哪些變更，及其時間和原因 (在活動記錄中擷取的內容以外記錄更多詳細資料)。
  • 如何處理與使用者的溝通？ 若進行的變更會影響到使用者所能執行的作業，請務必傳達該變更。 力求避免引發使用者不悅，和不必要的支援要求。

步驟 4：記錄租用戶設定

此時，請確定您已有可重複的方法可記錄租用戶設定值。 如需簡化的範例，請參閱上述步驟 1 中有關於檢閱租用戶設定的表格。

文件需要考量的一些層面如下。

  • 擷取快照集資料：記錄租用戶設定值時，建議您定期建立新的時間點快照集。 為此，每週建立一次快照集是適當的頻率。 使用取得租用戶設定 REST API 將程序自動化。
  • 提供對快照集資料的管理員存取：管理員、COE 和內部稽核員應具有所有快照集資料的存取權。 若要識別任何已變更的租用戶設定，請比較兩個快照集 (例如，本週與上週比較)。 活動記錄中的資料可補充快照集資料，讓您充分了解變更的內容、時間與變更者。 如需詳細資訊，請參閱下方關於稽核租用戶設定的步驟 6。
  • 為使用者提供目前設定的摘要：租用戶設定值是一種文件類型，可在集中式入口網站中提供給您的使用者社群使用。 例如，對於無法了解功能為何無法使用的使用者而言，這是一項有用的參考。 如果使用者想要使用某項功能，文件也可協助使用者得知應要求加入哪個安全性群組。 為了減少手動工作量，REST API 的最新快照集結果可作為 Power BI 報表發佈給使用者。 視您的需求而定，您可能需要合併資料的快照集與手動維護的其他資料 (例如，租用戶設定的描述、設定的理由、其他資訊的連結，或要求存取的表單連結)。

注意

如先前的步驟 2 所述，您也會有與決策程序相關的文件。 一般而言，該類型的文件僅適用於 COE 和管理員 (而不是所有 Power BI 使用者)。 如需簡化的範例，請參閱步驟 2。

步驟 5：管理租用戶設定

租用戶設定需要持續關注。 以下是需要考量的一些層面。

  • 新的租用戶設定：有新的可用租用戶設定時，您如何得知？ 由於 Fabric 是持續演進的雲端服務，因此新的租用戶設定可望定期導入。 了解新租用戶設定的其中一種方式，是檢視管理入口網站中的租用戶設定頁面頂端公告的訊息。 另一種方式是比較您從目前的快照集擷取的資料與先前的快照集 (如步驟 4 所述)。
  • 現有租用戶設定的變更：您如何得知現有租用戶設定的行為有所變更？ 租用戶設定變更通常會公告在 Power BI 部落格或 Fabric 部落格中。 請務必依照這些部落格的指示了解任何通知。
  • 當前的使用者要求：您要如何管理使用者要求？ 例如，想要認證內容的使用者知道須提交要求，才能成為允許該作業的特定安全性群組成員。 藉由發佈租用戶設定的文件供使用者參考 (如上述步驟 4 所述)，可使其成為有效的工作流程。 您可以選擇使用表單來收集這些類型的要求。 或者，您可以透過技術支援中心來路由傳送要求。
  • 新的安全性群組：如果租用戶設定限定於特定安全性群組，是否已有適當的安全性群組存在？ 或者，是否需要建立新的安全性群組？ 必要時，您如何協調建立新的安全性群組？ 如需詳細資訊，請參閱使用群組的策略。

步驟 6：稽核租用戶設定

最後，請務必要有定期稽核租用戶設定的程序。 以下是稽核租用戶設定時應識別的一些動作。

  • 租用戶設定已變更：使用 UpdatedAdminFeatureSwitch 活動來尋找活動記錄中已變更的值。 此活動只會指出某項目已更新 (無論是啟用還是停用，或是已指派不同的安全性群組)。 若要了解變更的內容，您必須比較目前的快照集與先前的快照集 (如先前的步驟 4 所述)。
  • 導入了新的租用戶設定：在管理入口網站中尋找訊息，或比較您從目前的快照集擷取的資料與先前的快照集 (如先前的步驟 4 所述)。
  • 群組成員資格已變更：在某些情況下，知道指派了哪個安全性群組可能還不夠。 您可能需要確認安全性群組成員資格，其中可包含個人使用者和服務主體。 您可以使用 Microsoft Graph 來取得群組成員資格資料。 如需詳細資訊，請參閱使用者和群組資料。

此外，您可能想要在租用戶設定更新時接收警示通知。 您可以使用 Microsoft 365 或 Microsoft Defender for Cloud Apps 的稽核記錄警示功能，在租用戶設定有所變更時接收通知，以及使用 UpdatedAdminFeatureSwitch 稽核記錄事件了解是誰進行的變更。 如需關於啟用警示的詳細資訊，請參閱租用戶層級稽核。

檢查清單 – 規劃及管理租用戶設定時的重要決策和動作包括：

  • 檢閱所有目前的租用戶設定：檢閱所有租用戶設定以確認目前的狀態。 識別為各個設定指派的安全性群組。
  • 識別現有的原則和決策：編譯現有的控管原則或先前的決策，使其可供使用。
  • 討論和決定：排程研討會以考量並確認應允許或不允許的事項，以及要對哪些使用者施行。 請確定所有決策都符合資料文化目標、控管指導方針和內部原則。 請務必讓每個主題的所有相關決策者和專案關係人參與其中。 適當時可獲取額外的核准。
  • 建立重新檢閱決策的排程：設定排程，定期重新檢閱決策和租用戶設定 (例如每年兩次)。
  • 進行更新：根據研討會中所做的決定，更新租用戶設定。
  • 使用 API 擷取快照集資料：使用取得租用戶設定 REST API 提高程序執行效率，甚至以排程方式自動建立快照集。
  • 為使用者建立文件：為您的使用者社群建立租用戶設定的文件。 將文件發佈至您的集中式入口網站。 其中應包含使用者必須屬於才能存取特性或功能的安全性群組。
  • 建立處理使用者要求的程序：設定讓使用者要求存取特性或功能的程序。
  • 設定例行管理租用戶設定的程序：建立排程，以便盡快識別新的租用戶設定。
  • 設定稽核：建立稽核程序，以便追蹤租用戶設定變更的時間點，以及是誰進行的變更。

控管定義域

定義域在 Fabric 中用來將具有類似特性的兩個或更多工作區分組在一起。 例如，您可以建立一個定義域將所有銷售工作區分組在一起，而財務工作區則使用另一個定義域。 定義域代表單一管理界限。 使用定義域也有助於將工作區擁有權和管理責任分散於組織各處。

如需關於規劃定義域的詳細資訊，請參閱工作區定義域。

提示

本節所述的 Fabric 定義域與 Microsoft 365 中的網域是不同的概念。

步驟 1：檢閱定義域

第一個步驟是檢閱現有的定義域和租用戶環境，以便了解目前的狀態。 以下是檢閱的過程中應考量的一些因素。

  • 定義域：有哪些定義域存在 (若有的話)？ 每個定義域的名稱和描述是否均清楚指出其用途？
  • 權限：每個定義域的定義域管理員是誰？ 每個定義域的定義域參與者是誰？ 所有指派的管理員和參與者是否都符合定義域的預定用途？
  • 指派的工作區：為每個定義域指派了哪些工作區？ 所有指派的工作區是否都符合定義域的預定用途？
  • 委派的租用戶設定：為定義域管理員 (或容量管理員) 委派了哪些租用戶設定以供其覆寫預設設定？

步驟 2：決定定義域

檢閱定義域後，接著應檢查決策程序。

對於現有的工作區，請考量如何將其分組在一起以形成單一管理界限。 如需詳細資訊以及可用來組織相關工作區的方式，請參閱工作區定義域。

以下是決策的過程中應考量的一些因素。

  • 哪些控管決策已存在？ 可能的話，請參閱現有的決策。 目標是要追求一致且有效率的工作區和定義域設定。
  • 內容的擁有權和管理有多分散？ 請考量整個組織目前在內容擁有權和管理方面的具體情形。 分散式方法有分散式、同盟或資料網格架構等不同稱呼。 在分析將工作區組織到定義域中的需求時，請將該資訊納入考量。
  • 哪些定義域群組成效較佳？ 有許多方法可將工作區分組到單一管理界限中。 例如，您可以選擇按主題領域、小組、業務單位或專案來組織定義域。 請記住，一個工作區只能指派給一個定義域。 如需詳細資訊，請參閱工作區定義域。
  • 應允許誰來管理各個定義域？ 理想情況下，定義域管理員是直接擁有及管理定義域內容的使用者。 此外，定義域管理員也應熟悉主題領域的內部、區域和政府法規。 他們也應熟悉所有內部控管和安全性需求。
  • 應允許誰將工作區指派給定義域？ 定義域參與者角色包含有權將工作區指派給定義域的使用者。 定義域參與者也必須是工作區管理員，才能將工作區指派給定義域。 請考量您想要為組織中的自助使用者委派多少控制權。
  • 不同的定義域是否應以不同的方式處理？ 在較大的組織中，某些定義域可能會有不同的原則。 準備好根據不同小組的需求和技能來調整您的決策。 如需詳細資訊，請參閱覆寫租用戶層級設定。

步驟 3：更新定義域

此時，您現有的定義域設定和制定的決策已可供使用。 接下來，您即可新增、變更或移除定義域 (如有必要)。

請務必遵循現有的變更管理做法，並通知將受到任何變更影響的所有使用者。

步驟 4：記錄定義域

根據您擁有的定義域數目，您可以建立文件來擴增管理入口網站中的可用資訊。 您的文件可包括：

  • 更多內容或詳細資料，例如定義域的用途、個別定義域為何有效用等等。
  • 核准定義域的人員和時間點。
  • 定義域擁有者或管理員是誰 — 是否與管理入口網站中設定的定義域管理員不同。
  • 任何與定義域有關的其他合規性或法規需求。

步驟 5：管理定義域

您應在管理入口網站中定期檢閱定義域。 每季一次或一年兩次應該就夠了。

此外，請考量如何管理想要建立新定義域、變更現有定義域，或將工作區新增至定義域的使用者提出的要求。

步驟 6：稽核定義域

您應有定期稽核定義域及其設定的程序。 以下是使用活動記錄來稽核定義域時應識別的一些動作。

  • 已建立新的定義域：尋找 InsertDataDomainAsAdmin 活動。
  • 現有的定義域已變更：尋找 UpdateDataDomainAsAdmin 活動。
  • 工作區已指派給定義域：尋找 UpdateDataDomainFoldersRelationsAsAdmin 活動。
  • 定義域管理員或定義域參與者已變更：尋找 UpdateDataDomainAccessAsAdmin 活動。

檢查清單 - 規劃及管理定義域時的重要決策和動作包括：

  • 檢閱目前的定義域：檢閱管理入口網站中的所有定義域，以確認目前的狀態。
  • 討論並決定：確認何種定義域群組最能符合您的需求。 在考量如何管理定義域時，應讓相關決策者和專案關係人參與其中。
  • 確認是否需要核准：確認在建立新的定義域時是否應以某個程序來取得其他人的核准。
  • 建立重新檢閱的排程：設定定期重新檢閱定義域的排程。
  • 進行更新：在出現新需求時更新定義域。
  • 建立文件：如果您需要記錄其他資訊，請為您的定義域建立文件。
  • 建立處理使用者要求的程序：設定使用者要求新定義域的程序。
  • 設定稽核：建立稽核程序，以便追蹤新定義域的建立時間，或發生變更的時間點。

控管工作區

工作區是 Fabric 中的基本概念。 工作區可作為儲存和保護內容的容器。 工作區主要是為了內容建立、共同作業和內容發佈而設計的。

管理入口網站中的工作區頁面可讓 Fabric 管理員檢閱及管理租用戶中的所有工作區。

以下是 Fabric 管理員參與管理工作區的幾個可能原因。

  • 取得標準工作區的存取權。 例如，當內容的主要擁有者外出或休假時，Fabric 管理員可能需要協助處理某些狀況 (例如，資料重新整理失敗)。 在此情況下，他們必須為自己指派工作區角色。
  • 取得個人工作區的臨時存取權。 Fabric 管理員可以取得其他使用者個人工作區的存取權，但僅限 24 小時。 當工作區擁有者離開組織或休假時，對個人工作區的臨時存取權會很有幫助。
  • 管理工作區角色。 Fabric 管理員有權管理租用戶中所有工作區的工作區角色。 當工作區存取由集中式小組管理時，這會很有幫助。 當工作區處於可能因僱用終止或調職而發生的孤立狀態 (意即沒有工作區管理員) 時，這也很有幫助。
  • 重新指派工作區。 若要解除鎖定其他功能，有時需要更新工作區的授權模式。 例如，Fabric 管理員可將工作區從 Pro 或 Premium per user (PPU) 變更為容量。
  • 確認工作區的類型。 Fabric 管理員可以檢閱工作區指派到的 SKU 層。 例如，管理員可以快速確認租用戶中目前有四個指派給 PPU 的工作區。
  • 找出並/或復原已刪除的工作區。 工作區狀態可能指出工作區已刪除。 在短時間內，如果工作區遭到誤刪，Fabric 管理員可以還原該工作區。 或者，他們可以將已刪除的個人工作區還原為標準工作區。 如需詳細資訊，請參閱工作區保留。
  • 更新工作區名稱。 Fabric 管理員可以重新命名工作區，可能的原因包括其名稱不符合已建立的命名慣例。

注意

對工作區管理的參與程度，取決於指派給 Fabric 管理員的角色和責任。 您在內容擁有權和管理方面的策略，也可能影響 Fabric 管理員參與工作區管理的程度。

步驟 1：檢閱工作區

第一個步驟是檢閱現有的工作區和租用戶環境，以便了解目前的狀態。 以下是檢閱的過程中應考量的一些因素。

  • 目前的工作區：檢閱目前存在的所有工作區。 您也應檢閱每個工作區的角色指派和設定，以確保其適當性。
  • 目前的租用戶設定：檢閱建立工作區租用戶設定目前的設定。

有兩種方式可以編譯目前的工作區清單。

  • 在管理入口網站中檢視工作區清單。 清單可以匯出至 CSV 檔案。
  • 使用系統管理 API 與下列工具，以程式設計方式擷取租用戶清查：
    • 中繼資料掃描 API (也稱為掃描器 API)。 這組 API 可讓您以非同步方式找出已變更的工作區。 由於能夠以累加方式擷取已變更的工作區，因此最適用於具有大量工作區的大型組織。 如需詳細資訊，請參閱中繼資料掃描 API。
    • 以管理員身分取得群組 REST API 或 Get-PowerBIWorkspace PowerShell Cmdlet。 這些方法會傳回租用戶中所有工作區的資料，因此最適用於資料量較低的小型組織。 如需詳細資訊，請參閱群組 API 或工作區 Cmdlet。

步驟 2：決定工作區

檢閱工作區後，接著應檢查決策程序。

以下是決策的過程中應考量的一些因素。

  • 哪些控管決策已存在？ 可能的話，請參閱現有的工作區控管決策。 目標是要追求一致且有效率的工作區設定。
  • 應允許誰建立工作區？ 請考量工作區建立權限屬於資料文化和控管決策。
  • 是否應有建立工作區的特定程序？ 請務必建立方便使用者遵循的工作區建立程序。
  • 工作區應如何命名？ 確認工作區命名慣例是否有利於組織。
  • 工作區如何組織？ 按主題和範圍來組織工作區通常會很有用。 將內容組織到工作區中的方法可能會隨著部門而不同。
  • 個人工作區中包含多少內容？ 請考量在組織內適當使用個人工作區是指什麼。
  • 誰應具備工作區的存取權？ 首先您應將工作區存取權限定於建立和管理內容的使用者。 如需詳細資訊，請參閱內容建立者安全性規劃 (部分機器翻譯)。

如需進一步的考量，請參閱租用戶層級工作區規劃和工作區層級工作區規劃。

步驟 3：更新工作區

此時，您現有的工作區和制定的決策已可供使用。 如果您發現工作區要重新命名或重新組織，您現在已可進行任何必要的調整。

更新過程中的考量包括：

  • 誰會處理更新？ 如果您有數個 Fabric 管理員，請確認工作區是否由一或兩名特定管理員管理。 請確定程序是一致的，且受到充分了解及妥善控制。
  • 是否有變更管理程序？ 請考量如何避免決策、文件與產生的更新之間出現差異。 小組之間的溝通是變更管理成功與否的關鍵因素。 根據您的稽核需求，您可以選擇維護內部變更記錄檔，以追蹤誰做了哪些變更，及其時間和原因 (在活動記錄中擷取的內容以外記錄更多詳細資料)。
  • 如何處理與使用者的溝通？ 若進行的變更會影響到使用者所能執行的作業，請務必傳達該變更。 力求避免引發使用者不悅，和不必要的支援要求。

步驟 4：記錄工作區

根據您擁有的工作區數目，您可以建立文件來擴增管理入口網站或 REST API 中的可用資訊。 這種類型的文件是租用戶清查的重要部分。 您的文件可包括：

  • 更多內容或詳細資料，例如工作區的預定用途 (如果工作區描述中尚未提及的話)。
  • 核准工作區的人員和時間。
  • 指派為工作區擁有者的人員 (如果擁有者與工作區管理員不同)。
  • 與儲存在工作區中的內容相關的合規性或法規需求。
  • 工作區是否包含特別敏感的資訊。
  • 工作區的控管需求。
  • 適用於工作區的生命週期管理程序。

步驟 5：管理工作區

工作區的持續性管理主要涉及：

  • 建立新的工作區。
  • 更新工作區中繼資料 (例如名稱或描述)。
  • 更新工作區角色。
  • 復原已刪除的工作區。
  • 重新指派工作區 (例如，從 Pro 到 PPU)。
  • 管理建立工作區租用戶設定。

視角色和責任而定，次要管理員活動可能包括：

  • 將內容 (例如語意模型或報表) 發佈至工作區。
  • 對現有工作區內容的相關問題進行疑難排解。

重要

Fabric 管理員角色是可以執行許多高階功能的高權限角色。 值得注意的是，此角色不會自動授與對租用戶中所有資料的存取權。 不過，由於管理員有權管理租用戶中的工作區，因此可以將存取權授與其他使用者 (透過工作區角色)，包括他們自己。

步驟 6：稽核工作區

您應有定期稽核工作區的程序。 以下是使用活動記錄來稽核工作區時應識別的一些動作。

  • 建立工作區租用戶設定已變更：使用 UpdatedAdminFeatureSwitch 活動尋找活動記錄中已變更的租用戶設定值。 項目名稱將是 CreateAppWorkspaces。
  • Fabric 管理員已取得使用者個人工作區的存取權：尋找 AddAdminPersonalWorkspaceAccess 活動。 工作區名稱的格式將是 PersonalWorkspace-NameOfUser。 系統自動撤銷存取權時 (在 24 小時後發生)，將不會記錄任何活動。
  • 已建立新的工作區：尋找 CreateFolder 活動。
  • 現有的工作區已變更：尋找 UpdateFolder 活動。
  • 工作區的存取權已變更：尋找 UpdateWorkspaceAccess 活動或 UpdateFolderAccess 活動。
  • 已重新指派工作區：尋找 MigrateWorkspaceIntoCapacity 活動。
  • 工作區已指派給定義域：尋找 UpdateDataDomainFoldersRelationsAsAdmin 活動。

提示

除了使用活動記錄以外，建議您也定期建立租用戶清查。 這是某個時間點的快照集，會描述所有工作區及其內容 (例如語意模型和報表)。 此外也可擷取工作區存取的詳細資料。 如需詳細資訊，請參閱租用戶清查和存取租用戶清查資料。

檢查清單 - 規劃及管理工作區時的重要決策和動作包括：

  • 檢閱目前的工作區：檢閱管理入口網站中的所有工作區和相關租用戶設定，以確認目前的狀態。
  • 討論並決定：確認如何控管及管理工作區。 在決定允許誰管理工作區時，應讓相關決策者和專案關係人參與其中。
  • 確認是否需要核准：確認在建立新的工作區時是否應以某個程序來取得其他人的核准。
  • 建立重新檢閱的排程：設定定期重新檢閱工作區的排程。
  • 進行更新：在新的需求出現時更新工作區，包括角色指派。
  • 建立文件：如果您需要追蹤補充資訊，請為您的工作區建立文件。
  • 建立處理使用者要求的程序：設定使用者要求新工作區的程序。
  • 設定稽核：建立稽核程序，以便追蹤新工作區的建立時間，或發生變更的時間點。

控管內嵌程式碼

當您使用發佈至 Web 功能時，Power BI 會產生內嵌程式碼。 內嵌程式碼可用來將報表內嵌到任何人都可在網際網路上存取的網頁中。 這項功能適用於特定用途：主要用於有公用資料可由匿名對象檢視 (無需驗證) 的資料新聞或報表。

定期檢閱和管理內嵌程式碼，是 Fabric 管理員的重要職責。 這是一項特別重要的職責，因其涉及驗證已在網際網路上公開發佈的報表。

警告

有些管理員誤認為內部應用程式或內部網路站台是內嵌「發佈至 Web」報表的安全位置。 強烈建議您不要以此方式使用這項技術，因為透過發佈至 Web 發佈的報表無論內嵌於何處，都可透過搜尋引擎探索到。 為內部對象內嵌 Power BI 內容的適當做法，是使用 API 內嵌功能，或使用無程式碼內嵌技術。 如需詳細資訊，請參閱為組織內嵌使用案例。

步驟 1：檢閱內嵌程式碼

第一個步驟是檢閱現有的內嵌程式碼和租用戶環境，以便了解目前的狀態。 以下是檢閱的過程中應考量的一些因素。

步驟 2：決定內嵌程式碼

檢閱內嵌程式碼後，接著應檢查決策程序。 在討論哪些內容 (如果有的話) 可發佈到網路時，應讓相關決策者和專案關係人參與其中。

同時也請確認哪些使用者可以將報表發佈至 Web。 有控管原則或安全性原則存在時，請儘可能加以參考。

重要

強烈建議您僅為極少數的使用者啟用發佈至 Web 租用戶設定。 由於不慎發佈包含敏感性資料的報表風險很高，請考慮不允許或限制內容建立者發佈至 Web。

步驟 3：更新內嵌程式碼

此時，您現有的內嵌程式碼和制定的決策已可供使用。 您現在已可對現有的內嵌程式碼進行暫時或永久變更。

若要確認需要哪些更新，您可能需進行進一步的研究。

  • 檢閱具有作用中內嵌程式碼的所有報表，以確認沒有不適當的資訊發佈至 Web。 也請確認基礎語意模型未包含機密或專屬資訊。
  • 請連絡發佈報表的使用者，以釐清其用途。
  • 請與內容擁有者合作，視需要將內容重新放置到適合該用途的非個人工作區。 請考慮使用可明確指出其中包含公用內容的工作區。 例如，財務報告 [公用] 工作區的名稱即明確指出了其用途。
  • 檢閱指派給內容的敏感度標籤。 確認敏感度標籤指出了目標對象是公用對象。

步驟 4：記錄內嵌程式碼

根據您所處的情況，您可以建立一些文件，以補充管理入口網站中可用的資訊。 您的文件可包括：

  • 更多內容和詳細資料，例如用途、預定對象和理由。
  • 誰核准了要公開發佈的內容，以及發佈於何時。
  • 內容擁有者是誰 — 是否與發佈內容的使用者不同。

步驟 5：管理內嵌程式碼

您應在管理入口網站中定期監視內嵌程式碼。 此外，請考量如何管理想要將報表發佈至 Web 的使用者提出的要求。

注意

並非所有報表都支援與「發佈至 Web」搭配使用。 使用者可能會有關於使用此功能的支援問題。

步驟 6：稽核內嵌程式碼

請務必要有定期稽核內嵌程式碼的程序。 以下是使用活動記錄來稽核內嵌程式碼時應識別的一些動作。

  • 已建立新的內嵌程式碼：尋找 PublishToWebReport 活動。
  • 發佈至 Web 租用戶設定已變更：使用 UpdatedAdminFeatureSwitch 活動尋找活動記錄中已變更的租用戶設定值。 項目名稱將是 PublishToWeb。

檢查清單 - 規劃及管理內嵌程式碼時的重要決策和動作包括：

  • 檢閱目前的內嵌程式碼：檢閱管理入口網站中的所有內嵌程式碼，以確認目前的狀態。
  • 檢閱目前的租用戶設定：檢閱發佈至 Web 租用戶設定的設定。
  • 討論並決定：確認哪些內容 (如果有的話) 可以公開發佈，以及由哪些使用者發佈。 情況允許時，應讓相關決策者和專案關係人參與其中。 可能的話，請參閱現有的控管原則。
  • 確認是否需要核准：確認在將報表發佈至 Web 時是否應以某個程序來取得其他人的核准。
  • 建立重新檢閱的排程：設定定期重新檢閱內嵌程式碼的排程。
  • 進行更新：視需要更新目前的內嵌程式碼。 根據所做的決策更新發佈至 Web 租用戶設定 (如果與目前發佈的不同)。
  • 建立文件：如果您需要追蹤補充資訊，請建立內嵌程式碼的工作區。
  • 建立處理使用者要求的程序：設定適當程序，讓使用者可要求將報表發佈至 Web，或有權將自己的報表發佈至 Web。
  • 設定稽核：建立稽核程序，以便追蹤是否有新的內嵌程式碼建立，以及發佈至 Web 租用戶設定是否有所變更。

控管組織視覺效果

Power BI 報表建立者可以在 Power BI 報表設計中使用數種類型的視覺效果。

  • 核心視覺效果：Power BI Desktop 和 Power BI 服務內建的預設現成視覺效果。
  • 來自 AppSource 的非認證自訂視覺效果：由第三方軟體廠商或全球 Power BI 社群的成員開發的自訂視覺效果。
  • 來自 AppSource 的認證自訂視覺效果：由第三方軟體廠商或全球 Power BI 社群的成員開發，且已通過 Microsoft 所定義的認證程序的自訂視覺效果。

組織可選擇藉由註冊允許哪些特定的視覺效果 (和版本) 來限制自訂視覺效果的使用 (當報表發佈至 Power BI 服務時)。 允許的視覺效果稱為組織視覺效果。

Fabric 管理員負責在系統管理中心註冊及管理組織視覺效果。 他們可以註冊：

註冊組織視覺效果有許多好處。

  • 部分或所有自訂視覺效果將在視覺效果窗格中自動提供給所有報表建立者使用。
  • 內容建立者不需要匯入 Power BI 視覺效果 (.pbiviz) 檔案。
  • 所有報表的自訂視覺效果版本都一致。
  • 報表和儀表板會在組織視覺效果更新時自動更新。
  • 新的和變更的自訂視覺效果可先經過有系統地測試並預先核准，再廣泛提供給組織使用。
  • 如果現有的自訂視覺效果不再符合組織的需求，將可快速停用或刪除。

若要深入了解在使用者裝置上發佈自訂視覺效果 (用於 Power BI Desktop) 時的考量事項，請參閱自訂視覺效果。

本節的其餘部分著重於組織視覺效果的管理。

步驟 1：檢閱組織視覺效果

第一個步驟是檢閱現有的組織視覺效果和租用戶環境，以便了解目前的狀態。

步驟 2：決定組織視覺效果

檢閱組織視覺效果後，接著應檢查決策程序。 您應做好準備，針對如何控管自訂視覺效果做出審慎考量的決策。

以下是決策的過程中應考量的一些問題。

  • 組織是否允許自訂視覺效果？ 組織可能基於若干原因刻意選擇使用自訂視覺效果。
    • 對品質與穩定性的期望會根據自訂視覺效果的開發人員而有所不同。
    • 免費提供的自訂視覺效果可能沒有技術支援。
    • 對於深切顧慮資料隱私權 (或對資料外洩問題極為敏感) 的組織，使用自訂視覺效果可能與其風險設定檔不相容。 這是因為自訂視覺效果可以存取從語意模型查詢的資料。 此外，自訂視覺效果可能會將資料傳回至 Web 服務 (通常是基於合法用途，例如呼叫 API 或執行 AI 演算法)。
  • 如何驗證及核准使用自訂視覺效果？ 所有自訂視覺效果都應先經過測試並預先核准，才在組織中使用。 此驗證程序可降低使用不受信任的視覺效果的風險。 此外也可讓管理員指定已經過測試並核准使用的版本。
  • 誰可以使用自訂視覺效果？ 允許使用 Power BI SDK 建立的視覺效果租用戶設定可控制誰可以新增、共用自訂視覺效果或與互動。 如果組織已決定要限定或限制這項功能 (從 AppSource 或匯入的 .pbiviz 檔案)，則您可以使用組織視覺效果作為允許特定自訂視覺效果的方法。
  • 是否需要經認證的視覺效果？ 如果允許 AppSource，某些組織會傾向於將其限定為經認證的視覺效果。 這可藉由設定僅新增和使用經認證的視覺效果租用戶設定來完成。 在此情況下，您可以使用組織視覺效果來發佈已核准供組織使用的未認證視覺效果。
  • 自訂視覺效果是否應集中管理？ 若視覺效果是由個別報表建立者從 AppSource 下載的，可能會有版本不相符的問題。 使用組織視覺效果存放庫來集中管理自訂視覺效果，報表建立者的程序將會更簡單，因為這可讓租用戶內的所有 Power BI 報表建立者使用相同的核准版本。 不過，這需要 Fabric 管理員參與，而可能因此導致延遲。
  • 允許哪些來源？ 組織視覺效果可來自 AppSource 或 .pbiviz 檔案。 AppSource 通常是最佳來源，尤其是您想要使用經認證的視覺效果時。 視覺效果是私下向廠商取得，或是由內部開發時，適合使用 .pbiviz 檔案。
  • 自訂視覺效果何時應出現在視覺效果窗格中？ 在許多情況下，都應允許自訂視覺效果出現在視覺效果窗格中，使其自動提供給所有報表建立者使用。

步驟 3：更新組織視覺效果

此時，您現有的組織視覺效果和制定的決策已可供使用。 您現在已可對現有的組織視覺效果進行暫時或永久變更。

您可能也需要修改與自訂視覺效果相關的租用戶設定 (如果允許報表建立者下載並安裝不在組織視覺效果存放庫中的自訂視覺效果)。

注意

與自訂視覺效果相關的租用戶設定僅適用於已發佈的報表，不適用於 Power BI Desktop 中的報表。 若要確保報表建立者在 Power BI 服務和 Power BI Desktop 中有一致的自訂視覺效果選項，您必須使用群組原則來管理本機電腦自訂視覺效果 (適用於 Power BI Desktop)。 如需詳細資訊，請參閱使用者工具和裝置。

步驟 4：記錄組織視覺效果

根據您所處的情況，您可以建立一些文件，以補充管理入口網站中可用的資訊。 您的文件可包括：

  • 更多內容和詳細資料，例如自訂視覺效果實現的成果。
  • 自訂視覺效果的建立者 (例如內部開發人員或廠商)，或您需要詳細資訊時的連絡對象。
  • 為了驗證視覺效果而執行的測試，以便在視覺效果更新時能夠重複型測試。
  • 核准使用自訂視覺效果的人員與時間點。

步驟 5：管理組織視覺效果

您應在管理入口網站中定期監視組織視覺效果。 此外，請考量如何管理想要使用在線上找到的新自訂視覺效果的使用者提出的要求。

有時，您也應檢閱每個自訂視覺效果上次更新的時間。 調查是否有較新的版本可供使用。 當有較新的版本可用時，您可以更新組織視覺效果，前提是必須已通過測試。

步驟 6：稽核組織視覺效果

請務必要有定期稽核組織視覺效果的程序。 以下是使用活動記錄來稽核組織視覺效果時應識別的一些動作。

  • 已新增組織視覺效果：尋找 InsertOrganizationalGalleryItem 活動。
  • 現有的組織視覺效果已更新：尋找 UpdateOrganizationalGalleryItem 活動。
  • 允許使用 Power BI SDK 建立的視覺效果租用戶設定已變更：使用 UpdatedAdminFeatureSwitch 活動尋找活動記錄中已變更的租用戶設定值。 項目名稱將是 CustomVisualsTenant。
  • 僅新增及使用經認證的視覺效果 (封鎖未認證的) 租用戶設定已變更：使用 UpdatedAdminFeatureSwitch 活動尋找活動記錄中已變更的租用戶設定值。 項目名稱將是 CertifiedCustomVisualsTenant。

檢查清單 – 規劃及管理組織視覺效果時的重要決策和動作包括：

  • 檢閱目前的組織視覺效果：檢閱管理入口網站中的所有組織視覺效果，以確認目前的狀態。
  • 檢閱目前的租用戶設定：檢閱每個 Power BI 視覺效果租用戶設定。 確認您對組織視覺效果的依賴如何受其影響。
  • 討論並決定：確認應如何在組織中使用自訂視覺效果，以及由誰使用。 在考量如何使用組織視覺效果、AppSource 和 .pbiviz 檔案時，應讓相關決策者和專案關係人參與其中。
  • 建立重新檢閱的排程：設定定期重新檢閱組織視覺效果的排程。
  • 進行更新：視需要更新目前的組織視覺效果。 根據所做的決策更新 Power BI 視覺效果 租用戶設定 (如果與目前發佈的不同)。
  • 管理使用者機器：設定群組原則，以確保在 Power BI Desktop 和 Power BI 服務中自訂視覺效果的管理方式相同。
  • 建立文件：如果您需要追蹤補充資訊，請建立組織視覺效果的工作區。
  • 建立處理使用者要求的程序：設定使用者要求使用自訂視覺效果 (一般) 或要求存取特定自訂視覺效果的程序。
  • 設定稽核：建立稽核程序，以便追蹤是否有新的自訂視覺效果註冊為組織視覺效果，以及是否有任何 Power BI 視覺效果租用戶設定有所變更。

控管 Azure 連線

Power BI 可以與 Azure 服務整合，以擴充功能及提供其他功能。 使用 Azure 連線有三個主要原因。

  • 資料流程 (Gen1) 的資料儲存體。 您可以直接在 Azure 中存取 Power BI 資料流程 (Gen1) 的資料。 工作區可以連線至定義於租用戶層級的儲存體帳戶，或連線至工作區專用的儲存體帳戶。 這項技術有時稱為自備授權 (BYOL)。 當您想要藉由允許其他程序 (或其他使用者) 檢視或存取資料，來重複使用 Power BI 以外的資料流程資料時，BYOL 策略的彈性會很有幫助。 如需詳細資訊，請參閱將資料流程儲存體設定為使用 Azure Data Lake Storage Gen2 和自助式資料準備使用案例。

  • 語意模型備份與還原。 基於災害復原用途，您可能需要備份與還原語意模型，以符合資料保留需求，或移轉資料模型。 如需詳細資訊，請參閱使用 Power BI Premium 備份與還原語意模型。

  • Azure Log Analytics 整合。 您可以分析語意模型活動、效能和趨勢。 Azure Log Analytics 可讓您檢閱 Analysis Services 引擎 (裝載了 Power BI 語意模型) 所產生的診斷資料。 如需詳細資訊，請參閱 語意模型事件記錄檔。

    注意

    數據集名稱變更已在 Power BI 服務 和檔中推出，不過可能有一些實例，例如事件記錄作業名稱，但變更尚未發生。

如果您的 Azure 連線主要使用案例是用於資料儲存 (上述第一點所說明的 BYOL)，建議您轉而考慮使用資料流程 Gen2 和 OneLake。 雖然兩者都使用 ADLS Gen2 作為資料儲存體，但提供不同的功能、具有略為不同的用途，且使用不同的儲存體選項 (視資料的寫入方式而定)。 例如：OneLake 會以開放式 Delta Parquet 格式儲存表格式資料和資料流程 Gen2 資料，而 Power BI 資料流程 (Gen1) (使用 Azure 連線) 的輸出則以通用資料模型格式儲存資料。 如需詳細資訊，請參閱從第 1 代資料流程到第 2 代資料流程。

本節的其餘部分著重於管理入口網站中的 Azure 連線控管。

步驟 1：檢閱 Azure 連線

第一個步驟是檢閱現有的 Azure 連線和租用戶環境，以便了解目前的狀態。 有兩個領域需要檢閱。

首先，請檢閱管理入口網站中的現有設定。

  • 目前的租用戶層級儲存體設定：檢閱租用戶層級儲存體目前的設定方式。 其中提供工作區管理員可以選擇在其工作區設定內連線到的預設 Azure 連線。
  • 目前的工作區層級儲存體權限：檢閱工作區層級儲存體權限是否啟用。 啟用時，會允許工作區管理員將工作區連線至其本身的 ADLS Gen2 帳戶。

其次，請檢閱工作區管理員的 Azure Log Analytics 連線租用戶設定的設定。 啟用時，工作區管理員可以將工作區連線至 ADLS Gen2 帳戶，以便傳送語意模型的診斷資料。

步驟 2：決定 Azure 連線

檢閱 Azure 連線後，接著應檢查決策程序。

以下是決策的過程中應考量的一些問題。

  • Azure 連線的使用是否符合您的資料策略和使用者需求？ 請考量 Azure 連線對於資料流程 (Gen1) 的儲存是否有效用。 確認您是否需要使用語意模型備份與還原功能。 請考量是否需要 Azure Log Analytics 整合。
  • 集中式與分散式資料儲存體分別為何？ 了解分散式小組的需求，以及個人或部門目前是否有其本身的 Azure 儲存體帳戶。 請確認工作區管理員是否可以連接自己的 ADLS Gen2 帳戶，或您是否傾向於對所有工作區使用一個 ADLS Gen2 帳戶 (租用戶層級儲存體)。
  • OneLake 與 Azure 連線的用法分別為何？ 隨著 OneLake 的導入，請考量您是否可以選擇逐改為使用 OneLake 進行資料儲存 (BYOL)。

如需詳細資訊，請參閱工作區與 ADLS Gen2 整合。

如需詳細資訊，請參閱工作區與 Azure Log Analytics 整合。

步驟 3：更新 Azure 連線

此時，您現有的 Azure 連線已可供使用，且您已針對是否打算整合資料湖與 Power BI 做出有意義的決策。 您現在已可視需要根據調查結果來調整設定。

步驟 4：記錄 Azure 連線

根據您所處的情況，您應建立一些文件以補充管理入口網站中可用的資訊。 您的文件可包括：

  • 已核准使用的租用戶層級資料湖位置。 包含擁有和管理資料湖的人員，以及您需要詳細資訊時的連絡對象。
  • 工作區層級資料湖是否可以整合。 其他資訊 (例如，做出的重要決策及其原因) 應記載於文件，以供日後參考。

步驟 5：管理 Azure 連線

您應不時在管理入口網站中監視 Azure 連線。

請考量如何在組織中支援多個 ADLS Gen2 帳戶 (如果允許工作區層級 Azure 連線)。

此外，請考量如何管理想要將工作區連線至 Azure Log Analytics 的使用者提出的要求。

步驟 6：稽核 Azure 連線

請務必要有定期稽核 Azure 連線的程序。 使用活動記錄來稽核 Azure 連線時有幾個需要識別的動作。

  • 工作區已連線至 ADLS Gen2：尋找 AddLinkToExternalResource 活動。 ResourceType 會指出這是儲存體帳戶還是 Log Analytics。
  • 工作區已與 ADLS Gen2 中斷連線：尋找 DeleteLinkToExternalResource 活動。 ResourceType 會指出這是儲存體帳戶還是 Log Analytics。
  • 租用戶層級儲存體已啟用或停用：使用 AddExternalResource 或 DeleteLinkToExternalResource 活動，在活動記錄中尋找已變更的值。
  • 工作區層級儲存體已啟用或停用：使用 UpdatedAdminFeatureSwitch 活動，尋找活動記錄中已變更的值。 項目名稱將是 storageAccountAttachForWorkspaceAdminsEnabled。 SwitchState 將是 true 或 false。
  • 工作區管理員的 Azure Log Analytics 連線租用戶設定已變更：此租用戶設定可讓部分或所有工作區管理員整合自己的 ADLS Gen2 帳戶。 使用 UpdatedAdminFeatureSwitch 活動，在活動記錄中尋找已變更的租用戶設定值。 項目名稱將是 LogAnalyticsAttachForWorkspaceAdmins。

檢查清單 - 規劃及管理 Azure 連線時的重要決策和動作包括：

  • 檢閱目前的 Azure 連線：檢閱管理入口網站中 Azure 連線的租用戶層級和工作區層級設定，以確認目前的狀態。 另請檢閱工作區管理員的 Azure Log Analytics 連線租用戶設定的設定。
  • 討論並決定：確認是否要整合 Azure 連線與 Power BI。 接下來，請決定 OneLake 與 Azure 連線的資料儲存 (BYOL) 最佳用途。
  • 確認是否需要核准：確認在使用工作區層級儲存體帳戶時是否應以某個程序來取得核准。
  • 建立重新檢閱的排程：設定定期重新檢閱 Azure 連線的排程。
  • 進行更新：視需要更新目前的 Azure 連線，以修改租用戶層級和工作區層級的儲存體權限。 此外，請根據所做的決策更新工作區管理員的 Azure Log Analytics 連線租用戶設定 (如果與目前設定的不同)。
  • 建立文件：如果您需要追蹤補充資訊，請建立 Azure 連線的工作區。
  • 建立處理使用者要求的程序：設定使用者要求能夠使用 Azure 連線的程序。
  • 設定稽核：建立稽核程序，以便監視工作區是否設定了 Azure 連線，或設定是否有所變更。

稽核 Power BI 的使用情形

租用戶層級稽核資料可讓您分析採用工作、了解使用模式、教育使用者、支援使用者、降低風險、改善合規性、管理授權成本，以及監視效能。 請務必及早擷取和儲存 Power BI 稽核資料，即使您尚未做好分析資料的準備亦然。

如需在 Power BI 中稽核使用者、活動和解決方案的相關資訊，請參閱租用戶層級稽核。

監視 Power BI 服務

監視是持續性的活動，會通知您目前發生的情況。 監視通常是涉及警示和自動化的被動活動，但有時會主動執行。

如需監視 Power BI 的相關資訊，請參閱租用戶層級監視。

相關內容

如需更多考量、動作、決策準則和指引以協助您進行 Power BI 實作決策，請參閱 Power BI 實作規劃。