共用方式為

分散式 IT 環境，多位管理員共用同一 Microsoft Intune 租戶

許多組織使用分散式 IT 環境，擁有單一的 Microsoft Intune 租戶，並有多個本地管理員。 本文說明了一種擴展 Microsoft Intune 的方法，以支援多個本地管理員，他們管理自己的使用者、裝置，並建立自己的政策，全部都在單一 Microsoft Intune 租戶內。

租戶裡應該有多少管理員沒有絕對的對錯。 文章聚焦於擁有許多地方行政人員的租戶。

分散式 IT 在大量本地管理員連接單一 Intune 租戶的組織中是必要的。 例如，有些學校系統組織起來，系統內或區域內的每所學校都有地方管理員。 有時，這個分散式環境可能包含超過 15 位不同的本地管理員，他們會整合到同一個中央系統或 Microsoft Intune 租戶。

每位地方管理員都可以根據當地組織需求設立群組。 本地管理員通常會建立群組，並依地理位置、部門或硬體特性組織多個使用者或裝置。 本地管理員也會利用這些群組來大規模管理任務。 例如，本地管理員可以為多位使用者設定政策，或將應用程式部署到一組裝置。

本文所用術語

  • 最低權限：確保對組織的存取權是重要的安全步驟。 Intune 利用基於角色 (RBAC) ，在Intune內分配管理員權限以管理不同任務。 根據 最小權限 存取原則，管理員只能對應有權限管理的使用者和裝置執行指派任務。

  • 中央團隊：中央團隊或群組包含租戶中的主要管理員。 這些管理員可以監督所有在地管理員，並能為當地管理員提供指導。

  • 本地管理員：本地管理員是本地的，專注於其特定地點的政策與設定檔;學校、醫院等等。

角色型存取控制

確保對組織的存取權是重要的安全措施。 Intune 使用基於角色的存取控制，授權管理員細緻的權限，控制誰能存取組織資源，以及他們能如何運用這些資源。 透過指派 Intune RBAC 角色並遵守最小權限存取原則，管理員只能在他們應有權限管理的使用者與裝置上執行指派任務。

以下章節簡要介紹不同模型，並在每個模型下有管理政策、設定檔與應用程式的指引，適用於 中央團隊 與 本地管理員之間的管理。 這些模型包括：

  • 部分委派模型
  • 全委派模型
  • 中央模型
  • 權力下放模式
  • 混合模式

部分委派模型

部分委派模式提出了以下政策管理指引，用於中央團隊與地方管理員之間的管理。

✔️ 權限

  • 政策、註冊設定檔和應用程式的建立、更新及刪除權限應由中央團隊負責。
  • 只授權本地管理員讀取並指派權限。

✔️ 再利用

  • 常見設定的政策、註冊設定檔和應用程式應盡可能提供給本地管理員可重複使用。
  • Microsoft Intune 使用許多常見的配置，這些配置可分為幾種類別。 請檢視應用程式 保護政策的建議。
  • 作為本地管理員，他們應該檢視現有政策並視需要重複使用。

✔️ 例外情況

  • 中央團隊可代表本地管理員在需要時建立新的政策、註冊設定檔及例外應用程式。 通常，這些例外包括任何需要唯一參數的配置檔。

在以下兩個領域提出了部分委派模型：

本地管理員的群組與指派指引：本地管理員在組織 Microsoft Intune 裝置管理群組時，有哪些最佳實務可以採用？ 想了解更多，請參閱 Intune 分組、目標與篩選：最佳效能的建議 - Microsoft Tech Community 部落格。

功能專屬指引：政策、設定檔、應用程式在中央權威與擁有特定權限的本地管理員之間如何管理？ 欲了解更多資訊，請參閱本文中的 專題指引 。

全委派模型

完整委派模式提出以下政策管理指引，由中央團隊與地方管理員共同管理。

  • 每個本地管理員都應該有自己的範圍標籤，來區分他們完全管理的每個物件。
  • 當本地管理員不需要建立、更新或刪除時，就授予本地管理員一個有讀取和指派權限的角色，避免再給其他角色完全權限。 透過這種方法，你可以避免跨範圍標籤合併權限。
  • 有時本地管理員可能需要建立自己的政策、個人檔案和應用程式，同時分享一些共同的政策、個人檔案和應用程式。 在這種情況下，建立一個專門的群組，並將共用的政策、設定檔和應用程式指派給該群組。 此群組不應包含在任何地方管理員Intune RBAC職務分配的範圍 (群組) 中。此方法阻止了本地管理員所擁有的建立、更新與刪除權限，無法套用到這些共同的政策、設定檔與應用程式。

