建立應用程控拒絕原則的指引

發行項
10/01/2024
適用於:

✅ Windows 11, ✅ Windows 10

使用商務用應用程控，您可以建立原則來明確拒絕特定驅動程式和應用程式。若要建立有效的商務用應用程控拒絕原則，您應該瞭解應用應用程控在根據使用中原則評估檔案時所套用的規則優先順序順序。

獨立拒絕原則

建立只包含拒絕規則的原則時，除了明確的拒絕規則之外，您必須在原則的核心和使用者模式區段中包含「全部允許」規則。「全部允許」規則可確保允許執行原則未明確拒絕的任何專案。如果您無法將「全部允許」規則新增至僅限拒絕的原則，則有封鎖所有項目的風險。之所以會發生此結果，是因為某些程式代碼 遭到明確 拒絕，而且所有其他程式代碼會 隱含拒絕 ，因為沒有任何規則可授權它。建議您在建立獨立拒絕原則時使用 AllowAll 原則範本。

<FileRules>
  <Allow ID="ID_ALLOW_A_1" FriendlyName="Allow Kernel Drivers" FileName="*" />
  <Allow ID="ID_ALLOW_A_2" FriendlyName="Allow User mode components" FileName="*" />
</FileRules>
<SigningScenarios>
    <SigningScenario Value="131" ID="ID_SIGNINGSCENARIO_DRIVERS" FriendlyName="Kernel Mode Signing Scenario">
      <ProductSigners>
        <FileRulesRef>
          <FileRuleRef RuleID="ID_ALLOW_A_1" />
        </FileRulesRef>
      </ProductSigners>
    </SigningScenario>
    <SigningScenario Value="12" ID="ID_SIGNINGSCENARIO_WINDOWS" FriendlyName="User Mode Signing Scenario">
      <ProductSigners>
        <FileRulesRef>
          <FileRuleRef RuleID="ID_ALLOW_A_2" />
        </FileRulesRef>
      </ProductSigners>
    </SigningScenario>
</SigningScenarios>

新增上述「全部允許」規則並不會影響您已部署並套用明確允許清單的任何其他應用程控原則。若要說明，請考慮下列範例：

Policy1 是 Windows 和Microsoft簽署應用程式的允許清單。

Policy2 是我們新的拒絕原則，可封鎖 MaliciousApp.exe 和 Windows 元件二進位 wmic.exe。它也包含「全部允許」規則。

MaliciousApp.exe 遭到封鎖，因為 Policy2 中有明確的封鎖規則。它也會被 Policy1 隱含封鎖 ，因為沒有任何允許規則涵蓋該原則中的檔案。
因為 Policy2 中有明確的封鎖規則，所以會封鎖 Windows 簽署的檔案 wmic.exe。
允許所有其他 Windows 和Microsoft簽署的應用程式，因為 Policy1 和 Policy2 中都有涵蓋檔案的明確允許規則。
所有其他應用程式都會隱含拒絕。例如，不允許 ExampleApp.exe，因為它只受到 Policy2 (信任，因為 [允許所有規則]) 而非 Policy1。

混合允許和拒絕原則考慮

如果拒絕規則集合要新增至包含明確允許規則的現有原則中，則不要包含上述的「全部允許」規則。相反地，拒絕規則應該透過應用程控精靈或使用下列 PowerShell 命令與現有的應用程控原則合併：

$DenyPolicy = <path_to_deny_policy>
$ExistingPolicy = <path_to_existing_policy>
Merge-CIPolicy -PolicyPaths $ DenyPolicy, $ExistingPolicy -OutputFilePath $ExistingPolicy

最佳做法

在稽核模式中先測試 - 如同所有新的原則，建議您在稽核模式中推出新的拒絕原則，並監視 3076 稽核封鎖事件，以確保只會封鎖您想要封鎖的應用程式。透過事件檢視器記錄和進階搜捕監視封鎖事件的詳細資訊：管理和疑難解答商務用應用程控原則
建議的拒絕規則類型 - 建議從安全性、管理性和效能觀點來看，簽署者和檔屬性規則。只有在必要時才應該使用哈希規則。由於檔案的哈希會隨著檔案的任何變更而變更，因此很難跟上以哈希為基礎的封鎖原則，攻擊者可在該原則中簡單地更新檔案。雖然應用程控已優化哈希規則的剖析，但如果原則有數以萬計的哈希規則，某些裝置可能會在運行時間評估時看到效能影響。

建立拒絕原則教學課程

您可以使用PowerShell Cmdlet或應用程控精靈來建立拒絕規則和原則。建議您盡可能 (PCACertificate、Publisher 和 FilePublisher) 建立簽署者規則。在未簽署的二進位檔案例中，必須在檔案的屬性上建立規則，例如原始檔名或哈希。

軟體發行者型拒絕規則

$DenyRules += New-CIPolicyRule -Level FilePublisher -DriverFilePath <binary_to_block> -Fallback SignedVersion,Publisher,Hash -Deny

軟體屬性型拒絕規則

$DenyRules += New-CIPolicyRule -Level FileName -DriverFilePath <binary_to_block> -Fallback Hash -Deny

哈希式拒絕規則

$DenyRules += New-CIPolicyRule -Level Hash -DriverFilePath <binary_to_block> -Deny

使用 AllowAll 範本原則合併拒絕規則

建立拒絕規則之後，您可以將它們與 AllowAll 範本原則合併：

$DenyPolicy = <path_to_deny_policy_destination>
$AllowAllPolicy = $Env:windir + "\schemas\CodeIntegrity\ExamplePolicies\AllowAll.xml"
Merge-CIPolicy -PolicyPaths $AllowAllPolicy -OutputFilePath $DenyPolicy -Rules $DenyRules
Set-CiPolicyIdInfo -FilePath $DenyPolicy -PolicyName "My Deny Policy" -ResetPolicyID

部署拒絕原則

您現在應該已準備好要部署的拒絕原則。請參閱應用程控部署指南，將原則部署至受控端點。

共用方式為