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

「お客様のPCにインストールしたら、アプリが起動しない。ダブルクリックしても何も出ない」──業務アプリの配布では、アプリ自身の不具合だけでなく、顧客環境のアプリケーション実行制御が原因になることがあります。exeは起動しても、同梱のDLLやスクリプトだけが止められる場合もあります。

このとき、最初から署名やインストール先を変えるのではなく、どの仕組みが、どのファイルを、何を根拠に止めたのかを切り分ける必要があります。

本記事は、アプリを作って配る側の視点で、Windowsの実行制御を整理します。AppLocker、App Control for Business(旧称WDAC=Windows Defender Application Control)、Smart App Control、SmartScreenの違いを押さえたうえで、典型的なブロック、イベントログの読み方、配布前の対策へ進みます。最後に、自社PCへ導入する情シス向けの手順もまとめます。

1. まず結論

• まず4つの仕組みを区別し、ログで対象を確定します。SmartScreenの警告、AppLockerのユーザー・グループ単位の制御、App Controlのマシン全体の制御、Smart App Controlの個人PC向け保護は、同じものではありません。AppLockerのexe/DLLなら8004、App Controlなら3077と署名情報3089が調査の中心です。スクリプト・MSIは別のログも確認します。¹²
• 配布側は、更新後も許可ルールが一致するアプリにします。中心になるのは、exeだけでなくDLL・インストーラー・同梱スクリプトまでの一貫した署名です。発行者情報、ファイル属性、配置先、自動更新の流れも揃えます。企業管理下でないPCでも、Smart App Controlにより未署名アプリが止まる場合があります。³⁴
• 導入側は、監査モードで業務を一巡させてから強制へ進みます。可能ならApp Controlを選び、ユーザー別制御などが必要な場面でAppLockerを使います。「顧客のPCはProだから無関係」とは考えられません。KB 5024351以降のWindows 10 2004以降・Windows 11ではAppLockerの強制に特定エディションが不要で、App Controlも全クライアントエディションに対応しています。³⁵

目的別の読み方

PowerShellには、完全にブロックされるのではなく制約付き言語モードで動き、一部の処理だけ失敗する場合があります。この違いも4章で扱います。²

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

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

名前の似た製品を、「対象」「効き方」「管理する人」で分けます。まずは、警告への対応が必要なのか、管理者の許可ルールとの照合が必要なのかを見分けてください。

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

SmartScreenは、ファイルの評判に基づいて警告する仕組みです。ルールを書く管理者がいなくても既定で働き、通常はユーザーが警告を越えて実行できます。

ただし、警告の突破を禁止する管理ポリシーが適用されていれば、SmartScreenも実質的なブロックになります。「警告だから必ず実行できる」という意味ではありません。

配布側の対策は、AppLockerなどの許可ルールを顧客に書いてもらうこととは分けて考えます。SmartScreenでは署名と評判の蓄積が中心です。詳しくは「Windows SmartScreenとコード署名」で扱っています。以降の2.2〜2.4は、警告ではなく実行をブロックする仕組みです。

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

何を根拠に、誰の実行を制御するか

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

「ルールを作れる」と「強制できる」を分ける

エディション要件は、この2つを分けると理解しやすくなります。KB 5024351以降、Windows 10 バージョン2004以降とすべてのWindows 11では、AppLockerポリシーの強制に特定のエディションは不要です。⁵

一方、古いWindowsでは配布方法による違いが残ります。2004より前のWindows 10やWindows Server 2019を含む環境では、グループポリシー配布での強制はEnterpriseとServerエディションのみ、MDM配布なら全エディション、という従来の条件です。⁵

Proでもルールの作成はできます。以前の制限は主に強制の可否であり、MDM配布なら当時からProでも強制できました。実行可能ファイル・Windowsインストーラー・スクリプト・DLL・パッケージアプリというルールの種類も、エディションで変わりません。⁵

