> 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-controls.md).

# ポリシーコントロール

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

ポリシーのステータスを**適用**にすると、ポリシーの適用範囲に一致する操作は、続行の前に1つ以上の**コントロール**を満たす必要があります。コントロールは、特権操作に対してユーザーが行うべきこと、またはKeeperが自動で行う内容を定義します。

コントロールはポリシーごとに設定され、対応するすべてのポリシータイプで一貫して適用されます。利用できるコントロールは[ポリシータイプ](/keeperpam/jp/endpoint-privilege-manager/policies/policy-types.md)によって若干異なります。

* [**特権昇格**](/keeperpam/jp/endpoint-privilege-manager/policies/policy-types/privilege-elevation-policy-type.md)および[**ファイルアクセス**](/keeperpam/jp/endpoint-privilege-manager/policies/policy-types/file-access-policy-type.md): すべてのコントロール (自動許可、自動拒否、管理者承認、正当な理由、MFA)
* [**コマンドライン**](/keeperpam/jp/endpoint-privilege-manager/policies/policy-types/command-line-policy-type.md): 管理者承認、正当な理由、MFA
* [**最小特権**](/keeperpam/jp/endpoint-privilege-manager/policies/policy-types/least-privilege-policy-type.md): 自動許可、自動拒否
* 3つのエージェンティックAIガバナンスポリシータイプ ([**エージェンティックAI**](/keeperpam/jp/endpoint-privilege-manager/policies/policy-types/agentic-ai-policy.md)、[**エージェンティックアクセス**](/keeperpam/jp/endpoint-privilege-manager/policies/policy-types/agentic-access-policy.md)、[**エージェンティック特権昇格**](/keeperpam/jp/endpoint-privilege-manager/policies/policy-types/agentic-privilege-elevation-policy.md)): 自動許可、自動拒否、管理者承認、正当な理由、MFA、エンドユーザー承認。1つのポリシーに複数のコントロールを組み合わせ、段階的な検証要件を重ねられます。

{% hint style="info" %}
同一のユーザー、マシン、またはアプリケーションに複数のポリシーが同時に当てはまる場合、該当するすべてのポリシーが評価され、内容が食い違うときは最も厳しい結果が自動で適用されます。
{% endhint %}

## 利用できるコントロール <a href="#available-controls" id="available-controls"></a>

**適用**のステータスでポリシーを新規作成または編集するとき、以下のコントロールを利用できます。

