本文へ移動
Signatures

シグネチャの更新/ Signature Updates

ウイルスの検出は、シグネチャ(検出定義)という「既知の脅威の特徴一覧」との照合が基本です。新種は日々現れるため、この定義を止めずに更新し続けることが、検査の品質を保つ生命線になります。その仕組みと、鮮度の見張り方を説明します。

01

検出定義(シグネチャ)の構成Signatures

ClamAV は 3 つの定義ファイルを使います。いずれもデジタル署名つきで、改ざんされていないことを検証してから読み込みます。

定義ファイル内容
main.cvd基本となるマルウェアの検出定義
daily.cvd最近見つかった新種の検出定義(日次で更新される差分)
bytecode.cvd単純な照合では捉えにくい、複雑な検出ロジック

定義が古いままだと、新しい脅威を見逃します。そのため、これらを定期的に取得して clamd に読み込ませ、常に最新に保ちます。

02

シグネチャ更新フローUpdate Flow

更新は 2 段構えです。取得役のジョブが外部から定義を取ってきて自前のミラーに置き、検査役のサービスがそこから受け取って読み込みます。

図 05 · シグネチャ更新フロー — 取得ジョブ・ミラー・検査サービス
Cloud Scheduler定期起動(cron)公式ミラーdatabase.clamav.net(外部・ClamAV 公式)clamav-mirror-updater取得ジョブ(Cloud Run Job)cvdupdate 同梱・CDN 作法どおり取得ミラーバケットシグネチャミラーCloud Storage(GCS)matsuba-scanner6h ごとに pull しclamd に RELOAD(読み直させる)6 時間ごと起動取得アップロード6h pull

起動時にも、matsuba-scanner はまずミラーから定義の取得を試みます(失敗してもコンテナに焼き込んだ定義で検査を続行)。以降は 6 時間ごとに取得し、変化があれば clamd に読み直させます。

03

ミラー経由の更新経路The Mirror Path

検査サービスが公式ミラーを直接叩かず、いったん自前のミラーに置く理由があります。

公式ミラー(database.clamav.net)を各インスタンスから直接、頻繁に取得すると、外向き通信の課金に加えて、公式側のレート制限に触れるリスクがあります。制限に触れると一定時間(最大 24 時間)ブロックされ、その間は定義を更新できません。

そこで、取得は取得役のジョブが 1 回だけ行い、その結果をクラウド内のミラーバケットに置いて、検査サービスはそこから受け取ります。これにより、外部への通信を最小化し、更新経路をクラウド内に閉じられます。この「自前のローカルミラー」方式は、設計の背景で触れた Google 公式リファレンスにも含まれる考え方です。

04

鮮度の監視と失敗検知Freshness

更新は「動いているつもりで止まっている」が最も怖いため、状態を記録して見張ります。

  • 取得のたびに、各定義ファイルのバージョン・サイズ・最終取得時刻・連続失敗回数を記録します。
  • daily.cvd の更新時刻が 一定時間を超えたら「定義が古い」警告を上げます。
  • 取得が 3 回連続で失敗したら、管理者へ警告アラートを上げます。
  • これらの状態は、管理画面(スキャンキュー)で一目で確認できます(→隔離と管理)。
05

EICAR による月次検出テストEICAR Self-Test

定義が最新でも、「検出する仕組みそのもの」が生きているかは別問題です。そこを月に一度、実際に確かめます。

EICAR(eicar.org(新しいタブで開きます))は、アンチウイルスの動作確認のために業界で標準化された無害なテストファイルです(実害はありませんが、すべてのアンチウイルスが「検出する」約束になっています)。月次のジョブ(clamav-eicar-test)がこの EICAR を投入し、きちんと隔離されることを確認します。

もし検出されなければ、それは定義の破損か更新の停止を意味するため、critical(重大)アラートとして管理者に知らせます。さらに、圧縮ファイルの中に入れた EICAR も投入し、アーカイブの内部までスキャンが効いていることも同時に確認します。

「検出できることを、実際に検出させて確かめる」――この定期テストがあることで、定義の更新と検出の仕組みの両方が生きていることを、推測ではなく事実として担保できます。