制定租用戶環境策略，以大規模採用 Power Platform

每個組織採用 Microsoft Power Platform 的旅程都是獨一無二的。 租用戶環境策略可奠定基礎，用可管理且安全的方式加速使用。

本白皮書介紹如何使 Power Platform 租用戶環境策略與產品功能和願景保持一致。 您將了解如何妥善利用該平台的最新功能來實施策略，使您採用 Power Platform 達到企業規模。

注意

您可選取瀏覽器的列印，然後選取儲存為 PDF 來儲存或列印本白皮書。

簡介

Power Platform 使組織能夠建置低程式碼解決方案，以實現快速創新。 這些解決方案可以專注於個人和小型團隊的生產力，也可以套用於整個組織。 它們還可以延伸到商務程序，包括外部客戶和合作夥伴。 支援這些解決方案的是 Power Platform 環境，其可建置、測試和使用低程式碼資源。 隨著組織逐漸採用 Power Platform，實施良好的租用戶環環境策略可在環境數量增長的同時，使環境易於管理並保持環境安全，這點至關重要。

為了協助您取得更大的成功，本文將指導您如何最好地使用可用功能來建立您的第一個環境策略，或改進您目前的計劃。 我們還將概述願景，說明對這些功能如何協同工作，以及它們將如何發展以進行大規模管理 Power Platform。 在本指南中，我們介紹了如何正確地將新使用者路由到環境和群組環境，以一致地套用租用戶環境策略的治理、安全性規則和其他重要部分。 我們還提供了保護預設環境的詳細步驟，這是實施環境策略的關鍵第一步。

雖然管理 Power Platform 環境有許多不同的觀點，但本文中的方法與 Microsoft 的最新產品方向保持一致，並使用目前功能和近期計劃的增強功能。 此更新的指南可幫助您確保僅使用對 Microsoft 打算如何大規模管理環境具有策略意義的環境功能和選項。

Microsoft 的租用戶環境策略願景

許多組織透過在稱為預設環境的共用中央環境中建置和執行個人生產力應用程式和自動化，來開始他們的 Power Platform 旅程。 這些資源通常只使用 Microsoft 365 隨附的基本功能，而不使用 Power Platform 的全部功能。 隨著初始採用速度加快，Microsoft 為組織提供了一個環境策略的入口，以便企業大規模採用完整的 Power Platform 功能。 當使用者擁有進階 Power Platform (Power Apps、Power Automate、和 Microsoft Copilot Studio Dynamics 365) 授權時，即可使用這些進階治理功能。 Power Platform 採用成熟度模型可以提供更多深入解析，幫助組織定義其路線圖，以實現超出其環境策略的企業規模採用。 此方法可以幫助組織從基本的個人生產力發展到 Power Platform 的企業級採用。

Power Platform 管理、治理和安全性功能可讓組織採用和管理 Power Platform，以提高企業生產力和企業應用程式的大規模使用。 使用受控環境可啟動一組進階功能，這些功能可實現更高的可見性和控制力，並減少管理和保護環境的手動工作。 使用這些功能，您可以確保套用一致的治理和安全性原則。 管理員可以使用這些功能轉換到企業級環境策略。 隨著組織的使用量增加，降低用於管理的時間和精力有助於降低平台的總體擁有成本 (TCO)。

向企業規模轉換的一個關鍵要素是，透過使製作者更容易使用個人開發環境來增強製作者的共用中心環境策略。 在共用的中央環境策略中，製作者在預設環境中建置、使用和共用應用程式。 這種策略可能導致缺乏隔離和製作者相互侵佔。 想像一下，如果公司中的每個人都共用一個 OneDrive 資料夾來存放他們的所有文件。 相反，您可以使用環境功能將製作者引導到他們自己的個人環境，在那裡他們可以安全地建置自己的應用程式，防止製作者處理不相關的資產，並為管理員簡化治理。 可以將同事作為製作者新增到這些環境中，以協作建置解決方案。

圖：共用的中央環境 (左) 和環境路由策略 (右) 的圖示。

新建立的製作者環境可以自動新增到套用規則的群組中，以確保環境具有一致的治理和安全性原則。 管理員可以透過將製作者的環境移動到規則寬鬆的組來處理例外狀況。

製作者建立的低程式碼資源代表了資源的應用程式生命週期管理 (ALM) 旅程的初始階段。 作為初始階段的一部分，擷取資源的每個版本並能夠在必要時重新建立它非常重要。 當資源準備好共用時，製作者可以使用附加到開發人員環境的持續整合將其提升到生產環境，使用者可以在其中執行與任何持續的製作者活動隔離的資源。

如果可能，您應該優先考慮使用平台的內建功能來管理環境，而不是建置自己的工具。 如果內建功能不符合組織的獨特要求，則可以使用平台管理工具建立自訂工具。 當新功能可用時，應針對任何自訂工具進行評估。 密切關注 Microsoft 的平台路線圖並維護您自己的路線圖，這可以幫助您簡化操作。

應使用針對組織獨特需求量身打造的建議環境功能來建立環境策略。 不要將建立環境策略視為一次性活動。 它應該隨著時間的推移而發展，以納入新的環境功能 (當它們可用時)。

支援企業級環境策略的功能

環境是 Power Platform 管理、治理和安全性的建置元素。 完整的功能概述超出了本文的範圍；但是，本節重點介紹支援在企業範圍內實施環境策略的功能。

• 環境類型描述了作為策略一部分的環境的不同用途。

• 受控環境提供一組進階功能，使環境更易於大規模管理。

• 授權自動聲明可讓使用者在需要時聲明 Power Apps 每個使用者授權，而不需要管理員提前識別需要授權的使用者，從而簡化了授權指派。

• 環境群組和規則說明如何將環境作為群組進行管理，以及如何將規則套用於群組以自動執行一致的治理原則。

• 預設環境路由會自動將製作者從在預設環境中建立資源轉移到他們自己的個人環境。

• Microsoft Dataverse 提供增強型安全性和 ALM。

