Windows Defender アプリケーション制御 (WDAC) ポリシー規則とファイル規則について理解する

Windows Defender アプリケーションコントロールの一部の機能は、特定の Windows バージョンでのみ使用できます。 WDAC 機能の可用性について詳しくは、こちらをご覧ください。

Windows Defender アプリケーション制御 (WDAC) は、ドライバーまたはアプリケーションが信頼されているかどうかを指定するポリシーを設定することで、Windows デバイスで実行される内容を制御できます。 ポリシーには、監査モードなどのオプションを制御するポリシー ルールと、organizationが信頼するアプリケーションを識別する方法を指定するファイル ルール (またはファイル ルール レベル) が含まれます。

Windows Defender Application Control のポリシー規則

既存の WDAC ポリシー XML のポリシー 規則オプションを変更するには、 WDAC ポリシー ウィザード または Set-RuleOption PowerShell コマンドレットを使用します。

1 つの WDAC ポリシー内に複数の規則のオプションを設定できます。 表 1 では、各ルール オプションと、補助ポリシーで設定できるかどうかを示します。 一部のルール オプションは、将来の作業用に予約されているか、サポートされていません。

新しい WDAC ポリシーを適用する前にテストできるため、最初は Enabled:Audit モード を使用することをお勧めします。 監査モードでは、アプリケーションは正常に実行されますが、WDAC は、ポリシーで許可されていないファイルが実行されるたびにイベントをログに記録します。 これらのファイルを許可するには、イベント ログからポリシー情報をキャプチャし、その情報を既存のポリシーにマージします。 Enabled:Audit モードが削除されると、ポリシーは強制モードで実行されます。

ポリシーが監査モードの場合でも、一部のアプリの動作が異なる場合があります。 オプションが監査モードで動作を変更する場合は、表 1 に記載されています。 WDAC ポリシーに重要な更新プログラムを展開するときは、常にアプリを徹底的にテストする必要があります。

表 1. Windows Defender Application Control のポリシー - ポリシー規則オプション