また、エディションとは別の前提があります。Application Identityサービス(AppIDSvc)が動いていなければ、ルールは評価されません。監査の準備とあわせて6章で確認します。

セキュリティ機能としての位置づけ

マイクロソフトは、AppLockerがMSRCのセキュリティ機能としてのサービス基準(servicing criteria)を満たさないと明記しています。回避手法が見つかっても、その事実だけではセキュリティ脆弱性として扱われない、という位置づけです。次のApp Controlとは、この点も異なります。³

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

マシン全体に適用する仕組み

App Control for Businessは、Windows 10でDevice Guardの一部として「構成可能なコード整合性」と呼ばれていた仕組みの現在の名称です。長くWDACと呼ばれてきました。ポリシーはマシン全体に適用され、そのデバイスの全ユーザーに影響します。こちらはMSRCのサービス基準で定義されたセキュリティ機能として設計されています。³

ルールの根拠は、次のように整理できます。³

利用条件と配布方法

ポリシーはWindows 10/11の任意のクライアントエディション、またはWindows Server 2016以降で作成・適用できます。配布にはIntuneなどのMDM、Configuration Manager、PowerShellを使えます。グループポリシーも使えますが、Windows Server 2016/2019で動くシングルポリシー形式に限られる点に注意してください。³

AppLockerとの選び分け

マイクロソフトは、App Controlで実装できるならApp Controlを使うことを推奨しています。App Controlは改善が続いている一方、AppLockerはセキュリティ修正を受けるものの、新機能は追加されていません。³

AppLockerが適するのは、古いWindowsを含む混在環境に同じポリシーを配りたい場合、共有PCでユーザー・グループごとにルールを変えたい場合です。App Controlの補完として、ユーザー単位の制限を追加する使い方もあります。³

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

Smart App ControlはWindows 11の個人利用者向け保護機能です。実行時にクラウドのセキュリティサービスによる安全性の予測と、有効な署名を確認します。悪意があると判定されたアプリや、有効な署名がなく信頼を確認できないアプリをブロックします。⁴

新しいPCでは評価モードから始まり、その利用者に向くかどうかをWindowsが判断して、有効・無効が決まります。開発者のように頻繁にブロックされそうな利用者では、自動でオフになります。⁴

配布側が押さえるべき点は、情シスがポリシーを書いていないPCでも実行制御が働くことです。小規模事業者や個人事業主の顧客も無関係ではありません。未署名アプリは止まる場合があり、マイクロソフトも開発者に有効な証明書での署名を案内しています。証明書の選び方は5章で整理します。⁴

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

「本体を起動できるか」だけでなく、インストール、DLLの読み込み、スクリプト、プラグイン、自動更新までを確認します。受託開発・パッケージ配布で問題になりやすいパターンは次のとおりです。

共通する原因は、許可ルールの根拠が安定しないこと

表に共通するのは、許可する側が必要とする根拠(署名・パス・ハッシュ)を、配布側が安定して提供できていないという構図です。

たとえばexeだけを署名しても、未署名のDLLには同じ発行者ルールを使えません。個別のハッシュルールで許可しても、更新でバイナリが変わればルールの更新が必要になります。顧客の制御が原因に見えて、実際には配布物や更新方法がルールを壊れやすくしている場合があります。

症状から候補を絞ったら、次のログで実際に止められたファイルを確定します。対策を考えるのは、その後です。

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

イベントログでは、「止められた事実」と「何を直せばよいか」を分けて読みます。入口はAppLocker配下とCodeIntegrityの2系統ですが、AppLockerというログ名でもApp Controlのイベントが記録される点が重要です。²

4.1. 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 です。

PowerShellで取得する場合は、管理者で開いて次のコマンドを実行します。これは直近24時間のexe/DLLの監査・ブロックだけを取り出す例です。スクリプトやMSIは対象に入っていません。

# 直近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)のイベント

exe・DLL・ドライバーと、スクリプト類でログが分かれる

