同じMicrosoft Intune テナント内の多数の管理者を含む分散 IT 環境

  • [アーティクル]

多くの組織では、複数のローカル管理者が 1 つのMicrosoft Intune テナントを持つ分散型 IT 環境を使用しています。 この記事では、Microsoft Intuneをスケーリングして、自分のユーザー、デバイスを管理し、1 つのMicrosoft Intune テナント内で独自のポリシーをすべて作成する複数のローカル管理者をサポートする 1 つの方法について説明します。 テナントに含めることができる管理者の数に関する正解や誤った回答はありません。 この記事では、多くのローカル管理者が存在するテナントに焦点を当てます。

分散 IT は、多数のローカル管理者が 1 つの Intune テナントに接続するシステムで必要です。 たとえば、一部の学校システムは、システムまたはリージョン内のすべての学校のローカル管理者が作成されるように構成されています。 場合によっては、この分散環境は、同じ中央システムまたはテナントにロールアップする 15 人以上の異なるローカル管理者Microsoft Intune可能性があります。

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

知る必要があるロール

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

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

ロールベースのアクセス制御

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

  • 部分委任モデル
  • 完全委任モデル
  • 中央モデル
  • デボルブモデル
  • ハイブリッド モデル

部分委任モデル

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

✔️ アクセス 許可

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

✔️ 再 利用

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

✔️ 例外

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

部分委任モデルは、次の 2 つの領域で提案されます。

ローカル管理者向けのグループと割り当てのガイドライン: Microsoft Intuneを通じてデバイス管理のグループを編成する際に、ローカル管理者が採用するベスト プラクティスの一部は何ですか? 詳しくは、「Intune のグループ化、ターゲット設定、フィルター処理: 最適なパフォーマンスのための推奨事項 - Microsoft Tech Community

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

完全委任モデル

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

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

中央モデル

中央モデルでは、1 つのローカル管理チーム (親) が複数の子組織を管理します。 地域、部署、サイズなどの要因は、子組織を関連付けることができます。

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

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

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

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

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

デボルブモデル

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

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

ハイブリッド モデル

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

機能固有のガイドライン

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

注:

このセクションで説明するガイダンスでは、すべての機能に対処するわけではありませんが、特別な手順がある領域についてのみ説明します。

アプリ保護 ポリシー

アプリ保護ポリシーは、管理対象アプリで組織のデータがセキュリティ保護または保持されるようにするルールです。 詳細については、「アプリ保護 ポリシー」を参照してください。

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

中央チーム - タスク

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

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

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

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

Intune のコンプライアンス ポリシーは、ユーザーとデバイスが準拠するために満たす必要があるルールと設定を定義します。 コンプライアンス ポリシーの詳細については、「 コンプライアンス ポリシー」を参照してください。

中央チーム

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

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

ローカル管理者

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

デバイス構成

このセクションの内容

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

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

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

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

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

リソース アクセス

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

Windows 更新リング

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

機能の更新プログラム

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

品質更新プログラム

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

証明書

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

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

アプリケーション

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

このセクションの内容

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

  • Windows

  • Android

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

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

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

Windows

Android

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

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

  • 中央チームは、マネージド Google Play アプリを追加する必要があります。

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

  • Zebra デバイスを除き、デバイスごとにサポートされる OEMConfig ポリシーは 1 つだけです。 Zebra デバイスでは、ポリシーを適用する時間が加算されるため、可能な限り少ない数のポリシーを用意することを強くお勧めします。 たとえば、6 つのポリシーを重ね合わせて重ね合わせて割り当てると、デバイスでの作業を 1 つのポリシーよりも約 6 倍長くかかります。

注:

多くの異なるアプリやグループで優先度の高い更新モードを設定する場合は、細心の注意を払ってください。 これは複数の理由で発生します。

  • 多くのアプリを優先度の高いモードに設定できますが、一度にインストールできるアプリの更新プログラムは 1 つだけです。 1 つの大規模なアプリ更新プログラムでは、大規模なアプリのインストールが完了するまで、多数の小さな更新プログラムがブロックされる可能性があります。
  • アプリが新しい更新プログラムをリリースするタイミングによっては、アプリのリリースが一致すると、ネットワーク使用量が急激に急増する可能性があります。 一部のデバイスで Wi-Fi が利用できない場合は、携帯ネットワークの使用量が急増する可能性もあります。
  • 破壊的なユーザー エクスペリエンスは既に説明されていますが、優先度の高い更新モードに設定されているアプリが増えるにつれて、問題は大きくなります。

優先度の高い更新モードを使用したマネージド Google Play アプリの更新に関するスケールの問題の詳細については、 こちらの Techcommunity の記事を参照してください。

登録プロファイル

このセクションの内容

  • Autopilot
  • [登録の状態] ページ (ESP)
  • Apple Business Manager (ABM)
  • Android Enterprise プロファイル
  • 登録制限
  • デバイス カテゴリ

Autopilot

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

登録ステータス ページ

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

Apple Business Manager

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

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

Android Enterprise プロファイル

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

登録制限

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

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

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

デバイス カテゴリ

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

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

詳細については、 デバイス カテゴリに関するページを参照してください。

エンドポイントの分析

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