AppLocker・App Control for Business（WDAC）與業務應用程式發布 ── 在被「執行控制」封鎖之前

「安裝到客戶的電腦之後，應用程式無法啟動。點兩下也沒有任何反應」──在業務應用程式的發布現場，原因不只可能出在應用程式本身的問題，也可能出在客戶環境的應用程式執行控制。有時候 exe 能啟動，卻只有隨附的 DLL 或指令碼被擋下來。

這種時候，不該一開始就急著改簽章或安裝位置，而是要先釐清是哪個機制、擋下了哪個檔案、依據又是什麼。

本文站在開發並發布應用程式的一方，整理 Windows 的執行控制。先掌握 AppLocker、App Control for Business（原稱 WDAC＝Windows Defender Application Control）、Smart App Control 與 SmartScreen 的差異，再進入典型的封鎖情形、事件記錄檔的解讀方式，以及發布前的對策。最後也整理了在自家電腦導入時，資訊系統部門適用的步驟。

1. 先講結論

• 先區分四種機制，再用記錄檔確定對象。SmartScreen 的警告、AppLocker 以使用者與群組為單位的控制、App Control 涵蓋整台機器的控制，以及 Smart App Control 針對個人電腦的保護，並不是同一回事。調查的重心，AppLocker 的 exe/DLL 是 8004，App Control 則是 3077 與簽章資訊 3089。指令碼與 MSI 還要另外查看別的記錄檔。¹²
• 發布方要把應用程式做成更新之後仍然符合允許規則的樣子。核心是不只 exe，連 DLL、安裝程式、隨附指令碼都要一致地簽署。發行者資訊、檔案屬性、安裝位置與自動更新的流程也要一併備齊。即使是不在企業管理之下的電腦，未簽署的應用程式也可能被 Smart App Control 擋下。³⁴
• 導入方要先在稽核模式下讓業務跑過一輪，再轉為強制套用。可行的話就選 App Control，需要依使用者區分控制等情況才使用 AppLocker。「客戶的電腦是 Pro 版，所以與我無關」這種想法已經行不通。在套用 KB 5024351 之後的 Windows 10 2004 以後與 Windows 11 上，強制套用 AppLocker 不需要特定版本，App Control 也支援所有用戶端版本。³⁵

依目的決定閱讀順序

PowerShell 有時不會被完全封鎖，而是以限制語言模式運作，只有部分處理失敗。這個差異也會在第 4 章說明。²

圖中實線表示始終成立的關係，虛線表示附帶條件的關係（成立條件寫在詳細頁面中各關係的說明中）。關係的完整清單（共 36 條，附依據與可信度）以及主要概念的定義，彙整在知識地圖詳細頁面（日文）。資料：JSON-LD / Turtle

2. 區分四種機制

這些產品名稱相近，這裡依「對象」「生效方式」「由誰管理」來區分。首先請分辨，眼前的狀況要處理的是警告，還是要與管理員的允許規則對照。

2.1. SmartScreen ── 唯一以「警告」阻止的機制

SmartScreen 是依檔案的信譽提出警告的機制。即使沒有管理員撰寫規則，它預設就會運作，而且通常使用者可以越過警告繼續執行。

不過，只要套用了禁止越過警告的管理原則，SmartScreen 實質上也會變成封鎖。並不是「因為只是警告，所以一定能執行」。

發布方的對策，要和「請客戶撰寫 AppLocker 之類的允許規則」分開思考。針對 SmartScreen，重心在於簽章與信譽的累積。詳細內容整理在「Windows SmartScreen 與程式碼簽章」。接下來的 2.2～2.4，則是不發出警告、直接封鎖執行的機制。

2.2. AppLocker ── 可依使用者控制的老前輩

依據什麼、控制誰的執行

AppLocker 是在 Windows 7 中導入的。規則的依據包括程式碼簽章憑證的屬性（發行者）、來自簽章中繼資料的檔案屬性（原始檔名、版本）、雜湊值，以及檔案的路徑。原則不只能套用到整台電腦，也能套用到特定的使用者與群組。³

區分「能建立規則」與「能強制套用」

