「ビルドツールは本番に持ち込むな」― Dockerマルチステージビルドで攻撃者の“足掛かり”を消し去る技術
現場でインシデント対応をしていると、つくづく思うことがある。侵入されたサーバーのDockerイメージを調査すると、決まって「不要なツール」が転がっているんだ。`gcc`、`git`、`curl`、そしてデバッグ用のライブラリ群。攻撃者にとって、これらは喉から手が出るほど欲しい「武器庫」そのものだ。
今回は、OWASP Top 10の「セキュリティ設定の不備」や「脆弱なコンポーネントの使用」を根本から封じ込める、Dockerマルチステージビルドの実践論を語る。
—
1. なぜ「オールインワン」のDockerイメージが危険なのか
多くのエンジニアがやりがちなのが、開発から実行までを一つのイメージで完結させる「モノリシックなDockerfile」だ。
悪い例：全部入りイメージ
FROM python:3.9
RUN apt-get update && apt-get install -y gcc git # ビルドに必要だったツールが残る
COPY . /app
WORKDIR /app
RUN pip install -r requirements.txt
CMD [“python”, “app.py”]
このイメージで何が起きるか？ 攻撃者はWebアプリの脆弱性（例えば、最近多いリモートコード実行：RCE）を突いてコンテナ内に侵入した瞬間、`gcc`を使ってその場で悪意のあるCコードをコンパイルし、`git`で外部の攻撃サーバーと通信してペイロードを落とし込む。
ビルドに必要な環境が実行環境に残っている状態は、泥棒に「鍵のかかっていない工具箱」をプレゼントしているのと同じだ。
—
2. マルチステージビルド：攻撃者の選択肢を奪う
マルチステージビルドの哲学はシンプルだ。「ビルドに必要なもの」と「実行に必要なもの」を完全に分離する。最終的なイメージには、プログラムの実行バイナリと最小限のランタイムしか含めない。
実践：Pythonアプリのセキュアなビルド例
以下のDockerfileを見てほしい。`builder`ステージでライブラリをビルドし、最終的な`runner`ステージには成果物だけをコピーしている。
— ステージ1: ビルド環境 —
FROM python:3.9-slim AS builder
ビルドに必要なツールをインストール
RUN apt-get update && apt-get install -y –no-install-recommends gcc python3-dev
依存関係をインストール
WORKDIR /build
COPY requirements.txt .
RUN pip install –user -r requirements.txt
— ステージ2: 実行環境 —
FROM python:3.9-slim AS runner
実行に必要な最小限の環境のみ
WORKDIR /app
実行ユーザーをrootから変更（重要：特権分離）
RUN groupadd -r appuser && useradd -r -g appuser appuser
USER appuser
builderステージからライブラリだけをコピー
COPY –from=builder /root/.local /home/appuser/.local
COPY –from=builder /build /app
COPY app.py .
パスを通す
ENV PATH=/home/appuser/.local/bin:$PATH
CMD [“python”, “app.py”]
—
3. この構成が「最強」である理由
① 攻撃対象領域（Attack Surface）の劇的な縮小
もし攻撃者がアプリの脆弱性を突いて侵入したとしても、コンテナ内には`gcc`も`git`も存在しない。`curl`すら入っていない可能性がある。攻撃者は「何もない場所」で、限られたコマンドしか使えず、新たなツールをインストールすることもできない。
② 特権分離の徹底
`USER appuser`の設定により、万が一侵入されても、コンテナのルート権限を奪取してホストOSに逃げ出す（コンテナエスケープ）ハードルを極限まで高めている。
③ イメージサイズの削減
不要なビルドツールを含まないため、イメージサイズが軽量化される。これは、脆弱性スキャナがスキャンする範囲を狭め、CI/CDのパイプラインも高速化させるという副次的なメリットも生む。
—
4. 現場のセキュリティ担当者からの提言
マルチステージビルドを導入するだけではまだ半分だ。現場でさらに堅牢にするためのTipsを記しておく。
1. Distrolessイメージの検討:
さらに厳格にするなら、Googleが提供する `gcr.io/distroless/python3` などを検討してほしい。シェル（`/bin/sh`）すら含まれていないため、侵入後のシェル操作を完全に封じることができる。
2. スキャンは日常に:
`Trivy` や `Snyk` といったツールをCIに組み込み、「ビルドしたイメージに脆弱性がないか」をリリース前に自動チェックするフローは必須だ。
3. WAFとの併用:
どれだけコンテナを堅牢にしても、アプリケーションコードにRCEの脆弱性があれば意味がない。AWS WAFやCloud Armorで、不正なリクエストをエッジで弾く多層防御を忘れないこと。
最後に
セキュリティは「これだけやれば終わり」というものではない。だが、「攻撃者の手間を増やす」という設計思想を持つだけで、君が守るべきシステムは格段に強くなる。
「便利だから」と開発環境のゴミを本番に持ち込むのはもうやめよう。今日から君のDockerfileを、攻撃者が絶望するほどクリーンなものに変えていくんだ。健闘を祈る。
コメント