# ポリシーのコントロール (グローバル許可ファイルアクセス - 承認必須)

<figure><img src="/files/WojKHVqTOa93JUCXTqjg" alt=""><figcaption></figcaption></figure>

本例は、**ファイルアクセスポリシー**を**アプリケーション実行に対するグローバルな承認要件**として使う方法を示します。有効にすると、ユーザーが起動しようとするあらゆるアプリケーションに適用され、すべてのエンドポイントにまたがる単一の最上位コントロールポイントになります。**ベースライン・ファイルアクセスポリシー**をこのように整えたうえで、特定のアプリケーション・チーム・シナリオについては承認なしで実行できるよう、追加のポリシーを足していけます。

***

### このポリシーの動作 <a href="#what-this-policy-does" id="what-this-policy-does"></a>

**対象内エンドポイント**上のユーザーがアプリケーションを実行しようとするとき、以下のとおりです。

1. 要求は**ファイルアクセス**のポリシーエンジンで評価されます。
2. ポリシーの対象範囲が広く設定されており (すべてのユーザー、すべてのアプリケーション)、対象の各エンドポイントではほとんどの実行試行に一致します。
3. 操作を続行する前に、**Keeper管理コンソール**で**承認**が得られる必要があります。

### この動作の理由 <a href="#why-it-behaves-this-way" id="why-it-behaves-this-way"></a>

このポリシーは意図的に「広く一致する」ポリシーとして書かれ、そのうえでコントロールを適用します。

* **適用**: ポリシーは有効で、(ログだけでなく) コントロールを適用します。
* **一致時の承認コントロール**: ポリシーに一致すると、承認ワークフローが起動します。
* **すべてのユーザー**: ワイルドカードのユーザーフィルターにより、対象マシン上のあらゆるユーザーアカウントに適用されます。
* **すべてのアプリケーション**: ワイルドカードのアプリケーションフィルターにより、このファイルアクセスポリシーで評価されるあらゆるアプリケーションに適用されます。
* **組み込みチェック**: 標準のチェック (ユーザー、マシン、ファイル、日時・曜日、証明書) があります。これらの制約を狭めていない場合 (例: 日時・曜日・証明書の制限を入れていない)、ポリシーは対象エンドポイント上の実行試行に広く一致するキャッチオールとして機能します。

### ユーザー側で起きること <a href="#what-the-user-experiences" id="what-the-user-experiences"></a>

* 対象エンドポイントでは、多くのアプリケーション起動で**承認要求**が発生します。
* ポリシーにはユーザー向けの通知メッセージが含まれます。特定の日付や一回限りのイベントに言及している場合は、本番では汎用的な文言に差し替えるか、削除して混乱を避けてください。

***

### 重要な注意点とよくある調整 <a href="#important-notes-and-common-adjustments" id="important-notes-and-common-adjustments"></a>

* **プロンプトが非常に多くなる**
  * すべてのアプリケーションに当てはまるため、特にエンドポイント数を増やすと承認が大量になりがちです。
* 必要に応じて**スコープを狭める**
  * アプリケーションフィルターを特定の実行ファイルやパスに限定する
  * ユーザーフィルターを特定のユーザー/グループに限定する
  * 証明書/発行者の制約を加え、信頼済みと未信頼のソフトウェアを分けて扱う
  * 段階的ロールアウトや営業時間内のみの適用のため、時刻・曜日・日付の制限を加える

***

## ベースライン・ファイルアクセスポリシーの作成手順 <a href="#how-build-a-baseline-file-access-policy" id="how-build-a-baseline-file-access-policy"></a>

{% stepper %}
{% step %}
**ポリシーの作成**

**Keeper管理コンソール**のエンドポイント特権マネージャーページで**ポリシー**タブを開き、<mark style="color:blue;">**ポリシーの作成**</mark>ボタンをクリックします。

<figure><img src="/files/RNRpoBrnNUFkJ8D0EVw6" alt=""><figcaption></figcaption></figure>

