ポリシー
本ページでは、ポリシーの種類、ステータス、コントロール、フィルターを整理し、セキュリティとコンプライアンスの目標に沿ったポリシーを設計するうえでの要点を説明します。
ポリシーの種類
各ポリシーには、どの操作を制御するかを決める種類 (タイプ) があります。
エージェント型AI
エンドポイント上でAIエージェント (自律型アシスタント、MCP接続ツール、その他の非人間アイデンティティ) が何を実行できるか
エージェント起点の操作を統制、承認の要求、またはリスクの高い動作の拒否
エージェント型アクセス
AIエージェントが起動する子プロセス (例: IDEエージェントが git や where を起動)
信頼できるサブプロセスの許可、それ以外への承認要求または拒否
エージェント型権限昇格
AIエージェントが昇格 (管理者/root) 権限で実行できる条件
エージェント起点の昇格への承認要求または拒否、信頼できるエージェント向けの特定操作の許可
コマンドライン
コマンドの実行 (例: PowerShell、シェル、スクリプト)
危険なコマンドのブロック、機微なスクリプトへの承認要求
ファイルアクセス
ファイルとフォルダへのアクセス
機微なパスへのブロックまたは許可、特定ファイルへの正当化または承認要求
最小権限
ユーザーがローカル管理者権限を維持するか、外すか
常時管理者権限の削除、特定ロールやマシンへの例外設定
特権昇格
ユーザーが管理者として実行する (または特権を昇格させる) とき
昇格前のMFA、承認、または正当化要求、特定アプリの許可またはブロック
Advanced Mode: Keeperアップデート
各エンドポイントで実行すべきKEPMのバージョン
最新リリースへの自動追従、または検証・変更管理向けのバージョン固定
Advanced Mode: ジョブの更新
エージェント上のジョブ定義のデプロイまたは更新
自動化やポリシー適用ジョブの一括展開
Advanced Mode: 設定の更新
エージェントへの構成のプッシュ (例: プラグインまたはグローバル設定)
ダッシュボードからの設定展開 (各エンドポイントの直接操作不要)
ユーザー (またはプロセス、エージェント) が操作を行うと、エージェント側でイベントタイプ (例: 特権昇格、ファイルアクセス) が判別され、その種類に該当するポリシーだけが評価されます。そのため、特権昇格のポリシーがファイルアクセスをブロックすることはなく、ファイルアクセスのポリシーが昇格をブロックすることもありません。複数のポリシー種類を組み合わせて、カバー範囲をそろえられます。
順序について
複数のポリシー種類を展開する際は、適用順が重要です。常時の管理者権限を削除した後も、統制下で昇格できる手段を確保するため、最小権限ポリシーを適用する前に、特権昇格ポリシーを構成してテストしてください。推奨手順は段階的ロールアウトの計画をご参照ください。
承認の有効期間
ファイルアクセス承認の有効期間
ファイルアクセスポリシーで承認が必要な場合、承認が付与されると、要求者は対象ファイルに4時間アクセスできます。この間、ファイルの開封、編集、保存、および閉じる操作が可能です。
MFAアクセス期間
MFA検証に成功すると、要求者は付与された特権を使える5分間の猶予が与えられます。この時間内に特権を行使しなかった場合、再度MFA検証が必要です。
詳しくは承認期間の構成をご参照ください。
ポリシーのステータス
各ポリシーには、実際にコントロールを適用するか、監視だけにとどめるかを決めるステータスがあります。
オフ
いいえ
いいえ
ポリシーは無視されます。削除せずに無効化するときに使います。
適用
はい
はい
ポリシーが評価され、コントロール (許可、拒否、MFA、承認など) が適用されます。
監視
はい
いいえ
ポリシーは評価され、ログに残りますが、コントロールは適用されず、操作は許可されます。本番適用の前に影響を把握するときに使います。
監視&通知
はい
いいえ
監視と同じですが、ポリシーに一致した場合にユーザーまたは管理者へ通知できます。教育や段階的な展開に向いています。
新しいポリシーはまず監視または監視&通知にし、レポートとログで挙動を確認してから、問題なければ適用に切り替えます。
コントロール
コントロールは、ポリシーが要求に一致したときにどうするかを定義します。許可・拒否のほか、MFA、正当化、承認などの追加手順を求めることもできます。
管理者承認
操作前に権限のある承認者による確認と承認が必要。リスクの高い操作向け
自動承認
ユーザーまたは承認者への確認なしで自動承認し、操作をログに記録。リスクの低い操作向け
自動拒否
ユーザーまたは承認者への確認なしで自動拒否し、試行をログに記録。許可すべきでない操作の把握向け
エンドユーザー承認
別の承認者なしでユーザー自身が要求を承認して続行。意思確認と監査記録が必要だが、承認者の監督が不要な操作向け
正当な理由の入力が必要
操作前に業務上の理由の入力を要求。監査・コンプライアンス向け
MFA必須
操作前に多要素認証を要求。機微な操作への追加認証
コントロールは組み合わせられます (例: MFAと管理者承認)。リスクの高い操作に複数段の確認を課せます。優先順位のルールにより、最終結果が明確になります (拒否は許可より優先されます)。
Advanced Modeとフィルター
フィルターは、ポリシーが誰と何に適用されるかを定義します。通常は以下の条件がすべて一致したときにポリシーが適用されます。
アカウント: どのユーザーまたはユーザーコレクションか
エージェント型AI エージェント起点の操作について、エージェント型AIコレクションで指定するAIエージェント
アプリケーション: どの実行ファイル、パス、パターンか (多くの場合、変数とワイルドカードを利用)
マシン: どのエンドポイントまたはマシンコレクションか
任意: 時刻帯、曜日、または日付の範囲
具体的なフィルター (例: 単一のアプリと単一のグループ) は、広いフィルター (例: 「すべてのユーザー」と「すべてのマシン」) より通常は優先されます。全員向けの既定ポリシーを置き、一部の対象にだけ効く限定的なポリシーで上書きする、といった構成が可能です。
Advanced Modeのオプションには、以下のようなものがあります。
Keeperアップデート: 対象エンドポイントで実行すべきKEPMバージョン (最新リリースまたは固定バージョン) を宣言し、手動での再インストールなしにマシンを揃えます。詳しくはKeeperアップデートをご参照ください。
カスタムルール: ご利用の展開構成で対応している場合、リスクスコアや場所などの追加条件。
Extension / AllowCommands: 一部の構成では、明示的に許可するコマンドのリスト (例: 時刻同期や特定の管理ツール)。許可リスト方式では、リストにないコマンドは拒否されることがあります。
最も限定した条件からポリシーを定義し、その後に広い既定ポリシーを置くとよいでしょう。フィルターを変数とワイルドカードで扱いやすくするには、参考資料: 変数とワイルドカードをご参照ください。
最終更新