AppArmor enforce モード段階移行｜プロファイル衝突の検出と本番ロールバック手順

enforce モードへの段階移行が必要な理由

AppArmor はカーネルレベルの強制アクセス制御（MAC）機構です。プロファイルが定義したパス・ケーパビリティ・ネットワークの組み合わせ以外の操作をプロセスに許さないため、脆弱性を突いた権限昇格やファイル漏えいの被害範囲を大幅に縮小できます。

ただし、プロファイルの精度が不十分なまま enforce モードに切り替えると、正規の操作が拒否されてサービス停止につながります。よくあるつまずきとして、complain モードで収集したログを十分に精査せず一括適用してしまい、深夜に本番サービスが静かに応答しなくなるケースがあります。

段階移行の基本的な流れは「complain（記録のみ）→ 監査ログの精査 → プロファイル修正 → enforce（実際に制御）」です。この流れを丁寧に踏むことで、突然の業務停止リスクを下げながら MAC の恩恵を得られます。

complain モードでのプロファイル衝突の検出

移行の第一歩は、対象プロセスを complain モードで稼働させながら、実運用トラフィックを流してログを収集することです。

現在の状態確認

sudo aa-status

出力の profiles in complain mode と profiles in enforce mode の行で各プロファイルの状態が確認できます。対象サービスが enforce 欄に既に入っている場合は先に complain へ戻す必要があります。

complain モードへの切り替え

sudo aa-complain /etc/apparmor.d/usr.sbin.nginx

プロファイルファイルのパスを直接指定します。複数のプロファイルをまとめて complain にする場合は以下のように書けます。

