ファイルアクセスポリシー評価ガイド
本ページでは、ファイルアクセスポリシーがいつ適用されるか、レイヤー型 (多層防御) のポリシーがどう連携するか、同じ起動に複数が一致したときにどれが優先されるかを取り扱います。
作成方法はファイルアクセスポリシーのページが対象です。本ページは評価の挙動を考えるときにご利用ください。起動がゲートされた (またはされなかった) 理由や、単一のパス一覧を超えて成り立つポリシースタックの設計に役立ちます。
ファイルアクセスポリシーが制御する内容
ファイルアクセスポリシーは、管理対象エンドポイント上でユーザーがアプリケーションを起動できるか (またはファイルアクセスのワークフローで保護ファイルを開けるか) を判定します。
起動がインターセプトされると、エージェントは有効なファイルアクセスポリシーを以下に対して評価します。
誰が起動しているか: ユーザーおよびグループのコレクション
どのマシンで起動しているか: マシンコレクション
何を起動しているか: アプリケーションコレクション (パス、ファイル名、ファイルハッシュ、および/または証明書)
任意の時刻、曜日、日付のスケジュール
ポリシーのコントロール: 許可、拒否、MFA、正当な理由、承認、およびそれらの組み合わせ
起動をブロックまたはゲートできるのは、ステータスが適用のポリシーだけです。監視ポリシーは監査のみで、すでに適用ポリシーが一致している場合は強制しません。
ファイルアクセスポリシーが適用される条件
ポリシーが起動に適用されるのは、以下のすべてが真の場合のみです。
ステータスが適用である (無効ではなく、強制が目的の場合は監視でもない)
ユーザーがポリシーのユーザーまたはグループのスコープに一致する (またはポリシーがすべてのユーザーを対象としている)
マシンがポリシーのマシンスコープに一致する (またはすべてのマシン)
アプリケーションまたはファイルがポリシーのアプリケーションスコープに一致する (アプリケーションの一致の仕組みをご参照ください)
ポリシー上のルールがあれば通過する (ユーザーチェックやファイルチェックなど)
任意のスケジュールフィルター (曜日、日付、時刻) がある場合、「現在」がその範囲に含まれる
必須フィルターのいずれかが失敗すると、そのポリシーはこの起動には適用されません。他のポリシーは引き続き適用される場合があります。
一致対象は評価中の起動
ファイルアクセスでは、アプリケーションの一致はいま起動しようとしているプロセスのパス (および任意のハッシュまたは証明書) と比較されます。「ディスク上にかつて存在したこのツールの任意のコピー」ではありません。
したがって:
{system32}\WindowsPowerShell\v1.0\powershell.exeを列挙したポリシーは、そのシステムパス上のPowerShellに一致します。同じバイト列を
C:\Users\alice\pwsh_copy.exeにコピーしたものは別の起動パスです。上記のパス固有ポリシーは、ハッシュ、ファイル名パターン、証明書、またはより広いアプリケーションスコープ (例: すべてのアプリケーション) でも対象にしていない限り、そのコピーには一致しません。
この挙動はパスベースのコレクションでは想定どおりです。耐久性のあるLiving-off-the-Land (LOTL) やブロックリストの設計で、単一のパス一覧だけでなくレイヤー型ポリシー (多層防御をご参照ください) を使う理由でもあります。
アプリケーションの一致の仕組み
アプリケーションコレクションは、ソフトウェアをいくつかの方法で識別できます。コレクションのメンバーはORで結合され、いずれか1つ一致すればそのコレクションには十分です。
パスまたはファイル名のパターン
パス変数解決後のフルパス (例:
{system32}\cmd.exeはC:\Windows\System32\cmd.exeに解決)パス内のワイルドカード (例:
{programfiles}\*\*.exe)ファイル名のみのパターン (例:
powershell.exe): 任意のディレクトリ配下のその名前に一致可能ワイルドカード
*(または空 / すべてのアプリケーションのコレクション): そのフィルターではすべてのアプリケーションに一致
コンテンツハッシュ (SHA256)
ハッシュのみのコレクションメンバーは、起動元の場所にかかわらずファイルの内容に一致
パスおよびハッシュのメンバーは、パスパターンとハッシュの両方の一致が必要
発行元証明書
構成されている場合、ポリシーは一致するコード署名証明書または拇印も要求できます。証明書フィルター (CertificationCheck)をご参照ください。
実務上の指針
通常のインストール場所でのみツールをブロックする: パスパターンを使用 (ファイルアクセスポリシーのページにある例1形式の一覧)
別の場所にコピーされた同じバイナリもブロックする: ファイルハッシュ (レイヤーC) および/またはファイル名のみのパターンに加え、広い承認または許可リストの姿勢 (レイヤーB) を併用
承認済みソフトウェアのみ許可する: 既知のアプリおよび/または信頼できる発行元を証明書で許可リスト化 (レイヤーD)。それ以外はすべてのアプリケーション向けポリシーで承認を要求する (または拒否する)
ファイルアクセスポリシーが一致しない場合の挙動
適用中のファイルアクセスポリシーが起動に一致しない場合:
エージェントはそのイベントにファイルアクセスコントロールを適用しません。
結果は実質的にファイルアクセスの EnforcementDisabled となり、その起動にはOSのデフォルト挙動が適用されます。特権昇格など他のポリシータイプは、昇格が要求されていれば引き続き適用される場合があります。
ファイルアクセス単体は、暗黙の「すべて拒否」製品モードではありません。デフォルトでゲートまたはデフォルト拒否は、すべてのアプリケーション向けの承認 (または拒否) ポリシーを作成し、承認済みソフトウェア向けに許可を切り出す姿勢として設計します。
多層防御 (推奨モデル)
ファイルアクセスは、単一のパス一覧ではなくポリシーのスタックとして扱います。
レイヤーA: 特定パスの承認 (既知の場所)
{system32}\cmd.exe、{system32}\WindowsPowerShell\v1.0\powershell.exe、certutil.exe、その他ドキュメント化されたシステムパス上のLOTLツールに対し、承認 (またはMFA / 正当な理由 + 承認) を要求します。
実インストール場所からの安易な利用を、明示的な承認ワークフローの背後にゲート
監査向けに明確 (「System32上のPowerShellは承認が必要」)
レビュー後も正当な管理者やサポートによる実システムパスの利用を残す必要がある場合は、ここでハードな拒否より承認を優先
このレイヤーだけでは、ユーザーが別パス上のコピーを実行することを止められない
レイヤーB: 広い姿勢 (すべてのアプリケーションまたは許可リスト)
よくあるパターンは2つです。
デフォルトでゲート: すべてのアプリケーション (
*) にファイルアクセスの承認を置き、チケット不要とすべき業務承認済みアプリには個別の許可ポリシーを追加デフォルト許可＋ゲート例外: 広く許可し、高リスクアプリにのみ承認 (または拒否)。LOTL封じ込めには弱い
予期しない起動を止めつつ、正当な新規ソフトウェアを恒久的にブロックしないことが目的の場合は、すべてのアプリケーション向けポリシーで承認を優先します。環境が未知の起動を承認経路なしで拒否すべき場合にのみ、レイヤーBでハードな拒否を使います。
LOTL緩和、ソフトウェアブロックリスト、インシデント対応での封じ込めでは、レイヤーAのパス一覧を外れる再配置、名前変更、予期しない起動を捉えるのがレイヤーBです。
レイヤーC: ハッシュ識別 (既知の不正バイナリ)
マルウェア検体、悪用されたツールのビルド、どこに現れても止めなければならないバイナリなど、特定の不正ファイルが分かっている場合は、その SHA256 ハッシュを拒否ポリシーに追加します。
一致の仕方は、アプリケーションコレクションメンバーの定義方法によって異なります。
ハッシュのみのメンバー: パスなしのSHA256。コンテンツハッシュのみで一致。ファイル名やフォルダの一致は不要。同じバイト列の名前変更や再配置コピーも引き続き拒否されます。目的が「特定バイナリをどこでもブロック」のときに使用
パス＋ハッシュのメンバー: 具体的なパスおよびSHA256 (インベントリアプリが
FullPathとFileHashの両方を渡す場合に多い)。パスとハッシュの両方の一致が必要。別フォルダから起動した同じバイト列はこのメンバーに一致しません。「この場所のこのファイルをブロック」であり、グローバルなコンテンツブロックではありません
パスだけでは足りないインシデント対応の封じ込めや精密なブロックリストでは、ハッシュのみのメンバーを優先するか、コレクションがハッシュをインストールパスにも結び付けていないことを確認します。
レイヤーD: 証明書識別 (信頼できる発行元)
発行元の証明書は、実行を信頼するソフトウェア向けの許可 (または制御を弱めた) ポリシーで使うのが適しています。
承認済みベンダーや署名済み製品に一致させ、脆いインストールパスだけに頼らず正当なアプリを起動可能にする
信頼できる発行元の許可リストには証明書を優先。「誰でも署名していればよい」を既知不正の拒否の代替にしない
レイヤーBと組み合わせ、未知または未署名の起動には引き続き承認を要求する (または拒否する) 一方で、信頼できる署名済みソフトウェアは許可する
レイヤーの連携
4つのレイヤーすべてを作成したスタックを考えます。
ユーザーが
C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exeを実行する。レイヤーAのパス承認ポリシーが一致 → 承認が必要 (承認されるまで起動はブロック)
ユーザーがそのファイルを
%USERPROFILE%\pwsh_copy.exeにコピーして実行する。レイヤーAのパス承認ポリシーは一致しない。
レイヤーBのすべてのアプリケーション向け承認ポリシーが一致 → 承認が必要。
そのバイナリ向けのハッシュ拒否も作成済みなら、レイヤーCも一致する。
レイヤーAだけを単独で評価すると「バイパス」に見えます。レイヤーBおよび/またはCがあれば、再配置された起動も引き続き制御されます。
複数のファイルアクセスポリシーが一致した場合の優先順位
同じ起動に複数の適用中ファイルアクセスポリシーが一致する場合、エージェントは無作為に1つを選びません。固定の順序を適用します。
ワイルドカードより具体的なポリシーを優先
一致したポリシーのあいだでは:
まずユーザーの具体性。 特定のユーザーまたはグループを指名したポリシーは、その人物についてすべてのユーザー (
*) を対象とするポリシーより優先されます。続いてアプリケーションの具体性。 特定のアプリケーションを対象とするポリシー (具体的なパス、ファイル名、証明書、コマンド制限など) は、アプリケーションスコープがワイルドカードの「すべてのアプリケーション」 (
*) だけのポリシーより優先されます。
帰結: 特定アプリの許可 (またはMFA / 承認) は、そのアプリについてすべてのアプリケーション向け拒否に勝てます。具体的なポリシーがより具体的な区分に入るためです。逆に、一致がすべてのアプリケーション向けポリシーだけの場合は、それらのワイルドカードポリシーが結果を決めます。
拒否は同一区分内で最優先のコントロールであり、同じ区分に許可があってもその許可の具体性にかかわらず評価を打ち切ります。具体性は区分間 (特定スコープとワイルドカードスコープ) の競合解決にのみ使い、すでに拒否を含む区分内では使いません。
平易な例
System32上の
powershell.exe向けの特定拒否と、すべてのアプリケーション向け許可。System32のPowerShellは特定区分で評価 → 拒否
すべてのアプリケーション向け許可にだけ一致する別アプリ → 許可
すべてのアプリケーション向け拒否と、
C:\Program Files\MyApp\app.exe向けの特定許可。MyAppは特定許可の区分に一致 → 許可 (特定がアプリワイルドカードに勝つ)
ユーザープロファイル配下の未知のコピーはワイルドカード拒否にのみ一致 → 拒否
すべてのアプリケーション向け拒否とすべてのアプリケーション向け承認 (同じ具体性)。
コントロール優先度で拒否が勝つ
全員向けのワイルドカードユーザー拒否と、同じアプリ上のAlice向けユーザー固有許可。
Aliceについてはユーザー固有ポリシーが勝つ → 許可
Bobについてはワイルドカードユーザーポリシーのみ適用 → 拒否
結果の意味 (ユーザーに見えるもの)
許可: 起動は続行。ファイルアクセスのチャレンジなし
拒否: 起動はブロック。一致したポリシー名を示す拒否メッセージが表示される場合あり
保留: MFA、正当な理由、および/または承認コントロールが正常に完了するまで起動を待機
承認が必要: 承認者がアクセスを付与するまでブロック扱い。拒否 (承認待ち) のワークフローとして示されることが多い
一致する適用ポリシーなし: ファイルアクセスは介在しない。そのイベントにはOSのデフォルトが適用
承認または正当な理由のワークフロー成功後に発行される一時的な付与により、限られた時間は再プロンプトなしで後続の起動を許可できます。一致する拒否ポリシーは、そのリソースに対する付与バイパスよりなお優先されます。付与期間の構成については、承認期間の構成をご参照ください。
LOTL、ブロックリスト、インシデント対応封じ込め向けの設計
以下のパターンを組み合わせて使います。
パス固有の承認: 高リスクツールの既知のシステム場所向け (ファイルアクセスポリシーの例1一覧をご参照ください)。実パスの正当な利用はレビュー後に付与可能にする
すべてのアプリケーション向け承認 (未知の起動を承認経路なしで拒否する必要がある場合は拒否): 明示的に許可していないものへの受け皿。パス再配置を止める役割
特定許可ポリシー: 承認済みの業務アプリケーション向け。任意で証明書による信頼できる発行元 (レイヤーD)
ハッシュベースの拒否: 現れる場所を問わずコンテンツ識別でブロックすべき既知不正バイナリ向け (レイヤーC)
封じ込めチェックリスト
封じ込めにファイルアクセスを頼る前に、以下を確認します。
すべてのアプリケーションに一致するポリシー、または許可リスト＋それ以外はすべて拒否の設計があるか
ユーザーが作業を続けられるよう、承認済みアプリが特定許可ポリシーでカバーされているか
「この既知不正バイナリをどこでもブロック」向けに、ハッシュのみの拒否があるか (レイヤーC)。パス＋ハッシュのインベントリメンバーや、
{system32}\...パスだけではないか「信頼できるベンダーを許可」向けに、許可ポリシー上の発行元証明書 (レイヤーD) と、それ以外をゲートするレイヤーBを併用しているか
実インストールパスとユーザー書き込み可能なフォルダ配下のコピーの両方をテストしたか
手順1だけを展開した場合、別フォルダへのコピーがそのパスポリシーを外れるのは正しい動作です。フィルター一致が設計どおり動いているのであり、より広いポリシーも一致しているときに拒否の強制が失敗したわけではありません。
クイックリファレンス
ファイルアクセスポリシーはいつ適用されるか。 ステータスが適用で、ユーザー、マシン、アプリケーション (パス、ハッシュ、または証明書)、ルール、スケジュールのフィルターがすべて起動に一致するときです。
System32パスの承認 (または拒否) は、別場所にコピーされたバイナリも止めるか。 いいえ。パスポリシーは起動パスに一致します。再配置のカバーには、すべてのアプリケーション向け承認、許可リスト、および/またはハッシュ (またはファイル名) による識別を使います。
ポリシーが競合するとき何が勝つか。
一致するフィルターのみ。
すべてのユーザーよりユーザー固有。その後、すべてのアプリケーションよりアプリ固有。
その集合の内部: 拒否 > 承認 > MFA / 正当な理由 / など > 許可
ファイルアクセスは最初からデフォルト拒否か。 いいえ。未知の起動をゲートまたは拒否したい場合はすべてのアプリケーション向け承認 (または拒否) を作成し、信頼するものを許可します。
関連する管理コンソールの概念
コレクション → アプリケーション: 「アプリ」の意味を定義 (パス、ハッシュ、インベントリメンバー)
ポリシー → ファイルアクセス: ユーザー、マシン、アプリケーション、コントロールを結び付け
ポリシーステータス: 適用、監視、または無効
ポリシーコントロール: 許可、拒否、MFA、正当な理由、承認、およびオペレーター承認
最終更新