大規模デプロイメント
大規模な環境にエージェントをデプロイする場合、すべてのエージェントが継続的にアクティブであり、Tenable Vulnerability Management または Tenable Nessus Manager に接続された状態を保つようなデプロイメント戦略にする必要があります。
デプロイメント戦略
多数のエージェントをデプロイする場合は、ソフトウェアを使用してネットワーク経由でエージェントをプッシュすることを検討してください。例
Tenable は、多数のエージェントをデプロイするときは、24 時間かけてエージェントをバッチ処理でデプロイすることを推奨しています。この方法は、ネットワーク帯域幅が制限されており、ネットワークが一度にダウンロードするデータの量を制限する必要がある場合に特に役立ちます。
インストール後、エージェントが評価を実行する指示を受けると、最初のプラグインアップデートを受け取ります。エージェントは、最初のプラグインアップデート時刻から 24 時間後に次のアップデートを試行するようにタイマーを設定します (後続のプラグインダウンロードが成功すると、プラグインアップデート日が更新されます)。エージェントをバッチ処理でデプロイすると、過剰な数のエージェントが一度に製品のアップデートをチェックし、帯域幅が過剰に消費されることも回避できます。
エージェントは、0～5 分のランダムな遅延の後に Tenable Nessus Manager または Tenable Vulnerability Management にリンクします。この遅延は、エージェントが最初にリンクするとき、およびエージェントが手動またはシステムの再起動によって再起動するときにも発生します。遅延を強制すると、大量のエージェントをデプロイまたは再起動する際のネットワークトラフィックを削減し、Tenable Nessus Manager または Tenable Vulnerability Management に対する負荷を軽減できます。
クラスタリング
Tenable Nessus Manager のクラスタリングを使用すると、単一の Tenable Nessus Manager インスタンスから多数のエージェントをデプロイおよび管理できます。10,000～200,000 のエージェントを持つ Tenable Security Center ユーザーの場合、Tenable Nessus Manager の複数のインスタンスを Tenable Security Center にリンクせずに、単一の Tenable Nessus Manager クラスターからエージェントスキャンを管理できます。
クラスタリングが有効になっている Tenable Nessus Manager インスタンスは子ノードの親ノードとして機能し、それぞれが少数のエージェントを管理します。Tenable Nessus Manager インスタンスが親ノードになると、エージェントを直接管理しなくなります。代わりに、子ノード全体にわたるすべてのエージェントのスキャンポリシーとスケジュールを管理できる単一のアクセスポイントとして機能します。クラスタリングを使用すると、複数の異なる Tenable Nessus Manager インスタンスを個別に管理する場合よりも簡単にデプロイメントサイズを調整できます。
シナリオの例: 100,000 のエージェントをデプロイする
Tenable Security Center ユーザーの担当者が、Tenable Nessus Managerに管理されている 100,000 のエージェントをデプロイするとします。
クラスタリングを使用しない場合、それぞれが 10,000 のエージェントをサポートする、10 個の Tenable Nessus Manager インスタンスをデプロイします。エージェントスキャンポリシーとスケジュールの設定、ソフトウェアバージョンの更新など、各 Tenable Nessus Manager インスタンスを個別に手動で管理する必要があります。各 Tenable Nessus Manager インスタンスを、Tenable Security Center に個別にリンクする必要があります。
クラスタリングを使用する場合、1 つの Tenable Nessus Manager インスタンスを使用して 100,000 のエージェントを管理します。Tenable Nessus Manager でクラスタリングを有効にすると、それが親ノードとなり、子ノードの管理ポイントに変わります。10 個の子ノードをリンクし、それぞれが約 10,000 のエージェントを管理します。新しいエージェントをリンクするか、クラスターに既存のエージェントを移行できます。子ノードは、親ノードからエージェントスキャンポリシー、スケジュール、プラグイン、ソフトウェアの更新を受け取ります。Tenable Nessus Manager 親ノードのみを Tenable Security Center にリンクできます。
詳細は Tenable Nessus ユーザーガイドのクラスタリングを参照してください。
エージェントグループ
Tenable Nessus Manager または Tenable Vulnerability Management でスキャンを管理し、スキャンデータを Tenable Security Center にインポートする場合は特に、エージェントグループのサイズを適切に設定することをお勧めします。Tenable Nessus Manager または Tenable Vulnerability Management でエージェントを管理すると、エージェントグループのサイズを設定できます。
スキャンして単一のエージェントグループに含めるエージェントが増えるほど、マネージャーが 1 つのバッチで処理するデータが増えます。エージェントグループのサイズに応じて、Tenable Security Center にインポートする必要がある .nessus ファイルのサイズが決まります。.nessus ファイルのサイズは、ハードドライブの容量と帯域幅に影響します。
グループのサイジング
| 製品 | グループごとに割り当てられるエージェント |
|---|---|
| Tenable Vulnerability Management |
Tenable Security Center に送信しない場合、グループあたりのエージェントは無制限 Tenable Security Center に送信する場合、グループあたり 20,000 エージェント |
| Tenable Nessus Manager |
Tenable Security Center に送信しない場合、グループあたりのエージェントは無制限 Tenable Security Center に送信する場合、グループあたり 20,000 エージェント |
| Tenable Nessus Manager クラスター | スキャンが個別の子ノードの数に応じて適切に自動的に分割されるため、無制限 |
グループタイプ
エージェントを環境にデプロイする前に、スキャン戦略に基づいてグループを作成します。
以下はグループタイプの例です。
オペレーティングシステム
資産タイプまたは場所
複数のスキャン戦略がある場合は、複数のグループにエージェントを追加することもできます。
スキャンプロファイル戦略
必要なすべての資産にエージェントをデプロイしたら、スキャンプロファイルを作成し、既存のエージェントグループにそれらを結び付けることができます。次のセクションでは、いくつかのスキャン戦略について説明します。
オペレーティングシステムのスキャン戦略
次の戦略は、スキャン戦略が資産のオペレーティングシステムに基づいている場合に有用です。
基本エージェントスキャン - Linux
この例では、スキャンは基本エージェントスキャンテンプレートに基づいて作成され、Amazon Linux、CentOS、Red Hat グループに割り当てられます。このスキャンは、これらの資産のみをスキャンします。
資産タイプまたは場所のスキャン戦略
次の戦略は、スキャン戦略が資産のタイプや場所に基づいている場合に役立ちます。
基本エージェントスキャン - 本番サーバー
この例では、スキャンは基本エージェントスキャンテンプレートに基づいて作成され、本番サーバーグループに割り当てられます。このスキャンは、本番サーバー資産のみをスキャンします。
基本エージェントスキャン - ワークステーション
この例では、スキャンは基本エージェントスキャンテンプレートに基づいて作成され、ワークステーショングループに割り当てられます。このスキャンは、ワークステーション資産のみをスキャンします。
スキャンスタガリング
Tenable Nessus Agents を使用したスキャンは、多くの点で従来のネットワークスキャンよりも効率的ですが、特定のタイプのシステムでは、スキャンスタガリングを検討することができます。
たとえば、仮想マシンに Tenable Nessus Agents をインストールする場合、複数のグループにエージェントを分散し、関連するスキャンウィンドウの開始時点を少しずらして起動させることができます。
スキャンをスタガリングすると、仮想ホストサーバーに対する 1 回の負荷が制限されます。これは、エージェントが、スキャンウィンドウの開始時に可能な限り早く評価を実行するためです。エージェントの評価がすべてのシステムで同時に開始されると、オーバーサブスクライブの環境またはリソース制限のある仮想環境ではパフォーマンスの問題が発生する可能性があります。