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

「安裝到客戶的電腦上後，應用程式無法啟動。點兩下也沒有任何反應」──在受託開發的 Windows 應用程式發布現場，收到這類諮詢的頻率正在上升。追查原因後發現，連錯誤對話方塊都不顯示就把應用程式擋下來的，正是客戶端日漸普及的應用程式執行控制。

Windows 中有多種機制，可以只讓指定的應用程式執行。分別是AppLocker、App Control for Business（長期以來被稱為 WDAC＝Windows Defender Application Control）、以及面向個人使用者的Smart App Control。在資安對策的脈絡中，多半是從「導入方」的角度解說，但本文換個視角，改從開發並發布應用程式的一方來整理。內容包含自家業務應用程式在客戶環境中被封鎖的典型模式、被封鎖時該看哪個記錄檔才能確定原因，以及開發、發布方能夠事先採取的對策。同時也整理了考慮在自家電腦導入時，資訊系統部門視角下的要點。

1. 先講結論

• 執行控制要區分成四種來思考。發出警告讓使用者自行選擇的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 以後。Microsoft 建議，只要可行就應優先使用 App Control 而非 AppLocker。²
• 發布方對策的核心是程式碼簽章。不只 exe，還要為包含 DLL 在內的所有二進位檔案與安裝程式，以一致的發行者資訊簽署（第 5 章）。隨著 Smart App Control 的普及，未簽署的應用程式在個人電腦上也可能無法執行。³
• 封鎖的證據可以透過事件記錄檔確定。AppLocker 要看「AppLocker - EXE and DLL」的事件 8004，App Control 則以「CodeIntegrity - Operational」的事件 3077 為主戰場（見第 4 章的判斷表）。⁴⁵
• PowerShell 指令碼有時不是被「封鎖」，而是變成「以受限模式執行」。在 App Control 環境中，不符合原則的指令碼會以受限語言模式（Constrained Language Mode）執行，因此會出現「能運作，但部分處理會失敗」這種難以察覺的異常。⁵
• 導入方要從稽核模式開始。AppLocker 與 App Control 都有一種模式，不實際封鎖，只記錄「原本應該會被封鎖的項目」，對應的就是事件 8003、3076。⁴⁵

2. 區分四種機制

首先看整體地圖。由於名稱相似容易混淆，這裡依「由誰管理」「以什麼單位」「如何生效」來區分。

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

SmartScreen 是「對信譽不佳的項目提出警告」的機制，預設情況下使用者可以自行繞過。不過在受管理的環境中，有時會啟用禁止繞過警告本身的原則，此時 SmartScreen 實質上也會發揮封鎖的作用（這個議題已在「Windows SmartScreen 與程式碼簽章」中討論過）。

從發布方的角度來看，SmartScreen 的特徵在於：即使沒有管理員撰寫規則，預設也會生效，以及封鎖的理由不是原則，而是「信譽」。因此，應對方式也和其他三種不同，不是請客戶撰寫允許規則，而是要靠簽章與信譽的累積來解決。以下 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 版能做什麼」拆成能否建立規則與建立的規則是否實際生效（強制套用）這兩件事來整理，結果如下表。正因為這兩者是不同的事，舊常識才會一直流傳下來。¹

常有人誤以為「在 Pro 環境下連建立都做不到」，但建立規則在任何版本都能做到。過去有分別的其實是強制套用，而且就算在當時，只要透過 MDM 發布，Pro 版也能強制套用。可套用的規則種類（可執行檔、Windows 安裝程式、指令碼、DLL、封裝應用程式）不會因版本而改變。¹ 另外，無論哪個版本，只要 Application Identity 服務（AppIDSvc）沒有執行，規則就不會被評估（第 6 章）。

不過 AppLocker 有一項重要的但書。Microsoft 自己明確指出，AppLocker 不符合作為安全性功能的服務基準（MSRC 的 servicing criteria）。也就是說，即使發現繞過手法，本身也不會被當作安全性弱點處理。²

2.3. App Control for Business ── 作為安全性功能的正牌選擇

App Control for Business 是 Windows 10 中以「Device Guard」「可組態程式碼完整性（WDAC）」形式登場的機制的現行名稱。原則會套用到整台機器，並影響裝置上的所有使用者。可以作為規則依據的有：簽章憑證的屬性、檔案屬性或雜湊值、Microsoft 的 Intelligent Security Graph（ISG）評估、發起安裝的處理程序（受管理安裝程式）、檔案路徑（Windows 10 1903 以後）、以及啟動來源處理程序。²

這個機制是依 MSRC 的服務基準所定義，設計為安全性功能。適用條件也很寬鬆，Windows 10/11 的任何用戶端版本，或 Windows Server 2016 以後都能建立、套用原則。發布方式可使用 Intune 等 MDM、Configuration Manager、PowerShell。也能透過群組原則發布，但僅限於在 Windows Server 2016/2019 上運作的單一原則格式。²

