LinuxのAppArmor入門｜プロファイル設定でアプリケーションのアクセスを制御する方法

「SELinuxは難しすぎて結局Permissiveにしている」――そんな声をよく耳にします。SELinuxの強力さは認めつつも、設定の複雑さに挫折した経験がある方は少なくないでしょう。

Ubuntu/Debian系のLinuxには、SELinuxとは異なるアプローチで強制アクセス制御（MAC）を実現するAppArmorという仕組みが標準搭載されています。ファイルパスベースのシンプルなルール記述で、アプリケーションがアクセスできるリソースを厳密に制限できます。

この記事では、AppArmorの基本的な仕組みから、プロファイルの読み方、自作プロファイルの作成手順、運用上の注意点まで、現場で今日から使えるレベルで解説します。

AppArmorとは？なぜ重要なのか

AppArmor（Application Armor）とは、Linuxカーネルのセキュリティモジュール（LSM: Linux Security Modules）を利用した強制アクセス制御の仕組みです。各アプリケーションに「プロファイル」と呼ばれるアクセス制御ルールを適用し、許可されていないファイルやネットワークリソースへのアクセスをカーネルレベルで遮断します。

従来のLinuxのパーミッション（DAC: 任意アクセス制御）だけでは、rootで実行されるプロセスが侵害された場合にシステム全体が危険にさらされます。AppArmorはこの弱点を補い、たとえroot権限で動くプロセスであっても、プロファイルで許可されていない操作はブロックします。

・Webサーバーの保護: Apacheやnginxが侵害されても、/etc/shadowや/home配下への読み取りを防止できます
・データベースの封じ込め: MySQLやPostgreSQLがアクセスできるディレクトリをデータファイルと設定ファイルに限定できます
・コンテナとの併用: DockerやLXDはAppArmorプロファイルを標準でサポートしており、コンテナの隔離を強化できます
・ゼロデイ攻撃への備え: アプリケーションの脆弱性が悪用されても、プロファイル外の操作は実行できないため被害を局所化できます

Ubuntu 7.10以降はAppArmorがデフォルトで有効化されており、多くのサービス用プロファイルが標準で提供されています。すでに「使える状態」になっているのに活用していないのは、鍵を持っているのに施錠しないようなものです。

AppArmorとSELinuxの違い

Linux上の強制アクセス制御には、AppArmorとSELinuxの2つの選択肢があります。どちらを選ぶかは、使用しているディストリビューションと運用体制で決まります。

AppArmorは「プロファイルがあるプロセスだけを制限する」という設計です。つまり、プロファイルが存在しないプロセスには何も制限がかかりません。一方のSELinuxは、すべてのプロセスとファイルにラベルを付与し、ポリシーに基づいて全体を制御します。

セキュリティの網羅性ではSELinuxが上回りますが、運用のしやすさとトラブルシューティングの容易さではAppArmorに分があります。中小企業の情シス担当者が限られた時間で導入するなら、AppArmorの方が現実的な選択肢です。

AppArmorの基本操作と状態確認

まずは、AppArmorの現在の状態を確認する方法から押さえましょう。

1. AppArmorの稼働状態を確認する

# AppArmorの稼働状態を確認
sudo aa-status

# 出力例:
# apparmor module is loaded.
# 47 profiles are loaded.
# 47 profiles are in enforce mode.
#    /snap/snapd/...
#    /usr/sbin/mysqld
#    ...
# 0 profiles are in complain mode.
# 12 processes have profiles defined.
# 12 processes are in enforce mode.

aa-statusの出力は3つのポイントを確認してください。

・profiles are loaded: 読み込まれているプロファイルの総数です
・enforce mode: アクセス制御が有効に動作しているプロファイルの数です
・complain mode: 違反をログに記録するだけで、実際にはブロックしないプロファイルの数です

2. AppArmorのモード

AppArmorの各プロファイルは、以下の3つのモードのいずれかで動作します。