exe・DLL・ドライバーの制御は、次のCodeIntegrityログを確認します。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

このコマンドが取得するのはCodeIntegrityの3076・3077・3089です。MSI・スクリプト・COMを調べるときは、下表に従ってAppLocker - MSI and Scriptも別途確認してください。仕組みが分からない段階では、AppLocker配下とCodeIntegrityを同じ時刻範囲で突き合わせます。

3089で、実際に評価された署名を確認する

3089は、ファイルの署名ごとに1件生成されます。未署名のファイルでは、署名数0のイベントが1件出ます。3076・3077などとは、相関Activity IDで対応を取ります。²

「署名したはずなのに未署名として扱われている」「古い証明書の署名が残っている」といった問題は、この署名情報で確認できます。配布側で確認したファイルと、顧客側で評価されたファイルの状態を照合してください。

8029でも、PowerShellが完全に停止するとは限らない

8029はスクリプトのブロックを示しますが、実際の強制動作はスクリプトホストに委ねられます。PowerShellでは、ポリシーで許可されないスクリプトを完全に止めず、制約付き言語モード(Constrained Language Mode)で実行します。²

このモードでは.NETオブジェクトの生成が広く制限されます。そのため、「スクリプトは開始したが、途中の1行だけ失敗した」という症状になります。同梱スクリプトの調査では、起動の成否だけで判断しないでください。署名の実務は「PowerShellの実行ポリシーとスクリプト署名」を参照してください。

なお、Windows Server CoreエディションにはAppLocker - MSI and Scriptログがありません。サーバー上のアプリを調べる場合は、ログの有無にも注意が必要です。²

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

目標は、顧客の情シスが安定した許可ルールを書ける状態で配ることです。署名は中心的な対策ですが、署名さえあれば顧客のポリシーに関係なく実行できる、という意味ではありません。揃えるものを6つに分けます。

この準備はSmart App Controlにも有効です。署名され、評判が蓄積したバイナリは、個人PCの自動ブロックにも引っかかりにくくなります。⁴

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

信頼された認証局のRSA証明書を選ぶ

外部の顧客へ配布する前提では、パブリック認証局(商用CA)が発行する、RSAベースのコード署名証明書を選びます。自己署名証明書や社内CAの証明書は、そのCAを信頼していない顧客PCでは検証できず、Smart App Controlでもサポートされません。⁶

アルゴリズムも確認してください。Smart App Controlの署名チェックはECC(楕円曲線)署名に対応していません。ECCで署名しても、個人PCでは未署名同然の扱いになる場合があります。⁶

App Controlでも、署名者ベースのルールはRSA(最大4096ビット)のみ対応です。ECDSA署名を発行者ルールで許可しようとすると、対応する3089に VerificationError = 23 が記録されます。「ECCのほうが新しくて強い」という理由だけで選ぶと、実行制御との互換性で困ることになります。⁷

OVとEVは、発行者ルールの観点ではどちらも使える

パブリックCAの証明書には、企業実在確認を行うOVと、より厳格な審査のEVがあります。AppLockerやApp Controlの発行者ルールは、どちらの証明書でも作れます。

App Controlには Required:EV Signers というルールオプションがありますが、公式ドキュメントでは現時点で未サポートです。したがって、ここで扱う実行制御のためにEVを選ぶ理由はありません。SmartScreenとの関係は「Windows SmartScreenとコード署名」で別に整理しています。⁷

証明書代だけでなく、秘密鍵の保管と署名運用を見積もる

費用はCAと有効期間で異なります。見積もりでは、証明書本体に加えて、トークン・HSM、またはCAが提供するクラウド署名サービスの利用料を確認してください。

2023年6月1日以降に発行される証明書では、CA/Browser Forumの基準により、OV・EVを問わず、FIPS 140-2レベル2相当以上のハードウェア(HSMやUSBトークン)で秘密鍵を生成・保管することが必要になっています。⁸

