Microsoft Intuneを自動化スクリプト、Azure Automation Runbook、またはサードパーティツールで管理している場合、2026年6月22日の週に展開されている最新の更新に注意を払う必要があります。
MicrosoftはMulti Admin Approval(MAA)が、Microsoft Graph APIを経由するアプリケーション認証(app-auth)のAPI呼び出しに承認ワークフローを強制するようになったことを発表しました。
これがエンタープライズITにとって何を意味するか、なぜ重要なのか、そして今すぐ取るべき対応について技術的に解説します。
変更内容
以前、IntuneのMulti Admin Approval機能は**対話型(委任)**の管理者アクションにのみ強制されていました。つまり、管理者がポータルでデバイスをワイプしたりスクリプトを変更したりする場合、2人目の管理者の承認が必要でした。しかし、自動化スクリプトやサービスプリンシパルがapp-onlyトークンを使用してGraph APIでまったく同じアクションを実行した場合、アクションは承認なしに素通りしました。
これはもはや当てはまりません。 app-onlyトークンを使用する自動化およびスクリプト呼び出しは、対象リソース(アプリ、スクリプト、デバイスアクションなど)がアクセスポリシーで保護されている場合、MAAによって傍受されるようになります。
自動化が適切な承認ヘッダーなしで保護されたワークロードを変更しようとすると、APIはHTTP 403 Forbiddenエラーを返します。
実世界での影響
この変更はUIとAPIの両方に「四人の目の原則」を強制し、重大なセキュリティの抜け穴をふさぎます。ただし、更新しなければ既存の自動化が壊れます。
- 壊れるRunbook: サービスプリンシパルを使用して保護されたIntuneリソースを変更するカスタムPowerShellスクリプトやPower Automateフローは、MAAポリシーがアクティブな場合、直ちに失敗します。
- サードパーティの混乱: エンタープライズアプリケーションを使用してIntuneを管理するツール(パッチ管理やプロビジョニングツールなど)は、明示的に除外しない限り、これらのブロックの対象になります。
- セキュリティ態勢の向上: 広範な権限(例:
DeviceManagementManagedDevices.ReadWrite.All)を持つ侵害されたサービスプリンシパルは、対話型の人間による承認ステップなしに大量のデバイスワイプを開始したり、悪意のあるスクリプトを展開したりできなくなります。
Intune管理者向けの即時対応
自動化をスムーズに継続しつつセキュリティを維持するため、次のステップを実行してください。
1. 保護されたワークロードを特定
Intune管理センターでテナント管理 > Multi Admin Approval > アクセスポリシーに移動します。現在MAAで保護されているプロファイルタイプ(アプリ、スクリプト、デバイスアクション)を確認し、これを自動化ワークフローと照合します。
2. 自動化スクリプトを更新
カスタムスクリプトを保守している場合、新しいMAAワークフローを処理するようにAPIリクエストを更新する必要があります:
- Base64エンコードされたビジネス妥当性を
x-msft-approval-justificationヘッダーに含める - 管理者がIntuneポータルで対話的にリクエストを承認するのを待つ(アプリケーションは自身のリクエストを承認できません)
x-msft-approval-codeヘッダーを使用して元のリクエストを再送信
3. エンタープライズアプリケーションの除外を構成
コードの更新が直ちに実行不可能な場合 — 例えばサードパーティベンダーツールに依存している場合 — MAAアクセスポリシーウィザード内の新しい除外タブを使用できます。これにより特定のエンタープライズアプリケーションやサービスプリンシパルをMAA強制から除外し、ワークフローが壊れないようにできます。
4. サービスプリンシパルを強化
MAAから除外するアプリケーションについては、それらを高権限エンティティとして扱うことが重要です。ワークロードアイデンティティのConditional Accessを使用してロックダウンし、クライアントシークレットの使用を制限して証明書ベース認証を優先し、使用状況を継続的に監査してください。
この変更に事前に対処することで、不可欠な運用自動化を停止することなく、テナントのセキュリティを大幅に強化できます。