AppLocker・App Control for Business(WDAC)と業務アプリ配布 ── 「実行制御」でブロックされる前に

「お客様のPCにインストールしたら、アプリが起動しない。ダブルクリックしても何も出ない」──受託開発したWindowsアプリの配布で、この相談が届く頻度が上がっています。原因を調べると、エラーダイアログすら出さずにアプリを止めていたのは、顧客側で導入が進むアプリケーション実行制御でした。

Windowsには、決めたアプリしか実行させないための仕組みが複数あります。AppLocker、App Control for Business(長くWDAC=Windows Defender Application Controlと呼ばれてきたもの)、そして個人向けのSmart App Controlです。セキュリティ対策の文脈では「導入する側」の解説が多いのですが、この記事は視点を変えて、アプリを作って配る側から整理します。自社の業務アプリが顧客環境でブロックされる典型パターン、ブロックされたときにどのログを見れば確定できるか、そして開発・配布側で先に打てる手です。あわせて、自社PCに導入を検討する情シス視点の要点もまとめます。

1. まず結論

• 実行制御は4つを区別して考えます。警告して選ばせるSmartScreen、ユーザー/グループ単位でルール制御するAppLocker、マシン全体を対象にするApp Control for Business、個人向けに自動で効くSmart App Controlです(2章の判断表)。
• 「AppLockerはEnterprise専用」という常識は古くなりました。KB 5024351以降、Windows 10 バージョン2004以降とすべてのWindows 11では、強制に特定のエディションが不要です。¹
• App Control for BusinessはWindows 10/11の全クライアントエディションとWindows Server 2016以降で使えます。マイクロソフトは、可能ならAppLockerではなくApp Controlの利用を推奨しています。²
• 配布側の対策の中心はコード署名です。exeだけでなくDLLを含む全バイナリとインストーラーに、一貫した発行者情報で署名します(5章)。Smart App Controlの普及で、未署名アプリは個人PCでも動かない場合が出てきました。³
• ブロックの証拠はイベントログで確定できます。AppLockerなら「AppLocker - EXE and DLL」のイベント8004、App Controlなら「CodeIntegrity - Operational」のイベント3077が本丸です(4章の判断表)。⁴⁵
• PowerShellスクリプトは「ブロック」ではなく「制限モードで実行」になることがあります。App Control環境ではポリシーに合わないスクリプトが制約付き言語モード(Constrained Language Mode)で動くため、「動くけれど一部の処理だけ失敗する」という分かりにくい壊れ方をします。⁵
• 導入する側は監査モードから始めます。AppLockerもApp Controlも、ブロックせずに「ブロックされるはずだったもの」を記録するモードがあり、イベント8003・3076がそれに当たります。⁴⁵

この記事の知識マップ

Windowsの実行制御は、警告するだけのSmartScreen、ユーザー・グループ単位で制御できるAppLocker、マシン全体に効くApp Control for Business、個人PCに自動で効くSmart App Controlの4つに分かれます。AppLockerとApp Controlは発行者・パス・ハッシュのルールで許可/拒否を判定し、マイクロソフトはセキュリティ機能として設計されたApp Controlの利用を推奨しています。配布側の対策の中心はコード署名で、DLLを含む全バイナリへの一貫した署名がなければ、更新のたびに発行者ルールが壊れたりハッシュルールが機能しなくなったりします。ブロックの有無はAppLockerイベントログとCodeIntegrity - Operationalログで確定でき、導入側はまず監査モードで一巡分のイベントを集めてから強制に切り替えるのが定石です。

