サイジング

Deep Security環境のサイジングガイドラインは、ネットワーク、ハードウェア、およびソフトウェアの規模によって異なります。

Deep Security Managerのサイジング

Deep Security Managerコンピュータのサイジングの推奨値は、管理対象のAgentの数によって異なります。

Agentの数 CPUの数 RAM JVMプロセスメモリ Managerノードの数 推奨ディスク容量
<500 2 8GB 4GB 2 200GB
500~1000 4 8GB 4GB 2 200GB
1000~5000 4 12GB 8GB 2 200GB
5000~10000 8 16GB 12GB 2 200GB
10000~20000 8 24GB 16GB 2 200GB
  • 冗長性を提供し、マネージャサービスの可用性を確保するには、2つのマネージャノードを推奨します。
  • 同時処理中に十分なパフォーマンスが発揮されるように、Deep Security Managerとデータベースは、同じ物理的な場所の個別の専用サーバにインストールすることを推奨します。
  • Java仮想マシン (JVM) のメモリ割り当ては、Deep Security Managerのパフォーマンスにとって重要です。Deep Security ManagerのJVMプロセスに初期設定で割り当てられたメモリを変更するには、Deep Security Managerのメモリ使用量の設定を参照してください。
  • Deep Security Managerの推奨設定の検索はCPU負荷が高くなります。推奨設定検索を実行する頻度を決定する際は、Deep Security Managerへのパフォーマンスの影響を考慮する必要があります。詳細については、推奨設定の検索の管理と実行を参照してください。
  • 多数の仮想マシンが同時に再起動され、各AgentがDeep Security Managerとの接続を同時に再確立すると、リソースの使用量が急増する場合があります。

複数のサーバノード

大規模環境での可用性とスケーラビリティを向上させるために、ロードバランサを使用して、同じバージョンのDeep Security Managerを複数のサーバ (ノード) にインストールします。これらのノードを同じデータベースストレージに接続します。

データベースサーバの負荷が高くならないように、データベースサーバ1台につき接続するDeep Security Managerノードは2個までにしてください。

各Managerノードがすべてのタスクを実行できます。あるノードが他のノードよりも重要ということはありません。すべてのノードにログインでき、Agent、Appliance、およびRelayはどのノードにも接続できます。1つのノードで障害が発生してもサービスは継続され、データが失われることはありません。

データベースのサイジング

いくつかの変数がデータベースのディスク容量の要件に影響します。

  • コンピュータ数
  • 1秒あたりに記録されたイベント (ログ) の数
  • イベントの保持期間

イベントの保持期間は、ポリシー、個々のコンピュータの設定、またはその両方で設定できます。(ポリシー、継承、およびオーバーライドを参照してください)。ディスク領域の使用率を設定するには、TCP、UDP、およびICMPのステートフル ファイアウォール に対してログに記録されるイベントを含む、 ログファイルのサイズを制限する)を参照してください。Deep Security Managerのパフォーマンス機能も参照してください。

次の表のデータベースサイズは、ログおよびイベントの保持の初期設定 (7日間) での使用が推奨されるサイズです。データベースのサイジングを見積もるには、次の手順に従います。

  1. 有効にする保護モジュールと、配信するエージェントの数を確認します。
  2. データベースサイズを見積もるために、保護モジュールごとに個別の推奨事項を追加します。
  3. この値を「2つ以上のモジュール」の推奨値と比較し、2つのモジュールのうち小さい方をプロビジョニングします。

たとえば、不正プログラム対策、侵入防御システム、変更監視を使用して750のAgentを配置するとします。個々の推奨値の合計は320GB (20 + 100 + 200) です。ただし、「2つ以上のモジュール」の推奨値は300 GBです。そのため、300GBをプロビジョニングする必要があります。

ディスク容量の見積もり

Agentの
不正プログラム対策 Web
レピュテーション
サービス
セキュリティログ
監視
ファイアウォール 侵入防御 アプリケーション
コントロール
変更
監視
2つ以上のモジュール
1~99 10GB 15GB 20GB 20GB 40GB 50GB 50GB 100GB
100~499 10GB 15GB 20GB 20GB 40GB 100GB 100GB 200GB
500~999 20GB 30GB 50GB 50GB 100GB 200GB 200GB 300GB
1000~9999 50GB 60GB 100GB 100GB 200GB 500GB 400GB 600GB
10000~20000 100GB 120GB 200GB 200GB 500GB 750GB 750GB 1 TB