CI/CDで自動署名するなら、物理トークンよりクラウド署名サービスのほうが構成しやすい場合があります。証明書を購入する前に、ビルドから署名までの運用方法も相談するのが実務的です。

全バイナリに署名し、タイムスタンプを付ける

Authenticode署名はexeだけでなく、自社ビルドのDLL、インストーラー(MSI/セットアップexe)、同梱スクリプトまで揃えます。署名メタデータがあれば、顧客は「この発行者のこの製品はバージョンを問わず許可」といった、更新に耐えるルールを作れます。³

タイムスタンプは、証明書の期限が切れた後も署名の有効性を保つために付けます。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

タイムスタンプサーバーは購入先CAが案内するURLを使います。トークンやHSMの鍵を使う場合は、CAの手順書でCSP/KSPの指定も確認してください。DLLもインストーラーも同じコマンドで署名できるので、ビルドの最後にまとめて署名・検証する流れにします。

5.2. 証明書とファイル属性の変更を、顧客のルール変更として扱う

署名が一貫していても、ルールの比較対象が変われば更新版は止まります。確認するのは、証明書のサブジェクトやチェーンだけではありません。製品名・元のファイル名・バージョンは、証明書ではなく各ファイルのバージョンリソース(アセンブリ情報)に由来します。

App ControlのPublisherは「PCA証明書(通常はルートの1つ下) + リーフ証明書のCN」、FilePublisherはさらに署名済みファイルのFileName属性(既定は OriginalFileName)と最小バージョンを組み合わせます。⁷

こうした変更は、顧客には「アップデートしたら、その環境でだけ起動しなくなった」と見えます。社名表記やCA、製品・ファイル属性を変える場合は、新旧の署名情報(サブジェクト、発行元CA)を並べた案内をリリースノートに載せ、事前通知してください。顧客の情シスが許可ルールを追加・更新できるようにします。

5.3. 配置先と自動更新の流れを安定させる

実行ファイルはProgram Files配下などに置き、実行時に %TEMP% や %APPDATA% へexe/DLLを展開して起動する設計を避けます。ユーザーが書き込める場所で実行する設計は、パスルール型の環境と相性が悪いためです。

自動更新では更新プログラム自体も署名し、署名済みバイナリを署名済みバイナリで置き換える流れにします。安全設計の詳細は「自動更新のセキュリティ」を参照してください。

IntuneやConfiguration Managerによる配布では、顧客が配布エージェントをマネージドインストーラーとして構成していれば、その経路で入ったバイナリを許可する運用が可能です。Intuneで配るだけで自動的に許可されるわけではなく、管理者の明示的な構成が前提です。サイレントインストール対応のMSIを用意すると、この選択肢を顧客に渡せます。

5.4. 導入手順書に、ルールを作るための情報を揃える

顧客へ渡す導入手順書には、署名のサブジェクト、実行に必要なバイナリ一覧、インストール先パスを記載します。これらは情シスが許可ルールを作るための根拠になります。

ブロック時には、4章のログ名とイベントIDを指定して確認を依頼できるようにします。「起動しません」だけの往復を減らし、対象ファイルと署名情報をすぐに照合できる状態にしておきます。

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

導入側の基本は、技術を選ぶ → 監査で影響を確認する → 許可ルールを整えて強制する → 例外を継続管理するという順序です。いきなり全端末でブロックを始めないことが重要です。

6.1. 用途で技術を選び、監査の前提を揃える

原則はApp Control for Businessです。共有PCでユーザー単位の制御が必要な場合や、古いOSが混在する場合はAppLockerを併用します。³ キオスクなど固定用途のPCは、先にシェル制限で用途を絞るとルールが単純になります。「キオスクモードと割り当てられたアクセス」も参照してください。

監査では、業務を止めずに「強制していればブロックされていたもの」を集めます。AppLockerではAppIDSvcの稼働が前提で、サービスが止まっていれば監査イベントも出ません。対象端末で自動起動を構成してから始めます。