關於該選用哪一個，Microsoft 的方針很明確：只要 App Control 能實作，就應該優先使用。App Control 持續在改進，而 AppLocker 雖然會收到安全性修正，卻不再新增功能。AppLocker 適合的場合是：混雜著舊版 Windows、想要發布同一份原則時；共用電腦需要依使用者、群組套用不同規則時；以及作為 App Control 的補充，追加以使用者為單位的限制時。²

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

Smart App Control 是 Windows 11 面向個人使用者的保護功能。當使用者嘗試執行應用程式時，雲端安全服務會確認是否能對該應用程式的安全性做出預測，並封鎖被判定為惡意的應用程式，以及沒有有效簽章、無法確認信任的應用程式。新電腦會從評估模式開始，由 Windows 自動判斷是否適合該使用者，決定啟用或停用（像開發者這種容易頻繁被封鎖的使用者，會自動關閉）。³

對發布方而言，這件事的意義很單純：即使是不受企業管理的電腦，也就是小型事業者或個人事業主客戶的電腦，如今也已進入預設就內建執行控制的時代。就算沒有任何管理員撰寫原則，未簽署的應用程式仍可能被封鎖。Microsoft 給開發者的建議中，也提到要用有效憑證為應用程式簽署以避免被封鎖。³

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

以下依原因列出在受託開發、套裝軟體發布現場實際會遇到的模式。

共通的癥結在於，「允許執行一方所依據的根據（簽章、路徑、雜湊）」，發布方沒能穩定地提供。就算客戶的資訊系統部門想撰寫發行者規則，若簽章只涵蓋部分二進位檔案，就只能改用雜湊規則，而雜湊規則會在您每次發行更新版時失效。表面上封鎖的責任似乎在導入方，但實際上很多情況是讓規則容易失效的原因出在發布方。

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

「無法啟動」的原因是否出在執行控制，不必靠猜測，可以用事件記錄檔確定。要查看的位置分成兩個系統。

4.1. AppLocker 的事件

請查看事件檢視器的 Applications and Services Logs\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，用下面這一行讀取（請客戶協助確認時，把這行指令交給對方也是最快的方法）。

# 取出最近 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 的封鎖記錄在另一個位置：Applications and Services Logs\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

在「不確定是被哪個機制封鎖的」狀態下，把這兩份記錄檔以相同時間範圍並排比對，是最確實的做法。

3089 容易被忽略，但很重要。每個檔案的每個簽章都會產生一筆事件，若檔案未簽署，就會產生一筆「簽章數為 0」的事件。「明明已經簽署，卻被當作未簽署處理」「殘留舊憑證的簽章」之類發布方的疏漏，都可以在這裡確定。⁵

指令碼的行為有其特別需要注意之處。事件 8029 表示「指令碼被封鎖」，但實際的強制方式取決於指令碼主機端的行為，例如 PowerShell 並不會完全阻止不符合原則的指令碼，而是以受限語言模式（Constrained Language Mode）執行。⁵ 由於 .NET 物件的建立會受到廣泛限制，因此會出現「指令碼本身能執行，但中途某一行會失敗」這種不上不下的異常。若應用程式隨附了指令碼，不了解這種異常模式會使調查拖得更久（指令碼簽章的實務作法可參考「PowerShell 的執行原則與指令碼簽章」）。

另外，「AppLocker - MSI and Script」記錄檔在 Windows Server Core 版中並不存在。⁵ 在調查伺服器部署的應用程式時，請記住這一點。

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

與其等被封鎖後才處理，正確做法是在發布時就讓客戶的資訊系統部門能夠撰寫穩定的允許規則。要做的事其實不多。