データベースのサイジングに関する注意事項

  • 初期設定では、システムイベントではデータ削除は実行されません。これはデータベースサイズに大きな影響を与えます。コンプライアンス要件に従って削除設定を調整してください。(ログとイベントの保存に関するベストプラクティスを参照してください)。
  • システムイベントに長期保持要件が必要な場合は、イベントの転送にSIEMまたはSyslogサーバを使用します。また、セキュリティコントロールイベントの転送にSEIMまたはSyslogサーバを使用することもできます。(Deep SecurityイベントをSyslogまたはSIEMサーバに転送するを参照)。

    システムイベントとSecurity ControlイベントがSIEMまたはSyslogサーバに転送されると、そのイベントはデータベースから削除されません。これらのイベントを削除するには、データ削除を使用します。

  • ディスク領域を節約するために、使用されていないプラットフォームごとにすべてのエージェント設定パッケージを削除してください。詳細については、 Deep Securityデータベースからソフトウェアパッケージを削除するからのソフトウェアパッケージの削除を参照してください。設定パッケージを保持する必要がある場合は、それに応じてディスク容量を追加します。ディスク容量の要件を見積もりやすくするために、新しくインストールされたDeep Security Managerと、Managerコンピュータを保護するポリシーが割り当てられたRelayを同じ場所に配置することを検討してください。29のAgent (Agentプラットフォームごとに最大で5つのバージョン) が追加される場合、データベースサイズは約5GBに増加します。
  • ベースラインの再構築、変更の検索、インベントリの変更の検索の操作では、データベース内のすべてのレコードが保持され、削除や外部のSyslogまたはSIEMシステムへの転送は実行されません。アプリケーションコントロールと変更監視のセキュリティモジュールではこれらの操作が使用されるため、他のセキュリティモジュールよりも多くのストレージ容量が必要です。システムイベントやセキュリティイベントなどのその他のタイプの操作では、削除や外部のSyslogまたはSIEMシステムへの転送が実行されます。
  • ファイアウォール および 侵入防御 モジュールを使用するトラフィックの多い環境では、多数の関連イベントが発生することがあります。イベントの数に影響を与える要因は、適用された 侵入防御 ルールと ファイアウォール ルール設定の数です。これらのイベントは大きなデータベースストレージを必要とする可能性があるため、これらのセキュリティイベントを監視し、適切なデータ削除を使用する必要があります。
  • 侵入防御 ルールは、推奨検索時に査定された脆弱性に基づいて適用されます。システムに定期的にパッチを適用し、アプリケーションを最新の状態に保つことで、割り当てられるルールの数を減らすことができます。
  • 大量の ファイアウォール イベントが発生することが予想される場合は、[Out of allowed policy]イベントを無効にすることを検討してください。(ファイアウォールの設定詳細セクションを参照してください)。

Deep Security AgentおよびRelayのサイジング

プラットフォーム 有効になっている機能 RAM 最小ディスク容量
Windows すべての保護 2 GB (4 GB推奨) 1 GB
Windows Relayのみ 2 GB (4 GB推奨) 30 GB
Linux すべての保護 1GB (5GB以上を推奨) 1GB
Linux Relayのみ 1GB (4 GB以上を推奨) 30GB
Solaris すべての保護(1) 4 GB 1GB

(1)Relay 機能はサポートされていません

  • OSのバージョンによって要件が異なるため、必要なRAMが少なくなることがあります。Deep Securityのすべての機能を有効にしていない場合は、RAMも少なくて済みます。
  • Deep Security Relay は、エージェントのプラットフォームごとにパッケージを保存する必要があります。詳細については、 Deep Security Agentソフトウェアの入手の入手を参照してください。プラットフォームが多数ある場合は、より多くのディスク容量が必要になります。使用するリレーの数については、 Relayによるセキュリティとソフトウェアのアップデートの配布によるセキュリティおよびソフトウェアアップデートの配信を参照してください。
  • V-Motionsが必要な場合は、さらに10 GBを推奨します(合計40 GB)。

Deep Security Virtual Applianceのサイジング

初期設定では、Deep Security Virtual Applianceのメモリは4GBだけです。Deep Security Virtual Applianceが保護する仮想マシンの数によって、Applianceのハードウェア要件が決まります。次の表は、保護されている仮想マシンの数に基づいて、割り当てられるvCPUの最小数とメモリ量を示しています。仮想アプライアンスにメモリを割り当てるには、 Deep Security Virtual Applianceのメモリ割り当てを参照してください。

保護される仮想マシンの数 vCPUの数 RAM 最小ディスク容量
1~25 2 6GB 40GB
26~50 2 8GB 40GB
51~100 2 10GB 40GB
101~150 4 12GB 40GB
151~200 4 16GB 40GB
201~250 6 20GB 40GB
251~300 6 24GB 40GB

上記のワークロードはDeep Securityでサポートされており、次の条件が適用されます。

  • エージェントレス 変更監視を使用する場合は、ESXiサーバあたり0〜50台のVMを配置する必要があります。大規模なVDI配信の場合(約51〜300台のサーバ), 変更監視 は無効にする必要があります。VDIを使用し、 変更監視が必要な場合は、各VMにエージェントを配置することをお勧めします。
  • エージェントレス 不正プログラム対策の検索を使用する場合は、VMwareのGuest Introspection機能が必要です。ゲストイントロスペクションでは、上記の表に記載されているものとは異なるワークロードがサポートされる場合があります。詳細については、 VMware Configuration Maximumツールを参照してください。
  • エージェントレス ファイアウォール, Webレピュテーション、または 侵入防御 機能を使用する場合は、VMwareのNetwork Introspection機能が必要です。ネットワークイントロスペクションでは、表に記載されているものとは異なるワークロードがサポートされる場合があります。詳細については、 NSX for vSphere推奨設定の最大を参照してください。

侵入防御を有効にする前に、保護下のOS(特にWindows)にパッチを適用することをお勧めします。パッチが適用されていないOSの場合、VMに割り当てられる 侵入防御 ルールの数が増え、アプライアンスのメモリ使用率が増加します。300の保護されたVMのメモリ推奨値は、VMごとに約350〜400 侵入防御 ルールが割り当てられていることに基づいています。推奨検索でさらにルールが推奨される場合は、Deep Security Virtual Applianceのメモリをそれに応じて増やす必要があります。たとえば、VDIを対象とする300台のVM(完全、リンク済み、またはインスタントクローン):)の推奨値を次に示します。

侵入防御ルールの数 アプライアンスのメモリ
350~400 24GB
500~600 30GB
600~700 40GB
700以上 50 GB

すべての300の保護されたVMで推奨設定の検索を実行すると、タイムアウトが発生することがあります。タイムアウトエラーのため推奨設定の検索に失敗した場合は、 推奨設定の検索の管理と実行 の管理と実行]の手順に従って、タイムアウト値を増やしてください。