> 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-examples/anti-ransomware-policies/gate-4-data-protection.md).

# ゲート4: データ保護

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

**対象:** 多層のKeeper EPMランサムウェア対策ベースラインを展開するWindows管理者向けです。

***

多層ランサムウェア対策モデルの概要と、このゲートの位置づけは[ランサムウェア対策ポリシー](/keeperpam/jp/endpoint-privilege-manager/policies/policy-examples/anti-ransomware-policies.md)をご参照ください。

本ポリシーは、Windows上で多層展開するKeeper EPMランサムウェア対策における**データ保護ゲート**です。他の3ゲートが実行、昇格、復旧手段の破壊を止めるのに対し、本ゲートはデータ自体を保護します。ファイルアクセスポリシーは保護ディレクトリのNTFS ACLを変更し、ポリシーコントロール (承認、MFA、正当な理由の入力) を満たさない限りREAD、WRITE、DELETEを拒否します。保護はOS自体が強制するため、ユーザーのフルトークンで動作するランサムウェア暗号化プロセスでも、保護ディレクトリ内のファイルを上書き・削除できません。Windowsがファイルシステム層でI/Oを拒否します。

最後の防衛線です。ゲート1〜3がすべて失敗し、ランサムウェアが暗号化を開始しても、本ゲートがデータを保全します。

### 手順: ポリシーの作成 <a href="#step-by-step-create-the-policy" id="step-by-step-create-the-policy"></a>

{% stepper %}
{% step %}

### 保護するディレクトリの特定

すべてのディレクトリを保護する必要はありません。広すぎる保護は摩擦だけを増やし、便益に見合いません。喪失が重大インシデントに相当するディレクトリに絞ります。

* 財務・会計共有のルート (総勘定、売掛/買掛の作業ファイル、給与エクスポート)
* 開発者エンドポイント上のソースコードリポジトリ (`C:\repos`、`C:\src`、`C:\dev`)
* 役員共有と取締役会資料
* HRデータ (従業員記録、福利厚生、評価資料)
* リーガルホールドと訴訟関連ディレクトリ
* バックアップステージングディレクトリ (オフホスト先へ書き込む前)
* エンジニアリング文書、IP、設計ファイル
* 顧客データエクスポートとCRM作業ファイル

{% hint style="info" %}
ドライブ全体やユーザープロファイルルートは保護しないでください。広すぎる保護は承認トラフィックを過剰にし、ユーザーが内容を読まずにクリックする習慣を助長します。本当に重要なディレクトリに絞ることで、運用負荷を抑えつつ意味のある統制になります。
{% endhint %}
{% endstep %}

{% step %}

### アプリケーションコレクションの作成

ディレクトリ向けファイルアクセスポリシーのアプリケーションコレクションは、実行ファイルコレクションとは別パターンです。各エントリはファイル名ではなくディレクトリパスです。必要に応じてパス変数 (`{userprofile}`、`{public}` など) を使いますが、データ保護の多くはリテラルパスです。

1. Keeper管理コンソールで **\[エンドポイント特権マネージャー]** → **\[コレクション]** → **\[アプリケーション]** に移動します。
2. **\[新しいコレクション]** をクリックします。
3. **\[新しいコレクション]** モーダルで以下を設定します。

   * **タイプ**: `Applications`
   * **名前**: `Protected Data Directories (Windows)`
   * **\[次へ]** をクリックします。

   <figure><img src="/files/VaD2ZEJgaPxso1RKsrSd" alt="" width="264"><figcaption></figcaption></figure>
4. **\[コレクションへのアイテム追加]** モーダルで **\[リソースを手動で定義する]** にチェックを入れます。
5. 保護ディレクトリをカスタムリソースとして追加します。例:

   * `C:\Finance`
   * `C:\Legal\LitigationHold`
   * `C:\repos`
   * `C:\Executive`
   * `C:\HR\Records`

   <figure><img src="/files/729wHV48pymVB9ryLdI2" alt="" width="244"><figcaption></figcaption></figure>

   **環境に合わせてパスを調整してください。** ユーザーエンドポイントでドライブレターにマップされたネットワーク共有は、ユーザーが見るマップ済みパス (例: `S:\Finance`) を使います。

