ポリシーコントロール

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

コントロールはポリシーごとに設定され、対応するすべてのポリシータイプで一貫して適用されます。利用できるコントロールはポリシータイプによって若干異なります。

• 特権昇格およびファイルアクセス: すべてのコントロール (自動許可、自動拒否、管理者承認、正当な理由、MFA)
• コマンドライン: 管理者承認、正当な理由、MFA
• 最小特権: 自動許可、自動拒否
• 3つのエージェント型AIガバナンスポリシータイプ (エージェント型AI、エージェント型アクセス、エージェント型特権昇格): 自動許可、自動拒否、管理者承認、正当な理由、MFA、エンドユーザー承認。1つのポリシーに複数のコントロールを組み合わせ、段階的な検証要件を重ねられます。

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

利用できるコントロール

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

• 管理者承認
• 自動許可
• 自動拒否
• 正当な理由
• MFA
• エンドユーザー承認

管理者承認

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

流れ:

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

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

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

タイムアウトの値は、Keeper管理コンソールの管理者 → 承認で、事象の種類ごとに変更できます。

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

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

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

自動許可

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

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

主な挙動:

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

自動拒否

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

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

主な挙動:

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

正当な理由

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

流れ:

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エージェントの統制で最もよく使われるヒューマンインザループのゲートであり、AIエージェントがポリシーでフィルターされた操作を試みたときに、ユーザーが確認する必要があります。

流れ:

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

主な挙動:

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

---

コントロールの組み合わせ

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

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

組み合わせ可能なコントロール

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

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

評価順序

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

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

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

ポリシーの具体性と優先順位

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

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

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

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

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

コントロール早見表

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

オフライン時の挙動まとめ

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

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