sudo aa-complain /etc/apparmor.d/*

切り替え後は実際の業務負荷をかけます。ピーク時間帯を含む最低24〜72時間の観察期間を設けると、普段は発生しにくいパスへのアクセスも記録に残ります。

監査ログの読み方

AppArmor の拒否・許可ログは /var/log/audit/audit.log（auditd 有効時）または /var/log/syslog に記録されます。complain モードでは ALLOWED というタグで出力されます。enforce に切り替えた際に実際に拒否されるのは、このタグが付いたアクセスです。

sudo grep 'apparmor="ALLOWED"' /var/log/syslog | awk '{print $NF}' | sort | uniq -c | sort -rn | head -30

出力から頻度の高いエントリを確認し、正規の操作かどうかを判断します。name= フィールドがアクセス先パス、requested_mask= が要求された権限（r=読み取り、w=書き込み、x=実行）を示します。

aa-logprof を使うと、ログを解析してプロファイルへの追記候補を対話的に提示してくれます。

sudo aa-logprof

提示されたルールを A（Allow）で承認するか D（Deny）で拒否し、最後に S（Save）で保存します。この操作でプロファイルファイルが自動更新されます。

complain → enforce への段階移行手順

aa-logprof によるプロファイル修正が完了したら、enforce への切り替えに進みます。一度にすべてのプロファイルを切り替えるのではなく、リスクの低いサービスから順に切り替えるのが一般的な方針です。

単一プロファイルの enforce 化

sudo aa-enforce /etc/apparmor.d/usr.sbin.nginx
sudo aa-status | grep -A5 'enforce mode'

切り替え直後からカーネルが制御を開始します。サービスを再起動する必要はありませんが、プロセスが既にキャッシュしているファイルディスクリプタは即座には影響を受けないため、再起動して初めて検出される拒否も存在します。重要なサービスはメンテナンスウィンドウ内で再起動してから確認するのが確実です。

プロファイルのリロード

プロファイルファイルを直接編集した後は、以下のどちらかでカーネルに読み込ませます。

# 単一プロファイルのリロード
sudo apparmor_parser -r /etc/apparmor.d/usr.sbin.nginx

# systemd 経由で全プロファイルをリロード（Ubuntu / Debian）
sudo systemctl reload apparmor

apparmor_parser -r はサービス全体を止めずに対象プロファイルだけ置き換えるため、本番環境での変更に適しています。

enforce 適用後の動作検証

enforce に切り替えた後は、実際に拒否が発生していないかを積極的に確認します。

リアルタイム監視

sudo journalctl -f | grep -i apparmor

enforce モードでの拒否は apparmor="DENIED" として記録されます。切り替え後しばらくこのコマンドを流しながらサービスを操作し、予期しない DENIED が出ていないかを確認します。

拒否の発生箇所の特定

sudo grep 'apparmor="DENIED"' /var/log/syslog | grep 'profile="usr.sbin.nginx"'

DENIED が出た場合は name= フィールドのパスと requested_mask= を確認し、正規の操作であればプロファイルにルールを追加します。不審なアクセスであればそのまま拒否させ、インシデント調査に進みます。これが enforce モードの本来の目的です。

本番ロールバック手順と判断基準

enforce 適用後にサービス障害が発生した場合、まず AppArmor に起因するかどうかを切り分けます。journalctl で DENIED が確認でき、かつ障害のタイミングと一致しているなら AppArmor が原因の可能性が高いです。

即時 complain への切り戻し

sudo aa-complain /etc/apparmor.d/usr.sbin.nginx

complain に戻すだけでカーネルによる拒否は即座に停止し、サービスは通常動作に戻ります。この操作はサービス再起動不要で数秒以内に完了するため、障害時の第一手として有効です。

プロファイルの完全無効化（緊急時）

complain への切り戻しでも問題が解消しない場合、またはプロファイル自体を一時的に外す必要がある場合は無効化します。

sudo ln -s /etc/apparmor.d/usr.sbin.nginx /etc/apparmor.d/disable/
sudo apparmor_parser -R /etc/apparmor.d/usr.sbin.nginx

-R オプションでカーネルからプロファイルをアンロードします。再び有効化するには disable/ 内のシンボリックリンクを削除してから apparmor_parser -r を実行します。

ロールバック後のプロファイル修正

complain に戻したあとは再び aa-logprof でログを解析し、不足していたルールを追加します。修正後は staging 環境などで enforce を試してから本番に適用するサイクルを繰り返すと、ロールバックのリスクを継続的に低減できます。

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

Ubuntu 24.04 LTS（Noble Numbat）および Debian 12（Bookworm）では AppArmor が標準で有効化されており、インストール直後から多くのシステムサービスに対してプロファイルが適用されています。以下に現行環境固有の注意点をまとめます。

Snap パッケージのプロファイル

Ubuntu 環境では Snap パッケージごとに AppArmor プロファイルが自動生成され、/var/lib/snapd/apparmor/profiles/ 以下に置かれます。このプロファイルは snapd が管理しており、手動で aa-enforce / aa-complain を実行しても snapd のアップデート時に上書きされます。Snap アプリの制御を調整したい場合は snap connect / snap disconnect インターフェースを経由するのが現行の推奨方法です。

Ubuntu 24.04 での userns_restrict

Ubuntu 24.04 はカーネル 6.8 以降の機能として unprivileged user namespace の制限（kernel.apparmor_restrict_unprivileged_userns）をデフォルト有効にしています。これにより、AppArmor プロファイルが存在しないプロセスでも user namespace の作成が制限されます。コンテナランタイム（Podman rootless など）の動作に影響することがあるため、移行計画に組み込む必要があります。

sysctl kernel.apparmor_restrict_unprivileged_userns

値が 1 になっている場合は有効です。この設定を変更する前に、影響範囲をセキュリティポリシーと照らし合わせて確認してください。

aa-* コマンドのパッケージ名変更

aa-logprof、aa-genprof、aa-complain などのツールは Ubuntu 24.04 / Debian 12 いずれも apparmor-utils パッケージに含まれています。最小インストール環境ではこのパッケージが入っていないことがあるため、移行作業の前に確認します。

sudo apt install apparmor-utils

月次 CVE パッチ適用後のプロファイル確認

月次の CVE パッチでシステムコンポーネントのバイナリパスや依存ライブラリが更新されると、既存の AppArmor プロファイルが新しいパスをカバーしていないために DENIED が増加するケースがあります。パッチ適用後は aa-status と直近のログを確認する運用フローを組み込むことで、パッチ起因の障害を早期に検出できます。

apt-listchanges や needrestart と組み合わせ、パッチ適用後に影響を受けたサービスを把握してから AppArmor ログを確認するとトラブルシュートの効率が上がります。