> 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). # ポリシーのコントロール
ポリシーのステータスを**適用**にすると、ポリシーの適用範囲に一致する操作は、続行の前に1つ以上の**コントロール**を満たす必要があります。コントロールは、特権操作に対してユーザーが行うべきこと、またはKeeperが自動で行うことを定義します。 コントロールはポリシーごとに設定され、対応するすべてのポリシータイプ (エージェンティックAIアクセス、エージェンティックアクセス、エージェンティック特権昇格、コマンドライン、ファイルアクセス、最小権限、特権昇格) で一貫して適用されます。1つのポリシーに複数のコントロールを組み合わせ、段階的な検証を重ねた要件にもできます。 {% hint style="info" %} **競合時の扱い:** 同一のユーザー、マシン、またはアプリケーションに複数のポリシーが同時に当てはまる場合、Keeperは該当するすべてのポリシーを評価し、内容が食い違うときは最も厳しい結果を自動で適用します。 {% endhint %} ## 利用できるコントロール **適用**のステータスでポリシーを新規作成または編集するとき、画面から以下のコントロールを選べます。
## 承認が必要 **内容:** ユーザーの操作は一時停止され、指定した承認チームに回されます。承認者が明示的に許可または拒否するまで、操作はブロックされたままです。 **流れ:** 1. ユーザーが特権操作を行います (例: アプリケーションを管理者として実行する)。 2. Keeperエージェントが要求を横取りし、保留中の通知をユーザーに表示します。 3. 要求はKeeperのバックエンドに送られ、**Keeper管理コンソール → エンドポイント特権マネージャー → リクエスト**のキューに表示されます。 4. 割り当てられた承認者が、要求元ユーザー、マシン、アプリケーション、コマンドライン引数、入力された正当化などを含む詳細を確認し、承認または拒否します。 5. 承認されればユーザーに通知され、操作を続行できます。 **主な挙動とタイムアウト:** | 事象 | 既定のタイムアウト | | ------------------- | ------------- | | 初回の承認要求の期限切れ | 30分 | | 要求が第2承認者へ自動エスカレーション | 30分経過後 | | エスカレーション後の要求の期限切れ | エスカレーションから4時間 | | 承認済み要求の利用可能期間 | 承認から24時間 | {% hint style="info" %} タイムアウトの値は、Keeper管理コンソールの**管理者 → 承認**で、事象の種類ごとに変更できます。 {% endhint %} **承認の設定:** 承認ルール、承認者の割り当て、エスカレーション、時間枠は、個々のポリシーではなく**管理者 → 承認**で一元的に管理されます。Keeper管理者は常に完全な承認権限を持ちます。レビュー履歴は**エンドポイント特権マネージャー → リクエスト**で追跡できます。 **オフライン時:** 承認要求にはネットワーク接続が必要です。オフラインでは承認要求を開始できません。 {% hint style="info" %} 承認には常に正当化が必要です。**承認が必要**を選ぶと、**正当な理由が必要**を別に有効にしていなくても、ユーザーには必ず理由の入力が求められます。 {% endhint %} #### 許可 (高度) **内容:** 一致した操作を、追加のユーザー検証なしで明示的に許可します。操作は通知なしで通過します。 **適用の目安:** 全体としては厳しいポリシーのなかで、特定のアプリケーション・コマンド・ファイルパスだけ例外的に緩めたいときに使います。例: 信頼できるITツールへの昇格だけはそのまま許可し、その他の昇格には承認を求める、といったとき。 **主な挙動:** * 一致した範囲では、既定の拒否より**許可**が優先されます。 * 通知、MFA、正当化、承認のいずれのワークフローも起動しません。 * ポリシーのステータスが**監視**または**監視&通知**のときは、イベントは引き続き監査ログに記録されます。 * **許可**と**拒否**は、それぞれ別のポリシーに同時に設定し得ます。複数ポリシーが当てはまるときは、Keeperは最も厳しい適用結果を採用します。 **JSON表現:** ```json "Controls": ["ALLOW"] ``` #### 拒否 (高度) **内容:** 一致した操作を明示的にブロックし、ユーザーに検証の経路を示すことなく、いかなる状況でも続行できないようにします。 **適用の目安:** 特定のアプリケーション・コマンド・ファイルパスに対するハードブロック (既定拒否の一部や、既知のリスクの高い実行ファイルの禁止など) に使います。業務上許可する理由がない操作に適したコントロールです。 **主な挙動:** * 一致した時点で操作は即終了します。承認、MFA、正当化のプロンプトは出ません。 * ブロックは監査ログに記録されます。 * 「すべて拒否」のモデルを組むとき、クリティカルなOSコンポーネントを誤って壊さないよう、Keeperの保護パスロジックが自動で適用されます。 * 複数ポリシーが競合するとき、**拒否**ポリシーは最も高い優先度で評価されます。 **JSON表現:** ```json "Controls": ["DENY"] ``` ### エンドユーザー承認 **内容:** 操作を一時停止し、影響を受けるエンドポイント上の**エンドユーザー**に、リアルタイムで許可または拒否の判断を求めます。ヒューマンインザループによる確認です。**エージェンティックAI**の統制における主要なコントロールであり、AIエージェントがポリシーの適用範囲内で操作を試みたとき、当該マシンにいるユーザーが明示的に承認または拒否するまで操作は保留されます。 **流れ:** 1. ポリシーの適用範囲内で操作が試みられます。多くの場合、検出されたAIエージェントがユーザーに代わって行います。 2. Keeperエージェントが操作を保留し、何が要求されているか、どのエージェントからか、どのリソースに対してかを説明する承認/拒否プロンプトをユーザーに表示します。 3. ユーザーが承認すれば操作は続行し、拒否すれば操作はブロックされます。 4. 判断内容、要求元のID、リソースは監査ログに記録されます。 **主な挙動:** * このコントロールは、Keeper管理コンソールの指定承認チームに回す**承認が必要**とは異なり、**エンドポイント上のエンドユーザー**に判断を委ねます。 * エージェンティックポリシーに付与すると、基盤となるコントロール値は `OPERATORAPPROVAL` です。 * **タイムアウト**時は、設定されたフェイルモードが適用されます。 {% hint style="info" %} エンドユーザー承認は通常、リスクしきい値 (下記の**リスク連動型コントロール**を参照) と組み合わせます。エージェントの操作が設定したAI可能性またはリスクレベルを超えたときだけプロンプトが表示され、日常的で低リスクなエージェント操作はユーザーを中断しません。 {% endhint %} ### 正当な理由が必要 **内容:** 続行の前に、ユーザーは要求した操作の理由を文章で入力する必要があります。 **流れ:** 1. ユーザーが特権操作を行います。 2. Keeperエージェントが正当化メッセージの入力を求めるプロンプトを表示します。 3. ユーザーが説明を入力して送信します。 4. 操作は許可され、正当化の文言は監査ログに記録されます。 **主な挙動:** * **正当な理由が必要**だけを単独で使う場合、承認者のレビューは不要です。ユーザーが正当化を送信すると直ちに操作が続行されます。 * 正当化の文言は監査イベントに紐づけられ、コンプライアンスやレビューに利用できます。 * **オフライン時:** 正当化のみが必要で (MFAや承認が不要な) ポリシーでは、オフラインでも実行は許可されます。正当化は端末にキャッシュされ、エージェントが再接続したあとサーバーに送られます。 ### MFA必須 **内容:** 操作が許可される前に、ユーザーは時刻ベースのワンタイムパスワード (TOTP) で本人であることを証明する必要があります。 **流れ:** 1. ユーザーが特権操作を行います。 2. Keeperエージェントが、登録済みのTOTP認証アプリから有効なMFAコードの入力を求めます。 3. コードは、ユーザーのKeeperボルトのMFA設定と照合されます。 4. コードが有効でセッション時間内であれば操作は続行します。無効または期限切れなら操作はブロックされます。 **主な挙動:** * テナント内で有効なKeeperボルトのアカウントがあり、TOTP方式の2要素認証が設定されている必要があります。 * アカウントがテナントに属している限り、有効なKeeperのメールと2FAの組み合わせは受理されます。 * MFAのセッションは**5分**間有効です。その間、同種の操作では再度の入力を求めません。 * MFAの検証にはネットワーク接続が必要です。端末がオフラインのとき、MFA必須の操作はブロックされます。 ### リスク連動型コントロール (エージェンティックAI) エージェンティックポリシーでは、一致する操作のたびにコントロールを適用するのではなく、**リスクしきい値**を超えたときだけコントロールを適用できます。適用範囲内のすべてのエージェント操作に即座に作用するのではなく、操作を評価し、設定したしきい値を超えた場合にのみポリシーのコントロールが有効になります。 * **`minAiLikelihoodPercent`**: ポリシーの `Extension` オブジェクトに設定する、プロセスがAIエージェントである確信度 (0〜100) の最小値。この値に達するまでポリシーは適用されません。 しきい値を超えると、ポリシーで設定した応答が実行されます。例として、**エンドユーザー承認**プロンプト、**承認が必要**、または拒否があります。 **JSON表現 (監視モードのエージェンティックアクセスポリシー、AI可能性 ≥ 90%):** ```json "Status": "monitor", "Actions": { "OnSuccess": { "Controls": ["ALLOW"] }, "OnFailure": { "Command": "" } }, "Extension": { "SubProcessCheck": ["*"], "minAiLikelihoodPercent": 90 } ``` `SubProcessCheck` はポリシーの適用範囲をエージェントが生成したサブプロセスに限定します (`"*"` はすべてに一致)。 ### コントロールの組み合わせ KEPMでは、1つのポリシーに複数のコントロールを組み合わせ、段階的な検証要件を適用できます。コントロールを組み合わせた場合、設定した**すべて**のコントロールを満たして初めて操作が許可されます。いずれか1つでも拒否、失敗、またはタイムアウトすると操作はブロックされます。 重ね合わせにより、1つのポリシーで操作のリスクに合わせた調整が可能です。日常的なセルフサービス操作には正当な理由の入力だけで足りる一方、エンドポイント群全体にわたる無制限の昇格のような高リスク操作には、人的な確認と本人確認を組み合わせて**承認が必要**とMFA必須を重ねられます。検証ステップを生むコントロールは任意に組み合わせられます。結果を単独で決定するコントロール (許可 (高度) と拒否 (高度)) は組み合わせできません。 **評価順序:** 複数のコントロールを設定した場合、KEPMはポリシーへの追加順ではなく、優先順位 (下記のコントロール優先順位を参照) に従ってユーザーに提示します。例: **承認が必要**とMFA必須を組み合わせた場合、先に承認キューに回され、承認されたあとにMFAの入力が求められます。MFA必須と**正当な理由が必要**を組み合わせた場合、MFAの完了後に正当化プロンプトが表示されます。 **ネットワークとタイムアウトの挙動:** 組み合わせたポリシーは、含まれるコントロールのうち最も厳しい要件を引き継ぎます。いずれかのコントロールがネットワーク接続を必要とする場合 (**承認が必要**、**エンドユーザー承認**、MFA必須)、操作はオフラインでは続行できません。同様に、重ねたすべてのコントロールのタイムアウト窓に操作が拘束されます。例: 承認ワークフローにMFA必須を加えると、承認者が許可したあとにユーザーがMFAを完了する必要があるため、全体のやり取り時間が延びます。 **摩擦への配慮:** コントロールを重ねるほど保証は高まりますが、ユーザーの負担も増え、承認ベースの層では承認キューの件数も増えます。重ねたポリシーを広い範囲 (例: すべてのエンドポイントのすべての昇格) に適用する場合は、アプリケーション、ユーザーコレクション、マシンコレクション、時間帯などで適用範囲を絞り、検証がリスクに見合うようにしてください。 **JSON表現:** コントロールは `Controls` 配列に各トークンを列挙して組み合わせます。配列の順序は評価順序に影響しません。優先順位は自動で適用されます。 ```json "Controls": ["APPROVAL", "MFA"] ``` コマンドラインポリシーは、KEPMのほかのポリシータイプと同じ、具体対ワイルドカードの優先順位規則に従います。複数のポリシーが要求に一致するとき、エンジンはそれらを**具体**ポリシーと**ワイルドカード**ポリシーに分け、より絞り込まれたグループだけを評価します。 `UserCheck`、`ApplicationCheck`、`MachineCheck` のいずれかにワイルドカード以外の値が1つ以上あるポリシーは**具体**ポリシーです (名前付きのユーザー、名前付きのアプリケーション、名前付きのマシンを対象とし、`"*"` だけではない場合)。3つすべてが `"*"` であるか空である場合は**ワイルドカード**ポリシーです。 **優先規則は以下のとおりです。** * 一致する具体ポリシーが1つでもあれば、**その具体ポリシーのみ**を評価し、同一の要求に対してワイルドカードポリシーは無視されます。 * 具体ポリシーが1つも一致しなければ、ワイルドカードポリシーを評価します。 このため、特定アプリケーション向けの具体的な**許可**ポリシーは、すべてのコマンドに **MFA** を課すワイルドカードポリシーがあっても効きます。具体ポリシーが優先し、ワイルドカードは脇に置かれるためです。 同様に、同一の要求に2つの具体ポリシーが両方あてはまり、一方が**正当化**、他方が**許可**を課す場合、**正当化**が求められます。衝突する具体ポリシーどうしは積み上げで組み合わされ、正当化は許可より優先します。 **コントロールの優先順位 (高い順):** `DENY` → `APPROVAL` → `MFA` → `JUSTIFY` → `ALLOW` **例** ***ポリシーA:** ワイルドカード。すべての昇格コマンドに MFA を課す* ```json { "ApplicationCheck": ["*"], "UserCheck": ["*"], "Extension": { "IsElevated": true }, "Actions": { "OnSuccess": { "Controls": ["MFA"] } } } ``` ***ポリシーB:** 具体。パスワード変更だけコントロールなしで許可* ```json { "ApplicationCheck": ["sudo", "/usr/bin/sudo"], "UserCheck": ["*"], "Extension": { "IsElevated": true, "AllowCommands": ["/usr/bin/passwd"] }, "Actions": { "OnSuccess": { "Controls": ["ALLOW"] } } } ``` ユーザーが `sudo passwd testuser` を実行すると、ポリシーBは `ApplicationCheck` が `sudo` を明示しているため具体ポリシーであり、ポリシーAはワイルドカードです。エンジンはポリシーBだけを評価し、MFA なしでコマンドが許可されます。 {% hint style="info" %} **重要:** 具体性は `AllowCommands` の有無ではなく、`UserCheck`、`ApplicationCheck`、`MachineCheck` で決まります。`AllowCommands` があっても `ApplicationCheck: ["*"]` のままならワイルドカード扱いのままであり、別のワイルドカードポリシーに対して自動的に優先は付きません。具体ポリシーの優先を得るには、`ApplicationCheck` (または `UserCheck` / `MachineCheck`) を `"*"` ではない名前付きのアプリケーションやコレクションに向けてください。 {% endhint %} ## コントロール早見表 | コントロール | ネットワーク必須 | Keeperボルトのアカウント必須 | 操作を即時ブロック | 承認者が必要 | | --------- | ---------------- | ----------------- | ----------------- | ---------------- | | 承認が必要 | はい | いいえ | いいえ (決まるまで保留) | はい | | エンドユーザー承認 | はい | いいえ | いいえ (決まるまで保留) | いいえ (エンドユーザーが判断) | | MFA必須 | はい | はい (TOTP設定済み) | いいえ (オフライン時はブロック) | いいえ | | 正当な理由が必要 | いいえ (オフラインキャッシュ) | いいえ | いいえ | いいえ | | 許可 (高度) | いいえ | いいえ | いいえ (操作を許可) | いいえ | | 拒否 (高度) | いいえ | いいえ | はい | いいえ | ## オフライン時の挙動まとめ ポリシーはエンドポイントへ配布され、端末上でローカルに評価されます。オフライン時の挙動は以下のとおりです。 * **承認が必要:** 承認要求を開始できません。操作はブロックされます。 * **許可 (高度) / 拒否 (高度):** ネットワーク依存なしでローカル評価されます。 * **エンドユーザー承認:** エンドポイント上のエンドユーザーが応答する必要があります。プロンプトを表示できない場合、またはタイムアウトした場合は、設定されたフェイルモードが適用されます。 * **正当な理由が必要:** 操作は許可されます。正当化はキャッシュされ、エージェントが再接続したあとサーバーに送られます。 * **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: ``` GET https://docs.keeper.io/keeperpam/jp/endpoint-privilege-manager/policies/policy-controls.md?ask= ``` 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.