同じ Microsoft Intune テナント内に多数の管理者が存在する分散 IT 環境

多くの組織では、複数のローカル管理者を持つ 1 つの Microsoft Intune テナントがある分散 IT 環境を使用しています。 この記事では、単一のMicrosoft Intuneテナント内で独自のユーザーとデバイスを管理し、独自のポリシーを作成する複数のローカル管理者をサポートするためにMicrosoft Intuneスケーリングする 1 つの方法について説明します。

テナントに管理者の数を設定する必要があるかについては、正解も不正解もありません。 この記事では、多くのローカル管理者がいるテナントに焦点を当てています。

多数のローカル管理者が単一の Intune テナントに接続する組織では、分散型 IT が必要です。 たとえば、一部の学校システムは、システムまたは地域のすべての学校にローカル管理者がいるように編成されています。 場合によっては、この分散環境に、同じ中央システムまたは Microsoft Intune テナントにロールアップする 15 人以上の異なるローカル管理者が含まれる場合があります。

各ローカル管理者は、ローカル組織のニーズに合わせてグループを設定できます。 通常、ローカル管理者はグループを作成し、地理的な場所、部署、またはハードウェアの特性別に複数のユーザーまたはデバイスを整理します。 ローカル管理者は、これらのグループを使用して大規模なタスクも管理します。 たとえば、ローカル管理者は多数のユーザーにポリシーを設定したり、アプリを一連のデバイスに展開したりできます。

この記事で使用されている用語

• 最小権限: organizationへのアクセスを保護することは、重要なセキュリティ手順です。 Intune では、ロールベースのアクセス制御 (RBAC) を使用して、Intune 内の管理者ユーザーにアクセス許可を割り当て、さまざまなタスクを管理します。 最小特権アクセスの原則により、管理者は、管理を許可する必要があるユーザーとデバイスに対してのみ、割り当てられたタスクを実行できます。

• 中央チーム: 中央チームまたはグループには、テナント内のプライマリ管理者が含まれます。 これらの管理者は、すべてのローカル管理者を監督でき、ローカル管理者にガイダンスを提供できます。

• ローカル管理者: ローカル管理者はローカルであり、特定の場所のポリシーとプロファイルに重点を置いています。学校、病院など。

役割ベースのアクセス制御

organizationへのアクセスを保護することは、重要なセキュリティステップです。 Intune は、ロールベースのアクセス制御を使用して管理者に詳細なアクセス許可を付与し、organizationのリソースにアクセスできるユーザーと、それらのリソースで実行できる操作を制御します。 Intune RBAC ロールを割り当て、最小特権アクセスの原則に従うことで、管理者は管理を許可する必要があるユーザーとデバイスに対してのみ、割り当てられたタスクを実行できます。

次のセクションでは、 Central チーム と ローカル管理者の間でポリシー、プロファイル、アプリを管理するためのガイドラインと、各モデルの下でさまざまなモデルについて簡単に説明します。 モデルは次のとおりです。

• 部分的な委任モデル
• 完全な委任モデル
• 中央モデル
• 代理モデル
• ハイブリッド モデル

部分的な委任モデル

部分的な委任モデルでは、Central チームとローカル管理者の間のポリシー管理について、次のガイドラインが提案されます。

✔️ アクセス許可

• ポリシー、登録プロファイル、アプリの作成、更新、削除のアクセス許可は、中央チームが保持する必要があります。
• ローカル管理者には読み取りおよび割り当てのアクセス許可のみを付与します。

✔️ 再利用

• 共通で構成されるポリシー、登録プロファイル、アプリは、可能な限り再利用できるように、ローカル管理者が利用できるようにする必要があります。
• Microsoft Intune では、いくつかのカテゴリに分類される多くの一般的な構成が使用されます。 アプリ保護ポリシーに一覧表示されている推奨事項を確認します。
• オンボードしたローカル管理者は、既存のポリシーを確認し、必要に応じて再利用する必要があります。

✔️ 例外

• 中央チームは、必要に応じて、ローカル管理者に代わって新しいポリシー、登録プロファイル、アプリを例外として作成できます。 通常、これらの例外には、一意のパラメーターを必要とするあらゆる種類のプロファイルが含まれます。

この 2 つの分野で部分的な委任モデルが提案されています。

