従来のウイルス対策がパブリック クラウドに適さない理由。 それで、どうすればいいでしょうか？

IT インフラストラクチャ全体をパブリック クラウドに導入するユーザーがますます増えています。 しかし、お客様のインフラストラクチャのウイルス対策管理が不十分な場合、重大なサイバーリスクが発生します。 実際には、既存のウイルスの最大 80% が仮想環境内で完全に生存していることがわかっています。 この記事では、パブリック クラウドで IT リソースを保護する方法と、従来のウイルス対策がこれらの目的に完全に適していない理由について説明します。

まず、通常のウイルス対策保護ツールはパブリック クラウドには適しておらず、リソースを保護するには別のアプローチが必要であるという考えにどのようにして至ったのかを説明します。

まず、プロバイダーは通常、クラウド プラットフォームが高レベルで保護されるようにするために必要な措置を提供します。 たとえば、#CloudMTS では、すべてのネットワーク トラフィックを分析し、クラウドのセキュリティ システムのログを監視し、侵入テストを定期的に実行しています。 個々のクライアントに割り当てられたクラウド セグメントも安全に保護する必要があります。

次に、サイバー リスクに対処するための古典的なオプションには、各仮想マシンにウイルス対策ツールとウイルス対策管理ツールをインストールすることが含まれます。 ただし、仮想マシンの数が多い場合、この方法は効果がなく、大量のコンピューティング リソースを必要とするため、顧客のインフラストラクチャにさらに負荷がかかり、クラウドの全体的なパフォーマンスが低下する可能性があります。 これは、顧客の仮想マシンに対する効果的なウイルス対策保護を構築するための新しいアプローチを模索するための重要な前提条件となっています。

さらに、市場に出回っているほとんどのウイルス対策ソリューションは、パブリック クラウド環境での IT リソースの保護の問題を解決するようには適応されていません。 原則として、これらは重量級の EPP ソリューション (エンドポイント保護プラットフォーム) であり、さらに、クラウド プロバイダーのクライアント側で必要なカスタマイズを提供しません。

従来のウイルス対策ソリューションは、更新やスキャン中に仮想インフラストラクチャに深刻な負荷をかけ、必要なレベルの役割ベースの管理や設定も備えていないため、クラウドでの作業にはあまり適していないことが明らかです。 次に、クラウドにウイルス対策保護に対する新しいアプローチが必要な理由を詳しく分析します。

パブリック クラウドのウイルス対策ツールでできること

それでは、仮想環境での作業の詳細に注目してみましょう。

アップデートとスケジュールされた一括スキャンの効率。 従来のウイルス対策ソフトウェアを使用している多数の仮想マシンが同時に更新を開始すると、いわゆる「嵐」のような更新がクラウドで発生します。 複数の仮想マシンをホストする ESXi ホストの能力は、デフォルトで実行される同様のタスクの集中処理を処理するには十分ではない可能性があります。 クラウド プロバイダーの観点から見ると、このような問題は多くの ESXi ホストにさらなる負荷を与える可能性があり、最終的にはクラウド仮想インフラストラクチャのパフォーマンスの低下につながります。 これは、他のクラウド クライアントの仮想マシンのパフォーマンスに影響を与える可能性があります。 一括スキャンを開始するときにも同様の状況が発生する可能性があります。異なるユーザーからの多数の同様のリクエストをディスク システムが同時に処理すると、クラウド全体のパフォーマンスに悪影響を及ぼします。 ストレージ システムのパフォーマンスの低下は、高い確率ですべてのクライアントに影響します。 このような突然の負荷は、クラウド内の「近隣」に影響を与えるため、プロバイダーにとっても顧客にとっても好ましくありません。 この観点から見ると、従来のウイルス対策ソフトウェアは大きな問題を引き起こす可能性があります。

安全な隔離。 ウイルスに感染している可能性のあるファイルまたはドキュメントがシステム上で検出された場合、それは隔離に送られます。 もちろん、感染したファイルはすぐに削除できますが、これはほとんどの企業にとって受け入れられないことがよくあります。 プロバイダーのクラウドでの動作に適応していない企業向けウイルス対策製品には、原則として共通の隔離ゾーンがあり、感染したオブジェクトはすべてそこに分類されます。 たとえば、企業ユーザーのコンピュータにあるものなどです。 クラウド プロバイダーのクライアントは、独自のセグメント (またはテナント) に「存在」します。 これらのセグメントは不透明で孤立しています。クライアントはお互いのことを知りませんし、もちろん、クラウドで他のクライアントが何をホストしているのかも知りません。 明らかに、クラウド内のすべてのウイルス対策ユーザーがアクセスする一般的な隔離には、機密情報や企業秘密を含む文書が含まれる可能性があります。 これはプロバイダーとその顧客にとって容認できないことです。 したがって、解決策は XNUMX つしかありません。それは、プロバイダーも他のクライアントもアクセスできない、セグメント内の各クライアントの個人隔離です。

