本ヘルプセンターは英語版を翻訳したものです。また、一部には翻訳ソフトウエアにより機械的に翻訳した内容が含まれます。翻訳については順次対応しておりますが、最新の情報になっていない場合があります。最新の情報は英語版のページでご確認ください。表示言語は、画面右上の言語名をクリックして切り替えられます。
本ヘルプセンターの一部の記事には外部リンクが含まれています。リンク切れなどお気づきの点がございましたら、トレンドマイクロサポート窓口までご連絡ください。
Azure Marketplaceのサイジング
Azure MarketplaceのDeep Securityのサイジングガイドラインは、環境の種類やその他の要因 (ネットワーク、ハードウェア、ソフトウェア、アプリケーションなど) によって異なります。
推奨事項は、小規模 (1-10 000)、中規模 (10 000-20 000)、大規模 (20 000+) の環境に分類されています。
Deep Security Manager
Agentの数 | インスタンスの種類 | Deep Security Managerノードの数 |
1 - 10 000 | Standard D2 v2 | 1 - 2 |
10 000 - 20 000 | Standard D3 v2 | 2 |
20 000 + | Standard D12 v2 | 3 |
データベース
初期設定のAzure SQLデータベースはStandard S3 (ストレージサイズは20GB) ですが、Agentの数が10,000を超える場合は、パフォーマンスを高めるためにPremium P1に変更することを推奨します。推奨されるサイズは次のとおりです。
Agentの数 | ハードドライブのサイズ |
1 - 10 000 | 10 - 20GB |
10 000 - 20 000 | 20 - 30 GB |
20 000 + | 30 - 40 GB |
上の表は、Deep Securityデータベースの初期サイズを決定する際の参考にしてください。これらの数字は次の前提に基づいています。
- セキュリティログ監視とWebレピュテーションサービス (WRS) が有効になっていない。
- 侵入防御 (IPS) が有効になっており、誤検出のイベントがほとんどない。
- 不正プログラム対策 (AM) イベントのサイズが無視できるほど小さく、大規模感染が発生しないかぎりイベントがログに記録されることは滅多にない。
- ログの保持期間が30日。
- ファイアウォールイベントが1日あたり約50個。
Azure SQLデータベースのストレージを拡張する方法の詳細については、「 単一データベースリソースのAzure SQLデータベース のスケーリング」を参照してください。
備考
- データベースサイズには、使用中のモジュール、保留中のセキュリティアップデートの数、ポリシーの数などのその他の要因が影響します。一般には、まとめて収集されるファイアウォールイベントと侵入防御イベントのログが、データベースボリュームの大半を占めます。データベースを合理的なサイズに保つには、イベントの保持設定 ([管理]→[システム設定]→[ストレージ]) が役立ちます。これらの設定は必要な容量の決定に役立つため、必ず確認してください。
- 大量のファイアウォールイベントが予想される環境では、「ポリシーで未許可」イベントを無効にすることを検討してください。この設定は、Agentごと、またはベースポリシーレベルで適用できます([コンピュータ] または [ポリシー] 詳細画面を開き、[ファイアウォール]→[詳細] の順に選択します)。
- ログを保持し続けることが厳しい環境では、SIEMサーバやSyslogサーバにログを格納することを検討してください。SIEMまたはSyslogにログを格納すると、Deep Securityデータベースの格納容量が少なくて済みます (外部のSyslogサーバまたはSIEMサーバへのイベントの転送を参照してください)。
- Deep Security ManagerでインポートしたDeep Securityソフトウェアがデータベースサイズに影響することがあります。データベースに保持するソフトウェアバージョンの数を常にチェックし、不要なバージョンを削除するようにしてください。