本ヘルプセンターは英語版を翻訳したものです。また、一部には翻訳ソフトウエアにより機械的に翻訳した内容が含まれます。翻訳については順次対応しておりますが、最新の情報になっていない場合があります。最新の情報は英語版のページでご確認ください。表示言語は、画面右上の言語名をクリックして切り替えられます。

本ヘルプセンターの一部の記事には外部リンクが含まれています。万一リンク切れなどお気づきの点がございましたら、お手数ですが弊社サポート窓口までご連絡ください。

サイジング

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

Deep Security Managerのサイジング

Deep Security Managerのサイジングの推奨値は、エージェントの数によって異なります。

最大限のパフォーマンスを発揮するには、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サーバに転送してから、削除機能を使用してローカルコピーを削除します(Deep SecurityイベントをSyslogまたはSIEMサーバに転送するを参照)。

    アプリケーションコントロールと変更監視の一部の操作 (ベースラインの再構築、変更の検索、およびインベントリの変更の検索) では、すべてのレコードがローカルに保持され、削除されることも転送されることもありません。

  • 侵入防御を有効にする前に、保護されているコンピュータのソフトウェアにパッチを適用します。推奨設定の検索では、脆弱な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と見積もることになります。

データベースのディスク容量は、個々の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 リソース消費量

「Deep Security Virtual Applianceのメモリ割り当て」も参照してください。

Windowsエージェント

有効なモジュール RAM
不正プログラム対策 Webレピュテーションサービス アクティビティ監視 アプリケーションコントロール 変更監視 セキュリティログ監視 ファイアウォール 侵入防御
✔ 156 MB
✔ 148 MB
✔ ✔ ✔ 150 MB
✔ ✔ ✔ ✔ 308 MB
✔ ✔ ✔ ✔ 280 MB
✔ ✔ ✔ ✔ ✔ ✔ ✔ 390 MB
✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ 361 MB

Linuxエージェント

有効なモジュール RAM
不正プログラム対策 Webレピュテーションサービス アクティビティ監視 アプリケーションコントロール 変更監視 セキュリティログ監視 ファイアウォール 侵入防御
✔ 315 MB
✔ ✔ 172 MB
✔ ✔ 399 MB
✔ ✔ ✔ 312 MB
✔ ✔ ✔ ✔ 448 MB
✔ ✔ ✔ ✔ 413 MB
✔ ✔ ✔ ✔ ✔ ✔ 492 MB
✔ ✔ ✔ ✔ ✔ ✔ ✔ 538 MB

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

DPDKモードを有効にするには、DPDKモードを設定してください。

  • 不正プログラム対策
  • アクティビティ監視
  • アプリケーションコントロール
  • 変更監視

Applianceが多数の仮想マシンを保護していて、タイムアウトエラーにより推奨設定の検索が失敗する場合は、推奨設定の検索の管理と実行を参照してタイムアウト値を大きくしてください。

  • AMSPによる全体的なCPU使用率は約10％です。これには、プロセスの作成、ファイル操作、およびネットワーク操作イベントが含まれます。
  • 異なるCPU消費計算方法はより大きなCPU使用結果をもたらす可能性があるため、コアごとのアプローチ（CPU消費をコア数で割る）を取ることをお勧めします。

次の表は、さまざまなVMの組み合わせに対するLinuxエージェントのAMSP CPU消費量とイベント処理能力の詳細なテスト結果を提供します。すべて共通のポリシー（AM、SENSOR、WRSなど）を使用しています。

OVFファイル vCPU vRAM

vCPU: 2

RAM: 4 GB

全体: 23%

コアごとのCPU使用率: 12.5%

1秒あたり3,523件のイベント、内訳は次のとおりです:

  • 非同期プロセス: 1秒あたり550
  • 同期プロセス: 1秒あたり280
  • 非同期ファイル: 1,295毎秒
  • ファイル同期: 1,397/秒
  • asyncNetwork: 1.2 per second

vCPU: 4

RAM: 8 GB

全体: 43%

コアごとのCPU使用率: 10.75%

1秒あたり4,651件のイベント、内訳は次のとおりです:

  • 非同期プロセス: 751/秒
  • 同期プロセス: 1秒あたり377
  • 非同期ファイル: 1,705毎秒
  • ファイル同期: 1,817/秒
  • asyncNetwork: 1秒あたり0.9

vCPU: 8

RAM: 16 GB

全体: 70%

コアごとのCPU使用率: 8.75%

1秒あたり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%

1秒あたり6,275件のイベント、内訳は以下の通り:

  • 非同期プロセス: 1,011/秒
  • 同期プロセス: 1秒あたり505
  • 非同期ファイル: 1秒あたり2,308
  • ファイルを同期: 1秒あたり2,450
  • asyncNetwork: 1 per second

vCPU: 32

RAM: 64 GB

全体: 120%

コアごとのCPU使用率: 3.75%

1秒あたり4,425件のイベント、内訳は以下の通りです:

  • 非同期プロセス: 749/秒
  • 同期プロセス: 1秒あたり375
  • 非同期ファイル: 1,603毎秒
  • ファイル同期: 1,697/秒
  • asyncNetwork: 1 per second

vCPU: 64

RAM: 128 GB

全体: 96%

コアごとのCPU使用率: 1.5%

1秒あたり4,346件のイベント、内訳は以下の通りです:

  • 非同期プロセス: 703毎秒
  • 同期プロセス: 1秒あたり352
  • 非同期ファイル: 1,600毎秒
  • ファイル同期: 1,690/秒
  • asyncNetwork: 1 per second