fapolicydでサーバーの実行ポリシーを本番設計する｜RHEL系段階導入とロールバック

fapolicydは、Linux上で動作する実行制御デーモンです。ファイルの実行やライブラリのロードをホワイトリスト／ブラックリストのルールセットで制御し、未署名・未登録のバイナリが起動することを防ぎます。RHEL 8.1以降で標準搭載され、月次CVEサイクルへの対応が本格化した2025〜2026年以降、EDRと組み合わせた多層防御の一環として採用が広がっています。

ただし、fapolicydはいきなりenforceモードで投入すると正規プロセスまで遮断し、サービス停止を招きます。本記事では、permissiveモードでの観察→ルール精査→enforcing移行という段階導入の設計と、万が一のロールバック手順を実務の流れとして整理します。

fapolicydが実行制御を行う仕組み

fapolicydの動作は大きく2つの要素で成立しています。ひとつは信頼データベース（trust database）、もうひとつはルールセット（rules）です。

信頼データベースには「このファイルは実行を許可してよい」と判断するための情報が格納されます。デフォルトではRPMデータベース（/var/lib/rpm）が信頼源として使われ、rpm -Vで整合性が確認できるパッケージ由来のバイナリは自動的に信頼済みとして登録されます。RPM管理外のバイナリ、たとえば手動で配置したシェルスクリプトやサードパーティのエージェントバイナリは、別途fapolicyd-cli --file addで信頼データベースへ追加しなければなりません。

ルールセットは/etc/fapolicyd/rules.d/以下に配置されたファイルで定義します。RHEL 9系ではルールファイルが番号プレフィックス付きで分割管理されており、10-languages.rulesや95-allow-open.rulesのように適用優先度が制御されています。ルールはトップダウンで評価され、最初にマッチしたルールが適用されます。この「最初マッチ」の性質を理解していないと、意図せず広い許可ルールが先に適用されてセキュリティが形骸化する、あるいは逆に重要なプロセスが先にdenyされるという事故が起きます。

permissiveモードでの観察フェーズ

本番への適用前に、まずpermissiveモードで稼働させて「どのバイナリが遮断対象になるか」を把握します。permissiveモードではルールに違反した実行を許可しつつ、auditログへ記録するだけにとどまります。

permissiveモードの有効化

# /etc/fapolicyd/fapolicyd.conf を編集
permissive = 1

# デーモン再起動
systemctl restart fapolicyd

permissive = 1に設定するとdenyルールにマッチしても実行はブロックされず、/var/log/audit/audit.logにtype=FANOTIFYのイベントとして記録されます。

観察ログの読み方と信頼DB追加

観察期間中にdenyイベントが記録されたバイナリを洗い出すには、以下のようにauditログを絞り込みます。

ausearch -m fanotify --raw | aureport --file -i | grep deny

出力されたパスを確認し、RPM管理外のバイナリであれば信頼データベースへ追加します。

# 個別ファイルを信頼DBへ追加
fapolicyd-cli --file add /opt/company/agent/bin/agent

# 信頼DBの更新を反映
fapolicyd-cli --update

観察期間は最低でも1〜2週間取ることが一般的です。月次バッチや夜間ジョブなど普段は実行されないパスを見落とすリスクがあるためです。

enforcingモードへの移行と段階的な本番投入

観察フェーズでdenyログが出なくなった（あるいは精査済みになった）段階で、enforcingモードへ移行します。いきなり全サーバーで切り替えるのではなく、ロール単位・サブネット単位で段階的に展開する設計が安全です。

enforcingへの切り替え

# /etc/fapolicyd/fapolicyd.conf
permissive = 0

systemctl restart fapolicyd

# 動作確認
systemctl status fapolicyd
fapolicyd-cli --dump-db | head -20

切り替え直後は必ず主要プロセスの起動・再起動テストを実施します。想定例として、Webサーバー（httpd/nginx）・DBサーバー（mysqld/postgresql）・監視エージェントの順に再起動して応答を確認するといった手順が考えられます。

Ansibleを使った段階展開の例（想定例）

実環境での段階展開には、AnsibleやSaltのようなCM（構成管理）ツールを使うことが多いです。想定例として、以下のようなインベントリ分割で段階管理ができます。

# インベントリ例（想定）
[fapolicyd_permissive]
web-stg01

[fapolicyd_enforcing]
web-prod01
web-prod02

ステージング環境でenforcing動作を一定期間確認したのち、本番グループへ段階的にロールアウトする流れです。タスクのpermissive = {{ fapolicyd_mode }}のように変数化すると、インベントリ変数で制御できます。

ポリシー検証と日常運用のチェックポイント

