ビジネス向けアプリコントロールのポリシールールとファイルルールについて

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

App Control for Business ポリシー ルール

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

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

表 1. ビジネス 向けアプリ制御ポリシー - ポリシー ルール オプション

App Control for Business のファイル ルール レベル

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

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

表 2. App Control for Business ポリシー - ファイル ルール レベル

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

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

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

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

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

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

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

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

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

表 3. -SpecificFileNameLevel オプション

ファイルパス規則の詳細

ファイルパス 規則は、変更可能なアクセス許可に基づいているため、明示的な署名者ルールと同じセキュリティ保証を提供しません。 ファイルパス 規則は、ほとんどのユーザーが管理者ではなく標準で実行されている環境に最適です。パスルールは、管理者が書き込み可能なパスのみを許可するのに最適です。 標準ユーザーがフォルダーの 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 スイッチを使用して、ワイルドカードを含むルールを定義します。

アプリコントロールのファイルパス規則でワイルドカードを使用する

アプリコントロールのファイルパス規則では、次のワイルドカードを使用できます。

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

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

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

ハッシュの詳細

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 を直接編集して、フラット ファイル ハッシュのポリシーにハッシュ 規則を追加します。