ローカル管理者のグループと割り当てのガイドライン: Microsoft Intune を使用したデバイス管理のグループを整理するときに、ローカル管理者が採用するベスト プラクティスにはどのようなものがありますか? 詳細については、「Intune のグループ化、ターゲット設定、フィルター処理: 最適なパフォーマンスのための推奨事項 - Microsoft Tech Community ブログ」を参照してください。

機能固有のガイドライン: 中央機関と、さまざまな機能に対する特定のアクセス許可を持つローカル管理者との間でポリシー/プロファイル/アプリをどのように管理するか。 詳細については、この記事の 機能固有のガイドライン を参照してください。

完全な委任モデル

完全な委任モデルでは、中央チームとローカル管理者の間のポリシー管理について、次のガイドラインが提案されます。

• 各ローカル管理者には、完全に管理する各オブジェクトを区切るために、独自のスコープ タグが必要です。
• ローカル管理者が作成、更新、または削除を行う必要がない場合は、ローカル管理者に読み取りと割り当てのアクセス許可を持つロールを付与し、フル アクセス許可を持つ他の役割を割り当てないようにします。 この方法を使用すると、スコープ タグ間でアクセス許可を組み合わせることを回避できます。
• ローカル管理者は、いくつかの一般的なポリシー、プロファイル、アプリを共有しながら、独自のポリシー、プロファイル、アプリを作成する必要がある場合があります。 このような場合は、特別なグループを作成し、共通のポリシー、プロファイル、アプリをこのグループに割り当てます。 このグループは、ローカル管理者の Intune RBAC ロール割り当てのスコープ (グループ) に含めないでください。この方法では、ローカル管理者に割り当てられた作成、更新、削除のアクセス許可が、これらの一般的なポリシー、プロファイル、アプリに適用されなくなります。

中央モデル

中央モデルでは、1 つのローカル管理チーム (親) が複数の子組織を管理します。 地域、部署、規模などの要素を使用して、子組織をグループ化できます。

• すべての管理されたローカル管理者をカバーするために使用されるスコープ タグは 1 つだけです。

• 可能であれば、ローカル管理チームはローカル管理者間で割り当てを標準化し、すべてのデバイスを割り当て用の単一の Microsoft Entra グループに配置する必要があります。 単一の Microsoft Entra グループを作成できない場合は、ローカル管理チームが別の Microsoft Entra グループを作成して、異なる割り当てを行うことができます。

• 別のローカル管理チームが組織を管理または移動する場合は、次の手順を実行する必要があります。

  • 組織のすべてのデバイスとユーザーは、元のローカル管理チームのスコープ内の一般的な Microsoft Entra グループから抽出する必要があります。

  • その組織に一意に割り当てられたすべてのポリシー/アプリ/プロファイルには、新しいローカル管理チームのスコープ タグを更新する必要があります。

代理モデル

委任モデルでは、複数のローカル管理者 (子) が、専任のローカル管理者によって管理され、また、中間ローカル管理チームによって監督されます。 親管理者と子管理者の両方に、管理境界を表す独自のスコープ タグがあります。

• 子管理者が 50 人未満の場合は、すべての子のスコープ タグを中間ローカル管理チームの RBAC ロールの割り当てに割り当てることで、中間ローカル管理チームにアクセス権を付与できます。
• 子管理者が 50 人を超える場合は、中間ローカル管理チームに、監督する子管理者のコレクション全体を表す独自のスコープ タグを付与する必要があります。
• 子管理者のスコープ タグの下に新しく作成されたポリシーには、中間ローカル管理チームが可視性を失わないように、適切なロールを持つユーザーによって追加された中間タグが必要です。

ハイブリッド モデル

ハイブリッド モデルでは、同じ親管理者がセントラル モデルと権限委譲モデルの両方で同時に使用されます。 このモデルには特別な推奨事項はありません。

機能固有のガイドライン

各機能のビジネス要件に応じて、このセクションに記載されているガイドラインでは、ローカル管理者ごとにポリシーを作成し、場合によってはオブジェクトの作成に必要なアクセス許可をローカル管理者に委任することをお勧めします。

アプリ保護ポリシー

アプリ保護ポリシーは、管理対象アプリで組織のデータがセキュリティ保護または保持されるようにするルールです。 詳しくは、アプリ保護ポリシーに関するページをご覧ください。

アプリ保護ポリシーのガイドラインは、次のように中央チームとローカル管理者に分けられています。

中央チーム - タスク

