こんにちは！tsuji です！
企業の端末管理では、攻撃対象となる範囲をあらかじめ狭めておくことと、万一マルウェアに感染した場合でも影響を最小限に抑えることの両方が重要です。ゼロトラストでも重視される「最小権限の原則」(ユーザーに必要最小限の権限だけを付与する考え方) に沿った対策として代表的なのが、端末利用ユーザーからのローカル管理者権限の剥奪です。
ただし管理者権限を剥奪すると、アプリやドライバーのインストールといった正当な操作まで止まってしまう問題が出てきます。
Intune の エンドポイント特権管理 (Endpoint Privilege Management、以下 EPM) は、この課題に対応する機能で、ローカル管理者権限を剥奪しつつも、必要な操作のときだけ一時的に管理者権限を付与できます。
この記事では、EPM の基本的な機能と導入の流れ、昇格ルールを作るときのポイントまでを紹介します。
EPM でできること 🔑
EPM を使うと、以下のような運用が可能になります。
- 標準ユーザーのまま、必要なアプリや操作だけを管理者権限で実行できる
- 誰がいつどのファイルを昇格したかのログが Intune に記録される
- ファイル ハッシュや発行元証明書でアプリを識別して、昇格対象を厳密に制御できる
EPM で昇格 (一時的に管理者権限を付与して実行すること) の対象にできるファイルは .exe / .msi / .ps1 の 3 種類です。実行ファイルやインストーラーだけでなく PowerShell スクリプトにも対応しているため、応用的にシステム周りの設定変更まで扱える可能性があります。
管理画面は エンドポイント セキュリティ > エンドポイント特権の管理 からアクセスできます。
端末側での操作
EPM が有効化された端末では、ユーザーはファイルを右クリックして [管理者特権での実行] を選択することで昇格操作を行います。EPM のエージェントがこの操作をフックし、昇格ルールや既定の昇格応答に従って処理されます。
EPM の構成要素 🧱
EPM は以下の 3 つの要素で構成されています。
昇格設定ポリシー (Elevation settings policy)
EPM を端末で有効化し、エージェントを配布するポリシー。昇格ルールで個別に定義されていないアプリに対する既定の動作 (既定の昇格応答) や、レポート収集の範囲もこのポリシーで設定します。
昇格ルールポリシー (Elevation rules policy)
個別のアプリに対して、どのように昇格を許可するかを定義するポリシー。ファイル ハッシュや発行元証明書などでアプリを識別し、「ユーザーが確認しました」「自動」「サポート承認済み」などの昇格の種類を選択します。
昇格レポート
端末上で発生した昇格操作を収集するレポート。どのユーザーがどのファイルを昇格したかを確認できます。
この 3 つを組み合わせて、「どの端末で EPM を有効化するか (昇格設定ポリシー) → 何を昇格できるようにするか (昇格ルールポリシー) → 実際の昇格操作を追跡する (昇格レポート)」というサイクルで運用していきます。
前提条件と知っておきたい制限 ⚠️
導入前に押さえておくべきポイントです。
- ライセンス：Microsoft Intune Suite または Microsoft Intune Endpoint Privilege Management (単体アドオン)
- 対応 OS：Windows 11 24H2 以降 / Windows 10 22H2 (ESU 適用済み)
- 対応する参加方式：Microsoft Entra 参加済み / Microsoft Entra ハイブリッド参加済み
- Microsoft Entra 登録済みは非対応
- SSL インスペクションは非対応
- EPM 関連エンドポイント (
*.dm.microsoft.com、*.events.data.microsoft.com) は復号検査の対象外にする必要あり - 参考：Microsoft Intune のネットワーク エンドポイント
- EPM 関連エンドポイント (
- ネットワーク共有やマップドライブ上のファイルは昇格対象にできない
- 昇格対象ファイルはローカルディスクに配置する必要あり
昇格の種類 🧭
昇格ルールで選べる「昇格の種類」は以下の 5 つです。
- ユーザーが確認しました：ユーザーが確認プロンプトに応じることで昇格。業務上の正当な理由の入力や Windows 認証の追加も可能
- サポート承認済み：ユーザーが申請 → 管理者が承認することで昇格 (公式でも既定の昇格応答として推奨されており、本記事で中心的に扱う運用パターン)
- 自動：ユーザー操作なしで透過的に昇格
- 現在のユーザーとして昇格する：サインイン中のユーザー自身のアカウントで昇格する
- 拒否：指定したファイルの昇格を明示的にブロック
導入の流れ 🛠
導入は、おおむね以下の 4 ステップで進めるとよいかと思います。
- 監査：現状把握のための設定ポリシー展開
- 業務タイプの整理：ユーザー層ごとの昇格ニーズ整理
- 昇格ルールの作成：必要なアプリに対してルールを定義
- ローカル管理者権限の削除：標準ユーザー化の実施
順番に見ていきます。
1. 監査 📊
最初に 昇格設定ポリシー を配布して EPM を有効化します。以下の設定値で配布すると、エンドポイントの昇格操作が Intune に記録されるようになります。
- エンドポイント特権の管理：有効
- 既定の昇格応答：未構成 (※ 昇格ルールに該当しないアプリの昇格要求はすべて拒否される動作になります)
- レポート用に昇格データを送信する：はい
- レポート スコープ：診断データとすべてのエンドポイントの昇格
エンドポイント セキュリティ > エンドポイント特権の管理 > [ポリシー] タブを開き、[+ 作成] を選択- プラットフォーム：Windows、プロファイル：Elevation settings policy を選択して作成
- ポリシー名を指定 (例：
EPM 設定ポリシー (監査)) - 構成設定で上記の値を指定
- スコープタグを選択 (必要に応じて)
- 対象のデバイスまたはユーザーグループを割り当て
- 確認して作成
ポリシー配布後、エンドポイント セキュリティ > エンドポイント特権の管理 > [レポート] タブ > 昇格レポート に昇格データが表示されるようになります。
2. 業務タイプの整理 👥
どのユーザー層にどのような昇格ニーズがあるかを整理します。ポリシーは業務タイプ (想定される業務・利用者像) の特性によって分けていくのがポイントです。
基本はサポート承認済みを軸にしつつ、業務特性に応じて自動やユーザーが確認しましたを組み合わせる形が運用しやすくなります。例として 2 つの業務タイプを挙げます。
一般業務ユーザー (事務・営業など)
アプリやドライバーのインストールといった場面でたまに管理者権限が必要になる程度で、頻繁に昇格を必要とする業務ではありません。
構成例：
- 既定の昇格応答を「サポートの承認を必須にする」にして申請ベースで運用
- よく使うアプリ (プリンタードライバーなど) は昇格ルールで個別に定義
- 昇格の種類は「ユーザーが確認しました」にし、発行元証明書 + 製品名 / 内部名で指定すると、バージョン更新時にハッシュを取り直さずに済む
開発者・研究者など
さまざまなツールやインストーラーを頻繁に扱うため、昇格対象のアプリを事前に把握しきるのは現実的ではありません。
構成例：
- 既定の昇格応答を「ユーザーの確認が必要」にして、昇格操作を記録しつつ素早く昇格できる運用に寄せる
3. 昇格ルールの作成 📝
決まりはありませんが、業務タイプに合わせて昇格ルールポリシーを作成し、必要なアプリに対して昇格ルールを定義していくのが良いかと思います。
運用イメージとしては、業務タイプごとに昇格ルールポリシーを 1 つ作成し、そのポリシーの中にアプリごとの昇格ルールを随時追加していく形になります。
昇格ルールポリシー「一般業務」
├── ルール：プリンタードライバー
├── ルール：XX インストーラー
└── ルール：...(随時追加)
昇格ルールポリシー「開発者」
├── ルール：VS Code インストーラー
├── ルール：Python インストーラー
└── ルール：...(随時追加)昇格ルールを作成する方法は大きく 2 つあります。
- サポート承認済みの昇格要求からルールを作成する (推奨)：ユーザーの昇格要求をきっかけに、申請ファイルの情報を引き継いでルールを作成する方法
- 手動で昇格ルールを作成する：ファイルのハッシュや証明書などを事前に取得してルールを作成する方法
監査フェーズで昇格設定ポリシーの既定の昇格応答を「サポートの承認を必須にする」で展開しておくと、ユーザーが昇格要求を送信したアプリの情報が エンドポイント セキュリティ > エンドポイント特権の管理 > [昇格要求] タブ に表示されます。この画面から、申請ファイルの情報をそのまま引き継いで昇格ルールを作成できます。
動作フローは以下のとおりです。
- ユーザーもしくは管理者が、昇格ルールを作成したいインストーラー等を対象端末で実行
[昇格要求] タブにほぼ即時にアプリ名が表示されるのでクリック- 画面上部の [+ これらのファイルの詳細を含むルールを作成] から昇格ルールを作成
- 業務タイプに対応する既存の昇格ルールポリシーに追加するか、業務タイプ単位で新規作成する
- 新規作成時は割り当てが未設定なので、必要に応じて割り当てを構成
- 既定ではファイル ハッシュで識別する構成になるため、必要に応じて発行元証明書ベースに変更 (製品名・内部名は
[昇格要求] タブの詳細画面から確認できます) - ユーザーまたは管理者の端末で、昇格ルールに沿って動作することを確認
サポート承認済みの運用フロー自体は、次章で詳しく紹介します。
管理者が明示的に昇格ルールを組みたい場合や、承認要求が頻繁に発生するアプリに対してあらかじめルールを用意しておきたい場合は、手動で昇格ルールを作成します。
エンドポイント セキュリティ > エンドポイント特権の管理 > [ポリシー] タブを開き、[+ 作成] を選択- プラットフォーム：Windows、プロファイル：Elevation rules policy を選択して作成
- ポリシー名を指定 (例：
EPM 昇格ルール (一般業務)) - 構成設定の特権管理で [+ 追加] → [インスタンスの編集] から昇格ルールを追加
- ルール名・昇格の種類・子プロセスの動作などを指定
- ファイル名・署名元 (発行元証明書) またはファイル ハッシュなどの検出属性を指定
- スコープタグを選択 (必要に応じて)
- 対象のデバイスまたはユーザーグループを割り当て
- 確認して作成
昇格ルールの検出属性の組み合わせなど、具体的なポイントは後述の「昇格ルールを作るときのポイント」で紹介します。
4. ローカル管理者権限の削除 🔒
業務タイプごとに昇格ルールが整備できたら、段階的にローカル管理者権限を削除していきます。
エンドポイント セキュリティ > アカウント保護 から ローカル ユーザー グループ メンバーシップ ポリシーを作成し、グループとユーザーのアクション を「追加 (置換)」に設定して、Administrators グループに残したいアカウントを明示的に指定することで、それ以外のユーザーのローカル管理者権限を一括で剥奪できます。残すアカウントには Windows LAPS で管理するローカル管理者や、グローバル管理者ロールの SID などが該当します。
具体的な構成手順は、過去のブログの「ローカル管理者グループ制限ポリシー構成」セクションをご参照ください。
サポート承認済みを中心にした運用 🙋
5 つの昇格の種類のうち、サポート承認済み は管理者が都度承認判断できる運用パターンです。公式ドキュメントでも、既定の昇格応答としての使用や、昇格ルールでカバーされていないアプリへの対応として、サポート承認済みの活用が推奨されています。EPM を導入する際は基本的にこの運用を軸に据える形が現実的です。
なぜサポート承認済みが基本になるのか
- ユーザー起点の申請のためアプリ情報がきちんと残る：前述のとおり昇格レポートではアプリ名が判別しづらいケースもありますが、サポート承認済みの申請では申請ファイルの情報 (名前・発行元・デバイス・ユーザーが入力した業務上の正当な理由) がそのまま承認画面に表示されるため、管理者が判断しやすくなります
- 未登録のアプリにも対応できる：昇格ルールを事前に整備しきれていない状態でも、申請ベースで運用できる
- ゼロトラストの「継続的な検証」の発想に合う：権限付与の判断を都度行える
- 承認要求から昇格ルールを直接作成できる：頻繁に承認するアプリは、承認要求の情報を引き継いで昇格ルールとして登録でき、運用の移行がスムーズ
運用フロー
サポート承認済みの運用は、以下の 4 ステップで進みます。
1. ユーザーが端末上で申請を送信
ファイルを右クリックし、[管理者特権での実行] を選択。表示されたプロンプトで業務上の正当な理由を入力して申請します。
2. 管理者が Intune 管理センターで承認判断
エンドポイント セキュリティ > エンドポイント特権の管理 > [昇格要求] タブ に申請が表示されるので、内容を確認して [承認] または [拒否します] を選択します。
3. ユーザー端末にトースト通知が届く
承認されると、ユーザー端末にトースト通知が届きます。
4. ユーザーが昇格実行
再度ファイルを右クリックし、[管理者特権での実行] を選択すると、管理者権限でファイルが実行できます。承認から 24 時間の間は有効です。
運用設計の考慮事項
サポート承認済みを中心に運用する場合、事前に設計しておきたいポイントがいくつかあります。
- 管理者への自動通知機能はない
[昇格要求] タブを管理者が定期的に確認する運用が必要- ユーザーから申請した旨を Teams などの別経路で管理者に連絡してもらう運用も有効
- 承認・拒否の結果は端末にトースト通知で伝わる が、ユーザーが通知を見落とす可能性や端末がシャットダウン中のケースもある
- 承認結果も Teams などの別経路でユーザーに伝える運用が安全
- 拒否時はユーザー端末に通知されない
- 公式ドキュメントによると「拒否の場合、Intune はユーザーに通知しません。管理者は、要求が拒否されたことをユーザーに手動で通知する必要があります」とあるため、拒否時の連絡フローは別途用意する必要あり
- 承認後は 24 時間有効
- 同じアプリでも 24 時間経過すると再申請が必要
昇格ルールを作るときのポイント 🧩
昇格ルールは「検出」と「昇格アクション」で構成されます。検出の強度が低いと意図しないファイルが昇格してしまうリスクがあるため、ルール作成時は検出に使う属性の組み合わせが重要です。
検出属性の基本的な使い分け
- ファイル ハッシュ (SHA-256)：最も強力。1 ビットでも変わると失効するので、更新頻度の低いファイルに向く
- 発行元証明書 + ファイルの署名で保護される属性 (製品名・内部名・説明など)：バージョン更新に強い。頻繁に更新されるベンダーアプリに向く
- ファイル名のみ：署名で保護されないため、他の属性と必ず組み合わせる
発行元証明書で指定する場合、証明書ファイル (.cer) は昇格ルール作成時に直接アップロードするか、あらかじめ 再利用可能な設定グループ として登録しておいたものを参照するかのどちらかで指定できます。同じ証明書を複数の昇格ルールで使う場合や、将来的な証明書の差し替えを見越す場合は、再利用可能な設定グループ (エンドポイント セキュリティ > エンドポイント特権の管理 > [再利用可能設定] タブ) の活用も可能です。
ファイル名にワイルドカードを使う
ファイル名には * (任意の文字列) と ? (任意の 1 文字) のワイルドカードが使えます。例えば VSCodeSetup-*.exe と指定すれば、VS Code のバージョン違いのインストーラーを 1 つのルールでカバーできます。
ただし、ファイル名部分 (拡張子を除く) のすべてがワイルドカードだけの指定は保存できない 仕様になっています。*.exe や ?*.exe のような極端に広範なルールは作成不可で、最低 1 文字は固定文字を含める必要があります。
EpmTools PowerShell モジュール
EPM が有効化されると C:\Program Files\Microsoft EPM Agent\EpmTools に EpmTools PowerShell モジュール が配置されます。ルール作成に必要なファイル属性の取得 や 適用済みポリシーの確認 などに使えます。
PowerShell で EpmTools のコマンドレットを使うには、まずモジュールをインポートします。PowerShell のセッションごとにインポートが必要なので、新しいセッションを開くたびに以下を実行してください。
Import-Module 'C:\Program Files\Microsoft EPM Agent\EpmTools\EpmCmdlets.dll'インポート後は、EpmTools のコマンドレットが使えるようになります。
以下は昇格ルールの材料 (ハッシュ・製品名・内部名・証明書チェーンなど) を一括取得する例です。”FilePath” はフルパスで指定し、”CertOutputPath” の証明書出力パスは事前にフォルダを作成する必要がある点に注意してください。
Get-FileAttributes -FilePath "C:\Path\To\App.exe" -CertOutputPath "C:\Temp\Certs\"
このほかにも、検証・トラブルシュートに役立つコマンドレットが用意されています。
例えば Get-Policies を使うと、端末に配信されている昇格ルールやクライアント設定の一覧を確認できます。ポリシー配布後、端末にルールが反映されているかを手早く確認したい場面で便利です。
Get-Policies -PolicyType ElevationRules -Verboseその他の各コマンドレットの詳細は以下の公式ドキュメントをご参照ください。
社内スクリプトを安全に配置する (intunewin 配布)
社内独自のアプリや独自スクリプトを EPM の昇格ルール対象とする場面では、コード署名が付与されていないケース が多く、名前だけ変更された別ファイルが昇格対象になってしまうリスクがあります。
公式ドキュメントでも以下のように推奨されています。
標準ユーザーが変更できない場所を指すファイル パスを使用することをお勧めします
ここでは、標準ユーザーからの書き込みを禁止するフォルダーを作成して、そこにスクリプトを配置する構成を紹介します。intunewin としてパッケージ化し、Win32 アプリとして配布します。
Deploy-ProtectedFolder.ps1 は以下のように動作します。
- スクリプト内で指定された配置先フォルダー (サンプルでは
C:\ManagedApps) を作成 - 標準ユーザーからの書き込みを禁止する ACL を適用
Deploy-ProtectedFolder.ps1と同じディレクトリにあるファイルを配置先フォルダーにコピー
intunewin パッケージに含めるファイル
├── Deploy-ProtectedFolder.ps1 ← 実行されるスクリプト
├── CompanyTool.exe ← 配置先にコピーされる
├── CustomScript.ps1 ← 配置先にコピーされる
└── InstallAgent.msi ← 配置先にコピーされる
↓ Intune から配布・実行
配置先フォルダー (サンプル：C:\ManagedApps)
├── CompanyTool.exe
├── CustomScript.ps1
└── InstallAgent.msiACL 設定のポイントは以下のとおりです。
- Administrators / SYSTEM：フルコントロール
- Users：読み取りと実行のみ (書き込み・変更・削除・リネームは不可)
- 親フォルダーからの継承は解除
スクリプト本体は以下で公開しています。
このスクリプトは引数によって 3 つのモードで動作します。
- 通常インストール (引数なし)：配置先フォルダーに上書きコピー
- 再インストール (
-Reinstall)：配置先フォルダーの既存ファイルを削除してから配置 - アンインストール (
-Remove)：配置済みファイルを全削除
コマンド
| 用途 | コマンド |
|---|---|
| インストール | powershell.exe -ExecutionPolicy Bypass -NoProfile -File ".\Deploy-ProtectedFolder.ps1" |
| アンインストール | powershell.exe -ExecutionPolicy Bypass -NoProfile -File ".\Deploy-ProtectedFolder.ps1" -Remove |
-Reinstall はインストール時に配置済みファイルを一度クリアしたいケース (ファイル削除や名称変更を含む更新時) でご利用ください。インストール処理
- インストール動作：System
検出規則
- 規則の種類：ファイル
- パス：
C:\ManagedApps - ファイルまたはフォルダー：配置対象のファイル名 (例：
CompanyTool.exe) - 検出方法：ファイルまたはフォルダーが存在する
このフォルダーに配置したファイルは標準ユーザーによる差し替えを防げるため、コード署名が付与されていない社内アプリや独自スクリプトを昇格対象にする際、意図しないファイルが昇格することを防ぐのに役立ちます。
保護フォルダの活用例として、ネットワーク設定変更スクリプトの配置を紹介します。
ncpa.cpl (ネットワーク接続) は、そのまま昇格してもネットワークアダプターのプロパティ画面 (COM CLSID で動作) に昇格が継承されないため、標準ユーザーのままではネットワーク設定を変更できません。
この課題への対処方法として、Mike's MDM Blog で参考になる解決策が紹介されています。公開されている PowerShell スクリプト (EPMNetworkHelper.ps1) は、CLSID を直接呼び出してネットワーク設定画面を開きます。このスクリプトを intunewin パッケージに含めて保護フォルダに配置し、昇格ルールの対象に登録することで、標準ユーザーがネットワーク設定を変更できるようになります。
昇格ルールの構成例 (最低限)
| 設定項目 | 値 |
|---|---|
| ルール名 | 任意 (例：ネットワーク設定変更) |
| 昇格の種類 | ユーザーが確認しました |
| 子プロセスの動作 | 昇格ルールを要求する |
| ファイル名 | EPMNetworkHelper.ps1 |
| ファイル パス | C:\ManagedApps |
| ファイル ハッシュ | Get-FileAttributes や [昇格要求] タブ から取得した SHA-256 |
本構成を実装すると以下のような動作になります。
- PowerShell スクリプト (
EPMNetworkHelper.ps1) を右クリック > [管理者特権での実行] をクリックします。
- 以下のようなポップアップが表示されるので、変更したいネットワークアダプターを選択して [Open Selected Adapter] をクリックします。
- UAC が表示されず [プロパティ] を開けるので、ネットワークアダプターの構成を変更することができます。
PowerShell スクリプト (.ps1) を昇格対象にする場合の前提
既定の Windows では PowerShell スクリプトの実行が制限されているため、.ps1 を EPM 経由で昇格する場合は、事前に実行ポリシーを RemoteSigned または Bypass に設定しておく必要があります。
Bypass は制約が緩いため、セキュリティ観点では RemoteSigned の構成をおすすめします。Intune で一括構成するには、設定カタログの利用がおすすめです。
デバイス > 構成を開き、[+ 作成] を選択- プラットフォーム：Windows、プロファイルの種類：設定カタログ を選択して作成
- ポリシー名を指定 (例：
PowerShell 実行ポリシー (RemoteSigned)) - 設定ピッカーで
Execution Policyを検索し、以下の設定を追加- 設定：
Turn on Script Execution(Device または User 向け) - 値：
Allow local scripts and remote signed scripts(= RemoteSigned)
- 設定：
- スコープタグを選択 (必要に応じて)
- 対象のデバイスまたはユーザーグループを割り当て
- 確認して作成
昇格ルールのちょっとした注意点
実機検証でわかった細かい挙動メモです。
- 昇格ルール側の「業務上の正当な理由」は英語のみ入力可：サポート承認済みでユーザーが入力する業務上の正当な理由は日本語で入力できますが、昇格ルールで事前定義する「業務上の正当な理由」欄は英語入力のみ受け付ける仕様でした
まとめ ✅
Intune の EPM について、基本的な機能から導入の流れ、応用までを紹介しました。
- EPM は、標準ユーザーのまま必要なときだけ管理者権限を付与する機能
- サポート承認済みを軸に、業務タイプの特性に応じて他の昇格の種類を組み合わせる
- 導入は「監査 → 業務タイプの整理 → 昇格ルール作成 → ローカル管理者権限の削除」の流れで進める
- 昇格ルールの作成は、サポート承認済みの昇格要求から作成する方法が運用の移行もスムーズで推奨
- 昇格ルールの検出は、ファイル ハッシュや発行元証明書を軸に属性を組み合わせる
- 導入後も、定期的にルールを見直していくのがおすすめ
まずは監査モードで現状把握をしてみるところから始めてみるのがおすすめです。
参考ドキュメント
- エンドポイント特権管理について | Microsoft Learn
- エンドポイント特権管理の展開の計画と準備 | Microsoft Learn
- エンドポイント特権管理を使用した昇格ルールの作成 | Microsoft Learn
- エンドポイント特権管理を使用してユーザーを管理者から標準ユーザーに移行する | Microsoft Learn
- Intune でのファイル昇格要求に EPM サポート承認を使用する | Microsoft Learn
- Microsoft Intune のネットワーク エンドポイント | Microsoft Learn
- Intune Endpoint Privilege Management tips and tricks – Mike's MDM Blog
