OpenSCAPで本番Linuxのセキュリティ設定を定期診断する｜OVAL評価とリスク受容判断フロー

なぜ本番環境に定期診断が必要なのか

CVEの公開件数は年間2万件を超える水準が続いており、パッチを当てるかどうかの判断を都度手作業でおこなっていては追いつきません。多くの運用現場では「適用漏れに気づいたのは監査の直前だった」という経験をしており、定期的な自動診断を仕組みとして持つことが実質的な必須要件になっています。

OpenSCAPは、NIST が策定したSCAP（Security Content Automation Protocol）を実装するオープンソースのコンプライアンス評価フレームワークです。OVAL（Open Vulnerability and Assessment Language）と呼ばれる機械可読な脆弱性定義を読み込み、システムの実際の状態と照合して合否を判定します。商用スキャナと異なりエージェントの追加費用が不要で、RHEL系・Debian系を問わず標準パッケージとして入手できるため、予算制約の大きい運用チームでも導入しやすい点が現場に評価されています。

OpenSCAPとOVALの関係を整理する

OpenSCAPの動作を理解するには、データ層とエンジン層を分けて考えると見通しが立ちやすくなります。

エンジンに相当するのが oscap コマンドです。評価ロジックを実装しており、引数で渡したコンテンツファイルに従ってシステムを検査します。データ層にあたるのがSCAPコンテンツで、具体的にはOVALファイルとXCCDF（Extensible Configuration Checklist Description Format）プロファイルの2種類が中心です。

OVALは個々の脆弱性や設定項目をXMLで記述したもので、ディストリビュータが配布します。たとえばRed Hat は com.redhat.rhsa-RHEL9.xml.bz2 のような形式で月次更新しており、AlmaLinux・Rocky Linuxも同様の配布体制を取っています。Ubuntuはcom.ubuntu.jammy.oval.xml.bz2という形式です。これらは公式リポジトリから直接取得でき、サードパーティへの依存が発生しないことも運用上の安心材料になります。

XCCDFはポリシーの集合体で、CIS Benchmarkや米政府のSTIG（Security Technical Implementation Guide）がよく使われます。OVALが「この脆弱性が存在するか」を問うのに対し、XCCDFは「パスワードポリシーが基準を満たすか」「不要なサービスが無効になっているか」といった設定面の合否を問います。月次CVE診断では両者を組み合わせるのが典型的な運用です。

実環境へのインストールとOVALスキャンの手順

RHEL 9系（AlmaLinux 9 / Rocky Linux 9含む）では以下でインストールできます。

dnf install openscap-scanner scap-security-guide bzip2 -y

Ubuntu 22.04 / 24.04 LTSの場合は次のとおりです。

apt install libopenscap8 openscap-scanner -y

インストール後、まずOVALコンテンツを取得します。AlmaLinux 9を例にすると、公式ミラーから最新のOVALファイルを curl または wget でダウンロードし、bzip2 -d で展開します。このファイルを月次の更新タイミングに合わせて置き換えることが、定期診断サイクルの核心です。

スキャン実行は1コマンドです。

oscap oval eval --results oval-results.xml --report oval-report.html oval.xml

--results で機械可読なXML、--report で人間が読めるHTMLレポートを同時出力します。本番環境では直接HTMLを生成せず、XMLのみ保存してCI/CDパイプラインで後処理する構成が多く見られます。HTMLは開発環境での確認用と割り切るとログ管理がシンプルになります。

systemdのタイマーで月次実行を組む場合、/etc/systemd/system/oscap-oval.service と oscap-oval.timer を作成し、systemctl enable --now oscap-oval.timer で有効化します。cronより管理しやすく、実行ログがジャーナルに統合されるため障害時の追跡が容易です。

レポートの読み方とリスク受容判断フロー

OVALレポートの各行は true（脆弱性あり）・false（該当なし）・error（評価不能）の3値で返ります。運用上、問題になるのは true の項目です。

判断フローは以下の流れで組むと現場に定着しやすくなります。

