コンテナの「脱獄」を防げ！runc脆弱性から学ぶ、堅牢なインフラの守り方
こんにちは。現場の最前線でセキュリティと向き合っているエンジニアです。
皆さんは「コンテナ」と聞くと、何を思い浮かべますか？ 「アプリケーションを軽く動かせる魔法の箱」といったイメージでしょうか。確かにその通りですが、セキュリティの観点から見ると、コンテナは「ホストOSという大きな家の、特定の部屋」のようなものです。
今日は、その部屋の壁を突き破って、家全体（ホストOS）を乗っ取ろうとする悪意ある攻撃、特に runc というコンテナの心臓部に潜む脆弱性に焦点を当てて、泥棒に侵入されないための「防犯対策」を一緒に学んでいきましょう。
コンテナの「脱獄」とはどういうこと？
まず、身近な例え話をしますね。
あなたは「アパートの一室（コンテナ）」を借りて、そこで自分の趣味の作業（アプリケーションの実行）をしています。大家さん（ホストOS）は、他の住人に迷惑をかけないよう、部屋の鍵を管理し、壁を頑丈に作っています。
ところが、もしあなたが使っている「ドアの鍵（コンテナランタイム：runc）」に、「特定のタイミングで操作すると、ドアが外側から開いてしまう」という致命的な欠陥があったらどうでしょう？
悪意ある泥棒（攻撃者）は、その部屋の中から鍵を操作し、なんと「大家さんのマスターキー」を奪い取って、アパート全体を支配してしまいます。これが、CVE-2019-5736 に代表される、コンテナの「脱獄（エスケープ）」です。
なぜこれが怖いの？
コンテナが破られると、その上で動いているアプリが盗まれるだけではありません。ホストOSそのものが乗っ取られれば、同じサーバー上で動いている他の全てのコンテナ、さらにはクラウドの認証情報までもが泥棒の手の中に落ちてしまうのです。
泥棒を入れないための「3つの防犯ステップ」
「そんな恐ろしいことが起きる前に、どうやって防げばいいの？」と不安になりますよね。大丈夫です。一歩ずつ、確実に守りを固めていきましょう。
1. 「鍵」を常に最新版にアップデートする
最も重要で、かつ地味な対策です。runc の脆弱性は、基本的に「古い鍵を使っているから」発生します。
システム管理者や開発者は、OSのパッケージ管理システムを使って、常に最新のパッチを当てることが義務です。
# UbuntuやDebian系でのパッケージ更新の例
# まずはリストを最新にして、runcをアップデートします
sudo apt-get update
sudo apt-get install --only-upgrade runc
# バージョンを確認して、脆弱性が修正されたバージョン以降かチェック！
runc --version2. 「不必要な権限」を与えない（最小権限の原則）
家の中でも、普段使わない道具を出しっぱなしにしないのと同じです。コンテナを起動する際、安易に privileged: true（特権モード）を付けていませんか？
docker-compose.yml での設定例を見てみましょう。
services:
my-app:
image: my-app:latest
# 「特権モード」は、泥棒に「マスターキー」を渡すようなもの。
# 基本的に「false」にするか、記述自体を避けるのが鉄則です！
privileged: false
# 必要な機能だけを制限付きで許可する「Capabilities」を使いましょう
cap_drop:
- ALL # 一度すべての権限を剥奪してから、必要なものだけ足すのがコツ
cap_add:
- NET_BIND_SERVICE # 80番ポートなどを使うために最低限必要な権限だけ付与3. 「監視」という名の防犯カメラを設置する
万が一、誰かがドアをこじ開けようとした時に気づけるように、監視体制を整えることも大切です。
Falcoのようなツールを活用する: コンテナ内で「想定外のコマンド（例えば、突然shを起動してシステムファイルを書き換えようとする等）」が実行された時に、即座にアラートを上げる仕組みを作っておきましょう。
まとめ：セキュリティは「継続」がすべて
セキュリティ対策に「これさえやれば絶対安心」という魔法はありません。でも、「鍵を最新にする」「不要な権限を与えない」「異常にいち早く気づく」という基本的な防犯をコツコツ積み上げるだけで、攻撃者にとって「この家はセキュリティが硬すぎて、割に合わないな」と思わせることができます。
最初から完璧を目指す必要はありません。まずは、今動いているコンテナがどのバージョンの runc を使っているか、一度確認してみることから始めてみませんか？
皆さんのインフラが、今日も安全に守られていることを願っています！
コメント