1. 為所有二進位檔案加上 Authenticode 簽章。不只是 exe，還包括自行建置的 DLL、安裝程式（MSI／安裝用 exe）、以及隨附的指令碼。發行者規則是以簽章中繼資料（發行者、產品名稱、檔名、版本）為根據的，因此只要有簽章，就能請對方寫出「允許此發行者的此產品，不論版本」這種能承受更新的規則。² 憑證請選擇由受信任憑證授權單位核發、以 RSA 為基礎的憑證。自我簽署憑證或內部 CA 的憑證，在不信任該 CA 的客戶電腦上無法通過驗證，Smart App Control 也不支援。此外，Smart App Control 的簽章檢查並不支援 ECC（橢圓曲線）簽章，因此若以 ECC 憑證簽署，在個人電腦上可能會被視同未簽署。⁶ App Control 也有相同的限制，以簽署者為基礎的規則只支援 RSA（最高 4096 位元），以 ECDSA 簽署的檔案無法用發行者規則允許（簽章資訊的 3089 事件會出現 VerificationError = 23）。⁷ 若因為「ECC 比較新、比較強」而選用它，在執行控制的觀點下反而會造成反效果。
2. 務必附加時間戳記。即使憑證過期，簽章的有效性仍能保持。簽章的實務步驟以及與 SmartScreen 的關係，已整理在另一篇文章中。
3. 讓發行者資訊與檔案的版本資源保持穩定。更新憑證時，若主體（組織名稱）改變，發行者規則就會失效。若要變更公司名稱表記方式或憑證取得來源，請將事先通知客戶的內容納入版本說明。另一個容易被忽略的地方是，發行者規則中的「產品名稱」「原始檔名」「版本」，並非取自憑證，而是取自各檔案的版本資源（組件資訊）。若把這些欄位留空，或是每次發行版本都更改產品名稱或執行檔名，即使簽署者相同，鎖定產品、檔案層級的規則也會失效。
4. 讓執行檔的存放位置貼近標準。安裝到 Program Files 底下，並停止那種在執行時把 exe/DLL 展開到 %TEMP% 或 %APPDATA% 再啟動的設計。因為在可寫入位置執行的設計，與採用路徑規則的環境根本上不相容。
5. 重新檢視自動更新的設計。更新程式本身也要簽署，讓更新流程成為「以已簽署的二進位檔案取代已簽署的二進位檔案」的封閉流程。若透過 Intune 或 Configuration Manager 發布，只要客戶端把該發布代理程式組態為受管理安裝程式，就能採用允許透過該安裝程式導入之二進位檔案的運用方式。這不是自動生效，而是以管理員端的明確組態為前提，但只要事先準備好支援無聲安裝的 MSI，就能把這個選項交給客戶（自動更新的安全設計整理在「自動更新的安全性」）。
6. 事先準備好被封鎖時所需的資訊。在「導入手冊」中明確記載簽章的主體、執行所需的二進位檔案清單、安裝路徑，客戶的資訊系統部門光憑這些就能撰寫規則。發生問題時，只要指定第 4 章的事件 ID 請對方確認，往返一次就能解決。

這六點，也直接適用於對 Smart App Control 的準備。已簽署、且累積了信譽的二進位檔案，比較不容易被個人電腦的自動封鎖攔下。³

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

光說「來簽章吧」會卡在原地無法前進，這裡寫下還沒有憑證時的下一步該怎麼做。

憑證的選擇方式。可用的是由公開憑證授權單位（商用 CA）核發的程式碼簽章憑證。自我簽署憑證或內部 CA 的憑證，在不信任該 CA 的客戶電腦上無法驗證，因此不能用於發布的軟體。公開 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 Level 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. 導入方（資訊系統部門）的要點

在自家電腦上導入執行控制的一方，本文只整理要點。

1. 選擇技術。原則上以 App Control for Business 為主。共用電腦需要以使用者為單位控制，或是混雜舊版作業系統的環境，則併用 AppLocker。² 像資訊站終端這類固定用途的電腦，先用殼層限制（「資訊站模式與指派的存取」）縮小範圍後再考慮，規則會比較單純。
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。既然記錄檔是分開的，就必須像下面這樣分別執行兩次。

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

App Control for Business 的情況流程也相同，先在原則 XML 中放入規則選項 3（Enabled:Audit Mode）再發布（可用 App Control Policy Wizard 或 Set-RuleOption Cmdlet 設定），蒐集3076與8028後，再移除這個選項切換為強制套用。Microsoft 也建議先以 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，即使是沒有人管理的個人電腦，也已經有了執行控制。未簽署的發布物，光是這一點就可能無法執行。³
• 封鎖與否要靠事件記錄檔確定。AppLocker 以 8004（EXE and DLL 記錄檔）、App Control 則以 3077 與簽章資訊的 3089（CodeIntegrity - Operational 記錄檔）為主戰場。⁴⁵
• 發布方的對策，是為所有二進位檔案一致地簽章、附加時間戳記、標準化的安裝位置、已簽署的自動更新，以及在導入手冊中提供資訊。打造讓客戶容易撰寫規則的應用程式，就是封鎖對策的全部。
• 導入方要以稽核模式（8003／3076）蒐集完一輪後再切換為強制套用。這個做法和其他安全性強化措施相同。

相關文章

• Windows 為什麼會出現「Windows 已保護您的電腦」
• 自動更新功能的安全性基本 - 糟糕的模式與最佳實踐
• Windows 應用發布方式怎麼選 - MSI / MSIX / ClickOnce / xcopy / 自訂 updater 的判斷表
• 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 軟體開發、技術諮詢與故障調查為中心，在難以重現的故障調查與既有資產仍在運作的專案上具有優勢。