• organization 全体のセキュリティとビジネス ニーズを確認し、ローカル管理者向けの共通のアプリ保護ポリシーのセットを生成します。
• アプリ保護ポリシーを作成する前に、一覧表示されている推奨事項を確認して、適切なセキュリティ制御を特定します。
• 既存の共通ポリシーではビジネス要件を達成できない特定のビジネス ニーズに合わせて、必要に応じてローカル管理者がカスタマイズされたアプリ保護ポリシーを要求する方法を確立します。
• 各構成レベルと保護する必要がある最小限のアプリに関する具体的な推奨事項については、「 アプリ保護ポリシーを使用したデータ保護フレームワーク」を参照してください。

ローカル管理者 - アクセス許可とタスク

• ローカル管理者に読み取りと割り当てのアクセス許可を提供しますが、マネージド アプリの作成、更新、または削除のアクセス許可は付与しません。 このアクセス許可の構成により、独自のアプリ保護ポリシーを作成できなくなります。
• アプリケーション構成ポリシーの割り当ての読み取りアクセス許可と割り当てのアクセス許可をアプリに付与します。
• 管理対象デバイスと管理対象外デバイスの保護ポリシーが異なる場合にのみ、読み取りおよび割り当てのアクセス許可を付与します。 中央チームが両方に対して 1 つのポリシーのみを提供することを選択した場合、アプリケーション構成ポリシーは必要ありません。
• アプリケーション構成ポリシーが使用されている場合は、例外なくすべてのアプリ インスタンスにアプリケーション構成ポリシーを割り当てることをお勧めします。
• 一般的なアプリ保護ポリシーから選択します。 ローカル管理者は、必要な場合のみ、例外としてカスタム アプリ保護ポリシーを作成するように中央チームに要求できます。
• 詳しくは、アプリ保護ポリシーに関するページをご覧ください。

コンプライアンス ポリシー

Intune のコンプライアンス ポリシーは、準拠するためにユーザーとデバイスが満たす必要のある規則と設定を定義します。 デバイスを使用して組織のリソースにアクセスする前に、コンプライアンスが必要になる場合があります。 コンプライアンス ポリシーの詳細については、「コンプライアンス ポリシーを使用して、Intune で管理するデバイスのルールを設定する」を参照してください。

中央チーム

中央チームは、ローカル管理者が選択できる共通のコンプライアンス ポリシーを作成し、必要な場合にのみ例外ポリシーを作成する必要があります。 詳細については、「コンプライアンス ポリシーを使用して、Intune で管理するデバイスのルールを設定する」を参照してください。 ポリシーの作成には、カスタム コンプライアンス ポリシー スクリプトの作成が含まれます。これは、通常のコンプライアンス ポリシーと同じスケールの対象となるためです。

コンプライアンス ポリシーを作成する方法の詳細については、「Microsoft Intune でコンプライアンス ポリシーを作成する」を参照してください。

ローカル管理者

ローカル管理者に読み取りおよび割り当てのアクセス許可を提供しますが、コンプライアンス ポリシーの作成、更新、または削除のアクセス許可は付与しません。 読み取りおよび割り当てのアクセス許可を使用すると、中央チームによって作成された一般的なコンプライアンス ポリシーから選択し、それらをユーザーとデバイスに割り当てることができます。

デバイス構成

このセクションの内容

• デバイスの制限と一般的な構成
• リソース アクセス
• Windows 更新リング
• 機能の更新プログラム
• 品質更新プログラム

デバイスの制限と一般的な構成

• ローカル管理者に、自分のスコープ内で作成、更新、削除するアクセス許可を付与します。

• Microsoft Intune 管理センターのスケールを緩和するには、構成プロファイルの一覧で作成されたプロファイルではなく、設定カタログとセキュリティ ベースラインを最大限に使用します。

• 一般に、中央チームは構成の内容を一元的に監視し、可能であれば重複するプロファイルを共有プロファイルに置き換えるようにする必要があります。

リソース アクセス

完全委任モデルをお勧めします。

Windows 更新リング

• Windows 更新プログラム リングは一元的に管理することをお勧めします。 中央チームは、ローカル管理者の差異をサポートするために、必要なだけ一般的な Windows Update リング ポリシーを作成する必要があります。
• ローカル管理者は、独自の Windows 更新リングを作成しないでください。 多数の管理者に委任すると、オブジェクトの合計数が大きくなり、管理が困難になる可能性があります。 ベスト プラクティスは機能によって異なります。 詳細については、「 Windows Update リング」を参照してください。