規則のオプション 説明 有効な補足オプション
0 有効: UMCI WDAC ポリシーでは、カーネル モードとユーザー モードの両方のバイナリを制限します。 既定では、カーネル モードのバイナリだけが制限されます。 この規則のオプションを有効にすると、ユーザー モードの実行可能ファイルとスクリプトが検証されます。 なし
1 有効: ブート メニューの保護 このオプションは現在サポートされていません。 なし
2 必須: WHQL 既定では、Windows Hardware Quality Labs (WHQL) 署名されていないカーネル ドライバーの実行が許可されます。 この規則を有効にするには、すべてのドライバーが WHQL 署名され、レガシ ドライバーのサポートが削除されている必要があります。 Windows 10用に構築されたカーネル ドライバーは WHQL 認定を受ける必要があります。 なし
3 有効: 監査モード (既定) ポリシーが適用された場合にブロックされたアプリケーション、バイナリ、スクリプトに関する情報をログに記録するように WDAC に指示します。 このオプションを使用して、WDAC ポリシーの潜在的な影響を特定し、監査イベントを使用してポリシーを適用する前に絞り込むことができます。 WDAC ポリシーを適用するには、このオプションを削除します。 なし
4 無効: Insider Preview ビルドの署名 有効にすると、Windows Insider ビルドからのバイナリは信頼されません。 このオプションは、Windows ビルドのプレリリースではなく、リリースされたバイナリのみを実行する組織に役立ちます。 なし
5 有効: 既定のポリシーの継承 このオプションは将来の使用のために予約されており、現在は効果がありません。
6 有効: 署名されていないシステム整合性ポリシー (既定) ポリシーを署名されていない状態にしておくことができます。 このオプションを削除する場合は、ポリシーに署名し、補足ポリシーも署名する必要があります。 今後のポリシー更新に対して信頼される証明書は、UpdatePolicySigners セクションで識別する必要があります。 補足ポリシーに対して信頼されている証明書は、SupplementalPolicySigners セクションで識別する必要があります。 なし
7 許可: デバッグ ポリシーの拡張 このオプションは現在サポートされていません。
8 必須: EV 署名者 このオプションは現在サポートされていません。 なし
9 有効: [詳細ブート オプション] メニュー すべての WDAC ポリシーで、F8 プリブート メニューが既定で無効になります。 この規則のオプションを設定すると、実際に使っているユーザーに対して F8 メニューを表示することができます。 なし
10 有効: エラー発生時における監査の起動 WDAC ポリシーが実施モードの場合に使われます。 起動時にブート クリティカルなドライバーが失敗すると、WDAC ポリシーが監査モードに設定され、Windows が読み込まれます。 管理者は、CodeIntegrity イベント ログを使って、エラーが発生した理由を確認できます。 なし
11 無効: スクリプトの適用 このオプションでは、PowerShell、Windows ベースのスクリプト ホスト (wscript.exe)、Windows コンソール ベースのスクリプト ホスト (cscript.exe)、Microsoft HTML アプリケーション ホスト (mshta.exe)、および MSXML で実行される HTA ファイルを対象とするスクリプト適用オプションが無効になります。 一部のスクリプト ホストは、ポリシーが監査モードの場合でも動作が異なる場合があります。 スクリプトの適用の詳細については、「 WDAC を使用したスクリプトの適用」を参照してください。
注: このオプションは、Windows Server 2016または Windows 10 1607 LTSB ではサポートされていないため、これらのオペレーティング システムでは使用しないでください。
なし
12 必須: Microsoft Store アプリケーションの適用 このルール オプションが有効になっている場合、WDAC ポリシーはユニバーサル Windows アプリケーションにも適用されます。 なし
13 有効: 管理インストーラー マネージド インストーラーによってインストールされたアプリケーションを自動的に許可するには、このオプションを使用します。 詳細については、「WDAC マネージド インストーラーを使用してデプロイされたアプリを承認する」を参照してください。 はい
14 有効: インテリジェント セキュリティ グラフの承認 このオプションを使用して、Microsoft のインテリジェント セキュリティ グラフ (ISG) によって定義された "既知の良好な" 評判を持つアプリケーションを自動的に許可します。 はい
15 有効: 再起動時に EA を無効化 インテリジェント セキュリティ グラフ オプション (14) を使うと、WDAC はファイルが実行を許可されていることを示す拡張ファイル属性を設定します。 このオプションにより、WDAC は、ISG によって以前に承認されたファイルの評判を定期的に再検証します。 なし
16 有効: ポリシーの更新 (再起動なし) システムの再起動を必要とせずに今後の WDAC ポリシーの更新の適用を許可するには、このオプションを使います。
注: このオプションは、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 以降でのみサポートされます。
注: このオプションは、WDAC UMCI ポリシーで有効に した 場合は常に適用されます。 .NET 動的コード セキュリティ強化の監査モードはありません。
なし
20 有効:失効期限切れ (署名なし) このオプションを使用して、失効した証明書で署名されたバイナリ、または署名の有効期間署名 EKU で期限切れの証明書を、エンタープライズ署名シナリオのユーザー モード プロセス/コンポーネントの "署名なしバイナリ" として扱います。 なし
Enabled:Developer Mode Dynamic Code Trust このオプションを使用して、 Visual Studio でデバッグされている UWP アプリ、または開発者モードがシステムで有効になっている場合にデバイス ポータルを介して展開される UWP アプリを信頼します。 なし

Windows Defender Application Control のファイル規則レベル

ファイル規則レベルを使うと、管理者はアプリケーションを信頼するレベルを指定できます。 このレベルの信頼は、各バイナリのハッシュと同じくらい細かく、または CA 証明書と同じくらい一般的な場合があります。 WDAC ウィザードまたは WDAC PowerShell コマンドレットを使用してポリシーを作成および変更する場合は、ファイル ルール レベルを指定します。

各ファイル ルール レベルには、長所と短所があります。 表 2 を使用して、使用可能な管理リソースと WDAC 展開シナリオに適した保護レベルを選択します。

