For the complete documentation index, see llms.txt. This page is also available as Markdown.

アーキテクチャ

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

本セクションでは、Keeperエンドポイント特権マネージャー (Keeper EPM) の構成概要と、運用上のベストプラクティスを取り扱います。

構成の考え方

信頼と制御

Keeperエンドポイント特権マネージャーは、お客様が制御権を維持できるよう設計されています。

  • ダッシュボード: Keeper管理コンソールでポリシー、承認者、コレクション、展開グループを定義します。ポリシーを変更するために各エンドポイントへログインする必要はありません。

  • エージェント: 各エンドポイント上のローカルサービスがポリシーを適用します。バックエンドと通信して登録およびポリシー同期を行い、ポリシー評価、ログの記録、ユーザー操作のためのプラグインを実行します。

  • ローカル優先の適用: ポリシー判定は、取得済みの最新ポリシーデータを用いてエンドポイント上で行われます。ネットワークが一時的に利用できなくても、エージェントは最後に受け取ったポリシーに基づき適用を継続できます。

可視化

  • 稼働と状態: エージェントはヘルスと状態を返すエンドポイントを公開します。稼働状況と応答の確認に利用できます (監視ツールとの連携も可能)。

  • 監査とログ: 操作、ポリシー一致、承認、拒否を監査・記録します。Keeperのバックエンドに加え、お客様のSIEMや監査ツールへも送信できます。

  • プラグイン: ポリシー、API、ログ、クライアントなどの中核機能をプラグインに分割しているため、更新や障害切り分けに取り組みやすくなります。

セキュリティ

  • 常時特権をユーザーに与えない: 設計上、ユーザーはローカル管理者である必要はありません。昇格はリクエストごとに、ポリシーに基づいて付与されます。

  • 制御された昇格: 昇格を許すときは、時間制限に加え、MFA、正当な理由の入力、承認といった要件を組み合わせて指定できます。

  • 安全な通信: エージェントはバックエンドと安全な経路で通信し、登録にはお客様が管理するトークンを用います。

実装の詳細まで把握する必要はありません。制御可視化セキュリティを大規模環境でも両立する構成であることだけ押さえれば十分です。

推奨される運用

  • まずは監視から: 新しいポリシーには監視のみ、または監視&通知を使い、適用前にブロックまたは許可となる挙動を把握します。

  • コレクションを使う: ユーザーと端末をコレクションにまとめると、長い一覧を維持せずにひとつのポリシーを多くのエンドポイントへ適用できます。

  • 変数とワイルドカードを使う: {userprofile} のような変数や、機能の対応範囲内での *.exe などのパターンで、ポリシーをシンプルかつクロスプラットフォームに保てます。

  • 展開グループで試験導入: まず小さな展開グループに展開し、挙動を検証してから拡大します。

  • ログを調整: トラブルシュート時は情報またはデバッグなど詳細なログレベルを使い、本番では警告またはエラーに抑えてノイズとストレージ負荷を下げます。

  • 登録トークンを保護する: 登録トークンは機密情報として扱い、安全に保管および送信します。

  • 承認と拒否を定期的に確認する: 承認リクエストと拒否イベントを定期的に確認し、ポリシー調整や不正利用の検知に用います。

  • コンプライアンスに合わせる: フレームワークが統制の証跡を求める箇所では、MFA、正当な理由の入力、承認を組み合わせて使います。

  • エージェントを更新する: 修正と新機能を取り込むため、通常のパッチ手順でエージェント更新を展開します。


制御権は常にお客様側にあります。本ガイドは顧客向けドキュメントのまとめであり、社内向けや開発者向けのリンクは含みません。Keeperエンドポイント特権マネージャーを安心して運用するうえで必要な内容だけを記載しています。

最終更新