ビジネス向けアプリコントロールのポリシールールとファイルルールについて
注
App Control for Business の一部の機能は、特定の Windows バージョンでのみ使用できます。 アプリ制御機能の可用性について詳しくは、こちらをご覧ください。
App Control for Business では、ドライバーまたはアプリケーションが信頼されているかどうかを指定するポリシーを設定することで、Windows デバイスで実行される操作を制御できます。 ポリシーには、監査モードなどのオプションを制御するポリシー ルールと、organizationが信頼するアプリケーションを識別する方法を指定するファイル ルール (またはファイル ルール レベル) が含まれます。
App Control for Business ポリシー ルール
既存のアプリ制御ポリシー XML のポリシー 規則オプションを変更するには、 アプリ制御ポリシー ウィザード または Set-RuleOption PowerShell コマンドレットを使用します。
アプリ制御ポリシー内で複数のルール オプションを設定できます。 表 1 では、各ルール オプションと、補助ポリシーで設定できるかどうかを示します。 一部のルール オプションは、将来の作業用に予約されているか、サポートされていません。
注
新しいアプリ制御ポリシーを適用する前にテストできるため、最初は Enabled:Audit モード を使用することをお勧めします。 監査モードでは、アプリケーションは正常に実行されますが、アプリ制御では、ポリシーで許可されていないファイルが実行されるたびにイベントがログに記録されます。 これらのファイルを許可するには、イベント ログからポリシー情報をキャプチャし、その情報を既存のポリシーにマージします。 Enabled:Audit モードが削除されると、ポリシーは強制モードで実行されます。
ポリシーが監査モードの場合でも、一部のアプリの動作が異なる場合があります。 オプションが監査モードで動作を変更する場合は、表 1 に記載されています。 アプリコントロール ポリシーに重要な更新プログラムをデプロイするときは、常にアプリを徹底的にテストする必要があります。
表 1. ビジネス 向けアプリ制御ポリシー - ポリシー ルール オプション
| 規則のオプション | 説明 | 有効な補足オプション |
|---|---|---|
| 0 有効: UMCI | アプリ制御ポリシーでは、カーネル モードバイナリとユーザー モード バイナリの両方が制限されます。 既定では、カーネル モードのバイナリだけが制限されます。 この規則のオプションを有効にすると、ユーザー モードの実行可能ファイルとスクリプトが検証されます。 | なし |
| 1 有効: ブート メニューの保護 | このオプションは現在サポートされていません。 | なし |
| 2 必須: WHQL | 既定では、Windows Hardware Quality Labs (WHQL) 署名されていないカーネル ドライバーの実行が許可されます。 この規則を有効にするには、すべてのドライバーが WHQL 署名され、レガシ ドライバーのサポートが削除されている必要があります。 Windows 10用に構築されたカーネル ドライバーは WHQL 認定を受ける必要があります。 | なし |
| 3 有効: 監査モード (既定) | ポリシーが適用された場合に、ブロックされたアプリケーション、バイナリ、スクリプトに関する情報をログに記録するようにアプリ コントロールに指示します。 このオプションを使用して、アプリ制御ポリシーの潜在的な影響を特定し、監査イベントを使用して適用前にポリシーを絞り込むことができます。 アプリ制御ポリシーを適用するには、このオプションを削除します。 | なし |
| 4 無効: Insider Preview ビルドの署名 | 有効にすると、Windows Insider ビルドからのバイナリは信頼されません。 このオプションは、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)、および MSXML で実行される HTA ファイルを対象とするスクリプト適用オプションが無効になります。 一部のスクリプト ホストは、ポリシーが監査モードの場合でも動作が異なる場合があります。 スクリプトの適用の詳細については、「 App Control を使用したスクリプトの適用」を参照してください。 注: このオプションは、Windows Server 2016または Windows 10 1607 LTSB ではサポートされていないため、これらのオペレーティング システムでは使用しないでください。 |
なし |
| 12 必須: Microsoft Store アプリケーションの適用 | このルール オプションが有効になっている場合、アプリ制御ポリシーはユニバーサル Windows アプリケーションにも適用されます。 | なし |
| 13 有効: 管理インストーラー | マネージド インストーラーによってインストールされたアプリケーションを自動的に許可するには、このオプションを使用します。 詳細については、「App Control マネージド インストーラーを使用してデプロイされたアプリを承認する」を参照してください。 | ○ |
| 14 有効: インテリジェント セキュリティ グラフの承認 | このオプションを使用して、Microsoft のインテリジェント セキュリティ グラフ (ISG) によって定義された "既知の良好な" 評判を持つアプリケーションを自動的に許可します。 | ○ |
| 15 有効: 再起動時に EA を無効化 | インテリジェント セキュリティ グラフ オプション (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 以降でのみサポートされます。 注: このオプションは、App Control UMCI ポリシーで有効に した 場合は常に適用されます。 .NET 動的コード セキュリティ強化の監査モードはありません。 |
なし |
| 20 有効:失効期限切れ (署名なし) | このオプションを使用して、失効した証明書で署名されたバイナリ、または署名の有効期間署名 EKU で期限切れの証明書を、エンタープライズ署名シナリオのユーザー モード プロセス/コンポーネントの "署名なしバイナリ" として扱います。 | なし |
| Enabled:Developer Mode Dynamic Code Trust | このオプションを使用して、 Visual Studio でデバッグされている UWP アプリ、または開発者モードがシステムで有効になっている場合にデバイス ポータルを介して展開される UWP アプリを信頼します。 | なし |
App Control for Business のファイル ルール レベル
ファイル規則レベルを使うと、管理者はアプリケーションを信頼するレベルを指定できます。 このレベルの信頼は、各バイナリのハッシュと同じくらい細かく、または CA 証明書と同じくらい一般的な場合があります。 アプリコントロール ウィザードまたは App Control PowerShell コマンドレットを使用してポリシーを作成および変更する場合は、ファイル ルール レベルを指定します。
各ファイル ルール レベルには、長所と短所があります。 表 2 を使用して、使用可能な管理リソースとアプリ制御のデプロイ シナリオに適した保護レベルを選択します。
注
アプリ コントロールの署名者ベースの規則は、最大キー長が 4096 ビットの RSA 暗号化でのみ機能します。 ECDSA などの ECC アルゴリズムはサポートされていません。 ECC 署名に基づいて署名によってファイルを許可しようとすると、対応する 3089 署名情報イベントに VerificationError = 23 が表示されます。 ファイルは、代わりにハッシュまたはファイル属性ルールによって許可することも、RSA を使用して署名で署名されている場合は、他の署名者ルールを使用することもできます。
表 2. App Control for Business ポリシー - ファイル ルール レベル
| 規則のレベル | 説明 |
|---|---|
| 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 | 個々の署名証明書レベルで、信頼できる署名者を追加します。 このレベルと個々のハッシュ レベルを使用する利点は、製品の新しいバージョンのハッシュ値は異なりますが、通常は同じ署名証明書を持つことです。 このレベルを使用する場合、新しいバージョンのアプリケーションを実行するためにポリシーの更新は必要ありません。 ただし、リーフ証明書は通常、他の証明書レベルよりも有効期間が短いので、これらの証明書が変更されるたびにアプリ制御ポリシーを更新する必要があります。 |
| PcaCertificate | 署名者に提供された証明書チェーン内で使用可能な最上位の証明書を追加します。 このレベルは通常、ルートより下の 1 つの証明書です。これは、スキャンによって、ローカル ルート ストアまたはオンライン チェックを介して完全な証明書チェーンが解決されないためです。 |
| 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 プロフェッショナルを考えてみましょう。 ハードウェア、オペレーティング システム、ウイルス対策、およびその他の重要なソフトウェアを提供する企業によって署名されたソフトウェアのみを実行する必要があります。 また、内部で作成されたアプリケーション (署名されておらず、更新もほとんど行われません) もサーバーで実行されることを理解しています。 IT 担当者は、このアプリケーションの実行を許可しました。
アプリ制御ポリシーを作成するには、標準ハードウェア上に参照サーバーを構築し、サーバーが実行されていることがわかっているすべてのソフトウェアをインストールします。 次に、-Level Publisher (ソフトウェア プロバイダー (発行元) からのソフトウェアを許可する) と -Fallback Hash (内部で作成された署名されていないアプリケーションを許可する) を指定して、New-CIPolicy を実行します。 ポリシーを監査モードで展開し、ポリシーの強制による潜在的な影響を判断します。 監査データの助けを借りて、実行する他のソフトウェアを含むようにアプリ制御ポリシーを更新します。 次に、サーバーに対して適用モードでアプリ制御ポリシーを有効にします。
通常の操作の一環として、最終的にはソフトウェア更新プログラムをインストールするか、同じソフトウェア プロバイダーからソフトウェアを追加します。 これらの更新プログラムとソフトウェアでは "Publisher" は同じままであるため、アプリ制御ポリシーを更新する必要はありません。 署名されていない内部アプリケーションが更新された場合は、新しいバージョンを許可するようにアプリ制御ポリシーも更新する必要があります。
ファイル ルールの優先順位
App Control には、優先順位に変換されるファイル ルール競合ロジックが組み込まれています。 最初に、検出されたすべての明示的な拒否ルールを処理します。 次に、明示的な許可規則を処理します。 拒否規則または許可規則が存在しない場合、アプリコントロールは、ポリシーによって許可されている場合、 マネージド インストーラー要求 をチェックします。 最後に、ポリシーで許可されている場合、アプリ制御 は ISG にフォールバックします。
注
アプリコントロール ポリシーを簡単に推論できるようにするには、複数のアプリコントロール ポリシーをサポートする 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 を変更できるディレクトリのパス規則を避ける必要がある場合があります。
ユーザーが書き込み可能なファイルパス
既定では、App Control は実行時にユーザー書き込みチェックを実行します。これにより、指定されたファイルパスに対する現在のアクセス許可で、管理者ユーザーの書き込みアクセスのみが許可されます。
アプリ コントロールが管理者として認識する SID の定義済みの一覧があります。 この一覧にない SID に対してファイルパスで書き込みアクセス許可が許可されている場合、SID がカスタム管理者ユーザーに関連付けられている場合でも、ファイルパスはユーザーが書き込み可能であると見なされます。 このような特殊なケースを処理するには、前に説明した 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 を使用してファイルパス 規則を生成すると、スキャンされたパスで検出されたすべてのファイルに対して一意の完全修飾パス規則が生成されます。 代わりに、指定したフォルダー パスのすべてのファイルを許可するルールを作成するには、 New-CIPolicyRule を使用して、 -FilePathRules スイッチを使用して、ワイルドカードを含むルールを定義します。
アプリコントロールのファイルパス規則でワイルドカードを使用する
アプリコントロールのファイルパス規則では、次のワイルドカードを使用できます。
| ワイルドカード文字 | 意味 | サポートされているオペレーティング システム |
|---|---|---|
* |
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\AppControlUSER\Downloads\Malware\CCMCACHE\Pwned\7zhaha-x64.exe |
Windows 11のみ |
ワイルドカードを使用しない場合、filepath 規則では特定のファイル (例: C:\foo\bar.exe) のみを許可します。
注
Configuration Managerを使用してアプリ制御ポリシーを作成する場合は、指定したファイルとフォルダーのルールを作成するオプションがあります。 これらのルール は、 アプリコントロールのファイルパスルールではありません。 代わりに、Configuration Managerは、指定したファイルとフォルダーの 1 回限りのスキャンを実行し、そのスキャン時にそれらの場所にあるバイナリのルールを構築します。 そのスキャン後に指定したファイルとフォルダーに対するファイルの変更は、Configuration Manager ポリシーが再適用されない限り許可されません。
ハッシュの詳細
App Control では、ファイルのハッシュを計算するときに Authenticode/PE イメージ ハッシュ アルゴリズム が使用されます。 より一般的に知られている フラット ファイル ハッシュとは異なり、Authenticode ハッシュ計算では、ファイルのチェックサム、証明書テーブル、属性証明書テーブルが省略されます。 したがって、ファイルの Authenticode ハッシュは、ファイルの署名とタイムスタンプが変更されたとき、またはデジタル署名がファイルから削除された場合には変更されません。 Authenticode ハッシュの助けを借りて、App Control はセキュリティを強化し、管理オーバーヘッドを減らします。そのため、ファイルのデジタル署名が更新されたときにポリシー ハッシュ 規則を変更する必要はありません。
Authenticode/PE イメージ ハッシュは、デジタル署名されたファイルと署名されていないファイルに対して計算できます。
スキャンによって XML ファイルごとに 4 つのハッシュ 規則が作成されるのはなぜですか?
PowerShell コマンドレットは、Authenticode Sha1 ハッシュ、Sha256 ハッシュ、Sha1 ページ ハッシュ、Sha256 ページ ハッシュを生成します。 検証中に、アプリ コントロールは、ファイルの署名方法と、ファイルが使用されるシナリオに基づいて計算されるハッシュを選択します。 たとえば、ファイルがページ ハッシュ署名されている場合、App Control はファイルの各ページを検証し、メモリ内のファイル全体の読み込みを回避して完全な sha256 authenticode ハッシュを計算します。
コマンドレットでは、使用されるハッシュを予測するのではなく、4 つのハッシュ (sha1/sha2 authenticode、最初のページの sha1/sha2) を事前計算して使用します。 このメソッドは、アプリ制御ポリシーに既に複数のハッシュを使用できるため、ファイルの署名方法の変更にも回復性があります。
スキャンによって特定のファイルに対して 8 つのハッシュ 規則が作成されるのはなぜですか?
UMCI と KMCI に対して個別のルールが作成されます。 コマンドレットで、ファイルがユーザー モードまたはカーネルでのみ実行されると判断できない場合は、注意が必要な両方の署名シナリオに対してルールが作成されます。 特定のファイルがユーザー モードまたはカーネルでのみ読み込まれることがわかっている場合は、追加のルールを安全に削除できます。
App Control でフラット ファイル ハッシュ値が使用されるのはいつですか?
ファイルの形式が Authenticode 仕様に準拠していないため、フラット ファイル ハッシュを使用するために App Control がフォールバックする場合はまれです。 この動作は、実行時にメモリ内バージョンのファイルに変更が加えられた場合など、さまざまな理由で発生する可能性があります。 このような場合、相関 3089 署名情報イベントに示されているハッシュが、3076/3077 ブロック イベントのフラット ファイル ハッシュと一致していることがわかります。 無効な形式のファイルのルールを作成するには、アプリ制御ウィザードを使用するか、ポリシー XML を直接編集して、フラット ファイル ハッシュのポリシーにハッシュ 規則を追加します。