コンテナの「脱獄」を許すな：SELinux/AppArmorで構築する深層防御の極致
多くのエンジニアがコンテナを「軽量な仮想マシン」と誤解している。だが、現実は全く違う。コンテナはホストカーネルを共有する単なる「プロセス空間の分離」に過ぎない。ひとたびアプリケーションにRCE（リモートコード実行）の脆弱性が突き刺されば、攻撃者はカーネルの脆弱性（Dirty Pipeなど）を足がかりに、ホストそのものを掌握する。
これを防ぐための「最後の砦」が、強制アクセス制御（MAC）だ。今回は、単なる「設定ガイド」を超え、攻撃者がコンテナ内で直面する「見えない壁」をどう設計するか、そのアーキテクチャの真髄を語る。
なぜ「デフォルトのコンテナ」は脆弱なのか
DockerやKubernetesのデフォルト設定は、利便性のために非常に寛容だ。アプリケーションが書き込む必要のない /etc/ や /proc/ へのアクセスを、本来ならカーネルレベルで拒絶すべきだ。
攻撃者は、侵害したコンテナ内でまず /proc/self/maps を読み取り、メモリレイアウトを解析し、ROP（Return-Oriented Programming）チェーンを構築する。この「偵察活動」すら許してはならない。MACによる制限は、アプリケーションの振る舞いを「許可リスト（Allowlist）」形式で定義し、それ以外の一切を拒絶する。
AppArmorによるシステムコール・ファイルアクセス制限
AppArmorは、パスベースの制御を行う。まずは、特定のコンテナに対して「読み込み専用」かつ「特定のディレクトリのみ」に制限を加えるプロファイルを作成する。
以下は、Webアプリケーション用のプロファイルの雛形だ。
# プロファイル名: docker-nginx-custom
profile docker-nginx-custom flags=(attach_disconnected,complain) {
# 基本的なライブラリへのアクセスは許可
/usr/lib/** r,
/usr/bin/nginx ix,
# 書き込み可能なディレクトリを限定する（ここが生命線）
/var/log/nginx/ w,
/tmp/ w,
# 攻撃者が好む敏感なパスへのアクセスを明示的に拒否
deny /etc/shadow r,
deny /proc/sys/kernel/core_pattern w,
deny /sys/kernel/debug/ r,
# ネットワークアクセスの制御
network tcp,
}この設定の肝は deny を活用することだ。AppArmorはデフォルトで許可しがちだが、セキュリティアーキテクトとしては、機密性の高いパスを明示的に deny リストに追加する「多重防御」の姿勢を見せなければならない。
SELinuxによる「型（Type）」による厳格な隔離
SELinuxはパスではなく「ラベル（コンテキスト）」で制御する。これは、ファイルシステムが物理的にどこにあろうと、カーネルがそのラベルを検証するため、攻撃者がシンボリックリンク攻撃などでバイパスしようとしても無効化される。
Kubernetes環境で特定のPodに厳格なラベルを適用するには、SecurityContext を利用する。
# Podの定義におけるSELinuxラベルの適用例
spec:
securityContext:
seLinuxOptions:
level: "s0:c123,c456" # コンテナ間でリソースを隔離するMCS（Multi-Category Security）ラベル
user: "system_u"
role: "system_r"
type: "container_t"この s0:c123,c456 というラベルが重要だ。攻撃者がもしホスト上の別のプロセスにアクセスしようとしても、カーネルは「ラベルが一致しない」として、即座に EACCES エラーを返す。これは、攻撃者がどんなに巧妙な権限昇格エクスプロイトを実行しようとも、カーネルの権限管理ロジックによって物理的に遮断されることを意味する。
現代の脅威と「ガードレイル」の未来
現在、LLMをバックエンドに持つシステムでは、プロンプトインジェクションによる「モデルの乗っ取り」がリスクとして浮上している。しかし、忘れてはならないのは、AIが吐き出した悪意あるコードを「実行する」のは、依然としてコンテナ内のOSだ。
MACでOSレイヤーを固め、さらに実行環境に「非特権ユーザー（Non-root user）」のみで動作する制約を課すことで、仮にAIが不正なコマンドを実行しようとしても、システムファイルへのアクセス権限がないため、被害はコンテナのサンドボックス内で完結する。
ホワイトハッカーが現場で守るべき「鉄則」
1. Read-Only Root Filesystem: コンテナ実行時に --read-only フラグを必ず付与せよ。攻撃者が永続化（Persistence）のために悪意あるスクリプトを保存することを防ぐ。
2. Syscall Filtering: seccomp プロファイルを活用し、コンテナから呼び出せるシステムコールを execve や socket など必要最小限に絞り込め。最近のカーネルエクスプロイトは、不要なシステムコール経由でトリガーされることが多い。
3. 監査の自動化: auditd や Falco を導入し、MACでブロックされた拒否ログをリアルタイムで監視せよ。拒否ログこそが、攻撃者があなたの防衛線をテストしている「生きた証拠」だ。
セキュリティとは、完璧な壁を作ることではない。「壁を突破しようとする攻撃者のコストを、攻撃の報酬（ROI）よりも高くする」ことだ。AppArmorやSELinuxの設定は、そのコストを最大化するための最も効率的な投資である。
泥臭い設定作業かもしれない。しかし、その一行のプロファイルが、深夜のインシデント対応という「悪夢」からあなたを救うことになる。さあ、今すぐコンテナのプロファイルを監査せよ。未設定のままデプロイすることなど、プロのエンジニアとしてあってはならない。
コメント