• 慣用的解決方案可幫助製作者確保他們建置的所有資產都在 Dataverse 解決方案中，讓他們可更輕鬆地將其提升到其他環境。

• Power Platform 中的管線提供了一個簡化的程序，用於將資產從開發環境提升到測試和生產環境，使所有製作者都可以使用持續整合和部署 (CI/CD)。

• Power Platform 中的目錄可讓製作者共用元件 (如應用程式和流程) 和更進階的起點 (如範本)。

環境類型

下表描述了可以建立的環境類型、其特點及預期用途。

Type	特點和使用方式
Default	每個租用戶附帶的環境。 許多 Microsoft 365 體驗使用此環境進行自訂和自動化。 此環境不適用於 Microsoft 365 個人生產力方案之外的長期或永久性工作。
實際執行環境	此環境適用於組織中的永久性工作。 生產環境支援延長備份保留期 (從 7 天到最多 28 天)。
沙箱	這些非生產環境支援複製和重設等環境動作。 沙箱最適合用於測試和 ALM 建置環境。
Developer	這些特殊環境旨在作為製作者的個人開發工作區，將低程式碼資產與使用者和其他製作者隔離開來。 製作者最多可以有三個開發人員環境。 它們不會計入租用戶容量。 如果擁有者未回應通知，90 天未使用的開發人員環境將自動關閉，然後從租用戶中移除。 Dynamics 365 應用程式無法在開發人員環境中使用。
試用服務	這些環境旨在支援短期測試和概念驗證。 每個使用者只能有一個。 試用環境會在短時間內自動從租用戶中移除。
Microsoft Dataverse for Teams	當您在 Teams 中建立應用程式或從應用程式目錄安裝應用程式時，會自動建立這些環境。 這些環境的安全性模型與其關聯的團隊一致。
支援	這些是由 Microsoft 支援服務建立的特殊環境，可讓工程師解決問題。 這些環境不會計入租用戶容量。

在制定整體租用戶環境策略時，不同類型的策略與支援策略建議相關。

受控環境

環境具有一組基本功能和特點，具體取決於環境類型。 受控環境擴充了基本功能，提供一套進階功能，使管理員能夠以更多的控制、更少的工作量和更多的深入解析，更輕鬆地大規模管理 Power Platform。 當您將環境設定為受控環境時，這些功能將會解鎖。

下表列出了截至撰寫本文時可用的受控環境的功能。 我們會經常新增功能，因此請參閱文件以取得最新清單。 儘管所有功能都可以幫助您建置環境策略，但斜體功能與本文中概述的策略更相關。

可見度提升	更多控制	更輕鬆
使用方式深入解析 管理員摘要 授權報表 資料原則檢視 將資料匯出至 Azure Application Insights 所有應用程式的 AI 生成描述	共用限制 桌面流程的資料原則 解決方案檢查程式 製作者歡迎使用內容 IP 防火牆 IP Cookie 繫結 客戶自控金鑰 客戶加密箱 擴充備份	輕鬆啟用 Power Platform 管線 環境路由 環境群組和規則 Power Platform Advisor

授權自動聲明

自動聲明原則會在使用者需要使用某些應用程式或功能時，自動為其指派 Power Apps 授權和 Power Automate 授權。 自動化有助於減少使用的授權數量，並避免手動指派授權的開銷。

設定原則後，組織中任何需要獨立 Power Apps 授權的使用者都會在以下條件下自動取得該授權：

• 如果沒有獨立 Power Apps 授權的使用者啟動需要進階授權的應用程式，系統會自動為使用者指派 Power Apps 每個使用者授權。

• 如果沒有獨立 Power Apps 授權的使用者在受控環境中啟動應用程式，系統會自動為使用者指派 Power Apps 每個使用者授權。

同樣地，設定原則後，組織中任何需要獨立 Power Automate 授權的使用者都會在以下條件下自動取得該授權：

• 使用者透過有人參與型的 RPA (機器人程序自動化) 觸發、儲存或開啟進階雲端流程。

• 使用者要求 Power Automate 進階授權。

如果您的環境策略包括受控環境，建議設定授權自動聲明。 應用程式和流程的使用者遇到的授權摩擦最少，您只需為主動執行應用程式或使用 Power Automate 的使用者耗用授權。

環境群組和規則

隨著租用戶中 Power Platform 採用率增加，需要管理和治理的環境數量也會增加。 隨著環境數量的增加，確保在環境中套用一致的設定和治理原則變得更具挑戰性。 環境群組功能能讓您更輕鬆地達成一致性，因為它可建立命名群組並將環境與群組關聯，就像將相關文件放在資料夾中。

考慮使用環境群組時，請記住以下注意事項：

• 必須對環境進行管理才能將其包含在群組中。

• 一個環境一次只能屬於一個群組。

• 環境可以從一個群組移動到另一個群組。

• 群組中的環境可以來自多個地理區域。

• 群組不能包含其他群組。

為了幫助您套用一致的設定和治理，環境群組可以設定並啟用以下一個或多個規則：

• 畫布應用程式的共用控制項

• 使用方式深入解析

• 製作者歡迎內容

• 解決方案檢查程式強制執行

• 備份保留

• AI 產生的描述

規則發佈後即生效。 活動規則將套用於與群組關聯的所有環境。

當群組規則管理設定時，各個環境設定將被鎖定。 變更它們的唯一方法是修改規則。 如果從群組中移除環境，它將保留群組設定，但現在環境管理員可以變更它們。 這對於環境策略很重要，因為它可確保環境管理員無法覆寫您為群組設定的原則。

使用環境群組可讓您以邏輯方式組織環境，類似於組織結構、產品服務階層或我們稍後將探討的其他框架。 下圖是 Contoso 組織如何考慮組織其環境群組的概念範例。

圖：Contoso 租用戶環境策略的概念化。

當您規劃要設定的規則時，請仔細考慮可以在概念階層的每個層級上套用哪些內容。 雖然您還無法設定群組階層，但可以搭配使用命名慣例和規則設定來實現概念設計。 例如，以先前的 Contoso 租用戶概念為例，下圖表示組織可用於實現其設計的環境群組。