**ポリシー作成フォーム**がモーダルウィンドウで開きます。

<figure><img src="/files/p06fuYTDRNfdCqLkuZ65" alt=""><figcaption></figcaption></figure>
{% endstep %}

{% step %}
**ポリシー名**

新しいベースライン・ファイルアクセスポリシー用の、内容が分かる名前を入力します。

<figure><img src="/files/JSD8dXKTbgW5jFBD1n4i" alt="" width="375"><figcaption></figcaption></figure>
{% endstep %}

{% step %}
**ポリシータイプ**

**ポリシータイプ**の選択リストから<mark style="color:blue;">**ファイルアクセス**</mark>を選びます。

<figure><img src="/files/ovGL1RSymWLONruHEpMJ" alt="" width="375"><figcaption></figcaption></figure>
{% endstep %}

{% step %}
**ステータス**

**ポリシーの作成**フォームを完了して送信したときに、新しい**ベースライン・ファイルアクセスポリシー**に付けたいステータスを選びます。

<figure><img src="/files/Z3dkxV6uiyKd8p6x01lV" alt="" width="375"><figcaption></figcaption></figure>
{% endstep %}

{% step %}
**コントロール**

**コントロールの追加**サブフォームから<mark style="color:blue;">**承認が必要**</mark>を選びます。

<figure><img src="/files/C66TV3Oxh1OFdm7jEmTQ" alt="" width="307"><figcaption></figcaption></figure>
{% endstep %}

{% step %}
**ユーザーグループ**

ポリシー作成フォームで<mark style="color:blue;">**グループの追加**</mark>リンクをクリックします。**グループの追加**サブフォームが開きます。

<figure><img src="/files/9vm8KIJA0ZgftxT9XByf" alt="" width="273"><figcaption></figcaption></figure>

**グループの追加**サブフォームで<mark style="color:blue;">**すべてのユーザーを選択**</mark>にチェックを入れ、サブフォームの外側をクリックして閉じます。**すべてのユーザーとグループ**が、**ベースライン・ファイルアクセスポリシー**に適用された**ユーザーグループ**の下に表示されます。

<figure><img src="/files/5Odibeg17XB7UruCuMCA" alt="" width="375"><figcaption></figcaption></figure>
{% endstep %}

{% step %}
**マシンコレクション**

ポリシー作成フォームで<mark style="color:blue;">**コレクションの追加**</mark>リンクをクリックします。**コレクションの追加**サブフォームが開きます。

<figure><img src="/files/K8YExQKxyVMAoeanfzLU" alt="" width="375"><figcaption></figcaption></figure>

**コレクションの追加**サブフォームで<mark style="color:blue;">**すべてのマシンを選択**</mark>にチェックを入れ、サブフォームの外側をクリックして閉じます。**すべてのマシン**が、**ベースライン・ファイルアクセスポリシー**に適用された**マシンコレクション**の下に表示されます。
{% endstep %}

{% step %}
**アプリケーション**

ポリシー作成フォームで<mark style="color:blue;">**アプリケーションの追加**</mark>リンクをクリックします。**アプリケーションの追加**サブフォームが開きます。

<figure><img src="/files/KYaRtdzIK7iqLxwNRMAf" alt="" width="259"><figcaption></figcaption></figure>

**アプリケーションの追加**サブフォームで<mark style="color:blue;">**すべてのアプリケーションを選択**</mark>にチェックを入れ、サブフォームの外側をクリックして閉じます。**すべてのアプリケーション**が、**ベースライン・ファイルアクセスポリシー**に適用された**アプリケーション**の下に表示されます。

<figure><img src="/files/M29keQfGt2fT5JbBcXSA" alt="" width="375"><figcaption></figcaption></figure>
{% endstep %}

{% step %}
**日付と時刻**

**ベースライン・ファイルアクセスポリシー**では、**日付と時刻の範囲**を<mark style="color:blue;">**常時**</mark>にすることを推奨します。時間帯の切れ目なく、承認を前提としたポリシー評価が継続して適用されます。