業務が一巡するまで集めてから強制へ移る考え方は、SMB署名やNTLM制限と同じです。月次・年次のバッチも含め、日常操作だけで確認を終えないようにします。

6.2. AppLockerは3ステップで監査から強制へ進む

1. 監査モードを有効にする。グループポリシー管理エディター(ローカルなら secpol.msc)で コンピューターの構成 > ポリシー > Windowsの設定 > セキュリティの設定 > アプリケーション制御ポリシー > AppLocker を開きます。AppLockerを右クリックしてプロパティを開き、ルールコレクションごと(実行可能ファイル、Windowsインストーラー、スクリプト、パッケージアプリ)に「構成する」を選び、「監査のみ」にします。各コレクションに既定の規則を作成し、AppIDSvcの自動起動も構成します。

2. 対象に合ったログからイベントを集める。exe/DLLは EXE and DLL の8003、スクリプト・MSIは MSI and Script の8006です。4.1節のコマンドはEXE and DLLだけなので、8006は拾いません。両方を見るには次のようにログを分けて取得します。¹

    # 監査モードで「強制していたらブロックされていたもの」を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
    }
   

   該当イベントがないログでは Get-WinEvent がエラーを返すため、この例は -ErrorAction SilentlyContinue を付けています。出力がない場合も、サービスの稼働・対象ログ・取得期間を確認してください。パッケージアプリも対象なら Packaged app-Deployment / Packaged app-Execution を同じ形で追加し、月次・年次のバッチまで確認します。

3. 許可ルールを整えてから強制へ切り替える。8003・8006に出た業務上必要なファイルを確認し、許可ルールへ取り込みます。その後、同じプロパティ画面で「規則の強制」に変更します。切り替え後は8004(exe/DLL)と8007(スクリプト・MSI)のブロックを監視します。

6.3. App Controlでは監査オプションを外して強制へ進む

ポリシーXMLにルールオプション3(Enabled:Audit Mode)を入れて配布します。設定にはApp Control Policy Wizard、または Set-RuleOption コマンドレットを使います。⁷

3076と8028で業務への影響を確認し、許可ルールを整えてから監査オプションを削除すると、強制モードになります。マイクロソフトも、新しいポリシーはまず監査モードで確認することを推奨しています。⁷

6.4. 未署名の例外を資産管理と結び付ける

未署名のまま使い続ける古い業務アプリは、ハッシュルールで例外登録して管理します。その一覧は、今後更改すべき資産の一覧でもあります。例外を作って終わりにせず、資産管理と紐づけて毎年見直してください。

7. まとめ

実行制御への対応は、仕組みを見分けること、ログで確定すること、許可ルールが安定する配布物を作ることの3つで整理できます。

SmartScreenは基本的に警告ですが、突破禁止ポリシー下ではブロックになります。AppLocker・App Control・Smart App Controlとは対処を分けて考えます。AppLockerのエディション制限は緩和され、App Controlは全クライアントエディションで使えます。Smart App Controlは個人PCにも働くため、「Proだから」「情シスがいないから」無関係とは言えません。⁵³⁴

起動しないときは、AppLockerの8004、App Controlの3077・3089を入口に、スクリプト・MSIのログも照合します。一部機能だけ失敗する場合は、PowerShellの制約付き言語モードも確認します。¹²

配る側は、全バイナリへの一貫した署名、タイムスタンプ、安定した発行者情報とファイル属性、標準的な配置先、署名済み自動更新、導入手順書を揃えます。顧客が許可ルールを書きやすく、更新後も維持しやすいアプリにすることが基本です。

導入する側は、AppLockerの8003・8006、App Controlの3076・8028で業務を一巡させてから強制へ進みます。配布と運用の両方を揃えることで、「顧客環境でだけ動かない」を減らせます。

関連記事

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