セキュリティ監査 15 分で読めます

Lynis・OpenSCAPによるLinuxセキュリティ監査実践ガイド：CIS準拠からAnsible自動修復まで

LynisとOpenSCAPを組み合わせたLinuxセキュリティ監査の実践ガイド。CISベンチマーク準拠の評価、Hardening Indexの改善、Ansibleによる自動修復、CI/CDパイプラインへの統合まで、コマンド例付きで解説。

Editorial Team

はじめに：なぜ「ハードニングの検証」が不可欠なのか

SSHの設定を強化した。ファイアウォールのルールを見直した。PAMのロックアウトも設定した――でも、それらが本当に意図どおりに機能しているかどうか、ちゃんと確認できていますか？

正直なところ、「設定を変更した＝安全になった」と思い込んでしまうのは、よくある落とし穴です。

2025年にLinuxカーネルだけで5,530件のCVEが報告されました。前年比で約28%増です。この数字を見ると、脅威が加速度的に増大していることは明らかですよね。セキュリティ対策を「やったつもり」で放置すると、設定のドリフトや見落としが静かに攻撃の入口を作ってしまいます。だからこそ、定量的にシステムの安全性を測定・検証できるセキュリティ監査ツールが必要になるわけです。

この記事では、Linuxセキュリティ監査の2大オープンソースツールであるLynisとOpenSCAPを組み合わせて、CISベンチマークへの準拠状況を体系的に評価・改善する方法を解説します。実際のコマンドとコード例をふんだんに盛り込んでいるので、手を動かしながら読んでもらえると理解が深まるはずです。さらに、Ansibleを使った自動修復（レメディエーション）まで踏み込んで、監査から改善までの一連のワークフローを構築していきます。

Lynis入門：300以上のチェックでシステムの弱点を洗い出す

Lynisとは何か

Lynisは、CISOfy社が開発・メンテナンスしているオープンソースのセキュリティ監査ツールです。Linux、macOS、BSD系のUNIXシステムに対して、300以上のセキュリティテストを一気に実行して、システムのハードニング状態を0〜100のスコア（Hardening Index）で数値化してくれます。

最新の安定版はLynis 3.1.6。カーネルパラメータ、ファイルパーミッション、認証設定、ネットワークサービス、暗号化、ログ管理、マルウェアスキャナの有無など、カバー範囲がかなり広いです。しかもエージェントレスで動作するので、スキャン対象にわざわざ追加のソフトウェアを入れなくていいのが地味にありがたいポイントですね。

インストール方法

ディストリビューションのパッケージマネージャからインストールできますが、最新版を確実に使いたいならCISOfyの公式リポジトリかGitHubから取得するのがおすすめです。

# RHEL/AlmaLinux/Rocky Linux（EPELリポジトリ）
sudo dnf install epel-release
sudo dnf install lynis

# Ubuntu/Debian
sudo apt update && sudo apt install lynis

# GitHubから最新版を取得（推奨）
git clone https://github.com/CISOfy/lynis.git
cd lynis
sudo ./lynis audit system

パッケージマネージャ版はバージョンが古い場合があるので、定期的に確認しておきましょう。

# インストール済みバージョンの確認
lynis show version

# 利用可能なコマンド一覧
lynis show commands

基本的なシステム監査の実行

最も基本的な使い方は、audit systemコマンドによるローカルスキャンです。やってみると意外とあっさり動きます。

# 対話的にシステム監査を実行（セクションごとに一時停止）
sudo lynis audit system

# 一時停止なしで一気にスキャン（自動化向け）
sudo lynis audit system --quick

# cronジョブ用（対話なし・色なし）
sudo lynis audit system --cronjob

スキャンが完了すると、こんな感じの結果サマリーが表示されます。