把版本需求拆成這兩件事來看，會比較容易理解。自 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 章一起確認。

作為安全性功能的定位

Microsoft 明確指出，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 的取捨

Microsoft 建議，只要能用 App Control 實作，就使用 App Control。App Control 持續在改進，而 AppLocker 雖然會收到安全性修正，卻不再新增功能。³

適合使用 AppLocker 的場合是：想把同一份原則發布到包含舊版 Windows 的混合環境時，以及共用電腦上想依使用者、群組套用不同規則時。也可以作為 App Control 的補充，額外加上以使用者為單位的限制。³

2.4. Smart App Control ── 「擅自」進駐個人電腦的執行控制

Smart App Control 是 Windows 11 面向個人使用者的保護功能。它會在執行時確認雲端安全服務對安全性的預測，以及檔案是否具有有效簽章，並封鎖被判定為惡意的應用程式，以及沒有有效簽章、無法確認信任的應用程式。⁴

新電腦會從評估模式開始，由 Windows 判斷它是否適合該使用者，再決定啟用或停用。像開發者這種可能頻繁被封鎖的使用者，它會自動關閉。⁴

發布方要掌握的重點是，即使電腦上沒有資訊系統部門撰寫任何原則，執行控制一樣會生效。小型事業者或個人事業主的客戶也不例外。未簽署的應用程式可能會被擋下，Microsoft 也建議開發者以有效憑證為應用程式簽署。憑證的選法整理在第 5 章。⁴

3. 你的應用程式被封鎖的典型模式

要確認的不只是「主程式能不能啟動」，還包括安裝、DLL 的載入、指令碼、外掛程式，一直到自動更新。在受託開發與套裝軟體發布中特別容易出問題的模式如下。

共通的原因是允許規則的依據不穩定

表中各項的共通點在於，允許執行的一方所需要的依據（簽章、路徑、雜湊值），發布方沒能穩定地提供。

舉例來說，就算只為 exe 簽署，未簽署的 DLL 也無法套用同一條發行者規則。即使改用個別的雜湊規則允許，只要更新後二進位檔案改變，規則就得跟著更新。表面上看起來是客戶端的控制造成的，實際上有時是發布物或更新方式讓規則變得容易失效。

從症狀縮小範圍之後，就用接下來要介紹的記錄檔確定實際被擋下的檔案。對策要等到這一步之後再考慮。

4. 用記錄檔確定發生了什麼事

讀事件記錄檔時，要把「確實被擋下的事實」與「該修正什麼」分開來看。入口分成 AppLocker 底下與 CodeIntegrity 兩個系統，但要注意，即使記錄檔名稱叫做 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 會依檔案的每個簽章各產生一筆。未簽署的檔案則會產生一筆簽章數為 0 的事件。它與 3076、3077 等事件之間，要用相關 Activity ID 對應。²

「明明簽署過，卻被當成未簽署處理」「還殘留著舊憑證的簽章」這類問題，都可以用這份簽章資訊確認。請把發布方確認過的檔案，與客戶端實際被評估的檔案狀態對照。

即使出現 8029，PowerShell 也未必完全停止

8029 表示指令碼被封鎖，但實際的強制行為交由指令碼主機決定。PowerShell 並不會完全擋下原則未允許的指令碼，而是以限制語言模式（Constrained Language Mode）執行。²

在這個模式下，.NET 物件的建立會受到廣泛限制。因此症狀會變成「指令碼確實開始執行了，但中途只有某一行失敗」。調查隨附指令碼時，請不要只憑能否啟動來判斷。簽署的實務做法請參考「PowerShell 的執行原則與指令碼簽署」。

另外，Windows Server Core 版沒有 AppLocker - MSI and Script 記錄檔。調查伺服器上的應用程式時，也要留意記錄檔是否存在。²

5. 發布方的對策 ── 打造「容易撰寫規則」的應用程式

目標是在客戶的資訊系統部門能夠撰寫穩定允許規則的狀態下發布。簽章是核心對策，但這不代表只要有簽章，就能不受客戶原則影響地執行。要備齊的項目分成六類。

