また、ウイルス対策アップデートは一般的にどのようにテストされていますか？
明らかな理由により、ウイルス対策業界では、テストの技術的な詳細は通常最大7つの封印に保持されます。 インターネットを検索してみてください-これに関する有用な情報はありません。
一方、アップデートのテストは、読者の注目に値する非常に興味深いトピックです。 そして、ここで共有するものがあります。
90年代後半、カスペルスキーは業界でこのプロセスを自動化した最初の企業の1つであり、約15年間絶えず開発を続けてきました。
まず、いくつかの興味深い数字：
- 製品の90を超えるバージョン/アセンブリに対して、120種類を超えるアップデートをリリースしています。
- 79パブリックセット：さまざまなプラットフォーム用のアンチウイルスデータベース、 アンチスパムデータベース、 アンチルートキットデータベース、アンチフィッシング、ペアレンタルコントロール、 BSSベースなど
- テクノロジーパートナー向けの43の特別なベースセット。
パブリックアンチウイルスデータベースは平均2時間ごとにリリースされ、アンチスパムデータベースは最大5分です。 すべてが誤検知（「改ざん」）、損失検出（マルウェアスキップ）、「クラッシュ」、システム負荷、各製品の作業能力、およびその他の多くの基準についてテストされます。
主なものの1つは、「偽造」と損失検出です。 保護の品質はそれらに依存し、このプロセスには特に徹底的に取り組みます。 データベースは、大規模なコレクション（ソフトウェア、曲線、壊れたファイルなど）で自動的にテストされ、通常のコンピューターでは1日かかります。 もちろん、このような贅沢品を購入する余裕はないため、テストは、6時間で80テラバイトのコレクションをスキャンできる独自の分散DDPS（分散データ処理システム）システムの制御下で、特別なコンピューティングクラスターで実行されます。
特定のOSに対する特定の製品のデータベースのパフォーマンスも非常に重要です（非稼働製品で優れたデータベースが必要なのは誰ですか？）。 これらは、サポートされているバージョンとOSのすべての組み合わせがインストールされている仮想マシン上の特別なロボットによってテストされます（Windows、異なるUnix-Linux、MacOS）。 このクラスターには1300を超える仮想マシンがあります。 潜在的に、1300（sic！）の組み合わせを同時にチェックできます。
更新されたモジュールは個別にテストされます（ウイルス対策エンジン、ルートキット対策、スクリプトエミュレーター、IDSなど。これらは20以上のモジュールです）。 これは、モスクワ、サンクトペテルブルク、北京にあるテスターの専任チームの作業です（合計10人）。 プロセスは半自動、つまり ロボットと専門家の両方がタスクに取り組んでいます。
テスト後、「計算キット」が作成され、南極を除くすべての大陸で合計60個を超えるパブリックサーバーにアップロードされます。 コンピューターにインストールされているウイルス対策プログラムも、これらのサーバーから更新プログラムを受け取ります。 ダウンロードは、独自のDRS（Distributed Replication System）を使用して再度行われます。 DRSのおかげで、プロセスは非常に高速で、多くのスレッドで高度な信頼性を備えています。 たとえば、次のような指標があります。これらすべてのサーバーへのレプリケーションの更新には数分しかかかりません。1時間あたり約20回の「計算」を行います。
制御された更新
更新の生産、テスト、および配信のすべてのこのメカニズムで重要なことは何ですか？
更新結果は、他のツール、つまりKSNクラウドシステムによって制御されます。 「バグ」の場合、KSNはユーザーからの最初の信号がテクニカルサポートに届く1時間前（または「バグ」の性質に応じて数時間、場合によっては数日）に問題を通知します。 この技術的特徴により、迅速に対応し、成長する前にいくつかのインシデントを解決することさえできます。
更新をテストするためのインフラストラクチャの総コストは、年間約300万ドルです。 安くはありませんが、これらは非常に重要なコストです-保護の品質、製品の安定性、そして最も重要なことは、ユーザーの意見と快適さはそれらに依存しています。 過去1年間、テストシステムは4つの主要なインシデントと、かなりの数の「偽物」を特定して防止しました。 一般に、インフラストラクチャの開発を継続しますが、これは節約の理由ではありません。
最近、更新を伴う重大なインシデントが2つ発生しました（12月と2月）。 私たちはそれらを徹底的に分析し、結論を出し、すでに組織的および技術的にいくつかの重要な変更を行っています。
まず、クライアント側で問題を引き起こす可能性のある「危険な」更新のリリースのルールを強化しました。制御レベルの向上-各ファイルのすべての操作が登録され、リリースの内容、方法、誰によって、最も重要でないものでもすぐに理解できるようになりましたインフラストラクチャの正常な状態または調査されたインシデントからの逸脱は、更新を停止する可能性があります（したがって、新しいインシデントを防ぎます）。
次に、更新の検証手順に「揮発性」の新しいテストが導入されました。 それらの1つはファイルの特別なコレクションを使用します。スキャン中、製品はアンチウイルスデータベース内の最大量のコードを使用しますが、品質の低いコードは表示される可能性が高くなります。 同時に、クライアント側（ダンプ）の「フォール」に関する情報を収集、記録、帰属、および集約するためのシステムを完成させました。データベース内の単一の「ドロップ」は解消されないため、すべてを調査します。 最初のテストは、手順が非常に効果的であることを示しました。 すでに1つの非常に不快なバグが見つかりました。
第三に、彼らは将来の製品が更新に伴うさまざまな問題に対する耐性を高めるための要件を形成しました。 将来の特許の説明を曖昧にしないために、ここには詳細はありません:-)。
最後に、関係するすべての部門を網羅し、開発者からクライアントへのチェーンに沿った情報フローの最大速度と透明性を保証する新しい企業危機管理手順を開始します。
重要：上記は、今年取り組んでいる改善のほんの一部です。
強力なテストシステムにもかかわらず、エラーが発生し、誰もこれから安全ではありません。 私たちもロボットとマシンガンを制御していますが、私たちは人間です。 人間のエラー しかし、残念ながら（または幸いなことに）完全性に制限はないため、ヒューマナムは各エラーから結論を導き、常に改善することが重要です。
投稿者：Nikolay Grebennikov、CTO Kaspersky Lab