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

Deep Security Manager のサイズ設定

Deep Security Managerのサイジングの推奨値は、エージェントの数によって異なります。
Agentの数
CPUの数
RAM
JVMプロセスメモリ
Managerノードの数
推奨ディスク容量
<500
2
16GB
8 GB
2
200 GB
500~1000
4
16GB
8 GB
2
200 GB
1000~5000
4
16GB
8 GB
2
200 GB
5000~10000
8
16GB
12 GB
2
200 GB
10000~20000
8
24 GB
16GB
2
200 GB
最大限のパフォーマンスを発揮するには、Deep Security Managerプロセスに十分なJava仮想マシン (JVM) メモリを割り当てることが重要です。Deep Security Managerのメモリ使用量の設定を参照してください。
Deep Security Managerの推奨設定の検索はCPU負荷が高くなります。推奨設定の検索を実行する頻度を決定する際には、パフォーマンスへの影響を考慮してください。推奨設定の検索の管理と実行を参照してください。
多数の仮想マシンが同時に再起動され、各AgentがDeep Security Managerとの接続を同時に再確立すると、リソースの使用量が急増する場合があります。

複数のサーバノード

可用性とスケーラビリティを向上させるには、ロードバランサを使用し、2台のサーバ(「ノード」)に同じバージョンのDeep Security Managerをインストールします。これらを同じデータベースに接続します。
各Managerノードがすべてのタスクを実行できます。あるノードが他のノードよりも重要ということはありません。すべてのノードにログインでき、Agent、Appliance、およびRelayはどのノードにも接続できます。1つのノードで障害が発生してもサービスは継続され、データが失われることはありません。
必要となるデータベースのCPU、メモリ、およびディスク容量は、以下の要素によって異なります。

データベースのサイズ設定

最小ディスク容量 = (2 x Deep Securityのデータサイズ) + トランザクションログ
  • 保護されているコンピュータの数
  • Deep Security Agentをインストールするプラットフォームの数
  • 1秒あたりに記録されるイベント (ログ) の数 (有効になっている特定のセキュリティ機能に関連)
  • イベントの保持期間
  • データベーストランザクションログのサイズ
最小ディスク容量 = (2 x Deep Securityのデータサイズ) + トランザクションログ
たとえば、データベースとトランザクションログのサイズが合計40GBの場合は、データベーススキーマをアップグレードする間に80GB (40 x 2) の空きディスク容量が必要です。
ディスクの空き容量を増やすには、使用されていないプラットフォーム用の不要なAgentパッケージ (Deep Securityデータベースからソフトウェアパッケージを削除するを参照)、トランザクションログ、不要なイベントレコードを削除します。
イベントの保持期間は設定可能です。セキュリティイベントの場合、保持期間はポリシー、個々のコンピュータ設定、またはその両方で設定されます。ポリシー、継承、およびオーバーライドログとイベントの保存に関するベストプラクティスを参照してください。
Deep Securityファイアウォールまたは侵入防御機能を使用する、トラフィックの多いコンピュータでは、1秒あたりに記録するイベント数が多くなるため、パフォーマンスの高いデータベースが必要になることがあります。また、ローカルのイベント保持期間の調整も必要になる場合があります。
  • イベントをローカルではなくリモートに保存します。イベントの保持期間を長くする必要がある場合は (コンプライアンスのためなど)、イベントをSIEMまたはSyslogサーバに転送してから、削除機能を使用してローカルコピーを削除します (外部のSyslogサーバまたはSIEMサーバへのDeep Securityイベントの転送を参照)。
    アプリケーションコントロールと変更監視の一部の操作 (ベースラインの再構築、変更の検索、およびインベントリの変更の検索) では、すべてのレコードがローカルに保持され、削除されることも転送されることもありません。
  • 保護されているコンピュータのソフトウェアにパッチを適用します。<em>侵入防御を有効にする前に</em>推奨設定の検索では、脆弱なOSを保護するために、より多くのIPSルールが割り当てられます。セキュリティイベントが増えると、ローカルまたはリモートのディスク使用量が増加します。
  • TCP、UDP、ICMP用のステートフルファイアウォールなど、頻繁にログを記録する不要なセキュリティ機能を無効にします。
Deep Securityファイアウォールまたは侵入防御機能を使用する、トラフィックの多いコンピュータでは、1秒あたりに記録するイベント数が多くなるため、パフォーマンスの高いデータベースが必要になることがあります。また、ローカルのイベント保持期間の調整も必要になる場合があります。
多数のファイアウォールイベントが予想される場合は、許可されたポリシー外のイベントを無効にすることを検討してください。ファイアウォール設定を参照してください。

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

次の表は、デフォルトのイベント保持設定でのデータベースディスク容量を推定しています。有効な保護モジュールの合計ディスク容量が2 or more modulesの値を超える場合は、より小さい推定値を使用してください。例えば、Deep Security不正プログラム対策、侵入防御システム、および変更監視を備えた750エージェントを展開することができます。個々の推奨設定の合計は320 GB (20 GB + 100 GB + 200 GB) ですが、2 or more modulesの推奨設定は300 GBです。したがって、300 GBを推定します。
エージェントの数
不正プログラム対策
WebReputationService
ログインスペクション
ファイアウォール
侵入防止システム
ApplicationControl
整合性モニタリング
2つ以上のモジュール
1~99
10 GB
15 GB
20 GB
20 GB
40GB
50 GB
50 GB
100 GB
100~499
10 GB
15 GB
20 GB
20 GB
40GB
100 GB
100 GB
200 GB
500~999
20 GB
30 GB
50 GB
50 GB
100 GB
200 GB
200 GB
300 GB
1000~9999
50 GB
60 GB
100 GB
100 GB
200 GB
500 GB
400 GB
600 GB
10,000~20,000
100 GB
120 GB
200 GB
200 GB
500 GB
750 GB
750 GB
1 TB
データベースのディスク容量は、個々のDeep Security Agentプラットフォームの数に伴って増加します。たとえば、30のAgent (Agentプラットフォームごとに最大5つのバージョン) がある場合、データベースサイズが約5GB増加します。