這些準備對 Smart App Control 同樣有效。已簽署且累積了信譽的二進位檔案，比較不容易被個人電腦的自動封鎖擋下。⁴

5.1. 第一次取得程式碼簽章憑證時

選擇受信任憑證授權單位的 RSA 憑證

若前提是要發布給外部客戶，就要選擇由公開憑證授權單位（商用 CA）核發、以 RSA 為基礎的程式碼簽章憑證。自我簽署憑證或內部 CA 的憑證，在不信任該 CA 的客戶電腦上無法驗證，Smart App Control 也不支援。⁶

演算法也要確認。Smart App Control 的簽章檢查不支援 ECC（橢圓曲線）簽章。就算以 ECC 簽署，在個人電腦上也可能被視同未簽署。⁶

在 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 提供的雲端簽署服務使用費。

依 CA/Browser Forum 的基準，自 2023 年 6 月 1 日起核發的憑證，無論 OV 或 EV，都必須以相當於 FIPS 140-2 Level 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 憑證（通常是根憑證下一層）＋葉憑證的 CN」，FilePublisher 則再加上已簽署檔案的 FileName 屬性（預設為 OriginalFileName）與最低版本。⁷

這類變更在客戶眼中，看起來就是「更新之後，只有這個環境無法啟動」。要變更公司名稱寫法、CA，或產品與檔案屬性時，請在版本說明中並列新舊簽章資訊（主體、核發 CA），並事先通知。好讓客戶的資訊系統部門能夠新增或更新允許規則。

5.3. 讓安裝位置與自動更新的流程保持穩定

執行檔請放在 Program Files 底下之類的位置，避免採用執行時把 exe/DLL 展開到 %TEMP% 或 %APPDATA% 再啟動的設計。因為在使用者可寫入的位置執行的設計，與採用路徑規則的環境並不契合。

自動更新時，更新程式本身也要簽署，讓流程成為以已簽署的二進位檔案替換已簽署的二進位檔案。安全設計的細節請參考「自動更新的安全性」。

透過 Intune 或 Configuration Manager 發布時，只要客戶把發布代理程式組態為受管理安裝程式，就能採取允許經由該途徑進入的二進位檔案的做法。光是用 Intune 發布並不會自動獲得允許，前提是管理員要明確組態。只要準備好支援無聲安裝的 MSI，就能把這個選項交給客戶。

5.4. 在導入手冊中備齊建立規則所需的資訊

交給客戶的導入手冊中，要記載簽章的主體、執行所需的二進位檔案清單、安裝目的地路徑。這些是資訊系統部門建立允許規則的依據。

發生封鎖時，要能指定第 4 章的記錄檔名稱與事件 ID 請對方協助確認。減少只有「無法啟動」這種來回往返，讓對象檔案與簽章資訊可以立刻對照。

6. 導入方（資訊系統部門）的要點

導入方的基本順序是：選擇技術 → 用稽核確認影響 → 整理好允許規則後強制套用 → 持續管理例外。重要的是不要一開始就在所有電腦上啟動封鎖。

6.1. 依用途選擇技術，並備齊稽核的前提

原則上採用 App Control for Business。共用電腦需要以使用者為單位控制，或是混雜舊版作業系統時，則併用 AppLocker。³ 像 Kiosk 這類用途固定的電腦，先用殼層限制縮小用途範圍，規則就會單純許多。也請參考「Kiosk 模式與 Assigned Access」。

稽核的目的，是在不中斷業務的前提下蒐集「若強制套用原本會被封鎖的項目」。AppLocker 的前提是 AppIDSvc 必須運轉中，服務若停止，連稽核事件都不會產生。請先在目標電腦上組態為自動啟動，再開始稽核。

「蒐集到業務跑過一輪之後再轉為強制套用」這個想法，和 SMB 簽署或 NTLM 限制相同。請把月結、年結批次作業也納入，不要只用日常操作就結束確認。

6.2. AppLocker 以三個步驟從稽核走向強制套用

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。要同時查看兩者，請像下面這樣分別從兩份記錄檔取得。¹

    # 在稽核模式下，從兩份記錄檔蒐集「若強制套用原本會被封鎖的項目」
    $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 Cmdlet。⁷

