コンテナの「脱獄」を封じ込める：SeccompとAppArmorによるカーネル・レイヤの防衛戦略
多くのエンジニアが「コンテナはプロセス分離されているから安全だ」という幻想を抱いている。しかし、現実のインシデントハンドリングの現場では、Linuxカーネルという「単一の巨大な共通基盤」が、防御側の最大のウィークポイントになることを誰もが知っているはずだ。
コンテナの特権昇格は、アプリケーション層のバグから始まり、最終的にはカーネルのシステムコール（syscall）の悪用に帰着する。CVE-2022-0492（cgroup v1の脆弱性）のような深刻なケースを振り返れば、ホストカーネルに対して「必要以上の権限を渡さない」ことが、アーキテクトとしての最低限の責務であることは明白だ。
今日は、教科書的な「コンテナをアップデートせよ」という空虚な助言を捨て、Linuxのカーネル機能を直接絞り込む「要塞化」の深淵に踏み込む。
—
1. Seccomp：システムコールの「ホワイトリスト」化
Linuxカーネルには約400近いシステムコールが存在するが、Webアプリケーションやマイクロサービスが日常的に使用するのはそのうちの10%にも満たない。execveやsocket、read、writeがあれば事足りる環境で、なぜptraceやkexec_loadを許可する必要があるのか？
これらを放置することは、攻撃者に「カーネルの攻撃対象領域（Attack Surface）」を広大に提供しているに等しい。DockerのデフォルトのSeccompプロファイルは確かに優秀だが、本番環境のクリティカルなワークロードには「過剰」である場合が多い。
推奨するSeccompプロファイルの最小化アプローチ
特定のコンテナに対して、許可するシステムコールを厳格に制限するJSONプロファイルを作成する。以下は、不要な機能を極限まで削ぎ落とした例だ。
{
"defaultAction": "SCMP_ACT_ERRNO", // デフォルトで拒否し、エラーを返す
"architectures": ["SCMP_ARCH_X86_64"],
"syscalls": [
{
"names": ["read", "write", "exit", "futex", "nanosleep"], // 最小限の動作に必要なコールのみ許可
"action": "SCMP_ACT_ALLOW"
}
]
}これをDocker実行時に適用するには、--security-opt seccomp=path/to/profile.jsonを付与する。運用上のコツは、SCMP_ACT_TRAPを使用して、違反が発生した際に即座にプロセスを停止させ、そのスタックトレースをログに吐き出すことだ。これにより、正常なリクエストまで遮断していないかを確認できる。
—
2. AppArmor：パスベースの強制アクセス制御
Seccompが「システムコールの制限」であるのに対し、AppArmorは「プロファイルに基づいたファイルアクセスやネットワーク能力の制限」を行う。コンテナがホストの/procや/sysを覗き見ようとした際、あるいは意図しないカーネルモジュールをロードしようとした際に、このガードレールが機能する。
AppArmorによるカーネルモジュールロードの禁止
コンテナ内からの特権昇格の常套手段は、カーネルモジュールを挿入してカーネル空間に自作のコードを注入することだ。これを防ぐためのAppArmorプロファイルは以下のようになる。
# /etc/apparmor.d/containers/my-hardened-container
profile my-hardened-container flags=(attach_disconnected,mediate_deleted) {
# プロセス間通信や不要なマウントを制限
deny mount,
deny /sys/** wklx,
deny /proc/** wklx,
# 特定のディレクトリ以外への書き込みを禁止
deny /etc/** w,
deny /usr/sbin/** w,
# カーネルモジュールのロード機能を明示的に拒否
deny capability sys_module,
}このプロファイルをapparmor_parser -rでロードし、コンテナ起動時に--security-opt apparmor=my-hardened-containerを指定する。これを導入するだけで、攻撃者が脆弱性を突いてファイルシステムを書き換えたり、カーネル機能を拡張しようとする試みを、カーネルレベルで一撃で拒絶できる。
—
3. 次世代の防衛：生成AI時代の「ガードレイル」との統合
今、我々が直面している新たな脅威は、AIエージェントがコンテナ内で実行されるケースだ。プロンプトインジェクションにより、LLMが意図せずos.system()のような関数を呼び出し、ホストOSを操作しようとするリスクがある。
ここで重要になるのが、「ランタイムセキュリティ監視（eBPF）」との連携だ。
- Falcoの導入: Seccomp/AppArmorで静的に防御しつつ、eBPFを活用して実行時の「異常なシステムコールシーケンス」を検知する。
- コンテキスト認識: AIが生成したコードが、どのプロセスから発行されたかをコンテキストとして保持し、許可されていないファイルシステムへのアクセスが発生した瞬間にコンテナを強制シャットダウンする。
アーキテクトへの提言
脆弱性管理とは、パッチを当てることではなく、「脆弱性が存在しても、それが悪用できない境界線を引くこと」である。
カーネルの機能を絞り込むことは、最初は「不便」に感じるかもしれない。しかし、その不便さこそが、攻撃者が越えられない「壁」となる。インシデント発生時に、攻撃者がシェルを取った瞬間に何もできず、ログだけが静かに異常を告げている状況こそが、我々エンジニアが目指すべき理想の要塞化だ。
貴方のプロダクトを守るのは、高価なセキュリティ製品ではなく、こうした泥臭いOSの作法への深い理解と、それをルールとして強制するアーキテクチャ設計に他ならない。次のリリースの前に、一度straceでコンテナの挙動を追ってみてほしい。そこで見えた「必要のないシステムコール」こそが、貴方のシステムの最大の脆弱性である。
コメント