圖：在實際租用戶中實作概念環境群組的範例

在本文的後面部分，我們將探討更多將環境群組作為租用戶環境策略一部分的方法。

預設環境路由

本文中概述的一個環境策略關鍵部分是，盡量不要讓製作者在預設環境中建立資源。 環境路由功能將製作者重新導向到他們自己的個人開發環境，並根據需要建立新的開發人員環境。

圖：製作者在建置應用程式時，自動重新導向到個人開發者環境而不是預設環境

預設情況下，會管理透過路由建立的開發人員環境。 具有開發人員方案授權的使用者只能在環境中建立和預覽資源。 若要以使用者身分執行資源，他們需要適當的授權。

您可以單獨使用環境路由，但建議將其與環境群組一起使用。 以這種方式使用時，建立的任何環境都會與您指定用於包含所有新開發人員環境的群組相關聯，從而確保治理策略立即涵蓋該環境。

系統會自動為製作者指派一個資訊安全角色，使他們成為開發人員環境的環境管理員。 當環境是環境群組的一部分時，製作者 (作為環境管理員) 無法變更環境設定，因為它們由環境群組規則管理。 只有可以修改群組規則的管理員才能進行變更。

您可以透過兩種方式施加更多控制。 首先，您可以禁止在租用戶設定中手動建立開發人員環境。 設定此選項後，製作者將無法在管理入口網站中自行建立環境。 他們也無法透用路由原則自動建立環境。 其次，您可以在路由原則中指定安全性群組，以限制誰可以自動建立環境。

最初，環境路由支援在新的和現有的製作者使用 make.powerapps.com 時，將其路由到遠離預設環境的位置。 隨著時間的推移，其他 Power Platform 服務將支援環境路由功能。

Microsoft Dataverse

Dataverse 可安全地儲存和管理應用程式使用的資料。 在環境策略的內容中，Dataverse 解決方案功能是用於將應用程式和元件從一個環境傳輸到另一個環境的功能。 製作者在容器 (解決方案) 中建置資產，這些容器可以追蹤他們建置的內容。 解決方案可以輕鬆轉移到其他環境。 使用此方法，可以將製作者建置資源的開發人員環境與使用這些資源的生產環境分開。 製作者和使用者都受益。 製作者可以繼續發展他們的資源，使用者不會對突然的變化感到驚訝。 當製作者準備好發佈其變更時，他們可以要求將更新的資源提升到生產環境。

Dataverse 解決方案是在 Power Apps 和 Power Automate 等 Power Platform 產品中實作 ALM 的機制。 Power Platform 中的管線使用解決方案來自動化製作者建置的資產的 CI/CD。 解決方案可以從 Dataverse 匯出，並儲存在 Azure DevOps 或 GitHub 等原始檔控制工具中。 如果需要重新建立開發環境，原始檔控制中的解決方案將成為事實來源。 例如，如果製作者建置了一個熱門的應用程式，然後刪除了開發人員環境，則可以使用儲存在原始檔控制中的匯出解決方案來重新建立可執行的開發環境。

使用 Dataverse 建立環境時的另一個重要考慮因素是，是否將任何 Dynamics 365 應用程式部署到該環境中。 如果存在這種可能性，您必須在建立環境時啟用 Dynamics 365，否則之後將無法安裝 Dynamics 365 應用程式。

建議您在製作者建立將與其他使用者共用的資產的任何環境中佈建 Dataverse。 這使得資產更容易做好 ALM 準備。

慣用的解決方案

當製作者在 Dataverse 環境中建立 Dataverse 資產 (而不是從自訂解決方案開始) 時，該資產將與預設解決方案相關聯，也可能與 Common Data Service 預設解決方案相關聯。 預設解決方案由在環境中建立資產的所有製作者共用。 這讓您無法輕鬆確定哪個製作者建立了哪些元件，或哪些資產屬於哪些應用程式。 這可能會導致熱門的應用程式難以提升到另一個環境，無法與更多受眾共用。 這使您必須提升預設解決方案中的所有資產，這可不是理想的情況。

為了支援您的環境策略並使其更易於使用，製作者應該在其開發環境中建立自訂解決方案，然後將其設定為環境中的慣用解決方案。 製作者會在環境中設定慣用的解決方案，以指示他們建立的資產應與哪個解決方案相關聯。 慣用的解決方案可以幫助確保當製作者使用管線將其資源提升到其他環境時，提升的解決方案包含所有必要的資產。 將此視為準備資產以做好 ALM 準備。

Power Platform 中的管線

正如我們所看到的，良好環境策略的一個關鍵原則是將資產的建置位置與部署和使用資產的位置隔離開來。 這種分離可確保嘗試使用資產的使用者不會因為製作者正在更新資產而遇到停機。 但是，它要求先將資產提升到生產環境 (理想情況下，作為 Dataverse 解決方案的一部分)，然後才能使用它們。

Dataverse 解決方案可以在環境之間手動傳輸。 但是，您可以使用管線自動執行該程序，並制定原則以確保進行適當的變更管理。 根據在解決方案檢查工具中設定的環境規則，管線會在部署解決方案之前自動強制實施所有規則，從而防止出現進一步的部署錯誤。 下圖說明了管線如何自動將資產從開發環境提升到生產環境。

圖：管線自動提升儲存在原始檔控制中的資產 (從開發環境、測試環境到生產環境)

您可以設定需要包含在管線中的環境和流程 (如核准) 的數量。

管線與環境群組協同工作。 它們可以針對開發環境進行預設定，以可讓製作者在嘗試與其他使用者共用其資產時回應提示，從而輕鬆啟動升階程序。 作為使用管線的部署要求的一部分，製作者可以建議與誰共用其資產以及所需的資訊安全角色。 管線管理員可以在部署之前核准或拒絕要求，方法是確保發起要求的製作者具有最低權限。

Power Platform 中的管線會將每個管線的定義儲存在 Microsoft 預設管理的託管環境中。 但是，您可以在您管理的租用戶中定義多個託管環境，從而處理獨特的要求。