個別のセキュリティ ポリシー。 クラウド内の各クライアントは別個の会社であり、その IT 部門は独自のセキュリティ ポリシーを設定します。 たとえば、管理者はスキャン ルールを定義し、ウイルス対策スキャンをスケジュールします。 したがって、ウイルス対策ポリシーを構成するには、各組織が独自のコントロール センターを用意する必要があります。 同時に、指定された設定は他のクラウド クライアントに影響を与えてはならず、プロバイダーは、たとえばウイルス対策の更新がすべてのクライアント仮想マシンに対して通常どおり実行されることを確認できる必要があります。

請求とライセンスの構成。 クラウド モデルは柔軟性が特徴で、料金は顧客が使用した IT リソースの量に対してのみ発生します。 たとえば、季節性などにより必要性がある場合、リソースの量は、現在のコンピューティング能力のニーズに基づいて、すぐに増減できます。 従来のウイルス対策はそれほど柔軟性がありません。原則として、クライアントは、あらかじめ決められた数のサーバーまたはワークステーションに対して XNUMX 年間のライセンスを購入します。 クラウド ユーザーは、現在のニーズに応じて追加の仮想マシンを定期的に切断したり接続したりするため、ウイルス対策ライセンスは同じモデルをサポートする必要があります。

XNUMX 番目の質問は、ライセンスが具体的に何をカバーするのかということです。 従来のウイルス対策は、サーバーまたはワークステーションの数に応じてライセンスが付与されます。 保護された仮想マシンの数に基づくライセンスは、クラウド モデル内には完全に適しているわけではありません。 クライアントは、利用可能なリソースから都合のよい数の仮想マシン (たとえば、XNUMX 台または XNUMX 台のマシン) を作成できます。 この数値はほとんどのクライアントにとって一定ではなく、プロバイダーとしてその変化を追跡することはできません。 CPU ごとにライセンスを取得する技術的な可能性はありません。クライアントは仮想プロセッサ (vCPU) を受け取り、これをライセンスに使用する必要があります。 したがって、新しいウイルス対策保護モデルには、ウイルス対策ライセンスを受け取るために必要な vCPU の数を顧客が決定できる機能が含まれている必要があります。

法令の遵守。 使用されるソリューションは規制当局の要件に確実に準拠する必要があるため、これは重要な点です。 たとえば、クラウドの「常駐者」は個人データを扱うことがよくあります。 この場合、プロバイダーは、個人データ法の要件に完全に準拠する、認定されたクラウド セグメントを別に持つ必要があります。 そうすれば、企業は個人データを扱うためのシステム全体を独自に「構築」する必要がなくなります。認定された機器を購入し、接続して構成し、認定を受ける必要があります。 このようなクライアントの ISPD をサイバー保護するために、ウイルス対策ソフトウェアはロシアの法律の要件にも準拠し、FSTEC 証明書を取得している必要があります。

パブリック クラウドのウイルス対策保護が満たさなければならない必須の基準を検討しました。 次に、プロバイダーのクラウドで動作するようにウイルス対策ソリューションを適応させた私たち自身の経験を共有します。

どうすればウイルス対策とクラウドを仲良くできるでしょうか?

私たちの経験が示しているように、説明とドキュメントに基づいてソリューションを選択することは別のことですが、すでに稼働しているクラウド環境にそれを実際に実装することは、複雑さの点でまったく別のタスクになります。 私たちが実際に何を行ったか、そしてプロバイダーのパブリック クラウドで動作するようにウイルス対策ソフトウェアをどのように適応させたかについて説明します。 ウイルス対策ソリューションのベンダーは Kaspersky で、そのポートフォリオにはクラウド環境向けのウイルス対策保護ソリューションが含まれています。 私たちは「Kaspersky Security for Virtualization」（ライトエージェント）に落ち着きました。

これには、単一の Kaspersky Security Center コンソールが含まれています。 ライト エージェントとセキュリティ仮想マシン (SVM、セキュリティ仮想マシン)、および KSC 統合サーバー。

カスペルスキー ソリューションのアーキテクチャを研究し、ベンダーのエンジニアと一緒に最初のテストを実施した後、サービスをクラウドに統合するかどうかという疑問が生じました。 最初の実装はモスクワのクラウド サイトで共同で実施されました。 そしてそれが私たちが気づいたことです。