WDAC 署名者ベースの規則は、RSA 暗号化でのみ機能します。 ECDSA などの ECC アルゴリズムはサポートされていません。 ECC 署名に基づいて署名によってファイルを許可しようとすると、対応する 3089 署名情報イベントに VerificationError = 23 が表示されます。 ファイルは、代わりにハッシュまたはファイル属性ルールによって許可することも、RSA を使用して署名で署名されている場合は、他の署名者ルールを使用することもできます。

表 2. Windows Defender Application Control ポリシー - ファイル規則レベル

規則のレベル 説明
Hash 検出されたバイナリごとに、個々の Authenticode/PE イメージ ハッシュ値 を指定します。 このレベルは最も具体的なレベルであり、現在の製品バージョンのハッシュ値を維持するためのより多くの労力が必要です。 バイナリが更新されるたびにハッシュ値が変更されるので、ポリシーの更新が必要となります。
FileName バイナリごとに元のファイル名を指定します。 アプリケーションの更新時にアプリケーションのハッシュ値は変更されますが、ファイル名は通常変更されません。 このレベルでは、ハッシュ レベルよりも固有のセキュリティが低くなりますが、通常、バイナリが変更されたときにポリシーを更新する必要はありません。 既定では、このレベルではファイルのリソース ヘッダーの OriginalFileName 属性が使用されます。 -SpecificFileNameLevel を使用して、ProductName などの代替属性を選択します。
FilePath バージョン 1903 Windows 10以降、このレベルではバイナリを特定のファイル パスの場所から実行できます。 FilePath ルールはユーザー モード バイナリにのみ適用され、カーネル モード ドライバーを許可するために使用することはできません。 FilePath レベルの規則の詳細については、この記事の後半で説明します。
SignedVersion このレベルでは、発行元ルールとバージョン番号が組み合わされます。 これにより、指定したバージョン番号以上のバージョンを使用して、指定した発行元から何かを実行できます。
Publisher このレベルは、PcaCertificate レベル (通常はルートの下に 1 つの証明書) とリーフ証明書の共通名 (CN) を組み合わせたレベルです。 この規則レベルを使用すると、特定の CA によって発行され、信頼する特定の会社 (デバイス ドライバーの場合は Intel など) に発行された証明書を信頼できます。
FilePublisher このレベルでは、署名済みファイルの "FileName" 属性に加えて、"Publisher" (リーフの CN を含む PCA 証明書) と最小バージョン番号が組み合わされます。 このオプションでは、指定された発行元からの特定ファイルが指定されたバージョン番号以上である場合に信頼されます。 既定では、このレベルではファイルのリソース ヘッダーの OriginalFileName 属性が使用されます。 -SpecificFileNameLevel を使用して、ProductName などの代替属性を選択します。
LeafCertificate 個々の署名証明書レベルで、信頼できる署名者を追加します。 このレベルと個々のハッシュ レベルを使用する利点は、製品の新しいバージョンのハッシュ値は異なりますが、通常は同じ署名証明書を持つことです。 このレベルを使用する場合、新しいバージョンのアプリケーションを実行するためにポリシーの更新は必要ありません。 ただし、リーフ証明書は通常、他の証明書レベルよりも有効期間が短いので、これらの証明書が変更されるたびに WDAC ポリシーを更新する必要があります。
PcaCertificate 署名者に提供された証明書チェーン内で使用可能な最上位の証明書を追加します。 このレベルは通常、ルートより下の 1 つの証明書です。これは、スキャンによって、ローカル ルート ストアまたはオンライン チェックを介して完全な証明書チェーンが解決されないためです。
RootCertificate サポートされません。
WHQL Microsoft に送信され、Windows ハードウェア修飾ラボ (WHQL) によって署名されたバイナリのみを信頼します。 このレベルは主にカーネル バイナリ用です。
WHQLPublisher このレベルは、WHQL レベルとリーフ証明書の CN を組み合わせたものであり、主にカーネル バイナリ用です。
WHQLFilePublisher このレベルでは、署名されたファイルの "FileName" 属性と "WHQLPublisher" と最小バージョン番号が結合されます。 このレベルは主にカーネル バイナリ用です。 既定では、このレベルではファイルのリソース ヘッダーの OriginalFileName 属性が使用されます。 -SpecificFileNameLevel を使用して、ProductName などの代替属性を選択します。

