セキュアブート（Secure Boot）とは？UEFIとTPMで守るファームウェアセキュリティの仕組みと企業での活用ガイド

「LinuxサーバーのUEFI設定でSecure Bootを有効にすべきか？」「セキュアブートが有効でもマルウェアに感染するケースがあると聞いた」——こうした疑問を持つインフラエンジニアや情シスの方は少なくないはずです。

セキュアブートは、OSが起動するよりも前のフェーズ——ファームウェアやブートローダーのレベルで改ざんを検証・拒否する仕組みです。従来のアンチウイルスやEDRでは検知すら困難な「ブートキット」型マルウェアに対して、現時点で最も根本的な防御手段として機能します。

この記事では、セキュアブートの仕組みとUEFI・TPMとの連携、Linuxサーバーでの確認・設定手順、中小企業の情シスが今日から取れる対策を、現場で使えるレベルで解説します。

セキュアブートとは？（概要・なぜ重要か）

セキュアブート（Secure Boot）は、コンピューターの電源を入れてOSが起動するまでの過程で、実行されるソフトウェアが「信頼できる署名」を持っているかどうかを検証する仕組みです。2012年にMicrosoftがWindows 8の認定要件として導入し、現在ではUEFIファームウェアの標準機能として広く普及しています。

従来のBIOSベースのシステムでは、コンピューターは電源投入後にブートローダーを無条件で読み込んで実行していました。ここには根本的な弱点があります。攻撃者がブートローダーに悪意あるコードを仕込んでも、OSが起動した時点では攻撃コードがすでに動作済みであり、セキュリティソフトが検知・除去するよりも先にシステムの制御を握られてしまいます。

セキュアブートはこの問題に正面から対処します。OSが起動するより前の段階で、ファームウェア自身が「今から実行しようとしているコードは信頼できるか？」を検証します。署名が確認できなければ、そのコードは実行されません。

セキュアブートはOSよりも下のレイヤーを守る技術です。一般的なマルウェア対策（アンチウイルス・EDR）とは守る対象が異なり、それらを補完する位置づけになります。

攻撃の仕組み（敵を知る）

なぜセキュアブートが必要かを理解するには、防御の対象となる攻撃を知る必要があります。

1. ブートキット攻撃とは

ブートキットは、マスターブートレコード（MBR）・ボリュームブートレコード（VBR）・UEFIのEFIシステムパーティションに感染するマルウェアの一種です。OSよりも早い段階で実行されるため、OSの保護機能や一般的なアンチウイルスを「下から」迂回できます。

感染したシステムでは、OSが起動しても攻撃者のコードがカーネルの下で動作し続けます。ログの書き換えやプロセスの隠ぺいが可能で、OSを再インストールしても、UEFIファームウェア自体に感染が及んでいる場合は除去できないケースもあります。

2. 実際に確認された脅威事例

2023年に発見された「BlackLotus」は、セキュアブートを有効にしたWindows環境でも動作するUEFIブートキットとして注目を集めました（CVE-2022-21894）。Windowsのブートマネージャーに存在する脆弱性を突き、セキュアブートの署名検証を迂回してマルウェアをロードする高度な手口でした。Microsoftのパッチとセキュアブートのブラックリスト（DBX）更新で対処されましたが、「セキュアブートが有効でも脆弱な実装があれば突破される」という教訓を残しています。

2020年発見の「BootHole」（CVE-2020-10713）は、Linuxのブートローダー「GRUB2」の設定ファイル解析に潜んでいたバッファオーバーフロー脆弱性です。セキュアブートが有効なLinuxシステムでも、細工された設定ファイルを経由して任意コードを実行できる可能性がありました。

これらの事例が示すのは、セキュアブートは強力な防御策ではあっても、「有効にしてあるから安心」ではなく、継続的なパッチ適用とDBXの更新が欠かせないということです。

セキュアブートの仕組みと防御手順

1. UEFIキー階層と署名データベース