# 特定のプロファイルをcomplainモードに変更
sudo aa-complain /etc/apparmor.d/usr.sbin.mysqld

# 特定のプロファイルをenforceモードに変更
sudo aa-enforce /etc/apparmor.d/usr.sbin.mysqld

# 特定のプロファイルを一時的に無効化
sudo aa-disable /etc/apparmor.d/usr.sbin.mysqld

3. 必要なツールのインストール

AppArmorの管理ツールは、Ubuntu/Debianでは以下のパッケージで提供されています。

# プロファイル作成・管理ツールのインストール
sudo apt install apparmor-utils

# aa-genprof, aa-logprof, aa-complain, aa-enforce 等が使えるようになる

プロファイルの構造と読み方

AppArmorのプロファイルは /etc/apparmor.d/ ディレクトリに格納されています。プロファイルのファイル名は、対象プログラムのパスをドットに置き換えた形式です（例: /usr/sbin/mysqld → usr.sbin.mysqld）。

1. プロファイルの基本構文

# /etc/apparmor.d/usr.sbin.example の構文例

#include <tunables/global>

/usr/sbin/example {
  #include <abstractions/base>
  #include <abstractions/nameservice>

  # 実行ファイル自体の読み取り許可
  /usr/sbin/example mr,

  # 設定ファイルの読み取り許可
  /etc/example/** r,

  # ログファイルへの書き込み許可
  /var/log/example/*.log w,

  # データディレクトリの読み書き許可
  /var/lib/example/** rw,

  # PIDファイルの作成許可
  /run/example.pid rw,

  # ネットワークアクセスの許可
  network inet stream,
  network inet dgram,
}

2. アクセス権限の記号

プロファイル内のパス指定の末尾に付く記号が、許可するアクセスの種類を表します。

3. グロブパターン

・*（アスタリスク）: ディレクトリ内のファイル名にマッチします。/etc/example/* は /etc/example/config にマッチしますが、/etc/example/sub/config にはマッチしません
・**（ダブルアスタリスク）: サブディレクトリを含むすべてのパスにマッチします。/var/lib/example/** は /var/lib/example/data/2024/01.dat にもマッチします
・?（クエスチョン）: 任意の1文字にマッチします
・{a,b}（波括弧）: 指定した文字列のいずれかにマッチします。/etc/example.{conf,cfg} は .conf と .cfg の両方にマッチします

プロファイルの作成手順

既存のプロファイルがないアプリケーションに対して、新しいプロファイルを作成する手順です。

1. aa-genprofによる自動生成

aa-genprofは、アプリケーションの動作を監視しながら必要なアクセス権限を自動で学習し、プロファイルの雛形を生成するツールです。

# 手順1: aa-genprofを起動（別ターミナルで対象アプリを操作する）
sudo aa-genprof /usr/sbin/example

# 以下のメッセージが表示される:
# Profiling: /usr/sbin/example
#
# [(S)can system log for AppArmor events] /
# [(F)inish]

# 手順2: 別のターミナルで対象アプリケーションを通常どおり操作する
# Webサーバーならページにアクセスする、DBならクエリを実行するなど
# すべての通常操作を一通り実行する

# 手順3: aa-genprofのターミナルに戻り「S」を入力
# ログから検出されたアクセス要求が表示される
# (A)llow: 許可 / (D)eny: 拒否 / (G)lob: パターン化
# 各アクセスについて判断を入力する

# 手順4: すべての判断が終わったら「F」（Finish）を入力
# プロファイルが /etc/apparmor.d/ に保存される

2. complainモードでのテスト運用

生成されたプロファイルは、まずcomplainモードで運用してアクセス漏れがないか確認します。

# complainモードに設定
sudo aa-complain /etc/apparmor.d/usr.sbin.example

# 通常運用を数日間続ける

# ログでアクセス違反を確認
sudo aa-logprof

# 検出された違反に対して、許可するかどうかを対話的に判断
# プロファイルが自動的に更新される

3. enforceモードへの切り替え

complainモードで十分なテスト期間を経たら、enforceモードに切り替えます。

# enforceモードに切り替え
sudo aa-enforce /etc/apparmor.d/usr.sbin.example

# 状態を確認
sudo aa-status | grep example

# プロファイルの再読み込み（変更を反映する場合）
sudo apparmor_parser -r /etc/apparmor.d/usr.sbin.example

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

AppArmorの導入は、以下の3ステップで段階的に進めるのが現実的です。

・ステップ1 — 現状の確認（5分）: sudo aa-status を実行して、現在有効なプロファイルを確認してください。Ubuntuでは初期状態でも多くのプロファイルがenforceモードで動作しています。まずは「今どこまで守られているか」を把握することが第一歩です
・ステップ2 — 標準プロファイルの追加（10分）: apparmor-profilesパッケージには、Apache、nginx、MySQL、PostgreSQL、Samba等の主要サービス用プロファイルが含まれています。sudo apt install apparmor-profiles apparmor-profiles-extra でインストールするだけで、追加の設定なしに保護範囲が広がります
・ステップ3 — 外部公開サービスの強化（30分）: インターネットに公開しているWebサーバーやメールサーバーのプロファイルを確認し、enforceモードで動作していることを確かめてください。complainモードのまま放置されているプロファイルがあれば、テスト後にenforceに切り替えます

# 追加プロファイルのインストール
sudo apt install apparmor-profiles apparmor-profiles-extra

# インストール後に状態を再確認
sudo aa-status

# complainモードのプロファイルを一覧表示
sudo aa-status | grep complain

よくある誤解と注意点

【誤解】「AppArmorを有効にすればすべてが守られる」

AppArmorはプロファイルが存在するプロセスだけを制限します。プロファイルのないアプリケーションは従来のDAC（ファイルパーミッション）のみで動作します。sudo aa-unconfined コマンドを実行すると、ネットワーク接続を持ちながらAppArmorで保護されていないプロセスを一覧表示できます。このリストに外部公開サービスが含まれていたら、優先的にプロファイルを作成してください。

【誤解】「complainモードのまま運用すれば安全」

complainモードはあくまでテスト用です。違反をログに記録するだけで実際のブロックは行いません。「ログが出ているから大丈夫」ではなく、テスト期間を設けたうえで必ずenforceモードに切り替えてください。

【注意】プロファイル変更時のサービス中断リスク

プロファイルを厳しくしすぎると、アプリケーションが正常に動作しなくなる可能性があります。設定変更時は以下の手順を守ってください。

・変更前にバックアップ: cp -p /etc/apparmor.d/usr.sbin.example /etc/apparmor.d/usr.sbin.example.bak でバックアップを取得してから編集します
・いきなりenforceにしない: プロファイルを変更したらまずcomplainモードでテストし、問題がないことを確認してからenforceに切り替えます
・ログを必ず確認: journalctl -k | grep apparmor または dmesg | grep apparmor で、DENIED（拒否）や ALLOWED（許可）のログを確認します

# AppArmorのログを確認（カーネルメッセージから抽出）
journalctl -k | grep apparmor | tail -20

# 出力例:
# audit: type=1400 audit(...): apparmor="DENIED" operation="open"
#   profile="/usr/sbin/example" name="/etc/secret.conf"
#   pid=1234 comm="example" requested_mask="r" denied_mask="r"
# → /usr/sbin/example が /etc/secret.conf を読もうとしてブロックされた

LinuxのSELinuxについては、当サイトの「SELinuxとは？仕組み・モード・設定方法をわかりやすく解説」で詳しく解説しています。Linuxの基本的なファイル権限管理については、姉妹サイトLinuxMaster.JPも参考にしてください。

本記事のまとめ

AppArmorは、Ubuntu/Debian系のLinuxに標準搭載されている強制アクセス制御の仕組みです。ファイルパスベースのシンプルなルール記述により、SELinuxと比べて導入・運用のハードルが低く、中小企業のサーバー保護に適しています。