コンテナは「消える」からこそ怖い。揮発性環境におけるフォレンジックと要塞化のリアル
現場でインシデントレスポンスを担当していると、よくこんな相談を受ける。「コンテナが乗っ取られたみたいだけど、どうやって調査すればいい？」と。
残念ながら、コンテナが停止・削除された瞬間に、攻撃者が残した痕跡（メモリ上のペイロードや一時ディレクトリのスクリプト）は跡形もなく消え去る。クラウドネイティブな環境では、従来の「サーバーにログインしてログを見る」というアプローチは通用しない。
今回は、攻撃者の視点に立ちつつ、現場で泥臭く生き残るための「コンテナ・フォレンジックと要塞化」の勘所を伝授する。
—
1. コンテナ侵害のリアル：なぜ「揮発性」が攻撃者の味方になるのか
攻撃者は、コンテナの「一過性」を悪用する。例えば、RCE（リモートコード実行）で侵入し、メモリ上でバックドアを動かし、目的を達したら exit する。あるいは、ログを stdout 経由で飛ばし、コンテナを即座に破棄して証跡を隠滅する。
彼らの常套手段はこれだ：
1. アプリ脆弱性（Command Injection等）を突く。
2. メモリ上でマルウェアをダウンロード・実行。
3. コンテナ内からクラウドメタデータサービスへアクセスし、IAMロールの権限を奪取。
この時、コンテナを docker stop してしまうと、すべてが終わる。調査のために必要なのは「削除せず、隔離する」ことだ。
—
2. インシデント発生！その瞬間の「隔離」手順
コンテナが怪しい挙動を示した時、慌てて削除ボタンを押してはいけない。以下の手順で「保存」する。
ステップ1：コンテナを一時停止（Freeze）する
メモリダンプを取るために、コンテナを凍結する。
# 実行中のコンテナを一時停止（プロセスを止めるが消さない）
docker pause <container_id>ステップ2：コンテナの変更点をコミットし、調査用イメージにする
実行中のコンテナから、新しいイメージを作成し、別の安全な環境で調査できるようにする。
# 実行中のコンテナ状態をキャプチャ
docker commit <container_id> suspicious_container_investigation:v1ステップ3：ネットワークからの隔離
セキュリティグループを書き換え、インバウンド・アウトバウンドを全遮断する。これで外部C&Cサーバーとの通信を物理的に断つ。
—
3. 「やられない」ための要塞化：実装サンプル
インシデントを「調査する」段階に持ち込ませないのが、真のセキュリティだ。まずは、コンテナの特権を剥奪せよ。
A. Nginxによるリクエスト制限（WAF代わりの防御）
コンテナ内のWebサーバーで、怪しいリクエスト（SQLiやパストラバーサル）を弾く設定だ。
# /etc/nginx/conf.d/security.conf
# 悪意あるリクエストを即座に403で返す
location ~ (\.php|\.env|\.git|\.aws) {
deny all;
return 403;
}
# 頻繁なアクセスを制限する（DoS対策）
limit_req_zone $binary_remote_addr zone=one:10m rate=10r/s;B. Pythonによる「メタデータ奪取」防止
クラウド上のコンテナが、IMDS（Instance Metadata Service）を叩いてIAM権限を盗むのを防ぐには、アプリケーション側でリクエストをフィルタリングする。
import requests
def secure_request(url):
# AWS/GCPのメタデータエンドポイントへのアクセスを禁止する
forbidden_hosts = ["169.254.169.254"]
# URLを解析して内部IPへのアクセスをブロック
if any(host in url for host in forbidden_hosts):
raise Exception("Security Alert: Unauthorized access to metadata service")
return requests.get(url)C. Dockerfileの要塞化（最小権限）
コンテナを root で動かすのは論外だ。必ず非特権ユーザーを指定せよ。
# 権限のないユーザーを作成
RUN addgroup -S appgroup && adduser -S appuser -G appgroup
# ファイルシステムを読み取り専用にする（実行時に指定するが、設計も重要）
# コンテナ起動時に --read-only オプションを付与することを推奨
USER appuser—
4. 最後に：エンジニアへの提言
セキュリティは「ツールを入れたら終わり」ではない。インシデントは必ず起きる。重要なのは、「いつ起きても、必要なログと状態を即座に保全できるか」という準備だ。
1. ログの外部転送: コンテナ内の /var/log は信じるな。Fluentd等でログを即座に別環境へ送れ。
2. イメージの署名: Docker Content Trust を使い、改ざんされたイメージが動かないようにする。
3. IAMの最小化: コンテナに付与するIAMロールは、特定のS3バケットへの書き込み権限のみ、といった粒度まで絞り込む。
「便利」と「セキュア」は常にトレードオフだ。しかし、設計段階で「攻撃者は必ず侵入してくる」という前提（ゼロトラスト）に立てば、自ずと取るべき手は見えてくる。
君たちのコードが、明日も堅牢であることを祈っている。何かあれば、またいつでも相談してくれ。
コメント