侵害された管理者アカウントから保護するには、Microsoft Intune の複数管理者承認アクセス ポリシーを使用して、変更を適用する前に 2 番目の管理者アカウントが変更を承認することを要求します。 この機能は、複数管理承認と呼ばれます。
マルチ管理承認を使用すると、デバイスのアプリやスクリプトなど、特定の構成を保護するアクセス ポリシーを構成できます。 アクセス ポリシーでは、保護対象と、それらのリソースへの変更を承認できるアカウント グループを指定します。
テナントのいずれかのアカウントを使用して、アクセス ポリシーによって保護されているリソースに変更を加えた場合、Intune は別のアカウントが明示的に承認するまで変更を適用しません。 アクセス保護ポリシーによって保護されたリソースが割り当てられている承認グループのメンバーである管理者のみが変更を承認できます。 承認者は、変更要求を拒否することもできます。
MAA の適用は、対話型 (委任) 管理アクションと、Microsoft Graph API を通じて行われるアプリケーション認証 (アプリ認証) API 呼び出しの両方に適用されます。 organization でサービス プリンシパル、オートメーション スクリプト、またはサード パーティ製アプリケーションを使用して Microsoft Graph API を介して Intune リソースを管理する場合、ターゲット リソースがアクセス ポリシーによって保護されている場合、それらの呼び出しも MAA によってインターセプトされます。 MAA と連携するように自動化を更新する方法の詳細については、「Microsoft Graph API での複数管理承認の使用」を参照してください。 特定のアプリを強制から除外するには、「 アクセス ポリシーからエンタープライズ アプリケーションを除外する」を参照してください。
ヒント
自動化によって行われた API 呼び出しに対する MAA の適用は、MAA アクセス ポリシーが既に構成されているテナントにのみ適用されます。 MAA を有効にしたり、テナントの登録を変更したりすることはありません。
Intune では、次のリソースのアクセス ポリシーがサポートされています。
- アプリ – アプリの展開に適用されますが、アプリの保護ポリシーには適用されません。
- コンプライアンス ポリシー - コンプライアンス ポリシーの作成と管理に適用されます。
- 構成ポリシー - 設定カタログを使用したポリシーの作成と管理に適用されます。
- デバイス アクション - デバイス アクションの ワイプ、 インベントリ終了、 および削除 に適用されます。
- ロールベースのアクセス制御 – ロールのアクセス許可、管理グループ、メンバー グループの割り当ての変更など、ロールの変更に適用されます。
- スクリプト – Windows を実行するデバイスへのスクリプトの展開に適用されます。
- テナントの構成 - デバイス カテゴリの作成、編集、削除など、管理に適用されます。
アクセス ポリシーを変更するには、2 番目の管理者の承認が必要です。 このリソースの種類は自動的に保護されるため、アクセス ポリシーを作成するときに選択可能なプロファイルの種類として使用することはできません。
アクセス ポリシーと承認者の前提条件
複数管理承認を使用するには、テナントに少なくとも 2 つの管理者アカウントが必要です。 MAA ワークフローには 3 つの異なる役割があり、それぞれに異なるアクセス許可要件があります。
管理者ライセンス
既定では、MAA ワークフローに参加する管理者は、アカウントに Intune ライセンスを割り当てている必要があります。 ライセンスのない管理者が MAA ワークフローに参加できるようにするには、[ ライセンスのない管理者へのアクセスを許可する] 設定を有効にします。
注意
この設定は元に戻すことはできません。 一度有効にすると、オフにすることはできません。 続行する前に、organization がこの制限を理解していることを確認してください。
この設定を有効にする前に、グループ メンバーシップの上限やアクセス権の変更が有効になるまでの時間など、重要な制限と動作の詳細について、「 ライセンスのない管理者」 を確認してください。
ロール 1: アクセス ポリシー マネージャー
アクセス ポリシーを作成および管理するには、次のいずれかのオプションを持つアカウントを使用します。
カスタム Intune ロール (推奨): 次の複数管理承認アクセス許可を含むカスタム ロールを使用します。
アクセス許可 説明 アクセス ポリシーの作成 新しい MAA アクセス ポリシーの作成 読み取りアクセス ポリシー 既存の MAA アクセス ポリシーを表示する アクセス ポリシーの更新 既存の MAA アクセス ポリシーを変更する アクセス ポリシーの削除 MAA アクセス ポリシーを削除する Intune 管理者
(Intune サービス管理者とも呼ばれる): このMicrosoft Entraロールは、Intuneへの完全な読み取り/書き込みアクセスを提供します。 これは特権ロールであるため、Microsoft では、このロールの代わりに、日常的なアクセス ポリシー管理に最小権限のカスタム Intune ロールを使用することをお勧めします。 詳細については、「Microsoft Entra の組み込みロール - Intune 管理者」を参照してください。
ロール 2: 承認者
他の管理者から送信された MAA 要求を承認または却下するには、アカウントが次の要件をすべて満たしている必要があります。
承認者グループのメンバーシップ: アカウントは、特定のリソースの種類のアクセス ポリシーに割り当てられている承認者グループのメンバーである必要があります。
Intune ロール アクセス許可: 承認者のアカウントには、承認するポリシーの種類に対してリソース固有の読み取りアクセス許可が必要です。 たとえば、デバイス削除操作の要求を承認するには、承認者に ManagedDevices/Read が必要です。 使用可能なアクセス許可の完全な一覧については、「 カスタム ロールのアクセス許可」を参照してください。
グループの RBAC ロールの割り当て: 承認者セキュリティ グループ自体をメンバー グループとして少なくとも 1 つの Intune ロールの割り当てに追加する必要があります。 承認者グループがロールの割り当てに追加されていない場合、承認者グループのメンバーはグループから定期的に削除されます。
重要
承認者グループには、次の 2 つの要件があります。
- セキュリティ グループである必要があります。 配布リスト、Microsoft 365 グループ、およびメールが有効なセキュリティ グループはサポートされておらず、承認者メンバーシップの解決にサイレントに失敗します。
- メンバー グループとして Intune の RBAC ロールに直接割り当てる必要があります。 個々のメンバーが保持する Intune ロールのアクセス許可は、他のグループまたは直接ユーザーの割り当てを介して、この要件を満たしていません。
- ユーザーは、割り当てられたグループの直接のメンバーである必要があります。 入れ子になったグループ メンバーシップは、信頼性の低い動作を引き起こす可能性があります。
ロール 3: 変更要求元
保護されたリソースの変更要求を送信し、承認済みの変更を完了するには、管理者は、実行している特定のアクションに対する標準の Intune RBAC アクセス許可が必要です。 最初の要求を送信し、別の管理者による承認後に [完了 ] を選択するという、同じアカウントで両方の手順が実行されます。たとえば、 MobileApps/Create でアプリを作成し、 RemoteTasks/Wipe でデバイスをワイプします。
注:
- 管理者は、承認者グループのメンバーであっても、自分の要求を承認できません。 別の管理者が要求を承認する必要があります。
- グローバル管理者または Intune 管理者アカウントによって送信された変更は、別の管理者によって承認される必要があります。
マルチ管理承認ポリシーとアクセス ポリシーのしくみ
管理者がアクセス ポリシーによって保護されている領域の新しいオブジェクトを編集または作成すると、[ 保存 + 確認 ] 画面にオプションが表示され、 ビジネス上の正当な理由として変更の説明を入力できます。
- ビジネス上の 正当な理由 は、変更の承認要求の一部になります。
- 変更を送信した管理者は、Microsoft Intune 管理センターで要求の状態を表示できます。[テナント管理]>マルチ 管理の承認に移動し、[自分の要求] ページを表示します。
変更が送信された後、承認者は [マルチ管理承認] ノードの [すべての要求] ページに移動するか、[テナント管理]>管理 [タスク] に移動して要求を管理できます。 どちらの場所にも、アクティブな要求または最近管理された要求の一覧が表示されます。 このビューには、要求をいつ、誰が送信したか、作成や割り当てなどの関連する操作の種類、ステータスなど、要求に関する詳細が表示されます。 要求を管理するには:
- 承認者は、要求の ビジネス上の正当な理由 リンクを選択します。 この操作により、[アクセス ポリシー要求] ウィンドウが開き、要求の [ビジネス上の正当な理由] フィールドに指定されたすべての詳細を含む、変更に関する詳細を表示できます。
- [アクセス ポリシー要求] ウィンドウで、承認者は [ 承認者のメモ ] フィールドにメモを入力し、[ 要求の承認 ] または [要求を拒否] のオプションを選択できます。 これらのメモは要求に追加され、変更を要求した個人が [ 自分の要求 ] ページで要求を確認するときに表示されます。 たとえば、リクエストが拒否された場合、承認者のメモを通じてリクエスト者に拒否の理由を戻すことができます。
- 要求を送信し、その承認グループのメンバーでもある個人は、[すべての要求] ページで自分の要求を表示できます。 ただし、独自の要求を承認することはできません。
マルチ管理承認でのレビュー エージェントの提案を変更する
変更レビュー エージェントがセットアップされ、実行が完了すると、[自分の要求] タブと [すべての要求] タブに、Windows PowerShell スクリプト要求の [エージェントの応答] 列が表示されます。 提案が使用可能な場合は、提案を選択して、マルチ管理承認ノードを離れることなく、その要求に対する変更レビューエージェントの承認ワークフローを開いて完了できます。
変更レビュー エージェントの提案は、 エージェントのプライマリ エクスペリエンス でも引き続き利用できます。 エージェントの詳細については、「 変更レビュー エージェントの概要」を参照してください。
変更が承認されると、Intune は要求された変更を処理し、オブジェクトを更新します。 Intune が要求を処理する間、その状態は [承認済み] として表示されることがあります。 元の要求元は要求を表示し、[ 完了] を選択して変更を開始する必要があります。 正常に処理されると、状態は [完了] に更新されます。
要求が 3 日以内に処理されない場合、期限 切れとなり、再送信する必要があります。 各状態の変更は、状態の変更後、最大 30 日間表示されます。
アクセス ポリシーを作成する
Microsoft Intune 管理センターにサインインし、[テナント管理]>マルチ 管理の承認>アクセス ポリシー] に移動し> [作成] を選択します。
[ 基本] で、[ 名前] とオプションの [説明] を入力します。 [ プロファイルの種類] で、利用可能なオプションから選択します。 各ポリシーは、1 つのプロファイルの種類をサポートします。
[ 承認者] で [ グループの追加 ] を選択し、このポリシーの承認者のグループとしてグループを選択します。 グループを除外するより複雑な構成はサポートされていません。
[ 除外] で、必要に応じて [エンタープライズ アプリケーションの追加 ] を選択して、このポリシーに対する MAA の適用からアプリ認証トークンを使用する特定のエンタープライズ アプリケーションを除外します。 除外されたアプリケーションは、承認ワークフローを経ずに保護されたリソースを変更できます。 詳しくは、 アクセス・ポリシーからエンタープライズ・アプリケーションを除外するを参照してください。
[ レビュー + 承認のための送信] で、基本、承認者、除外を含むポリシーの概要を確認します。 ビジネス上の正当な理由を入力し、[承認のために送信] を選択します。
次に、複数管理承認の承認アクセス許可を持つ別の管理アカウントを使用して管理センターにサインインし、新しいアクセス ポリシーを確認して承認します。
アクセス ポリシーを作成した最初の管理者アカウントで管理センターに再度サインインし、ポリシーを表示し、[ 完了] を選択して完了します。 Intune がこのポリシーを適用した後、保護されたプロファイルの種類の構成には複数の管理者の承認が必要です。
アクセス ポリシーからエンタープライズ アプリケーションを除外する
アクセス ポリシーを作成または編集するときに、特定のエンタープライズ アプリケーションをそのポリシーに対する MAA の適用から除外できます。 除外されたアプリケーションは、承認ワークフローを経ずに、保護されたリソースの種類を変更できます。
重要
除外は、アプリ認証 (アプリケーション認証) 呼び出しにのみ適用されます。 代理認証を使用して行われた呼び出しは、アプリケーションが除外されている場合でも、常に MAA の適用の対象となります。
警告
アプリケーションを除外すると、影響を受けるリソースの種類に対する MAA 保護がバイパスされます。 除外するたびに、承認ワークフローにギャップが生じ、除外されたアプリケーションが侵害された場合に悪用される可能性があります。 必要な場合にのみアプリケーションを除外し、除外リストを定期的に確認して、不要になったエントリを削除します。
次の詳細に注意してください。
- ポリシーごとのスコープ — 各除外は、それが構成されているアクセス ポリシーにのみ適用されます。 1 つのアクセス ポリシーの除外は、他のポリシーやワークロードには影響しません。
- 制限 — アプリの除外は、アクセス ポリシーあたり 50 アプリケーションの上限です。
- 承認が必要 - 除外の追加、削除、または変更には、他のアクセス ポリシーの変更と同様に、2 番目の管理者による承認が必要です。
- 監査ログ — 除外リストのすべての追加、削除、および変更アクションは、Intune 監査ログにキャプチャされます。
要求を送信する
複数管理承認が有効になっているときに要求を送信するには、通常のプロセスを使用してリソースを作成または編集します。
変更を保存する前に最後のページで、[ ビジネス上の正当な理由 ] フィールドに詳細を追加し、要求を送信します。 緊急のリクエストの場合は、既知の承認者のリストに連絡して、リクエストがタイムリーに表示されるようにすることを検討してください。
同じオブジェクトに対する要求が既に承認待ちの場合、要求を送信できません。 Intune は、この状況について警告するメッセージを表示します。
要求の状態を監視するには、Microsoft Intune 管理センターで、[テナント管理]>複数管理承認]>[自分の要求] に移動します。
[ 自分のリクエスト ] ページで選択し、[ 要求の キャンセル ] を選択すると、承認前に要求をキャンセルできます。
要求の承認
承認する要求を検索するには、Microsoft Intune管理センターで、[テナント管理]>複数管理承認>受信要求] に移動します。
要求の [ ビジネス上の正当な理由 ] リンクを選択して、要求の詳細を確認し、承認または拒否を管理できるレビュー ページを開きます。
詳細を確認した後、[ 承認者のメモ ] フィールドに関連する詳細を入力し、[ 要求の承認 ] または [要求の拒否] を選択します。
要求を承認した後、要求元は [完了] を選択する必要があります。 Intune は変更を処理し、状態を [完了] に変更します。完了時にコンソール通知を確認して、承認が成功した (または失敗した) ことを確認します。
承認が成功した (または失敗した) かどうかを確認するには、Intune 管理センターの通知を確認します。 承認が成功したか失敗したかを示すメッセージが表示されます。
ヒント
これらのタスクは、Intune 管理センターの集中管理タスク ペインから管理することもできます。
その他の考慮事項
Intune は、新しい要求が作成された場合、または既存の要求の状態が変更されたときに通知を送信しません。 緊急の変更要求を送信する場合は、それらの要求を承認するアクセス許可を持つ個人に連絡してください。
Intune 管理センターの [マルチ管理承認] ノードの [自分の要求] ページで、要求の状態を監視します。
オブジェクトの承認が既に保留中の場合、そのオブジェクトに対して新しい要求を送信することはできません。
保護されたリソースに対するすべてのアクションは保護されます。これには以下が含まれますが、これらに限定されません。
- 編集
- 作成する
- 変更
- 削除
- Assign
Intune 監査ログには、要求と承認プロセスに対するアクションが記録されます。 詳細については、「Intune アクティビティの監査ログ」を参照してください。
要求には、次のステータス条件を使用できます。
- 承認が必要 – この要求は承認者によるアクションが保留中です。
- 承認済 – この要求は Intune によって処理されています。
- 完了 – この要求は正常に適用されました。
- 拒否 – このリクエストは承認者によって拒否されました。
- 取り消された – この要求は、送信した管理者によって取り消されました。
ロール ポリシーの種類のアクセス ポリシーを作成するときは注意してください。 このポリシーの種類は、RBAC ロールとロールの割り当ての作成、更新、削除など、ロール関連のすべての変更を保護します。 MAA 自体が必要とする RBAC 割り当てなど、ロールを変更しようとすると、MAA 自体が必要とされる場合は、まず MAA の承認が必要です。 この要件により、MAA が機能するために必要な RBAC 割り当てを構成できないデッドロック状況が発生する可能性があります。
このデッドロックが発生した場合:
- [テナント管理]>[マルチ 管理の承認]>[アクセス ポリシー] に移動します。
- ロール ポリシーの種類に対して構成されたアクセス ポリシーを見つけて削除します。
- 変更が反映されるまで 3 分から 5 分待ちます。
- [ テナント管理>ロール ] に移動し、必要な RBAC ロールの割り当てを完了して、承認者グループをロールの割り当てに追加します。
- RBAC を正しく構成した後、必要に応じて ロール アクセス ポリシーを再作成できます。
この問題を回避するには、 ロール ポリシー タイプのアクセス ポリシーを有効にする前に、他のすべての MAA アクセス ポリシーを構成し、RBAC 割り当てが正しいことを確認します。