{% hint style="danger" %}
コレクション保存時にコレクションのUIDを控えてください。
{% endhint %}

<figure><img src="/files/qh9mXnt8w7iFU4cc8Rg7" alt="" width="201"><figcaption></figcaption></figure>

{% hint style="info" %}
非実行パスへのファイルアクセスポリシー適用はネイティブNTFS ACLを使います。Keeperは保護パス上の対象ユーザー向けに明示的なDENY ACEを追加します。ユーザーがアクセスを要求しポリシーコントロールを満たすと、ACEを変更して付与期間中の読み書きを許可します。保護はWindows自体が強制するため、ランサムウェアプロセスがユーザーのフルトークンを持っていても有効です。
{% endhint %}
{% endstep %}

{% step %}

### ポリシーの作成

1. **\[エンドポイント特権マネージャー]** → **\[ポリシー]** に移動し、**\[ポリシーの作成]** をクリックします。
2. ポリシー詳細を入力します。
   * **ポリシー名**: `Protect Sensitive Data Directories (Windows)`
   * **ポリシータイプ**: `File Access`
   * **ステータス**: 初期パイロットは `Monitor`。**\[監視]** モードではACLを実際には適用せず、プロンプト対象となるユーザーをログに記録し、適用前の承認トラフィックをプレビューできます。

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

{% step %}

### 承認コントロールの追加

1. **\[コントロールを追加]** をクリックします。
2. **\[管理者承認]** を選択します。

<figure><img src="/files/LuHBcXm7x5bB7IEkhiv5" alt="" width="267"><figcaption></figcaption></figure>

{% hint style="info" %}
データ保護では、監査付きリクエストワークフローで正当なアクセスを維持できるため、承認が既定の推奨です。代替案は以下のとおりです。

* 監査記録で足り、承認者が不要な低摩擦ディレクトリには **\[正当な理由が必要]**
* 正当なアクセスはあるが資格情報の紐づけを追加したいディレクトリには **\[MFA必須]**
* いかなる場合も書き込みを許可しないディレクトリには **\[拒否]** (データディレクトリでは稀。システム領域でより一般的)
  {% endhint %}
  {% endstep %}

{% step %}

### フィルターの設定

1. **アカウント**: **\[すべてのアカウント]** (ワイルドカード) を選択します。除外 (例: 正当なバックアップソフトのサービスアカウント) は別途優先度の高い許可ポリシーで扱います。
2. **マシンコレクション**: Windowsエンドポイントコレクションを選択します。特定エンドポイントにのみ存在するディレクトリ (例: 開発者マシンのみの `C:\repos`) は、開発者向けマシンコレクションに限定します。
3. **アプリケーション**: 手順2の `Protected Data Directories (Windows)` コレクションを選択します。
4. **日時範囲**は未設定のままにします。

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

{% step %}

### Advanced Modeでの通知設定

1. **通知メッセージ**: `Keeper EPM protects this directory because it contains sensitive business data. Please submit your access request with a brief description of what you need to do. Your administrator will be notified to approve.`

<figure><img src="/files/8dLryZQZ12LWp398Uvyf" alt="" width="563"><figcaption></figcaption></figure>
{% endstep %}

{% step %}

### 保存とパイロット

1. **\[保存]** をクリックします。ポリシーは約30分以内に適用範囲内のすべてのエンドポイントへ配布されます。
2. **少なくとも1週間監視モードで運用**します。監査ログで通常のアクセスパターンを把握します。
   * 各保護ディレクトリにルーティンでアクセスするユーザーは誰か
   * 適用モードでは承認トラフィックはどの程度になるか
   * 除外が必要な正当な自動プロセス (バックアップエージェント、インデックスサービス) はあるか
