LinuxにおけるOpenSCAP活用ガイド：CIS Benchmarkに準拠した構成スキャンと自動修復の手順 - ITFROMZERO - Share tobe shared! OpenSCAPを使用してCIS Benchmarkに準拠したLinuxの構成スキャン、レポート出力、自動修復を実施する実践ガイド。サービス停止を防ぎつつ、サーバーを国際基準に準拠させる自動化アプローチを解説します。

Table of Contents

Linuxサーバーのセキュリティ監査における3つのアプローチ

LinuxサーバーのOSをインストールしただけの状態は、運用のスタートラインに過ぎません。デフォルト設定ではセキュリティよりも利便性が優先されており、SSHのroot直接ログインが許可されていたり、ファイルパーミッションが緩かったり、不要なデーモンがバックグラウンドで動作していたりします。システムをセキュアな状態に引き上げるため、運用チームは通常、以下の3つのアプローチのいずれかを選択します。

チェックリストによる手動確認： 管理者が自ら設定ファイルを開き、ポートの開放状況をコマンドで1つずつ確認しながら、100〜200項目におよぶ社内Excelシートと突き合わせる手法です。
スタンドアロン型スキャンツールの利用（Lynisなど）： 手軽さが最大の利点で、コマンドを1回実行するだけで、約2分後には総合スコアと改善推奨リストが出力されます。
OpenSCAPによる標準化： SCAPフレームワークを活用し、実環境の構成をCIS Benchmark、PCI-DSS、STIGといった国際的なセキュリティ基準と照合します。明確なスコアリングに加えて、自動修復スクリプトの生成まで対応しています。

各手法の実用的なメリット・デメリット比較

それぞれの手法には異なるユースケースがあります。

1. 手動確認

メリット： 各パラメータの意味や、設定を変更する背景・理由をエンジニア自身が深く理解できます。
デメリット： 工数が膨大で、確認漏れが発生しやすくなります。1台を綿密に精査するだけでも2〜3時間は要するため、30〜50台規模のクラスタ環境では完全に破綻します。

2. スタンドアロン型スキャナー（Lynis）

メリット： インストールが容易で動作も非常に軽量です。サーバー引き渡し前の簡易的な事前診断に適しています。
デメリット： 結果はあくまで社内参考用にとどまりがちです。国際的な外部監査人に対してコンプライアンス遵守を証明する証跡としては、証拠能力が不足するケースが多く見られます。

3. OpenSCAPツールセット

メリット： 銀行や金融機関でも採用されるデファクトスタンダード「CIS Benchmark」に厳密に準拠しています。HTMLレポートは視覚的に分かりやすく、リスクが項目ごとに詳細分類されます。さらに、検出された脆弱性に対応する修復（remediation）スクリプトを自動生成できる点が大きな特長です。
デメリット： コマンド構文が長く、ルールプロファイルの定義が膨大なため、初めて扱う際はやや圧倒されがちです。

どのような場面でOpenSCAPを導入すべきか？

これまで10件以上のシステム監査を実施してきた経験上、セキュリティリスクの大半はごく些細な不備に潜んでいます。例えば、PermitRootLogin yesの放置、SSHセッションのタイムアウト未設定、/etc/cron.*配下の過剰なパーミッション開放などです。ファイアウォールで不要ポートを閉じるだけで安心してしまうケースも少なくありませんが、特権昇格リスクの約70%はOS内部の誤った設定に起因しています。

個人ブログ用のVPSを1台運用する程度であれば、Lynisで十分事足りるでしょう。しかし、本番インフラを管理している現場や、ISO 27001、PCI-DSSなどの認証取得・監査対応を控えている場合、あるいは800ページ超におよぶCISのPDFを読まずに確実なOSハーデニングを実施したい場合には、OpenSCAPが最も確実で標準的な選択肢となります。

OpenSCAPによるCIS Benchmarkスキャンと修復スクリプト適用の実践手順

ここでは、Ubuntu 22.04 LTSおよびRHEL/Rocky Linux 9を想定した具体的な手順を解説します。

ステップ1：スキャナー本体とSCAP Security Guideのインストール

OpenSCAPは、スキャナー本体（oscap）とセキュリティルール集（SSG）で構成されます。

Ubuntu / Debian環境の場合：

sudo apt update
sudo apt install -y libopenscap8 scap-security-guide