中央模型

在中央模式中，一個本地管理團隊 (家長) 管理多個子組織。 地理、事業單位或規模等因素都可以被用來分組子組織。

  • 只有一個範圍標籤來涵蓋所有受管理的本地管理員。

  • 如果可能，本地管理員團隊應將分配標準化，並將所有裝置放入單一的 Microsoft Entra 群組進行分配。 當無法建立單一的 Microsoft Entra 群組時，本地管理員團隊可以建立不同的 Microsoft Entra 群組來執行不同的指派。

  • 若由不同的本地管理團隊管理或遷移組織，必須採取以下步驟：

    • 組織所有裝置與使用者必須從原始本地管理團隊範圍內的共同 Microsoft Entra 群組中擷取。

    • 所有為該組織唯一指派的政策/應用程式/設定檔，都必須更新其範圍標籤以更新給新的本地管理員團隊。

權力下放模式

在分權模式下，多位地方管理員 (子管理員) 由專屬的地方管理員管理，並由中間的本地管理團隊監督。 父管理員和子管理員都有自己的範圍標籤來代表管理邊界。

  • 若子管理員少於 50 人，中介本地管理團隊可透過將所有子權限標籤分配給中介本地管理團隊的 RBAC 角色來獲得存取權限。
  • 若有超過 50 名兒童管理員，中間本地管理團隊應獲得專屬範圍標籤，以代表他們所監督的整個兒童管理員集合。
  • 在子節點管理員範圍標籤下新建立的政策，必須由具有適當角色的使用者新增中間標籤，以防止中間本地管理團隊失去可見性。

混合模式

在混合模式中，中央與分權模式同時使用同一位家長管理。 此型號沒有特別推薦。

專題指引

根據各功能的業務需求，本節提供的指引可建議你依照本地管理員建立政策，並可能將建立物件所需的權限委派給本地管理員。

注意事項

本節提供的指引並非涵蓋所有功能，僅涵蓋我們有特殊指示的領域。

應用程式防護政策

應用程式防護原則是確保組織資料保持安全或包含在受管理應用程式中的規則。 如需詳細資訊，請參閱 應用程式防護原則。

應用程式防護政策的指引分為中央團隊與本地管理員，具體如下：

中央團隊 - 任務

  • 檢視組織內的安全與業務需求，並為本地管理員產生一套通用的應用程式防護政策。
  • 在制定任何應用程式防護政策前，請檢視所列建議，以確定適當的安全控管措施。
  • 為本地管理員建立一套方法，以便在特定業務需求下，請求客製化的應用程式防護政策，以滿足現有通用政策無法達成的業務需求。
  • 關於各組態層級及必須保護的最低應用的具體建議，請參閱使用應用程式防護政策的資料保護框架。

本地管理員 - 權限與任務

  • 讓本地管理員可以讀取並分配權限，但不能在管理應用程式上建立、更新或刪除權限。 這種權限設定會阻止他們自行建立應用程式防護政策。
  • 提供讀取權限，並指派應用程式的設定政策權限。
  • 只有在受管理裝置與非受管理裝置有不同的保護政策時，才提供讀取與權限分配。 如果中央團隊選擇只提供一個政策給兩者，則不需要應用程式設定政策。
  • 若使用應用程式組態政策，建議將該應用程式組態政策無例外指派給所有應用程式實例。
  • 請從常見的應用程式防護政策中選擇。 本地管理員可請求中央團隊作為例外，且僅在必要時才會建立自訂的應用程式保護政策。
  • 如需詳細資訊，請參閱 應用程式防護原則。

合規政策

Intune 的合規政策定義了使用者與裝置必須遵守的規則與設定，才能符合規範。 在裝置用於存取組織資源之前，可能需要符合規定。 欲了解更多合規政策資訊，請參閱使用合規政策為你管理的 Intune 裝置設定規則。

中央隊