以 3076 與 8028 確認對業務的影響，整理好允許規則後移除稽核選項，就會進入強制模式。Microsoft 也建議新原則要先以稽核模式確認。⁷

6.4. 把未簽署的例外與資產管理連結

持續以未簽署狀態使用的舊業務應用程式，要用雜湊規則登錄為例外並加以管理。這份清單同時也是今後應該汰換的資產清單。請不要建立例外就算了事，而要與資產管理連結，每年重新檢視。

7. 總結

因應執行控制的做法，可以整理成三件事：分辨是哪個機制、用記錄檔確定事實、做出能讓允許規則保持穩定的發布物。

SmartScreen 基本上是警告，但在禁止越過的原則之下就會變成封鎖，因此要和 AppLocker、App Control、Smart App Control 分開處理。AppLocker 的版本限制已經放寬，App Control 則在所有用戶端版本都能使用。Smart App Control 連個人電腦都會生效，所以不能因為「是 Pro 版」「沒有資訊系統部門」就當作事不關己。⁵³⁴

無法啟動時，以 AppLocker 的 8004、App Control 的 3077 與 3089 作為入口，並一併對照指令碼與 MSI 的記錄檔。若只有部分功能失敗，也要確認 PowerShell 的限制語言模式。¹²

發布方要備齊的是：對所有二進位檔案一致地簽署、時間戳記、穩定的發行者資訊與檔案屬性、標準的安裝位置、已簽署的自動更新，以及導入手冊。基本原則就是讓客戶容易撰寫允許規則，而且更新之後也容易維持。

導入方則要用 AppLocker 的 8003、8006 與 App Control 的 3076、8028，讓業務跑過一輪之後再轉為強制套用。把發布與維運兩端都備齊，就能減少「只有在客戶環境無法運作」的情況。

相關文章

• Windows 為什麼會出現「Windows 已保護您的電腦」
• 自動更新功能的安全性基本 - 糟糕的模式與最佳實踐
• Windows 應用程式散發方式怎麼選 - MSI/MSIX/ClickOnce/xcopy/自訂更新
• PowerShell 的執行原則與指令碼簽署 ── 從「用 Bypass 蓋住問題」的做法畢業的實務指南
• 自行開發的 Windows 應用程式被當成病毒處理時 ── Microsoft Defender 誤判的因應方式，以及與效能影響的相處之道
• 用 Kiosk 模式固定業務終端 ── Assigned Access・Shell Launcher 的選型與運用設計
• 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 與程式碼簽章」中）。比起憑證的種類，更重要的是讓包含 DLL 與安裝程式在內的所有二進位檔案都以一致的主體（Subject）簽署、附加時間戳記，並在憑證更新時也維持發行者資訊的穩定。因為發行者規則正是依賴這份簽署者資訊撰寫的，若每次發行版本簽署狀態都不一致，客戶端的規則就會失效。

客戶環境中自家應用程式似乎被封鎖了，但記錄檔裡什麼都找不到。應該看哪裡？

原因大多是應該查看的記錄檔分成兩個系統。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 在應用程式執行時，會確認雲端安全服務對其安全性的預測，以及該應用程式是否具有有效簽章，並封鎖被判定為惡意，或是無法確認信任的未簽署應用程式。Microsoft 給開發者的建議中，也提到要用有效憑證為應用程式簽署。不過需要留意簽章演算法：Smart App Control 的簽章檢查並不支援橢圓曲線密碼（ECC）簽章，只有以 RSA 為基礎的憑證簽署的應用程式才會被允許執行。Smart App Control 並非企業管理功能，而是 Windows 11 面向個人使用者的保護機制，會從評估模式開始自動決定啟用或停用，因此就發布方而言，安全的做法是抱持「未簽署的執行檔在個人電腦上可能無法執行」這個前提來處理。

作者檔案

本文作者的個人檔案頁面。

Go Komura

小村軟體有限公司 代表

以 Windows 軟體開發、技術諮詢與故障調查為中心，在難以重現的故障調查與既有資產仍在運作的專案上具有優勢。