機能の更新プログラム

完全委任モデルをお勧めします。

品質更新プログラム

完全委任モデルをお勧めします。

証明書

• 必要に応じて、中央チームを通じてアクセス許可を使用して、コネクタをオンボードおよびオフボードすることをお勧めします。 証明書の発行をサポートするために、各ローカル管理者のオンボード コネクタ。

• コネクタを更新または削除するアクセス許可をローカル管理者に付与しないでください。

アプリケーション

ローカル管理者に、そのスコープの範囲でアプリを管理するための完全なアクセス許可を付与します。

このセクションの内容

• Apple のボリューム購入プログラム

• Windows

• Android

詳細については、「 アプリの管理」を参照してください。

Apple のボリューム購入プログラム

現時点では、サポートされている一括購入プログラム トークンの数に関するスケールの問題はありません。 詳細については、「 アップロードできるトークンの数」を参照してください。

Windows

• ローカル管理者は、クロスプラットフォーム、基幹業務アプリ、および Web リンクの制限内で、必要に応じて Win32 アプリを作成できます。 詳細については、「 Win32 アプリ管理」を参照してください。

  注:

  ビジネス向け Microsoft Store は廃止されます。 Windows 11 以降では、プライベート ボリューム ライセンス アプリ用の新しいオプションがあります。 詳細については、「Windows 11 のプライベート アプリ リポジトリ」および「Windows 上の Microsoft Store との Microsoft Intune 統合の更新」を参照してください。

Android

• ローカル管理者は、既存のストア アプリから選択するか、中央チームに新しい Android ストア アプリを追加するよう依頼する必要があります。 ローカル管理者は、新しい Android ストア アプリを作成しないでください。 オブジェクトの総数が大きくなり、管理が困難になる可能性があります。

• ローカル管理者は、クロスプラットフォーム、基幹業務アプリ、および Web リンクの制限内で、必要に応じて Android 基幹業務アプリを作成できます。

• 中央チームは管理対象 Google Play アプリを追加する必要があります。

  • 中央チームは、テナントの国または地域で利用可能なマネージド Google Play アプリのみを表示できます。 中央チームが特定の国または地域でのみ利用可能なマネージド Google Play アプリを必要とする場合は、アプリ開発者と協力して正しく一覧表示されるようにする必要がある場合があります。
  • 中央チームは、プライベート アプリ、Web アプリ、コレクションなど、管理された Google Play アプリに関連するすべてのコンテンツを管理する必要があります。 たとえば、顧客が マネージド Google Play iframe を使用してプライベート アプリを公開することを計画している場合、中央チームが所有する 1 つの開発者アカウントで公開する必要があります。
  • 中央チームは、1 つのスコープ タグを Managed Google Play スコープ タグとして選択できます。 [管理対象 Google Play コネクタ] ページには特別なドロップダウンがあります。 スコープ タグは、中央チームがコンソールに追加した後、すべてのマネージド Google Play アプリに適用されますが、既に追加されているアプリには遡及的には適用されません。 中央チームがアプリを追加する前に スコープ タグを設定し 、各地域チームにそのスコープ タグを割り当てることを強くお勧めします。 そうしない場合、地域の管理者は管理対象の Google Play アプリを表示できない可能性があります。

• Zebra デバイスを除き、デバイスごとに 1 つの OEMConfig ポリシーのみがサポートされます。 Zebra デバイスでは、ポリシーの適用に時間がかかるため、ポリシーの数をできるだけ少なくすることをお勧めします。 たとえば、6 つのポリシーを割り当て、それらが互いに重なることを前提とすると、デバイスで作業を開始するのに 1 つのポリシーよりも約 6 倍の時間がかかります。

優先度の高い更新モードを使用したマネージド Google Play アプリの更新に関するスケールの問題の詳細については、Techcommunity ブログの「 Android Enterprise アプリを更新するためのベスト プラクティス」を参照してください。

登録プロファイル

このセクションの内容

• Windows Autopilot
• 登録状態ページ (ESP)
• Apple ビジネス マネージャー (ABM)
• Android Enterprise プロファイル
• 登録制限
• デバイス カテゴリ

Windows Autopilot