* [管理者承認](#admin-approval)
* [自動許可](#auto-approve)
* [自動拒否](#auto-deny)
* [正当な理由](#justification)
* [MFA](#mfa)
* [エンドユーザー承認](#require-user-approval)

### 管理者承認 <a href="#admin-approval" id="admin-approval"></a>

**内容:** ユーザーの操作は一時停止され、指定した承認チームに回されます。承認者が明示的に許可または拒否するまで、操作はブロックされたままです。

**流れ:**

1. ユーザーが特権操作を行います (例: アプリケーションを管理者として実行する)。
2. Keeperエージェントが要求を横取りし、保留中の通知をユーザーに表示します。
3. 要求はKeeperのバックエンドに送られ、**Keeper管理コンソール → エンドポイント特権マネージャー → リクエスト**のキューに表示されます。
4. 割り当てられた承認者が、要求元ユーザー、マシン、アプリケーション、コマンドライン引数、入力された理由などを含む詳細を確認し、承認または拒否します。
5. 承認されればユーザーに通知され、操作を続行できます。

**主な挙動とタイムアウト:**

| 事象                  | 既定のタイムアウト     |
| ------------------- | ------------- |
| 初回の承認要求の期限切れ        | 30分           |
| 要求が第2承認者へ自動エスカレーション | 30分経過後        |
| エスカレーション後の要求の期限切れ   | エスカレーションから4時間 |
| 承認済み要求の利用可能期間       | 承認から24時間      |

{% hint style="info" %}
タイムアウトの値は、Keeper管理コンソールの**管理者 → 承認**で、事象の種類ごとに変更できます。
{% endhint %}

**承認の設定:** 承認ルール、承認者の割り当て、エスカレーション、時間枠は、個々のポリシーではなく**管理者 → 承認**で一元的に管理されます。Keeper管理者は常に完全な承認権限を持ちます。レビュー履歴は**エンドポイント特権マネージャー → リクエスト**で追跡できます。

**オフライン時:** 承認要求にはネットワーク接続が必要です。オフラインでは承認要求を開始できません。

{% hint style="info" %}
承認には常に理由の入力が必要です。**管理者承認**を選ぶと、**正当な理由**を別に有効にしていなくても、ユーザーには必ず理由の入力が求められます。
{% endhint %}

### 自動許可 <a href="#auto-approve" id="auto-approve"></a>

**内容:** 一致した操作を、追加のユーザー検証なしで明示的に許可します。操作は通知なしで通過します。

**適用の目安:** 全体としては厳しいポリシーのなかで、特定のアプリケーション・コマンド・ファイルパスだけ例外的に緩めたいときに使います。例: 信頼できるITツールへの昇格だけはそのまま許可し、その他の昇格には承認を求める、といったとき。

**主な挙動:**

* 一致した範囲では、既定の拒否より**許可**が優先されます。
* 通知、MFA、理由の入力、承認のいずれのワークフローも起動しません。
* ポリシーのステータスが**監視**または**監視&通知**のときは、イベントは引き続き監査ログに記録されます。
* **自動許可**と**自動拒否**は、それぞれ別のポリシーに同時に設定できます。複数ポリシーが当てはまるときは、最も厳しい適用結果が採用されます。
* **自動許可**は他のコントロールと組み合わせられません。選択するとポリシー上の他のコントロールはすべて無効になり、選択または解除時に確認プロンプトが表示されます。適用範囲を定義するには、最低1つのユーザーまたはマシンコレクションと、1つのアプリケーションまたはエージェンティックAIコレクションが必要です。

### 自動拒否 <a href="#auto-deny" id="auto-deny"></a>

**内容:** 一致した操作を明示的にブロックし、ユーザーに検証の経路を示すことなく、いかなる状況でも続行できないようにします。

**適用の目安:** 特定のアプリケーション・コマンド・ファイルパスに対するハードブロック (既定拒否の一部や、既知のリスクの高い実行ファイルの禁止など) に使います。業務上許可する理由がない操作に適したコントロールです。

**主な挙動:**

* 一致した時点で操作は即終了します。承認、MFA、理由入力のプロンプトは出ません。
* ブロックは監査ログに記録されます。
* 「すべて拒否」のモデルを組むとき、クリティカルなOSコンポーネントを誤って壊さないよう、Keeperの保護パスロジックが自動で適用されます。
* 複数ポリシーが競合するとき、**自動拒否**ポリシーは最も高い優先度で評価されます。
* **自動拒否**は他のコントロールと組み合わせられません。選択するとポリシー上の他のコントロールはすべて無効になり、選択または解除時に確認プロンプトが表示されます。ユーザー向けプロンプトなしで即座に拒否応答を返します。適用範囲を定義するには、最低1つのユーザーまたはマシンコレクションと、1つのアプリケーションまたはエージェンティックAIコレクションが必要です。

### 正当な理由 <a href="#justification" id="justification"></a>

**内容:** 続行の前に、ユーザーは要求した操作の理由を文章で入力する必要があります。

**流れ:**

1. ユーザーが特権操作を行います。
2. Keeperエージェントが理由の入力を求めるプロンプトを表示します。
3. ユーザーが説明を入力して送信します。
4. 操作は許可され、入力内容は監査ログに記録されます。

**主な挙動:**

* **正当な理由**だけを単独で使う場合、承認者のレビューは不要です。ユーザーが理由を送信すると直ちに操作が続行されます。
* 入力内容は監査イベントに紐づけられ、コンプライアンスやレビューに利用できます。
* **オフライン時:** 理由の入力のみが必要で (MFAや管理者承認が不要な) ポリシーでは、オフラインでも実行は許可されます。入力内容は端末にキャッシュされ、エージェントが再接続したあとサーバーに送られます。

### MFA <a href="#mfa" id="mfa"></a>

**内容:** 操作が許可される前に、ユーザーは時刻ベースのワンタイムパスワード (TOTP) で本人であることを証明する必要があります。

**流れ:**

1. ユーザーが特権操作を行います。
2. Keeperエージェントが、登録済みのTOTP認証アプリから有効なMFAコードの入力を求めます。
3. コードは、ユーザーのKeeperボルトのMFA設定と照合されます。
4. コードが有効でセッション時間内であれば操作は続行します。無効または期限切れなら操作はブロックされます。

**主な挙動:**

* テナント内で有効なKeeperボルトのアカウントがあり、TOTP方式の2要素認証が設定されている必要があります。
* アカウントがテナントに属している限り、有効なKeeperのメールと2FAの組み合わせは受理されます。
* MFAのセッションは**5分**間有効です。その間、同種の操作では再度の入力を求めません。
* MFAの検証にはネットワーク接続が必要です。端末がオフラインのとき、MFA必須の操作はブロックされます。

### エンドユーザー承認 <a href="#require-user-approval" id="require-user-approval"></a>

**内容:** エンドポイント上でサインインしているエンドユーザーに、リアルタイムで操作の許可または拒否を求めます。**管理者承認**が別の承認チームに判断を回すのに対し、**エンドユーザー承認**はキーボードの前にいる本人に判断を委ねます。AIエージェントの統制で最もよく使われるヒューマンインザループのゲートであり、AIエージェントがポリシーでフィルターされた操作を試みたときに、ユーザーが確認する必要があります。

**流れ:**

1. **エンドユーザー承認**が設定されたポリシーに一致する監視対象の操作が発生します (例: AIエージェントが機密ファイルへのアクセスや特権コマンドの実行を試みる)。
2. Keeperエージェントが、影響を受けるエンドポイント上のエンドユーザーに承認プロンプトを表示し、操作の詳細を示します。
3. ユーザーが承認または拒否します。承認された場合のみ操作が続行され、拒否された場合はブロックされます。
4. 判断内容は監査ログに記録されます。

**主な挙動:**

* プロンプトには\*\*「今後 N 時間は再確認しない」\*\*オプションがあり、設定した期間、同じ操作範囲に対する繰り返しプロンプトを抑制できます。
* **エンドユーザー承認**は、リスクスコアのしきい値と組み合わせられ、操作のリスクスコアが設定した上限を超えた場合にのみプロンプトが表示されます。
* 判断内容は、応答したエンドユーザーに帰属づけられ、監査ログに記録されます。

***

## コントロールの組み合わせ <a href="#combining-controls" id="combining-controls"></a>

KEPMでは、1つのポリシーに複数のコントロールを組み合わせ、段階的な検証要件を適用できます。コントロールを組み合わせた場合、設定した**すべて**のコントロールを満たして初めて操作が許可されます。ポリシーへの追加順にかかわらず、コントロールは常に固定の順序でユーザーに提示されます。

**自動許可**と**自動拒否**は終端コントロールです。操作を単独で解決し、他のコントロールとは組み合わせられません。残りのコントロール (管理者承認、MFA、正当な理由) は互いに組み合わせられます。**エンドユーザー承認**は独立したエンドユーザー向けゲートであり、管理者側のコントロールとは組み合わせません。

#### 組み合わせ可能なコントロール <a href="#allowed-combinations" id="allowed-combinations"></a>

以下の表は、1つのポリシーで組み合わせられるコントロールを示しています。

| コントロール    | 管理者承認 | MFA | 正当な理由 | 自動許可 | 自動拒否 |
| --------- | ----- | --- | ----- | ---- | ---- |
| **管理者承認** | －     | はい  | はい    | いいえ  | いいえ  |
| **MFA**   | はい    | －   | はい    | いいえ  | いいえ  |
| **正当な理由** | はい    | はい  | －     | いいえ  | いいえ  |
| **自動許可**  | いいえ   | いいえ | いいえ   | －    | いいえ  |
| **自動拒否**  | いいえ   | いいえ | いいえ   | いいえ  | －    |

#### 評価順序 <a href="#order-of-evaluation" id="order-of-evaluation"></a>

1つのポリシーに複数のコントロールを組み合わせた場合、固定の順序で処理されます。各コントロールを順に満たした場合のみ操作が続行され、いずれかが失敗、キャンセル、または拒否された場合は操作がブロックされ、以降のコントロールは提示されません。

<table><thead><tr><th width="89.5333251953125">順序</th><th width="151.933349609375">コントロール</th><th>ユーザーが遭遇する内容</th></tr></thead><tbody><tr><td>1</td><td>自動拒否</td><td>設定されている場合、操作は即座にブロックされ、以降のコントロールは評価されません。</td></tr><tr><td>2</td><td>管理者承認</td><td>要求は承認者に回され、許可されるまで保留状態のままです。</td></tr><tr><td>3</td><td>MFA</td><td>TOTP検証の完了を求められます。</td></tr><tr><td>4</td><td>正当な理由</td><td>理由の入力を求められ、監査ログに記録されます。</td></tr><tr><td>5</td><td>自動許可</td><td>設定されている場合、追加のプロンプトなしで操作が許可されます。</td></tr></tbody></table>

{% hint style="info" %}
コントロールの優先順位 (高から低) は `DENY` → `APPROVAL` → `MFA` → `JUSTIFY` → `ALLOW` です。単一の操作に競合するコントロールが適用される場合も、同じ順序で結果が決まります。
{% endhint %}

#### ポリシーの具体性と優先順位 <a href="#policy-specificity-and-precedence" id="policy-specificity-and-precedence"></a>

すべてのKEPMポリシータイプで、具体性とワイルドカードの優先順位ルールが適用されます。複数のポリシーが要求に一致する場合、エンジンは**具体的**なポリシーと**ワイルドカード**ポリシーに分け、より対象を絞ったグループだけを評価します。

`UserCheck`、`ApplicationCheck`、`MachineCheck` のいずれかにワイルドカード以外の値 ( `"*"` ではなく、名前付きユーザー、アプリケーション、マシンを指定) が含まれるポリシーは**具体的**とみなされます。3つのフィルターすべてが `"*"` または空の場合、そのポリシーは**ワイルドカード**とみなされます。

優先順位ルールは以下のとおりです。

* 具体的なポリシーが要求に一致する場合、**具体的**なポリシーのみが評価され、すべてのワイルドカードポリシーはその要求では無視されます。
* 具体的なポリシーが一致しない場合、ワイルドカードポリシーが評価されます。
* 複数の具体的なポリシーが同じ要求に一致する場合、コントロールは加算的に組み合わされ、上記の固定順序で評価されます。

{% hint style="warning" %}
具体性は `AllowCommands` の有無ではなく、`UserCheck`、`ApplicationCheck`、`MachineCheck` によって決まります。`AllowCommands` があっても `ApplicationCheck: ["*"]` のポリシーはワイルドカードとして扱われ、別のワイルドカードポリシーより自動的に優先されません。具体的なポリシーの優先順位を得るには、`ApplicationCheck` (または `UserCheck` / `MachineCheck`) が `"*"` ではなく、名前付きのアプリケーションまたはコレクションを対象にしていることを確認してください。
{% endhint %}

### コントロール早見表 <a href="#control-reference-summary" id="control-reference-summary"></a>

<table><thead><tr><th width="134.06671142578125">コントロール</th><th width="171.6666259765625">ネットワーク必須</th><th width="141.13330078125">Keeperボルトのアカウント必須</th><th width="144">操作を即時ブロック</th><th>承認者が必要</th></tr></thead><tbody><tr><td>管理者承認</td><td>はい</td><td>いいえ</td><td>いいえ (決まるまで保留)</td><td>はい</td></tr><tr><td>自動許可</td><td>いいえ</td><td>いいえ</td><td>いいえ (操作を許可)</td><td>いいえ</td></tr><tr><td>自動拒否</td><td>いいえ</td><td>いいえ</td><td>はい</td><td>いいえ</td></tr><tr><td>正当な理由</td><td>いいえ (オフラインキャッシュ)</td><td>いいえ</td><td>いいえ</td><td>いいえ</td></tr><tr><td>MFA</td><td>はい</td><td>はい (TOTP設定済み)</td><td>いいえ (オフライン時はブロック)</td><td>いいえ</td></tr><tr><td>エンドユーザー承認</td><td>状況による</td><td>いいえ</td><td>いいえ (決まるまで保留)</td><td>いいえ (エンドユーザーが判断)</td></tr></tbody></table>

### オフライン時の挙動まとめ <a href="#offline-behavior-summary" id="offline-behavior-summary"></a>

ポリシーはエンドポイントへ配布され、端末上でローカルに評価されます。オフライン時の挙動は以下のとおりです。

* **管理者承認が必要:** 承認要求を開始できません。操作はブロックされます。
* **MFAが必要:** MFAの検証が完了できません。操作はブロックされます。
* **正当な理由のみ:** 操作は許可されます。入力内容はキャッシュされ、エージェントが再接続したあとサーバーに送られます。
* **エンドユーザー承認が必要:** エンドポイント上でプロンプトを表示できるか、判断をローカルにキャッシュできるかによって、オフライン時の挙動が異なります。
* **自動許可 / 自動拒否:** ネットワーク依存なしでローカル評価されます。
* **監査イベント:** ローカルにキャッシュされ、エージェントがオンラインに戻ったあとサーバーに送られます。


---

# 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-controls.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.