カーネルモジュール署名検証の本番有効化｜既存ドライバ影響確認とロールバック設計

カーネルモジュール署名検証（module signature enforcement）は、ロードされるカーネルモジュールが信頼された鍵で署名されていることを強制する仕組みです。セキュリティ要件が厳しい環境で有効化を検討する場面が増えていますが、既存のサードパーティドライバやOSSドライバが突然ロード不能になるリスクを見落とすと、本番障害に直結します。本記事では「有効化前の影響調査」から「設定」「検証」「切り戻し設計」まで、1本で完結する運用シナリオを整理します。

署名検証の仕組みと有効化モードを理解する

Linuxカーネルのモジュール署名検証は、大きく3つの動作レベルに分かれます。

• 署名なし・検証なし（デフォルト）：署名の有無を問わずモジュールをロード可能。
• 警告モード（CONFIG_MODULE_SIG=y / TAINT_UNSIGNED_MODULE）：署名のないモジュールはロード可能だが、カーネルに「汚染フラグ」が立つ。dmesgに警告が出る。
• 強制モード（CONFIG_MODULE_SIG_FORCE=y / module.sig_enforce=1）：署名のないモジュールは一切ロードできない。

UEFI Secure Bootが有効な環境では、多くのディストリビューションが配布するカーネルはデフォルトで強制モードに近い挙動をとります。ただし「Secure Bootが有効だから署名検証も有効」とは限らず、独自ビルドのカーネルやSecure Boot無効の環境では明示的に設定が必要です。2026年現在、RHEL 9系・Ubuntu 22.04 LTS以降・openSUSE Leap 15.5以降はいずれも標準カーネルでSHIM経由のSecure Bootが有効な場合に署名検証が自動的に強制されます。まずは現在の状態を確認するところから始めます。

# 署名強制モードが有効かどうかを確認
cat /sys/module/module/parameters/sig_enforce

# Secure Boot 状態の確認（mokutilが使える環境）
mokutil --sb-state

# カーネルの設定を確認
grep -E "MODULE_SIG" /boot/config-$(uname -r)

sig_enforce が 1 であれば強制モードが有効、0 であれば無効です。Secure Bootが有効でも sig_enforce が 0 というケースはあり得るため、両者を独立して確認する習慣が重要です。

有効化前の影響調査：ロードされているモジュールの署名状態を洗い出す

強制モードに切り替える前に、現在ロードされているモジュールの署名状態を確認することが最重要ステップです。ここを怠ると、サーバ再起動後にNICドライバやGPUドライバがロードできず、ネットワーク断・グラフィック障害が発生します。

現在ロードされているモジュール一覧のうち、署名がないもの（または失効・未検証のもの）を抽出するには、/sys/module/ 以下の taint ファイルと dmesg の組み合わせが有効です。