• ローカル管理者に、Windows Autopilot デバイスの読み取りおよび新しい Windows Autopilot デバイスのアップロードのアクセス許可を付与します。
• ローカル管理者は、Windows Autopilot プロファイルを作成しないでください。 多数の管理者に委任すると、オブジェクトの合計数が大きくなり、管理が困難になる可能性があります。 ベスト プラクティスは、機能領域によって異なります。 Windows Autopilot の詳細については、「Windows Autopilot を使用して Windows デバイスを Intune に登録する」を参照してください。

登録ステータス ページ

• ローカル管理者は、既存の登録ステータス ページ プロファイルから割り当てるものを選択するか、必要な場合にのみセントラル チームに例外プロファイルの作成を依頼する必要があります。
• ローカル管理者は、登録ステータス ページのプロファイルを作成しないでください。 多数の管理者に委任すると、オブジェクトの合計数が大きくなり、管理が困難になる可能性があります。 ベスト プラクティスは、機能領域によって異なります。 登録ステータス ページの詳細については、「 登録ステータス ページの設定」を参照してください。

Apple Business Manager

可能であれば、ローカル管理者に登録プロファイルの作成、更新、または削除のアクセス許可を付与しないでください。 ローカルの管理者に Apple Business Manager プロファイルを作成するアクセス許可が付与されている場合は、Windows Autopilot での作成、更新、削除のアクセス許可も付与されます。 ただし、ローカル管理者は Windows Autopilot プロファイルを作成しないでください。

多数の管理者に委任すると、オブジェクトの合計数が大きくなり、管理が困難になる可能性があります。 ベスト プラクティスは、機能領域によって異なります。 詳細については、「Apple Business Manager を使用して Apple デバイスを Intune に登録する」を参照してください。

Android Enterprise プロファイル

• 中央チームは、デバイス グループ化用にローカル管理者ごとに Android Enterprise 企業所有の専用デバイス登録プロファイルを作成する必要があります。
• 可能であれば、Android Enterprise デバイスの作成、更新、または削除のアクセス許可をローカル管理者に付与しないでください。 これらの制限により、ローカル管理者はテナント全体の Android Enterprise 設定とグローバル フル マネージド登録プロファイルを変更できなくなります。

登録制限

• 同じアクセス許可のセットが、デバイス構成と登録制限の両方を管理します。 デバイス構成の作成アクセス許可を付与すると、登録制限の作成アクセス許可も付与されます。 ただし、登録制限プロファイルを作成するアクセス許可をローカル管理者に付与しないでください。 代わりに、新しい登録制限プロファイルを作成しないように指示します。

• 登録デバイスの制限では、各ユーザーが登録できるデバイスの数を定義します。 登録デバイスの制限は、ローカル管理者が共有できるすべてのデバイス制限をカバーする必要があります。 詳細については、「 登録制限とは」を参照してください。

• 中央チームは、デバイス タイプの制限を可能な限り標準化し、新しい制限を追加する必要がありますが、これはローカル管理者が既存の制限を確認した後、特別な例外としてのみです。

デバイス カテゴリ

デバイス カテゴリ (デバイス>デバイス カテゴリ) 機能には、独自のアクセス許可ファミリがありません。 代わりに、そのアクセス許可は、[ 組織] で設定されたアクセス許可によって管理されます。 [ テナント管理] > [ロール] に移動します。 カスタム ロールまたは組み込みロールを選択し、[ プロパティ] を選択します。 ここで、アクセス許可を割り当てることができ、そのうちの 1 つは 組織です。

中央チームはデバイス カテゴリを作成できます。 ただし、ローカル管理者にデバイス カテゴリの作成、更新、または削除を許可するべきではありません。これには、組織のアクセス許可によって管理される他のテナントレベルの機能へのアクセス権が付与されるためです。

詳細については、「 デバイス カテゴリ」を参照してください。

エンドポイントの分析

• 中央チームは、ローカル管理者の変動をサポートするために必要なだけ一般的なエンドポイント分析ベースラインを作成する必要があります。
• 可能であれば、ローカル管理者が独自のエンドポイント分析ベースラインを作成しないでください。 多数の管理者に委任すると、オブジェクトの合計数が大きくなり、管理が困難になる可能性があります。 ベスト プラクティスは、機能領域によって異なります。
• 詳細については、「 エンドポイント分析の設定の構成」を参照してください。

関連コンテンツ

• Microsoft Intune で適切なターゲティング方法を選択する