セキュアブートはUEFI（Unified Extensible Firmware Interface）の機能として実装されています。UEFIには以下の鍵と署名データベースが存在します。

・PK（Platform Key）: プラットフォーム最上位鍵。PCメーカーが保有し、KEKの更新権限を持つ。
・KEK（Key Exchange Key）: dbおよびdbxを更新する権限を持つ鍵。OSベンダー（Microsoftなど）が保有。
・db（Signature Database）: 実行を許可するソフトウェアの署名・ハッシュを格納するホワイトリスト。
・dbx（Forbidden Signature Database）: 実行を拒否するブラックリスト。脆弱性が見つかったブートローダーの署名が追加される。

起動時、UEFIはブートローダーの署名をdbに照合します。署名が有効でなければ起動を拒否します。BlackLotusへの対処でdbxに脆弱なブートマネージャーの署名が追加されたのは、まさにこの仕組みを活用したものです。

2. 信頼チェーン（Chain of Trust）

セキュアブートは「信頼の連鎖」を起動プロセス全体に通します。

・UEFIファームウェア（信頼の起点・PKで保護）
　↓ 署名検証
・ブートローダー（EFIバイナリ）
　↓ 署名検証
・OSカーネル
　↓ 署名検証
・カーネルモジュール

各段階で署名が検証され、信頼できないコードがあれば起動が停止します。この連鎖が完全に機能している状態が、安全なシステムの起点です。デジタル署名の仕組みについては、PKI（公開鍵基盤）の解説記事も参考にしてください。

3. TPMとの連携（PCR値による整合性測定）

TPM（Trusted Platform Module）は、暗号鍵やハッシュ値を安全に保管するハードウェアチップです。マザーボードに搭載（TPM 2.0）またはCPU内蔵（fTPM）の形で提供されます。

セキュアブートとTPMを組み合わせると、より強固な整合性測定が可能になります。TPMには「PCR（Platform Configuration Register）」と呼ばれるレジスタが複数あり、起動プロセスの各段階でハッシュ値が記録されます。

・PCR0: UEFIファームウェアコアのハッシュ
・PCR4: ブートローダーのハッシュ
・PCR7: セキュアブートの状態（有効/無効、使用中の署名DBなど）

BitLockerやLinuxのTPM対応ディスク暗号化（LUKS + TPM）では、これらのPCR値が期待値と一致する場合にのみ暗号化キーを解放します。ブートローダーが改ざんされていればPCR値が変化し、ディスクの復号に失敗します。ブートキットが侵入に成功しても、暗号化データには到達できないという多層防御が実現します。

4. Linuxサーバーでのセキュアブート確認手順

現在のサーバーでセキュアブートが有効かどうかは、以下のコマンドで確認できます。

# セキュアブートの状態確認（"SecureBoot enabled" と出れば有効）
mokutil --sb-state

# ファームウェア変数から直接確認する方法
cat /sys/firmware/efi/efivars/SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c

# 起動ログからの確認
dmesg | grep -i "secure boot"

仮想マシン（KVM/QEMU・VMware・Hyper-V）の場合、UEFIモードで起動するよう設定されていないとセキュアブートは利用できません。クラウド環境（AWS EC2・Azure VM・GCP）では、インスタンスタイプと起動設定によってサポート状況が異なります。

5. カーネルモジュール署名の確認

セキュアブートが有効な環境では、カーネルモジュール（.ko ファイル）も署名が検証されます。署名のないモジュールはロードが拒否されます。

# カーネルのモジュール署名強制ポリシーを確認
cat /proc/sys/kernel/module_sig_enforce
# 1 = 署名済みモジュールのみ許可

# 特定モジュールが署名済みか確認
modinfo <モジュール名> | grep sig

# サードパーティドライバーのMOK（Machine Owner Key）登録
# （nvidia等のプロプライエタリドライバー導入時に必要）
mokutil --import /path/to/mok.cer

6. DBXの更新（継続運用で最重要）