flowchart LR
    accTitle: AppLocker・App Control for Business・Smart App Controlの知識マップ
    accDescr: AppLocker、App Control for Business(旧WDAC)、Smart App Control、SmartScreenという4つの実行制御の違い、それぞれが使うルール(発行者・パス・ハッシュ)、コード署名との関係、ブロックの確認に使うイベントログ、監査モードから強制への移行、配布側でアプリがブロックされる典型パターンの関係を示す図
    applocker["AppLocker"]
    app_control_for_business["App Control for Business(旧WDAC)"]
    publisher_rule["発行者ルール"]
    path_rule["パスルール"]
    hash_rule["ハッシュルール"]
    managed_installer["マネージドインストーラー"]
    intelligent_security_graph["Intelligent Security Graph(ISG)"]
    appidsvc["Application Identityサービス(AppIDSvc)"]
    windows_update["Windows Update"]
    intune["Microsoft Intune"]
    group_policy["グループポリシー"]
    smart_app_control["Smart App Control"]
    code_signing_cert["コード署名証明書"]
    ecc_signature["ECC(楕円曲線)署名"]
    hsm_key_storage["HSM/トークンでの秘密鍵保管"]
    code_signing_timestamp["コード署名のタイムスタンプ"]
    certificate_expiry["証明書の期限切れ"]
    unsigned_binary["未署名バイナリ"]
    blocked_app_startup_failure["実行制御によるアプリ起動失敗"]
    smartscreen["Windows SmartScreen"]
    applocker_log["AppLockerイベントログ"]
    codeintegrity_log["CodeIntegrity - Operationalログ"]
    constrained_language_mode["制約付き言語モード(Constrained Language Mode)"]
    audit_mode["監査モード"]
    writable_folder_execution["書き込み可能フォルダでの実行"]
    applocker -->|"利用する"| publisher_rule
    applocker -->|"利用する"| path_rule
    applocker -->|"利用する"| hash_rule
    app_control_for_business -->|"利用する"| publisher_rule
    app_control_for_business -->|"利用する"| path_rule
    app_control_for_business -.->|"利用する"| managed_installer
    app_control_for_business -->|"利用する"| intelligent_security_graph
    applocker -->|"前提とする"| appidsvc
    applocker -.->|"前提とする"| windows_update
    app_control_for_business -->|"の後継"| applocker
    app_control_for_business -->|"で構成できる"| intune
    app_control_for_business -.->|"で構成できる"| group_policy
    applocker -->|"で構成できる"| group_policy
    applocker -->|"で構成できる"| intune
    smart_app_control -.->|"前提とする"| code_signing_cert
    smart_app_control -.->|"両立しない"| ecc_signature
    publisher_rule -->|"両立しない"| ecc_signature
    publisher_rule -->|"前提とする"| code_signing_cert
    code_signing_cert -.->|"前提とする"| hsm_key_storage
    code_signing_cert -.->|"利用する"| code_signing_timestamp
    code_signing_timestamp -->|"軽減する"| certificate_expiry
    unsigned_binary -.->|"原因になり得る"| blocked_app_startup_failure
    unsigned_binary -.->|"両立しない"| smart_app_control
    applocker -.->|"原因になり得る"| blocked_app_startup_failure
    app_control_for_business -.->|"原因になり得る"| blocked_app_startup_failure
    smart_app_control -.->|"原因になり得る"| blocked_app_startup_failure
    smartscreen -.->|"原因になり得る"| blocked_app_startup_failure
    blocked_app_startup_failure -->|"で確認できる"| applocker_log
    blocked_app_startup_failure -->|"で確認できる"| codeintegrity_log
    app_control_for_business -.->|"原因になり得る"| constrained_language_mode
    audit_mode -->|"より先に行うべき"| applocker
    audit_mode -->|"より先に行うべき"| app_control_for_business
    managed_installer -.->|"で構成できる"| intune
    writable_folder_execution -.->|"原因になり得る"| blocked_app_startup_failure
    path_rule -->|"用いるのは非推奨"| writable_folder_execution
    hash_rule -.->|"原因になり得る"| blocked_app_startup_failure

図の実線は常に成り立つ関係、破線は条件付きの関係です(成立条件は詳細ページの各関係の説明に記載)。関係すべての一覧(全36件、根拠・確度つき)と主要概念の定義は知識マップ詳細ページにまとめています。データ: JSON-LD / Turtle

2. 4つの仕組みを区別する

まず全体地図です。名前が似ていて混同されやすいので、「誰が」「何の単位で」「どう効くか」で分けます。

2.1. SmartScreen ── 唯一「警告」で止める仕組み

SmartScreenは「評判の悪いものを警告する」仕組みで、既定ではユーザーが突破できます。ただし管理された環境では、警告の突破自体を禁止するポリシーが有効になっていることがあり、その場合はSmartScreenも実質的にブロックとして働きます(この話は「Windows SmartScreenとコード署名」で扱いました)。

配る側から見たSmartScreenの特徴は、ルールを書く管理者がいなくても既定で効いている点と、ブロックの理由がポリシーではなく「評判」である点です。したがって対処も他の3つとは違い、顧客に許可ルールを書いてもらうのではなく、署名と評判の蓄積で解くことになります。以降の2.2〜2.4は、警告ではなくブロックする仕組みです。

