GPOの「指定されたWindowsアプリケーションを実行しない」に powershell.exe を登録すると、対象ユーザーがエクスプローラー経由でPowerShellを起動する操作を制限できます。ただし、PowerShellをすべての起動経路で無効化する設定ではありません。これだけでEmotetなどのマルウェア対策が完了するとは判断できません。
この記事では、従来のGPO設定手順と画面例を残しつつ、制限できる範囲、適用確認、Officeマクロを悪用する攻撃に対して別途検討すべき対策を整理します。
グループポリシー（GPO）の作成と適用手順
「グループポリシーて何？」という方は「グループポリシーの作成と適用手順」Active Directoryをフル活用して端末を完全制御しちゃおう！！で細かい説明をしていますのでご参照ください。実例を用いて説明をしていますので、全くの初心者でもグルーポプリシーが自由に扱えるようになります。
最初に確認：このGPOは「完全な実行禁止」ではない
MicrosoftのDisallowAppsの説明では、この設定の対象はエクスプローラーのプロセスから起動されるプログラムです。ほかのプロセスからの起動まで一律に拒否するアプリケーション制御ではありません。
- できること：対象ユーザーの、エクスプローラー経由の指定アプリ起動を制限する。
- 保証できないこと：Office、サービス、スケジュールされた処理など、別の起動元を含めたPowerShellの実行阻止。
- 別の問題：
powershell.exeはWindows PowerShellの実行ファイル名です。PowerShell 7のpwsh.exeやISEなどを含む全環境の利用状況を、この1件だけでは管理できません。
そのため、一般ユーザーの誤操作を抑える補助策と、マルウェアによるコード実行を防ぐ対策を分けて設計してください。実行ファイル名を追加するだけで、すべての攻撃経路を防げるわけではありません。
GPOを設定する前の準備
- PowerShellを使用するログオン処理、業務アプリ、運用スクリプト、ヘルプデスク作業を確認します。
- 対象ユーザーを限定した検証用OUまたは既存の検証スコープで試します。最初からドメイン全体へ適用しないでください。
- 変更するGPOをバックアップし、元の設定、リンク先、適用対象を記録します。管理用の復旧経路を確保します。
以下はADドメインのGPOを管理する担当者向けの手順です。編集・リンク操作には適切な権限と、グループポリシー管理コンソール（GPMC）が必要です。「ユーザーの構成」の設定なので、通常は対象ユーザーが属するOU側の適用範囲を確認します。コンピューターのOUにリンクしただけでユーザーへ必ず適用されるわけではありません。ループバック処理を使用している環境は、その設計も確認してください。
GPOの設定
1．対象のGPOを編集する
グループポリシー管理コンソールで、検証対象に適用するGPOを右クリックして「編集」を選びます。グループポリシー管理エディターで次の場所を開きます。
ユーザーの構成
→ ポリシー
→ 管理用テンプレート
→ システム
→ 指定されたWindowsアプリケーションを実行しない下図は従来の管理画面の例です。OSや管理用テンプレートによって表示が多少異なる場合があります。
2．設定を有効にして実行ファイル名を登録する
「有効」を選び、実行を許可しないアプリケーション一覧の「表示」をクリックします。
「値」欄に powershell.exe と入力します。説明用の括弧は入力しません。「OK」で一覧を閉じ、設定画面も「OK」で保存します。
PowerShell 7やISEについても同じ操作制限が必要なら、導入済みの実行ファイル名と影響を確認して個別に検討します。pwsh.exe や powershell_ise.exe を追加しても、このGPO自体の「エクスプローラー経由のみ」という限界は変わりません。
適用結果と起動制限を確認する
1．対象ユーザーにGPOが適用されたか確認する
GPOのリンクが有効で、ユーザーが適用範囲に含まれていることを確認します。検証端末に対象ユーザーでサインインし、通常のポリシー更新を待つか、管理者の手順に従ってユーザーポリシーを更新します。
gpupdate /target:userこのコマンドはポリシーを更新する操作です。処理結果を確認し、サインアウトが求められた場合は作業を保存してから対応します。適用されたGPOの概要は、対象ユーザーのセッションで次のように確認できます。
gpresult /scope user /r一覧に該当GPOが出ないときは、リンク先、継承、セキュリティフィルター、ユーザーの所属、ドメイン接続を確認します。管理者の別アカウントで実行した結果を、対象ユーザーの結果と混同しないでください。詳細はGPMCの「グループポリシーの結果」などで確認します。
2．制限する経路で新規起動を試す
エクスプローラーから対象のWindows PowerShellを新しく起動して、制限メッセージが表示されるか確認します。以下は従来の画面例です。
この画面だけを見て「Officeからの悪用も防げた」と結論づけないでください。これは、そのユーザー・その起動方法で制限が働いたことを示す確認です。PowerShell 7、運用ツール、既存の業務フローへの影響は別途検証し、記録します。
戻す場合の注意
検証で問題が出た場合は、管理者が変更したGPOの設定を元の状態へ戻し、ポリシー更新後に再確認します。別の禁止アプリも同じ一覧で管理している場合は、一覧全体を無効にせず今回追加した対象だけを見直します。ほかのGPOが同じ設定を適用していると、1つ戻しただけでは解除されない場合があります。
Emotetなどのマルウェア対策として検討する設定
Officeマクロの実行を管理する
業務上マクロが必要でも、入手元不明の文書まで実行可能にする必要はありません。インターネット由来のOfficeファイルのマクロをブロックし、必要な業務マクロは管理された署名などを使って扱いを分けます。適用される既定動作はOffice製品・バージョン・ポリシーで異なるため、MicrosoftのOfficeマクロ管理ガイドで確認してください。
Word向けの設定場所については、既存のグループポリシー（GPO）でMicrosoft Wordのマクロを無効にする方法も参照できます。マクロ設定だけで、すべての感染経路を防げるという意味ではありません。
Officeからの子プロセス起動をASRで制御する
Officeから別のプログラムが起動される経路を制御したい場合は、Microsoft Defenderの攻撃面の縮小（ASR）ルール「すべてのOfficeアプリケーションによる子プロセスの作成をブロックする」が候補です。対象ルールのGUIDは d4f940ab-401b-4efc-aadc-ad5f3c50688a です。
このルールにはMicrosoft Defender Antivirusなどの前提条件があり、Officeのインストール場所に関する条件もあります。正当な業務マクロやアドインが子プロセスを起動する場合にも影響するため、まず監査モードで業務への影響を調べ、承認された範囲でブロックへ移行します。監査モード自体はブロックしません。
GPOから管理する場合の場所は「コンピューターの構成 → 管理用テンプレート → Windowsコンポーネント → Microsoft Defender Antivirus → Microsoft Defender Exploit Guard → 攻撃面の縮小」です。「攻撃面の縮小ルールを構成する」でルールGUIDと動作を指定します。監査は値 2、ブロックは値 1 です。既存ルールを消したり、全ルール共通の広い除外を安易に追加したりせず、MicrosoftのGPO設定手順と組織の変更管理に従ってください。
対象アプリと条件の詳細はASRルールの公式リファレンスで確認できます。
アプリケーション制御と実行ポリシーを区別する
実行できるアプリやコードを組織として制御する必要がある場合は、App Control for BusinessやAppLockerの適用を検討します。ユーザー別の制御、対応OS、運用要件などが異なるため、単純に同じものとして置き換えないでください。
また、App Controlによるスクリプト制御では、許可されていないPowerShellスクリプトが制約付き言語モードで動く場合があり、単に「すべて起動禁止」になるわけではありません。PowerShellに対する実際の制御動作を含めて設計・検証が必要です。
Set-ExecutionPolicy Restricted やGPOのスクリプト実行ポリシーだけを、PowerShellそのものの禁止策として扱うのも適切ではありません。Microsoftが説明する実行ポリシーは、スクリプト読み込み時の安全機能であり、セキュリティ境界ではありません。
まとめ
「指定されたWindowsアプリケーションを実行しない」は、対象ユーザーのエクスプローラー経由の起動を制限するための設定です。GPOの適用結果と起動経路を分けて確認し、完全なPowerShell無効化やEmotet対策として過信しないでください。マクロ管理、ASR、適切なアプリケーション制御を、必要な業務を維持できるよう検証しながら組み合わせることが重要です。
参考：グループポリシーの概要／gpupdate／gpresult（公式資料確認日：2026年10月20日）
コメント