Power Platform 中的目錄

開發人員和製作者在其中建置和共用元件 (如應用程式和流程以及範本) 的組織 (更進階的起點) 往往會從 Power Platform 中獲得更多價值。 Power Platform 目錄可讓製作者輕鬆且有效率地跨環境共用其元件和範本。

目錄安裝在環境中，並且可以與管線主機安裝在同一環境中。 還可以透過安裝具有目錄的多個環境來處理獨特的資源分割要求。

功能藍圖

隨著 Microsoft 繼續發展支援治理和管理的 Power Platform 功能，您可以透過發行計劃了解情況。 您將了解計劃的內容、接下來的發行版本內容，以及現在可以試用的內容。 您甚至可以透過儲存您想關注的項目來建立自己的發行計劃。

企業級環境策略的基礎

我們討論了企業級租用戶環境策略的願景，以及支援它的關鍵環境功能。 現在，我們將研究如何將這些功能作為環境策略的一部分搭配使用。 您的策略應基於組織的獨特要求，因此在討論如何自訂策略以滿足您的需求之前，讓我們先從一個基本範例開始。

在此範例中，Contoso 領導層希望授權員工利用 Power Platform，並已確定以下進階要求：

• 員工需要能夠使用 Microsoft 365 建置自動化的文件核准流程和其他 Power Platform 自訂功能。

• 員工應該能夠建置 Power Apps 和 Power Automate 自動化程序，以提高他們的個人生產力。

• 負責公司合規追蹤應用程式的開發者必須能夠開發和維護它。

為了支援這些要求，Contoso 管理員和治理團隊提出了以下環境拓撲：

圖：Contoso Power Platform 大規模專案的建議環境拓撲。

讓我們詳細探討此環境拓撲圖。

預設環境用於建立 Microsoft 365 生產力自訂。 資料外洩防護原則和共用限制限縮了其他類型的製作者活動，並為製作者可以在此環境中建置的內容設定了護欄。

只有管理員才能建立試用、沙箱和生產環境。 製作者使用自訂 Microsoft Form 或其他流程來要求新環境。 Microsoft Power Platform 卓越中心 (CoE) 入門套件包括可以使用的環境要求。

將建立四個環境群組：開發環境群組、共用開發環境群組、UAT (使用者驗收測試) 環境群組和生產環境群組。

• 為開發群組設定的環境路由原則會將製作者從預設環境路由到他們自己的開發人員環境中。 建立新的開發環境時，它們會自動與開發群組關聯並套用其規則。

• 共用開發群組支援包含具有多個製作者的專案的環境。

• UAT 群組包含用於在將資源提升到生產環境之前測試資源的環境。

• 生產群組包含託管應用程式、流程和其他供生產使用之成品的環境。

此建議的拓撲中缺少用於在開發、測試和生產環境之間自動升級的管線。 現在讓我們新增它們。

圖：與將管線託管環境連接到開發、測試和生產環境的管線相同的環境拓撲。

在修訂後的環境拓撲圖中，我們新增了一個管線託管環境和兩個管線。 一個管線將資源從開發移動到測試環境，然後再移動到生產環境。 將修改開發群組上的管線規則以使用此管線。 另一個管線將資源從共用開發環境移至測試，然後移至生產。 將修改開共用發群組上的管線規則以使用此管線。

這種基本環境策略提供了一個基礎，您可以在此基礎上建置其他使用案例，我們將在下面進行探討。

針對特定場景的環境策略

以下是可能需要合併到基礎租用戶環境策略中的一些常見使用案例。

控制哪些製作者可以建立開發人員環境

預設情況下，任何具有 Power Platform 進階授權、開發人員計劃授權或 Power Platform 租用戶管理員角色的人都可以從管理員入口網站建立開發人員環境。

在基礎環境策略中，環境路由可確保將製作者從預設環境定向到在指定群組中建立的新開發人員環境。 但是，製作者仍然可以手動建立未放置在環境群組中且未應用程式其規則的開發人員環境。

要最佳化哪些製作者符合環境路由的條件，請在路由設定中指定安全性群組。 設定安全性群組時，僅路由安全性群組的成員。 所有其他環境將回退到預設環境。

為進階製作者提供更大的靈活性

在基礎環境策略中，所有新的製作者環境都將路由到指定的開發人員環境群組。 通常，這組環境套用了一組相當嚴格的治理規則。

隨著製作者越來越進步，您可以允許他們要求存取更多功能。 您可以使用另一個環境群組來追蹤這些進階製作者，而不是將其從原始環境群組中移除並手動管理例外狀況。

圖：將更多有能力的製作者新增到放寬治理規則的環境中。

依照區域或業務單位組織開發人員環境

在目前環境路由的實作中，所有新的開發人員環境都是在單一環境群組中建立的。 如果要依照區域 (例如) 或業務單位組織製作者的開發人員環境，該怎麼辦？

使用路由將製作者導向到在指定群組中建立的新開發人員環境。 然後，您可以將其移動到基於區域、組織單位或其他條件的另一個群組，您可以在其中套用更精細的治理規則。

圖：環境路由在指定群組中建立開發人員環境後，將它們移至結構更具體的群組。

移動環境目前是手動操作，但當 Power Platform 管理連接器在將來的更新中支援組功能時，您將能夠自動執行它。

開發供企業使用的應用程式

組織中的某個團隊可能正在開發供整個企業使用的應用程式。 該團隊可能是 IT 導向的，也可能包括 IT 和業務使用者 (所謂的融合團隊)。

在最簡單的環境策略中，專案團隊在沙箱或生產類型的共用環境中建置。 開發人員環境類型不是支援多個製作者協作處理資源的最佳方式。 但是，製作者需要相互通訊，以避免在共用環境中產生衝突。

不需要專用的測試和生產環境。 該應用程式可以在託管多個應用程式的組織範圍內的測試和生產環境中進行測試和部署。

圖：在專用環境中開發的兩個企業應用程式，然後在與其他應用程式共用的環境中進行測試和部署