2.2. AppLocker ── ユーザー単位で制御できる古参

AppLockerはWindows 7で導入された実行制御で、コード署名証明書の属性(発行者)、署名メタデータ由来のファイル属性(元のファイル名・バージョン)やハッシュ、ファイルのパスに基づいてルールを定義します。ポリシーはコンピューター全体にも、特定のユーザー・グループにも適用できます。²

エディション要件は誤解が多いところです。現在のドキュメントは明快で、KB 5024351以降、Windows 10 バージョン2004以降とすべてのWindows 11では、AppLockerポリシーの強制に特定のエディションを必要としません。古いバージョン(2004より前のWindows 10、Windows Server 2019を含む)では、グループポリシー配布での強制はEnterpriseとServerエディションのみ、MDM配布なら全エディション、という従来の制限が残ります。¹

「Proで何ができるのか」を、ルールを作れるかと作ったルールが実際に効く(強制される)かの2つに分けて整理すると、次のようになります。この2つが別物であることが、古い常識が生き残っている原因です。¹

「Pro環境では作成すらできない」と誤解されがちですが、作成はどのエディションでもできます。かつて分かれていたのは強制のほうで、しかもMDM配布なら当時からProでも強制できました。適用できるルールの種類(実行可能ファイル・Windowsインストーラー・スクリプト・DLL・パッケージアプリ)はエディションで変わりません。¹ なお、どのエディションであっても、Application Identityサービス(AppIDSvc)が動いていなければルールは評価されません(6章)。

ただしAppLockerには重要な但し書きがあります。マイクロソフト自身が、AppLockerはセキュリティ機能としてのサービス基準(MSRCのservicing criteria)を満たさないと明記しています。つまり回避手法が見つかっても、それ自体はセキュリティ脆弱性としては扱われません。²

2.3. App Control for Business ── セキュリティ機能としての本命

App Control for Businessは、Windows 10で「Device Guard」「構成可能なコード整合性(WDAC)」として登場した仕組みの現在の名称です。ポリシーはマシン全体に適用され、デバイスの全ユーザーに影響します。ルールの根拠にできるのは、署名証明書の属性、ファイル属性やハッシュ、マイクロソフトのIntelligent Security Graph(ISG)による評価、インストールを開始したプロセス(マネージドインストーラー)、ファイルのパス(Windows 10 1903以降)、起動元プロセスです。²

こちらはMSRCのサービス基準で定義されたセキュリティ機能として設計されています。利用条件も広く、Windows 10/11の任意のクライアントエディション、またはWindows Server 2016以降でポリシーを作成・適用できます。配布はIntuneなどのMDM、Configuration Manager、PowerShellが使えます。グループポリシーでも配布できますが、Windows Server 2016/2019で動くシングルポリシー形式に限られます。²

どちらを使うべきかについて、マイクロソフトの指針は明確です。App Controlで実装できるならそちらを使うべきで、App Controlは改善が続いているのに対し、AppLockerはセキュリティ修正は受けるものの新機能は追加されていません。AppLockerが適するのは、古いWindowsが混在していて同じポリシーを配りたい場合と、共有PCでユーザー・グループごとに異なるルールが必要な場合、およびApp Controlの補完としてユーザー単位の制限を足す場合です。²

2.4. Smart App Control ── 個人PCに「勝手に」入っている実行制御

Smart App ControlはWindows 11の個人利用者向けの保護機能です。アプリを実行しようとすると、クラウドのセキュリティサービスがそのアプリの安全性を予測できるか確認し、悪意があると判定されたアプリや、有効な署名がなく信頼を確認できないアプリをブロックします。新しいPCでは評価モードから始まり、その利用者に向くかどうかをWindowsが自動判定して有効・無効が決まります(開発者のように頻繁にブロックされそうな利用者では自動でオフになります)。³

配る側にとっての意味は単純です。企業管理下にないPC、つまり小規模事業者や個人事業主の顧客のPCにも、実行制御が既定で入っている時代になったということです。管理者が誰もポリシーを書いていなくても、未署名のアプリはブロックされ得ます。マイクロソフトの開発者向けの案内も、ブロックを避けるために有効な証明書でアプリに署名することを挙げています。³

3. あなたのアプリがブロックされる典型パターン

受託開発・パッケージ配布の現場で実際に踏むパターンを、原因別に並べます。