<figure><img src="/files/H1C2g8kH2rj0NtYfmnom" alt="" width="375"><figcaption></figcaption></figure>
{% endstep %}

{% step %}
**ベースライン・ファイルアクセスポリシーの保存**

これまでの手順どおりフォームに十分入力すると、<mark style="color:blue;">**保存**</mark>ボタンが非アクティブからアクティブに変わります。<mark style="color:blue;">**保存**</mark>をクリックします。**ポリシーの作成**モーダルが閉じ、**ベースライン・ファイルアクセスポリシー**が保存されます。

<div align="right"><figure><img src="/files/kv1gnUCvaITAmc4jCG00" alt="" width="44"><figcaption></figcaption></figure></div>
{% endstep %}
{% endstepper %}

***

## 代表的な利用場面 <a href="#use-case-definitions" id="use-case-definitions"></a>

### <mark style="color:blue;">このベースライン・ファイルアクセスポリシーを最初のポリシーとすべき理由</mark> <a href="#why-this-baseline-file-access-policy-should-be-your-first-policy" id="why-this-baseline-file-access-policy-should-be-your-first-policy"></a>

**ベースライン・ファイルアクセス**として、既定であらゆる実行試行を対象に含め、**承認が必要**とするこのパターンは、エンドポイント特権マネージャーにおいて明確で重要な戦略的役割を果たします。主な利用場面とその背景を以下に整理します。

### 基本的な考え方: 既定の承認必須による事実上の拒否 <a href="#the-core-concept-default-deny-via-default-require-approval" id="the-core-concept-default-deny-via-default-require-approval"></a>

危険なアプリケーションを最初からすべて列挙するのはほぼ不可能なので、この方式は**モデルを反転**します。既定ではすべてに承認が必要とし、信頼できる既知の安全なアプリケーションだけを例外として切り抜きます。ルールセット末尾の、既定拒否に相当するファイアウォール規則と概念的に似ています。

### 主な利用場面 <a href="#primary-use-cases" id="primary-use-cases"></a>

#### 1. 規制対象または高セキュリティ環境 <a href="#id-1-regulated-or-high-security-environments" id="id-1-regulated-or-high-security-environments"></a>

HIPAA、PCI-DSS、SOC 2、政府・防衛要件などのコンプライアンス枠組みの対象となる組織では、文書化された承認チェーンなしに**不正なソフトウェアが管理エンドポイントで実行されない**ことを示す必要がよくあります。承認必須のグローバルなファイルアクセスをベースラインにすると、すべてのアプリケーション起動に対する単一の監査可能なコントロールポイントになります。

#### 2. アプリケーション許可リスト (アローリスト) の展開 <a href="#id-2-application-allowlisting-rollouts" id="id-2-application-allowlisting-rollouts"></a>

アプリケーション許可リストを構築するときの理想的な**基盤層**です。いきなりすべてをブロックする (混乱が大きい) のではなく、以下のように進められます。

* ベースライン内でグローバルな承認要件から始める (ユーザーはまだ実行できるが、承認を要請する)
* どの実行が承認要請の対象になるか観察する
* IT承認済みソフト向けに、その上に**許可ポリシー**を追加する (承認ゲートを通さずに許可済みアプリが通過する)
* 許可リストが成熟したら、ベースラインを真の拒否ポリシーへ移行する

このポリシー構成は意図的に「広く一致し、コントロールを適用する」形で書かれており、ユーザーとアプリケーションのフィルターがともにワイルドカードのため、対象エンドポイント上の実行に対する広いキャッチオールとして機能します。

#### 3. パイロットまたは段階的展開 <a href="#id-3-pilot-or-phased-deployment" id="id-3-pilot-or-phased-deployment"></a>

エンドポイントの一群 (パイロットグループや部門など) に、アプリケーション実行の承認ワークフローを導入する例として使えます。セキュリティチームは承認フローを検証し、承認者のキャパシティを調整し、すべてのエンドポイントに展開する前に例外リストを構築できます。

