次の方法で共有

アプリコントロール拒否ポリシーの作成に関するガイダンス

  • [アーティクル]
  • 適用対象:
    ✅ Windows 11, ✅ Windows 10

App Control for Business では、特定のドライバーとアプリケーションを明示的に拒否するポリシーを作成できます。 効果的な App Control for Business 拒否ポリシーを作成するには、アクティブなポリシーに対してファイルを評価するときに適用される ルールの優先順位を理解 する必要があります。

スタンドアロン拒否ポリシー

拒否規則のみで構成されるポリシーを作成する場合は、明示的な拒否規則に加えて、ポリシーのカーネル モード セクションとユーザー モード セクションの両方に "すべて許可" ルールを含める必要があります。 "すべて許可" ルールを使用すると、ポリシーによって明示的に拒否されていないもの実行が許可されます。 拒否のみのポリシーに "すべて許可" ルールを追加できない場合は、すべてをブロックするリスクがあります。 この結果は、承認する規則がないため、一部のコードが 明示的に 拒否され、他のすべてのコードが 暗黙的に 拒否されるために発生します。 スタンドアロン拒否ポリシーを作成するときは 、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 をブロックする新しい拒否ポリシーです。 また、"すべて許可" ルールも含まれます。

  • Policy2 には明示的なブロック規則があるため、MaliciousApp.exe はブロックされます。 また、そのポリシー内のファイルをカバーする許可規則がないため、Policy1 によって 暗黙的 にブロックされます。
  • Policy2 には明示的なブロック規則があるため、Windows 署名されたファイル wmic.exe はブロックされます。
  • Policy1 と Policy2 の両方にファイルをカバーする明示的な許可規則があるため、他のすべての Windows および Microsoft 署名されたアプリケーションが許可されます。
  • 他のすべてのアプリケーションは暗黙的に拒否されます。 たとえば、ExampleApp.exe は、Policy1 ではなく Policy2 によってのみ信頼されるため、許可されません。

許可ポリシーと拒否ポリシーの混在に関する考慮事項

明示的な許可規則を含む既存のポリシーに拒否規則のセットを追加する場合は、前の "すべて許可" 規則を含めないでください。 代わりに、拒否規則は、アプリ制御ウィザードまたは次の PowerShell コマンドを使用して、既存の アプリ制御 ポリシーとマージする必要があります。

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

ベスト プラクティス

  1. 監査モードで最初にテスト する - すべての新しいポリシーと同様に、新しい拒否ポリシーを監査モードでロールアウトし、 3076 監査ブロック イベント を監視して、ブロックする予定のアプリケーションのみがブロックされるようにすることをお勧めします。 イベント ビューアー ログを使用したブロック イベントの監視と高度なハンティング: App Control for Business ポリシーの管理とトラブルシューティングの詳細

  2. 推奨される拒否規則の種類 - 署名者とファイル属性の規則は、セキュリティ、管理容易性、およびパフォーマンスの観点から推奨されます。 ハッシュ 規則は、必要な場合にのみ使用する必要があります。 ファイルのハッシュはファイルの変更に伴って変更されるため、攻撃者がファイルを簡単に更新できるハッシュベースのブロック ポリシーに追いつくのは難しいです。 アプリコントロールはハッシュルールの解析を最適化していますが、ポリシーに数万以上のハッシュルールがある場合、実行時の評価時にパフォーマンスに影響を与える可能性があります。

拒否ポリシーの作成に関するチュートリアル

拒否ルールとポリシーは、PowerShell コマンドレットまたは アプリ制御ウィザードを使用して作成できます。 可能な限り、署名者ルール (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

拒否ポリシーを展開する

これで、展開する拒否ポリシーが準備されます。 管理対象エンドポイントにポリシーをデプロイするには、 アプリ制御デプロイ ガイド を参照してください。