中央團隊應為本地管理員制定共同的合規政策，並僅在必要時制定例外政策。 欲了解更多資訊，請參閱使用合規政策為你管理的裝置設定規則Intune。 建立政策包括建立自訂的合規政策腳本，因為它們的規模與一般合規政策相同。

欲了解更多如何建立合規政策的資訊，請參閱在 Microsoft Intune 中建立合規政策。

本地管理員

提供本地管理員閱讀與指派權限，但不允許建立、更新或刪除合規政策的權限。 讀取與分配權限讓他們能從中央團隊建立的共同合規政策中選擇，並指派給使用者與裝置。

裝置設定

本節內容：

  • 裝置限制與一般配置
  • 資源存取
  • Windows 更新環
  • 功能更新
  • 品質更新

裝置限制與一般配置

  • 授權本地管理員在其範圍內建立、更新、刪除。

  • 請盡可能使用設定目錄和安全基線，而非在設定設定檔列表中建立的設定檔，以減輕 Microsoft Intune 管理中心的規模擴大。

  • 一般而言，中央團隊應嘗試集中監控設定內容，並在可能的情況下以共享設定檔取代重複的設定檔。

資源存取

建議採用 全委派模式 。

Windows 更新環

  • 我們建議 Windows 更新環由集中管理。 中央團隊應該建立盡可能多的通用 Windows 更新環政策，以支援本地管理員的變異。
  • 本地管理員不應該自己建立 Windows 更新環。 當你委託給大量管理員時，物件總數可能會變得龐大且難以管理。 最佳實務因功能而異。 更多資訊請參見 Windows 更新環。

功能更新

建議採用 全委派模式 。

品質更新

建議採用 全委派模式 。

憑證

  • 我們建議您透過中央團隊使用權限，根據需要安裝接線與離機接頭。 每個本地管理員都有內建連接器以支援憑證的發行。

  • 不要授權本地管理員更新或刪除連接器。

應用程式

授權本地管理員在應用程式範圍內的完整管理權限。

本節內容：

  • 蘋果量購計畫

  • Windows

  • Android

欲了解更多資訊，請參閱 管理應用程式。

蘋果量購計畫

目前，對於支持的批量購買計畫代幣數量，尚無規模問題。 更多資訊請參見「 我可以上傳多少代幣..

Windows

Android

  • 本地管理員應從現有的商店應用程式中選擇，或請中央團隊新增 Android 商店應用程式。 本地管理員不應該建立新的 Android 商店應用程式。 物品總數可能會變得龐大且難以管理。

  • 本地管理員可依需求在跨平台、業務線應用程式及網頁連結限制內建立 Android 業務線應用程式。

  • 中央團隊必須新增受管理的 Google Play 應用程式。

    • 中央團隊只能看到租戶所在國家或地區可用的託管 Google Play 應用程式。 如果中央團隊需要一個只在特定國家或地區可用的託管 Google Play 應用程式，他們可能需要與應用程式開發者合作，才能正確列出。
    • 中央團隊應管理所有與 Google Play 管理相關的內容，包括私人應用、網頁應用及收藏。 例如，如果客戶打算使用 Managed Google Play iframe 發佈私人應用程式，他們必須使用由中央團隊擁有的單一開發者帳號來完成。
    • 中央團隊可選擇單一範圍標籤作為受管 Google Play 範圍標籤。 它在 Managed Google Play 連接器頁面有一個特殊的下拉選單。 範圍標籤會在中央團隊將 Google Play 管理應用程式加入主控台後套用，但不會追溯適用於已新增的應用程式。 我們強烈建議中央團隊在新增應用程式前先 設定範圍標籤 ，然後分配給每個區域團隊該範圍標籤。 否則，區域管理員可能無法看到他們的 Managed Google Play 應用程式。

  • 每個裝置只支援一個 OEMConfig 政策，Zebra 裝置除外。 使用 Zebra 裝置時，我們建議您盡量少投保單，因為執行該保單的時間會累積。 舉例來說，如果你指派六個政策，假設它們會層層疊加，啟動裝置運作的時間大約是單一政策的 6 倍。

注意事項

