Deep Securityの配置のサイジングのガイドラインは、ネットワーク、ハードウェア、およびソフトウェアの規模によって異なります。Azure Marketplaceのサイジングも参照してください。
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のデータサイズ) + トランザクションログ
-
保護されているコンピュータの数
-
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秒あたりに記録するイベント数が多くなるため、パフォーマンスの高いデータベースが必要になることがあります。また、ローカルのイベント保持期間の調整も必要になる場合があります。
多数のファイアウォールイベントが予想される場合は、許可されたポリシー外のイベントを無効にすることを検討してください。ファイアウォール設定を参照してください。
Deep Security Managerのパフォーマンス機能も参照してください。
データベースのディスク容量の推定
次の表は、デフォルトのイベント保持設定でのデータベースディスク容量を推定しています。有効な保護モジュールの合計ディスク容量が
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件のイベント、以下を含む:
|
|
vCPU: 4
RAM: 8 GB
|
全体: 43%
コアごとのCPU使用率: 10.75%
|
1秒あたり4,651件のイベント、内訳は以下の通りです:
|
|
vCPU: 8
RAM: 16 GB
|
全体: 70%
コアごとのCPU使用率: 8.75%
|
毎秒5,841イベント、以下を含む:
|
|
vCPU: 16
RAM: 32 GB
|
全体: 127%
コアごとのCPU使用率: 7.9%
|
毎秒6,275イベント、以下を含む:
|
|
vCPU: 32
RAM: 64 GB
|
全体: 120%
コアごとのCPU使用率: 3.75%
|
毎秒4,425件のイベント、内訳は以下の通りです:
|
|
vCPU: 64
RAM: 128 GB
|
全体: 96%
コアごとのCPU使用率: 1.5%
|
毎秒4,346イベント、以下を含む:
|