コアを守る：なぜファイルの整合性が重要なのか
自動化されたボットネットが1時間に5,000回以上のSSHログイン試行でサーバーを執拗に攻撃する様子を目の当たりにしてから、私はセキュリティを単なる境界防御の問題として捉えるのをやめました。その夜、私は厳しい教訓を学びました。侵入を防ぐのは最初のハードルに過ぎないということです。攻撃者が侵入に成功した場合、次の行動はほぼ間違いなくシステムバイナリの変更か、永続的なバックドアの設置です。標準的なセキュリティツールでは、被害が出るまでこうした微細な変更を見逃してしまうことがよくあります。
Linux Integrity Measurement Architecture（IMA）は、検知機能をカーネル自体に組み込むことで、この状況を一変させます。スケジュールに従って動作するユーザー空間のスキャナーとは異なり、IMAはゲートキーパー（門番）として機能します。システムがファイルを実行または開く前にすべてのファイルを計測し、システムの状態をライブログとして保持します。コアファイルが改ざんされた場合、IMAはそれがアクセスされた瞬間にそれを捉えます。
アプローチの比較：IMA vs. 従来のファイル整合性ツール
私が最初にファイル整合性について調査したときは、AIDEやTripwireのようなツールを使用していました。これらは優れたツールですが、根本的な「ブラインドスポット（空白期間）」が存在します。カーネルレベルのアプローチと比較してみましょう。
ユーザー空間スキャニング（AIDE、Tripwire）
- ワークフロー： これらのツールは、cronジョブを介して、保存されたハッシュのデータベースとファイルシステムを比較します。
- ギャップ： これらは「リアクティブ（事後対応的）」です。攻撃者が午後2時5分に
/usr/bin/sudoを変更し、スキャンが午後3時に実行される場合、侵入者は55分間、検知されることなく自由に行動できてしまいます。 - 脆弱性： 賢い攻撃者は、スキャナーのバイナリ自体やローカルデータベースを書き換えて、足跡を隠すことができます。
カーネルレベルの計測（IMA）
- ワークフロー： ファイルがアクセスされる際、カーネルがリアルタイムでファイルハッシュを計算します。
- ギャップ： なし。計測は実行または読み取りのまさにその瞬間に行われます。
- 脆弱性： IMAをバイパスすることは非常に困難です。ロジックはカーネル内にあり、Trusted Platform Module（TPM）のようなハードウェアベースのセキュリティを使用してロックダウンできるからです。
Linux IMAを使用するメリットとデメリット
ファイルレベルで「ゼロトラスト」アーキテクチャに移行することは、セキュリティ上の大きな勝利ですが、代償がないわけではありません。高度な保護とシステムリソースのバランスを取る必要があります。
メリット
- 不変の証拠： 実行されたすべてのバイナリの暗号化ログが得られます。
- ハードウェアによる信頼： IMAは計測値をTPMに「拡張（extend）」できます。これにより、たとえroot権限を持つ攻撃者であっても、ハードウェアレジスタをクリアせずにログを偽造することは不可能になります。
- きめ細かな制御： 「全か無か」のアプローチに縛られる必要はありません。rootが所有するファイルなど、リスクの高いファイルのみを計測するポリシーを作成できます。
課題
- パフォーマンスのオーバーヘッド： ファイルのハッシュ化はCPUサイクルを消費します。負荷の高いデータベースサーバーでは、重いI/O操作中にCPU使用率が2%から5%増加することを想定しておく必要があります。
- 設定のリスク： IMAはデリケートです。ポリシーに小さなミスがあると、システムがハングしたり、不可欠なサービスの起動を拒否したりすることがあります。
- ログの増大： 稼働率の高いシステムでは、IMAログは急速に増大します。データをローテーションしたり、リモートのログサーバーに転送したりする計画が必要です。
推奨設定：TPMを活用したIMA
私は常にIMAをTPMチップに紐付けることを推奨しています。ハードウェアとの連携がない場合、IMAのリストはRAM上に保持されるため、高度なカーネルルートキットによって改ざんされる可能性があります。TPMを使用すると、カーネルはすべてのファイルのハッシュをPCR 10（Platform Configuration Register）に送信します。これにより、リモートサーバーで検証可能な「信頼の連鎖（Chain of Trust）」が構築され、ログが消去されていないことを保証できます。
実装ガイド：IMAの設定方法
Ubuntu、RHEL、Debianなどの最新ディストリビューションの多くは、カーネルでIMAをサポートしていますが、通常は休止状態です。ここでは、IMAを有効化するための手順を説明します。
1. カーネルのサポートを確認する
カーネルがIMAに対応しているか確認します。以下のコマンドを実行してブート設定をチェックしてください。
grep CONFIG_IMA /boot/config-$(uname -r)CONFIG_IMA=y と表示されることを確認してください。もし ‘n’ と表示される場合は、別のカーネルに切り替えるか再コンパイルする必要がありますが、最新のクラウドイメージでは稀なケースです。
2. ブートパラメータ経由でIMAを有効にする
IMAは起動時に特定の指示を必要とします。GRUB設定ファイルを開きます。
sudo nano /etc/default/grubGRUB_CMDLINE_LINUX_DEFAULT を探し、tcb（Trusted Computing Base）ポリシーを追加してハッシュアルゴリズムを設定します。古いSHA1よりもSHA256を推奨します。
GRUB_CMDLINE_LINUX_DEFAULT="... ima_policy=tcb ima_hash=sha256"tcb ポリシーは優れた出発点です。実行されるすべてのプログラムと、rootによって読み取り用に開かれたすべてのファイルを計測します。変更を適用して再起動します。
sudo update-grub
sudo reboot3. 計測リストを確認する
システムが再起動すると、IMAは即座に記録を開始します。以下のコマンドでライブ計測リストを覗き見ることができます。
sudo cat /sys/kernel/security/ima/ascii_runtime_measurements | head -n 15出力にはPCRインデックス、テンプレートハッシュ、ファイルパスが表示されます。以下のようになります。
10 4967... ima-ng sha256:e3b0c442... /usr/bin/ls
10 5a2d... ima-ng sha256:f72a12b... /etc/shadow4. カスタムポリシーへの移行
tcb ポリシーはノイズが多くなる可能性があります。本番環境では、パフォーマンスへの影響を抑えるために焦点を絞るのが一般的です。ima_policy という名前のファイルでカスタムポリシーを定義できます。
# 実行前にすべてのバイナリを計測する
measure func=BPRM_CHECK
# rootが触れるすべてのファイルを計測する
measure func=FILE_CHECK mask=MAY_READ subj_user=root
# カーネルモジュールを計測する
measure func=MODULE_CHECKこれをロードするには、内容をセキュリティファイルシステムにリダイレクトする必要があります。注意：このファイルの記述ミスはシステムのロックアップにつながる可能性があります。
sudo cp ima_policy /sys/kernel/security/ima/policy本番環境におけるベストプラクティス
ラボ環境でIMAを設定するのは簡単ですが、本番環境ではより慎重な運用が求められます。私の経験則をいくつか紹介します。
- SHA1の使用をやめる： 多くの古いチュートリアルではSHA1が使われていますが、暗号学的に脆弱です。ブートパラメータで必ず明示的に
ima_hash=sha256を設定してください。 - メモリ使用量を監視する： 計測リストはカーネルメモリ上に保持され、再起動時にのみリセットされます。サーバーを500日以上稼働させ、数百万のユニークなスクリプトを実行する場合は、RAM使用量を監視してください。
- リモートアテステーション（遠隔検証）を利用する： ローカルログは閲覧可能ですが、リモートアテステーションはそれらが真正であることを証明します。Keylime のようなツールを使用すると、別の安全なサーバーからTPMの計測値を監視できます。
- EVMとのレイヤー化： IMAはファイルの内容を計測しますが、Extended Verification Module（EVM）はパーミッションや所有権などのメタデータを保護します。これらを併用することで、最大の防御力を発揮します。
IMAの設定は最初は手間に感じるかもしれません。しかし、セキュリティ面での投資対効果（ROI）は否定できないほど高いものです。カーネルがあらゆる実行ファイルを能動的に監視していると知ることで、ユーザー空間のツールでは決して得られないレベルの安心感を得ることができます。