在更進階的變體中，每個製作者都有一個單獨的開發人員環境。 這樣做的好處是為製作者提供了更大的隔離，但可能會使整合環境中的單一工作組合更加複雜。 儘管隔離工作對於大型、複雜的團隊很有幫助，但它可能會給較小的團隊增加不必要的開銷，這些團隊可以在共用的開發環境中更成功地進行協作。

圖：在單一開發人員環境中處理同一應用程式的兩名製作者必須在共用整合環境中合併他們的工作，然後才能進入測試和生產環境。

此變體通常包含原始檔控制策略，每個開發環境都表示為原始檔控制中的一個分支，當準備好提升變更內容時，該分支將合併。 請務必考慮在初始發佈後如何維護應用程式。

例如，應用程式的 1.0 版可能正在生產中，而團隊則繼續建立 2.0 版。 您的環境策略必須支援修復 1.0 版中的問題，而 2.0 版的開發正在進行中。

圖：在開發、測試和部署 2.0 版時，必須修補、測試和部署 1.0 版。

環境群組提供了多種方法來處理此企業應用程式方案。 例如，這可以是單一應用程式群組，也可能涉及為每個開發階段使用單獨的群組。 在最佳做法一節中，我們將探討如何評估選項。

盡量減少使用開發人員環境

建議使用單一開發人員環境，為製作者提供工作區來建置低程式碼解決方案。 這可提供與其他製作者最高層級的隔離。 但是，如果您的組織希望最大程度地減少開發人員環境的數量，則多個共用環境比鼓勵製作者在預設環境中建置資產要好。

在此場景中，您將限制開發人員環境的建立，並建立共用的生產類型開發環境。 您可以依照組織結構、區域或其他條件組織這些共用環境。 環境群組可以包含它們，以確保它們套用一致的治理規則。 授予製作者在指派給他們的環境中建立低程式碼資產的權限。

安全性是環境策略的一部分

環境是安全使用 Power Platform 的關鍵組成部分。 它們表示租用戶中的安全性邊界，可幫助保護應用程式和資料。 作為環境策略的一部分，必須考慮安全要求如何影響租用戶中環境的數量和用途。

環境使您能夠在租用戶中建立多個安全性邊界來保護應用程式和資料。 透過對環境套用一組可設定的安全性功能，可以調整環境提供的保護以滿足必要的安全性保護。 對各個環境安全性功能的詳細討論超出了本文的範圍。 但在本節中，我們提供了有關如何將安全性視為租用戶環境策略一部分的建議。

租用戶層級的安全性

影響環境的大多數安全設定都是為每個環境單獨設定的。 但是，可以在租用戶層級進行一些變更，以幫助支援環境策略。

• 請考慮關閉 Power Platform 中的 [與所有人共用] 功能。 只有管理員才能與所有人共用資產。
• 請考慮保護與 Exchange 的整合。
• 套用跨租用戶隔離，以最大程度地降低租用戶之間資料外流的風險。
• 限制對系統管理員建立淨新生產環境。 限制環境建立 一般對維持控制有利：兩者可預防不負責的容量消耗，並減少要管理的環境數目。 如果使用者必須從中央 IT 請求環境，若系統管理員是閘道管理員，就能更容易明白使用者正在做的工作。

保全預設的環境

預設環境在支援 Microsoft 365 生產力自訂方面發揮作用。 但是，作為推薦的環境策略的一部分，最好盡量減少使用它。 相反，製作者應該在自己的隔離環境中建置。 雖然無法阻止對預設環境的存取，但可以最大程度地減少可在其中執行的操作。

首先，使用環境路由將製作者定向到他們自己的工作區，以建置低程式碼資產。

• 查看誰對預設環境具有管理員存取權，並將其限制為需要它的角色。

• 請考慮將預設環境重新命名為更具描述性的名稱，例如「個人生產力」。

  • 為預設環境建立資料外洩防護 (DLP) 原則，以阻止新連接器並限制製作者僅使用基本的、不可阻止的連接器。 將所有無法封鎖的連接器移至商務資料群組。 將所有的可封鎖連接器移至已封鎖資料群組。

  • 建立規則以阻止自訂連接器使用的所有 URL 模式。

保護預設環境應是當務之急。 將其與租用戶層級安全性一起執行，作為實施環境策略的第一步。 如果不實施這些措施，製作者就更有可能將資產新增到預設環境中。 隨著它們和環境路由的到位，鼓勵製作者使用自己的環境。

保護其他環境

如果您的組織與大多數組織一樣，則除了預設環境外，您還有多個環境。 每個所需的安全層級可能因其中包含的應用程式和資料而異。 開發人員環境的規則通常比生產環境的更寬鬆。 某些生產環境需要盡可能多的保護。

作為建立環境策略的一部分，請確定環境的常見安全性層級以及保護每個層級的功能，如以下範例所示。

圖：三層環境安全性以及適用於每層環境的安全性功能範例。

將您確定的安全性層級合併到您的群組策略中，並在可能的情況下使用規則在您的環境中啟用安全性功能。 在此範例中，規則限制指定為普通或中等安全性的所有環境中的共用。

使環境與資料外洩防護策略保持一致

資料策略是控制環境中低程式碼資源所使用的服務的整體治理工作的另一個重要部分。 環境群組沒有將 DLP 原則套用於環境的規則。 但是，您可以將 DLP 策略與環境群組保持一致。 例如，您可以建立與環境群組名稱相同或相似的 DLP 原則，並將其套用於該組中的環境。

詳細了解如何制定 DLP 策略。

圖：在此範例中，個人開發群組中的環境遵循阻止所有非 Microsoft 連接器的 DLP 原則。

為您的組織量身打造環境策略

在前面的部分中，我們描述了組織如何大規模管理環境的願景。 我們探討了基本功能、它們如何為環境策略做出貢獻，以及使用它們的基礎環境拓撲可能會是什麼樣子。 我們舉例說明了如何在此基礎上進行建置以適應常見場景。 由於每個組織都是獨一無二的，因此下一步是自訂滿足組織需求的環境策略。