ネットワーク トラフィックを最小限に抑えるために、各 ESXi ホストに SVM を配置し、SVM を ESXi ホストに「結び付ける」ことが決定されました。 この場合、保護された仮想マシンのライト エージェントは、それらが実行されている正確な ESXi ホストの SVM にアクセスします。 メイン KSC には別の管理テナントが選択されました。 その結果、下位 KSC は各クライアントのテナントに配置され、管理セグメントに配置された上位 KSC に対応します。 このスキームにより、クライアント テナントで発生した問題を迅速に解決できます。

ウイルス対策ソリューション自体のコンポーネントを増やすという問題に加えて、追加の VxLAN の作成を通じてネットワーク相互作用を組織するという課題にも直面しました。 このソリューションはもともとプライベート クラウドを使用する企業クライアントを対象としていましたが、NSX Edge のエンジニアリングの知識と技術的な柔軟性のおかげで、テナントとライセンスの分離に関連するすべての問題を解決することができました。

私たちはカスペルスキーのエンジニアと緊密に連携しました。 したがって、システム コンポーネント間のネットワーク相互作用の観点からソリューション アーキテクチャを分析する過程で、ライト エージェントから SVM へのアクセスに加えて、SVM からライト エージェントへのフィードバックも必要であることがわかりました。 異なるクラウド テナントの仮想マシンのネットワーク設定が同一になる可能性があるため、マルチテナント環境ではこのネットワーク接続は不可能です。 したがって、私たちの要求に応じて、ベンダーの同僚は、SVM からライト エージェントへのネットワーク接続の必要性を排除するという観点から、ライト エージェントと SVM の間のネットワーク相互作用のメカニズムを作り直しました。

ソリューションをモスクワのクラウド サイトに展開してテストした後、認定されたクラウド セグメントを含む他のサイトにソリューションを複製しました。 このサービスは現在、国内のすべての地域で利用可能です。

新しいアプローチの枠組みにおける情報セキュリティ ソリューションのアーキテクチャ

パブリック クラウド環境におけるウイルス対策ソリューションの一般的な運用スキームは次のとおりです。

パブリッククラウド環境におけるウイルス対策ソリューションの運用スキーム #CloudMTS

クラウドにおけるソリューションの個々の要素の動作の特徴を説明しましょう。

• 単一のコンソールにより、クライアントはスキャンの実行、更新の制御、隔離ゾーンの監視など、保護システムを集中管理できます。 セグメント内で個別のセキュリティ ポリシーを構成することが可能です。

当社はサービスプロバイダーではありますが、クライアントが設定した設定には干渉しません。 再構成が必要な場合は、セキュリティ ポリシーを標準のポリシーにリセットするしかありません。 たとえば、クライアントが誤って締め付けたり、著しく弱めたりした場合に、これが必要になる場合があります。 企業は、デフォルトのポリシーを備えたコントロール センターをいつでも受け取ることができ、個別に構成できます。 Kaspersky Security Center の欠点は、このプラットフォームが現在 Microsoft オペレーティング システムでのみ利用できることです。 ただし、軽量エージェントは Windows マシンと Linux マシンの両方で動作します。 ただし、Kaspersky Lab は、近い将来、KSC が Linux OS 上で動作することを約束しています。 KSC の重要な機能の XNUMX つは、隔離を管理する機能です。 私たちのクラウド内の各クライアント企業は、個人用のクラウドを持っています。 このアプローチにより、一般的な隔離機能を備えた従来の企業向けウイルス対策製品の場合に発生する可能性のある、ウイルスに感染したドキュメントが誤って一般公開される状況が排除されます。

• ライトエージェント。 新しいモデルの一部として、軽量の Kaspersky Security エージェントが各仮想マシンにインストールされます。 これにより、各 VM にウイルス対策データベースを保存する必要がなくなり、必要なディスク容量が削減されます。 このサービスはクラウド インフラストラクチャと統合されており、SVM を通じて動作します。これにより、ESXi ホスト上の仮想マシンの密度が向上し、クラウド システム全体のパフォーマンスが向上します。 ライト エージェントは、各仮想マシンのタスクのキューを構築します。ファイル システム、メモリなどをチェックします。 ただし、SVM はこれらの操作を実行する責任があります。これについては後で説明します。 このエージェントはファイアウォールとしても機能し、セキュリティ ポリシーを制御し、感染ファイルを隔離に送信し、エージェントがインストールされているオペレーティング システム全体の「健全性」を監視します。 これらすべては、すでに述べた単一のコンソールを使用して管理できます。

