Essential Eight 應用程式控制

本文詳細說明使用 Microsoft App Locker 和 Windows Defender 應用程式控制，實現澳洲網路安全中心 (ACSC) 應用程式控制的基本八成熟度模型的方法。

為什麼要遵循 ACSC Essential Eight 應用程式控制指南？

應用程式控制是一種安全方法，旨在防止在系統上執行惡意程式碼。 實施這種安全方法時，它確保只有批准的代碼（例如可執行檔、軟件庫、腳本、安裝程序和驅動程序）才有權執行。 由於其有效性，應用程式控制是 ACSC 減輕 網路安全事件策略中必不可少的八項之一。

應用程式控制

應用程式控制是一種安全方法，旨在防止在系統上執行惡意程式碼。 實施這種安全方法時，它確保只有批准的代碼（例如可執行檔、軟件庫、腳本、安裝程序和驅動程序）才有權執行。

雖然應用程式控制主要是為了防止惡意程式碼在系統上執行和傳播，但它也可以防止安裝和使用未經批准的應用程式。

達到組織成熟度層級需求

• 成熟度等級 1 (ML1) ：可以使用 AppLocker Microsoft來達成
• 成熟度層級 2 和 3 (ML2 & ML3) ：可以使用 Microsoft Windows Defender 應用程式控制 來達成

應用程式控制的實作

實作應用程式控制涉及組織的下列高階步驟：

• 識別已核准的申請
• 制定應用程式控制規則以確保只能執行已核准的應用程式
• 使用變更管理程序維護應用程式控制規則
• 經常驗證應用程式控制規則

在決定如何在組織內強制執行應用程式授權時，澳洲網路安全中心會考慮正確實施以下方法：

• 加密雜湊規則
• 發布者認證規則
• 路徑規則 當設定檔案系統權限時 (，以防止未經授權修改資料夾和檔案權限、資料夾內容和個別檔案)

應用程式控制可以防止未經授權執行未經核准的應用程式。 應用程式控制還有助於識別威脅行為者在系統上執行惡意程式碼的嘗試。 設定 WDAC 以產生授權和未經授權執行的事件記錄檔，可以為組織的安全性作業中心提供有價值的資訊。

請務必注意，應用程式控制解決方案並不能取代已經到位的防毒軟體和其他安全軟體解決方案。 WDAC 一律會與防病毒軟體解決方案搭配使用，例如 Defender 防毒軟體。 同時使用 Microsoft 安全性解決方案有助於採取有效的縱深防禦方法，以防止系統遭到入侵。

應用程式控制的成熟度等級 (ML)

澳洲網路安全中心的緩解策略有三個成熟度級別，構成了「基本八項」。 成熟度等級是基於減輕威脅行為者使用的貿易技巧不斷增加的程度。 在應用程式控制的背景下，澳洲網路安全中心會決定符合 ML 1、2 和 3 所需的條件。

適用於 Windows 的應用程式控制項

使用哪種解決方案？

Microsoft建議客戶實作 Windows Defender 應用程式控制 (WDAC) ，而不是 AppLocker。 Windows Defender 應用程式控制正在持續改進。 雖然 AppLocker 會繼續接收安全性修正，但不會收到功能改善。

不過，AppLocker 也可以部署為 Windows Defender 應用程式控制的補充，適用於共用裝置等案例，其中防止某些使用者執行特定應用程式非常重要。 Microsoft 建議您的組織應該強制執行 Windows Defender 應用程式控制，作為組織可能最嚴格的層級，並視需要使用 AppLocker 進一步微調使用者模式限制。

AppLocker

AppLocker 是隨 Windows 7 引進的，可讓組織控制允許在其 Windows 作業系統上執行哪些使用者模式 (應用程式) 進程。 AppLocker 原則可以套用至系統上的所有使用者，或套用至個別使用者和群組，其規則可根據下列項目定義：

• 加密雜湊規則
• 發布者認證規則
• 路徑規則

AppLocker 原則可以在任何支援的 Windows 作業系統版本和新增專案上建立，而且可以使用群組原則、PowerShell 或行動裝置管理解決方案來部署。

Windows Defender 應用程式控制

Windows Defender 應用程式控制 (WDAC) 是隨 Windows 10 一起引進的。 它允許組織控制允許在其 Windows 操作系統上運行哪些用戶模式 (應用程序) 和內核模式 (驅動程序) 進程。 WDAC 原則會套用至整個受控系統，並影響裝置的所有使用者，並使用可根據下列專案定義的規則：