從您所在的位置開始

無論您的組織剛接觸 Power Platform，還是已經使用它多年，第一步都是評估您的情況。 從較高的層面評估您的預設環境中的內容、您擁有的其他環境以及它們的用途。 通常，環境策略是作為在組織中建立 Power Platform 治理的一部分完成的。 如果是這種情況，您可能已經建立了為組織自訂策略所需的一些治理願景。

您應該了解的組織資訊包括：

• 如何在組織中使用 Power Platform，其願景是什麼？

• 由組織中的誰來建置低程式碼資產？

您需要做出一些關鍵決策：

• 製作者將如何獲得新的環境？

• 您是否會對環境進行分組，如果會，該如何分組？

• 不同環境需要哪些安全層級，環境如何分類？

• 您將如何決定應用程式、自動化或 Copilot 是使用現有環境還是新環境？

• 平台的基準功能與需要自訂治理程序的要求之間是否存在差距？

• 您將如何處理預設環境中的現有資產？

• 是否有租用戶和環境 DLP 原則策略，如果有，它如何與要建立的環境策略保持一致？

您可能還會在雲端作業模型中找到一些靈感，這些模型是 Azure 雲端採用框架的一部分。

使用平台填補空白

您經常會發現平台的內建功能無法滿足的要求。 在評估這些差距時，請考慮評估的以下可能結果：

• 差距是可以接受的。

• 可以使用 Power Platform 卓越中心入門套件來填補這一空白。

• 可以使用平台的功能 (例如 API、連接器和自訂應用程式或自動化) 來填補這一空白。

• 可以使用第三方工具或應用程式來填補空白。

CoE 入門套件

Power Platform 卓越中心入門套件和工具的集合，旨在幫助您的組織採用和支援使用 Power Platform。 入門套件的一個關鍵方面是它能夠收集有關環境中平台使用方式的資料，這在您制定和發展環境策略時會有所幫助。

例如，環境 Power BI 儀表板提供了一個概述，可幫助您了解租用戶中存在哪些環境、製作者以及它們包含哪些資產。

圖：Power BI 中的環境儀表板。

該套件包括起點或靈感，例如製作者可用於要求新環境的程序，以及對其環境的 DLP 原則進行變更。

圖：說明 CoE 入門套件中環境管理流程的流程圖。

平台可編程性和可擴展性

低程式碼平台的一大優點是，您可以使用它來建置應用程式、自動化、入口網站和副手，以幫助您管理它。 您還可以存取較低等級的工具，這些工具可用於填補支援環境策略的空白。

您可以使用以下連接器來建置應用程式和流程：

• Power Platform for Admins 和 Power Platform for Admins V2

• Power Apps for Admins 和 適用於製作者的 Power Apps

• Power Automate 管理

您可以使用 Power Platform 命令列介面 (CLI) 開發自動化，以幫助您管理環境生命週期以及與 DevOps 做法相關的其他任務。

使用適用於 Power Platform 建立者和管理員的 PowerShell Cmdlet，您可以自動執行許多監視和管理工作。

Power Platform DLP SDK 可以協助您管理租用戶和環境資料外洩防護原則。

最佳做法建議

在本文的這一節中，我們將根據基礎和特定場景一節中的建議進行建置。

新環境

作為制定策略的一部分，請考慮何時建立環境以支援工作負載。 評估必須平衡環境提供的隔離的好處 (例如，從安全角度來看，能夠比其他環境更有助於鎖定特定環境) 和缺點 (例如隔離會給嘗試跨應用程式共用資料的使用者帶來摩擦)。

在評估應用程式或自動化是否屬於其自己的環境中時，請分別評估應用程式生命週期的不同階段。 在開發過程中，與其他應用程式的隔離非常重要。 在單一環境中開發多個應用程式時，可能會建立跨應用程式相依性。

作為一般建議，如果可能，開發環境應該是單一用途的、一次性的，並且易於重新建立。

如果多個應用程式在生產環境中一起執行，則在同一環境中測試這些應用程式是有意義的。 事實上，如果不使用將在生產環境中執行的應用程式進行測試，則可能無法發現相容性問題。

評估應用程式的生產環境時，請記住以下注意事項：

• 應用程式是否與環境中的現有應用程式相容？ 例如，同時將 Dataverse 連絡人表用於不同用途的兩個應用程式可能不相容。 從 DLP 策略的角度來看，應用程式是否相容？

• 對資料分離是否有特殊的法規遵從性或法規要求？ 例如，資料的通知標準是否需要將其隔離？ 是否有要求資料不能包含在其他資料中？

• 資料是高度機密還是敏感？ 滲透是否會對組織造成金錢或聲譽損害？ 在單獨的環境中隔離可以更好地控制安全性。

• 應用程式是否需要來自其他應用程式的資料，並需要與它們並置？ 例如，兩個同時使用「客戶」表的應用程式應一起託管。 將它們分開會建立冗餘的資料副本，並在維護資料時產生問題。

• 資料是否需要區域資料駐留？ 在某些情況下，可以將相同的應用程式或自動化部署到區域環境，以確保適當的資料隔離和駐留。

• 大多數使用者是否與環境位於同一區域？ 如果環境位於 EMEA 中，但應用程式的大多數使用者都位於美國，則共用環境可能無法提供最佳效能。

• 是否需要新管理員，還是現有管理員就足夠了？ 如果新應用程式需要更多管理員，它們是否與現有管理員相容，因為他們所有人都對環境中的所有應用程式具有管理員權限？

• 應用程式的預期壽命是多少？ 如果應用程式或自動化是臨時的或短暫的，則將其安裝在具有更永久應用程式的環境中可能不是一個好主意。

• 使用者是否難以為不同的應用程式使用多個環境？ 這可能會影響從在行動裝置上尋找應用程式到必須從多個環境中提取資料的自助服務報告的所有內容。

容量

每個環境 (除了試用和開發人員環境) 初期的佈建將佔用 1 GB 的資源。 容量在租用戶之間共用，因此需要將其指派給需要它的人員。