RHEL / Rocky Linux / AlmaLinux環境の場合：

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

ステップ2：利用可能なセキュリティプロファイルの確認

Linuxディストリビューションごとに専用のDataStreamファイルが用意されています。以下のコマンドを実行し、Ubuntu 22.04でサポートされているプロファイル一覧を確認します。

oscap info /usr/share/xml/scap/ssg/content/ssg-ubuntu2204-ds.xml

画面にはcis_level1_server、cis_level2_server、pci-dssなどのプロファイルが表示されます。稼働中のサービスがある環境では、CIS Level 1 Serverが最もバランスの取れた選択肢です。一般的なアプリケーションの動作を妨げることなく、強固なセキュリティベースラインを確立できます。

ステップ3：システムスキャンの実行とHTMLレポートの出力

CIS Level 1プロファイルを指定して監査を実行します。

sudo oscap xccdf eval \
  --profile xccdf_org.ssgproject.content_profile_cis_level1_server \
  --results-arf /tmp/cis-results.xml \
  --report /tmp/cis-report.html \
  /usr/share/xml/scap/ssg/content/ssg-ubuntu2204-ds.xml

200項目以上のチェックが行われ、スキャン完了までに約1〜3分かかります。各項目はpass、fail、またはnotapplicableとして評価されます。

ステップ4：グラフィカルレポートの確認

生成された/tmp/cis-report.htmlをSCPなどでローカルPCにダウンロードします。

scp user@server-ip:/tmp/cis-report.html .

ブラウザでファイルを開くと、総合適合度スコア（Compliance Score）が表示されます。その下には違反ルール、危険度レベル、不合格の理由、手動修正用のスクリプトスニペットなどの詳細情報がまとめられています。

ステップ5：安全な自動修復（Remediation）の実装

本番環境のサーバーに対して、いきなりインラインでの自動修復コマンドを実行するのは避けてください。まずは修正用Bashスクリプトを外部出力し、内容を事前にレビューするのが最も安全なアプローチです。

# スキャン結果に基づいた修復スクリプトの生成
sudo oscap xccdf generate fix \
  --profile xccdf_org.ssgproject.content_profile_cis_level1_server \
  --fix-type bash \
  --output /tmp/remediate-cis.sh \
  /usr/share/xml/scap/ssg/content/ssg-ubuntu2204-ds.xml

出力された/tmp/remediate-cis.shをlessやvimで確認します。このスクリプトには、SSHのrootログイン無効化、umaskの027設定、コアダンプの制限、/etc/shadowのパーミッション0000化といった具体的な設定変更が含まれています。内容を精査し、既存アプリケーションへの影響がないことを確認した上で実行します。

sudo bash /tmp/remediate-cis.sh

なお、新規構築直後の初期サーバー（まだアプリケーションが稼働していない状態）であれば、--remediateフラグを付与してスキャンと同時に修復を行うことも可能です。

sudo oscap xccdf eval \
  --profile xccdf_org.ssgproject.content_profile_cis_level1_server \
  --remediate \
  --report /tmp/cis-report-after-fix.html \
  /usr/share/xml/scap/ssg/content/ssg-ubuntu2204-ds.xml

適用後に再度レポートを開くと、適合率スコアが当初の40〜50%台から85%以上に跳ね上がり、大半の警告（赤色）が合格（緑色）へ切り替わっていることを確認できます。

締め出し（ロックアウト）を防ぐための2つの必須注意点

システムのハーデニングは、注意を怠ると管理者がサーバーから締め出されるリスクを伴います。以下の2原則を徹底してください。

作業中は必ず別系統のSSHセッションを維持しておくこと： CIS Benchmarkのルールでは、パスワード認証が無効化され（公開鍵認証のみ許可）、rootログインも遮断されます。修復スクリプト実行後は、現在のターミナルセッションを絶対に閉じず、別タブを新しく開いてSSH接続の疎通テストを行ってください。正常にログインできることを確認できて初めて、元のセッションを切断します。
ステージング環境で事前に48時間検証すること： 厳格なumask設定やカーネルモジュール（cramfsやtipcなど）の無効化によって、Nginx、Docker、データベースなどが正常に起動しなくなる恐れがあります。本番環境へ反映する前に、必ずステージング環境で最低2日間はサービスを稼働させて問題がないか経過を観察してください。