New-CIPolicy を使用して WDAC ポリシーを作成する場合は、-Level パラメーターを含めることで、プライマリ ファイル ルール レベルを指定できます。 最優先するファイル規則の条件に基づいて判断したときに、信頼できないバイナリが検出された場合、-Fallback パラメーターを使うことができます。 たとえば、プライマリ ファイル規則レベルが PCACertificate であっても、署名されていないアプリケーションを信頼する場合は、フォールバックとしてハッシュ 規則レベルを使用すると、署名証明書を持たないバイナリのハッシュ値が追加されます。

  • WDAC では、最大 4096 ビットの RSA 証明書署名キーの署名者ルールのみがサポートされます。
  • このコードでは、ポリシーの CertSubject フィールドと CertIssuer フィールドに CN を使用します。 受信トレイ certutil を使用して基になる形式を調べ、UTF-8 が CN で使用されていないことを確認できます。 たとえば、印刷可能な文字列、IA5、または BMP を使用できます。

該当する場合、ファイル ルールの最小バージョン番号と最大バージョン番号は、ポリシー XML で MinimumFileVersion と MaximumFileVersion としてそれぞれ参照されます。

  • MinimumFileVersion と MaximumFileVersion の両方が指定されました: 許可規則の場合、バージョンが MinimumFileVersion 以上 で MaximumFileVersion 以下 のファイルが許可されます。 拒否規則の場合、バージョンが MinimumFileVersion 以上 で MaximumFileVersion 以下 のファイルは拒否されます。
  • MaximumFileVersion なしで指定された MinimumFileVersion: 許可ルールの場合、指定したバージョン 以上 のバージョンのファイルの実行が許可されます。 [拒否規則] では、指定したバージョン 以下 のバージョンのファイルがブロックされます。
  • MinimumFileVersion なしで指定された MaximumFileVersion: 許可ルールの場合、指定したバージョン 以下 のバージョンのファイルの実行が許可されます。 [拒否規則] の場合、指定したバージョン 以上 のバージョンのファイルはブロックされます。

ファイル規則レベルの使用例

たとえば、多くのサーバーを実行する部門の IT プロフェッショナルを考えてみましょう。 ハードウェア、オペレーティング システム、ウイルス対策、およびその他の重要なソフトウェアを提供する企業によって署名されたソフトウェアのみを実行する必要があります。 また、内部で作成されたアプリケーション (署名されておらず、更新もほとんど行われません) もサーバーで実行されることを理解しています。 IT 担当者は、このアプリケーションの実行を許可しました。

WDAC ポリシーを作成するために、標準のハードウェア上に参照サーバーを構築し、サーバーでの実行が許可されているすべてのソフトウェアをインストールします。 次に、-Level Publisher (ソフトウェア プロバイダー (発行元) からのソフトウェアを許可する) と -Fallback Hash (内部で作成された署名されていないアプリケーションを許可する) を指定して、New-CIPolicy を実行します。 ポリシーを監査モードで展開し、ポリシーの強制による潜在的な影響を判断します。 監査データの助けを借りて、実行する他のソフトウェアを含むように WDAC ポリシーを更新します。 その後で、IT 担当者は、サーバーに対して WDAC ポリシーを実施モードで有効にします。

通常の操作の一環として、最終的にはソフトウェア更新プログラムをインストールするか、同じソフトウェア プロバイダーからソフトウェアを追加します。 これらの更新プログラムとソフトウェアでは "Publisher" は同じままであるため、WDAC ポリシーを更新する必要はありません。 署名されていない内部アプリケーションが更新された場合は、新しいバージョンを許可するように WDAC ポリシーも更新する必要があります。

ファイル ルールの優先順位

WDAC には、優先順位に変換するファイル ルール競合ロジックが組み込まれています。 最初に、検出されたすべての明示的な拒否ルールを処理します。 次に、明示的な許可規則を処理します。 拒否規則または許可規則が存在しない場合、WDAC は、ポリシーによって許可されている場合に マネージド インストーラー要求 をチェックします。 最後に、ポリシーで許可されている場合、WDAC は ISG にフォールバックします。

