コンテナの「檻」を再定義する：AppArmor/SELinuxによる強制アクセス制御（MAC）の真髄
インフラエンジニアの多くが、コンテナを「軽量な仮想マシン」と誤解している。だが、実態は「ホストカーネルを共有する、ただの隔離されたプロセス」に過ぎない。名前空間（Namespaces）やコントロールグループ（cgroups）による論理的な分離は、カーネルのゼロデイ脆弱性一つでいとも簡単に突破される。
ランタイムコンテナのセキュリティにおいて、我々アーキテクトが最後に頼る砦は、カーネルレベルの強制アクセス制御（Mandatory Access Control: MAC）である。本稿では、AppArmorやSELinuxを用いたコンテナのハーデニングを、単なる「設定手順」ではなく、攻撃者の視点からどう「無力化」するかという観点で深掘りする。
—
1. なぜ「コンテナの脱獄」は防げないのか
攻撃者は、コンテナ内の脆弱なアプリケーション（例えば、最近のCVE-2024-XXXX系のようなRCE）を足がかりに、まずはコンテナ内での足場固めを行う。彼らが最初に行うのは、/proc や /sys へのアクセス、あるいはホスト側のデバイスファイルへのマッピングの探索だ。
ここでMACが機能していない場合、コンテナ内からカーネルの特定のシステムコールを呼び出し、特権昇格を狙う。AppArmorやSELinuxは、この「プロセスがシステムコールを通じてカーネルとどう対話するか」を、プロファイルという名の「物理法則」としてカーネルに刻み込む技術である。
—
2. AppArmorプロファイルの設計思想：最小権限の極致
AppArmorはパスベースの制御を行う。シンプルだが強力だ。コンテナ化されたアプリケーションに対し、一切の書き込み権限を剥奪し、読み取り専用のファイルシステムを強制する設定例を見てほしい。
# プロファイルの定義例 (etc/apparmor.d/containers/web-app)
profile docker-web-app flags=(attach_disconnected, complain) {
# 最小限のライブラリへの読み込みアクセスのみ許可
/usr/lib/** r,
/usr/bin/python3 mixr,
# 設定ファイルは読み込みのみ
/etc/app-config/ r,
/etc/app-config/** r,
# 書き込みは特定のログディレクトリと、tmpの一時ファイルのみに限定
/var/log/app/ w,
/tmp/ w,
# ネットワークの制御（Rawソケットの禁止）
deny network raw,
network tcp,
}ポイント:
deny network rawを明示することで、コンテナ内からパケット構造を偽装する攻撃（ARPスプーフィングやポートスキャン）をカーネルレベルで遮断する。complainモードで運用を開始し、auditログを徹底的に解析して「本当に必要なファイル」だけをホワイトリスト化する。この泥臭い作業こそが、攻撃者の攻撃ベクトルを物理的に塞ぐ。
—
3. SELinuxと「ラベル」の強制力
SELinuxはAppArmorと異なり、ラベルベースの制御を行う。コンテナ一つひとつに固有のコンテキスト（system_u:object_r:container_t:s0 等）を付与する。
特に、コンテナがホストのボリュームをマウントする際は要注意だ。攻撃者はマウント先のラベルを悪用してホストのファイルを読み書きしようとする。これを防ぐには、以下のようにマウント時にラベルを強制する。
# コンテナ起動時に強制的にラベルを付与する
docker run -d \
--security-opt label=type:container_t \
--security-opt label=level:s0:c123,c456 \
-v /host/data:/container/data:ro,Z \
my-secure-image注釈: :Z オプションは、マウントされたディレクトリにプライベートなラベルを再帰的に付与する。これにより、他のコンテナやホストプロセスが同じファイルに触れることを防ぐ「隔離の二重化」が完成する。
—
4. チーフホワイトハッカーの視点：アーキテクチャへの統合
単にプロファイルを適用するだけでは不十分だ。現代のインフラでは、以下の観点が監査の鍵となる。
1. 生成AIによるプロファイル生成の罠:
現在、AIを用いてAppArmorプロファイルを生成する試みがあるが、AIは「アプリケーションの論理的な脆弱性（例: ログ出力のインジェクション）」までは理解しない。生成されたプロファイルが、意図せず exec を許可していないか、あるいはライブラリの動的リンクを制限しすぎていないか、必ず人間がコードレビューを行うこと。
2. 耐量子暗号とランタイム:
将来的に、コンテナ間通信の暗号化に耐量子暗号（PQC）を採用する際、MACによる制御は「暗号化されていない通信フロー」を隔離する最後の壁となる。TLSライブラリがPQCにアップデートされても、そのライブラリ自体が侵害されれば終わりだからだ。MACは、アプリケーションの「振る舞い」を縛るため、暗号化アルゴリズムとは別次元の防御層として機能する。
3. 監査ログの異常検知:
auditd が出力する denied ログを SIEM（SplunkやElastic Stack）に流し込み、特定のコンテナが執拗に /etc/shadow や /proc/kallsyms にアクセスしようとしていないかを可視化せよ。MACが弾いたログは、攻撃者が「そこに何かがある」と確信してアクセスを試みている、極めて精度の高い攻撃シグナルである。
—
結論：セキュリティは「設定」ではなく「規律」である
AppArmorやSELinuxは、インフラの構築を面倒にする。しかし、脆弱性（CVE）は必ず発生する。ソフトウェアのバグを完璧にゼロにすることは不可能だが、バグを悪用した際の「爆発の範囲（Blast Radius）」をプロファイル一つで数キロバイトのメモリ空間に閉じ込めることは可能だ。
技術は常に進化し、攻撃手法は巧妙化する。しかし、カーネルがリソースへのアクセスを仲介するというOSの基本設計が変わらない限り、MACは最強の防衛手段であり続ける。設計書に「MAC適用済み」と書くだけで満足せず、その中身が本当に「最小権限」であるか、今一度、プロファイルの行間を読み解いてほしい。
コメント