この記事の監修:宮崎智広(Linux実務・教育歴20年以上・受講者3,100名超)
この記事では、DISA STIG の基本、0.1.82 のプロファイル、RHEL のマイナーリリースごとの注意点、管理基盤を使った自動化、インストール時・イメージ作成時のハードニングまでを、Linux 管理者の作業の順に整理します。
「このままじゃマズい」と感じていませんか?
参考書を開く気力もない、同年代に取り残される不安——
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
姓・名・メールの3つだけ/30秒/解除は3秒 /
詳細はこちら
DISA STIG とは何か
DISA が発行する STIG は、米国防総省(DoD)とその他の連邦政府機関が持つ情報システムの構成要素について、標準の設定ベースラインを定めたガイドです。ソフトウェアやアプリケーションを安全に設定するための技術的な指針で、「最低限の機能(Least Functionality)」「アクセス制御」「パッチ管理」「暗号化」「監査」に関する設定を含みます。特定の脆弱性を緩和するための推奨事項もあり、システムの攻撃対象領域を減らす内容も含まれます(出典:Red Hat DISA STIG ページ)。STIG は主に米国の国家安全保障システムを対象としていますが、連邦政府機関や契約事業者に加え、米国内外の民間組織でもセキュリティの実践を強化する目的で広く使われています。DoD ネットワークに接続する情報システムには STIG への準拠が求められる、と Red Hat のブログは説明しています(出典:Red Hat ブログ)。
Red Hat の製品で STIG が公開されているものとして、Red Hat DISA STIG ページには RHEL のほか、Red Hat OpenShift Container Platform、Red Hat Ansible Automation Controller、JBoss Enterprise Application Platform が挙げられています。STIG の一覧そのものは、DISA が DoD Cyber Exchange で公開しています。
RHEL 10 向け STIG の公開と scap-security-guide 0.1.82 の対応内容
Red Hat のブログによると、DISA は 2026年3月に RHEL 10 向けの STIG を公開しました。その後の scap-security-guide バージョン 0.1.82 で、RHEL 10 の DISA STIG プロファイルが公式の DISA STIG に従う形になり、DISA STIG Benchmark V1R2 に整合しました(出典:SCAP Security Guide リリースノート)。同じ 0.1.82 では、RHEL 8 の DISA STIG プロファイルが V2R8 に、RHEL 9 のプロファイルが V2R9 に更新されています。RHEL 10 の修正としては、修復のスクリプトが新しいファイルやディレクトリを作るときに、所有者とパーミッションを明示的に設定するよう改善されました。
RHEL 10 のシステムを DISA STIG に合わせるときは、次のプロファイル ID を使います。stig_gui は「Server with GUI」のパッケージセットで構成したシステム向けです(出典:Red Hat DISA STIG ページ)。
xccdf_org.ssgproject.content_profile_stig
xccdf_org.ssgproject.content_profile_stig_gui
このプロファイルは、FIPS モードでインストールしたシステムを前提としています。FIPS モードへの切り替えは、RHEL 10 のセキュリティハードニングのドキュメントにある「Switching RHEL to FIPS mode」の章で説明されています。
リリースノートから読む RHEL 10 向けの修正
scap-security-guide は、Linux システム向けのセキュリティポリシーをまとめたパッケージです。中身は実務的なハードニングの助言の一覧で、該当する場合は政府の要件と結び付けられています(出典:SCAP Security Guide リリースノート)。版ごとの変更は、リリースノートに RHEL のメジャーバージョン別に書かれています。0.1.82 の RHEL 10 向けの主な修正は次の2つです。
・修復のスクリプトが、新しいファイルやディレクトリを作るときに所有者とパーミッションを明示的に設定するようになった
・ルール package_sssd_installed に、そのルールを設ける理由(Rationale)の説明が追加された
その1つ前の 0.1.81 でも、RHEL 10 向けに次の修正が入っています。
・ルール file_permission_user_init_files と file_permission_user_init_files_root に、準拠していないファイルに設定済みのパーミッションを失わずに修復する方法の説明文が追加された
・ログインバナーを確認する複数のルールで、改行を含む独自の文言を指定できるようになった
同じ 0.1.82 では、RHEL 9 の STIG プロファイルにルール crypto_policy_not_overridden が追加され、STIG の要件 RHEL-09-672020 との対応が改善されています。RHEL 8・RHEL 9・RHEL 10 の変更は、リリースノートの中でメジャーバージョン別の節に分けて書かれているので、自分の環境の版の節を確かめてください。
使う前に確かめること:マイナーリリースごとのプロファイル
Red Hat DISA STIG ページは、RHEL のシステムを設定するときは、そのマイナーリリースに含まれているプロファイルだけを使うよう求めています。ハードニングの部品や SCAP のコンテンツが、それより前の版と互換でない場合があるためです。同じページの「RHEL release/Current baseline」の表では、RHEL 10.1 と RHEL 10.0 のどちらも、ベースラインが「vendor」と記載されています。つまり、手元の RHEL 10 のマイナーリリースに入っているプロファイルが、どの版の STIG に合わせたものかは、表からは読み取れません。0.1.82 の V1R2 対応のプロファイルで評価する前に、自分のシステムのマイナーリリースと、そこに含まれる scap-security-guide のプロファイルを確かめてから進めてください。
Red Hat の製品には DISA STIG の方針に合わせるための機能が組み込まれており、Red Hat のシステム管理の製品と連携すると、マシンの設定を要件に合わせられます。ただし、Red Hat の製品に備わるコンプライアンスの機能を使っても、その結果が完全な準拠を意味するわけではありません。結果を必ず見直し、それぞれの導入環境の事情を考慮する必要がある、と Red Hat DISA STIG ページは明記しています。
OpenSCAP と管理基盤による評価と修復
Red Hat のブログは、評価と修復を繰り返し行う手段として、OpenSCAP(oscap)、Red Hat Satellite、Red Hat Lightspeed を挙げています。プロファイルは stig または stig_gui を選び、Lightspeed、Satellite、または oscap のコマンドラインから、システムを DISA STIG V1R2 に照らして評価・修復します。oscap の具体的な使い方は、RHEL 10 のセキュリティハードニングのドキュメントにある「Scanning the system for configuration compliance」の章で確認してください。Red Hat Satellite
Satellite では、コンプライアンスのポリシーを計画・設定し、ホストに展開して、各ホストの準拠状況を監視できます。詳細は製品ドキュメント「Managing Security Compliance」にあります。
Red Hat Lightspeed(旧 Red Hat Insights)
Lightspeed のコンプライアンスサービスでは、独自のセキュリティポリシーの作成と管理、システムの準拠状態の監視、不一致の修復を画面上で行えます。作ったポリシーを image builder で使い、追加のシステムを展開することもできます(出典:Red Hat DISA STIG ページ)。
RHEL 10 STIG Ansible ロール
ルールの適用を Ansible で行う場合は、公式の RHEL 10 STIG Ansible Galaxy ロールを使えます(出典:Red Hat ブログ)。
Red Hat のブログは、これらの仕組みの効果として、コンプライアンスの報告を簡単にし、文書の整備を進めることで、Authority to Operate(ATO)までの道のりを速められる点も挙げています(出典:Red Hat ブログ)。
インストール時・イメージ作成時のハードニング
導入済みのシステムを後から修復する方法とは別に、最初から STIG に合わせた状態で構築する方法もあります。Red Hat のブログは、Kickstart、RHEL image builder、RHEL image mode を使ってインストール時やイメージ作成時にハードニングすることで、STIG への整合を手作業の後片付けにしない、と説明しています(出典:Red Hat ブログ)。Kickstart ベースのインストール
Kickstart を使うインストールの方法は、RHEL 10 のセキュリティガイドの「Performing a hardened installation of RHEL with Kickstart」で説明されています(出典:Red Hat DISA STIG ページ)。
RHEL image builder による事前ハードニングイメージ
RHEL image builder を使うと、最初から DISA STIG に合わせて設定したシステムをインストールできます。RHEL 10 の手順は「Creating pre-hardened images with RHEL image builder OpenSCAP integration」にあります。この仕組みは Red Hat Insights にも組み込まれています(出典:Red Hat DISA STIG ページ)。
RHEL image mode
Red Hat のブログは、RHEL image mode もインストール時・イメージ作成時のハードニングの手段として挙げています。image mode については RHEL 10.2/9.8 新機能の解説記事も参照してください。
本記事のまとめ
・DISA は 2026年3月に RHEL 10 向けの STIG を公開し、その後の scap-security-guide 0.1.82 で RHEL 10 の DISA STIG プロファイルが Benchmark V1R2 に整合しました・プロファイル ID は content_profile_stig と content_profile_stig_gui。どちらも FIPS モードでインストールしたシステムが前提です
・使うのは、そのマイナーリリースに含まれるプロファイルだけです。RHEL 10.1 と 10.0 のベースラインは表で「vendor」となっているため、評価の前に手元のマイナーリリースとプロファイルを確かめてください
・評価と修復は oscap、Satellite、Lightspeed で行え、ルールの適用には公式の Ansible ロールも使えます
・Kickstart、image builder、image mode で、インストール時から STIG に合わせて構築できます
・ツールの結果は完全な準拠を意味しません。結果を見直し、自分の環境の事情に照らして判断する必要があります
STIG の原本は DoD Cyber Exchange で確認できます。
DISA STIG や OpenSCAP の設定を現場で確実に動かすには、土台となる Linux の知識が欠かせません。
FIPS モード・パーミッション管理・パッケージの版の確認といった基礎を押さえておくと、コンプライアンスの結果を自分で読み解けるようになります。
ネットの切れ端の情報をコピペするだけでなく、現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、『Linuxサーバー構築入門マニュアル(図解60P)』を完全無料でプレゼントしています。
「独学の時間がもったいない」「プロから直接、現場の技術を最短で学びたい」という本気の方には、2日で実務レベルのスキルが身につく【初心者向けハンズオンセミナー】も開催しています。
暗記不要・1時間後にはサーバーが動く
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
姓・名・メールの3つだけ/30秒/解除は3秒 / 詳細はこちら
Linux無料マニュアル(図解60P)
名前とメールで30秒登録
- 前のページへ:CVE-2026-46242「Bad Epoll」速報|一般ユーザーがrootを奪うLinuxカーネル脆弱性と防御手順
- この記事の属するカテゴリ:Linux情報・技術・セキュリティへ戻る

無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。
登録無料・いつでも解除できます