保存容量的作法：

• 管理共用測試和生產環境。 有別於共用開發環境，測試和生產環境中的權限應限制為使用者對測試的存取權。
• 自動清理臨時開發環境並鼓勵將試用環境用於測試或概念驗證工作上。

環境群組

環境群組非常靈活，可讓您適應組織特有的各種使用案例。 以下是將環境分組作為環境策略一部分的幾種方法：

• 按服務或元件；例如，ServiceNow ServiceTree

• 開發、測試和生產

• 部門、業務群組或成本中心

• 依照專案

• 按位置，如果某個位置中的大多數環境具有類似的治理需求；這也有助於滿足類似的區域法規和法律合規性

圖：兩個不同部門的環境群組有不同的規則。

命名環境和群組

作為策略的一部分，請考慮如何命名環境和群組。

• 管理員、製作者和使用者可看到環境名稱。 通常只有管理員使用環境群組，但如果製作者具有建立環境的權限，則可能會遇到它們。

• 自動建立的開發人員環境遵循模式<使用者名稱>的環境；例如，「Avery Howard 的環境」。環境群組不會自動命名。

• 環境和環境群組名稱不需要是唯一的。 但是，為避免混淆，最佳做法是避免重複的名稱。

• 名稱限制為 100 個字元。 較短的名稱更易於使用。

建立一致的命名約定。

• 一致的名稱可幫助管理員了解組的用途以及它管理的環境，並使自動化和報告更容易。

• 一種常見的做法是在環境名稱中包含生命周期階段；例如，Contoso Dev、Contoso Test、Contoso Prod。目標是明確區分具有相同內容但用途不同的環境。

• 另一種常見做法是在環境專用於該使用者組時，在名稱中包含部門或業務單位。

• 例如，您可能決定所有環境或環境群組名稱必須遵循<生命週期階段>-<區域>-<業務單位跟隨>-<用途>模式 (產品-美國-財務-工資單)。

保持名稱簡短、有意義和描述性。

考慮您的組將如何隨著時間的推移而發展和成長，並確保您的命名約定能夠滿足這些不斷變化的需求。

避免在名稱中包含機密資訊。 有權存取管理中心的任何人都可以看到它們。

預設環境中的資產

您的環境策略應鼓勵 (或強制) 使用個人開發環境，以減少在預設環境中建立的內容。 但是，您應該查看製作者在預設環境中已經建立的內容，並評估如何處理每個使用案例。 是否適合保留預設環境，還是應將其移轉到另一個環境？

執行此衛生工作的一個關鍵部分是確定組織中廣泛使用的應用程式，這些應用程式應具有自己的受保護開發環境，該環境獨立於生產環境。

下表列出了範例使用案例和移轉動作。 最終，您的組織需要確定自己的使用案例以及與將資產保留在預設環境中相關的風險因素。 深入了解何時從預設環境中移動資產。

預設環境	移轉動作
Microsoft 365 個人生產力	保持預設環境。
最近使用過但未共用的單一製作者的資產	移轉到所有者的個人開發人員環境。
最近使用過且共用的單一製作者的資產	移動到所有者的個人開發人員環境，並從共用生產環境執行。
最近使用過且共用的多個製作者的資產	移轉到共用開發人員環境，並從共用生產環境執行。
最近未使用的資產	通知擁有者，如果沒有回應，請移至隔離區。

Dataverse for Teams 環境中的資產

Microsoft Dataverse for Teams 可讓使用者使用 Power Apps、Microsoft Copilot Studio 和 Power Automate 在 Microsoft Teams 組建自訂的應用程式、機器人和流程。 當團隊負責人將此功能新增至他們的團隊時，會建立一個具有 Dataverse for Teams 資料庫的 Microsoft Power Platform 環境，並連結至他們的團隊。 了解如何建立治理原則以管理 Microsoft Dataverse for Teams 環境。

Microsoft 內部環境策略

Microsoft 將自己視為“零客戶”，因為它在內部採用 Power Platform 來推動員工的自動化和效率。 以下數字可讓您了解 Microsoft 內部租用戶的使用規模。

• 每月 50,000 - 60,000 名活躍的製作者

• 超過 250,000 個應用程式和超過 300,000 個流程

• 超過 20,000 個環境

Microsoft 正在從以前的環境策略轉向使用最新 Power Platform 治理功能 (包括受控環境、環境群組和規則) 的策略。

作為增強策略的一部分，Microsoft 計劃根據開發類型、組織擁有權和風險層級將方案組合在一起。 由於整個公司正在建置太多內容，因此很難專注於每個可能的場景並針對每個使用案例進行自訂。 有太多的事情發生，它需要自動化並盡可能多地利用開箱即用的控制項。

Microsoft 正在將其 Power Platform 環境建置為三個更廣泛的類別，涵蓋七個使用案例，反映了不同程度的風險和控制：個人生產力、團隊協作和企業開發。

• 個人生產力 – 這適用於只想為自己建置應用程式或流程的人。 例如，他們不與其他人協作。 這些使用者被路由到個人開發環境，這些環境被鎖定。 這些環境使用受控環境功能，包括限制共用以及控制您可以在環境中執行的其他操作。 連接器和可用的操作在這組環境中受到嚴格限制。 這些環境的風險最小。 透過使用鎖定的個人環境，使用者可以避免更嚴格的合規性流程，只是為了建置個人生產力應用程式和流程。

• 團隊協作 – 這適用於為其團隊建置工具、自動化和流程的使用者。 對於此方案，Microsoft 鼓勵使用 Dataverse for Teams 環境。 生命週期、存取管理和資料標記在 Microsoft 365 群組層級進行控制，因此我們不必花時間從 Power Platform 治理的角度來管理這些使用者。 這種使用等級是風險範圍的下一步。

