OpenSCAP は「診断ツール」で終わらない。個人で試す Linux ハードニングの実践的な使い方
- 4月24日
- 読了時間: 8分
Hi, there.
今回は、Linux OSのハードニングについてのお話です。
Linux のハードニングに興味を持つと、多くの人が最初にぶつかるのは、「設定項目が多すぎる」という壁です。カーネルパラメータ、認証設定、監査ログ、ファイル権限、不要サービスの停止。手で一つずつ詰めていく方法は勉強にはなりますが、全体像を掴む前に疲れてしまいやすい。しかも、手作業にはどうしても設定漏れや設定ゆれ、単純な見落としが入り込みます。そこで役に立つのが OpenSCAP です。OpenSCAP は SCAP 準拠コンテンツを使ってシステムの設定評価やレポート生成を行うためのツール群として案内されており、RHEL では SCAP Security Guide のプロファイルを使った評価や remediation、Ansible Playbook や Bash スクリプトの生成まで公式に整備されています。
OpenSCAP の本当の価値は、単に「CIS に照らして監査すること」ではありません。むしろ大きな価値は、ベースライン構築を標準化できることにあります。どのプロファイルを採用するのか、どのルール群を土台にするのか、どの修正を自動で当てるのか。そうした判断を、個人の勘や属人的な設定メモではなく、明示されたルールセットに基づいて進められるようになります。Red Hat の公式文書でも、OpenSCAP と SCAP Workbench は設定コンプライアンスの評価、脆弱性スキャン、レポート生成、remediation のための仕組みとして位置づけられています。
いちばん押さえたいのは、「ベースライン構築を仕組みにできる」という点
ハードニングで本当に面倒なのは、設定を変えることそのものではありません。面倒なのは、何をどの順番で、どの水準まで揃えるかを毎回人力で考えることです。
たとえば、同じ Linux を複数台作る場面を想像すると分かりやすいでしょう。手で harden すると、どうしても微妙な差が出ます。あるサーバでは SSH の設定を直したのに、別のサーバでは監査設定を入れ忘れる。あるいは、作業者ごとに判断がぶれて、同じ「ハードニング済み」のつもりでも実態が揃わない。OpenSCAP は、そうしたばらつきを抑えるための基準点、つまりセキュアなベースラインの土台として使えるのが強みです。OpenSCAP が読む SCAP コンテンツには、ルール、プロファイル、ベンチマーク、remediation 情報がまとまっており、これを使うことで「何を満たすべきか」を一貫した形で扱えます。
だからこそ、OpenSCAP を「点検ツール」とだけ見るのは少しもったいない。本質的には、ベースラインを定義し、その差分を測り、必要なら是正までつなげられる仕組みとして見るほうがしっくりきます。
まず覚えたいのは、「OpenSCAPはスキャナ」「SSGは中身」という構造
OpenSCAP を理解するうえで最初に押さえたいのは、ツール本体とルール群は別物だという点です。oscap は評価を実行する側で、実際のベンチマークやプロファイル、ルール、fix の中身は SCAP Security Guide 由来のコンテンツに含まれています。Red Hat の資料でも、SCAP Security Guide の data stream には definitions、benchmarks、profiles、individual rules が含まれると説明されています。
この構造を知ると、OpenSCAP の見え方が変わります。OpenSCAP が万能なのではなく、どのプロファイルを選ぶかでベースラインの性格が決まるのです。つまり、OpenSCAP の価値は「とにかく scan できること」ではなく、「明確な基準を土台に環境を揃えられること」にあります。Red Hat は oscap info を使って利用可能なプロファイルと詳細説明を確認する手順を案内しており、これは単なる事前確認ではなく、ベースライン選定の第一歩といえます。
下準備：自分の環境に合うプロファイルを選ぶ
OpenSCAP を使ってベースラインを作るとき、最初に大切なのは「どの基準で揃えるか」を決めることです。RHEL 9 の公式文書には、CIS Level 1 / Level 2、STIG、PCI-DSS、OSPP、HIPAA など、複数のプロファイルが並んでいます。これはつまり、「安全な設定」は一種類ではなく、目的ごとに複数あるということです。サーバ用途とワークステーション用途では要求が違い、求める厳格さも違います。
ここで OpenSCAP が効いてきます。ゼロから自分で「何を harden するべきか」を設計しなくても、まずは既存プロファイルを土台にできます。たとえば、個人 lab や小規模サーバなら、最初から厳格な STIG に飛びつくより、比較的現実的な CIS Level 1 系から入るほうが、ベースラインとして扱いやすいことが多いでしょう。重要なのは、「完全な正解」を探すことではなく、自分の環境で再現可能な標準設定の出発点を持つことです。OpenSCAP は、その出発点を明文化された形で与えてくれます。
活用法1：HTMLレポートを“設定の抜け漏れ確認表”として使う
OpenSCAP は評価結果をレポートとして出力できます。このレポートの価値は、単に pass / fail を数えることではありません。むしろ大きいのは、ベースラインとの差分を一覧で見える化できることです。どのルールが未達なのか、なぜ fail したのか、何が期待値なのかがまとまって出るので、手作業で項目を洗い出すよりも圧倒的に速く、抜け漏れも減らせます。SCAP Workbench も、スキャンとその結果に基づくセキュリティレポート生成を行える GUI ツールとして案内されています。
ここで重要なのは、レポートを「学習資料」として使うこと以上に、標準との差分管理表として使うことです。つまり、「どこが足りないか」を人の記憶に頼らず機械的に出せることが価値なのです。ハードニングの現場では、設定の巧拙よりも、まず“揃っているかどうか”が大切になる場面が少なくありません。OpenSCAP のレポートは、その確認を省力化してくれます。
活用法2：remediation を使ってベースライン構築を一気に進める
OpenSCAP をベースライン構築の道具として見るなら、いちばん実践的なのは remediation です。OpenSCAP のマニュアルでは、XCCDF 評価を行い、失敗したルールに対応する fix 要素を探し、その fix スクリプトを実行する流れが説明されています。つまり、OpenSCAP は「診断して終わり」ではなく、標準設定へ寄せるための修正処理まで担えるわけです。さらに Red Hat は、特定ベースラインに沿うための remediation Ansible Playbook や、後から適用するための Bash スクリプトの生成も案内しています。 (https://github.com/OpenSCAP/openscap/blob/main/docs/manual/manual.adoc)
この点こそ、ベースライン構築で OpenSCAP を推したい最大の理由です。Linux の hardening をすべて手でやろうとすると、時間がかかるだけでなく、設定ミスや漏れの温床になります。ですが、既存プロファイルを土台に remediation を活用すれば、“まず標準形に近づける” ところまでをかなり効率よく進められる。その後で、自分の環境に固有の例外設定や業務上必要な緩和を見直せばよい。順番としては、最初に白紙から組み立てるのではなく、まず安全側のベースラインへ寄せてから必要最小限だけ戻すほうが、一般に手間も少なく、ミスも減らしやすいのです。
もちろん、自動 remediation は慎重に扱う必要があります。Red Hat は、使い方を誤るとシステムが正常に動かなくなるおそれがあり、設定の自動巻き戻しは提供されないと明記しています。ですが、この注意点は OpenSCAP の価値を下げるものではありません。むしろ、手で雑に harden するのではなく、標準化された修正を前提に、変更管理を意識して適用するべきだという話です。
活用法3：Ansibleやスクリプト生成まで含めて“再利用可能なベースライン”にする
ベースライン構築でさらに効いてくるのは、一度作った標準を再利用できることです。Red Hat の公式 PDF では、特定ベースラインへ合わせるための remediation Ansible Playbook の生成や、後で適用する Bash スクリプトの生成が章立てで整理されています。これは単に「今の1台を直せる」という話ではなく、同じ方針を別の環境へ横展開しやすいことを意味します。
この再利用性は大きいです。手作業の hardening は、一度うまくいっても再現が難しい。ですが OpenSCAP ベースなら、「どのプロファイルを採用したか」「どのルールを基準にしたか」「どの修正を生成したか」が追いやすい。つまり、設定を“職人技”ではなく“資産”にできます。個人環境でも、検証用 VM、WSL、ホームサーバなど複数の Linux を触る人ほど、この差を実感しやすいはずです。
活用法4：SCAP Workbench で GUI から始める
CLI が苦手なら、SCAP Workbench から入るのもよい方法です。Red Hat は SCAP Workbench を、ローカルまたはリモートシステムに対する設定スキャン、脆弱性スキャン、remediation、レポート生成に使える GUI ツールとして説明しています。
ここでも価値は同じです。GUI であっても、単に見やすいだけではありません。プロファイル選定、結果確認、適用判断を、よりミスなく進めやすいという意味があります。とくに最初の一歩では、「どの基準を選んだか」を視覚的に確認しながら進められるのは大きい。
OpenSCAP を難しい監査ツールだと感じる人でも、SCAP Workbench を使うと「ベースラインを選び、差分を見て、揃える」という流れが掴みやすくなります。
おわりに
OpenSCAP は、監査ツールとしてだけ見ると少しもったいない道具です。私がいちばん大きいと感じる利点は、セキュアなベースライン構築を、簡単に、手間なく、そして人手由来のミスを減らしながら進められることにあります。
Linux には膨大な設定項目があります。それを一つひとつ読み解き、必要なものを選び、漏れなく適用し、複数台で揃えるのは、想像以上に大変です。OpenSCAP は、その負担をかなり軽くしてくれます。プロファイルという土台があり、レポートという差分確認手段があり、remediation という修正の仕組みがあり、さらに再利用可能な Playbook やスクリプト生成まで見据えられる。つまり、OpenSCAP は「監査結果を眺める道具」ではなく、セキュアな標準形を作るための実務的な仕組みなのです。
個人で試すなら、まずはプロファイルを知り、どれを自分のベースラインにするかを決める。次に差分を見て、必要なら remediation や生成物を使って揃える。この順番で触れると、OpenSCAP は「怖い自動 hardening ツール」ではなく、Linux を標準化された形で安全側へ寄せていくための、かなり頼もしい案内役になります。ぜひ活用してみてください。
参考