セキュアブートの実効性を維持するには、脆弱なブートローダーを拒否するブラックリスト（DBX）を最新の状態に保つ必要があります。多くのLinuxディストリビューションではOSアップデートに含まれますが、手動で確認・適用する方法も知っておくと安心です。

# fwupdを使ったDBXアップデート（Ubuntu/Debian/RHEL系共通）
fwupdmgr get-devices
fwupdmgr update

# dbxtoolでの確認（RHEL系）
dnf install dbxtool
dbxtool --list

# UEFI変数としてDBXを更新する（メーカー提供のDBXファイルを使用）
efi-updatevar -a -c /path/to/dbxupdate.bin dbx

Linuxサーバー全体の初期セキュリティ設定については、Linuxサーバー初期セキュリティ設定チェックリストもあわせてご参照ください。また、CISベンチマークに基づく体系的な堅牢化はCIS Benchmarkを使ったLinuxサーバー堅牢化ガイドで解説しています。

中小企業でも今日からできること

セキュアブートの完全な活用にはある程度の知識が必要ですが、情シス1人体制でも取れる現実的なステップがあります。

・既存サーバー・PCのSecure Boot有効状況を棚卸しする: mokutil --sb-state を全サーバーで実行し、無効になっているものをリストアップします。新規導入機器では有効化を標準ルールにしましょう。
・OSアップデートを継続する: DBXの更新はOSアップデートの一部として配布されます。自動更新の維持だけで多くの既知の脆弱なブートローダーに対する保護が得られます。
・クラウドサーバーの「Shielded VM」オプションを確認する: AWSのNitro Enclave、Azure Trusted LaunchのvTPM、Google CloudのShielded VMなど、クラウド各社はセキュアブート相当の機能を提供しています。既存VMの設定を確認し、未有効のものは有効化を検討してください。
・新規調達時にTPM 2.0搭載を要件に含める: 調達仕様書にTPM 2.0搭載を必須要件として加えるだけで、将来のディスク暗号化との組み合わせがスムーズになります。
・カスタムカーネルモジュールの署名手順を文書化する: サードパーティのドライバーや自社開発モジュールを使用している場合、MOK登録の手順をドキュメントとして整備しておきます。

Linuxサーバーのセキュリティ設定については、姉妹サイトLinuxMaster.JPでもファイル権限管理やサービスの堅牢化手順を詳しく解説しています。

よくある誤解と注意点

【誤解1】セキュアブートを有効にするとLinuxが使えなくなる

かつてはサードパーティドライバーの署名問題からLinuxとの相性が悪い時期もありましたが、現在では主要ディストリビューション（RHEL・Ubuntu・SUSE等）はMicrosoftに承認された「shim」を使ってセキュアブートに対応しています。ほとんどの環境では有効にしたままLinuxを問題なく使えます。

【誤解2】セキュアブートがあればマルウェア対策は不要

セキュアブートが守るのは「起動プロセスの整合性」に限定されます。OSが起動した後のアプリケーション層の攻撃（SQLインジェクション・フィッシング・ランサムウェア等）にはまったく効果がありません。多層防御の一層として位置づけましょう。

【注意】UEFI設定変更は慎重に

セキュアブートの設定変更はUEFI設定画面から行います。誤操作でPKをクリアしたり、Setup Modeに移行したりすると、起動不能になるリスクがあります。変更前に必ず現在の設定をメモし、リカバリーメディアを準備してから作業してください。

【注意】検証環境でも無効化したままにしない

「検証機だから無効にしておいた」ブートローダーに感染したマルウェアが、ネットワークを通じて本番環境に横展開するリスクは現実にあります。開発・検証環境でも本番同等のセキュリティポリシーを適用することを推奨します。

本記事のまとめ

セキュアブートは「有効にしたら終わり」ではなく、DBXの更新・TPMとの組み合わせ・カーネルモジュールの管理を継続することで初めて実効性を発揮します。まずは手元のサーバーで mokutil --sb-state を実行し、現状を把握するところから始めてみてください。