LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

OpenVASとGreenbone Community Editionの基本構成

OpenVAS（Greenbone Community Editionが提供する脆弱性スキャンエンジン）とは、ネットワーク上のホストやサービスに対して既知の脆弱性を検査するオープンソースのスキャンエンジンを指します^*1。無償のCommunity Feedを使えば費用をかけずに継続的な脆弱性スキャンを自社運用できる一方、構築・運用には相応の技術知識が必要になります。

Greenbone Vulnerability Management（GVM、脆弱性管理フレームワークの名称）は、Web画面のGreenbone Security Assistant（GSA）、中核デーモンのgvmd、スキャナ制御を担うospd-openvas、実際にスキャンを実行するopenvas-scannerという複数コンポーネントで構成されます^*1。gvmdはPostgreSQLデータベースを使い、スキャン設定・スケジュール・結果を一元管理します^*1。

名称の経緯を整理すると理解しやすくなります。2006年にNessusのオープンソース版フォークとしてOpenVASが生まれ、2008年にGreenbone AGが開発を主導し始めました^*2。2017年にフレームワーク全体を「Greenbone Vulnerability Management（GVM）」と改称し、2022年に無償版の呼称を「Greenbone Community Edition」に統一しています^*2。現在の資料では「OpenVAS」はスキャンエンジン単体を指す名称として使われる場面が多く、混同を避けるため呼び分けを意識する必要があります。

スキャンエンジンの仕組み — NVTとフィード更新

OpenVASのスキャンは、NVT（Network Vulnerability Test、個別の脆弱性検査ロジック）と呼ばれる検査項目の集合を対象ホストに適用する形で行われます^*1。NVTは日々新規・更新分が追加されるため、スキャン精度を保つには継続的なフィード更新が欠かせません。

フィードには無償のGreenbone Community Feed（GCF）と商用のGreenbone Enterprise Feed（旧称Security Feed、GSF）の2種類があります^*3。Community Feedは一般的な製品（OS・主要ソフトウェア）の脆弱性検査を提供しますが、Enterprise Feedはシスコ製品やMicrosoft Exchangeなどエンタープライズ製品向けの検査やCISベンチマーク準拠ガイドラインを追加で含み、更新頻度も1日複数回に拡張されます^*3。EPSS（脆弱性の悪用可能性を示すスコア）との統合もEnterprise Feed側の機能です^*3。

フィードの取得には公式ツール「greenbone-feed-sync」を使い、NVT・SCAPデータ・レポートフォーマットなどの種別を指定して同期します^*4。Community Feedは接続元IPアドレスごとの同時接続数や帯域に制限が設けられており、過度な頻度での再同期はサーバー負荷を理由に制限されている点に注意が必要です^*5。フィード同期が失敗すると検査項目が古いまま固定され、スキャン結果が実態を反映しなくなるリスクがあります。

構築の流れ — コンテナ導入からスキャン設定まで

Greenbone Community Editionの構築は、公式が提供するDocker Composeベースのコンテナ構成を使う方法が主流です^*6。構成にはpg-gvm（PostgreSQL）、gvmd、gsa、ospd-openvas、Redis、各種フィードデータコンテナが含まれ、これらを個別にビルドせずに公式イメージを組み合わせて起動します^*6。

初回起動時にはgvmdコマンドで管理者パスワードを設定する初期化作業が必要です^*6。GSA（Web画面）は初期状態でlocalhostのみにバインドされるため、社内ネットワークから利用する場合はリバースプロキシやSSHトンネルなど、アクセス経路の設計をあわせて行う必要があります^*6。

構築後の初期設定では、スキャン対象ホスト（Target）の登録、使用するスキャン設定（Scan Config、検査するNVTの範囲を定義したテンプレート）の選定、実行するスキャナの指定という3点を組み合わせてタスクを作成します。ネットワーク構成やファイアウォールの設定によっては、スキャナからスキャン対象への到達性を個別に確認する作業も欠かせません。

スキャン設定・スケジュール・レポートの運用実務

構築が完了した後の運用は、一度きりの作業ではなく継続するオペレーションです。定期的なスキャンを回すには、スキャン設定・対象範囲・実行スケジュールを組み合わせたタスク管理が中心になります。

• スキャン設定（Scan Config）は検査するNVTの範囲を定義するテンプレートで、標準では「フルスキャン」に近い設定から軽量な設定まで複数の選択肢が用意されています。
• 対象範囲（Target）はIPアドレスやポートレンジで指定し、認証情報（クレデンシャル）を登録すればログイン型のローカルチェックも実行できます。
• スケジュール機能でタスクを定期実行に設定し、フィード更新のタイミングと合わせて運用サイクルを組む必要があります。

スキャン結果はレポート形式でエクスポートでき、重大度別に分類された脆弱性一覧を確認できます。ただし検査対象が増えるほどスキャン時間が延び、誤検知（False Positive）の確認や重大度の再評価といった後工程の作業量も増加します。この後工程を計画に含めずに構築だけを進めると、レポートが積み上がるだけで対応が追いつかない状態に陥りやすくなります。

脆弱性スキャンとペネトレーションテストの違い

OpenVASのようなツールが行うのは既知の脆弱性シグネチャに基づく自動スキャンであり、人手による攻撃シナリオの検証を行うペネトレーションテスト（侵入テスト）とは異なる作業です。この違いを理解せずに導入すると、期待する検査範囲と実際の結果にギャップが生じます。

