合同会社小村ソフト
相談する
メニュー

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

· · Windows, セキュリティ, 情報システム, AppLocker, WDAC, Smart App Control, コード署名, Deployment

「お客様の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では、強制に特定のエディションが不要です。1
  • App Control for BusinessはWindows 10/11の全クライアントエディションとWindows Server 2016以降で使えます。マイクロソフトは、可能ならAppLockerではなくApp Controlの利用を推奨しています。2
  • 配布側の対策の中心はコード署名です。exeだけでなくDLLを含む全バイナリとインストーラーに、一貫した発行者情報で署名します(5章)。Smart App Controlの普及で、未署名アプリは個人PCでも動かない場合が出てきました。3
  • ブロックの証拠はイベントログで確定できます。AppLockerなら「AppLocker - EXE and DLL」のイベント8004、App Controlなら「CodeIntegrity - Operational」のイベント3077が本丸です(4章の判断表)。45
  • PowerShellスクリプトは「ブロック」ではなく「制限モードで実行」になることがあります。App Control環境ではポリシーに合わないスクリプトが制約付き言語モード(Constrained Language Mode)で動くため、「動くけれど一部の処理だけ失敗する」という分かりにくい壊れ方をします。5
  • 導入する側は監査モードから始めます。AppLockerもApp Controlも、ブロックせずに「ブロックされるはずだったもの」を記録するモードがあり、イベント8003・3076がそれに当たります。45

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

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

仕組み 対象 効き方 管理する人
SmartScreen 主にダウンロードされたファイル 警告(既定ではユーザーが突破できるが、突破を禁止する管理ポリシーもある) OS既定
Smart App Control Windows 11の個人利用PC 自動でブロック(署名とクラウド評価で判定) OS(自動)
AppLocker ドメイン/管理下のPC ルールで許可/拒否。ユーザー・グループ単位で変えられる 情シス
App Control for Business(旧WDAC) 管理下のPC ルールで許可/拒否。マシン全体・全ユーザーに適用 情シス

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

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

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

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

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

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

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

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

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

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

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

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

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

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

パターン 何が起きるか 根本原因
exeは署名したがDLLは未署名 本体起動直後に落ちる/機能単位で失敗する DLLルールを有効にした環境では全バイナリが検証対象になる
自己解凍アーカイブや一時フォルダ展開 %TEMP% に展開したexeが起動しない パスルールの許可範囲(Program Files等)の外で実行している
自動更新が新バージョンを差し替えた 更新後から起動しない ハッシュルール運用の顧客環境で、更新のたびにハッシュが変わる
インストーラーだけ署名、MSIは未署名 インストール自体が失敗する MSI・スクリプトも制御対象(「AppLocker - MSI and Script」ログの管轄)
同梱のPowerShellスクリプトが動かない アプリは起動するが一部機能だけ失敗 App Control環境ではポリシー外のスクリプトが制約付き言語モードで実行される5
プラグイン・拡張DLLの後入れ 追加モジュールだけ動かない 後から入れたDLLが許可ルールに含まれない
書き込み可能フォルダへのインストール 環境によって動いたり動かなかったり パスルールは通常、ユーザーが書き込めるパスを許可しない前提で設計される

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

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

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

4.1. AppLockerのイベント

イベントビューアーの アプリケーションとサービス ログ\Microsoft\Windows\AppLocker 配下を見ます。4

ログ イベント 意味
EXE and DLL 8002 許可されて実行された
EXE and DLL 8003 監査モード: 強制されていればブロックされていた
EXE and DLL 8004 ブロックされた(強制モード)
MSI and Script 8005 / 8006 / 8007 スクリプト・MSIの許可/監査/ブロック
Packaged app 8020〜8025 パッケージアプリ(MSIX/AppX)の許可/監査/ブロック
─ 8008 AppLockerに対応しないSKU

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

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

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

ログ イベント 意味
CodeIntegrity - Operational 3076 監査モードの主ブロックイベント: 強制されていればブロックされていた
CodeIntegrity - Operational 3077 強制モードの主ブロックイベント: ポリシーを通らずブロックされた
CodeIntegrity - Operational 3089 ブロック(または監査ブロック)されたファイルの署名情報。3076/3077と相関IDで突き合わせる
CodeIntegrity - Operational 3033 署名の失効・期限切れなどによるブロック(3077と併発することがある)
AppLocker - MSI and Script 8028 / 8029 スクリプト・MSIの監査/ブロック
AppLocker - MSI and Script 8036 COMオブジェクトのブロック
AppLocker - MSI and Script 8039 / 8040 パッケージアプリの監査/ブロック

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

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

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

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

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

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

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

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

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

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

7. まとめ

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

関連記事

関連する相談領域

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