共通する構図は、「実行を許可する側の根拠(署名・パス・ハッシュ)を、配る側が安定して提供できていない」ことです。顧客の情シスが発行者ルールを書きたくても、署名が一部のバイナリにしかなければハッシュルールで書くしかなく、ハッシュルールはあなたが更新版を出すたびに壊れます。ブロックの責任は導入側にあるように見えて、ルールを壊れやすくしている原因は配布側にある、というケースが実際には多いのです。

4. 何が起きたかをログで確定する

「起動しない」の原因が実行制御かどうかは、推測ではなくイベントログで確定できます。見る場所は2系統です。

4.1. AppLockerのイベント

イベントビューアーの アプリケーションとサービス ログ\Microsoft\Windows\AppLocker 配下を見ます。⁴ 初めて開く方向けに、たどり方を書いておきます。

イベントビューアー(スタートメニューで「イベントビューアー」、またはファイル名を指定して実行で eventvwr.msc)> アプリケーションとサービス ログ > Microsoft > Windows > AppLocker > EXE and DLL / MSI and Script / Packaged app-Deployment / Packaged app-Execution

英語環境では Applications and Services Logs > Microsoft > Windows > AppLocker です。GUIをたどらずに済ませたい場合は、PowerShellを管理者で開いて次の1行で読めます(顧客に依頼するときも、この行を渡すのがいちばん速い方法です)。

# 直近24時間のAppLockerのブロック(8004)と監査(8003)を取り出す
Get-WinEvent -FilterHashtable @{
    LogName   = 'Microsoft-Windows-AppLocker/EXE and DLL'
    Id        = 8003, 8004
    StartTime = (Get-Date).AddDays(-1)
} | Format-List TimeCreated, Id, Message

イベントには、対象ファイルのパス、許可かブロックか、適用されたルールの種別(パス・ハッシュ・発行者)とルール名、ルールのユーザー/グループのSIDが記録されます。⁴ ただし読み方に注意が要ります。許可リスト型の運用では、ブロックの多くは「どれかの拒否ルールに一致した」のではなく、どの許可ルールにも一致しなかった暗黙の拒否です。この場合、8004で確定するのは「ブロックされた事実と対象ファイル」までで、ルール名は手がかりになりません。明示的な拒否ルールに当たったときはルール名がそのまま原因ですが、暗黙の拒否では「どの許可ルールが足りないのか」を適用中のポリシー側と突き合わせて探すことになります。

4.2. App Control for Business(WDAC)のイベント

App Controlのブロックは別の場所、アプリケーションとサービス ログ\Microsoft\Windows\CodeIntegrity\Operational に出ます。exe・DLL・ドライバーの制御はこちら、MSI・スクリプト・COMの制御は先ほどの「AppLocker - MSI and Script」ログに出る、という分担です。⁵

イベントビューアー > アプリケーションとサービス ログ > Microsoft > Windows > CodeIntegrity > Operational(英語環境では Applications and Services Logs > Microsoft > Windows > CodeIntegrity > Operational)

# App Controlのブロック(3077)・監査(3076)と、対応する署名情報(3089)をまとめて見る
Get-WinEvent -FilterHashtable @{
    LogName   = 'Microsoft-Windows-CodeIntegrity/Operational'
    Id        = 3076, 3077, 3089
    StartTime = (Get-Date).AddDays(-1)
} | Sort-Object TimeCreated | Format-List TimeCreated, Id, Message

「どちらの仕組みでブロックされたのか分からない」状態のときは、この2つのログを同じ時刻範囲で並べて突き合わせるのが確実です。

3089は見逃されがちですが重要です。ファイルの署名ごとに1件生成され、未署名ファイルなら署名数0の1件が出ます。「署名したはずなのに未署名扱いされている」「古い証明書の署名が残っている」といった配布側の不備は、ここで確定できます。⁵

スクリプトの挙動には特有の注意があります。イベント8029は「スクリプトがブロックされた」ことを示しますが、実際の強制はスクリプトホスト側の挙動に委ねられており、たとえばPowerShellはポリシーに合わないスクリプトを完全に止めるのではなく制約付き言語モード(Constrained Language Mode)で実行します。⁵ .NETオブジェクトの生成が広く制限されるため、「スクリプト自体は動いたが、途中の1行だけ失敗する」という中途半端な壊れ方をします。アプリにスクリプトを同梱している場合、この壊れ方を知らないと調査が長引きます(スクリプト署名の実務は「PowerShellの実行ポリシーとスクリプト署名」)。

