Linuxの要塞化：OpenSCAPを使用してCISベンチマーク・コンプライアンスを自動化する

Table of Contents

「動けばいい」の罠：デフォルト設定がセキュリティ上のリスクになる理由

新しいLinuxサーバーを立ち上げ、サービスのステータスが「グリーン（正常）」になった瞬間は達成感を感じるものです。ウェブサーバーは応答し、ファイアウォールはポート443の通信を通し、すべてが完璧に見えます。しかし、ここに落とし穴があります。「デフォルト」が「安全」であることは滅多にありません。ほとんどのディストリビューションは、セキュリティのロックダウンよりも、すぐに使える互換性を優先しています。レガシープロトコルが有効なまま出荷されたり、ハードウェアが正常に動作するように寛容な設定が施されていたりするのです。

私はこれを身をもって学びました。立ち上げたばかりのVPSが、6時間足らずで140のユニークなIPアドレスから8,500回ものSSHログイン試行（失敗）を受けたのです。ログは悲惨な状態でした。もしあらかじめSSHを非標準ポートに変更し、公開鍵認証のみに制限していなければ、この話は肥大化したログファイルではなく、データベースの漏洩という結末を迎えていたでしょう。機能しているシステムが、必ずしも安全なシステムとは限りません。

サーバーを手動でハードニングするのは、気の遠くなるような作業です。カーネルパラメータからファイル権限まで、200以上の個別の設定を確認する必要があります。世界中から書き込み可能な設定ファイルや、安全でないsysctl変数など、たった一つの些細な詳細を見逃すだけで、攻撃者が権限を昇格させるには十分なのです。

「稼働中」と「要塞化済み」の間のギャップ

サーバーを脆弱な状態のままにしてしまう主な理由は、その複雑さにあります。新しいパッケージをインストールすると、メンテナは可能な限り幅広い環境で動作するように設計された設定を提供します。たとえその機能が攻撃対象領域（アタックサーフェス）を大幅に広げることになったとしても、5%のユーザーが必要とするかもしれない機能を無効にすることはありません。

また、正式なフレームワークがない場合、セキュリティは危険なほど主観的になります。ある管理者はrootログインを無効にすれば「十分だ」と考えるかもしれません。別の管理者は、nosuidやnodevのような複雑なfstab制限を主張するかもしれません。厳格で業界に認められた標準がなければ、セキュリティのレベルは、そのサーバーを構築した人の記憶力と忍耐力に左右されてしまいます。

手動ハードニング vs 自動監査

通常、このセキュリティギャップを埋めるには3つの方法があります。

手動チェックリスト： 300ページのPDFに従ってコマンドを一つずつ実行します。低速でヒューマンエラーが発生しやすく、最終的には手順を飛ばしたり、タイポをしたりすることになります。
カスタムシェルスクリプト： hardening.shのようなツールを自作します。これはOSがアップデートされるまでは機能します。Ubuntu 22.04から24.04へ移行する際にスクリプトの互換性を維持し続けるのは、メンテナンスの負担になります。
SCAP準拠ツール： Security Content Automation Protocol (SCAP) は、脆弱性スキャンのプロフェッショナルな標準です。OpenSCAPを使用すると、オペレーティングシステム・セキュリティのゴールドスタンダードであるCISベンチマークに基づいてシステムを監査できます。

本番環境において、OpenSCAPは論理的な選択肢です。セキュリティポリシーを定義するための正式かつ再現可能な方法を提供し、システムがコンプライアンス要件を満たしていることを証明する、監査対応のレポートを生成します。

ステップ・バイ・ステップ：OpenSCAPによるコンプライアンスの自動化

OpenSCAPは自動監査役として機能します。確立されたプロファイルに基づいて設定をスキャンし、不合格（Fail）箇所を正確に特定し、問題を修正するために必要なコードを提供します。

1. エンジンとセキュリティガイドのインストール

スキャンエンジンと「セキュリティガイド」（実際のルール）が必要です。DebianやUbuntuでは、apt経由でインストールします。

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

RHEL、AlmaLinux、またはRocky Linuxの場合、パッケージ名が若干異なります。

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

2. セキュリティプロファイルの選択

ルールは、/usr/share/xml/scap/ssg/content/内の「DataStream」ファイルに保存されています。これらのファイルには、PCI-DSS、STIG、CISなどの異なるプロファイルが含まれています。Ubuntu 22.04システムで利用可能なものを確認するには、次を実行します。

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

xccdf_org.ssgproject.content_profile_cisというラベルのIDを探してください。これが、Center for Internet Securityの標準に照らしてサーバーを評価するために使用するプロファイルです。

3. セキュリティ監査の実行

次に、スキャンを実行します。このコマンドはシステムを評価し、詳細なHTMLレポートを生成します。このステップは安全です。設定を観察するだけで、変更は行いません。

sudo oscap xccdf eval \
  --profile xccdf_org.ssgproject.content_profile_cis \
  --report cis_report.html \
  /usr/share/xml/scap/ssg/content/ssg-ubuntu2204-ds.xml

ターミナルにPass（合格）とFail（不合格）の結果が流れます。終了したら、ブラウザでcis_report.htmlを開き、カテゴリ別のセキュリティスコアを確認してください。

4. 失敗箇所の修正

立ち上げたばかりのサーバーのスコアが40%未満でも、慌てないでください。主に以下の3つの領域で重大な失敗が見られるはずです。

パーティショニング： /tmpや/dev/shmにnodev、nosuid、またはnoexecフラグが設定されていない。
監査： auditdサービスがファイルの削除や管理者による変更を追跡していない。
ネットワーキング： IPフォワーディングが有効になっているか、システムが依然としてICMPリダイレクトを受け入れている。

OpenSCAPは2つの修正方法を提供します。HTMLレポートにはすべてのルールに対して「Remediation（修正）」セクションがあり、手動修正に必要な正確なコマンドや設定行が表示されます。

または、自動修正（automated remediation）を使用して、修正を即座に適用することもできます。

# 注意：システムファイルを直接変更します
sudo oscap xccdf eval \
  --remediate \
  --profile xccdf_org.ssgproject.content_profile_cis \
  /usr/share/xml/scap/ssg/content/ssg-ubuntu2204-ds.xml

稼働中の本番ノードで--remediateを盲目的に実行するのは避けてください。システムバイナリの権限を厳しくするなど、一部のルールは特定のレガシーアプリケーションを壊す可能性があります。レポートの結果を利用して、代わりにAnsibleプレイブックを更新するようにしてください。これにより、設計段階からインフラの安全性を確保できます。

セキュリティはタスクではなくプロセスである

ハードニングは、一度やれば終わりのプロジェクトではありません。開発者が新しいツールをインストールしたり、設定ファイルを微調整したりするたびに、コンプライアンスは低下します。常に先手を打つために、OpenSCAPを週次のcronジョブやCI/CDパイプラインに統合しましょう。これらのスキャンを自動化し、週次レポートを確認することで、「設定のドリフト（乖離）」によってサーバーが次のブルートフォース攻撃の格好の標的になるのを防ぐことができます。