# 汚染フラグ(O=unsigned, E=OOT)を持つモジュールを一覧化
for mod in /sys/module/*/taint; do
  taint=$(cat "$mod" 2>/dev/null)
  [[ "$taint" == *O* || "$taint" == *E* ]] && echo "$mod: $taint"
done

# dmesgで署名関連の警告を確認
dmesg | grep -iE "module.*signature|sig.*module|unsigned"

フラグ O は「署名なしモジュール」、E は「外部（Out-of-tree）モジュール」を示します。特に注意が必要なのは以下のカテゴリです。

• DKMS経由でビルドされたサードパーティドライバ（NVIDIAドライバ、VirtualBox、ZFSオンLinux等）。ディストリのDKMSがMOKで自動署名する設定になっているかを要確認。
• ベンダ提供のバイナリドライバ（一部のネットワーク機器・SAN HBAドライバ）。ベンダ側が提供する署名鍵をMOKに登録済みかどうかを確認する。
• 自社ビルドのカスタムモジュール。開発環境で作成してそのまま本番に持ち込んでいるケースで最もリスクが高い。

洗い出した未署名モジュールは「署名を付与してから有効化する」か「対象モジュールを利用しないことを確認してから有効化する」かのどちらかを判断します。この判断を先送りにしたまま有効化に進むのが最も危険なパターンです。

MOK鍵登録とDKMSの自動署名設定

サードパーティドライバをSecure Boot環境で使い続けるには、MOK（Machine Owner Key）に自社の署名鍵を登録し、DKMSビルド時に自動署名させる仕組みを整える必要があります。

まず署名用の鍵ペアを生成します。

# 鍵ペアの生成（/etc/mok/ など管理しやすいパスに配置）
openssl req -new -x509 -newkey rsa:2048 -keyout /etc/mok/mok.key \
  -out /etc/mok/mok.crt -days 3650 -subj "/CN=Local Module Signing Key/" \
  -nodes

# DER形式に変換してMOKに登録申請
openssl x509 -in /etc/mok/mok.crt -outform DER -out /etc/mok/mok.der
mokutil --import /etc/mok/mok.der

mokutil --import 実行後は再起動時にUEFI MOK管理画面が表示され、設定したパスフレーズを入力して鍵を承認します。これは物理コンソールまたはIPMI/iDRAC等のリモートコンソールが必要な操作です。クラウド環境（EC2・GCP等）ではSecure BootとMOK管理の扱いがベアメタルと異なるため、プラットフォームのドキュメントを別途確認してください。

MOK登録後、DKMSが自動署名を使うよう設定します。RHEL/AlmaLinux/Rocky Linux系では /etc/dkms/framework.conf に以下を追記します。

mok_signing_key="/etc/mok/mok.key"
mok_certificate="/etc/mok/mok.crt"

Ubuntu系では /etc/dkms/sign_helper.sh が署名処理を担います。既存DKMSモジュールを再ビルドして署名を付与する場合は dkms autoinstall を実行します。

署名強制モードの有効化と検証手順

影響調査と署名対応が完了したら、段階的に有効化します。カーネルコマンドラインパラメータ module.sig_enforce=1 を追加する方法が、再起動なしでの試験やGRUBでの制御に向いています。

GRUBの場合、/etc/default/grub の GRUB_CMDLINE_LINUX に追記します。

GRUB_CMDLINE_LINUX="... module.sig_enforce=1"

# RHEL/AlmaLinux/Rocky
grub2-mkconfig -o /boot/grub2/grub.cfg

# Ubuntu/Debian
update-grub

再起動前に、シングルユーザーモードまたはレスキューモードでの起動確認を計画に含めておくことを強く推奨します。万一ドライバがロードできない場合でも、シングルユーザーモードなら最小限のモジュールでシステムにアクセスできます。

再起動後の検証手順は以下の順序で行います。

• cat /sys/module/module/parameters/sig_enforce で 1 を確認。
• dmesg | grep -iE "sig|module.*denied" でロード拒否が発生していないかを確認。
• lsmod と事前調査のリストを突き合わせ、必要なモジュールが全て存在するかを確認。
• サービス稼働状況（systemctl --failed）とネットワーク疎通を確認。

ここで問題が出た場合は、次のセクションのロールバック手順に進みます。

ロールバック設計と運用上の注意点

署名強制を有効化した後に問題が発生した場合、最速の切り戻しはGRUBメニューからカーネルパラメータを一時的に変更することです。GRUBのエディット画面（eキー）で module.sig_enforce=1 を削除し、起動します。この変更は一時的なもので、次回再起動では元に戻ります。

恒久的なロールバックは /etc/default/grub から該当パラメータを削除し、grub2-mkconfig または update-grub を再実行します。

Secure Bootレベルでの署名強制を無効化する場合は、mokutil --disable-validation を使いますが、こちらは再起動時にMOK管理画面での操作が必要になります。クラウドや遠隔地のサーバでは物理コンソール相当のアクセス手段を事前に確保しておくことが前提条件です。

運用上の継続的な注意点として、以下を押さえておきます。

• カーネルアップデート時の再確認：メジャーバージョンアップ後にDKMSモジュールが再ビルドされ、署名が自動的に付与されるかを確認する。dkms status で全モジュールの状態を定期チェックする運用フローを整備する。
• 鍵の有効期限管理：生成時に設定した有効期限（上記例では3650日＝10年）が切れると署名検証が失敗する。証明書の更新とMOK再登録のタイミングをカレンダー管理する。
• Ansible/Puppetとの統合：フリート管理環境では鍵配布・GRUB設定変更をIaCで管理し、手動変更が混入しないようにする。

2026年の現行環境における差分と注意点

2026年現在の主要ディストリビューションでは、署名検証の扱いがいくつかの点で従来と変わっています。

RHEL 9（およびAlmaLinux 9、Rocky Linux 9）では、インストール時にSecure Bootを有効にするとSHIM + MOK管理が標準フローに組み込まれ、DKMSパッケージのインストール時に自動的にMOK鍵生成と登録ウィザードが起動します。手動で鍵を生成する手順が必要になるケースは、既存サーバのSecure Boot後付け有効化や、自社ビルドモジュールを追加する場合に限られてきました。

Ubuntu 24.04 LTS（Noble Numbat）以降では dkms パッケージが linux-modules-extra-* との依存関係を整理しており、DKMSビルド時の署名フローが改善されています。ただし、MOK鍵を管理する mokutil と実際の署名処理を行う sbsign / kmodsign は引き続き手動設定が必要な部分が残っています。

Fedora 40以降では、fedora-linux-kernel-uki（UKI：Unified Kernel Image）の採用が段階的に進んでいます。UKI環境ではカーネル・initramfs・カーネルコマンドラインが1つのEFIバイナリにまとめられるため、GRUBのカーネルパラメータを直接編集する方法が機能しなくなる場合があります。UKIを採用した環境で署名強制パラメータを変更する場合は kernel-install や bootctl を使った手順に移行が必要です。Fedoraの変化はRHELへの先行実装として現場でも注目しておく価値があります。

クラウド環境（AWS・GCP・Azure）では各プラットフォームが提供するSecure Boot対応AMI/イメージがデフォルトで署名検証を有効にしているケースが増えています。クラウド上でカスタムカーネルモジュールを使う場合、インスタンスのSecure Boot設定とMOK管理の扱いをプラットフォームごとに確認することが出発点になります。特にAWSではNitro Enclavesとの組み合わせ、Azureでは仮想TPMを使ったSecure Bootの有効化手順が整備されており、物理サーバとは異なるMOK管理フローが必要です。

カーネルモジュール署名検証の本番有効化は、セキュリティ強化として効果的な一方、準備なしに実行すると重大な障害を引き起こすリスクがあります。影響調査・署名付与・段階的有効化・ロールバック手順の4ステップを事前に計画し、変更管理のフローに組み込んだうえで進めることが、運用現場での安全な導入につながります。