3. 正当な自動化向けの除外ポリシーを整備します。最も一般的な例は、エンタープライズバックアップソフト (Veeam、CommVault、Backup Exec) が保護ディレクトリへの読み取りを必要とする場合で、バックアップサービスアカウント向けの許可ポリシーを作成します。
4. 監視データを把握し除外が整ったら、**\[ステータス]** を `Enforce` に変更します。NTFS ACLの変更は約30分以内に適用され、承認済みリクエストなしのアクセス試行はOS層で拒否されます。
   {% endstep %}
   {% endstepper %}

### 参考: ポリシーJSON <a href="#reference-policy-json" id="reference-policy-json"></a>

以下は完成したポリシーのエクスポート形式です。`<generated-policy-uid>` と `<uid-of-Protected-Data-Directories-collection>` のプレースホルダーは、管理コンソールでポリシーとコレクションを作成すると自動で埋まります。

```json
{
	"PolicyName": "Protect Sensitive Data Directories (Windows)",
	"PolicyType": "FileAccess",
	"PolicyId": "<generated-policy-uid>",
	"Status": "enforce",
	"Actions": {
		"OnSuccess": {
			"Controls": [
				"APPROVAL"
			]
		},
		"OnFailure": {
			"Command": ""
		}
	},
	"NotificationMessage": "Keeper EPM protects this directory because it contains sensitive business data. Please submit your access request with a brief description of what you need to do. Your administrator will be notified to approve.",
	"NotificationRequiresAcknowledge": false,
	"RiskLevel": 85,
	"Operator": "And",
	"Rules": [
		{
			"RuleName": "UserCheck",
			"ErrorMessage": "This user is not included in this policy",
			"RuleExpressionType": "BuiltInAction",
			"Expression": "CheckUser()"
		},
		{
			"RuleName": "MachineCheck",
			"ErrorMessage": "This Machine is not included in this policy",
			"RuleExpressionType": "BuiltInAction",
			"Expression": "CheckMachine()"
		},
		{
			"RuleName": "ApplicationCheck",
			"ErrorMessage": "This application is not included in this policy",
			"RuleExpressionType": "BuiltInAction",
			"Expression": "CheckFile(false)"
		},
		{
			"RuleName": "DateCheck",
			"ErrorMessage": "Current date is not covered by this policy",
			"RuleExpressionType": "BuiltInAction",
			"Expression": "CheckDate()"
		},
		{
			"RuleName": "TimeCheck",
			"ErrorMessage": "Current time is not covered by this policy",
			"RuleExpressionType": "BuiltInAction",
			"Expression": "CheckTime()"
		},
		{
			"RuleName": "DayCheck",
			"ErrorMessage": "Today is not included in this policy",
			"RuleExpressionType": "BuiltInAction",
			"Expression": "CheckDay()"
		},
		{
			"RuleName": "CertificateCheck",
			"ErrorMessage": "Certificate hash is not included in this policy",
			"RuleExpressionType": "BuiltInAction",
			"Expression": "CheckCertificate()"
		}
	],
	"UserCheck": [
		"*"
	],
	"MachineCheck": [
		"*"
	],
	"ApplicationCheck": [
		"<uid-of-Protected-Data-Directories-collection>"
	],
	"DayCheck": [],
	"DateCheck": [],
	"TimeCheck": [],
	"CertificationCheck": [],
	"Extension": {}
}
```

### 本ゲートの重要性 <a href="#why-this-gate-matters" id="why-this-gate-matters"></a>

最初の3ゲートは、ランサムウェアが被害を与える前に止めることを目的とします。本ゲートは、予防的統制に完璧はなく、失敗の結果がデータ喪失であるため存在します。最悪のケースでランサムウェアが実行ゲートをすり抜け、何らかの形で管理者権限を得て、シャドウコピーとバックアップの削除に成功しても、暗号化プロセスはファイルシステムへの書き込みが必要です。Keeper EPMのACL変更によりOSが書き込みを拒否します。

多層防御の価値はここにあります。各ゲートが攻撃者の作業を難しくし、最後のゲートは他の防御がすべて失敗しても攻撃のペイロードを無力化します。


---

# 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-examples/anti-ransomware-policies/gate-4-data-protection.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.