#### 4. ゼロトラストのエンドポイント姿勢 <a href="#id-4-zero-trust-endpoint-posture" id="id-4-zero-trust-endpoint-posture"></a>

ゼロトラストでは**暗黙の信頼を排除**します。標準ユーザー向けアプリケーションであっても同様です。承認必須のグローバルなファイルアクセスをベースラインにすると、その姿勢を実行レイヤーで強制します。マシン上にあるからといって、どのアプリケーションも暗黙には信頼されません。

#### 5. インシデント対応/侵害の封じ込め <a href="#id-5-incident-response-breach-containment" id="id-5-incident-response-breach-containment"></a>

侵害を経験した、または疑う組織では、このポリシーを迅速に展開して**エンドポイントのセグメントをロックダウン**し、調査中はすべてのアプリケーション起動を人間の承認にできます。すぐにすべてをブロックして全停止を招かずに済みます。

#### 6. 高リスクのユーザーグループまたはマシン <a href="#id-6-high-risk-user-groups-or-machines" id="id-6-high-risk-user-groups-or-machines"></a>

請負業者、第三者ベンダー、機密性の高いネットワークセグメント上のエンドポイント (OT隣接、財務系など) では、グローバルな承認ポリシーが、最初からアプリ単位の細かいポリシー作成なしに最大限の監視を提供します。

***

### ファイルアクセスポリシーとする理由 (特権昇格ポリシーではない理由) <a href="#why-file-access-policy-not-privilege-elevation-for-the-use-cases" id="why-file-access-policy-not-privilege-elevation-for-the-use-cases"></a>

細かいが重要な違いです。**ファイルアクセスポリシー**は、ファイルの**実行** (アプリケーションが起動した瞬間) をポリシー評価でインターセプトします。**特権昇格**ポリシーは、昇格した権限で何かを実行しようとしたときにだけインターセプトします。ここではファイルアクセスを使うことで、ユーザーが管理者権限を必要とするかどうかにかかわらず、**あらゆるアプリケーション起動**に承認要件がかかり、カバレッジが広がります。

#### ベースラインを土台としたレイヤー型のポリシー戦略 <a href="#the-layered-policy-strategy-that-follows" id="the-layered-policy-strategy-that-follows"></a>

複数のポリシーを同一リソースに重ねるレイヤー型の構成で、防御の深さを確保できます。このベースラインのファイルアクセスポリシーが整ったあとの運用イメージは以下のとおりです。

| 優先度         | ポリシー                                 | スコープ             |
| ----------- | ------------------------------------ | ---------------- |
| 高           | **許可** — IT承認済みアプリ (ブラウザー、Office など) | 特定アプリ、すべてのユーザー   |
| 高           | **許可** — 開発者向けツール                    | 特定ユーザー/グループ      |
| 低 (キャッチオール) | **承認が必要** — 上記以外すべて                  | すべてのユーザー、すべてのアプリ |

優先度の高い許可ポリシーに一致したアプリケーションは、そのまま実行が許可されます。明示的に許可されていないものはすべて、承認必須のベースライン・ファイルアクセスポリシーが適用されます。

***

### 運用上の重要な考慮事項 <a href="#key-operational-consideration" id="key-operational-consideration"></a>

このポリシーはすべてのアプリケーションに適用されるため、特にエンドポイントを広げると承認要求が非常に多くなります。そのためドキュメントでは**パイロットグループ**から始め、広く展開する**前に**例外 (許可) ポリシーを整えることを推奨しています。バッチで展開しながらシステム性能とユーザーからの反応を監視し、運用要件に応じてポリシーを調整するのが推奨される進め方です。


---

# Agent Instructions: 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:

```
GET https://docs.keeper.io/keeperpam/jp/endpoint-privilege-manager/policies/policy-examples/policy-global-allow-file-access-require-approval.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
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.