Deep Security Agentのサイズとリソース消費

次の表は、一般的に使用される機能の組み合わせを使用した環境でのリソース消費の見積もりを示しています。

Deep Security AgentとRelayのサイズ設定

Deep Security AgentおよびRelayのCPU、RAM、ディスクスペースの割り当てに関する要件については、Deep Security Agentの要件およびDeep Security Relayの要件を参照してください。

推定されるDeep Security Agentのリソース消費量

以下の表は、一般的な機能の組み合わせを使用したデプロイメントの推定RAM消費量を示しています。

Windows Agent

有効なモジュール
RAM
不正プログラム対策
Web Reputation Service
アプリケーションコントロール
Integrity Monitoring
Log Inspection
ファイアウォール
侵入防御
156 MB
148 MB
150 MB
308 MB
280 MB
390 MB
361 MB

Linux Agent

有効なモジュール
RAM
不正プログラム対策
Web Reputation Service
アクティビティ監視
アプリケーションコントロール
Integrity Monitoring
Log Inspection
ファイアウォール
侵入防御
315 MB
172 MB
399 MB
312 MB
448 MB
413 MB
492 MB
538 MB

不正プログラム対策ソリューションプラットフォームサービスのCPUサイズ設定

Deep Securityエージェントは、不正プログラム対策ソリューションプラットフォーム (AMSP) サービスが準備完了したときに自動的にセキュリティアップデートをトリガーします。これは、次のモジュールのうち少なくとも1つが有効になっている場合に発生します:
  • 不正プログラム対策
  • アクティビティ監視
  • アプリケーションコントロール
  • Integrity Monitoring
トレンドマイクロによって実施されたLinux上のエージェントのテストに基づいて、以下のことが結論付けられます:
  • AMSPによる全体のCPU使用率は約10%です。これには、プロセスの作成、ファイル操作、およびネットワーク操作イベントが含まれます。
  • 異なるCPU消費計算方法は、より大きなCPU使用結果をもたらす可能性があるため、コアごとのアプローチ (CPU消費をコア数で割る) を取ることをお勧めします。
以下の表は、共通ポリシー (AM、センサ、WRSなど) を使用したさまざまなVMの組み合わせに対するLinuxエージェントのAMSP CPU消費量とイベント処理能力の詳細なテスト結果を示しています。
OVFファイル
vCPU
vRAM
vCPU: 2
RAM: 4 GB
全体: 23%
コアごとのCPU使用率: 12.5%
毎秒3,523件のイベント、以下を含む:
  • 非同期プロセス: 1秒あたり550
  • 同期プロセス: 1秒あたり280
  • 非同期ファイル: 1秒あたり1,295
  • ファイルの同期: 1,397/秒
  • asyncNetwork: 1.2毎秒
vCPU: 4
RAM: 8 GB
全体: 43%
コアごとのCPU使用率: 10.75%
1秒あたり4,651件のイベント、内訳は以下の通りです:
  • 非同期プロセス: 1秒あたり751
  • 同期プロセス: 1秒あたり377
  • 非同期ファイル: 1,705/秒
  • 同期ファイル: 1,817毎秒
  • asyncNetwork: 1秒あたり0.9
vCPU: 8
RAM: 16 GB
全体: 70%
コアごとのCPU使用率: 8.75%
毎秒5,841イベント、以下を含む:
  • 非同期プロセス: 1秒あたり970
  • 同期プロセス: 1秒あたり485
  • 非同期ファイル: 1秒あたり2,128
  • ファイル同期: 1秒あたり2,257
  • asyncNetwork: 1秒あたり0.9
vCPU: 16
RAM: 32 GB
全体: 127%
コアごとのCPU使用率: 7.9%
毎秒6,275イベント、以下を含む:
  • 非同期プロセス: 1,011/秒
  • 同期プロセス: 1秒あたり505
  • 非同期ファイル: 1秒あたり2,308
  • 同期ファイル: 1秒あたり2,450
  • asyncNetwork: 1秒あたり1
vCPU: 32
RAM: 64 GB
全体: 120%
コアごとのCPU使用率: 3.75%
毎秒4,425件のイベント、内訳は以下の通りです:
  • 非同期プロセス: 1秒あたり749
  • 同期プロセス: 1秒あたり375
  • 非同期ファイル: 1,603毎秒
  • 同期ファイル: 1,697毎秒
  • asyncNetwork: 1秒あたり1
vCPU: 64
RAM: 128 GB
全体: 96%
コアごとのCPU使用率: 1.5%
毎秒4,346イベント、以下を含む:
  • 非同期プロセス: 1秒あたり703
  • 同期プロセス: 1秒あたり352
  • 非同期ファイル: 1秒あたり1,600
  • 同期ファイル: 1,690毎秒
  • asyncNetwork: 1秒あたり1