コンテナの「中身」を疑え：Distrolessと脆弱性スキャンから見る攻撃対象領域の最小化戦略
コンテナセキュリティを語る際、多くのエンジニアが「脆弱性スキャナーをCI/CDに組み込みました」という報告で満足する。しかし、レッドチームの視点から言わせれば、それは単なる「静的な儀式」に過ぎない。CVEのスコアを追うことは重要だが、真の脅威は、OSという肥大化したレイヤーが運んでくる「攻撃者のための道具箱」そのものにある。
本稿では、単なるスキャン手法を超え、攻撃対象領域（Attack Surface）を物理的に消滅させるためのアーキテクチャ設計について深掘りする。
—
1. 脆弱性スキャンの盲点：なぜ「見つかったもの」だけでは足りないのか
TrivyやClairといったスキャナーは、OSパッケージマネージャのメタデータを参照して既知のCVEを突き合わせる。これは必須だが、以下の事実に直面したことがあるだろうか。
- ライブラリのネストによる可視性の欠如: 静的リンクされたバイナリや、アプリケーション固有のパッケージ（npm, pip, go mod）内に埋め込まれた脆弱性は、OSレベルのスキャンをすり抜ける。
- ゼロデイの放置: スキャナーは「過去の記録」を照合するツールだ。昨今のサプライチェーン攻撃では、スキャンをパスした後に、依存先ライブラリ経由でバックドアが注入されるケースが急増している。
防衛の鍵：バイナリ解析へのシフト
単にパッケージをスキャンするのではなく、生成された最終的なバイナリが、どのようなシステムコールを発行し、どのネットワークソケットを叩いているのかをプロファイリングすべきだ。例えば、strace や ebpf (Cilium Tetragon等) を用いて、ランタイム中の挙動を監視し、期待されないファイルアクセスやネットワーク接続を即座にキルするガードレイルが必要となる。
—
2. Distrolessによる攻撃対象領域の極小化
多くの開発者が Alpine Linux を軽量なベースイメージとして好むが、実戦では Alpine でさえ多すぎる。apk パッケージマネージャ、シェル（/bin/sh）、ネットワークツール（curl, wget）が含まれているからだ。
攻撃者がコンテナに侵入した際、最初に探すのは sh や curl だ。これらが存在しない環境、すなわち Distroless は、攻撃者の「横移動（Lateral Movement）」を劇的に困難にする。
Dockerfileの最適化例
以下の例は、Go言語のアプリケーションをDistrolessで構築する際のベストプラクティスだ。
# ステージ1: ビルド環境（ツールチェーンを完備）
FROM golang:1.21-bullseye AS builder
WORKDIR /app
COPY . .
# 静的リンクを行い、libcへの依存を排除する
RUN CGO_ENABLED=0 GOOS=linux go build -ldflags="-s -w" -o /my-app .
# ステージ2: 本番環境（Distroless - 実行に必要なファイルのみ）
# gcr.io/distroless/static-debian12 を使用し、シェルすら存在しない環境にする
FROM gcr.io/distroless/static-debian12:nonroot
COPY --from=builder /my-app /my-app
# ユーザー権限をroot以外に固定
USER nonroot:nonroot
# コンテナが実行するバイナリを直接指定
ENTRYPOINT ["/my-app"]この構成の最大の強みは、「シェルが起動できない」ことにある。攻撃者がリモートコード実行（RCE）の脆弱性を突き、任意のコマンドを注入しようとしても、実行可能なバイナリが一つしかないため、偵察活動（Enumeration）は瞬時に破綻する。
—
3. 生成AI時代のガードレイル：プロンプトインジェクションへの防御
最近のコンテナアーキテクチャでは、LLMをバックエンドに置くケースが増えている。ここで無視できないのがプロンプトインジェクションだ。これをコンテナレベルで防ぐには、単なるアプリケーション層のバリデーションではなく、セキュアなコンテナ境界内でのサンドボックス化が求められる。
アーキテクチャの指針
1. ネットワーク分離: LLMを呼び出すコンテナには、内部APIへのアクセス権限を与えず、Egressルールを厳格に制限する。
2. メモリ保護: seccomp プロファイルを用いて、コンテナが実行できるシステムコールを極限まで制限し、LLMの出力が万が一シェルコードとして解釈された場合でも、悪意ある操作（execve 等）ができないようにする。
/* seccompプロファイルの例: 許可するシステムコールのみをリスト化 */
{
"defaultAction": "SCMP_ACT_ERRNO",
"architectures": ["SCMP_ARCH_X86_64"],
"syscalls": [
{ "names": ["read", "write", "exit", "futex"], "action": "SCMP_ACT_ALLOW" }
]
}—
結論：守りのアーキテクチャは「引き算」である
セキュリティエンジニアとして、多くの開発現場を見てきたが、最も堅牢なシステムは「何も入っていない」システムだ。
1. Distroless化によって不要なツールを排除し、攻撃者の生存権を奪う。
2. バイナリのスキャンと実行監視によって、サプライチェーンの盲点を突く。
3. カーネルレベルの制御（seccomp/apparmor）によって、アプリケーションの挙動をガチガチに縛り上げる。
脆弱性管理とは、パッチを当てることではない。「攻撃者に何を見せ、何をさせないか」というコンテキストを設計することである。最新のサイバー脅威は常に進化しているが、OSの基本構造を利用するという攻撃の本質は変わらない。我々がやるべきは、その「土台」を極限まで削ぎ落とすことなのだ。
コメント