なお、「AppLocker - MSI and Script」ログはWindows Server Coreエディションには存在しません。⁵ サーバー配置のアプリで調査するときは頭に入れておいてください。

5. 配る側の対策 ── ルールを「書きやすい」アプリにする

ブロックされてから対処するのではなく、顧客の情シスが安定した許可ルールを書ける状態で配るのが本筋です。やることは多くありません。

1. 全バイナリにAuthenticode署名する。exeだけでなく、自社ビルドのDLL、インストーラー(MSI/セットアップexe)、同梱スクリプトまで。発行者ルールは署名メタデータ(発行者・製品名・ファイル名・バージョン)を根拠にするので、署名されていれば「この発行者のこの製品はバージョン問わず許可」という更新に耐えるルールを書いてもらえます。² 証明書は信頼された認証局が発行した、RSAベースのものを選んでください。自己署名証明書や社内CAの証明書は、そのCAを信頼していない顧客のPCでは通用せず、Smart App Controlでもサポートされません。またSmart App Controlの署名チェックはECC(楕円曲線)署名に対応していないため、ECC証明書で署名すると個人PCでは未署名同然の扱いになり得ます。⁶ 同じ制約はApp Controlにもあり、署名者ベースのルールはRSA(最大4096ビット)のみ対応で、ECDSA署名のファイルは発行者ルールで許可できません(署名情報の3089イベントに VerificationError = 23 が出ます)。⁷ 「ECCのほうが新しくて強い」と考えて選ぶと、実行制御の観点では逆効果になります。
2. タイムスタンプを必ず付ける。証明書の期限が切れても署名の有効性が保たれます。署名の実務手順とSmartScreenとの関係は別記事にまとめています。
3. 発行者情報と、ファイルのバージョンリソースを安定させる。証明書を更新するとき、サブジェクト(組織名)が変わると発行者ルールが壊れます。社名表記・証明書の取得元を変える場合は、顧客への事前通知をリリースノートに含めてください。もうひとつ見落とされがちなのは、発行者ルールの「製品名」「元のファイル名」「バージョン」が証明書ではなく各ファイルのバージョンリソース(アセンブリ情報)から取られることです。これらのフィールドを空にしたり、リリースごとに製品名や実行ファイル名を変えたりすると、署名者が同じでも製品・ファイル単位に絞ったルールは壊れます。
4. 実行ファイルの置き場所を標準に寄せる。Program Files配下にインストールし、実行時に %TEMP% や %APPDATA% へexe/DLLを展開して起動する設計をやめます。書き込み可能な場所で実行する設計は、パスルール型の環境と根本的に相性が悪いためです。
5. 自動更新の設計を見直す。更新プログラム自体も署名し、更新が「署名済みバイナリを署名済みバイナリで置き換える」閉じた流れになるようにします。IntuneやConfiguration Managerで配布される場合、顧客側がその配布エージェントをマネージドインストーラーとして構成していれば、インストーラー経由で入ったバイナリを許可する運用が可能になります。自動で効くわけではなく管理者側の明示的な構成が前提ですが、サイレントインストールに対応したMSIを用意しておくことで、その選択肢を顧客に渡せます(自動更新の安全設計は「自動更新のセキュリティ」)。
6. ブロック時の情報提供を準備しておく。署名のサブジェクト、実行に必要なバイナリの一覧、インストール先パスを「導入手順書」に明記しておくと、顧客の情シスはそれだけでルールを書けます。トラブル時には4章のイベントIDを指定して確認を依頼すれば、往復が1回で済みます。

この6点は、Smart App Controlへの備えとしてもそのまま効きます。署名され、評判が積み上がったバイナリは、個人PCの自動ブロックにも引っかかりにくくなります。³

5.1. はじめてコード署名証明書を取るとき

「署名しましょう」で止まると先に進めないので、証明書を持っていない場合の次の一手を書いておきます。

証明書の選び方。使えるのはパブリック認証局(商用CA)が発行するコード署名証明書です。自己署名証明書や社内CAの証明書は、そのCAを信頼していない顧客のPCでは検証できないので、配布物には使えません。パブリックCAの証明書には企業実在確認を行うOVと、より厳格な審査のEVがありますが、AppLockerやApp Controlの発行者ルールという観点ではどちらでも同じようにルールを書けます。App Controlには「EV署名を必須にする」ルールオプション(Required:EV Signers)が用意されてはいるものの、現時点ではサポートされていないとドキュメントに明記されているため、実行制御のためにEVを選ぶ理由は今のところありません。⁷