脆弱性スキャンは既知のCVE（共通脆弱性識別子）や設定ミスを広く検査する定期健診に近い役割を担います。一方でペネトレーションテストは、診断員が実際の攻撃手法を模して侵入可能性を検証するため、未知の組み合わせによる脆弱性や業務ロジックの欠陥まで踏み込んで評価できます。OpenVASの結果だけでは、認証情報を組み合わせた侵入経路や複数の脆弱性を連鎖させた攻撃シナリオまでは検証できません。

そのため実務では、OpenVASなどのスキャナで日常的な脆弱性の有無を継続監視し、一定周期でペネトレーションテストを外部診断サービスに委託して深度のある検証を補う組み合わせが選ばれます。両者は代替関係ではなく、検査の頻度と深度が異なる補完関係にあると捉えるのが実態に近いといえます。

商用スキャナとの機能差 — Nessus・Qualysとの比較

OpenVASと商用スキャナの違いを検討する際は、費用だけでなく検査範囲・運用負荷・サポート体制まで含めて比較する必要があります。Nessusは2005年にクローズドソース化された経緯を持ち、現在はTenable社が開発する商用ツールとして提供されています^*2。Qualysはクラウド型の脆弱性管理サービスとして、継続的なスキャンとコンプライアンス監査機能を統合しています。

費用面だけを見ればOpenVASは優位に見えますが、フィードの網羅性やサポート体制まで含めると一律に「無償だから有利」とは言い切れません。自社の対象システムの重要度や、検査結果を精査できる人員の有無を踏まえて選ぶ必要があります。

内製が難しくなる場面 — 運用で直面する課題

OpenVASの構築自体はコンテナ化された手順に沿えば進められますが、運用フェーズに入ると想定より工数がかかる場面が出てきます。ここでは代表的な3つの課題を整理します。

第一に、フィード同期の失敗や停止に気づかず古い検査項目のままスキャンを継続してしまうリスクがあります。フィード同期状況を監視する仕組みを別途用意しないと、検査結果が実態を反映しない状態が続いてしまいます。

第二に、誤検知（False Positive）の判別には検査対象システムの構成理解とセキュリティの知識が両方必要です。スキャン結果に列挙された脆弱性を鵜呑みにして対応すると、実際には影響のない項目に工数を割く事態を誤ると、優先度の高い修正が後回しになるリスクがあります。

第三に、スキャナ自体・データベース・Web画面という複数コンポーネントの保守（バージョンアップ・障害対応・バックアップ）が必要になり、これを兼務で担う体制では対応が追いつかなくなる場面が出てきます。この作業を内製で回すには、Linuxサーバー運用・PostgreSQL運用・脆弱性の読み解きという3領域の知識と、月あたりの定常的な工数確保が必要です。

内製と外注の判断軸

OpenVASを内製するか、スキャン基盤の構築・運用を外部パートナーに委ねるかは、次の3つの軸で検討すると整理しやすくなります。

1. 継続運用に割ける人員がいるか：フィード監視・誤検知の精査・コンポーネント保守を定常業務として割り当てられるかを確認します。
2. スキャン対象の重要度と数：対象システムが少数かつ低リスクであれば内製の負荷は限定的ですが、対象が拡大するほど運用負荷も比例して増えます。
3. 診断サービスとの役割分担が明確か：OpenVASによる継続スキャンとペネトレーションテストなどの診断委託を、それぞれ何のために使うか役割を切り分けておく必要があります。

専門パートナーに構築・運用を依頼する場合は、フィード更新の運用設計やスキャン結果のトリアージ（優先度判定）まで含めて任せられる点が内製との差分になります。一方で内製を選ぶ場合は、前章で挙げた3つの課題に対応できる体制を事前に用意しておく必要があります。どちらを選ぶにしても、「スキャンして終わり」にせず、結果を継続的に運用へ反映する仕組みまで設計することが欠かせません。

まとめ：OpenVAS構築を判断する3つの軸

本稿ではOpenVAS（Greenbone Community Edition）の構成要素、NVTフィード更新の仕組み、構築の流れ、商用スキャナとの違い、内製と外注の判断軸を整理しました。要点を3つに集約すると次のとおりです。第一に、OpenVASはコンテナ構成で無償構築できますが、フィード管理と誤検知の精査という継続運用の負荷が伴います。第二に、脆弱性スキャンとペネトレーションテストは検査の深度が異なる補完関係にあり、どちらか一方で完結しません。第三に、内製か外注かは人員・対象規模・診断委託との役割分担という3軸で判断する必要があります。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：Greenbone AG「Greenbone Community Documentation – Background」（https://greenbone.github.io/docs/latest/background.html）
2. *2　出典：Greenbone AG「Greenbone Community Documentation – History of Greenbone, GVM and OpenVAS」（https://greenbone.github.io/docs/latest/history.html）
3. *3　出典：Greenbone AG「OPENVAS feed comparison – COMMUNITY vs. ENTERPRISE」（https://www.greenbone.net/en/feed-comparison/）
4. *4　出典：Greenbone AG「greenbone-feed-sync（GitHubリポジトリ）」（https://github.com/greenbone/greenbone-feed-sync）
5. *5　出典：Greenbone Community Forum「Important: IP and bandwith limitations on Community Feed」（https://forum.greenbone.net/t/important-ip-and-bandwith-limitations-on-community-feed/10595）
6. *6　出典：Greenbone AG「Greenbone Community Documentation – Greenbone Community Containers」（https://greenbone.github.io/docs/latest/22.4/container/index.html）
7. *7　出典：Tenable, Inc.「Nessus と他の脆弱性評価ソリューションの比較」（https://www.tenable.com/nessus/competitive-comparison）

Tweet