================================================================================
  Lynis security scan details:

  Hardening index : 67 [##############      ]
  Tests performed : 268
  Plugins enabled : 2

  Components:
  - Firewall               [V]
  - Malware scanner         [X]

  Scan mode:
  Normal [V]  Forensics [ ]  Integration [ ]  Pentest [ ]

  Lynis update available : YES
================================================================================

この例ではHardening Indexが67。悪くはない数値ですが、まだまだ改善の余地があります。マルウェアスキャナが未導入（[X]マーク）なのも一目でわかりますね。

レポートの読み方と活用法

Lynisは2種類のファイルに結果を出力します。

  • /var/log/lynis.log：スキャンの全技術的詳細（デバッグ情報含む）
  • /var/log/lynis-report.dat：警告（Warning）と提案（Suggestion）のサマリー

具体的に何を直せばいいのかを確認するには、レポートファイルから警告と提案を抽出します。

# 警告の一覧を抽出
grep "^warning\[\]" /var/log/lynis-report.dat

# 提案の一覧を抽出
grep "^suggestion\[\]" /var/log/lynis-report.dat

# 特定カテゴリ（SSH関連）の提案を確認
grep "SSH" /var/log/lynis-report.dat

各提案にはテストIDが含まれていて、このIDで詳細情報を調べられます。たとえばSSH-7408というIDが出たら、CISOfyのWebサイトやlynis show details SSH-7408コマンドで具体的な対処法がわかります。

Hardening Indexを改善するための実践テクニック

ひとつ注意しておきたいのは、Hardening Indexはあくまで「対策の実施度合い」を示す指標であって、「安全性そのもの」を直接表しているわけではないということです。とはいえ、この数値を上げていくプロセスは、結果的にシステムのセキュリティ強化そのものになります。

効果の大きい改善項目を優先順に並べると、こうなります。

  1. SSH設定の強化：ルートログイン禁止、鍵認証のみ許可、不要なプロトコルの無効化
  2. カーネルパラメータのハードニング：sysctl設定でIPフォワーディング無効化、ASLR有効化など
  3. ファイアウォールの有効化：nftablesまたはfirewalldの適切な設定
  4. 不要なサービスの停止：systemctlで使っていないデーモンを無効化
  5. ファイル整合性監視の導入：AIDE（Advanced Intrusion Detection Environment）のインストール
  6. マルウェアスキャナの導入：ClamAVやrkhunterのインストールと定期実行
  7. ログ監査の強化：auditdルールの設定とログローテーションの確認

特にsysctlのハードニングは効果が大きいので、以下の設定を参考にしてみてください。

# sysctl ハードニングの例
cat <<EOF | sudo tee /etc/sysctl.d/99-hardening.conf
# IPフォワーディングを無効化
net.ipv4.ip_forward = 0
net.ipv6.conf.all.forwarding = 0

# ソースルーティングを無効化
net.ipv4.conf.all.accept_source_route = 0
net.ipv6.conf.all.accept_source_route = 0

# SYN Cookie保護を有効化
net.ipv4.tcp_syncookies = 1

# ICMPリダイレクトを無効化
net.ipv4.conf.all.accept_redirects = 0
net.ipv6.conf.all.accept_redirects = 0

# ASLRを有効化（最大レベル）
kernel.randomize_va_space = 2

# コアダンプを制限
fs.suid_dumpable = 0
EOF

sudo sysctl --system

定期監査の自動化

月次でLynisを自動実行して、結果をログに残す設定例です。こういうのは一度組んでしまえば、あとは勝手に回ってくれるので楽ですよ。

#!/bin/bash
# /etc/cron.monthly/lynis-audit
LOG_DIR="/var/log/lynis"
mkdir -p "${LOG_DIR}"

TIMESTAMP=$(date +%Y%m%d_%H%M%S)
cd /usr/local/lynis || exit 1

./lynis audit system --cronjob \
  --logfile "${LOG_DIR}/lynis-${TIMESTAMP}.log" \
  --report-file "${LOG_DIR}/lynis-report-${TIMESTAMP}.dat"

# Hardening Indexの推移を記録
SCORE=$(grep "hardening_index" "${LOG_DIR}/lynis-report-${TIMESTAMP}.dat" | cut -d= -f2)
echo "${TIMESTAMP},${SCORE}" >> "${LOG_DIR}/hardening-index-history.csv"

OpenSCAP入門：標準化されたフレームワークでコンプライアンスを評価する

OpenSCAPとは何か

OpenSCAPは、NISTが管理するSCAP（Security Content Automation Protocol）仕様のオープンソース実装です。Lynisが「幅広いセキュリティチェック＋改善提案」に強みを持つのに対して、OpenSCAPはCISベンチマーク、STIG、PCI-DSSなどの正式なコンプライアンスフレームワークへの準拠状況を厳密に評価することに特化しています。

ざっくり言えば、Lynisが「実践的なセキュリティドクター」なら、OpenSCAPは「公式の監査員」みたいな立ち位置です。

2026年1月にはCIS Red Hat Enterprise Linux 10 Benchmark v1.0.1やCIS RHEL 8 Benchmark v4.0.0が更新されており、Ubuntuなど他ディストリビューション向けのベンチマークも頻繁にアップデートが続いています。

インストールとセットアップ

# RHEL/AlmaLinux/Rocky Linux
sudo dnf install openscap-scanner scap-security-guide

# Ubuntu/Debian
sudo apt install libopenscap8 ssg-base ssg-debderived ssg-ubuntu

# インストールされたSCAPコンテンツの確認
ls /usr/share/xml/scap/ssg/content/

scap-security-guideパッケージには、各ディストリビューション向けのデータストリームファイル（セキュリティプロファイル定義）が含まれています。これがOpenSCAPスキャンの「ルールブック」になるわけですね。

利用可能なプロファイルの確認

まず、使用するデータストリームファイルにどんなプロファイルが入っているか確認しましょう。

# RHEL 9の場合
sudo oscap info /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml

# Ubuntu 22.04の場合
sudo oscap info /usr/share/xml/scap/ssg/content/ssg-ubuntu2204-ds.xml

出力にはCIS Level 1 Server、CIS Level 2 Server、CIS Level 1 Workstationなど、複数のプロファイルが表示されます。自分の環境に合ったものを選んでください。

  • CIS Level 1：基本的なセキュリティ要件。システムの機能性への影響を最小限に抑えた設定
  • CIS Level 2：より厳格なセキュリティ要件。パフォーマンスや使い勝手に影響が出る可能性もある

迷ったら、まずはLevel 1から始めるのが無難です。

CISベンチマークに対するスキャンの実行

# RHEL 9 - CIS Level 1 Serverプロファイルでスキャン
sudo oscap xccdf eval \
  --profile xccdf_org.ssgproject.content_profile_cis_server_l1 \
  --results /tmp/cis-results.xml \
  --report /tmp/cis-report.html \
  /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml

# Ubuntu 22.04 - CIS Level 1 Serverプロファイルでスキャン
sudo oscap xccdf eval \
  --profile xccdf_org.ssgproject.content_profile_cis_level1_server \
  --results /tmp/cis-results.xml \
  --report /tmp/cis-report.html \
  /usr/share/xml/scap/ssg/content/ssg-ubuntu2204-ds.xml

生成されるcis-report.htmlをブラウザで開くと、各ルールのPass/Failが色分けされた詳細なHTMLレポートが表示されます。このレポートは監査証跡としてそのまま保存できるので、コンプライアンス対応の証拠資料として使えるのも嬉しいところです。

スキャン結果の解釈

スキャン結果には、各ルールについて以下のステータスが表示されます。

  • pass：ルールに準拠している
  • fail：ルールに違反している（対応が必要）
  • notapplicable：システムに該当しないルール
  • notchecked：自動チェックが利用できないルール（手動確認が必要）
  • error：チェック実行中にエラーが発生した

ここで大事なポイント。100%準拠を目指す必要はありません。組織のリスク許容度やビジネス要件に基づいて、一部のルールに「例外（Exception）」を設定するのはごく一般的なことです。重要なのは、なぜ例外としたのかをきちんと文書化しておくことです。

リモートスキャン

OpenSCAP 1.2.3以降に同梱されているoscap-sshコマンドを使えば、SSHを介してリモートマシンのスキャンもできます。複数台のサーバーを管理している場合には、これがとても便利です。

# リモートマシンをスキャン（リモート側にはoscapのみ必要）
oscap-ssh [email protected] 22 xccdf eval \
  --profile xccdf_org.ssgproject.content_profile_cis_server_l1 \
  --results-arf /tmp/remote-arf.xml \
  --report /tmp/remote-report.html \
  /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml

Lynis × OpenSCAP：2つのツールを組み合わせた多角的監査

なぜ両方を使うのか

「どっちか片方でいいんじゃない？」と思うかもしれませんが、実は両方使うことで得られるメリットはかなり大きいです。LynisとOpenSCAPは、それぞれ異なる角度からシステムを評価してくれます。

  • Lynis：幅広い実践的チェック＋具体的な改善提案。スコアリングが直感的で、日常の監査に向いている
  • OpenSCAP：CISやSTIGなどの正式なベンチマークへの厳密な準拠チェック。監査証跡の生成やコンプライアンス報告に強い

併用すれば、「Lynisが指摘した問題がCISベンチマークではどのルールに当たるのか」「CISベンチマークのfailだけでは見えない実践的な弱点はないか」といった多角的な分析が可能になります。

統合的な監査ワークフロー

では、具体的にどう組み合わせるか。以下の手順で2つのツールを使った定期監査を回していけます。

  1. Lynisでクイック監査：まず全体的なセキュリティ状態を把握し、主要な問題を洗い出す
  2. OpenSCAPでCIS準拠チェック：Lynisの結果を踏まえて、特定のコンプライアンスフレームワークへの準拠状況を確認
  3. 優先順位付けと修復：両ツールの結果を統合して、リスクベースで対応の優先順位を決定
  4. 修復後の再スキャン：修復を実施したら、両ツールで再スキャンして改善を確認

この一連の流れを自動化するスクリプトがこちらです。

#!/bin/bash
# combined-audit.sh - Lynis + OpenSCAP 統合監査スクリプト

REPORT_DIR="/var/log/security-audit"
TIMESTAMP=$(date +%Y%m%d_%H%M%S)
mkdir -p "${REPORT_DIR}/${TIMESTAMP}"

echo "=== Phase 1: Lynis Security Audit ==="
lynis audit system --cronjob \
  --logfile "${REPORT_DIR}/${TIMESTAMP}/lynis.log" \
  --report-file "${REPORT_DIR}/${TIMESTAMP}/lynis-report.dat"

LYNIS_SCORE=$(grep "hardening_index" \
  "${REPORT_DIR}/${TIMESTAMP}/lynis-report.dat" | cut -d= -f2)
echo "Lynis Hardening Index: ${LYNIS_SCORE}"

echo ""
echo "=== Phase 2: OpenSCAP CIS Benchmark Scan ==="
# RHEL 9の例（ディストリビューションに応じて変更）
oscap xccdf eval \
  --profile xccdf_org.ssgproject.content_profile_cis_server_l1 \
  --results "${REPORT_DIR}/${TIMESTAMP}/cis-results.xml" \
  --report "${REPORT_DIR}/${TIMESTAMP}/cis-report.html" \
  /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml

# pass/fail集計
PASS_COUNT=$(grep -c 'result>pass' \
  "${REPORT_DIR}/${TIMESTAMP}/cis-results.xml" 2>/dev/null || echo "0")
FAIL_COUNT=$(grep -c 'result>fail' \
  "${REPORT_DIR}/${TIMESTAMP}/cis-results.xml" 2>/dev/null || echo "0")
echo "CIS Results - Pass: ${PASS_COUNT}, Fail: ${FAIL_COUNT}"

echo ""
echo "=== Summary ==="
echo "Reports saved to: ${REPORT_DIR}/${TIMESTAMP}/"
echo "Lynis Score: ${LYNIS_SCORE}/100"
echo "CIS Compliance: ${PASS_COUNT} pass / ${FAIL_COUNT} fail"

Ansibleによる自動修復（レメディエーション）

OpenSCAPからAnsible Playbookを生成する

さて、ここからが個人的に一番テンションが上がるパートです。OpenSCAPには、スキャン結果から自動修復用のAnsible Playbookを生成する機能があります。これを使うと、手動で一つ一つ設定を直す手間が劇的に減ります。

# CISプロファイル全体のPlaybookを生成
oscap xccdf generate fix \
  --fix-type ansible \
  --profile xccdf_org.ssgproject.content_profile_cis_server_l1 \
  /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml \
  > cis-full-remediation.yml

# スキャンで失敗したルールのみのPlaybookを生成（推奨）
oscap xccdf generate fix \
  --fix-type ansible \
  --profile xccdf_org.ssgproject.content_profile_cis_server_l1 \
  --output cis-failed-remediation.yml \
  /tmp/cis-results.xml

失敗したルールだけに絞ってPlaybookを生成するアプローチがおすすめです。全ルール対象だと、すでに準拠している設定まで再適用することになって、不要な変更リスクが出てきます。

生成されたPlaybookのレビューと適用

ここは声を大にして言いたいのですが、生成されたPlaybookは必ずレビューしてから適用してください。自動生成の修復が、自分の環境にそのまま合うとは限りません。

# 生成されたPlaybookの内容を確認
cat cis-failed-remediation.yml

# ドライラン（実際に変更は加えない）
ansible-playbook -i "localhost," -c local \
  cis-failed-remediation.yml --check --diff

# 問題がなければ実際に適用
ansible-playbook -i "localhost," -c local \
  cis-failed-remediation.yml

scap-security-guide付属のPlaybookを活用する

scap-security-guideパッケージには、各プロファイル向けのAnsible Playbookが最初から同梱されています。スキャン結果からの生成が面倒な場合は、こちらを使う手もあります。

# 利用可能なPlaybookを確認（RHEL 9の場合）
ls /usr/share/scap-security-guide/ansible/

# 出力例：
# rhel9-playbook-cis.yml
# rhel9-playbook-cis_server_l1.yml
# rhel9-playbook-cis_workstation_l1.yml
# rhel9-playbook-cis_workstation_l2.yml

# CIS Level 1 Server Playbookをローカルに適用
ansible-playbook -i "localhost," -c local \
  /usr/share/scap-security-guide/ansible/rhel9-playbook-cis_server_l1.yml

devsec.hardeningロールとの連携

Ansible Galaxyで公開されているdevsec.hardeningコレクションは、SSH・OS・MySQLなどのハードニング用ロールを提供しています。OpenSCAPの自動修復と組み合わせれば、より包括的なハードニングが実現できます。

# devsec.hardeningコレクションのインストール
ansible-galaxy collection install devsec.hardening
# hardening-playbook.yml
---
- hosts: all
  become: true
  collections:
    - devsec.hardening
  roles:
    - os_hardening
    - ssh_hardening
  tasks:
    - name: OpenSCAP CISスキャンを実行
      command: >
        oscap xccdf eval
        --profile xccdf_org.ssgproject.content_profile_cis_server_l1
        --results /tmp/cis-results.xml
        --report /tmp/cis-report.html
        /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml
      register: oscap_result
      failed_when: false
      changed_when: false

    - name: CISスキャン結果を表示
      debug:
        msg: "OpenSCAP exit code: {{ oscap_result.rc }}"

CI/CDパイプラインへの監査統合

GitLab CIでの自動監査パイプライン

インフラのコード化（IaC）を実践しているチームなら、CI/CDパイプラインにセキュリティ監査を組み込むのが自然な流れです。設定変更のたびに自動でコンプライアンスチェックが走るようにしておけば、問題の早期発見につながります。

# .gitlab-ci.yml（一部抜粋）
security_audit:
  stage: test
  image: registry.access.redhat.com/ubi9/ubi:latest
  before_script:
    - dnf install -y openscap-scanner scap-security-guide lynis
  script:
    # Lynisスキャン
    - lynis audit system --cronjob --report-file lynis-report.dat
    - SCORE=$(grep "hardening_index" lynis-report.dat | cut -d= -f2)
    - echo "Lynis Hardening Index = ${SCORE}"
    - |
      if [ "${SCORE}" -lt 70 ]; then
        echo "WARNING: Hardening Index is below threshold (70)"
        exit 1
      fi
    # OpenSCAPスキャン
    - oscap xccdf eval
        --profile xccdf_org.ssgproject.content_profile_cis_server_l1
        --results cis-results.xml
        --report cis-report.html
        /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml || true
  artifacts:
    paths:
      - lynis-report.dat
      - cis-report.html
      - cis-results.xml
    when: always

Jenkins・GitHub Actionsとの統合

同じアプローチはJenkinsやGitHub Actionsでも実現できます。押さえておくべきポイントは以下のとおりです。

  • スキャン結果をアーティファクトとして保存して、監査証跡を残す
  • Hardening Indexやfailルール数にしきい値を設けて、基準を下回ったらパイプラインを失敗させる
  • スキャン結果の推移をダッシュボードで可視化して、セキュリティの改善トレンドを追う

実践的なチューニングとトラブルシューティング

Lynisのカスタムプロファイル

環境によっては、特定のテストがシステムの役割に合わないことがあります。たとえば、コンテナホストでUSBストレージのテストは明らかに不要ですよね。そういう場合はカスタムプロファイルでテストをスキップできます。

# /etc/lynis/custom.prf
# USB関連テストをスキップ
skip-test=USB-1000
skip-test=USB-2000

# コンテナ環境でのブートローダーテストをスキップ
skip-test=BOOT-5122

ただし、テストのスキップは慎重に。「面倒だから」という理由でスキップし始めると、他のシステムとのスコア比較が困難になってしまいます。不要なテストの除外は合理的ですが、安易な除外は避けましょう。

OpenSCAPのテーラリング

OpenSCAPでは「テーラリングファイル」を使って、プロファイルから特定のルールを除外したり、パラメータを変更したりできます。scap-workbench（GUI）を使うと直感的に作成できるので、CLIが苦手な方にもおすすめです。

# scap-workbenchのインストール
sudo dnf install scap-workbench    # RHEL系
sudo apt install scap-workbench    # Debian/Ubuntu

よくある問題と解決策

  • 「oscap xccdf evalがセグメンテーションフォルトで落ちる」：openscapパッケージのバージョンが古い可能性大です。dnf update openscap-scannerで最新版に更新してみてください
  • 「Lynisのスコアが突然下がった」：Lynisのバージョンアップで新しいテストが追加された可能性があります。lynis.logで追加テストを確認しましょう
  • 「CISベンチマークのfailが多すぎて対応しきれない」：まずLevel 1の高優先度ルール（認証・アクセス制御・ログ関連）から着手して、段階的に範囲を広げるのが現実的です。一度に全部やろうとしないことが大事ですね

FAQ：よくある質問

LynisとOpenSCAPのどちらを使えばよいですか？

結論から言うと、両方を併用するのがベストです。Lynisは日常的なセキュリティチェックと実践的な改善提案に優れていて、OpenSCAPはCISベンチマークなどの正式なコンプライアンス基準への準拠証明に向いています。Lynisで広く問題を把握して、OpenSCAPで正式な準拠状況を測定する――この組み合わせが最も効果的です。

CISベンチマークの100%準拠は必要ですか？

いいえ、100%準拠は必須ではないし、現実的でもありません。組織の環境やビジネス要件によって、適用できないルールは普通に出てきます。大事なのは、準拠していない項目について「なぜ例外としたのか」を文書化し、代替の制御策（Compensating Control）を準備しておくことです。

Lynis監査はどのくらいの頻度で実行すべきですか？

最低でも月1回。理想的にはシステムに大きな変更を加えるたびに実行してほしいところです。CI/CDに組み込んでいるなら、設定変更がプッシュされるたびに自動実行されるのが理想ですね。Hardening Indexの推移を時系列で記録して、スコアが下降傾向にあったらすぐに原因を調べるようにしましょう。

OpenSCAPのスキャンが完了するまでにどれくらい時間がかかりますか？

システムのスペックや選択するプロファイルによりますが、CIS Level 1プロファイルのスキャンなら5〜15分程度が目安です。Level 2はチェック項目が増えるぶん、もう少しかかります。cronやCI/CDで非対話的に実行する場合は、タイムアウトに余裕を持たせておくと安心です。

コンテナ環境やクラウドインスタンスにもLynis・OpenSCAPは使えますか？

はい、問題なく使えます。LynisにはDockerfileの監査機能（lynis audit dockerfile）も用意されています。ただし、コンテナ内のスキャンではホストとは異なるチェック項目が適用される点に注意してください。クラウドインスタンスに対しては、oscap-sshを使ったリモートスキャンが便利です。AWS・GCP・Azureどの環境でも、オンプレミスと同じ手順で監査を実施できます。

著者について Editorial Team

Our team of expert writers and editors.