# ポリシーのコントロール
ポリシーのステータスを**適用**にすると、ポリシーの適用範囲に一致する操作は、続行の前に1つ以上の**コントロール**を満たす必要があります。コントロールは、特権操作に対してユーザーが行うべきこと、またはKeeperが自動で行うことを定義します。 コントロールはポリシーごとに設定され、対応するすべてのポリシータイプ (特権昇格、ファイルアクセス、コマンドライン、最小権限) で一貫して適用されます。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 %} *** ### MFA必須 **内容** 操作が許可される前に、ユーザーは時刻ベースのワンタイムパスワード (TOTP) で本人であることを証明する必要があります。 **流れ** 1. ユーザーが特権操作を行います。 2. Keeperエージェントが、登録済みのTOTP認証アプリから有効なMFAコードの入力を求めます。 3. コードは、ユーザーのKeeperボルトのMFA設定と照合されます。 4. コードが有効でセッション時間内であれば操作は続行します。無効または期限切れなら操作はブロックされます。 **主な挙動** * テナント内で有効なKeeperボルトのアカウントがあり、TOTP方式の2要素認証が設定されている必要があります。 * アカウントがテナントに属している限り、有効なKeeperのメールと2FAの組み合わせは受理されます。 * MFAのセッションは**5分**間有効です。その間、同種の操作では再度の入力を求めません。 * MFAの検証にはネットワーク接続が必要です。端末がオフラインのとき、**MFA必須**のコントロールが設定された操作はブロックされます。 *** ### 正当な理由が必要 **内容** 続行の前に、ユーザーは要求した操作の理由を文章で入力する必要があります。 **流れ** 1. ユーザーが特権操作を行います。 2. Keeperエージェントが正当化メッセージの入力を求めるプロンプトを表示します。 3. ユーザーが説明を入力して送信します。 4. 操作は許可され、正当化の文言は監査ログに記録されます。 **主な挙動** * **正当な理由が必要**だけを単独で使う場合、承認者のレビューは不要です。ユーザーが正当化を送信すると直ちに操作が続行されます。 * 正当化の文言は監査イベントに紐づけられ、コンプライアンスやレビューに利用できます。 * **オフライン時**は正当化のみが必要で (MFAや承認が不要な) ポリシーでは、オフラインでも実行は許可されます。正当化は端末にキャッシュされ、エージェントが再接続したあとサーバーに送られます。 *** ## 高度なコントロール 次のコントロールは、JSONポリシーエディターの**Advanced Mode**から利用できます。特定のアプリケーション、コマンド、またはファイルパスにスコープした明示的な許可/拒否を指定できます。 *** ### 許可 (高度) **内容** 一致した操作を、追加のユーザー検証なしで明示的に許可します。操作は通知なしで通過します。 **適用の目安** 全体としては厳しいポリシーのなかで、特定のアプリケーション・コマンド・ファイルパスだけ例外的に緩めたいときに使います。例: 信頼できるITツールへの昇格だけはそのまま許可し、その他の昇格には承認を求める、といったとき。 **主な挙動** * 一致した範囲では、既定の拒否より**許可**が優先されます。 * 通知、MFA、正当化、承認のいずれのワークフローも起動しません。 * ポリシーのステータスが**監視**または**監視&通知**のときは、イベントは引き続き監査ログに記録されます。 * **許可**と**拒否**は、それぞれ別のポリシーに同時に設定し得ます。複数ポリシーが当てはまるときは、Keeperは最も厳しい適用結果を採用します。
*** ### 拒否 (高度) **内容** 一致した操作を明示的にブロックします。承認やMFA、正当化などの検証手順は表示されません。 **適用の目安** 特定のアプリケーション・コマンド・ファイルパスに対するハードブロック (既定拒否の一部や、既知のリスクの高い実行ファイルの禁止など) に使います。業務上許可する理由がない操作に適したコントロールです。 **主な挙動** * 一致した時点で操作は即終了します。承認、MFA、正当化のプロンプトは出ません。 * ブロックは監査ログに記録されます。 * 「すべて拒否」のモデルを組むとき、クリティカルなOSコンポーネントを誤って壊さないよう、Keeperの保護パスロジックが自動で適用されます。 * 複数ポリシーが競合するとき、**拒否**ポリシーは最も高い優先度で評価されます。
*** ## コントロールの組み合わせ エンドポイント特権マネージャー (KEPM) では、1つのポリシーに複数のコントロールを組み合わせ、段階的な検証を適用できます。組み合わせた場合、設定したすべてのコントロールを満たして初めて操作が許可されます。
*** ### 承認 + MFA **適用の目安** 人的な確認 (承認者がレビューして許可する) と本人確認 (操作ユーザーが本人であることの証明) の両方が必要なときに使います。利用できる組み合わせのなかでは最も強い検証で、多数の端末にまたがり条件の緩い昇格など、リスクの高い操作に推奨されます。 **ユーザー体験** 1. ユーザーが特権操作を行い、保留中の通知が表示されます。 2. 要求が承認キューに回されます。 3. 承認者が要求を許可したあと、ユーザーにMFAの入力が求められます。 4. MFAが確認されると操作が続行します。 **留意点** * 承認フローには独自のタイムアウト (初回レビュー30分、エスカレーション後4時間など) があるため、MFAを足すと全体のやり取り時間がやや長くなります。 * 広い範囲 (例: すべての端末のすべての昇格) に適用すると、承認キューの件数とエンドユーザーへのMFA提示が増えます。アプリケーション、ユーザーグループ、時間帯などでスコープを絞り、負荷を下げることを検討してください。 **JSON表現** ```json "Controls": ["APPROVAL", "MFA"] ``` *** ### 承認 + 正当化 **適用の目安** 人的な確認が必要で、かつユーザーの申し立て理由を承認記録に残したいときに使います。承認者は決定前に要求の詳細とあわせて正当化の文言を確認できます。 **ユーザー体験** 1. ユーザーが特権操作を行います。 2. 要求が送信される前に、正当化メッセージの入力が求められます。 3. 正当化を含んだ要求が承認キューに回されます。 4. 承認者が正当化と詳細を確認し、承認または拒否します。 5. 承認されれば操作が続行します。 **留意点** * **承認が必要**だけでも、正当化は暗黙のうちに必須になります。**正当な理由が必要**を明示的に足すと、正当化の入力がワークフローで確実に挟まり、記録されます。 * 正当化の文言は**エンドポイント特権マネージャー → リクエスト**のダッシュボードの詳細で承認者に見え、監査ログにも残ります。 **JSON表現** ```json "Controls": ["APPROVAL", "JUSTIFY"] ``` *** ### MFA + 正当化 **適用の目安** 本人確認と文書化された理由の両方が必要で、リアルタイムの承認者レビューは不要なときに使います。定型的なセルフサービス的な特権操作で、説明責任と監査に耐える記録が必要な場合に向きます。 **ユーザー体験** 1. ユーザーが特権操作を行います。 2. まずMFAの入力が求められます。 3. MFAが確認されたあと、正当化メッセージの入力が求められます。 4. 正当化の送信後、直ちに操作が続行します (承認者のレビューは不要です)。 **留意点** * MFAと正当化の両方があるときは、常に先にMFAが処理されます。 * ネットワーク接続が必要です (MFAはオフラインでは完了できません)。 * 正当化は監査ログに記録され、MFAで確認した本人情報と紐づきます。承認者を介さずに説明責任の根拠を強くできます。 **JSON表現** ```json "Controls": ["MFA", "JUSTIFY"] ``` *** ## ポリシーの優先順位 コマンドラインポリシーは、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: 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.