RHEL系LinuxでFIPS 140準拠モードを段階的に有効化する｜影響調査・適用・切り戻し手順

FIPS 140 準拠モードとは何か、なぜ今必要か

FIPS 140（Federal Information Processing Standard 140）は、米国国立標準技術研究所（NIST）が定める暗号モジュールのセキュリティ要件です。政府機関・金融・医療・防衛関連のシステムでは、このFIPS 140への準拠が契約や法令で要求されるケースが増えています。クラウドネイティブ化が進む2026年においても、オンプレミスのRHEL系Linuxが規制対象システムの基盤として残るケースは少なくなく、「FIPS準拠モードを有効化してほしい」という要件が現場に降りてくることがあります。

RHEL系Linuxには、OSレベルでFIPS 140準拠モードを切り替えるしくみが組み込まれています。有効化すると、カーネルの暗号APIやOpenSSL・GnuTLSなどのユーザー空間ライブラリが、承認済みアルゴリズムのみを使用するよう制限されます。ただし、この制限は既存のサービスやスクリプトに影響を与える可能性があるため、やみくもに適用するのではなく、段階的な調査と検証を経て進めることが重要です。

なお、RHEL 8系まではFIPS 140-2が主な対象でしたが、RHEL 9系からはFIPS 140-3に対応したモジュールが標準となっています。この違いが既存環境とのギャップを生むこともあるため、後述の「2026年現行環境差分」の節で整理します。

有効化前の影響調査：何が動かなくなるかを把握する

FIPS準拠モードを有効化すると、承認されていない暗号アルゴリズムを使用するアプリケーションやサービスが起動拒否・接続失敗・エラー終了を起こします。事前調査なしに本番環境へ適用するのは危険です。まず影響範囲を把握することが先決です。

代表的な影響ポイントを以下に示します。

• SSH鍵の種別：RSA 1024ビット以下の鍵、DSA鍵はFIPSモードで使用不可になります。既存の~/.ssh/authorized_keysや/etc/ssh/ssh_host_*を確認し、RSA 2048ビット以上またはECDSA/Ed448への移行が必要です。
• MD5・SHA-1の使用箇所：チェックサム検証スクリプト、古いTLS設定、自己署名証明書などにMD5・SHA-1が残っている場合は接続失敗の原因になります。
• Python・Ruby・Java等のアプリケーション：言語ランタイムがシステムのOpenSSLを利用している場合、非承認アルゴリズムを呼び出すコードが実行時エラーになります。
• VPN・認証基盤：OpenVPN、FreeRADIUSなど暗号設定を持つミドルウェアは、設定ファイルのアルゴリズム指定を見直す必要があります。

影響調査の出発点として、crypto-policiesの現在の設定を確認します。

update-crypto-policies --show

出力が DEFAULT であれば、現在はFIPSモードではありません。FIPS と表示されている場合はすでに有効化済みです。また、fips-mode-setup --check コマンドで現在の状態を確認できます。

SSHホスト鍵の種別確認は以下のコマンドで行えます。

for key in /etc/ssh/ssh_host_*_key; do
  ssh-keygen -l -f "${key}" 2>/dev/null && echo "  -> ${key}"
done

RSA 1024ビットやDSA鍵が見つかった場合は、適用前に再生成が必要です。調査結果をスプレッドシート等に記録し、対応が必要な項目をすべて洗い出してから次のステップに進むことを推奨します。

RHEL系でFIPS 140準拠モードを有効化する手順

影響調査と事前対応が完了したら、実際の有効化に進みます。RHEL 8以降では fips-mode-setup コマンドが標準ツールです。このコマンドは、カーネルパラメータの設定・dracut（initramfs生成ツール）の再構築・crypto-policiesの切り替えを一括で行います。

まず、必要なパッケージがインストールされていることを確認します。

dnf install -y crypto-policies crypto-policies-scripts dracut

次に、有効化コマンドを実行します。このコマンドはrebootを要求します。

fips-mode-setup --enable

実行後、コマンドはinitramfsの再生成を行い、GRUBの起動パラメータに fips=1 を追加します。完了したら再起動します。

reboot

再起動後は次の節の検証手順に進んでください。なお、本番環境では必ずメンテナンスウィンドウを設け、コンソールアクセス（iDRAC・iLO・シリアルコンソール等）を確保した状態で実施します。SSHのみが唯一のアクセス手段である場合、鍵の互換性問題でロックアウトされるリスクがあるため、コンソールアクセスは必須です。

有効化後の動作検証

再起動後、まずFIPSモードが正常に有効化されているかを確認します。

# カーネルレベルの確認
cat /proc/sys/crypto/fips_enabled
# 1 が返ればFIPSモード有効

# crypto-policiesレベルの確認
update-crypto-policies --show
# FIPS と表示されれば正常