参考リンク

  1. Microsoft Learn, Requirements to use AppLocker. KB 5024351以降、Windows 10 バージョン2004以降とすべてのWindows 11でAppLockerポリシーの強制に特定のエディションが不要になったこと、バージョン2004より古いWindows(Windows Server 2019を含む)ではグループポリシー配布のポリシーはEnterpriseおよびServerエディションのみでサポートされ、MDM配布のポリシーは全エディションでサポートされること、Windows 10/11とWindows Server 2012 R2以降でパッケージアプリ・実行ファイル・Windowsインストーラー・スクリプト・DLLのルールが構成・強制できることについて。 ↩ ↩2 ↩3

  2. Microsoft Learn, App Control and AppLocker Overview. App Control for BusinessがWindows 10で導入され、MSRC(Microsoft Security Response Center)のサービス基準で定義されたセキュリティ機能として設計されていること、もともとDevice Guardの一部として「構成可能なコード整合性」の名称でリリースされたこと、App Controlポリシーがマシン全体に適用されデバイスの全ユーザーに影響すること、ルールの根拠が署名証明書の属性・署名メタデータ由来のファイル属性やハッシュ・Intelligent Security Graphによる評価・マネージドインストーラー・ファイルパス(Windows 10 1903以降)・起動元プロセスであること、App ControlポリシーがWindows 10/11の任意のクライアントエディションまたはWindows Server 2016以降で作成・適用でき、MDM(Intune等)・Configuration Manager・PowerShellで配布でき、グループポリシー配布はWindows Server 2016/2019で動作するシングルポリシー形式に限られること、AppLockerがWindows 7で導入され、セキュリティ機能としてのサービス基準を満たさないこと、AppLockerポリシーがコンピューター全体または個々のユーザー・グループに適用でき、ルールの根拠が署名証明書の属性・ファイル属性・パスであること、可能ならAppLockerではなくApp Controlを使うべきで、App Controlは継続的に改善されている一方AppLockerはセキュリティ修正のみで新機能は追加されていないこと、AppLockerが適するのはOS混在環境と共有PCでのユーザー・グループ別ポリシーであり、App Controlの補完としても使えることについて。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9

  3. Microsoft Support, What is Smart App Control?. Smart App ControlがWindows 11でアプリの実行時にクラウドベースのセキュリティサービスがそのアプリの安全性について確信を持った予測ができるかを確認し、悪意があると判定されたアプリや有効な署名を持たず信頼を確認できないアプリをブロックすること、新しい環境では評価モードから始まり、頻繁にブロックに遭遇しそうな利用者(開発者など)ではWindowsが自動的にSmart App Controlをオフにすること、判定にクラウドの評価とアプリが有効な署名を持つかの両方が使われること、開発者への案内として有効な証明書でアプリに署名することが挙げられていること、および他のセキュリティソフトウェアと並行して動作することについて。 ↩ ↩2 ↩3 ↩4 ↩5

  4. Microsoft Learn, Using Event Viewer with AppLocker. AppLockerのイベントログに対象ファイルのパス、許可かブロックか、ルール種別(パス・ハッシュ・発行者)、ルール名、ルールのユーザー/グループのSIDが記録されること、イベント8002がexe/DLLの許可、8003が監査モードで「強制されていればブロックされていた」、8004が強制モードでのexe/DLLのブロック、8005〜8007がスクリプト・MSIの許可/監査/ブロック、8020〜8025がパッケージアプリ関連、8008がAppLocker非対応SKUを示すこと、および「AppLocker - EXE and DLL」ログが非常に多くのイベントを生成しうるため収集構成に注意が必要なことについて。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6

  5. Microsoft Learn, Understanding App Control event IDs. App Controlのイベントが「CodeIntegrity - Operational」(exe・DLL・ドライバーの制御とポリシー適用)と「AppLocker - MSI and Script」(MSI・スクリプト・COMオブジェクトの制御)の2か所に記録されること、イベント3076が監査モードの主ブロックイベントで強制されていればブロックされていたことを示し、3077が強制モードの主ブロックイベントであること、3089がブロックまたは監査ブロックされたファイルの署名ごとに生成される署名情報イベントで、未署名ファイルでは署名数0の1件が生成され、相関Activity IDで3076/3077等と突き合わせられること、3033が署名の失効・期限切れ等によるブロックを示すこと、8028/8029がスクリプト・MSIの監査/ブロックを示し、実際の強制はスクリプトホストが制御していて、たとえばPowerShellはApp Controlポリシーで許可されないスクリプトを制約付き言語モード(Constrained Language Mode)で実行すること、8036がCOMオブジェクトのブロック、8039/8040がパッケージアプリの監査/ブロックであること、および「AppLocker - MSI and Script」のイベントがWindows Server Coreエディションには含まれないことについて。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10

  6. Microsoft Learn, Code signing for Smart App Control. Smart App ControlがRSAベースのデジタル証明書で署名されたアプリケーションの実行を許可すること、およびSmart App Controlの署名チェックが楕円曲線暗号(ECC)の署名に対応していないことについて。 ↩

関連する記事

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

関連トピック

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

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

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

よくある質問

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

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

お問い合わせ
ブログ一覧に戻る