アーキテクチャ
エンドポイント特権マネージャーのアーキテクチャとベストプラクティス

本節では、Keeperエンドポイント特権マネージャー (EPM) の構成の概要と、運用上のベストプラクティスを説明します。
アーキテクチャ
信頼と制御
Keeperエンドポイント特権マネージャー (EPM) は、お客様自身が制御を維持できるように設計されています。
ダッシュボード: ポリシー、承認者、コレクション、展開グループは Keeper管理コンソールで定義します。ポリシーを変えるために各エンドポイントにログインする必要はありません。
エージェント: 各エンドポイント上のローカルサービスが、お客様のポリシーを適用します。バックエンドと通信して登録とポリシー同期を行い、ポリシー評価・ログ・ユーザー操作のためのプラグインを実行します。
ローカル優先の適用: ポリシー判断は、最新のポリシーデータを用いてエンドポイント上で行われます。そのため、ネットワークが一時的に利用できなくても、エージェントは最後に受け取った内容に基づき適用を継続できます。
可視性
正常性とステータス: エージェントは正常性とステータス用のエンドポイントを公開しており、お客様 (または監視ツール) が稼働と応答を確認できます。
監査とログ: 操作、ポリシー一致、承認、拒否は監査・ログの対象です。これらのデータをKeeperバックエンドおよびお客様のSIEMや監査ツールへ送れます。
プラグイン: 中核機能 (ポリシー、API、ログ、クライアント) はプラグインに分割されており、アップデートやトラブルシューティングを対象に絞って行えます。
セキュリティ
常時特権の排除: 設計上、ユーザーがローカル管理者である必要はありません。昇格は要求ごとに、ポリシーに従って付与されます。
制御された昇格: 昇格が許可される場合、時間制限やMFA、正当化、承認と紐づけられます。
安全な通信: エージェントとバックエンドの通信は安全な経路を使い、登録はお客様が管理するトークンを用います。
実装の詳細は必須ではありません。大規模な環境でも制御・可視性・セキュリティを両立するよう構築されている、という点を押さえておけば十分です。
ベストプラクティス概要
監視から始める: 新しいポリシーは監視または監視&通知で運用し、適用前に何がブロックまたは許可されるかを把握する。
コレクションを使う: ユーザーとマシンをコレクションにまとめ、1つのポリシーを多数のエンドポイントに適用し、長い一覧を個別に維持しない。
変数とワイルドカードを使う:
{userprofile}のような変数や、対応環境であれば*.exeのようなパターンで、ポリシーをシンプルかつクロスプラットフォームに保つ。展開グループでパイロット: まず小さな展開グループに展開し、挙動を検証してから拡大する。
ログを調整する: トラブルシューティング時はログレベルを上げる (例: Information または Debug)。本番ではWarningまたはErrorにし、ノイズとストレージを抑える。
登録トークンを保護する: 登録トークンはシークレットとして扱い、安全に保管・伝達する。
承認と拒否をレビューする: 承認要求と拒否イベントを定期的に確認し、ポリシーを調整し、不正利用の兆候を把握する。
コンプライアンスに合わせる: フレームワークで統制の証跡が求められる箇所では、MFA、正当化、承認を使う。
エージェントを最新に保つ: 通常のパッチプロセスでエージェントを更新し、修正と新機能を取り込む。
本ガイドは顧客向けドキュメントの参照先として一箇所にまとめてあり、内部向けや開発者向けのリンクは含みません。Keeperエンドポイント特権マネージャー (EPM) を安心して運用するために必要な内容に絞っています。
最終更新
役に立ちましたか?