費用の考え方。金額はCAと有効期間で変わるので見積もりを取っていただく前提ですが、内訳の構造だけ知っておくと比較しやすくなります。2023年6月1日以降、CA/Browser Forumの基準により、OV・EVを問わず秘密鍵をFIPS 140-2レベル2相当以上のハードウェア(HSMやUSBトークン)で生成・保管することが必須になりました。⁸ つまり費用は「証明書本体」だけでなく「トークンやHSM、あるいはCAが提供するクラウド署名サービスの利用料」を含みます。CI/CDで自動署名したい場合は、物理トークンよりクラウド署名サービスのほうが構成しやすいので、見積もり時に署名の運用方法まで含めて相談してください。

最小の署名コマンド。Windows SDKに含まれる signtool を使います。

:: 署名する(SHA-256でハッシュし、RFC 3161タイムスタンプを付ける)
signtool sign /fd sha256 /tr <タイムスタンプサーバーのURL> /td sha256 /a MyApp.exe

:: 署名を確認する(Authenticodeのポリシーで検証し、詳細を表示)
signtool verify /pa /v MyApp.exe

/fd がファイルのハッシュアルゴリズム、/tr がRFC 3161タイムスタンプサーバーのURL、/td がタイムスタンプのハッシュアルゴリズム、/a が証明書ストアから適切な証明書を自動選択する指定です。タイムスタンプサーバーのURLは証明書を買ったCAが案内しているものを使ってください。トークンやHSMの鍵で署名する場合は、CSP/KSPの指定がCAの手順書に載っています。DLLもインストーラーも同じコマンドで署名できるので、ビルドの最後にまとめてかけるのが確実です。

証明書を更新するときに何が壊れるか。発行者ルールは、署名の発行者情報(証明書チェーンとサブジェクト)を根拠にしています。したがって次のような変更で、顧客側のルールが黙って一致しなくなります。

• 社名表記を変えた(例: 証明書のサブジェクトを Komura Soft LLC から 合同会社小村ソフト に変更した)。同じ会社でも文字列が違えば別の発行者です。
• CAを乗り換えた。App Controlの Publisher レベルのルールは「中間CA(PCA)証明書 + リーフ証明書のCN」の組み合わせなので、CAが変わるとPCAが変わり、一致しなくなります。⁷
• 実行ファイル名や製品名を変えた。FilePublisher レベルのルールには、これらに加えて元のファイル名(OriginalFileName)と最小バージョンが含まれます。⁷

いずれも症状は同じで、更新版に差し替えた瞬間から、その環境でだけアプリが起動しなくなるという形で出ます。しかも顧客側から見れば「アップデートしたら壊れた」なので、原因が署名にあるとは気づかれません。証明書を更新・変更するときは、新旧の署名情報(サブジェクト、発行元CA)を並べた案内をリリースノートに載せ、顧客の情シスがルールを追加できるようにしてください。

6. 導入する側(情シス)の要点

自社のPCに実行制御を入れる側の手順は、この記事の範囲では要点だけにします。

1. 技術を選ぶ。原則はApp Control for Business。ユーザー単位の制御が要る共有PCや古いOSが混在する環境ではAppLockerを併用します。² キオスク端末のような固定用途PCは、まずシェル制限(「キオスクモードと割り当てられたアクセス」)で絞ってから考えると、ルールがシンプルになります。
2. 必ず監査モードから始める。AppLockerの「監査のみ」ならイベント8003・8006、App Controlの監査モードならイベント3076・8028に「強制していたらブロックされていたもの」が記録されます。⁴⁵ 業務が一巡するまで集めてから強制に切り替える、という運びはSMB署名やNTLM制限とまったく同じです。なおAppLockerを使う場合は前提がひとつあります。AppLockerのポリシーはApplication Identityサービス(AppIDSvc)が動いていないと評価されず、監査モードにしてもイベントは出ません。監査を始める前に、対象端末でこのサービスの自動起動を構成してください。
3. 例外を台帳にする。未署名のまま使い続ける古い業務アプリは、ハッシュルールでの例外登録になります。その一覧は「いつか更改すべきもの」のリストそのものなので、資産管理と紐づけて毎年見直してください。