# fips-mode-setup による総合確認
fips-mode-setup --check

続いて、主要なサービスの動作確認を行います。SSHの再接続テストは別端末から行い、既存セッションを維持したまま確認するのが安全です。

# SSHdの状態確認
systemctl status sshd

# OpenSSLのFIPSモード確認
openssl version -a | grep -i fips
openssl speed sha256  # 承認済みアルゴリズムの動作確認

# 非承認アルゴリズムが拒否されるか確認（MD5はエラーになるはず）
echo "test" | openssl dgst -md5 2>&1

OpenSSLのMD5コマンドが Error setting digest などのエラーを返せば、FIPSモードが正しく機能しています。次に、事前調査で洗い出したサービスを順番に起動・動作確認していきます。問題が発生した場合は切り戻し手順に移行します。

Javaアプリケーションを運用している環境では、JVMのFIPSプロバイダー設定も確認が必要です。RHEL 9系ではNSSおよびBouncy CastleFIPSプロバイダーとの連携が推奨されています。

切り戻し手順と運用上の注意点

FIPSモードの無効化（切り戻し）も fips-mode-setup で行えます。ただし、切り戻し後も再起動が必要な点に注意してください。

fips-mode-setup --disable
reboot

このコマンドは、GRUBから fips=1 パラメータを削除し、crypto-policiesを DEFAULT に戻します。initramfsも再生成されます。

運用上の注意点として、以下の点が現場でよく問題になります。

• SSHホスト鍵の再生成後はknown_hostsの更新が必要：クライアント側で Host key verification failed が発生するため、接続元のknown_hostsから対象ホストのエントリを削除する必要があります。自動化ツール（Ansible等）からの接続がある場合は特に注意が必要です。
• コンテナ環境との整合性：ホストがFIPSモードになっても、コンテナ内のバイナリが非FIPSライブラリを持ち込む場合があります。コンテナイメージも ubi9-minimal などのFIPS対応イメージを使用し、整合性を保つ必要があります。
• 定期的なコンプライアンス検証：OpenSCAPやComplianceAsCode（旧scap-security-guide）を使った定期スキャンを組み合わせることで、設定ドリフトを検出できます。
• カーネル更新後のinitramfs再生成：カーネルを更新した際は dracut -f でinitramfsを再生成し、FIPSモジュールが新カーネルに引き継がれていることを確認します。

2026年現行環境での差分と注意点（RHEL 9系・AlmaLinux・Rocky Linux）

2026年時点では、RHEL 9系（およびそのダウンストリームであるAlmaLinux 9・Rocky Linux 9）が主流となっています。RHEL 8系との重要な差分を整理します。

FIPS 140-3への移行：RHEL 9系ではFIPS 140-3に対応した暗号モジュールが標準搭載されています。FIPS 140-2との主な違いは、SHA-3のサポート追加と、一部の鍵長要件の厳格化です。RHEL 8系環境からの移行では、FIPS 140-3でのみ有効な設定がある一方、RHEL 8系では動作していた一部の構成がRHEL 9系のFIPSモードで非承認となる場合があります。

Ed25519鍵の扱い：FIPS 140-3準拠のRHEL 9系では、Ed25519はFIPS承認アルゴリズムとして含まれています。一方、RHEL 8系のFIPS 140-2モードではEd25519が使用不可でした。移行先のOSバージョンに応じて、SSH鍵の選定方針が変わる点に注意が必要です。

AlmaLinux 9・Rocky Linux 9での注意点：これらのディストリビューションはRHELとバイナリ互換を目指していますが、NISCからFIPS 140の正式認定を受けているのはRHEL本体のみです。厳密な規制準拠が求められる環境では、認定を受けたモジュールとしての位置づけが異なる点を法務・コンプライアンス担当と確認することが重要です。技術的な手順は同一で動作しますが、「FIPS認定モジュールを使用している」という証跡としてはRHEL本体が必要になるケースがあります。

crypto-policies のサブポリシー活用：RHEL 9系ではcrypto-policiesのサブポリシー機能が強化されています。FIPS:OSPP（Common Criteria準拠の追加制限）やFIPS:NO-SHA1など、FIPSモードをベースに追加制限を重ねる構成が可能です。より厳格なセキュリティ要件がある場合は、サブポリシーの活用も検討に値します。

# サブポリシーの適用例（SHA-1をFIPSモード上でさらに制限する場合）
update-crypto-policies --set FIPS:NO-SHA1

FIPS 140準拠モードの有効化は、適用するだけで完結するものではありません。影響調査・段階的な適用・継続的なコンプライアンス検証をセットで運用することで、初めて実効性のあるセキュリティ対策になります。変更管理プロセスと組み合わせ、テスト環境での十分な検証を経てから本番環境に展開することを強く推奨します。