enforcingに移行した後も、パッケージアップデートや新規バイナリ配置のたびに信頼DBの整合性が崩れる可能性があります。以下のチェックを定期的に組み込むことを推奨します。

• RPMアップデート後は信頼DB再構築を実施する：dnf updateでバイナリが置き換わると信頼DBとハッシュが一致しなくなります。fapolicyd-cli --updateをポストスクリプトやDNFプラグインで自動実行するよう構成します。
• auditログのdenyイベントを監視に組み込む：ZabbixやPrometheusのログモニタリングでtype=FANOTIFY.*denyパターンを検知ルールに追加しておくと、予期しない遮断を素早く検出できます。
• 信頼DBの内容を定期的にダンプして差分確認する：fapolicyd-cli --dump-db > /var/log/fapolicyd/db-snapshot.txtを月次で取得し、前回との差分を確認することで意図しない信頼追加を検出できます。

また、fapolicydはデーモン自体が停止するとポリシーが無効化されます。systemctl enable fapolicydでブート時の自動起動を確実に有効化し、死活監視の対象にも含めてください。

ロールバック手順と緊急時の対応

enforcingモードで予期しない遮断が発生した場合、焦らず以下の順序で対処します。

即時緩和：permissiveに戻す

# ランタイムで一時的にpermissiveへ（再起動不要、効果は即時）
fapolicyd-cli --permissive

# または設定ファイルを書き換えて再起動
sed -i 's/^permissive = 0/permissive = 1/' /etc/fapolicyd/fapolicyd.conf
systemctl restart fapolicyd

fapolicyd-cli --permissiveはRHEL 9系で利用可能なランタイム切り替えです。設定ファイルを変更せずに動作だけ変更できるため、緊急時の初動として有効です。ただしサーバー再起動後は設定ファイルの値に戻るため、恒久的に戻す場合はconfファイルも変更してください。

デーモンの一時停止

permissiveへの切り替えでも解消しない障害（fapolicyd自体のクラッシュループ等）では、デーモンを停止します。

systemctl stop fapolicyd
# 自動起動も一時無効化
systemctl disable fapolicyd

停止後は/var/log/fapolicyd/fapolicyd.logとjournalctl -u fapolicydでクラッシュ原因を確認します。よくあるつまずきとして、信頼DBが破損した状態での起動失敗があります。この場合はrm -f /var/lib/fapolicyd/fapolicyd.trustでキャッシュを削除し、デーモン起動時に再構築させます。

ロールバック後のポストモーテム

ロールバック後は必ずauditログを遡り、どのバイナリがdenyされてサービス影響を起こしたかを特定します。信頼DBへの追加またはルールの修正を行ったうえで、再度permissiveで観察してからenforcing再投入の判断をするサイクルが安全です。

2026年現行環境での差分と注意点

2025〜2026年にかけて、RHEL系ディストリのfapolicyd実装にいくつか注目すべき変化があります。

RHEL 9.4以降のIMAとの統合強化：IMA（Integrity Measurement Architecture）との連携が深まり、IMAポリシーで署名検証を行ったうえでfapolicydがアクセス制御する多層構成が組みやすくなっています。ただしIMAを有効化するにはカーネルパラメータの追加が必要で、再起動を伴うため既存環境への後付けには計画が必要です。

AlmaLinux / Rocky Linux 9系での動作確認：RHEL互換ディストリでもfapolicydは同梱されており、基本的な設定ファイルの互換性はありますが、独自のSELinuxポリシーとの組み合わせでAVCdenyが追加で発生するケースが報告されています。SELinuxをpermissiveにして切り分ける手順を事前に周知しておくとトラブルシュートが円滑です。

コンテナ環境での制約：podmanやDockerで動くコンテナ内バイナリはホストのfapolicydポリシーの対象外です。コンテナランタイム（conmon、runc等）がホスト上で実行されるため、それらのバイナリは信頼DBに登録が必要ですが、コンテナ内部の実行は制御できません。コンテナワークロードの実行制御にはSELinux MCSラベルやSeccompプロファイルを組み合わせる設計が現行標準です。

月次CVEサイクルとの連携：CVEパッチ適用でバイナリが更新されるたびに信頼DBの再構築が必要です。dnf-automaticを使った自動更新環境では、/etc/dnf/automatic.confのapply_updatesと合わせてfapolicyd-cliのupdateをsystemdのパスユニットやDNFプラグインで連動させる構成が、2026年時点での実用的な対処法として広まっています。手動管理に頼るとCVE適用後のサービス障害につながりやすいため、自動化の優先度は高めに設定することを推奨します。