WDAC ポリシーを簡単に推論できるようにするには、 複数の WDAC ポリシーをサポートする Windows バージョンで個別の ALLOW ポリシーと DENY ポリシーを維持することをお勧めします。

FileName、FilePublisher、または WHQLFilePublisher レベルの規則で -SpecificFileNameLevel を使用する

既定では、FileName、FilePublisher、WHQLFilePublisher の各規則レベルでは、ファイルのリソース ヘッダーの OriginalFileName 属性が使用されます。 -SpecificFileNameLevel を設定することで、ルールの代替リソース ヘッダー属性を使用できます。 たとえば、ソフトウェア開発者は、アプリの一部であるすべてのバイナリに同じ ProductName を使用する場合があります。 -SpecificFileNameLevel を使用すると、すべてのファイルの個々のルールではなく、ポリシー内のすべてのバイナリをカバーする 1 つのルールを作成できます。

表 3 では、-SpecificFileNameLevel で設定できる使用可能なリソース ヘッダー属性オプションについて説明します。

表 3. -SpecificFileNameLevel オプション

SpecificFileNameLevel 値 説明
FileDescription バイナリの開発者が提供するファイルの説明を指定します。
InternalName バイナリの内部名を指定します。
OriginalFileName バイナリの元のファイル名、またはファイルが最初に作成された名前を指定します。
PackageFamilyName バイナリのパッケージ ファミリ名を指定します。 パッケージ ファミリ名は、ファイルの名前と発行元 ID の 2 つの部分で構成されます。
ProductName バイナリが出荷される製品の名前を指定します。
Filepath バイナリのファイル パスを指定します。

ファイルパス規則の詳細

ファイルパス 規則は、変更可能なアクセス許可に基づいているため、明示的な署名者ルールと同じセキュリティ保証を提供しません。 ファイルパス 規則は、ほとんどのユーザーが管理者ではなく標準で実行されている環境に最適です。パスルールは、管理者が書き込み可能なパスのみを許可するのに最適です。 標準ユーザーがフォルダーの ACL を変更できるディレクトリのパス規則を避ける必要がある場合があります。

ユーザーが書き込み可能なファイルパス

既定では、WDAC は実行時にユーザー書き込みチェックを実行し、指定されたファイルパスに対する現在のアクセス許可で管理者ユーザーに対してのみ書き込みアクセスが許可されるようにします。

WDAC が管理者として認識する SID の定義済みの一覧があります。 この一覧にない SID に対してファイルパスで書き込みアクセス許可が許可されている場合、SID がカスタム管理者ユーザーに関連付けられている場合でも、ファイルパスはユーザーが書き込み可能であると見なされます。 このような特殊なケースを処理するには、前述の Disabled:Runtime FilePath Rule Protection オプションを使用して、WDAC のランタイム管理者が書き込み可能なチェックをオーバーライドできます。

WDAC の既知の管理者 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 を使用してファイルパス 規則を生成すると、スキャンされたパスで検出されたすべてのファイルに対して一意の完全修飾パス規則が生成されます。 代わりに、指定したフォルダー パスのすべてのファイルを許可するルールを作成するには、 New-CIPolicyRule を使用して、 -FilePathRules スイッチを使用して、ワイルドカードを含むルールを定義します。

WDAC ファイルパス規則でのワイルドカードの使用

WDAC ファイルパス 規則では、次のワイルドカードを使用できます。

ワイルドカード文字 意味 サポートされているオペレーティング システム
* 0 個以上の文字と一致します。 Windows 11、Windows 10、および Windows Server 2022
? 1 文字に一致します。 Windows 11のみ

また、正確なボリュームが異なる場合は、次のマクロを使用することもできます。 %OSDRIVE%%WINDIR%%SYSTEM32% これらのマクロは、上記のワイルドカードと組み合わせて使用できます。

Windows 11では、ファイルパス 規則内の任意の場所で 1 つ以上のワイルドカードを使用できます。