• 所有員工使用的企業開發/生產層級 – 這些人建置的工具或解決方案在整個公司中更廣泛地使用。 這些環境可能儲存最敏感的資料，使用更強大的連接器，並且需要更多的治理。 這被認為是最高風險，大部分精力都花在治理上。 ALM 是必要的，預先生產工作在沙箱環境中進行，並且在生產環境中只允許使用受控解決方案。 這些環境必須連結到 ServiceTree，後者會強制執行重複的安全性和隱私審查。 環境群組規則是根據 ServiceTree 中繼資料和信號自訂的。 許多環境群組和規則用於管理和控制這些環境。

Microsoft 的治理策略不是一成不變的。 它是流動和變化的，以適應新的挑戰並融入新 Power Platform 功能。

發展您的租用戶環境策略

在本文中，我們介紹了如何建立企業級租用戶環境策略。 無論您從何處開始，該策略都可以隨著您的業務而增長。 任何規模的組織都可以從我們提出的策略中受益；但是，對於已經處於更高規模的組織，好處更大。

制定租用戶環境策略不是一次性活動。 這是一個旅程。 隨著需求的變化，您應該隨著時間的推移發展您的策略。 您的策略還必須進行調整，以採用平台的新功能並應對新的挑戰。

像所有旅程一樣，不同的組織在途中的不同點加入，但都有相同的目的地。 以下是代表您的組織目前所處的位置的可能入口。

開始時間

您的組織正處於採用 Power Platform 旅程的起始階段。 這通常稱做綠地。 您將在最佳位置開始您的旅程，因為您不必擔心現有環境或新原則可能對組織中人員的使用 Power Platform 的方式產生的影響。 這是實施與產品功能和最佳做法一致的企業級環境策略的最佳時機。

瀏覽本文中概述的關鍵環境功能和策略。 花點時間了解設計和實施最適合您要求的租用戶環境策略所需的關鍵主題，以及注意事項和決策。

建立堅實的基礎對於避免陷入失控的局面至關重要，如果您一開始就沒有明確的策略，那麼以後可能會出現失控的情況。 規劃加速使用 Power Platform，但避免透過增加不必要的複雜性來過度設計環境策略。 請記住，這是一個旅程，您可以隨著需求的變化繼續發展您的策略。

Align

您的組織已正在執行一項環境策略，但該策略需要進行修改以與新 Power Platform 功能和最佳做法保持一致。 這通常稱做棕地。 與剛起步的組織不同，您需要考慮變更環境策略對組織的影響。

探索本文中概述的關鍵環境功能和策略，並評估改進策略以使其更符合要求的內容。 通常所需要的只是漸進式調整。 如果可能，請計劃推出變更，以最大程度地減少對使用者的影響。

以下建議是可以實施的常見增量變更：

• 若要在不影響現有環境的情況下開始對齊，請建立一個包含新開發人員環境的環境群組，並建立要如何管理它們的規則。 啟用環境路由以確保在指定群組中建立所有新的開發人員環境。

• 評估分組策略，並根據需要建立組以支援現有環境。 為這些組建立符合現有限制和例外的規則。 將現有環境移動到這些群組中。

• 確定在預設環境中建置和使用的熱門應用程式。 使用管線將其發佈到組織中使用者可以執行它們的生產環境。 然後，將這些應用程式的開發移轉到個人開發人員環境或專用開發環境。

• 建立一個計劃，以識別、隔離和刪除預設環境中未使用的資產。

增強

您正在執行的環境策略已符合最新功能和最佳做法，但您的組織希望新增更多控制項或功能。

向您的組織傳達您的環境策略

如果您的 Power Platform 使用者瞭解並與您想要實現的目標保持一致，您可以更成功地實施租用戶環境策略。 如果您只是在沒有任何溝通的情況下啟動策略，使用者會將這些變更視為限制，並尋找解決方法。

作為制定或改進策略的一部分，請決定如何告知使用者影響他們使用 Power Platform 的策略關鍵要素。 他們不需要您策略的所有技術細節，只需要有助於確保他們保持生產力的基本要素，例如：

• 預設環境的用途

• 他們應該在哪裡建置新的低程式碼資產

• 他們應該如何使用其個人開發人員環境

• 如何為特定業務部門或專案要求自訂環境

• 一般連接器使用策略，以及如何為其環境要求更多連接器權限

• 如何與他人分享他們建置的內容

• 例如決策者的責任：

  • 保持租用戶乾淨。 如果不再需要您的環境、應用程式和流程，請將它們刪除。 如果正在實驗，請使用測試環境。

  • 明智地共用。 小心切勿過度共用您的環境、應用程式、流程和共用的連接。

  • 保護組織資料。 避免將資料從高度機密或機密資料來源移到非保護或外部儲存體。

• 當您的策略發生變化時，請分享這些變更如何影響您的使用者，以便他們知道該採取哪些不同的做法

一個好的開始是在新增了新製作者的環境群組中啟用製作者歡迎內容。

圖：使用歡迎內容幫助新製作者取得成功。

與使用者通訊的另一種有效方法是建立內部 Power Platform 中心。 該中心可以成為人們協作專案、分享構想和發掘套用技術達成更多的新方式的地方。 您可以在中心共用與使用者相關的環境策略的更多詳細資訊。 了解如何建立內部 Power Platform 中心。

推論

在本文中，我們探討了旨在協助組織管理企業規模的 Power Platform 環境，並將其合併到租用戶環境策略中的功能。

隨著組織採用 Power Platform 並加速使用，組織對環境的需求可能會迅速變化。 您需要一種敏捷的方法來幫助您的環境策略跟上變化，並繼續滿足組織不斷變化的治理要求。

租用戶環境策略成功的一個關鍵因素是與製作者和使用者溝通並獲得他們的支援。 確保建置低程式碼應用程式和自動化的人員知道如何遵循組織的環境策略，以及他們應該在哪裡建置低程式碼資產。

每個組織採用 Power Platform 的旅程都是獨一無二的。 我們提出了一些想法來幫助您正確起步。 您的 Microsoft 客戶團隊或 Power Platform 合作夥伴可以協助您為組織建立更客製化的租用戶環境策略。

資源

• 環境群組
• 環境路由
• Power Platform 企業安全性白皮書
• 低程式碼安全性和治理
• ALM 中的解決方案概念