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

ファイルインベントリの有効化

概要

Keeperエンドポイント特権マネージャー (EPM) は、マシンコレクション内のエンドポイントにインストールされた実行可能ファイルの詳細インベントリを収集できます。このインベントリにより、管理者は正確で的を絞ったポリシーを作成するためのデータを得られます。例えば、特定の古いバージョンのPowerShellをブロックしつつ、新しい承認済みバージョンを許可する、といった運用が可能になります。

comment-question

なぜファイルインベントリを収集するのか? EPMのポリシーは、広いワイルドカードではなく、特定のファイルパス、バージョン、ハッシュを対象にしたときに最も効果を発揮します。ファイルインベントリは、それらの詳細を把握するための仕組みです。インベントリがなければ、_想定している_インストール内容に対してポリシーを書くことになり、インベントリがあれば、_実際に_インストールされている内容に対してポリシーを書けます。

macOSでのアンインストール

macOSからKeeperエージェントをアンインストールするには、デプロイパッケージとともにダウンロードされるインストールスクリプトに含まれるアンインストールスクリプトを実行します。

ファイルインベントリの仕組み

エンドポイントでファイルインベントリが有効になると、エージェントはファイルシステムをスキャンし、実行可能ファイル (パス、メタデータ、バージョン情報) をカタログ化します。そのデータはKeeperへアップロードされ、ポリシービルダーで利用できるApplicationsコレクションに反映されます。

Applicationsコレクションには、ワイルドカードや一般的なパス変数 (例: {system32}、{programFiles}) があらかじめ登録されています。ファイルインベントリは、実際のエンドポイントから得た解決済みデータでこのコレクションを充実させます。

lightbulb-exclamation-on

重要: 特定バージョンのアプリケーションを対象とするポリシーを作成する場合、そのバージョンがファイルインベントリの対象に含まれる少なくとも1台のマシンにインストールされている必要があり、Applicationsコレクションに表示されるまで待つ必要があります。

ファイルインベントリがデフォルトで無効な理由

ファイルインベントリは、以下の2つの理由によりデフォルトで無効です。

  1. パスのばらつき: ファイルパスはマシンごとに異なります。EPMのポリシーエンジンは、フリート全体でポリシーが機能するよう、パス変数とワイルドカードを使うよう設計されています。ベースラインのビルドイメージと変数マッピングを定義する前にフルファイルインベントリを有効にすると、ポリシーに適さないパスが大量に登録される可能性があります。

  2. リソースコスト: フルファイルシステムスキャンはリソースを大量に消費する操作です。大規模環境では特に、すべてのエンドポイントでデフォルト実行すると不要な負荷が生じます。管理者は意図的かつ選択的に有効化すべきです。

ファイルインベントリの有効化

ファイルインベントリはkeeperInventoryFullプラグイン設定で制御されます。有効にするには、そのプラグイン構成で enabledtrue に設定するSettingsUpdateポリシーを適用する必要があります。

手順1: SettingsUpdateポリシーの作成

以下のJSONを出発点として使用します。Keeperダッシュボードの新しいSettingsUpdateポリシーにコピーし、"enabled": false"enabled": true に変更します。

pencil-line

注: modifiedAt タイムスタンプの更新は不要です。内部のバージョン追跡に使用され、ポリシー評価には影響しません。

手順2: ポリシーをコレクションに割り当て

インベントリを収集したいマシンコレクションにポリシーを割り当てます。ポリシーがそれらのエンドポイントに同期されると、エージェントは file-inventory.json で定義されたスケジュール (以下参照) に従ってファイルインベントリデータの収集を開始します。

ファイルインベントリジョブ (file-inventory.json)

インベントリスケジュールは FileInventory ジョブで制御されます。デフォルトでは、このジョブは以下のスケジュールで動作します。

  • エージェント起動時に1回実行

  • 定期スケジュールで5日ごと (7,200分) に再実行

環境に合わせてこのジョブを変更できます。例えば、リソースへの影響を減らすために間隔を延長する、起動時トリガーを無効にしてスケジュール実行のみにする、など。

comment-question

ヒント: ジョブJSONの enabled フィールドは、ジョブがアクティブかどうかを制御します。これは keeperInventoryFull プラグイン設定とは別です。インベントリ収集を実行するには、両方を true に設定する必要があります。

プラットフォーム対応

ファイルインベントリ収集は3プラットフォームすべてで利用できます。

プラットフォーム
対応

Windows

✅ 可

macOS

✅ 可

Linux

✅ 可

リソース上の考慮事項

ファイルインベントリはリソースを大量に消費する操作です。フルスキャンはシステム上のすべてのファイルパスを読み取り、結果をKeeperへアップロードします。スキャン中は、エージェントの通常の定常状態と比べてCPUおよびメモリ使用量が上昇します。

推奨事項

  • 選択的にインベントリを有効化: ファイルインベントリは参照用コンピューター、ゴールデンイメージマシン、または専用テストエンドポイントに限定してください。大規模フリートのすべてのワークステーションで実行する必要はほとんどなく、大きなオーバーヘッドが生じます。

  • 参照マシンを使用: OSごと、部門ごと、ロールごとに1台など、標準ビルドを代表するマシンを選びます。それらのマシンからのインベントリで、ユーザーが実際に使用するアプリケーションをカバーできます。

  • 必要な場合のみスコープを拡大: 特定のアプリケーションバージョンがApplicationsコレクションにない場合、そのバージョンがインストールされているマシンを対象インベントリコレクションに追加し、インベントリを収集した後、スコープから外します。

  • スケジュールを調整: デフォルトの5日間隔は妥当な基準です。安定した環境では、週次または月次に延長できる場合があります。

down-to-dotted-line

要点: ファイルインベントリはネットワークスキャンと同様に、正確に、スケジュールを組み、実際に必要な範囲に限定して扱ってください。常にすべての場所で実行する必要はありません。

インベントリ実行後の動作

エンドポイントでファイルインベントリが完了すると、以下の処理が行われます。

  1. 収集したファイルデータはエージェントの統合ストレージにローカル保存されます。

  2. MQTT経由でKeeperApiトピックへ通知が公開されます。

  3. KeeperAPIがインベントリデータをKeeperクラウドバックエンドへアップロードします。

  4. KeeperダッシュボードのApplicationsコレクションが、検出された実行可能ファイルで更新されます。

  5. 特定のファイルパス、ハッシュ、バージョンを参照するポリシーが、それらのエントリを正確に対象にできるようになります。

ポリシーでのインベントリデータの利用

ファイルインベントリで充実したApplicationsコレクションは、きめ細かいポリシーターゲティングの基盤です。可能になる操作の例は以下のとおりです。

  • 特定バージョンのアプリケーションを拒否: 例: powershell.exe バージョン 5.1.17763.x をブロックし、7.x を許可

  • 既知の正常なインストーラーの昇格を許可: ファイル名だけでなく、正確なファイルハッシュで対象指定

  • 「Living off the land」バイナリの検出と制御: インベントリにより、エンドポイント上に存在するネイティブOSツール (例: wmic、certutil、mshta) が明らかになり、正確なコマンドラインまたはファイルアクセスポリシーが可能になります

最終更新