了解商務用應用程控原則規則和檔案規則
注意
商務用應用程控的某些功能僅適用於特定的 Windows 版本。 深入了解 應用程控功能可用性。
商務用應用程控可藉由設定原則來指定驅動程式或應用程式是否受信任，以控制在 Windows 裝置上執行的內容。 原則包含原則 規則 ，可控制稽核模式等選項，以及 ( 或 檔案規則層級) ，以指定如何識別組織信任的應用程式。
商務用應用程控原則規則
若要修改現有應用程控原則 XML 的原則規則選項，請使用 應用程控原則精 靈或 Set-RuleOption PowerShell Cmdlet。
您可以在應用程控原則內設定數個規則選項。 表 1 描述每個規則選項，以及補充原則是否可以設定它們。 有些規則選項會保留供未來工作使用，或不支援。
注意
我們建議您一開始使用 Enabled：Audit 模式 ，因為它可讓您先測試新的應用程控原則，再強制執行這些原則。 使用稽核模式時，應用程式會正常執行，但每當原則不允許的檔案執行時，應用程控就會記錄事件。 若要允許這些檔案，您可以從事件記錄檔擷取原則資訊，然後將該資訊合併到現有的原則中。 刪除 Enabled：Audit 模式 時，原則會以強制模式執行。
即使您的原則處於稽核模式，某些應用程式的行為也可能不同。 當選項可能會在稽核模式中變更行為時，請參閱表 1。 將重大更新部署至應用程控原則時，您應該一律徹底測試應用程式。
表 1. 商務用應用程控原則 - 原則規則選項
| 規則選項 | 描述 | 有效的補充選項 |
|---|---|---|
| 0 啟用：UMCI | 應用程控原則會同時限制內核模式和使用者模式二進位檔。 根據預設，只有核心模式二進位檔案會受到限制。 啟用此規則選項會驗證使用者模式的可執行檔和指令碼。 | 否 |
| 1 啟用：開機功能表保護 | 目前不支援此選項。 | 否 |
| 2 必要：WHQL | 根據預設，未簽署 WHQL (WHQL) 的核心驅動程式可以執行。 啟用此規則需要每個驅動程式都已簽署 WHQL，並移除舊版驅動程序支援。 針對 Windows 10 建置的核心驅動程式應經過 WHQL 認證。 | 否 |
| 3 啟用：稽核模式 (預設值) | 指示應用程控在強制執行原則時，記錄已封鎖之應用程式、二進制檔和腳本的相關信息。 您可以使用此選項來識別應用程控原則的潛在影響，並在強制執行之前使用稽核事件來精簡原則。 若要強制執行應用程控原則，請刪除此選項。 | 否 |
| 4 停用：正式發行前小眾測試版簽署 | 如果啟用，就不會信任來自 Windows 測試人員組建的二進位檔。 此選項適用於只想要執行已發行的二進位檔，而不是發行前版本 Windows 組建的組織。 | 否 |
| 5 啟用：繼承預設原則 | 此選項保留供日後使用，目前沒有任何作用。 | 是 |
| 6 啟用：未簽署的系統完整性原則 (預設值) | 允許原則維持未簽署。 拿掉此選項時，必須簽署原則，而且也必須簽署任何補充原則。 未來原則更新所信任的憑證必須在 UpdatePolicySigners 區段中識別。 在 SupplementalPolicySigners 區段中，必須識別受補充原則信任的憑證。 | 是 |
| 7 允許：增強偵錯原則 | 目前不支援此選項。 | 是 |
| 8 必要：EV 簽署者 | 目前不支援此選項。 | 否 |
| 9 啟用：進階開機選項功能表 | 預設會停用所有應用程控原則的 F8 開機前功能表。 設定這個規則選項可對實際存在的使用者顯示 F8 功能表。 | 否 |
| 10 啟用：失敗時執行開機稽核 | 當應用程控原則處於強制模式時使用。 當開機關鍵驅動程式在啟動期間失敗時，應用程控原則會處於稽核模式，讓 Windows 載入。 系統管理員可以驗證 CodeIntegrity 事件記錄檔中失敗的原因。 | 否 |
| 11 停用：指令碼強制執行 | 這個選項會停用腳本強制執行選項，包括 PowerShell、Windows 腳本主機 (wscript.exe) 、Windows 控制台型腳本主機 (cscript.exe) 、在 Microsoft HTML 應用程式主機 (mshta.exe) 中執行的 HTA 檔案，以及 MSXML。 即使您的原則處於稽核模式，某些腳本主機的行為也可能不同。 如需腳本強制執行的詳細資訊，請參閱使用 應用程控執行腳本。 注意：Windows Server 2016 或 Windows 10 1607 LTSB 上不支援此選項，因此不應該在這些操作系統上使用。 |
否 |
| 12 必要：強制執行 Store 應用程式 | 如果啟用此規則選項，應用程控原則也會套用至通用 Windows 應用程式。 | 否 |
| 13 啟用：受管理的安裝程式 | 使用這個選項可自動允許受管理安裝程式所安裝的應用程式。 如需詳細資訊，請 參閱授權使用應用程控管理的安裝程式部署的應用程式 | 是 |
| 14 啟用：Intelligent Security Graph 授權 | 使用此選項可自動允許具有「已知良好」信譽的應用程式，如Microsoft的 Intelligent Security Graph (ISG) 所定義。 | 是 |
| 15 啟用：在重新開機時使 EA 失效 | 使用 Intelligent Security Graph 選項 (14) 時，應用程控會設定擴充檔屬性，指出檔案已獲授權執行。 此選項會導致應用程控定期重新驗證先前由ISG授權之檔案的信譽。 | 否 |
| 16 啟用：更新原則而不重新開機 | 使用此選項可允許未來套用應用程控原則更新，而不需要系統重新啟動。 注意：只有 Windows 10 版本 1709 和更新版本或 Windows Server 2019 和更新版本才支援此選項。 |
否 |
| 17 已啟用：允許補充原則 | 在基底原則上使用此選項，以允許補充原則加以擴充。 注意：只有 Windows 10 版本 1903 和更新版本或 Windows Server 2022 和更新版本才支援此選項。 |
否 |
| 18 已停用：運行時間 FilePath 規則保護 | 此選項會停用預設運行時間檢查，只允許只有系統管理員可寫入之路徑的 FilePath 規則。 注意：只有 Windows 10 版本 1903 和更新版本或 Windows Server 2022 和更新版本才支援此選項。 |
是 |
| 19 已啟用：動態程式碼安全性 | 啟用 .NET 應用程式和動態載入連結庫的原則強制執行。 注意：只有 Windows 10 版本 1803 和更新版本或 Windows Server 2019 和更新版本才支援此選項。 注意：如果 有任何 應用程控 UMCI 原則啟用此選項，則一律會強制執行此選項。 .NET 動態程式代碼安全性強化沒有稽核模式。 |
否 |
| 20 已啟用：撤銷已過期為未簽署 | 在企業簽署案例下，使用此選項將使用已撤銷憑證簽署的二進制檔，或簽章上具有存留期簽署 EKU 的過期憑證，視為使用者模式進程/元件的「未簽署二進位檔」。 | 否 |
| 已啟用：開發人員模式動態程式代碼信任 | 使用此選項可信任 在 Visual Studio 中偵錯 的 UWP 應用程式，或在系統上啟用開發人員模式時透過裝置入口網站部署的 UWP 應用程式。 | 否 |
商務用應用程控檔案規則層級
檔案規則層級可讓系統管理員指定他們信任其應用程式的層級。 此信任層級可以與每個二進位檔的哈希一樣細微，或一般為 CA 憑證。 使用應用程控精靈或應用程控 PowerShell Cmdlet 來建立和修改原則時，您可以指定檔案規則層級。
每個檔案規則層級都有優缺點。 使用表 2 為可用的系統管理資源和應用程控部署案例選取適當的保護層級。
注意
應用程控簽署者型規則僅適用於密鑰長度上限為 4096 位的 RSA 密碼編譯。 不支援 ECC 演算法，例如 ECDSA。 如果您嘗試根據 ECC 簽章依簽章來允許檔案，您會在相對應的 3089 簽章資訊事件中看到 VerificationError = 23。 哈希或文件屬性規則可以改為允許檔案，如果檔案也使用 RSA 以簽章簽署，則可以使用其他簽署者規則。
表 2. 商務用應用程控原則 - 檔案規則層級
| 規則層級 | 說明 |
|---|---|
| Hash | 為每個探索到的二進位檔指定個別 的 Authenticode/PE 影像哈希值 。 這個層級是最特定的層級，而且需要投入更多心力來維護目前產品版本的哈希值。 每次更新二進位檔案時雜湊值就會變更，因此需要更新原則。 |
| FileName | 指定每個二進位檔的原始檔名。 雖然更新時會修改應用程式的雜湊值，但檔案名稱通常不會。 此層級提供比哈希層級更不明確的安全性，但在修改任何二進位檔時，通常不需要更新原則。 根據預設，這個層級會使用檔案資源標頭的 OriginalFileName 屬性。 使用 -SpecificFileNameLevel 選擇替代屬性，例如 ProductName。 |
| FilePath | 從 Windows 10 1903 版開始，此層級允許從特定檔案路徑位置執行二進位檔。 FilePath 規則只適用於使用者模式二進位檔，不能用來允許內核模式驅動程式。 如需 FilePath 層級規則的詳細資訊，請參閱本文稍後。 |
| SignedVersion | 這個層級會將發行者規則與版本號碼結合。 它可讓任何專案從指定的發行者執行，其版本位於或高於指定的版本號碼。 |
| 發行者 | 此層級結合 PcaCertificate 層級 (通常在根) 下方有一個憑證，以及分葉憑證的一般名稱 (CN) 。 您可以使用此規則層級來信任特定 CA 所發行的憑證，並發行給您信任的特定公司 (，例如 Intel，適用於設備驅動器) 。 |
| FilePublisher | 此層級結合已簽署檔案的 「FileName」 屬性，加上 「Publisher」 (PCA 憑證與分葉) 的 CN，再加上最低版本號碼。 此選項信任來自指定發行者的特定檔案 (版本等於或高於指定的版本號碼)。 根據預設，這個層級會使用檔案資源標頭的 OriginalFileName 屬性。 使用 -SpecificFileNameLevel 選擇替代屬性，例如 ProductName。 |
| LeafCertificate | 在個別的簽署憑證層級新增信任的簽署者。 使用此層級與個別哈希層級的優點是，新版本的產品有不同的哈希值，但通常是相同的簽署憑證。 使用此層級時，不需要更新原則即可執行新版本的應用程式。 不過，分葉憑證的有效期間通常比其他憑證層級短，因此只要這些憑證變更，就必須更新應用程控原則。 |
| PcaCertificate | 將提供的憑證鏈結中最高的可用憑證新增給簽署者。 此層級通常是根目錄下方的一個憑證，因為掃描不會透過本機根存放區或在線檢查來解析完整的憑證鏈結。 |
| RootCertificate | 不支援。 |
| WHQL | 僅信任已提交至 Microsoft 並由 Windows 硬體資格實驗室 (WHQL) 簽署的二進位檔。 此層級主要用於核心二進位檔。 |
| WHQLPublisher | 此層級結合分葉憑證上的 WHQL 層級和 CN，主要用於核心二進位檔。 |
| WHQLFilePublisher | 這個層級結合了已簽署檔案的 “FileName” 屬性加上 “WHQLPublisher”，再加上最低版本號碼。 此層級主要用於核心二進位檔。 根據預設，這個層級會使用檔案資源標頭的 OriginalFileName 屬性。 使用 -SpecificFileNameLevel 選擇替代屬性，例如 ProductName。 |
注意
當您使用 New-CIPolicy 建立應用程控原則時，可以藉由包含 -Level 參數來指定主要檔案規則層級。 如果發現有二進位檔案無法根據主要的檔案規則條件信任，請使用 –Fallback 參數。 例如，如果主要檔案規則層級是 PCACertificate，但您也想要信任未簽署的應用程式，則使用哈希規則層級作為後援會新增沒有簽署憑證之二進位檔的哈希值。
注意
適用時，在原則 XML 中，檔案規則中的最低和最大版本號碼會分別參考為 MinimumFileVersion 和 MaximumFileVersion。
- 指定 MinimumFileVersion 和 MaximumFileVersion：針對 [允許規則]，允許版本 大於或等於 MinimumFileVersion 且 小於或等於 MaximumFileVersion 的檔案。 針對拒絕規則，版本 大於或等於 MinimumFileVersion 且 小於或等於 MaximumFileVersion 的檔案會遭到拒絕。
- 未指定 MaximumFileVersion 的 MinimumFileVersion：針對 [允許規則]，允許執行版本 大於或等於 指定版本的檔案。 針對拒絕規則，版本 小於或等於 指定版本的檔案會遭到封鎖。
- 未指定 MinimumFileVersion 的 MaximumFileVersion：針對 [允許規則]，允許執行版本 小於或等於 指定版本的檔案。 針對拒絕規則，版本 大於或等於 指定版本的檔案會遭到封鎖。
使用中的檔案規則層級範例
例如，假設在執行許多伺服器的部門中有IT專業人員。 他們只想要執行由提供其硬體、操作系統、防病毒軟體和其他重要軟體的公司所簽署的軟體。 他們明白伺服器亦會執行未簽署但鮮少更新的內部寫入應用程式。 他們想要允許執行此應用程式。
若要建立應用程控原則，他們會在其標準硬體上建置參照伺服器，並安裝其伺服器已知要執行的所有軟體。 然後他們使用 -Level Publisher 執行 New-CIPolicy (允許來自軟體供應商的軟體，「發佈者」) 和 -Fallback Hash (允許內部未簽署應用程式)。 他們會在稽核模式中部署原則，以判斷強制執行原則的潛在影響。 在稽核數據的協助下，他們會更新其應用程控原則，以包含他們想要執行的任何其他軟體。 然後，他們會在其伺服器的強制模式中啟用應用程控原則。
在一般作業中，他們最終會安裝軟體更新，或是從相同的軟體提供者新增軟體。 因為「發行者」在這些更新和軟體上維持不變，所以不需要更新其應用程控原則。 如果未簽署的內部應用程式已更新，則也必須更新應用程控原則以允許新版本。
檔案規則優先順序順序
應用程控具有內建的檔案規則衝突邏輯，可轉譯為優先順序順序。 它會先處理它找到的所有明確拒絕規則。 然後，它會處理任何明確的允許規則。 如果沒有拒絕或允許規則存在，如果原則允許，應用程控會檢查 Managed Installer 宣告 。 最後，如果原則允許，應用程控會回復為 ISG 。
注意
為了讓您更輕鬆地推理應用程控原則，建議您在支援 多個應用程控原則的 Windows 版本上維護個別的 ALLOW 和 DENY 原則。
搭配 FileName、FilePublisher 或 WHQLFilePublisher 層級規則使用 -SpecificFileNameLevel
根據預設，FileName、FilePublisher 和 WHQLFilePublisher 規則層級會使用來自檔案資源標頭的 OriginalFileName 屬性。 您可以藉由設定 -SpecificFileNameLevel，為規則使用替代的資源標頭屬性。 例如，軟體開發人員可能會針對屬於應用程式的所有二進位檔使用相同的 ProductName。 使用 -SpecificFileNameLevel，您可以建立單一規則來涵蓋原則中的所有二進位檔，而不是每個檔案的個別規則。
表 3 描述您可以使用 -SpecificFileNameLevel 設定的可用資源標頭屬性選項。
表 3. -SpecificFileNameLevel 選項
| SpecificFileNameLevel 值 | 描述 |
|---|---|
| FileDescription | 指定二進位檔開發人員所提供的檔案描述。 |
| InternalName | 指定二進位檔的內部名稱。 |
| OriginalFileName | 指定二進位檔的原始檔名，或第一次建立檔案的名稱。 |
| PackageFamilyName | 指定二進位檔的套件系列名稱。 套件系列名稱包含兩個部分：檔案名稱和發行者標識符。 |
| ProductName | 指定二進位檔隨附的產品名稱。 |
| Filepath | 指定二進位檔的檔案路徑。 |
檔案路徑規則的詳細資訊
Filepath 規則不會提供與明確簽署者規則相同的安全性保證，因為它們是以可變動的訪問許可權為基礎。 Filepath 規則最適合大部分用戶以標準而非系統管理員身分執行的環境。路徑規則最適合允許您預期只保留管理員可寫入的路徑。 您可能想要避免目錄的路徑規則，其中標準使用者可以修改資料夾上的 ACL。
用戶可寫入的檔案路徑
根據預設，應用程控會在運行時間執行使用者寫入能力檢查，以確保指定之檔案路徑的目前許可權只允許系統管理員使用者的寫入存取權。
有一份定義的 SID 清單，應用程控可辨識為系統管理員。 如果 filepath 允許任何不在此清單中之 SID 的寫入許可權，即使 SID 與自定義系統管理員使用者相關聯，filepath 也會被視為使用者可寫入。 若要處理這些特殊案例，您可以使用稍早所述的 Disabled ：Runtime FilePath Rule Protection 選項覆寫應用程控的運行時間系統管理員可寫入檢查。
應用程式控制的已知系統管理員 SID 清單如下：
S-1-3-0;S-1-5-18;S-1-5-19;S-1-5-20;S-1-5-32-544;S-1-5-32-549;S-1-5-32-550;S-1-5-32-551;S-1-5-32-577;S-1-5-32-559;S-1-5-32-568;S-1-15-2-1430448594-2639229838-973813799-439329657-1197984847-4069167804-1277922394;S-1-15-2-95739096-486727260-2033287795-3853587803-1685597119-444378811-2746676523。
使用 New-CIPolicy 產生 filepath 規則時，系統會針對掃描路徑中探索到的每個檔案產生唯一的完整路徑規則 () 。 若要建立規則，改為允許指定資料夾路徑下的所有檔案，請使用 New-CIPolicyRule 來定義包含通配符的規則，使用 -FilePathRules 參數。
在應用程控檔案路徑規則中使用通配符
下列通配符可用於應用程控檔案路徑規則：
| 通配符 | 意義 | 支援的作業系統 |
|---|---|---|
* |
比對零個或多個字元。 | Windows 11、Windows 10 和 Windows Server 2022 |
? |
比對單一字元。 | 僅限 Windows 11 |
當確切的磁碟區可能有所不同時，您也可以使用下列巨集： %OSDRIVE%、 %WINDIR%、 %SYSTEM32%。 這些巨集可以與上述通配符搭配使用。
注意
在 Windows 11 上，您可以在 filepath 規則內的任何位置使用一或多個通配符。
在所有其他 Windows 和 Windows Server 版本上，每個路徑規則 只允許一個 通配符 ，而且必須在路徑規則的開頭或結尾。
使用通配符的範例檔案路徑規則
| 範例 | 描述 | 支援的作業系統 |
|---|---|---|
|
C：\Windows\* D：\EnterpriseApps\MyApp\* %OSDRIVE%\Windows\* |
放置在路徑結尾的通配符會以遞歸方式授權立即路徑及其子目錄中的所有檔案。 | Windows 11、Windows 10 和 Windows Server 2022 |
| *\bar.exe | 放置在路徑開頭的通配符允許在任何位置中指定的確切檔名。 | Windows 11、Windows 10 和 Windows Server 2022 |
|
C：\*\CCMCACHE\*\7z????-x64.exe %OSDRIVE%\*\CCMCACHE\*\7z????-x64.exe |
路徑中間使用的通配符允許符合該模式的所有檔案。 請仔細考慮所有可能的相符專案，特別是當您的原則使用 Disabled ：Runtime FilePath Rule Protection 選項停用系統管理員可寫入檢查時。 在此範例中，這兩個假設路徑會相符：C:\WINDOWS\CCMCACHE\12345\7zabcd-x64.exe C:\USERS\AppControlUSER\Downloads\Malware\CCMCACHE\Pwned\7zhaha-x64.exe |
僅限 Windows 11 |
如果沒有通配符，filepath 規則只允許特定檔案 (例如 C:\foo\bar.exe) 。
注意
使用 Configuration Manager 撰寫應用程控原則時，可以選擇為指定的檔案和資料夾建立規則。 這些規則 不是 應用程控檔案路徑規則。 相反地，Configuration Manager 對指定的檔案和資料夾執行一次性掃描，並針對在掃描時在這些位置找到的任何二進位檔建置規則。 除非重新套用 Configuration Manager 原則，否則不允許在掃描之後變更這些指定檔案和資料夾的檔案。
哈希的詳細資訊
應用程控會在計算檔案的哈希時使用 Authenticode/PE 影像哈希演算法 。 不同於較常見的 一般檔案哈希，Authenticode 哈希計算會省略檔案的總和檢查碼、憑證數據表和屬性憑證數據表。 因此，變更檔案的簽章和時間戳，或從檔案移除數字簽名時，檔案的 Authenticode 哈希不會變更。 在 Authenticode 哈希的協助下，應用程控可提供額外的安全性和較少的管理額外負荷，讓客戶不需要在更新檔案上的數位簽名時修改原則哈希規則。
Authenticode/PE 映射哈希可以針對數字簽署和未簽署的檔案計算。
為什麼掃描會為每個 XML 檔案建立四個哈希規則？
PowerShell Cmdlet 會產生 Authenticode Sha1 哈希、Sha256 哈希、Sha1 頁面哈希、Sha256 頁面哈希。 在驗證期間，應用程控會根據檔案的簽署方式和使用檔案的案例，選取要計算的哈希。 例如，如果檔案已簽署頁面哈希，應用程控會驗證檔案的每個頁面，並避免將整個檔案載入記憶體中，以計算完整的sha256 authenticode 哈希。
在 Cmdlet 中，我們不會嘗試預測將使用哪個哈希，而是預先計算並使用第一頁) 的四個哈希 (sha1/sha2 authenticode 和 sha1/sha2。 此方法也可復原檔案簽署方式的變更，因為您的應用程控原則已經有一個以上的哈希可供檔案使用。
為什麼掃描會為特定檔案建立八個哈希規則？
系統會為 UMCI 和 KMCI 建立個別規則。 如果 Cmdlet 無法判斷檔案只在使用者模式或核心中執行，則會基於謹慎考慮而針對這兩個簽署案例建立規則。 如果您知道特定檔案只會在使用者模式或核心中載入，則可以安全地移除額外的規則。
應用程控何時會使用一般檔案哈希值？
在某些情況下，檔案的格式不符合 Authenticode 規格，因此應用程控會回復為使用一般檔案哈希。 這種行為可能會因為許多原因而發生，例如，如果在運行時間對檔案的記憶體內部版本進行變更。 在這種情況下，您會看到相互關聯的 3089 簽章資訊事件中顯示的哈希符合來自 3076/3077 區塊事件的一般檔案哈希。 若要為格式無效的檔案建立規則，您可以使用應用程控精靈或直接編輯原則 XML，將哈希規則新增至一般檔案哈希的原則。