手順2の「監査モードから始める」は、他記事へ送らずに済むよう、最低限の流れをここに置いておきます。

AppLockerの場合(3ステップ)

1. 監査モードを有効にする。グループポリシー管理エディター(ローカルなら secpol.msc)で コンピューターの構成 > ポリシー > Windowsの設定 > セキュリティの設定 > アプリケーション制御ポリシー > AppLocker を開き、AppLockerを右クリックしてプロパティ。ルールコレクションごと(実行可能ファイル、Windowsインストーラー、スクリプト、パッケージアプリ)に「構成する」にチェックを入れ、「監査のみ」を選びます。あわせて各コレクションに既定の規則を作成し、対象端末でApplication Identityサービス(AppIDSvc)を自動起動に構成します(これが動いていないとポリシーは評価されず、イベントも出ません)。

2. イベントを集める。業務が一巡するまで、Microsoft-Windows-AppLocker/EXE and DLL のイベント8003(exe/DLL)と MSI and Script の8006(スクリプト・MSI)を収集します。⁴ ここで注意が要ります。4章のPowerShellはログ名を「EXE and DLL」に固定しているので、そのままではスクリプトとMSIの8006を拾いません。ログが分かれている以上、次のように2本流す必要があります。

    # 監査モードで「強制していたらブロックされていたもの」を2つのログから集める
    $since = (Get-Date).AddDays(-7)
    $collections = @(
        @{ LogName = 'Microsoft-Windows-AppLocker/EXE and DLL';    Id = 8003 }
        @{ LogName = 'Microsoft-Windows-AppLocker/MSI and Script'; Id = 8006 }
    )
    foreach ($c in $collections) {
        Get-WinEvent -FilterHashtable ($c + @{ StartTime = $since }) -ErrorAction SilentlyContinue |
            Select-Object TimeCreated, LogName, Id, Message
    }
   

   該当イベントが1件も無いログでは Get-WinEvent がエラーを返すため、-ErrorAction SilentlyContinue を付けています。パッケージアプリも制御対象にしている場合は Packaged app-Deployment / Packaged app-Execution も同じ形で足してください。月次・年次のバッチまで含めて拾えたかを確認します。

3. 強制に切り替える。8003と8006に出たものを許可ルールに取り込んでから、同じプロパティ画面で「規則の強制」に変更します。切り替え後は8004(exe/DLLのブロック)と8007(スクリプト・MSIのブロック)を監視します。

App Control for Businessの場合も流れは同じで、ポリシーXMLにルールオプション3(Enabled:Audit Mode)を入れた状態で配布し(App Control Policy Wizard、または Set-RuleOption コマンドレットで設定します)、3076と8028を集めてからこのオプションを削除して強制に切り替えます。マイクロソフトも、まず Enabled:Audit Mode で影響を確認することを推奨しています。⁷

7. まとめ

• 実行制御は「警告する」SmartScreenと「ブロックする」AppLocker / App Control for Business / Smart App Controlを区別して考えます(ただしSmartScreenも、警告の突破を禁止する管理ポリシー下では実質的にブロックとして働きます)。
• AppLockerのエディション制限は緩和済みで(Windows 10 2004以降・Windows 11全エディション)、App Controlは元々全クライアントエディションで使えます。「うちの顧客はProだから関係ない」はもう成り立ちません。¹²
• Smart App Controlにより、誰も管理していない個人PCにも実行制御が入りました。未署名の配布物は、それだけで動かない場合があります。³
• ブロックの確定はイベントログで。AppLockerは8004(EXE and DLLログ)、App Controlは3077と署名情報の3089(CodeIntegrity - Operationalログ)が本丸です。⁴⁵
• 配る側の対策は、全バイナリへの一貫した署名、タイムスタンプ、標準的なインストール先、署名済み自動更新、そして導入手順書での情報提供。顧客がルールを書きやすいアプリにすることがブロック対策のすべてです。
• 導入する側は監査モード(8003 / 3076)で一巡分を集めてから強制へ。この運びは他のセキュリティ強化と同じです。

関連記事

• Windowsで「Windows によって PC が保護されました」が出る理由
• 自動アップデートのセキュリティ設計 - HTTPSだけでは足りない理由
• Windowsアプリ配布方式の選び方 - MSI/MSIX/ClickOnce/xcopy/独自更新
• PowerShellの実行ポリシーとスクリプト署名 ── 「Bypassで蓋をする」運用から卒業する実務ガイド
• Windows Defenderの誤検知(False Positive)対応ガイド
• Windowsのキオスクモードと割り当てられたアクセス
• Windows 10サポート終了後の現実解 ── ESU・LTSC・買い替えの判断表

