ポリシー
ユーザーとマシンに最小特権ポリシーを適用
ポリシーの概要
エンドポイント特権マネージャーは、Keeperエージェントが実行されているエンドポイント全体に対して、アプリケーション、ユーザー、マシンごとに最小権限ポリシーを適用できます。ポリシーはテナント内の任意のコレクションに対して適用可能であり、組織の要件に応じて管理者がカスタマイズします。
アプリケーション、ユーザー、マシン、コレクション、実行コンテキストにわたり、きめ細かな適用制御を設定できます。フィルタ機能の強化により、管理者はポリシーの種類、ステータス、コントロール、ユーザーグループ、マシンコレクション、アプリケーション、日時範囲の単位でポリシーを指定でき、包括的なガバナンスとピンポイントの適用の両立が可能です。
ポリシーは以下に基づいて適用されます。
リソースのコレクション
ポリシーの種類
制御項目 (コントロール)
属性
「ポリシー」画面には、テナント内でアクティブなすべてのポリシー適用状況が表示されます。
ポリシーの作成
新しいポリシーを作成するには、[ポリシーを作成] をクリックし、ポリシーの詳細フォームを完成させます。
重要: 複数のポリシーを同じデバイスやユーザーに同時に適用することができます。この場合、適用できるすべてのポリシーを厳密に順守して適用します。ポリシーに設定の競合がある場合、自動的に最も制限的なオプションを適用し、エンドポイントの最大のセキュリティを確保します。
ポリシーの種類
Keeperで利用できるポリシータイプは以下のとおりです。
最小特権: ローカルユーザーを管理者ロールから削除します。
特権昇格: 管理者昇格のリクエストを管理します。
ファイルアクセス: 実行可能ファイルや機密ファイルへのアクセスを制御します。
コマンドライン: Unix系システムにおける
sudoの制御用。
ポリシーステータス
ポリシーは以下のいずれかの方法で適用できます。
モニター: Keeperは何もアクションを起こさず、ユーザーに通知は行われません。
モニター＆通知: Keeperは何もアクションを起こしませんが、ユーザーにはイベントが発生したことを通知します。
モニター＆通知を選ぶ場合は、ポリシーの確認が必要にチェックを入れる必要があります。
適用: Keeperはポリシーに基づきアクションを起こし、ユーザーには通知が届きます。
オフ: ポリシーは無効です。
ポリシーコントロール
ポリシーのステータスが適用のとき、ユーザーは定義された特定のコントロールを通過する必要があります。オプションは以下のとおりです。
多要素認証 (MFA) 必須: 割り当てられたMFAデバイスを使用して、身元を証明する必要があります。MFAが必須の場合、ユーザーはKeeperボルトにサインアップし、TOTP方式の2FA (2要素認証) を設定する必要があります。MFAセッションの有効期間は5分です。テナント内であれば、有効なKeeperのメールアドレスと2FAの組み合わせで認証が行えます。
承認が必要: 指定された承認者がリクエストを処理するまで待機する必要があります。承認には常に理由の入力が必要です。最初の承認リクエストは30分でタイムアウトし、30分経過すると自動的にエスカレーションされます。エスカレーション後の承認は4時間以内に完了する必要があります。リクエストが承認されると、ユーザーは24時間以内にその権限を使用できます。タイムアウトは、イベントタイプごとの承認ページで構成できます。
正当な理由が必要: リクエストの理由を説明する必要があります。承認時に理由の入力に加えてMFAが必要な場合、ユーザーはまずMFA認証を完了し、その後に理由の入力を求められます。
標準実行についても、昇格制御に加え、アプリケーションの許可リストと拒否リストによる適用が可能です。特権操作だけでなく通常のアプリケーション運用にも最小権限の原則を広げ、一元管理を維持したままデフォルト拒否の運用ができます。
ポリシーフィルタ
ポリシーは、ポリシーフィルタセクションで指定されたユーザーおよびデバイスにのみ適用されます。以下のオプションがあります。
ユーザーグループ: 自動生成されたまたはカスタムユーザーグループコレクションから選択します。
マシン: 自動生成されたまたはカスタムマシンコレクションから選択します。
アプリケーション: 自動生成されたまたはカスタムアプリケーションコレクションから選択します。
日時ウィンドウ: 特定の日付範囲、曜日、時刻にのみポリシーを適用します。たとえば、勤務時間外にだけ制限を強化するポリシーを設定できます。
ファイルアクセスの承認期間
ファイルアクセスポリシーで承認が必要な場合、承認後は4時間以内、要求者が承認されたファイルにアクセスできます。この4時間以内は、許可されたファイルを開き、編集、保存、閉じる操作が可能です。
MFAアクセス期間
MFAチャレンジが発行され、正常に完了すると、要求者は5分間、承認された特権を利用できます。この時間内に特権を行使しなければ、新しいMFA要求を送信する必要があります。
参考: 承認期間の構成
すべて拒否のポリシー
「すべて拒否」のモデルでは、意図しないシステム障害を避けつつ厳格な適用を維持するため、保護パスのロジックが組み込まれています。保護パスにより、広範な制限をかけても OS の重要な構成要素の安定性を保てます。
詳細は保護パスをご参照ください。
ワイルドカードポリシー
ポリシーフィルタを選択する際に [すべて選択] を選ぶと、ワイルドカードポリシーとなります。ワイルドカードポリシーを設定すると、将来コレクションに追加されるオブジェクトも自動的に対象に含まれます。
たとえば、以下のポリシーでは、すべてのユーザーグループ、マシンコレクション、およびアプリケーションに対してワイルドカードポリシーが適用されています。
ポリシーエディタ
ポリシーは、ユーザーインターフェースで基本モードまたは詳細モードで編集できます。詳細モードでは、JSON形式のポリシー定義を編集できます。
詳細なポリシーエディタ
ポリシーエディタの詳細モードでは、管理者がポリシーを直接JSON構文で管理できます。
承認設定
エンドポイント特権マネージャー (KEPM) の承認は、グローバルな承認フレームワークに基づいて管理されます。承認の設定はKEPM内ではなく、管理コンソールの [管理者] → [承認] に集約されています。すべてのリクエスト種別に共通する承認となり、チームを承認者またはエスカレーション先の承認者として指定できます。Keeper管理者には引き続き承認の全権限があります。承認の有効期間ウィンドウも設定でき、最長30日まで指定できます。
日々の運用では、引き続き [エンドポイント特権マネージャー] → [リクエスト] で リクエストの状況を確認 します。承認ルール、承認者の割り当て、エスカレーションの動作、承認の時間ウィンドウは、[管理者] → [承認] で一元管理します。
これは、承認者および承認の設定をKeeper管理コンソールで行うという一般的な手順とも整合します (メニュー名はコンソールのバージョンによって異なる場合があります)。
コマンドレベルの昇格
ポリシーでは、実行可能ファイルに含まれるコマンドライン引数やサブコマンド単位で、コマンドレベルの昇格を制御できます。承認や拒否の単位を細かく指定できるため、許可されたアプリケーションでも、事前に承認された操作に限り昇格を許可でき、権限の濫用リスクを低減できます。
ポリシーの適用タイミング
ポリシーはエンドポイント全体に対してプッシュされ、30分以内に適用されます。Keeperエージェントのユーザーインターフェースには、[ポリシーを更新] オプションも用意されています。
オフラインアクセス
Keeper管理者が作成したポリシーは、エンドユーザーのデバイスにプッシュされ、ローカルにキャッシュされます。オフライン時もデバイス上でポリシーが評価されます。
理由の入力が必要な場合、ユーザーが入力したメッセージは、エージェントがオンラインになるまで端末上に一時保存され、その後サーバーに送信されます。ポリシーが「正当な理由のみ」を求めている場合は、実行が許可されます。
多要素認証 (MFA) が必要な場合、ユーザーはオンライン時のみ操作を実行できます。
承認が必要な場合、ユーザーはオンライン時のみ承認リクエストを開始できます。
監査メッセージはローカルにキャッシュされ、エージェントがオンラインになるとサーバーに送信されます。
コマンダーを使用した自動化処理
Keeperコマンダーは、コマンドラインインターフェイス、サービスモードREST API、Python SDKを通じてポリシーの自動化に利用できます。エンドポイント特権マネージャーのコマンドの詳細は、エンドポイント特権マネージャーコマンドのページをご参照ください。
ポリシー管理
epm policy コマンドでポリシーの生成を管理します。
承認とKEPMポリシーの関連付け
承認チームを作成しただけでは、承認フローは始まりません。以下の条件をすべて満たした場合に限り、承認が求められます。
エンドポイント特権マネージャーのポリシーに承認が必要コントロールが含まれること
リクエストの種類が、管理コンソールで設定した承認の種類と一致すること
両方を満たすと、リクエストは割り当てられた承認チームに送られます。
承認ワークフロー
ポリシーで承認が必要な場合の流れは以下のとおりです。
ユーザーが操作を開始する 例: 管理者として実行。
エージェントがポリシーを評価する 承認が必要な「保留中」の判定が返されます。
リクエストが作成される リクエストが Keeper のバックエンドに送られます。
承認チームがリクエストを受信する 承認者は以下の内容を確認できます。
リクエストしたユーザー
マシン
アプリケーション
コマンドライン (該当する場合)
正当な理由 (必要な場合)
承認者が対応する
承認 → 昇格が続行されます
拒否 → リクエストはブロックされます
最終更新