• ステップ1：CVSSスコアの確認　OVAL定義にはCVSS v3スコアが付与されています。スコア9.0以上のCriticalは48〜72時間以内のパッチ適用を原則とし、例外申請のフローへ直行させます。
• ステップ2：攻撃経路の評価　Network経由（AV:N）か、認証不要（PR:N）かを確認します。インターネット非公開かつ内部ネットワーク限定のサーバーではAttack Vectorの実効スコアを再評価できる場合があります。
• ステップ3：回避策の有無　Red Hat Security Advisoryなどベンダーの公式情報を参照し、パッチ以外の一時的な緩和策（設定変更・機能の無効化）が存在するか確認します。
• ステップ4：リスク受容の記録　対応を保留する場合は、理由・期限・担当者を管理票に記録します。無記録の放置は監査で指摘対象になるため、記録の有無がリスク受容とリスク無視を分ける境界線です。

この4ステップを月次サイクルのチケット運用に組み込むことで、「脆弱性は把握しているが対応できていない」状態を可視化できます。スコアが低くても長期間放置されている項目は、次回スプリントで強制的に再評価するルールを設けると慢性的な積み残しを防げます。

XCCDFプロファイルを使った設定コンプライアンス評価

パッケージの脆弱性だけでなく、OSの設定そのものを評価したい場合はXCCDFとSCAPコンテンツを組み合わせます。RHEL 9では scap-security-guide パッケージを導入すると /usr/share/xml/scap/ssg/content/ 以下にプロファイルが展開されます。

CIS Level 1相当のベースライン診断を実行する場合、次のようにプロファイルを指定します。

oscap xccdf eval \
  --profile xccdf_org.ssgproject.content_profile_cis_l1_server \
  --results xccdf-results.xml \
  --report xccdf-report.html \
  /usr/share/xml/scap/ssg/content/ssg-almalinux9-ds.xml

XCCDFレポートはOVALより項目数が多く、初回診断では数十〜数百件のfailが出ることが珍しくありません。全件を即日修正しようとすると稼働中サービスへの影響が読めなくなるため、まず「修正コスト低・影響範囲小」の項目から着手し、サービスの再起動が必要な変更は変更管理ウィンドウに計画する段階的対応が現実的です。

2026年現行環境における注意点と差分

2025年末時点でRHEL 10のリリースが見込まれており、AlmaLinux・Rocky Linuxも追随しています。RHEL 10ではOpenSCAPとSCAPコンテンツのメジャーバージョン対応が必要で、既存の ssg-rhel9-ds.xml をそのまま流用すると定義ミスマッチが発生します。ディストリビューションの大型アップグレード時にはOVALファイルとSSGコンテンツのバージョンを必ずセットで更新してください。

Ubuntu 24.04 LTS（Noble Numbat）では、OVALコンテンツの命名規則が com.ubuntu.noble.oval.xml.bz2 に変わっています。22.04（Jammy）環境でスクリプトを流用する際はファイル名の書き換えを忘れがちな点に注意が必要です。

コンテナ環境での利用については、OpenSCAPの --chroot オプションや oscap-docker ラッパーを使うことでコンテナイメージのスキャンが可能ですが、カーネルパラメーターの評価はホスト側に依存するため、コンテナ内の評価結果とホスト側の評価結果を混同しないよう管理を分けることが推奨されます。

また、systemd-resolved や NetworkManager が標準化されている現代のディストリビューションでは、旧来のネットワーク設定ファイル（/etc/sysconfig/network-scripts/）を前提としたOVAL定義が error を返すケースがあります。これはシステムの異常ではなく定義側の前提不一致によるものですが、レポート上では目立つため、誤検知リストとして管理台帳に記録しておくと月次レビューの工数を削減できます。

定期診断の運用を軌道に乗せるうえで重要なのは、ツールの精度より「結果を見て判断する人間のフロー」を先に固めることです。OpenSCAPはあくまで現状の可視化装置であり、リスクを受容するか対処するかの判断は組織の責任として残ります。月次サイクルに診断・判断・記録の三段階を組み込むことで、コンプライアンス対応と実態のセキュリティ水準を両立させる基盤が整います。