{% stepper %}
{% step %}
### **レイヤー1: 最小権限 (基盤)**
標準ユーザーが既定でエンドポイント上のローカル管理者権限を持たないよう、[最小権限ポリシー](/keeperpam/jp/endpoint-privilege-manager/policies/policy-types/least-privilege-policy-type.md)を作成します。**上位のすべてのレイヤーは、このベースラインを前提とします。**
* 持つべきでないユーザーから常設のローカル管理者を取り除き、昇格は既存権限の静かな行使ではなく、特権昇格ポリシーを通じて**リクエスト**されるようにします。
* 起動や昇格イベントの評価より前に効き、実行してよい内容ではなく、**ユーザーが最初に持つ権限**を形作ります。
* この基盤がないと、レイヤー1〜4は起動と昇格リクエストをゲートしても、すでにローカル管理者を持つユーザーは、標準ユーザー文脈を前提とする多くのコントロール (レジストリ書き込み、サービスインストール、ドライバー読み込みなど) を迂回できます。
* 権限削除後も承認済みの管理作業に経路が残るよう、[**特権昇格**](/keeperpam/jp/endpoint-privilege-manager/policies/policy-types/privilege-elevation-policy-type.md) (昇格イベント上のレイヤー1、2、3) と組み合わせます。
* 作成の指針は[最小権限ポリシー](/keeperpam/jp/endpoint-privilege-manager/policies/policy-types/least-privilege-policy-type.md)をご参照ください。
{% endstep %}
{% step %}
### レイヤー2: 既知の場所 (承認)
通常のインストールパス上の高リスクツール (例: `{system32}\cmd.exe`、System32配下のPowerShell) に対し、[**承認**を要求します (任意でMFAまたは正当な理由を併用)](/keeperpam/jp/endpoint-privilege-manager/policies/policy-controls.md)。
* [**ファイルアクセス**](/keeperpam/jp/endpoint-privilege-manager/policies/policy-types/file-access-policy-type.md)で使い、レビューなしの昇格を許さない場合は[**特権昇格**](/keeperpam/jp/endpoint-privilege-manager/policies/policy-types/privilege-elevation-policy-type.md)でも使います。
* 実パスの安易な利用をゲートしつつ、承認後の正当な利用は残します。
* 単独では、別フォルダから起動したコピーを**止められません**。
{% endstep %}
{% step %}
### レイヤー3: 広い姿勢 (すべてのアプリケーション)
受け皿として**すべてのアプリケーション** (`*`) 向けの**承認**ポリシーを作成し、チケット不要とすべき業務承認済みアプリ (および信頼できる発行元) を**許可**します。
* レイヤーAを外れる再配置、名前変更、予期しない起動または昇格対象を捉えます。
* 未知のソフトウェアをレビュー可能にしたい場合は承認を優先し、承認経路なしで拒否すべき場合にのみハードな拒否を使います。
* 昇格を既定でゲートしたい場合は、**特権昇格**でも同じ考え方を適用します。
{% endstep %}
{% step %}
### レイヤー4: 既知の不正コンテンツ (ハッシュ拒否)
**どこに現れても**止めなければならない特定の不正バイナリには、**ハッシュのみ**の拒否 (パスを結び付けないSHA256) を使います。
* **内容**に一致するため、名前変更や再配置でも拒否されます。
* パス＋ハッシュのメンバーは**両方**の一致が必要であり、グローバルなコンテンツブロックではありません。「このバイト列をどこでもブロック」にはハッシュのみを優先します。
* [**ファイルアクセス**](/keeperpam/jp/endpoint-privilege-manager/policies/policy-types/file-access-policy-type.md)と[**特権昇格**](/keeperpam/jp/endpoint-privilege-manager/policies/policy-types/privilege-elevation-policy-type.md)に適用できます。エージェント経路では、ベースラインの拒否がそのバイナリのエージェント駆動の利用もブロックします。
{% endstep %}
{% step %}
### レイヤー5: 信頼できる発行元 (証明書による許可)
信頼するベンダーや製品向けの**許可**ポリシーで、**発行元証明書**を使います。
* 署名済みソフトウェアの許可リストに適しています。
* レイヤーBと組み合わせ、それ以外には引き続き承認を要求する (または拒否する) ようにします。
{% endstep %}
{% step %}
### レイヤー6: AI固有のコントロール
AIワークフロー向けにエージェント型ポリシーを追加します。ベースラインのレイヤーをこれだけで置き換えないでください。
* [**エージェント型AI**](/keeperpam/jp/endpoint-privilege-manager/policies/policy-types/agentic-ai-policy.md): 誰がAIアプリケーションを起動でき、どのようなコントロールか。
* [**エージェント型AIアクセス**](/keeperpam/jp/endpoint-privilege-manager/policies/policy-types/agentic-access-policy.md): それらのエージェントが生成してよいもの (シェル、パッケージマネージャー、ブラウザーなど)。エージェント＋子 (サブプロセス) のスコープによる。
* [**エージェント型AI特権昇格**](/keeperpam/jp/endpoint-privilege-manager/policies/policy-types/agentic-privilege-elevation-policy.md): AIに帰属するプロセスが昇格してよいもの。
ユーザーやエージェントがコピーしたツールの起動や昇格でベースラインの拒否を迂回できないよう、レイヤー1〜4はそのまま残します。エージェント型ポリシーはAI固有のゲートを追加するものであり、広いファイルアクセスと特権昇格の姿勢の必要性をなくすものではありません。
{% endstep %}
{% endstepper %}
## レイヤーの連携
* ユーザーがSystem32のPowerShellを実行 → レイヤーAのファイルアクセス承認が適用され得る。
* ユーザーがプロファイル配下のコピーを実行 → レイヤーAは一致せず、レイヤーBが引き続き承認を要求する (または拒否する)。
* 既知不正のハッシュ → バイト列が現れる場所での起動または昇格で、レイヤーCが拒否する。
* 信頼できるベンダーのアプリ → レイヤーDが許可し、未知のソフトウェアはレイヤーBでゲートされたまま。
* AIエージェントが `cmd.exe` の生成を試行 → エージェント型アクセスがオペレーター承認を要求する場合あり。その子プロセスに対するベースラインのファイルアクセス**拒否**があれば、なおブロックする。
* AIエージェントがツールの昇格を試行 → エージェント型特権昇格が適用され、ベースラインの特権昇格**拒否**がなお勝つ。
## ポリシーが競合する場合
ポリシータイプをまたぎ、同じ評価集合で複数の**適用**ポリシーが一致する場合:
1. **より具体的なものが広いものに勝つ:** 「すべてのユーザー」よりユーザーまたはグループ固有、「すべてのアプリケーション」よりアプリケーション固有 (証明書、コマンド、サブプロセス一覧でも同様の具体性)。
2. **その集合内では、コントロールの順位は:** **拒否 → 承認 → MFA / 正当な理由 / オペレーター承認 → 許可**。
承認済みアプリ向けの特定許可は、そのアプリについてすべてのアプリケーション向け承認に勝てます。未知のパスは広いレイヤーに当たります。勝った集合内の拒否は、その操作をブロックします。
{% hint style="warning" %}
拒否は、勝った集合内で最優先のコントロールです。具体性はスコープ**間** (特定とワイルドカード) の競合解決に使い、すでに拒否を含む集合内では使いません。
{% endhint %}
## AI経路の権限上限
AIに帰属する起動と昇格では:
* **ベースラインの拒否** (ファイルアクセスまたは特権昇格) は、より緩いエージェント型AI、エージェント型アクセス、エージェント型特権昇格の結果に**常に勝ちます**。
* AIエージェントは、同じリソースについてユーザーのベースラインポリシーが拒否する場所で許可を得られません。
* エージェント経路上のベースラインのMFAと正当な理由は、エージェント型のルール (拒否中心の例外) の下で扱われ、AI固有の承認とオペレーターフローはエージェント型ポリシーが担います。
**設計上の含意:** エージェント型アクセスポリシーに大きく投資する場合でも、強いベースラインの拒否と承認のレイヤーを維持します。
## 結果
* **許可:** 操作は続行します。
* **承認 / MFA / 正当な理由 / オペレーター承認:** コントロールが成功するまで操作を待機します。
* **拒否:** 操作はブロックされます。
* **一致する適用ポリシーなし:** そのポリシーファミリは介在しません。そのイベントにはOSのデフォルトが適用されます。他のポリシータイプは引き続き適用される場合があります。
Keeper EPM自体は暗黙のデフォルト拒否ではありません。未知のソフトウェアや昇格をゲートまたは拒否するには、すべてのアプリケーション向けの承認または拒否ポリシー (レイヤーB) を作成し、信頼するものを許可します。
## 設計チェックリスト
* [**ファイルアクセス**](/keeperpam/jp/endpoint-privilege-manager/policies/policy-types/file-access-policy-type.md): 実行制御向けレイヤーA〜D (パス承認、広い承認、ハッシュのみの拒否、証明書による許可)。
* [**特権昇格**](/keeperpam/jp/endpoint-privilege-manager/policies/policy-types/privilege-elevation-policy-type.md): 昇格イベント向けに同じレイヤー型の考え方。
* [**エージェント型AI**](/keeperpam/jp/endpoint-privilege-manager/policies/policy-types/agentic-ai-policy.md)**、**[**エージェント型AIアクセス**](/keeperpam/jp/endpoint-privilege-manager/policies/policy-types/agentic-access-policy.md)**、および**[**エージェント型AI特権昇格**](/keeperpam/jp/endpoint-privilege-manager/policies/policy-types/agentic-privilege-elevation-policy.md): AIの起動、生成、昇格向けの明示的なポリシー。
* **ベースラインのカバー:** ユーザーとエージェントが実行してはならないツールを、ベースラインの拒否がなおカバーしていること。
* **コンテンツ識別:** 「このバイナリをどこでもブロック」にはハッシュのみのメンバーを優先。
* **検証:** 実インストールパス、再配置コピー、 (該当する場合) エージェントが生成した子プロセスをテスト。
## 関連資料
* [ファイルアクセスポリシー評価ガイド](/keeperpam/jp/endpoint-privilege-manager/policies/policy-reference/policy-evaluation/file-access-policy-evaluation-guide.md): ファイルアクセスの一致、ハッシュのみとパス＋ハッシュ、競合例の詳細。
* [ポリシータイプ](/keeperpam/jp/endpoint-privilege-manager/policies/policy-types.md): 適用対象の各タイプとコントロールの概要。
* [ポリシーコントロール](/keeperpam/jp/endpoint-privilege-manager/policies/policy-controls.md): 許可、拒否、MFA、正当な理由、承認、およびオペレーター承認。
* [ポリシーステータス](/keeperpam/jp/endpoint-privilege-manager/policies/policy-status.md): 適用、監視、無効の各モード。
* [パス変数と保護パス](/keeperpam/jp/endpoint-privilege-manager/policies/policy-reference/path-variables.md)および[ワイルドカード](/keeperpam/jp/endpoint-privilege-manager/policies/policy-reference/wildcards.md): アプリケーションスコープの共通構成要素。
---
# 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.md?ask=&goal=
```
`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.
.png?alt=media)
.png?alt=media)