注意
商務用應用程控的某些功能僅適用於特定的 Windows 版本。 深入了解 應用程控功能可用性。
本文涵蓋適用於系統管理員的秘訣和訣竅，以及商務用應用程控的已知問題。 在生產環境中啟用此組態之前，請先在實驗室中測試此設定。
管理員 秘訣和提示
應用程控原則檔案位置
視原則是否簽署，以及所使用的原則部署方法而定，下列位置會找到多個原則格式的應用程控原則。
- <OS 磁盘區>\Windows\System32\CodeIntegrity\CiPolicies\Active\{PolicyId GUID}.cip
- <EFI 系統分割區>\Microsoft\Boot\CiPolicies\Active\{PolicyId GUID}.cip
{PolicyId GUID} 值是原則唯一的值，並以 PolicyId> 元素定義於原則 XML <中。
針對 單一原則格式應用程控原則，除了上述兩個位置之外，也請在下列位置尋找名為 SiPolicy.p7b 的檔案：
- <EFI 系統分割區>\Microsoft\Boot\SiPolicy.p7b
- <OS 磁盘區>\Windows\System32\CodeIntegrity\SiPolicy.p7b
注意
使用單一原則格式 GUID {A244370E-44C9-4C06-B551-F6016E563076} 的多個原則格式應用程控原則可能會存在於任何原則檔案位置下。
檔案規則優先順序順序
當應用程控引擎根據裝置上的作用中原則集評估檔案時，規則會以下列順序套用。 一旦檔案遇到相符專案，應用程控就會停止進一步處理。
任何符合明確拒絕規則的檔案都會遭到封鎖，即使您建立其他規則來嘗試允許它也一樣。 拒絕規則可以使用任何 規則層級。 建立拒絕規則時，請使用最實際的規則層級，以避免封鎖超出您預期的程度。
任何符合明確允許規則的檔案都會執行。
如果原則 (受管理 的安裝程式 或ISG) 啟用比對選項，則具有 Managed Installer 或 Intelligent Security Graph (ISG ) 擴充屬性 (EA) 執行的任何檔案。
根據上述條件不允許的任何檔案，在原則中啟用該選項時，會使用ISG來檢查其信譽。 如果ISG決定它是安全的，而且檔案上寫入了新的ISG EA，檔案就會執行檔案。
明確規則或根據ISG或受管理的安裝程序不允許的任何檔案都會隱含封鎖。
已知問題
稽核模式中的應用程控原則可能會影響裝置上的效能
當檔案根據目前的應用程控原則集合進行評估時，應用程控引擎會在傳遞使用中原則時，將核心擴充屬性設定 (EAS) 。 稍後，如果執行相同的檔案，只要作用中的原則保持不變，應用程控就會檢查 IA 並重複使用快取的結果。 此快取機制可確保應用程控會在許多原則作用中且包含大量規則時進行調整。 不過，此效能優化不會用於稽核模式中的原則。 在某些情況下，相較於具有稽核原則的系統，您可能會發現只有強制執行原則之系統之間的效能差異。
當雲端檢查許多檔案時，[Intelligent Security Graph (ISG) ] 選項可能會影響效能
ISG 選項是應用程控的極重要功能，可簡化管理個別檔案和應用程式規則的複雜性。 但是，由於其依賴雲端型人工智慧 (AI) 模型，因此您應該避免依賴 ISG 來決定您需要執行的重要應用程式和檔案。 不建議對重要工作負載、Windows OS 程式代碼依賴 ISG，尤其是在開機期間執行的程式代碼，或效能最為重要的情況。 您應該盡可能確保原則中有明確的規則，或使用受管理的安裝程式而非ISG來減少原則管理額外負荷。
在考慮您對ISG效能影響的承受度時，也請考慮 上述問題對稽核模式原則效能造成影響的額外效能影響。 請嘗試避免在稽核模式中執行嚴重依賴大量檔案之ISG授權的原則。
如果有超過 32 個原則在作用中， (藍色畫面) 發生開機停止失敗
在您套用 2024 年 4 月 9 日或之後發行的 Windows 安全性更新之前，您的裝置僅限 32 個使用中原則。 如果超過原則數目上限，則參照 ci.dll 的裝置藍屏錯誤檢查值為 0x0000003b。 規劃您的應用程控原則時，請考慮此原則計數上限。 裝置上作用 中的任何 Windows 收件匣原則 也都會計入此限制。 若要移除最大原則限制，請安裝在 2024 年 4 月 9 日或之後發行的 Windows 安全性更新，然後重新啟動裝置。 否則，請減少裝置上的原則數目，保持低於 32 個原則。
注意
原則限制未在 Windows 11 21H2 上移除，且仍受限於 32 個原則。
稽核模式原則可能會變更某些應用程式的行為，或導致應用程式當機
雖然應用程控稽核模式是設計來避免對應用程式造成任何影響，但某些功能一律會使用任何開啟/一律強制執行的應用程控原則，其會開啟使用者模式程式代碼完整性 (UMCI) 選項 0 Enabled：UMCI。 以下是稽核模式中的已知系統變更清單：
- 某些腳本主機可能會封鎖程序代碼，或以較少的許可權執行程序代碼，即使在稽核模式中也一樣。 如需個別腳本主機行為的相關信息，請參閱使用 應用程控 執行腳本。
- 選項 19 已啟用：如果任何 UMCI 原則在某些版本的 Windows 和 Windows Server 上包含該選項，則一律會強制執行動態程式碼安全性。 請參閱 應用程控和 .NET。
.NET 原生映射可能會產生誤判區塊事件
在某些情況下，撰寫商務用應用程控錯誤和警告的程式代碼完整性記錄包括針對 .NET 元件產生的原生映射的錯誤事件。 一般而言，原生映射區塊在功能上是良性的，因為封鎖的原生映像會回復到其對應的元件，而 .NET 會在下一個排程的維護期間重新產生原生映射。 若要避免這種情況，請事先將 .NET 應用程式編譯成 原生程序代碼 功能。
.NET 不會載入元件物件模型 (COM) GUID 不相符的物件
COM 物件可讓不同的軟體元件輕鬆地進行通訊和共同作業。 若要供另一個元件使用，COM 對象必須向作系統註冊。 註冊包含根據物件的程式代碼計算的 GUID。 COM 物件的載入和啟用是使用名為類型名稱之註冊的另一個部分來完成。 有時候，已註冊的 GUID 與已啟動之 COM 物件程式代碼的實際 GUID 之間會出現不相符的情況。 不相符可能來自應用程式的 COM 物件註冊程式代碼中的錯誤，或是 COM 物件的程式代碼變更的方式會影響 GUID。 一般而言，Windows 和 .NET 是關於此條件的，不論是執行 COM 物件的程序代碼。 但是，允許 COM 物件在 GUID 不相符的情況下載入，讓系統容易受到攻擊者攻擊，攻擊者可能會利用 GUID 混淆來執行非預期的程式代碼。
為了提高應用程控在容易受到此攻擊技術之系統上的保護效率，.NET 會套用額外的驗證，以檢查已註冊的 COM 物件 GUID 是否符合系統計算的 GUID。 如果發現不符，.NET 不會載入 COM 物件，而且會引發一般 COM 載入錯誤。 使用具有此條件之 COM 物件的應用程式可能會以非預期的方式運作，而且必須更新以修正應用程式的 COM 物件註冊程式代碼問題。
由於只有在使用者模式程式代碼上強制執行應用程控原則時，才會發生此行為，因此您無法在稽核模式中偵測到它。 當 COM 對象因為額外的驗證檢查而無法載入時，沒有任何記錄或其他事件。 修復或重新安裝應用程式可以暫時解決問題，但需要應用程式更新才能修正 COM 註冊問題，並防止未來發生問題。
沒有原則控制選項可管理 。NET 的 GUID 驗證檢查，表示一律會執行檢查。 如果您在部署應用程控原則之後看到 COM 物件失敗，請連絡軟體開發人員或獨立軟體廠商 (ISV) ，以要求修正問題。
不支援使用橢圓曲線密碼編譯 (ECC) 的簽章
應用程控簽署者型規則僅適用於 RSA 密碼編譯。 不支援 ECC 演算法，例如 ECDSA。 如果應用程控根據 ECC 簽章封鎖檔案，則對應的 3089 簽章資訊事件會顯示 VerificationError = 23。 您可以改為透過哈希或檔屬性規則來授權檔案，如果檔案也使用 RSA 以簽章簽署，則可以使用其他簽署者規則。
當 FilePath 規則允許時，MSI 安裝程式會被視為可在 Windows 10 上寫入的使用者
MSI 安裝程式檔案一律會在 Windows 10 上偵測為用戶可寫入，Windows Server 2022 及更早版本。 如果您需要使用 FilePath 規則來允許 MSI 檔案，您必須在應用程控原則中設定選項 18 Disabled：Runtime FilePath Rule Protection 。
直接從因特網啟動的 MSI 安裝程式遭到封鎖
將 .msi 檔案直接從因特網安裝到受應用程控保護的計算機時失敗。 例如，此指令失敗：
msiexec -i https://download.microsoft.com/download/2/E/3/2E3A1E42-8F50-4396-9E7E-76209EA4F429/Windows10_Version_1511_ADMX.msi
因應措施是下載 MSI 檔案並在本機執行：
msiexec -i c:\temp\Windows10_Version_1511_ADMX.msi
使用自定義原則的慢速開機和效能
應用程控會評估所有執行的進程，包括收件匣 Windows 進程。 如果您的原則不是以應用程控範本為基礎，或是不信任 Windows 簽署者，則可能會導致開機時間變慢、效能降低，而且可能會發生開機問題。 基於這些理由，您應該盡可能使用 應用程控基底範本 來建立原則。
AppId 標記原則會評估不在標記範圍內的 DLL 檔案
當您使用AppId標記原則時，結果會是元數據“tags”，新增至傳遞原則之任何可執行文件的進程令牌。 然後，您可以使用標記來變更瞭解 AppId 標籤的應用程式或元件行為，並在進程上尋找相符的標記。 例如，您可以設定使用自定義標籤的 Windows 防火牆規則，以識別應該允許透過防火牆連線的進程。 AppId 標籤僅適用於 EXE) (可執行檔，且永遠不會套用至其他類型的程式代碼，例如動態連結庫 (DLL) 。 但是當 DLL 執行時，應用程控會根據您的原則評估檔案，除非有規則允許該類型的所有檔案。 若要縮短 DLL 的線路原則評估，並進一步降低應用程控對效能的影響，請將下列規則新增至 AppId 標記原則：