• セキュリティ仮想マシン。 リソースを大量に消費するすべてのタスク（ウイルス対策データベースの更新、スケジュールされたスキャン）は、別のセキュリティ仮想マシン（SVM）によって処理されます。 彼女は、本格的なウイルス対策エンジンとそのデータベースの運用を担当しています。 企業の IT インフラストラクチャには、複数の SVM が含まれる場合があります。 このアプローチにより、システムの信頼性が向上します。XNUMX 台のマシンに障害が発生して XNUMX 秒間応答しない場合、エージェントは自動的に別のマシンを探し始めます。

• KSC 統合サーバー。 メイン KSC のコンポーネントの XNUMX つ。設定で指定されたアルゴリズムに従って SVM をライト エージェントに割り当て、SVM の可用性も制御します。 したがって、このソフトウェア モジュールは、クラウド インフラストラクチャのすべての SVM にわたる負荷分散を提供します。

クラウドで作業するためのアルゴリズム: インフラストラクチャの負荷を軽減する

一般に、ウイルス対策アルゴリズムは次のように表すことができます。 エージェントは仮想マシン上のファイルにアクセスしてチェックします。 検証の結果は、共通の集中型 SVM 判定データベース (共有キャッシュと呼ばれる) に保存され、各エントリは一意のファイル サンプルを識別します。 このアプローチにより、同じファイルが連続して複数回スキャンされることを確実に防ぐことができます (たとえば、ファイルが別の仮想マシンで開かれた場合など)。 ファイルが再スキャンされるのは、ファイルに変更が加えられた場合、またはスキャンが手動で開始された場合のみです。

プロバイダーのクラウドへのウイルス対策ソリューションの実装

この画像は、クラウドでのソリューション実装の一般的な図を示しています。 メインの Kaspersky Security Center はクラウドのコントロール ゾーンに展開され、個別の SVM は KSC 統合サーバーを使用して各 ESXi ホストに展開されます (各 ESXi ホストには、VMware vCenter Server 上の特別な設定で接続された独自の SVM があります)。 クライアントは、エージェントを備えた仮想マシンが配置されている独自のクラウド セグメントで作業します。 これらは、メイン KSC に従属する個々の KSC サーバーを通じて管理されます。 少数の仮想マシン (最大 5 台) を保護する必要がある場合は、クライアントに特別な専用 KSC サーバーの仮想コンソールへのアクセスを提供できます。 クライアント KSC とメイン KSC、およびライト エージェントと SVM の間のネットワーク対話は、EdgeGW クライアント仮想ルーターを介して NAT を使用して実行されます。

私たちの推定とベンダーの同僚によるテストの結果によると、Light Agent はクライアントの仮想インフラストラクチャの負荷を約 25% 削減します (従来のウイルス対策ソフトウェアを使用したシステムと比較した場合)。 特に、物理環境用の標準の Kaspersky Endpoint Security (KES) アンチウイルスは、軽量のエージェントベースの仮想化ソリューション (2,95%) のほぼ 1,67 倍のサーバー CPU 時間 (XNUMX%) を消費します。

CPU負荷比較表

ディスク書き込みアクセスの頻度でも同様の状況が観察されます。従来のウイルス対策では 1011 IOPS、クラウド ウイルス対策では 671 IOPS です。

ディスクアクセス速度比較グラフ

パフォーマンス上の利点により、インフラストラクチャの安定性を維持し、コンピューティング能力をより効率的に使用できるようになります。 このソリューションはパブリック クラウド環境での作業に適応することで、クラウドのパフォーマンスを低下させません。ファイルを一元的にチェックして更新をダウンロードし、負荷を分散します。 これは、クラウド インフラストラクチャに関連する脅威を見逃さない一方で、仮想マシンのリソース要件が従来のウイルス対策製品と比較して平均 25% 削減されることを意味します。

機能の点では、両方のソリューションは互いに非常に似ています。以下に比較表を示します。 ただし、上記のテスト結果が示すように、クラウドでは、仮想環境用のソリューションを使用することが依然として最適です。

新しいアプローチの枠組みにおける関税について。 vCPU の数に基づいてライセンスを取得できるモデルを使用することにしました。 これは、ライセンスの数が vCPU の数と同じになることを意味します。 リクエストを残すことでウイルス対策をテストできます オンライン.

クラウド トピックに関する次の記事では、クラウド WAF の進化と、ハードウェア、ソフトウェア、クラウドのどれを選択するのが良いかについて説明します。

このテキストは、クラウド プロバイダー #CloudMTS の従業員、主力アーキテクトのデニス・ミャグコフ氏と情報セキュリティ製品開発マネージャーのアレクセイ・アファナシエフ氏によって作成されました。

出所： habr.com