その他のすべての Windows および Windows Server バージョンでは、パス 規則ごとに 1 つのワイルドカードのみが 許可 され、パス 規則の先頭または末尾に存在する必要があります

ワイルドカードを使用したファイルパス規則の例

説明 サポートされているオペレーティング システム
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\WDACUSER\Downloads\Malware\CCMCACHE\Pwned\7zhaha-x64.exe
Windows 11のみ

ワイルドカードを使用しない場合、filepath 規則では特定のファイル (例: ) のみを使用できます。 C:\foo\bar.exe

Configuration Managerを使用して WDAC ポリシーを作成する場合は、指定したファイルとフォルダーのルールを作成するオプションがあります。 これらの規則 WDAC ファイルパス規則ではありません。 代わりに、Configuration Managerは、指定したファイルとフォルダーの 1 回限りのスキャンを実行し、そのスキャン時にそれらの場所にあるバイナリのルールを構築します。 そのスキャン後に指定したファイルとフォルダーに対するファイルの変更は、Configuration Manager ポリシーが再適用されない限り許可されません。

ハッシュの詳細

WDAC は、ファイルのハッシュを計算するときに Authenticode/PE イメージ ハッシュ アルゴリズム を使用します。 より一般的に知られている フラット ファイル ハッシュとは異なり、Authenticode ハッシュ計算では、ファイルのチェックサム、証明書テーブル、属性証明書テーブルが省略されます。 したがって、ファイルの Authenticode ハッシュは、ファイルの署名とタイムスタンプが変更されたとき、またはデジタル署名がファイルから削除された場合には変更されません。 Authenticode ハッシュの助けを借りて、WDAC はセキュリティを強化し、管理オーバーヘッドを減らします。そのため、ファイルのデジタル署名が更新されたときにポリシー ハッシュ規則を変更する必要はありません。

Authenticode/PE イメージ ハッシュは、デジタル署名されたファイルと署名されていないファイルに対して計算できます。

スキャンによって XML ファイルごとに 4 つのハッシュ 規則が作成されるのはなぜですか?

PowerShell コマンドレットは、Authenticode Sha1 ハッシュ、Sha256 ハッシュ、Sha1 ページ ハッシュ、Sha256 ページ ハッシュを生成します。 検証中、WDAC は、ファイルの署名方法と、ファイルが使用されるシナリオに基づいて計算されるハッシュを選択します。 たとえば、ファイルがページ ハッシュ署名されている場合、WDAC はファイルの各ページを検証し、メモリ内のファイル全体の読み込みを回避して完全な sha256 authenticode ハッシュを計算します。

コマンドレットでは、使用されるハッシュを予測するのではなく、4 つのハッシュ (sha1/sha2 authenticode、最初のページの sha1/sha2) を事前計算して使用します。 この方法は、WDAC ポリシーに既に複数のハッシュを使用できるため、ファイルの署名方法の変更にも回復性があります。

スキャンによって特定のファイルに対して 8 つのハッシュ 規則が作成されるのはなぜですか?

UMCI と KMCI に対して個別のルールが作成されます。 コマンドレットで、ファイルがユーザー モードまたはカーネルでのみ実行されると判断できない場合は、注意が必要な両方の署名シナリオに対してルールが作成されます。 特定のファイルがユーザー モードまたはカーネルでのみ読み込まれることがわかっている場合は、追加のルールを安全に削除できます。

WDAC でフラット ファイル ハッシュ値が使用されるのはいつですか?

ファイルの形式が Authenticode 仕様に準拠していないため、WDAC がフラット ファイル ハッシュを使用するためにフォールバックする場合はまれです。 この動作は、実行時にメモリ内バージョンのファイルに変更が加えられた場合など、さまざまな理由で発生する可能性があります。 このような場合、相関 3089 署名情報イベントに示されているハッシュが、3076/3077 ブロック イベントのフラット ファイル ハッシュと一致していることがわかります。 無効な形式のファイルのルールを作成するには、WDAC ウィザードを使用するか、ポリシー XML を直接編集して、フラット ファイル ハッシュのポリシーにハッシュ 規則を追加します。