よくある質問
エンドポイント特権マネージャーに関するよくある質問
Keeper EPMはEDRおよびITDRツールとどう比較されますか？
Keeper EPMのような特権昇格および委任管理 (PEDM) ツールとEDR製品は、境界が曖昧に見えることがありますが、解決する課題は異なり、互いに置き換えるのではなく補完し合います。各カテゴリの位置づけはおおむね以下のとおりです。
PEDM (Keeper EPM): 実行のガバナンス（能動型）。特権昇格、ファイルアクセス、コマンド実行をポリシーで制御し、実行前に権限の悪用や不正操作を防ぐ
EDR: 振る舞いの検出（受動型）。プロセスを監視し、実行済みまたは不審な挙動への検知・対応を行う
ITDR (Keeper EPMの今後の方向性): アイデンティティの信頼性と異常検知。アイデンティティ起点の脅威や、通常と異なるアイデンティティの挙動への対応
PEDMとEDRを併用すると、単独利用より強固な防御になります。Keeper EPMは恒常的な特権を排除し、リスクの高い操作にMFA、正当な理由の入力、承認を求めることで攻撃対象領域を縮小します。一方、EDRはエンドポイント上で実際に発生した不審な挙動を監視します。
カテゴリが重なる領域もあります。たとえば、一見正当なアプリケーションからのデータ持ち出しの検知と防止などです。今後もこの領域に該当する機能の追加を予定しています。リアルタイムの攻撃検知と対応 (EDRの中核) は、Keeper EPMの目的ではありません。現在の開発重点はPEDM機能の強化にあり、ITDRへの展開にも注力しています。
スタック内の別ツールを統合または置き換えるためにKeeper EPMに必要な特定の機能がある場合は、ぜひお知らせください。そのフィードバックは、ギャップの評価とロードマップ策定に活用されます。
エンドポイント特権マネージャーに追加予定の機能は？
今後のロードマップには多くの機能拡張が計画されています。2026年末までに、以下の主要な機能が追加される予定です。
リアルタイム／即時更新
モバイルプッシュによる承認機能
管理者およびエンドユーザー向けの操作性向上
FIDO2キーなどを含む追加のMFA制御オプション
エンドポイント特権マネージャーはどのように機能しますか？
Windowsでは、Keeperエンドポイント特権マネージャーはシステム権限のエージェントとしてインストールされ、サービスとして実行されます。このエージェントは、ユーザーセッション内で作成されるすべてのプロセスをフック (監視) し、各プロセス作成をインターセプトします。なお、システムプロセスや他のセキュリティ製品にはフックを行いません。
アプリケーション実行ファイルが起動されると、Keeperは各サブプロセスのリクエストをポリシーに基づいて個別に評価します。これにより、以下のような制御が可能になります。
MFA (多要素認証) の要求
実行理由の入力要求
拒否
承認リクエストの送信
サブプロセスが実行される際は、一時的に作成されるエフェメラルアカウントの下で動作し、処理後このアカウントは破棄されます。
macOSでは、KeeperはAppleが承認したシステム機能拡張として動作します。 macOSのシステム拡張は、カーネル空間ではなくユーザー空間で動作するため、セキュリティと安定性が向上します。
Linuxでは、KeeperはPluggable Authentication Module (PAM) を使用しており、プロセスの権限昇格を制御します。
Keeperエージェントはどのようにバックエンドサービスと通信しますか？
デフォルトでは、Keeperエージェントはゼロ知識暗号化メッセージングプロトコルを用いて、Keeperのバックエンドインフラストラクチャと通信します。
お客様の環境にSPIFFEサーバーがある場合は、SPIFFEに対応したプラグインを利用し、署名付きペイロードでお客様のSPIFFEエージェントと通信するよう登録できます。
Keeperにエンドポイントへのアクセスはありますか？
いいえ、Keeperはゼロ知識プラットフォームです。Keeperエージェントが収集したすべての情報は、ユーザーのデバイス上で暗号化され、管理コンソールのKeeper管理者のみが復号化できます。
Keeperのサーバーは従業員が何のプログラムを実行しているか知り得ますか？
いいえ、Keeperはゼロ知識プラットフォームです。Keeperエージェントが収集したすべての情報は、ユーザーのデバイス上で暗号化され、管理コンソールのKeeper管理者のみが復号化できます。
承認が必要ない際にはどのようにしてジャストインタイムアクセスが付与されますか？
デバイスに適用されたポリシーが特定のイベントに対して承認を必要としない場合、Keeperエージェントは追加の承認手続きなしで昇格を許可します。多要素認証が必要な場合、ユーザーは認証トークンの提示を求められます。
ユーザーがオフラインでインターネット接続がない場合にはどのようにして昇格を許可しますか？
Keeperのエージェントは、オフライン時に暗号化されたポリシー情報をキャッシュします。ユーザーがオフラインの間も、ポリシーはユーザーに対して適用されます。ユーザーがオンラインに戻ると、イベントログはKeeperクラウドに送信されます。
KeeperPAM、エンドポイント特権マネージャーとMicrosoft LAPSの併用に関して
KeeperPAMとエンドポイント特権マネージャーは、LAPSの導入を既に行っている組織とシームレスに連携できます。この補完的な構成では、LAPSはドメイン参加コンピュータのローカル管理者パスワードのローテーションを引き続き管理し、KeeperPAMはドメインアカウント、サービスアカウント、LAPSの範囲外の他の特権認証情報を管理します。この統合により、既存のLAPSを維持しながら、より多くのシステムとアカウントタイプに対して特権アクセス保護が拡張されます。
エンドポイント特権マネージャーは、エンドポイントで最小特権を適用することにより、このセキュリティエコシステムを強化します。LAPSは既存の管理者アカウントの認証情報を保護することに焦点を当てていますが、特権マネージャーは、特定のタスクのために一時的な特権昇格を可能にすることにより、これらのアカウントを使用する必要性を最小限に抑えます。つまり、LAPSはローカル管理者パスワードを保護し、KeeperPAMはそれらの認証情報とその他の特権アカウントへのアクセスを管理・制御し、特権マネージャーはユーザーが必要かつ承認された場合のみ昇格した特権が付与されるようにします。
どのようにしてLAPSを置き換えることができますか？
Keeperを使用すると、Microsoft LAPSよりも包括的に特権アクセス管理にアプローチできます。LAPSはドメイン参加済みコンピューターのローカル管理者パスワードのみを管理しますが、Keeperでは以下の2つの補完的なコンポーネントを通じて完全なソリューションが実現します。
KeeperPAM はドメインおよびローカルアカウントの認証情報の管理とローテーションを実行します。
エンドポイント特権マネージャー は最小特権ポリシーとジャストインタイム昇格を実施します。
組織は、KeeperのソリューションでLAPSを完全に置き換えるか、移行期間中に両方を併用することができます。
KeeperPAMはエンドユーザーのマシンでどのように認証情報を管理しますか？
KeeperPAMはKeeperゲートウェイを通じて、以下の認証情報のローテーションを行います。
Active Directory内の任意のドメインユーザーアカウント
個別のマシン上のローカル管理者アカウント (WindowsではWinRM、Linux/macOSではSSHによるアクセスが必要)
これにより、KeeperPAMは、環境全体で集中管理されたドメイン認証情報と分散管理されたローカル管理者認証情報の両方を管理できます。
エンドポイント特権マネージャーは管理者アクセスのセキュリティをどのように確保しますか？
エンドポイント特権マネージャーは認証情報管理ではなく、特権昇格に焦点を当てています。
ユーザーをローカル管理者グループから削除
管理権限が必要な場合、ユーザーが昇格をリクエストする
デフォルトの管理者アカウントが昇格リクエストを承認または実行するポリシーを設定可能
管理者認証情報を晒すことなく、ジャストインタイムでアクセスを付与
Microsoft LAPSの有無に応じたKeeperソリューションの利用オプション
オプション 1: LAPSをKeeperPAMで置き換える
KeeperPAMはドメインおよびローカル管理者の認証情報を管理・ローテーション
LAPSよりも包括的な認証情報管理を実現
ボルト、多要素認証、きめ細かなアクセス制御を通じてセキュリティを強化
オプション 2: LAPSをKeeperソリューションで補完する
LAPSはローカル管理者パスワードの管理を継続
KeeperPAMはドメイン管理者およびサービスアカウントの認証情報を管理
エンドポイント特権マネージャーは最小特権ポリシーとジャストインタイム昇格を実施
オプション 3: Keeperソリューション (最も安全)
KeeperPAMはすべての管理者認証情報 (ドメインおよびローカル) を管理
エンドポイント特権マネージャーは最小特権ポリシーを実施
ユーザーは管理者認証情報に直接アクセスする必要がない
管理者認証情報は緊急時にのみ使用
最大のセキュリティを確保するために推奨されるアプローチは？
Keeperソリューション (オプション 3) は、KeeperPAMによる認証情報管理とエンドポイント特権マネージャーによる特権管理の両方に対応する最も包括的なアプローチとなります。これにより、従来のLAPSは不要となり、優れたセキュリティ制御を達成し、詳細な監査証跡が取得できます。
Keeperはシェルエスケープやサブプロセスの起動を防止しますか？
はい。アプリケーションが起動する際、Keeperは実行前に各サブプロセスのリクエストをポリシーに基づいて評価します。これにより、許可されていないシェルエスケープをブロックし、サブプロセスを経由した権限昇格を防止することができます。これにより、権限昇格の経路に対して厳格な制御が実現されます。
Keeperはsudoポリシーを一元管理できますか？
はい。Keeperの「コマンドライン」ポリシーには、「sudo」の使用を保護する機能が含まれています。管理者は、sudo コマンドの実行に対して、理由の入力、MFA (多要素認証)、または承認が必要かどうかを指定できます。このポリシーは、ユーザー、グループ、マシンのコレクションに適用することができます。
昇格リクエストが拒否されたのはなぜですか？
多くの場合、明示的に許可するポリシーがないことが原因です。ユーザーがローカル管理者であり、「管理者に対するポリシーの適用」がオンになっている場合などでは、エージェントがデフォルトで拒否するように構成されていることがあります。該当するアプリ、コマンド、またはシナリオに一致する特権昇格ポリシーを追加し、制御を許可 (または MFA、正当な理由の入力、承認など、運用に合わせた設定) にしてください。ポリシーのフィルター (ユーザー、マシン、アプリケーション) がリクエストに一致しているかどうかも確認してください。
「今すぐ同期」(時刻同期) やローカルユーザーとグループを許可したい場合は？
これらはいずれも昇格が伴う操作です。時刻の同期や MMC のローカルユーザーとグループなど、特定の実行ファイルまたはコマンドを許可する特権昇格ポリシーを作成してください。環境によっては、既知の安全なコマンド用の AllowCommands (またはこれに類する) リストを使用している場合があります。その場合は該当コマンドをリストに追加してください。その他の管理ツールを許可する場合も同様です。
監視と適用の違いは何ですか？
監視では、ポリシーは評価されログに残りますが、実行に対する制限はかかりません。適用では、許可、拒否、MFA、承認など、ポリシーで指定した制御が実行に反映されます。動作確認の段階では監視を、ブロックや追加手順の要求を本番で行う段階では適用を使用してください。
ポリシーは管理者にも適用されますか？
ローカル管理者が、どのポリシーにも一致しない場合に特権昇格ポリシーの適用対象となるかどうかを構成できます。「管理者に対するポリシーの適用」がオフ (デフォルト) の場合、一致するポリシーがなくても管理者は昇格できます。オンの場合、許可するポリシーがないリクエストは拒否されます。この挙動は、ダッシュボードまたは構成ポリシーから変更できるプラグイン設定 (KeeperPolicy) で制御します。
独自の承認システム (ServiceNow、Jira など) を利用できますか？
Keeperでは、カスタム承認フローを利用できます。外部のチケット発行または承認システムと連携し、リクエストをそこに起票して結果をエージェントへ反映できます。具体的な構成は、Keeperの導入形態とコンソールで利用できる連携オプションによって異なります。アカウント担当者またはコンソール向けの連携ドキュメントをご参照ください。
最終更新