関連する相談領域

合同会社小村ソフトでは、実行制御環境(AppLocker / App Control for Business)で動作する業務アプリの開発・改修、コード署名を組み込んだ配布・自動更新の設計、顧客環境でアプリが起動しない事象の調査を扱っています。

• Windowsアプリ開発
• 既存Windowsソフトの改修・保守
• 不具合調査・原因解析
• お問い合わせ

参考リンク

関連する記事

同じタグを共有する最新の記事です。さらに近い話題で知識を深められます。

関連トピック

このテーマと近いトピックページです。記事を起点に、関連するサービスや他の記事へ進めます。

このテーマがつながるサービス

この記事は次のサービスページにつながります。近い入口からご覧ください。

よくある質問

この記事のテーマについて、相談時によくある質問をまとめています。

AppLockerはProエディションでは使えないのでは？

その常識は更新されています。KB 5024351以降、Windows 10 バージョン2004以降とすべてのWindows 11では、AppLockerポリシーの強制に特定のエディションが不要になりました。かつての「グループポリシー配布での強制はEnterpriseとServerエディションのみ」という制限が当てはまるのは、バージョン2004より古いWindows 10とWindows Server 2019までです(その場合もMDM経由の配布なら全エディションで使えます)。中小企業のPro端末が中心の環境でも、いまはAppLockerが選択肢に入ります。

コード署名証明書はEVを買うべきですか？

AppLockerやApp Control for Businessの発行者ルールという観点では、OV(企業実在確認)とEVのどちらの証明書でも署名者情報に基づくルールは作れます。なお「EVならSmartScreenの警告が初回から消える」という理解は古くなっており、現在はEVで署名したファイルもOVと同様に評判の蓄積を前提に考える必要があります(この論点は別記事「Windows SmartScreenとコード署名」に整理しています)。重要なのは証明書の種別よりも、exeだけでなくDLLやインストーラーを含めて全バイナリに一貫したサブジェクトで署名し、タイムスタンプを付け、証明書更新時にも発行者情報を安定させることです。発行者ルールはその署名者情報を頼りに書かれるため、リリースごとに署名状態が揺れると顧客側のルールが壊れます。

顧客環境で自社アプリがブロックされたようですが、ログに何も見つかりません。どこを見ればよいですか？

見るべきログが2系統に分かれているのが原因のことが多いです。AppLockerによるexe/DLLのブロックは「AppLocker - EXE and DLL」ログのイベント8004(監査モードなら8003)、スクリプトとMSIは「AppLocker - MSI and Script」ログの8007(同8006)に出ます。一方、App Control for Business(WDAC)によるブロックは「CodeIntegrity - Operational」ログのイベント3077(監査モードなら3076)に出て、対応する署名情報が3089に記録されます。さらにスクリプト・MSI・COMがApp Controlに引っかかった場合は「AppLocker - MSI and Script」ログの8029・8036・8040に出ます。どちらの仕組みが動いているのか分からない状態で調べるときは、CodeIntegrity - OperationalとAppLocker配下の両方を時刻で突き合わせてください。

Smart App Controlで自社アプリがブロックされないためには何が必要ですか？

実質的にはコード署名です。Smart App Controlはアプリの実行時に、クラウドのセキュリティサービスによる安全性の予測と、アプリが有効な署名を持っているかを確認し、悪意があると判定されたアプリや、信頼を確認できない未署名のアプリをブロックします。マイクロソフトも開発者向けの案内として、有効な証明書でアプリに署名することを挙げています。ただし署名アルゴリズムに注意が必要で、Smart App Controlの署名チェックは楕円曲線暗号(ECC)の署名に対応しておらず、RSAベースの証明書で署名されたアプリが実行を許可される対象です。Smart App Controlは企業の管理機能ではなくWindows 11の個人利用者向けの保護で、評価モードから自動で有効・無効が決まるため、配布側からは「署名されていない実行ファイルは個人PCで動かない場合がある」という前提で扱うのが安全です。

著者プロフィール

記事の著者プロフィールページです。

小村 豪

合同会社小村ソフト 代表

Windows ソフト開発、技術相談、不具合調査を中心に、既存資産が残る案件や原因が見えにくい障害調査に強みがあります。