> For the complete documentation index, see [llms.txt](https://docs.keeper.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.keeper.io/keeperpam/jp/endpoint-privilege-manager/policies/policy-reference/policy-evaluation/file-access-policy-evaluation-guide.md).

# ファイルアクセスポリシー評価ガイド

<figure><img src="https://859776093-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FPL6k1aGsLiFiiJ3Y7zCl%2Fuploads%2Fgit-blob-b42940b26d67e5125d661705d1d0ce1f7e3eaac0%2Fimage%20(493).png?alt=media" alt=""><figcaption></figcaption></figure>

本ページでは、ファイルアクセスポリシーがいつ適用されるか、レイヤー型 (多層防御) のポリシーがどう連携するか、同じ起動に複数が一致したときにどれが優先されるかを取り扱います。

作成方法は[ファイルアクセスポリシー](/keeperpam/jp/endpoint-privilege-manager/policies/policy-types/file-access-policy-type.md)のページが対象です。本ページは**評価の挙動**を考えるときにご利用ください。起動がゲートされた (またはされなかった) 理由や、単一のパス一覧を超えて成り立つポリシースタックの設計に役立ちます。

{% hint style="info" %}
コントロールの種類、ステータスモード、作成ワークフローについては、[ファイルアクセスポリシー](/keeperpam/jp/endpoint-privilege-manager/policies/policy-types/file-access-policy-type.md)をご参照ください。アプリケーションフィルターとフォルダフィルターでのワイルドカードの挙動については、[ワイルドカード](/keeperpam/jp/endpoint-privilege-manager/policies/policy-reference/wildcards.md)をご参照ください。パス変数の解決については、[パス変数と保護パス](/keeperpam/jp/endpoint-privilege-manager/policies/policy-reference/path-variables.md)をご参照ください。
{% endhint %}

### ファイルアクセスポリシーが制御する内容 <a href="#what-file-access-policies-control" id="what-file-access-policies-control"></a>

ファイルアクセスポリシーは、管理対象エンドポイント上でユーザーがアプリケーションを**起動**できるか (またはファイルアクセスのワークフローで保護ファイルを開けるか) を判定します。

起動がインターセプトされると、エージェントは有効なファイルアクセスポリシーを以下に対して評価します。

* **誰が**起動しているか: ユーザーおよびグループのコレクション
* **どのマシン**で起動しているか: マシンコレクション
* **何を**起動しているか: アプリケーションコレクション (パス、ファイル名、ファイルハッシュ、および/または証明書)
* 任意の**時刻、曜日、日付**のスケジュール
* ポリシーの**コントロール:** 許可、拒否、MFA、正当な理由、承認、およびそれらの組み合わせ

起動をブロックまたはゲートできるのは、ステータスが**適用**のポリシーだけです。**監視**ポリシーは監査のみで、すでに適用ポリシーが一致している場合は強制しません。

### ファイルアクセスポリシーが適用される条件 <a href="#when-a-file-access-policy-applies" id="when-a-file-access-policy-applies"></a>

ポリシーが起動に適用されるのは、以下の**すべて**が真の場合のみです。

1. **ステータス**が適用である (無効ではなく、強制が目的の場合は監視でもない)
2. **ユーザー**がポリシーのユーザーまたはグループのスコープに一致する (またはポリシーがすべてのユーザーを対象としている)
3. **マシン**がポリシーのマシンスコープに一致する (またはすべてのマシン)
4. **アプリケーションまたはファイル**がポリシーのアプリケーションスコープに一致する (アプリケーションの一致の仕組みをご参照ください)
5. ポリシー上の**ルール**があれば通過する (ユーザーチェックやファイルチェックなど)
6. 任意の**スケジュール**フィルター (曜日、日付、時刻) がある場合、「現在」がその範囲に含まれる

必須フィルターのいずれかが失敗すると、そのポリシーはこの起動には適用されません。他のポリシーは引き続き適用される場合があります。

#### 一致対象は評価中の起動 <a href="#matching-is-against-the-launch-being-evaluated" id="matching-is-against-the-launch-being-evaluated"></a>

ファイルアクセスでは、アプリケーションの一致は**いま起動しようとしているプロセスのパス (および任意のハッシュまたは証明書)** と比較されます。「ディスク上にかつて存在したこのツールの任意のコピー」ではありません。

したがって:

* `{system32}\WindowsPowerShell\v1.0\powershell.exe` を列挙したポリシーは、**そのシステムパス上の**PowerShellに一致します。
* 同じバイト列を `C:\Users\alice\pwsh_copy.exe` にコピーしたものは**別の起動パス**です。上記のパス固有ポリシーは、ハッシュ、ファイル名パターン、証明書、またはより広いアプリケーションスコープ (例: すべてのアプリケーション) でも対象にしていない限り、そのコピーには一致しません。

この挙動はパスベースのコレクションでは想定どおりです。耐久性のあるLiving-off-the-Land (LOTL) やブロックリストの設計で、単一のパス一覧だけでなく**レイヤー型**ポリシー (多層防御をご参照ください) を使う理由でもあります。

### アプリケーションの一致の仕組み <a href="#how-application-matching-works" id="how-application-matching-works"></a>

アプリケーションコレクションは、ソフトウェアをいくつかの方法で識別できます。コレクションのメンバーは**OR**で結合され、いずれか1つ一致すればそのコレクションには十分です。

#### パスまたはファイル名のパターン <a href="#path-or-filename-patterns" id="path-or-filename-patterns"></a>

* パス変数解決後のフルパス (例: `{system32}\cmd.exe` は `C:\Windows\System32\cmd.exe` に解決)
* パス内のワイルドカード (例: `{programfiles}\*\*.exe`)
* ファイル名のみのパターン (例: `powershell.exe`): **任意の**ディレクトリ配下のその名前に一致可能
* ワイルドカード `*` (または空 / すべてのアプリケーションのコレクション): そのフィルターでは**すべての**アプリケーションに一致

#### コンテンツハッシュ (SHA256) <a href="#content-hash-sha256" id="content-hash-sha256"></a>

* ハッシュのみのコレクションメンバーは、起動元の場所にかかわらず**ファイルの内容**に一致
* パス**および**ハッシュのメンバーは、パスパターンとハッシュの**両方**の一致が必要

#### 発行元証明書 <a href="#publisher-certificate" id="publisher-certificate"></a>

構成されている場合、ポリシーは一致するコード署名証明書または拇印も要求できます。[証明書フィルター (CertificationCheck)](/keeperpam/jp/endpoint-privilege-manager/policies/policy-reference/certificate-filter-certificationcheck.md)をご参照ください。

#### 実務上の指針 <a href="#practical-guidance" id="practical-guidance"></a>

* **通常のインストール場所でのみツールをブロックする:** パスパターンを使用 (ファイルアクセスポリシーのページにある例1形式の一覧)
* **別の場所にコピーされた同じバイナリもブロックする:** ファイルハッシュ (レイヤーC) および/またはファイル名のみのパターンに加え、広い承認または許可リストの姿勢 (レイヤーB) を併用
* **承認済みソフトウェアのみ許可する:** 既知のアプリおよび/または信頼できる発行元を証明書で許可リスト化 (レイヤーD)。それ以外はすべてのアプリケーション向けポリシーで承認を要求する (または拒否する)

### ファイルアクセスポリシーが一致しない場合の挙動 <a href="#what-happens-when-no-file-access-policy-matches" id="what-happens-when-no-file-access-policy-matches"></a>

**適用**中のファイルアクセスポリシーが起動に一致しない場合:

* エージェントはそのイベントにファイルアクセスコントロールを適用しません。
* 結果は実質的にファイルアクセスの **EnforcementDisabled** となり、その起動にはOSのデフォルト挙動が適用されます。特権昇格など他のポリシータイプは、昇格が要求されていれば引き続き適用される場合があります。

ファイルアクセス単体は、暗黙の「すべて拒否」製品モードではありません。**デフォルトでゲート**または**デフォルト拒否**は、すべてのアプリケーション向けの承認 (または拒否) ポリシーを作成し、承認済みソフトウェア向けに許可を切り出す姿勢として設計します。

## 多層防御 (推奨モデル) <a href="#defense-in-depth-recommended-model" id="defense-in-depth-recommended-model"></a>

ファイルアクセスは、単一のパス一覧ではなく**ポリシーのスタック**として扱います。

### レイヤーA: 特定パスの承認 (既知の場所) <a href="#layer-a-specific-path-approvals-known-locations" id="layer-a-specific-path-approvals-known-locations"></a>

`{system32}\cmd.exe`、`{system32}\WindowsPowerShell\v1.0\powershell.exe`、`certutil.exe`、その他ドキュメント化されたシステムパス上のLOTLツールに対し、**承認** (またはMFA / 正当な理由 + 承認) を要求します。

* 実インストール場所からの安易な利用を、明示的な承認ワークフローの背後にゲート
* 監査向けに明確 (「System32上のPowerShellは承認が必要」)
* レビュー後も正当な管理者やサポートによる実システムパスの利用を残す必要がある場合は、ここでハードな拒否より承認を優先
* このレイヤーだけでは、ユーザーが別パス上のコピーを実行することを止められない

### レイヤーB: 広い姿勢 (すべてのアプリケーションまたは許可リスト) <a href="#layer-b-broad-posture-all-applications-or-allow-list" id="layer-b-broad-posture-all-applications-or-allow-list"></a>

よくあるパターンは2つです。

* **デフォルトでゲート:** **すべてのアプリケーション** (`*`) にファイルアクセスの**承認**を置き、チケット不要とすべき業務承認済みアプリには個別の許可ポリシーを追加
* **デフォルト許可＋ゲート例外:** 広く許可し、高リスクアプリにのみ承認 (または拒否)。LOTL封じ込めには弱い

予期しない起動を止めつつ、正当な新規ソフトウェアを恒久的にブロックしないことが目的の場合は、すべてのアプリケーション向けポリシーで**承認**を優先します。環境が未知の起動を承認経路なしで拒否すべき場合にのみ、レイヤーBでハードな拒否を使います。

LOTL緩和、ソフトウェアブロックリスト、インシデント対応での封じ込めでは、レイヤーAのパス一覧を外れる**再配置、名前変更、予期しない**起動を捉えるのがレイヤーBです。

### レイヤーC: ハッシュ識別 (既知の不正バイナリ) <a href="#layer-c-hash-identity-known-bad-binaries" id="layer-c-hash-identity-known-bad-binaries"></a>

マルウェア検体、悪用されたツールのビルド、どこに現れても止めなければならないバイナリなど、**特定の不正ファイル**が分かっている場合は、その `SHA256` ハッシュを拒否ポリシーに追加します。

一致の仕方は、アプリケーションコレクションメンバーの定義方法によって異なります。

* **ハッシュのみのメンバー:** パスなしのSHA256。**コンテンツハッシュのみ**で一致。ファイル名やフォルダの一致は不要。同じバイト列の名前変更や再配置コピーも引き続き**拒否**されます。目的が「特定バイナリをどこでもブロック」のときに使用
* **パス＋ハッシュのメンバー:** 具体的なパス**および**SHA256 (インベントリアプリが `FullPath` と `FileHash` の両方を渡す場合に多い)。パスとハッシュの**両方**の一致が必要。別フォルダから起動した同じバイト列はこのメンバーに一致しません。「この場所のこのファイルをブロック」であり、グローバルなコンテンツブロックではありません

パスだけでは足りないインシデント対応の封じ込めや精密なブロックリストでは、**ハッシュのみ**のメンバーを優先するか、コレクションがハッシュをインストールパスにも結び付けていないことを確認します。

### レイヤーD: 証明書識別 (信頼できる発行元) <a href="#layer-d-certificate-identity-trusted-publishers" id="layer-d-certificate-identity-trusted-publishers"></a>

発行元の**証明書**は、実行を信頼するソフトウェア向けの**許可** (または制御を弱めた) ポリシーで使うのが適しています。

* 承認済みベンダーや署名済み製品に一致させ、脆いインストールパスだけに頼らず正当なアプリを起動可能にする
* 信頼できる発行元の許可リストには証明書を優先。「誰でも署名していればよい」を既知不正の拒否の代替にしない
* レイヤーBと組み合わせ、未知または未署名の起動には引き続き承認を要求する (または拒否する) 一方で、信頼できる署名済みソフトウェアは許可する

### レイヤーの連携 <a href="#how-the-layers-work-together" id="how-the-layers-work-together"></a>

4つのレイヤーすべてを作成したスタックを考えます。

1. ユーザーが `C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe` を実行する。
   * レイヤーAのパス承認ポリシーが一致 → **承認が必要** (承認されるまで起動はブロック)
2. ユーザーがそのファイルを `%USERPROFILE%\pwsh_copy.exe` にコピーして実行する。
   * レイヤーAのパス承認ポリシーは一致しない。
   * レイヤーBのすべてのアプリケーション向け承認ポリシーが一致 → **承認が必要**。
   * そのバイナリ向けのハッシュ拒否も作成済みなら、レイヤーCも一致する。

レイヤーAだけを単独で評価すると「バイパス」に見えます。レイヤーBおよび/またはCがあれば、再配置された起動も引き続き制御されます。

## 複数のファイルアクセスポリシーが一致した場合の優先順位 <a href="#multiple-file-access-policy-match-precedence" id="multiple-file-access-policy-match-precedence"></a>

同じ起動に複数の適用中ファイルアクセスポリシーが一致する場合、エージェントは無作為に1つを選びません。固定の順序を適用します。

{% stepper %}
{% step %}

### フィルターに一致するポリシーを残す <a href="#keep-policies-that-match-filters" id="keep-policies-that-match-filters"></a>

ユーザー、マシン、アプリケーション、ルール、スケジュールのフィルターを通過したポリシーだけが候補です。
{% endstep %}

{% step %}

### ワイルドカードより具体的なポリシーを優先 <a href="#prefer-more-specific-policies-over-wildcards" id="prefer-more-specific-policies-over-wildcards"></a>

一致したポリシーのあいだでは:

1. **まずユーザーの具体性。** 特定のユーザーまたはグループを指名したポリシーは、その人物についてすべてのユーザー (`*`) を対象とするポリシーより優先されます。
2. **続いてアプリケーションの具体性。** **特定の**アプリケーションを対象とするポリシー (具体的なパス、ファイル名、証明書、コマンド制限など) は、アプリケーションスコープがワイルドカードの「すべてのアプリケーション」 (`*`) だけのポリシーより優先されます。

**帰結:** 特定アプリの**許可** (またはMFA / 承認) は、そのアプリについてすべてのアプリケーション向け**拒否**に勝てます。具体的なポリシーがより具体的な区分に入るためです。逆に、一致がすべてのアプリケーション向けポリシーだけの場合は、それらのワイルドカードポリシーが結果を決めます。
{% endstep %}

{% step %}

### 勝った区分内ではコントロール優先度を適用 <a href="#within-the-winning-bucket-apply-control-priority" id="within-the-winning-bucket-apply-control-priority"></a>

具体性のあと残ったポリシーのあいだでは、コントロールは以下の順位です。

1. **拒否:** 最優先、ハードブロック
2. **承認が必要:** 承認が完了するまでブロック。構成によっては他の保留コントロールと併用される場合あり
3. **保留コントロール:** MFA、正当な理由、オペレーター承認など
4. **許可**
5. **監視**モードは、すでに適用ポリシーが効いている場合は強制しない。

勝った区分内のいずれかのポリシーに**拒否**があれば、起動は拒否されます。同じ区分内では許可は拒否を上書きできません。
{% endstep %}
{% endstepper %}

{% hint style="warning" %}
**拒否は同一区分内で最優先のコントロールであり、同じ区分に許可があってもその許可の具体性にかかわらず評価を打ち切ります。具体性は区分間 (特定スコープとワイルドカードスコープ) の競合解決にのみ使い、すでに拒否を含む区分内では使いません。**
{% endhint %}

#### 平易な例 <a href="#plain-language-examples" id="plain-language-examples"></a>

* System32上の `powershell.exe` 向けの**特定拒否**と、**すべてのアプリケーション向け許可**。
  * System32のPowerShellは特定区分で評価 → **拒否**
  * すべてのアプリケーション向け許可にだけ一致する別アプリ → **許可**
* **すべてのアプリケーション向け拒否**と、`C:\Program Files\MyApp\app.exe` 向けの**特定許可**。
  * MyAppは特定許可の区分に一致 → **許可** (特定がアプリワイルドカードに勝つ)
  * ユーザープロファイル配下の未知のコピーはワイルドカード拒否にのみ一致 → **拒否**
* **すべてのアプリケーション向け拒否**と**すべてのアプリケーション向け承認** (同じ具体性)。
  * コントロール優先度で**拒否**が勝つ
* 全員向けの**ワイルドカードユーザー拒否**と、同じアプリ上のAlice向け**ユーザー固有許可**。
  * Aliceについてはユーザー固有ポリシーが勝つ → **許可**
  * Bobについてはワイルドカードユーザーポリシーのみ適用 → **拒否**

### 結果の意味 (ユーザーに見えるもの) <a href="#outcome-meanings-what-the-user-sees" id="outcome-meanings-what-the-user-sees"></a>

* **許可:** 起動は続行。ファイルアクセスのチャレンジなし
* **拒否:** 起動はブロック。一致したポリシー名を示す拒否メッセージが表示される場合あり
* **保留:** MFA、正当な理由、および/または承認コントロールが正常に完了するまで起動を待機
* **承認が必要:** 承認者がアクセスを付与するまでブロック扱い。拒否 (承認待ち) のワークフローとして示されることが多い
* **一致する適用ポリシーなし:** ファイルアクセスは介在しない。そのイベントにはOSのデフォルトが適用

承認または正当な理由のワークフロー成功後に発行される一時的な**付与**により、限られた時間は再プロンプトなしで後続の起動を許可できます。一致する**拒否**ポリシーは、そのリソースに対する付与バイパスよりなお優先されます。付与期間の構成については、[承認期間の構成](/keeperpam/jp/endpoint-privilege-manager/policies/policy-reference/configuring-the-approval-duration.md)をご参照ください。

### LOTL、ブロックリスト、インシデント対応封じ込め向けの設計 <a href="#designing-for-lotl-blocklists-and-incident-response-containment" id="designing-for-lotl-blocklists-and-incident-response-containment"></a>

以下のパターンを組み合わせて使います。

1. **パス固有の承認:** 高リスクツールの既知のシステム場所向け (ファイルアクセスポリシーの例1一覧をご参照ください)。実パスの正当な利用はレビュー後に付与可能にする
2. **すべてのアプリケーション向け承認** (未知の起動を承認経路なしで拒否する必要がある場合は拒否): 明示的に許可していないものへの受け皿。パス再配置を止める役割
3. **特定許可**ポリシー: 承認済みの業務アプリケーション向け。任意で証明書による信頼できる発行元 (レイヤーD)
4. **ハッシュベースの拒否:** 現れる場所を問わずコンテンツ識別でブロックすべき既知不正バイナリ向け (レイヤーC)

#### 封じ込めチェックリスト <a href="#containment-checklist" id="containment-checklist"></a>

封じ込めにファイルアクセスを頼る前に、以下を確認します。

* **すべてのアプリケーション**に一致するポリシー、または許可リスト＋それ以外はすべて拒否の設計があるか
* ユーザーが作業を続けられるよう、承認済みアプリが**特定許可**ポリシーでカバーされているか
* 「この既知不正バイナリをどこでもブロック」向けに、**ハッシュのみ**の拒否があるか (レイヤーC)。パス＋ハッシュのインベントリメンバーや、`{system32}\...` パスだけではないか
* 「信頼できるベンダーを許可」向けに、許可ポリシー上の**発行元証明書** (レイヤーD) と、それ以外をゲートするレイヤーBを併用しているか
* **実インストールパス**と**ユーザー書き込み可能なフォルダ配下のコピー**の両方をテストしたか

手順1だけを展開した場合、別フォルダへのコピーがそのパスポリシーを外れるのは正しい動作です。フィルター一致が設計どおり動いているのであり、より広いポリシーも一致しているときに拒否の強制が失敗したわけではありません。

### クイックリファレンス <a href="#quick-reference" id="quick-reference"></a>

**ファイルアクセスポリシーはいつ適用されるか。** ステータスが適用で、ユーザー、マシン、アプリケーション (パス、ハッシュ、または証明書)、ルール、スケジュールのフィルターがすべて起動に一致するときです。

**System32パスの承認 (または拒否) は、別場所にコピーされたバイナリも止めるか。** いいえ。パスポリシーは起動パスに一致します。再配置のカバーには、すべてのアプリケーション向け承認、許可リスト、および/またはハッシュ (またはファイル名) による識別を使います。

**ポリシーが競合するとき何が勝つか。**

1. 一致するフィルターのみ。
2. すべてのユーザーよりユーザー固有。その後、すべてのアプリケーションよりアプリ固有。
3. その集合の内部: **拒否 > 承認 > MFA / 正当な理由 / など > 許可**

**ファイルアクセスは最初からデフォルト拒否か。** いいえ。未知の起動をゲートまたは拒否したい場合はすべてのアプリケーション向け承認 (または拒否) を作成し、信頼するものを許可します。

### 関連する管理コンソールの概念 <a href="#related-admin-console-concepts" id="related-admin-console-concepts"></a>

* [**コレクション**](/keeperpam/jp/endpoint-privilege-manager/collections.md) **→ アプリケーション:** 「アプリ」の意味を定義 (パス、ハッシュ、インベントリメンバー)
* [**ポリシー → ファイルアクセス**](/keeperpam/jp/endpoint-privilege-manager/policies/policy-types/file-access-policy-type.md): ユーザー、マシン、アプリケーション、コントロールを結び付け
* [**ポリシーステータス**](/keeperpam/jp/endpoint-privilege-manager/policies/policy-status.md): 適用、監視、または無効
* [**ポリシーコントロール**](/keeperpam/jp/endpoint-privilege-manager/policies/policy-controls.md): 許可、拒否、MFA、正当な理由、承認、およびオペレーター承認

{% hint style="info" %}
本ページは、プロセス起動制御における顧客向けに見えるファイルアクセスの評価挙動を取り扱います。特権昇格、エージェント型AIポリシータイプ、OS ACLによるファイル保護ワークフローは関連しつつ別のルールに従います。ベースラインのファイルアクセスからの拒否は、それらのポリシーが有効なとき、エージェント駆動の起動もブロックします。
{% endhint %}


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.keeper.io/keeperpam/jp/endpoint-privilege-manager/policies/policy-reference/policy-evaluation/file-access-policy-evaluation-guide.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.