設計の背景/ Why This Design
この仕組みに至った背景を、ファイル検査の実施・検査エンジン ClamAV・参照アーキテクチャと拡張・設計の三原則の順に説明します。結論から言えば、Google Cloud が公開している公式のリファレンスアーキテクチャに準拠し、業務要件に合わせて必要な部分を拡張しています。
ファイル検査の実施File Inspection
取引先とのファイル共有では、こちらが用意したものだけでなく、相手から受け取るファイルも日常的に扱います。
受領するファイルは、送り主・作成経路・中身が事前には分かりません。従来のメール・FAX・紙の運用を Web アプリに置き換えるにあたって、この「外から入ってくるファイル」を、社内で開いたり別の取引先に渡したりする前に、一度必ず検査する層が必要になります。
そこで、アップロードされたファイルは検査を通過するまで一切流通させない方針としました。検査済み（clean）と確定したものだけを、一覧表示・ダウンロード・プレビュー・共有リンク・Drive 同期の対象にします。これにより、下流のあらゆる機能は「手元にあるのは検査済みのファイルだけ」という前提の上に組み立てられます。
検査エンジン ClamAVThe ClamAV Engine
検査エンジンには ClamAV を採用しました。オープンソース（GPLv2）のアンチウイルスエンジンで、開発は Cisco の脅威インテリジェンス組織 Talos がスポンサーし、検出定義（シグネチャ）を管理しています。
ClamAV は単体のアプリではなく、いくつかの部品の集合です。本プロジェクトで使うのは、常駐して検査を担う
clamd と、検出定義そのものです。定義の更新は ClamAV
標準の freshclam デーモンには任せず、後述の自前ミラー方式で供給しています。
| 構成要素 | 役割（ClamAV の一般的な位置づけ） | 本プロジェクトでの使い方 |
|---|---|---|
clamd | 常駐するマルチスレッドのスキャンデーモン | コンテナ内で常時起動し、ファイルをストリーム（INSTREAM）で流し込んで検査 |
freshclam | 検出定義を自動更新するツール（署名検証つき） | デーモンとしては使わない。定義は自前のミラー経由で 6 時間ごとに取得（→「シグネチャの更新」） |
| main.cvd / daily.cvd / bytecode.cvd | シグネチャ（検出定義）DB。基本／新種／複雑な検出ロジック。いずれもデジタル署名つき | これらを更新して clamd に読み込ませることで、最新の脅威に追従 |
| EICAR | アンチウイルスの動作確認用の標準テストファイル（無害） | 月次で自動投入し、「検出できること」自体を確認（→「隔離と管理」） |
参照：clamav.net（新しいタブで開きます） ／ docs.clamav.net（新しいタブで開きます）
参照アーキテクチャと拡張Reference & Extensions
構成はゼロから発明したものではありません。Google Cloud 公式のアーキテクチャ「Automate malware scanning for files uploaded to Cloud Storage」と、その公式リファレンス実装（GitHub の GoogleCloudPlatform/docker-clamav-malware-scanner・Apache-2.0）に準拠して土台を作り、業務要件に合わせて拡張しています。
GoogleCloudPlatform/docker-clamav-malware-scanner（GitHub・Apache-2.0）（新しいタブで開きます）
参照アーキテクチャの骨格は、①未検査バケットにファイルが届く → ②その到着イベントでスキャン処理が起動 → ③ClamAV で検査 → ④検査済み／隔離バケットへ振り分け、というものです。加えて、検出定義を外部から直接取りに行かずクラウド内のミラー経由で更新する（外部ミラーのレート制限を避ける）点も、この参照設計に含まれています。
| 区分 | 内容 |
|---|---|
| 準拠 Google 公式リファレンス | 未検査バケット → 到着イベント → Cloud Run 上の ClamAV → 検査済み／隔離への振り分け／検出定義をクラウド内ミラー経由で更新（外部レート制限の回避） |
| 拡張 業務要件で追加 | 隔離ファイルの台帳（レジストリ）と取り出し・恒久削除の管理画面／検査済み以外を一般利用者に見せない可視性制御（RLS）／暗号化・上限超過など検証不能ファイルの扱い／再スキャン運用／EICAR 月次テスト／感染時の即時通知 |
参照実装との主な差分として、検出定義の更新間隔は参照実装の 2 時間ごとに対し、本プロジェクトは 6 時間ごととしています（更新頻度と負荷・コストの兼ね合い）。
設計の三原則Design Principles
拡張部分を貫く 3 つの考え方です。各ページで具体的に裏づけます。
- 検査を通るまで流通させない（fail-closed）。 clean と確定するまで、ファイルは一般利用者から見えず、ダウンロードも共有もできません。判定がつかない・失敗した場合も、安全側に倒して止めます。
- 渡す権限は最小に。 検査処理には必要最小限の権限しか渡さず、ファイルの受け渡しは時間を区切った署名付き URL 経由に限定します。隔離バケットの読み取りは、専用のサービスアカウントを通す関門だけに絞っています。
- 危険・疑いは物理的に分離する。 未検査・感染したファイルは、利用者がアクセスするバケットとは別の専用バケットに置き、経路そのものを分けます。