MetaDefender Cloud
MetaDefender Cloud は、OPSWATクラウドベースの高度な脅威防止およびマルウェア分析プラットフォームです。Deep CDR™テクノロジーと、20以上の最高峰のアンチウイルスエンジンMultiscanning 独自に組み合わせることで、組織をゼロデイ攻撃や高度化するマルウェアから保護します。MetaDefender CloudサンドボックスCloud、OPSWATインテリジェンスデータベースを活用したリアルタイムハッシュ・IP・ドメイン分析と連動し、マルウェア研究者を支援するとともに、既存および潜在的な脅威に対する深い理解を提供します。
MetaDefender Cloud プラットフォームは現在、顧客からの1日あたり500万件以上のスキャン要求をサポートしながら、平均スキャン時間0.4秒を実現しています。
なぜ、MetaDefender as a Service (MDaaS)を開発したのか？
市場の要求に応え、お客様をよりよくサポートするために
私たちは、MetaDefender Cloud 、変化する要件や、高度なアプリケーションセキュリティサービスに対するニーズの高まり、そして、より多くのアプリケーションがクラウドに移行するにつれて複雑化するDevOpsセキュリティに対応できるよう、確実に拡張できるようにしたいと考えていました。ファイルトラフィックの増加に伴い、MetaDefender Cloud エンドカスタマーのスムーズなユーザーエクスペリエンスを保証するために、そのパフォーマンスを維持し、向上させることが必要でした。
モニタリングと予測スケーリングを強化する
私たちは、現在のデプロイとモニタリングのモデルよりもシームレスで一貫したエクスペリエンスを提供できるようにするため、オンプレミスのアーキテクチャを、インフラストラクチャー・アズ・コードによるマイクロサービスをベースとしたクラウドネイティブなKubernetesに移行することにしました。
MetaDefender サービス・アーキテクチャとして
MDaaSへの移行に伴い、Multiscanning サービスはWindowsベースのAMI からKubernetesベースのクラスタに移行しました。管理者はエンジンごとにスケーラビリティを設定できるようになった。エンジンの性能はそれぞれ異なるため、遅いエンジンをスケールアップしてスキャン時間を短縮することができる。
ファイル処理の流れは次のようになる：
1. 外部のリクエスト送信者からのメッセージが、「request」というKafkaトピック (1) に送信されます。このメッセージには、AV1やAV2などを使用してファイルをスキャンする、Deep CDR™テクノロジーを使用してファイルをクリーンアップする、Sandbox を使用してファイルを分析する、といったリクエストの指示が含まれています。
2. その後、メッセージの受信を購読しているLambdaエクストラクタ（2）が、リクエストをいくつかの異なるコマンドに分割し、それらを別のKafkaトピック（3）に送信します。そこでコマンドは分類され、関連するエンジン（複数可）に割り当てられます。（4）
3. エンジン処理（4）は、システムの核となる部分です。これには複数のエンジンコンテナが含まれており、Amazon Elastic Kubernetes Service（EKS）上で実行され、ワークロードに応じてスケールインまたはスケールアウトする機能を備えています。各エンジンは特定のリクエストを処理し、処理パフォーマンスを向上させます。
4. この処理の過程では、入力ファイルと出力ファイルを保存するために、S3バケット（5）も使用されます。
5. 同時に、利用可能なログ処理モジュール（6）がエンジンからログを受信し、それをログ分析システムに送信する。
6. ファイル処理が完了すると、各エンジンから得られた結果が「results」というKafkaトピック（7）に返されます。
7. その後、AWS Lambda を利用したマイクロサービス・アグリゲーター（8）が、結果を1つのレポートにまとめ、Kafkaトピック（9）に送信し、リクエスト元へ返します。
技術的課題と解決策
エンジンの挙動予測と異常への対応
従来のMDCore AMI デプロイメントでは、エンジンは強力なコンピューター上で動作し、互いにリソース（CPU、RAM、ディスク、ネットワークなど）を共有できる。しかし、マイクロサービス・アーキテクチャでは、各エンジンはそれほど強力ではないコンテナ内で個別に動作する。そのため、このケースでシステムのリソース要件を定義するのは困難だった。
この問題に対処するため、旧システムの履歴データを使用して各エンジンのベースラインを設定し、Datadogのモニタリングを追加しました。私たちは、製品が優れたパフォーマンスを達成するまで、エンジンの動作を監視し、インフラを微調整し続けました。
パフォーマンスとホスティングコストのバランスを保つ
新しいアーキテクチャにより、MetaDefender Cloud 顧客の無限のニーズに適応し、最適なレベルで実行できるように簡単に拡張できるようになりました。とはいえ、それはメンテナンスコストが比例して急増する可能性があることも意味していました。支出のチェックやガバナンスモデルがなければ、スケーリングは制御不能となり、当初割り当てられた予算をはるかに超えるクラウドサービスの請求額の増加につながる可能性がありました。
そのため、安定したバランスの取れたコストで一貫した経験を保証するため、利害関係者との頻繁な建築レビューが行われた。
環境シミュレーション
本番環境での負荷を、実データを持たない非本番環境でシミュレートすることは困難です。この問題に対処するため、私たちは並列ワークフローを設定し、実データが新旧両方のアーキテクチャを通過するようにしました。このような比較により、新アーキテクチャが旧アーキテクチャより優れている部分と、新アーキテクチャの改善が必要な部分を迅速かつ効果的に特定することができました。
モニタリング、レポーティング、コントロール
クラウドインフラのリアルタイム監視
MetaDefender Cloud 、システムの健全性を明確に把握するために、システムに堅牢なモニタリングを組み込むことに重点を置いています。MDaaSのようなサービスは、0.6%のエラー率で1秒間に44以上のリクエスト（RPS）を処理し、トラフィックソースとして複数の上流システムやパートナーのエコシステムに依存し、同時にさまざまな内部および外部の下流システムに対して大量のトラフィックを生成します。
Datadogの環境別高異常トラフィックに関するアラート
CPU、メモリ、パフォーマンスなどの標準的なシステム健全性メトリクスに加え、キュー内の成長、サービスの応答時間、ステータスケイク、上流または下流のシステムからの異常を捕捉するためのロギングなど、いくつかの「エッジ・オブ・サービス」メトリクスを追加しました。さらに、重要なメトリクスのトレンド分析を追加し、長期的なデグレードを捕捉できるようにしました。Datadogと呼ばれるリアルタイム・ストリーム処理アプリケーションでMDaaSを計測しました。Datadogを使用することで、コンテナ単位でリアルタイムにイベントを追跡することができ、デバッグが容易になりました。最後に、問題の根本原因をより早く特定するために、サービス固有のアラートを出すことが有用であることがわかりました。
Datadogでサイト信頼性エンジニアの注意を必要とする例外に関するインシデントを作成する。
DatadogプラットフォームによるSaaSモニタリングにより、チームはより迅速かつ容易に導入することができ、継続的なツールのメンテナンス、容量の拡張、更新、管理が不要になります。これらのメリットは、チームがコア製品に取り組む時間が増え、モニタリング・ソリューションを独自に作成する必要がなくなることを意味します。
成果
• MDaaSへの移行により、エンジン・マイクロサービスはより柔軟になり、FedRAMPの「中程度」ベースラインのセキュリティ管理要件を満たしやすくなりました。
• アプリケーションのパフォーマンス監視機能が、リアルタイムのアラート機能やダッシュボードにより強化されました。新しいマイクロサービスアーキテクチャにより、管理者はアプリケーションおよび各コンポーネントを簡単かつ効果的に監視できるようになりました。また、導入やスケーラビリティも容易になります。
• インフラストラクチャが「コードとして定義される」限り、ユーザーはインフラストラクチャの望ましい状態を確保しつつ、設定を容易に編集・配布することができます。つまり、再現性のあるインフラストラクチャ構成を作成できるということです。
詳細については MetaDefender Cloud 、または詳細についてはお問い合わせください。
