サイジング

本ページでは事例に基づき、Deep Securityの安定稼働のために推奨されるサイジングについて記載しています。Deep Securityの導入にあたり必要となるシステム要件についてはこちらをご確認ください。

オンプレミスのDeep Security環境のサイジングガイドラインは、ネットワーク、ハードウェア、およびソフトウェアの規模によって異なります 。Deep Security RelayのサイジングとAzure Marketplaceのサイジングも参照してください。

データベースのディスク容量

必要なデータベースのディスク容量は以下の要素によって異なります。

  • コンピュータ数
  • 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

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

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

    システムイベントとセキュリティコントロールイベントは、SIEMまたはSyslogサーバに転送されても、データベースから削除されません。これらのイベントを削除するには、データ削除を行います。

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

Deep Security Managerのサイジング

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

Agentの数 CPUの数 RAM JVMプロセスメモリ Managerノードの数
< 1000 2 8GB 4GB 2
1000～5000 4 12GB 8GB 2
5000～10000 8 16GB 12GB 2
10000～20000 8 24GB 16GB 2

冗長性を提供し、Managerサービスの可用性を確保するために、2つ以上のManagerノードが推奨されます。同時処理中に十分なパフォーマンスが発揮されるように、Deep Security Managerとデータベースは、同じ物理的な場所の個別の専用サーバにインストールすることを推奨します。

複数のサーバノード

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

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

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