• 加密雜湊規則
• 發布者認證規則
• 路徑規則
• 應用程式的信譽，由 Microsoft 的智慧型安全性圖表所決定
• 由受管理安裝程式起始應用程式安裝的程式身分識別

您可以在任何支援的 Windows 10、Windows 11 用戶端版本或 Windows Server 2016 和更新版本上建立 WDAC 原則。 WDAC 原則可以使用群組原則、行動裝置管理解決方案、Configuration Manager 或 PowerShell 來部署。

由於 Microsoft 的 Windows 即服務允許向我們的客戶開發和部署新功能，因此 WDAC 的某些功能僅適用於特定的 Windows 版本。

如需 Windows Defender 應用程式控制和 AppLocker 的詳細資訊，請參閱 Windows Defender 應用程式控制和 AppLocker 功能可用性。

使用 AppLocker for ML1 的基本 Eight 應用程式控制

使用 AppLocker 來達成 ML1

當系統管理員部署使用者型應用程式控制的 AppLocker 原則時，下列規則可作為路徑型實作範例。 這包括規則、規則的強制執行，以及應用程式身分識別服務的自動啟動。

建議至少) 以下路徑阻止 (：

• C：\Windows\Temp\*.*
• %USERPROFILE%\AppData\Local\*.*
  • 新增 %USERPROFILE%\AppData\Local\Microsoft\WindowsApps 的例外狀況
• %USERPROFILE%\AppData\Roaming\*.*

如需 ML1 的 AppLocker 相關資訊，請參閱下列文章：

• ACSC - 實作應用程式控制項
• AppLocker 概觀

建立 AppLocker 原則以達到 ML1

您可以使用數種方法建立 Microsoft AppLocker 原則。 Microsoft 建議使用 Microsoft 開放原始碼專案 AaronLocker 來協助建立 AppLocker 原則。 AaronLocker 允許為 AppLocker 創建和維護強大、嚴格的應用程序控制，盡可能簡單實用，就像使用 PowerShell 腳本服務一樣。 AaronLocker 的設計目的是要限制非系統管理使用者執行程式和腳本。

如需 AaronLocker 的詳細資訊，請參閱 AaronLocker：適用於 Windows 的強大且實用的應用程式控制。

部署 AppLocker 原則以達成 ML1

您可以使用 Microsoft Intune、群組原則或 PowerShell 來部署 Microsoft AppLocker。 部署方法將取決於組織目前的管理解決方案。

如需部署應用程式鎖定物櫃的詳細資訊，請參閱下列文章：

• AppLocker 部署指南
• AppLocker CSP

監視 AppLocker 原則事件

Microsoft AppLocker 相關事件是由安全性資訊和事件管理解決方案監視，例如 Microsoft 的 Sentinel。 也會使用適用於端點的 Microsoft Defender 的進階搜捕資訊來監視事件。

適用於端點的 Microsoft Defender：AppLocker 參考

適用於端點的 Microsoft Defender 會擷取下列與 Microsoft AppLocker 相關的事件。

如需事件檢視器和進階搜捕的詳細資訊，請參閱下列文章：

• 搭配 AppLocker 使用事件檢視器
• 使用進階搜捕集中查詢 應用程式控制項 事件

使用 WDAC for ML2 的基本 Eight 應用程式控制

Microsoft 正在概述設計過程、生命週期管理、部署和操作指南，以使用 WDAC 滿足 Essential Eight 應用程序控制 ML2 和 ML3。

具有 Essential Eight 應用程式控制項 ML1 需求的客戶可以使用 Microsoft AppLocker。

需要使用本指南的必要條件：

• Windows 11 22H2 企業版
• 使用 Intune 進行管理解決方案
• 適用於端點的 Defender，適用於端點安全性解決方案
• Microsoft Sentinel for Security 資訊和事件管理;和
• 本文檔中使用的解決方案中管理員的適當許可權

Windows Server 作業系統上的 WDAC 不在本指南的範圍內。 Windows Server 的指引將在未來版本上提供。

授權需求

M365 相關服務可以位於 Microsoft 365 和 Office 365 服務描述中，以了解所需的必要服務、價值主張和授權要求：

Microsoft 365 和 Office 365 服務描述

如需與 WDAC 相關聯之產品的資訊，請參閱下列文章：

• Windows 的應用程式控制
• Microsoft Intune
• Microsoft Azure Sentinel

開始使用 WDAC

政策設計

當組織開始規劃 WDAC 時，考慮設計決策會塑造它如何影響原則部署和應用程式控制原則維護。

如果符合下列條件，WDAC 應該作為組織應用程式控制原則的一部分：

• 您已在組織中部署或計劃部署支援的 Windows 版本
• 您需要改善對組織應用程式存取權和使用者存取資料的控制
• 您的組織有明確定義的應用程式管理和部署程序
• 您有資源可根據組織的需求測試原則
• 您有資源可讓服務台參與，或針對使用者應用程式存取問題建置自助程式
• 群組對生產力、可管理性和安全性的需求可以透過限制性原則來控制

WDAC 融入了「信任圈」的概念。 每個組織都有不同的「信任圈」定義，以滿足其業務需求。 ACSC Essential 8 相關定義是 ISM 控制 1657 – 「應用程式控制將可執行檔、軟體庫、腳本、安裝程式、編譯的 HTML、HTML 應用程式和控制面板小程式的執行限制為組織核准的集合。」

Microsoft 提供數個 XML 格式的範例原則，位於 Windows 的 %OSDrive%\Windows\schemas\CodeIntegrity\ExamplePolicies 下。 Microsoft 範例原則可讓您的組織從現有的基底原則開始，並視需要新增或移除規則以建置自訂原則。

如需原則設計的詳細資訊，請參閱下列文章：

• Microsoft Intune 文件
• Windows Defender 應用程式控制範例基底原則

原則格式

WDAC 支援兩種原則格式：

• 單一原則格式：隨 Windows 10 RTM 和 Windows Server 2016 發行的原始原則格式。 單一原則格式在任何給定時間僅支援系統上的單一作用中原則

• 建議) (多種原則格式：Windows 10 1903+、Windows 11 和 Windows Server 2022 支援此原則格式。 多原則格式可讓您更靈活地部署 Windows Defender 應用程式控制，並在裝置上支援多達 32 個作用中原則。 此外，它還允許以下情況：

  • 並存強制執行和稽核：在部署強制執行之前驗證原則變更。 使用者可以將稽核模式基底原則與現有的強制執行模式型原則並存部署
  • 多個基本原則：使用者可以同時強制執行兩個或多個基本原則
  • 補充原則：使用者可以部署一或多個補充原則來擴充基底原則。 您可以針對組織內的不同角色使用補充原則，例如 HR 和 IT

Microsoft 建議使用多種原則格式，而且只針對定義良好的案例使用單一原則格式，或無法使用多個原則格式，例如 Windows Server 2016 和 Windows Server 2019。

如需 WDAC 控制原則的詳細資訊，請參閱 使用多個 Windows Defender 應用程式控制原則。

原則規則和檔案規則

WDAC 包含兩個概念：

• WDAC 原則規則：WDAC 原則規則會指定稽核模式、受控安裝程式、腳本強制執行、補充原則 (多個原則格式) 、Reputation-Based 智慧 (ISG 授權/智慧應用程控) 等設定。 原則規則也會判斷核心模式和使用者模式二進位檔的 WDAC
• WDAC 檔案規則：WDAC 檔案規則會指定在 Windows 上執行的授權和重新授權。 檔案規則支援雜湊、檔案名稱、檔案路徑和發行者規則，可讓客戶定義一組組織核准的允許應用程式。 規則會先處理它找到的所有明確拒絕規則，然後處理所有明確的允許規則。 如果沒有拒絕或允許規則存在，WDAC 會檢查受控安裝程式。 最後，如果這些集合都不存在，WDAC 會依賴 Reputation-Based 情報

如需原則規則和檔案規則的詳細資訊，請參閱下列文章：

• 了解 Windows Defender 應用程式控制 (WDAC) 原則規則和檔案規則

原則建立

使用 PowerShell 或 WDAC 精靈建立 WDAC 原則有兩種主要方式：

• PowerShell：WDAC 原則是使用 PowerShell 中的可設定程式代碼完整性 Cmdlet 來建立。 PowerShell 可讓 IT 專業人員將 WDAC 原則系統掃描自動化，以產生原則 XML。 PowerShell 可用來合併原則 XML、設定原則規則，並在必要時新增另一個原則檔案規則可設定的程式代碼完整性 Cmdlet 也可用來修改 WDAC 範例原則，以符合組織的需求。
• Windows Defender 應用程式控制精靈 (建議) ：WDAC 原則精靈是以 C# 撰寫的開放原始碼 Windows 傳統型應用程式，並隨附為 MSIX 套件。 它旨在為安全架構師提供安全性，並為系統管理員提供更易用的方法來建立、編輯和合併應用程式控制項 原則。 此工具會在後端使用設定 CI PowerShell Cmdlet，因此工具和 PowerShell Cmdlet 的輸出原則相同

如需建立原則的詳細資訊，請參閱下列文章：

• 使用參考電腦建立 WDAC 原則
• Windows Defender 應用程式控制精靈
• 配置CI
• WDAC 原則精靈

Microsoft 建議使用 Windows Defender 應用程式控制精靈來實作應用程式控制的基本八項。 或者，PowerShell 可供在 DevOps 作業模型中具有進階需求的組織使用範例原則作為基礎，或想要從參考系統建立明確定義案例的原則。

原則生命週期

在組織開始實作應用程式控制解決方案之前，您必須考慮如何隨時間管理和維護您的原則。 大部分的 WDAC 原則都會隨著時間演進，並在其存留期內持續經歷一組可識別的階段。 這些階段包括：

1. 定義原則並建置原則 XML 的稽核模式版本。 在稽核模式中，會產生封鎖事件，但不會阻止檔案執行
2. 將稽核模式原則部署至預期的系統
3. 監控來自預期系統的審核區塊事件，並根據需要完善規則以解決意外/不需要的區塊
4. 重複這些步驟，直到剩餘的區塊事件在稽核期間符合您的預期為止
5. 產生原則的強制模式版本。 在強制模式中，未定義為原則允許的檔案會無法執行，並產生對應的封鎖事件
6. 將強制模式原則部署至預期的系統
7. 持續重複所有這些步驟，以解決任何意外/不需要的封鎖操作

若要有效管理 WDAC 原則，您應該將原則 XML 檔儲存和維護在中央存放庫中。 Microsoft 建議使用原始檔控制解決方案，例如 GitHub 或文件管理解決方案，例如 SharePoint，以提供版本控制。

• 規劃 Windows Defender 應用程式控制 生命週期原則管理

受控安裝程式的 WDAC 必要條件

本節旨在提供客戶使用 PowerShell 和 Microsoft Intune 設定 WDAC 受控安裝程式需求指引。

• 檢閱 Windows 威脅防護 自動允許受控安裝程式使用 Windows Defender 應用程式控制部署的應用程式 (/windows/security/threat-protection/windows-defender-application-control/configure-authorized-apps-deployed-with-a-managed-installer)

• 建立完成下列作業的 PowerShell 指令碼：
  • 儲存 AppLocker XML
  • 匯出 AppLocker XML
  • 設定 AppLocker 原則
  • 啟動 AppLocker 服務

以下是可以使用 Intune 管理延伸模組 – PowerShell 腳本部署的腳本範例：

$ScriptDir = Split-Path $script:MyInvocation.MyCommand.Path

$AppLockerMIPolicy = 
@"
<AppLockerPolicy Version="1">
<RuleCollection Type="ManagedInstaller" EnforcementMode="Enabled">
  <FilePublisherRule Id="55932f09-04b8-44ec-8e2d-3fc736500c56" Name="MICROSOFT.MANAGEMENT.SERVICES.INTUNEWINDOWSAGENT.EXE version 1.39.200.2 or greater in MICROSOFT® INTUNE™ from O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US" Description="" UserOrGroupSid="S-1-1-0" Action="Allow">
    <Conditions>
        <FilePublisherCondition PublisherName="O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US" ProductName="*" BinaryName="MICROSOFT.MANAGEMENT.SERVICES.INTUNEWINDOWSAGENT.EXE">
          <BinaryVersionRange LowSection="1.39.200.2" HighSection="*" />
        </FilePublisherCondition>
  </Conditions>
  </FilePublisherRule>
  <FilePublisherRule Id="6ead5a35-5bac-4fe4-a0a4-be8885012f87" Name="CMM - CCMEXEC.EXE, 5.0.0.0+, Microsoft signed" Description="" UserOrGroupSid="S-1-1-0" Action="Allow">
    <Conditions>
      <FilePublisherCondition PublisherName="O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US" ProductName="*" BinaryName="CCMEXEC.EXE">
        <BinaryVersionRange LowSection="5.0.0.0" HighSection="*" />
      </FilePublisherCondition>
    </Conditions>
  </FilePublisherRule>
  <FilePublisherRule Id="8e23170d-e0b7-4711-b6d0-d208c960f30e" Name="CCM - CCMSETUP.EXE, 5.0.0.0+, Microsoft signed" Description="" UserOrGroupSid="S-1-1-0" Action="Allow">
    <Conditions>
      <FilePublisherCondition PublisherName="O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US" ProductName="*" BinaryName="CCMSETUP.EXE">
        <BinaryVersionRange LowSection="5.0.0.0" HighSection="*" />
        </FilePublisherCondition>
      </Conditions>
    </FilePublisherRule>
  </RuleCollection> 
</AppLockerPolicy>
"@

$AppLockerMIPolicy | Out-File -FilePath $ScriptDir\AppLockerMIPolixy.xml
Set-AppLockerPolicy -XmlPolicy $ScriptDir\AppLockerMIPolixy.xml -Merge -ErrorAction SilentlyContinue
Start-Process -FilePath "$env:windir\System32\appidtel.exe" -ArgumentList "start -mionly" | Wait-Process
Remove-Item -Path $ScriptDir\AppLockerMIPolixy.xml

WDAC 受控安裝程式

概觀

WDAC 稱為 Managed Installer 的功能可讓組織在強制執行應用程式控制原則時平衡安全性和可管理性。 這可讓軟體散發解決方案安裝應用程式，例如 Microsoft Configuration Manager 或 Intune。

常見的誤解是在 WDAC 原則內設定「受控安裝程式」規則是唯一必要的步驟。 這是不正確的，而且需要另一個 AppLocker 設定，才能運作此功能。

受控安裝程式會使用 AppLocker 內的規則集合來指定組織信任的二進位檔以進行應用程式安裝。 Windows 會監視已設定的二進位檔進程及其啟動的任何子進程，同時監視寫入磁碟的相關聯檔案。 這些檔案會標記為源自受管理的安裝程式，因此允許執行。

部署受管理安裝程式

GPO 編輯和 AppLocker PowerShell Cmdlet 內的 AppLocker 原則建立無法直接用來建立受控安裝程式集合的規則。 您必須使用 VS Code 或其他編輯器工具來建立受控安裝程式規則集合。

AppLocker 設定服務提供者 (CSP) 目前不支援受控安裝程式規則集合類型，因此 AppLocker 原則必須使用 PowerShell 輸入 Intune Microsoft。

由於需要 Windows Defender 應用程式控制 的「腳本強制執行」功能才能符合 ISM-1657，因此需要腳本強制執行才能控制 PowerShell、VBscript、cscript、cscript、HSMTA 和 MSXML。 設定「受控安裝程式」的 PowerShell 腳本必須位於使用 Hash 或 Publisher 的 WDAC 檔案原則規則內。

Microsoft 建議設定 Microsoft Intune 的受控安裝程式。 Intune 可讓您健全地管理使用 Microsoft Intune 封裝的應用程式，而不需要經常更新 Windows Defender 應用程式控制原則。

部署受控安裝程式的 PowerShell 腳本

根據案例，可以使用 Microsoft Intune 以兩種方式來部署受控安裝程式的此組態腳本：

• 雜湊：腳本的雜湊必須在 WDAC 檔案原則內已知、使用 Microsoft Intune 內的 Microsoft Win32 內容準備工具或 PowerShell 腳本功能進行封裝和部署。
• 程式代碼簽署的 (發行者) ：PowerShell 腳本已由受信任的授權單位簽署，並使用 WDAC 檔案原則來瞭解，並使用 Microsoft Win32 內容準備工具或 PowerShell 腳本功能來封裝和部署Microsoft Intune。

如需部署 PowerShell 腳本的詳細資訊，請參閱下列文章：

• 使用 Windows Defender 應用程式控制項自動允許受控安裝程式部署的應用程式
• AppLocker CSP
• 使用 Windows Defender 應用程式控制 (WDAC) 強制執行腳本
• Microsoft Intune 中的 Win32 應用程式管理
• 在 Intune 的 Windows 10/11 裝置上使用 PowerShell 腳本

WDAC 稽核原則建立

建立稽核原則

瞭解選項並做出設計決策後，組織可以使用 Windows Defender 應用程控精靈建立第一個稽核原則：

1. 開啟 Windows Defender 應用程控精靈，然後選取「原則建立者」。

2. 在 [原則建立者] 中，選取 [多個原則格式 ] 和 [基本原則 ]，然後選取 [ 下一步]。

3. 在 原則範本中，您會看到三個選項：

   • 預設 Windows 模式包括 Windows 作業系統、市集應用程式、Microsoft 365 Apps for Enterprise (Office 365 Pro Plus) 和 WHQL 簽署的核心驅動程式。
   • 允許 Microsoft 模式 包括預設 Windows 模式和所有 Microsoft 簽署的應用程式中的所有區段。
   • 簽名和信譽模式 包括所有先前的部分和 Reputation-Based 情報。

4. 選取 [預設 Windows 模式 ] 或 [允許 Microsoft 模式 ] ，視您組織的需求而定。 在本文檔中，Microsoft使用 允許Microsoft模式。
5. 將 原則名稱 和 位置 修改為您想要的 原則名稱 和 原則檔案位置 以儲存檔案，然後選取 下一步。

• ISM 1657 和 1658 需要將停用指令碼強制設定為「已停用」，才能控制指令碼、已編譯的 HTML 和 HTML 應用程式。
• ISM 1657、1658 和 1582 需要將智慧型安全圖表設定為「已停用」。
• 建議將受控安裝程式 設為「已啟用」，以協助組織具有 WDAC 原則生命週期。
• WDAC 原則需要使用者模式程式代碼完整性，才能同時套用核心模式和使用者模式二進位檔。
• 需要允許補充原則，才能使用多原則格式來協助組織具有 WDAC 原則生命週期。

6. 在 簽署規則中，系統管理員能夠看到已新增為允許發行者規則的所有 Microsoft 憑證。 我們將在本文稍後介紹新增自訂規則。
7. 選取 [下一步]。

Windows Defender 應用程控精靈會產生：

• 原則 XML
• {GUID} 的 GUID。CIP

如需 WDAC 的詳細資訊 – 原則規則，請參閱這裡。

WDAC 原則已成功建立。

原則 XML

由於組織已使用 WDAC 精靈建立 WDAC 原則，因此組織能夠在文字編輯器中檢視此檔案的內容。 XML 會分成數個不同的區段，針對 Essential Eight 的內容，請記下 PolicyID 和 BasePolicyID。

WDAC 稽核原則部署

透過 Intune 部署 WDAC 稽核原則

現在組織已建立稽核原則，是時候使用 Intune 裝置管理來部署它了。

1. 登入 Intune 系統管理中心。
2. 在 Intune 系統管理中心內，移至 [裝置] ，然後移至 [ 組態配置檔]。
3. 接下來，建立設定檔>平台 – Windows 10 或更新版本、設定檔類型範本和自訂。
4. 建立原則 (的名稱，例如「應用程式控制 - Microsoft允許 - 稽核」) 然後選取 下一步。
5. 在 [OMA-URI 設定] 底下，選取 [新增]。

6. 當 Windows Defender 應用程控精靈產生原則 XML 時，也會建立 (GUID) 。CIP 檔案。 需要複製 CIP 檔案，並將副檔名重新命名為 。BIN 例如 {CB46B243-C19C-4870-B098-A2080923755C}.bin。
7. 上傳 Base64 下的 BIN， (檔案) 。
8. 選取 [儲存]。
9. 依照提示建立 設定檔。
10. 將您建立的原則 （例如，「應用程式控制 - Microsoft 允許 – 稽核」、組態設定檔） 部署至預期的系統。

WDAC – 稽核原則監視

在 WDAC 原則生命週期之後，組織必須檢閱從「允許 Microsoft 稽核」原則所產生的事件。 WDAC 稽核原則監視可以使用兩種方法來達成：

• 應用程式控制項事件識別碼：應用程式控制項事件識別碼是在 Windows 作業系統上檢閱稽核事件的傳統方法。 這些事件標識碼可以使用 Windows 事件記錄檔轉送或協力廠商安全性資訊和事件管理，轉送至集中位置。

如需事件識別碼的相關資訊，請參閱 瞭解應用程式控制項事件識別碼 - Windows 安全性。

• 適用於端點的 Microsoft Defender (建議的) ：適用於端點的 Windows Defender 和 AppLocker 相關事件會在進階搜捕適用於端點的 Microsoft Defender中擷取。 事件中包含的資訊包括 Device、FileName、FolderPath、InitiatingProcessFileName、File Hashes 等。 請參閱： 使用 Windows) (進階搜捕查詢應用程式控制項 事件 - Windows 安全性

Microsoft建議使用 Microsoft Defender 全面偵測回應 (MDE) 整合來Microsoft Sentinel。 與 適用於端點的 Microsoft Defender 相比，MDE 和 Sentinel 允許將高級狩獵遙測數據存儲超過 30 天。

如需連線和監視的詳細資訊，請參閱下列文章：

• 將資料從 Microsoft Defender 全面偵測回應連線到 Microsoft Sentinel
• Windows 用戶端裝置上的 Azure 監視器代理程式
• 使用 Azure 監視器代理程式從虛擬機器收集事件和效能計數器

使用適用於端點的 Microsoft Defender 監視 WDAC 適用於端點的 Microsoft Defender

下列範例示範使用者有數個應用程式用於組織的日常工作。 此範例包含 Microsoft 應用程式和各種開放原始碼應用程式。

由於範例處於強制 稽核模式，因此管理員 (可以看到它，但不會影響使用者) WinSCP、VLC、Putty 和 FileZilla 觸發的事件，因為這些應用程式不是初始稽核原則的一部分。

現在使用 Microsoft Defender 入口網站，輸入進階搜捕以縮小稽核事件範圍，以瞭解如果稽核模式停用，會發生哪些非預期/不想要的封鎖，因此在此範例中進入強制模式。

使用上一頁的參考架構，尋找過去 7 天內 WDAC 觸發的所有原則稽核事件，並使用範例鍵盤查詢語言 (KQL) 查詢來呈現相關資訊：

DeviceEvents 
| where ActionType startswith "AppControlCodeIntegrityPolicyAudited"
| where Timestamp > ago(7d)
| project DeviceId,                                  // The device ID where the audit block happened
    FileName,                                        // The audit blocked app's filename
    FolderPath,                                      // The audit blocked app's system path without the FileName
    InitiatingProcessFileName,                       // The file name of the parent process loading the executable
    InitiatingProcessVersionInfoCompanyName,         // The company name of the parent process loading the executable
    InitiatingProcessVersionInfoOriginalFileName,    // The original file name of the parent process loading the executable
    InitiatingProcessVersionInfoProductName,         // The product name of the parent process loading the executable
    InitiatingProcessSHA256,                         // The SHA256 flat hash of the parent process loading the executable
    Timestamp,                                       // The event creation timestamp
    ReportId,                                        // The report ID - randomly generated by MDE AH
    InitiatingProcessVersionInfoProductVersion,      // The product version of the parent process loading the executable
    InitiatingProcessVersionInfoFileDescription,     // The file description of the parent process loading the executable
    AdditionalFields                                 // Additional fields contains FQBN for signed binaries.  These contain the CN of the leaf certificate, product name, original filename and version of the audited binary

以下是使用先前 KQL 查詢的輸出範例。

在記錄中，有詳細的資訊報告，例如「程序樹狀結構」、「檔案路徑」、「SHA 資訊」、「簽署者」和「簽發者資訊」。

下一步是縮小結果範圍。

使用相同的 KQL 查詢，新增另一個欄位，其中 起始程式檔案名稱 是 Windows 檔案總管。 KQL 查詢會顯示使用者在 GUI 內執行的應用程式。

 DeviceEvents 
| where ActionType startswith "AppControlCodeIntegrityPolicyAudited"
| where Timestamp > ago(7d)
| where InitiatingProcessFileName startswith "explorer.exe" // Users starting an Application via File Explorer / GUI
| project DeviceId,                                  // The device ID where the audit block happened
    FileName,                                        // The audit blocked app's filename
    FolderPath,                                      // The audit blocked app's system path without the FileName
    InitiatingProcessFileName,                       // The file name of the parent process loading the executable
    InitiatingProcessVersionInfoCompanyName,         // The company name of the parent process loading the executable
    InitiatingProcessVersionInfoOriginalFileName,    // The original file name of the parent process loading the executable
    InitiatingProcessVersionInfoProductName,         // The product name of the parent process loading the executable
    InitiatingProcessSHA256,                         // The SHA256 flat hash of the parent process loading the executable
    Timestamp,                                       // The event creation timestamp
    ReportId,                                        // The report ID - randomly generated by MDE AH
    InitiatingProcessVersionInfoProductVersion,      // The product version of the parent process loading the executable
    InitiatingProcessVersionInfoFileDescription,     // The file description of the parent process loading the executable
    AdditionalFields                                 // Additional fields contains FQBN for signed binaries.  These contain the CN of the leaf certificate, product name, original filename and version of the audited binary

以下是使用先前 KQL 查詢的輸出範例。

KQL 查詢動作現在已將資訊縮小到更多管理資料集。 可以看到預期系統正在使用的應用程式。 這些應用程式必須新增至組織的原則，或視為透過組織變更控制新增。

WDAC – 更新稽核原則

使用適用於端點的 Microsoft Defender 和 WDAC 精靈更新稽核原則

使用 KQL 縮小搜尋結果範圍後，下一個步驟是更新 WDAC 基底原則或使用補充原則。 下一個範例使用補充原則。

1. 開啟 Windows Defender 應用程控精靈 ，然後選取 [原則建立者]。

2. 在 [原則建立者] 中，選取 [多個原則格式] 和 [補充原則]，流覽至您的基底原則，更新位置以儲存補充原則，然後選取 [ 下一步]。

3. 選取原則規則中的下一步。

4. 在 [ 原則簽署規則] 中，選取 [自訂規則]。

5. 在 自訂規則條件中，有許多選項可供使用：

   • 規則範圍 使用者模式規則/核心模式規則
   • 規則動作：允許/拒絕
   • 規則類型
     • 發布者 (推薦)
     • 檔案
     • 檔案屬性
     • 打包的應用程序
     • 刴
   • 參考檔案

使用適用於端點的 Microsoft Defender

1. 在 搜尋 中搜尋檔案名稱，然後導航到檔案資訊並下載檔案。
2. 直接從進階搜捕檢查記錄，並下載檔案，然後下載所需的二進位檔。
3. 使用必要的二進位檔，接下來繼續為組織的 ISV 應用程式建立另一個原則。
4. 在 Windows Defender 應用程控精靈中，選取所需的 規則類型 ，然後流覽至上一個步驟中的參考二進位檔。 下一個範例示範 VLC 符合所需的發佈者資訊。

5. 按下一步並創建。
6. 使用先前「透過 Microsoft Intune 部署 Windows Defender 應用程式控制稽核原則」一節中所述的步驟來部署此補充原則。

WDAC – 切換以強制執行原則

若要切換至強制執行原則：

1. 開啟 Windows Defender 應用程控精靈，然後選取原則編輯器。

2. 導覽至要變更為強制執行的原則 XML。

3. 停用原則規則中的稽核模式開關。

4. 選取原則規則中的下一步。

5. 使用修改的版本號碼建立 更新原則 ，並建立新的 CIP 檔案。

6. 在 Microsoft Endpoint Manager 管理員中心內，移至 [裝置]，然後移至 [組態配置檔]。

7. 接下來，建立設定檔、平台 – Windows 10 或更新版本、設定檔類型範本和自訂。

8. 建立原則的名稱，例如應用程式控制 - 強制執行原則，然後選取 下一步。

9. 在 [OMA-URI 設定] 底下，選取 [新增]。

   注意事項

   此資訊相依於從上述建立稽核區段建立的原則 XML 從 Windows Defender 應用程控精靈產生的原則識別碼。
   
   - 名稱 = Microsoft 允許強制執行
   - OMA-URL = ./Vendor/MSFT/ApplicationControl/Policies/CB46B243-C19C-4870-B098-A2080923755C/Policy
   - 資料類型 = Base64 (檔案)

10. 當 Windows Defender 應用程控精靈產生原則 XML 時，也會建立 (GUID) 。CIP 檔案。 下一步是複製此 CIP 文件並將文件擴展名重命名為。BIN 例如 {CB46B243-C19C-4870-B098-A2080923755C}.bin。

11. 上傳 Base64 下的 BIN， (檔案) 。

12. 選取 [儲存]。

13. 依照提示建立 設定檔。

14. 部署 應用程式控制 – 將原則 組態設定檔強制執行至預期系統。

    注意事項

    管理員需要從要切換以強制執行的預期系統中排除先前建立的應用程式 - 稽核原則