在多個應用程式和群組設定高優先度更新模式時，務必格外謹慎與謹慎。 這是因為多種原因：

  • 雖然許多應用程式可設定為高優先權模式，但一次只能安裝一個應用程式更新。 一個大型應用程式更新可能會阻擋許多較小的更新，直到大型應用程式安裝完成。
  • 根據應用程式發布新更新的時間，如果應用程式同時發布，網路使用量可能會突然激增。 如果 Wi-Fi 在某些裝置上無法使用，行動通訊使用量也可能激增。
  • 雖然已經提到干擾使用者體驗，但隨著越來越多應用程式被設定為高優先更新模式，問題也在惡化。

關於使用高優先更新模式進行管理式 Google Play 應用程式更新的規模問題，請參閱 Techcommunity 部落格《 更新 Android 企業應用程式的最佳實務》。

招生概況

本節內容：

  • Windows Autopilot
  • ESP) (註冊狀態頁面
  • Apple 商務經理 (ABM)
  • Android 企業級設定檔
  • 招生限制
  • 裝置類別

Windows Autopilot

  • 授權本地管理員讀取 Windows Autopilot 裝置並上傳新的 Windows Autopilot 裝置。
  • 本地管理員不應該建立 Windows Autopilot 設定檔。 當你委託給大量管理員時，物件總數可能會變得龐大且難以管理。 最佳做法會因功能領域而異。 欲了解更多關於 Windows Autopilot 的資訊，請參閱使用 Windows Autopilot 將 Windows 裝置註冊至 Intune。

註冊狀態頁面

  • 本地管理員應從現有的註冊狀態頁面設定檔中選擇指派，或僅在必要時請求中央團隊建立例外設定檔。
  • 本地管理員不應該建立註冊狀態頁面的個人檔案。 當你委託給大量管理員時，物件總數可能會變得龐大且難以管理。 最佳做法會因功能領域而異。 有關註冊狀態頁面的資訊，請參閱 設定註冊狀態頁面。

蘋果商務經理

如果可能，本地管理員不應被授予註冊設定檔的建立、更新或刪除權限。 如果本地管理員有權限建立 Apple Business Manager 個人檔案，Windows Autopilot 也會賦予他們建立、更新和刪除的權限。 不過，本地管理員不應該建立 Windows Autopilot 設定檔。

當你委託給大量管理員時，物件總數可能會變得龐大且難以管理。 最佳做法會因功能領域而異。 欲了解更多資訊，請參閱使用 Apple Business Manager 將 Apple 裝置註冊至 Intune。

Android 企業級設定檔

  • 中央團隊應該為每個本地管理員建立 Android 企業擁有的專用裝置註冊設定檔，以便裝置分組。
  • 如果可能，本地管理員不應被授權在 Android 企業裝置上建立、更新或刪除權限。 這些限制阻止本地管理員修改租戶範圍的 Android Enterprise 設定以及全球完全管理的註冊設定檔。

招生限制

  • 同一組權限同時管理裝置設定與註冊限制。 當你授權裝置設定建立權限時，也同時授權了建立註冊限制的權限。 然而，本地管理員不應該被授權建立註冊限制設定檔。 相反地，指示他們不要建立新的註冊限制檔案。

  • 註冊裝置限制定義了每位使用者可註冊的裝置數量。 註冊裝置限制應該涵蓋所有本地管理員可共享的裝置限制。 欲了解更多資訊，請參閱 「註冊限制是什麼」。

  • 中央團隊應盡可能標準化裝置類型的限制，並新增限制，但僅限於在當地管理員審查現有限制後作為特殊例外。

裝置類別

裝置類別 (裝置>裝置類別) 功能沒有自己的權限家族。 取而代之的是，其權限由 組織中設定的權限所控制。 請前往 租戶管理 > 職務。 選擇自訂或內建角色，並選擇 屬性。 在這裡你可以指派權限，其中之一是 組織權限。

中央團隊可以建立裝置類別。 然而，本地管理員不應該被允許建立、更新或刪除裝置類別，因為這需要他們在 組織 權限中獲得權限，而組織權限則能讓他們使用其他由 組織 權限管理的租戶層級功能。

欲了解更多資訊，請參閱 裝置分類。

端點分析

  • 中央團隊應建立盡可能多的通用端點分析基線，以支援本地管理員的差異。
  • 如果可能，本地管理員不應該自行建立端點分析基線。 當你委託給大量管理員時，物件總數可能會變得龐大且難以管理。 最佳做法會因功能領域而異。
  • 欲了解更多資訊，請參閱 端點分析中的設定設定。
  • Last updated on