ハードニングされたイメージとは、安全なソフトウェアサプライチェーンを目的に設計されたコンテナイメージのカテゴリーを指す。柔軟性を重視する標準のベースイメージとは異なり、設計段階からCVEの発生を極力抑え、攻撃対象領域を削減している。

　Dockerfileに「FROM ubuntu:22.04」と記述すると、メンテナーが含めた全てのパッケージや設定ファイル、バイナリを継承することになる。本番環境から見れば、その大半は不要な負荷となる。

　Node.jsアプリケーションを実行するコンテナに実行時のCコンパイラは不要だ。ハードニングされたNode.jsイメージには、基本的にNode.jsのランタイムのみが含まれる。パッケージマネージャやbash、curl、sshなどのツールは除外される。Dockerfileの別ステージで依存関係を導入するなどイメージ構築の手法を少し見直す必要があるものの、脆弱性を最小限に抑えた安全なイメージを生成できる。

　要するに、アプリケーションの実行に必要な最小限の要素だけを含めるという考え方だ。現在では複数のベンダーがハードニング済みイメージを提供し、継続的なパッチ適用を担っている。

これまで標準にならなかった理由

　コンテナ技術の黎明（れいめい）期で、コンテナは軽量な仮想マシンとして扱われていた。初期のDockerは、セキュリティよりも移植性や開発者の利便性を優先して最適化されていた。

　開発者は手軽にコンテナを起動して対話形式でデバッグし、必要なパッケージをその場で導入できた。この使いやすさが普及を促した一方で、イメージの肥大化を招いた。

　イメージのハードニングはワークロードごとに異なる。Java向けとGo言語向けでは構成が大きく変わるため、作成と維持には多大な投資が必要だった。

　しかし現在では、CVEの存在を無視することはできない。汎用イメージに個別にパッチを適用し続ける運用が、終わりのない作業であると企業は気付き始めている。

　こうした背景から、インフラ担当者の負担を軽減するサブスクリプション型のイメージハードニングサービスが台頭してきた。

ベンダー選定のポイント

　ここ2年ほどで、ハードニングされたイメージの利用は推奨事項から業界標準の要件へと変化した。各ベンダーは独自のアプローチや理念、ビジネスモデルに基づいたソリューションを提供している。代表的な製品には以下のようなものがある。

BellSoft Hardened Images

　BellSoftはエンタープライズJava環境に注力し、ランタイム層のハードニングを提供する。同社のイメージは「Alpaquita Linux」をベースにしており、C標準ライブラリとしてmuslとglibcの両方を選択できる。

　この仕様は、従来のGNU Cライブラリに依存するアプリケーションを書き換えることなく、軽量なベースイメージへ移行する上で役立つ。

　同社はOS層からコンテナランタイム、イメージ層までを一括したSLA（サービス水準合意）で管理するため、調達や契約手続きを簡素化できる。

Chainguard Hardened Images

　Chainguardは、シェルやパッケージマネジャーを含まない「ディストロレス」の概念を取り入れた独立Linuxディストリビューション「Wolfi」を採用している。ビルドエンジンを活用し、上流の最新ソースから毎日イメージを再構築することでCVEを常にほぼゼロに保つ。

　無償版と企業向けの有償版を用意しており、複雑な構成を持つマイクロサービスの運用に適している。

Docker Hardened Images（DHI）

　Docker Hardened Imagesはディストロレスの構成を基本としつつ、ビルドパイプラインを経由することで堅牢性が損なわれる課題に対処している。

　ルート証明書の追加や社内ツールの組み込みといったカスタマイズに対応しながら、SLSAレベル3の来歴証明やセキュリティ検証、DockerのSLAを維持できる。

　中核となるイメージ群は「Apache 2.0」ライセンスの下で無償提供されている。標準のベースイメージから柔軟に移行したいチームに向いている。

Red Hatの「UBI」とCanonicalの「Chiseled Ubuntu」

　Red HatとCanonicalは、企業向けLinuxの機能を絞り込みつつ基盤となるパッケージ管理機能を残すアプローチを取る。最小限のコンテナが持つ安全性と、商用OSの安定性やコンプライアンス要件を両立させている。

　完全なディストロレス構成やChainguardと比較すると、含まれるCVEの数は多くなる傾向がある。また、ライセンス体系の違いによる運用上の調整が必要になる場合もある。

ハードニングされたコンテナを採用する際のリスク

　ハードニングされたコンテナの利用には留意すべき課題も存在する。

　第一に、デバッグの難度が高くなる点だ。実行中のコンテナ内にシェルがないため、コマンドを実行して内部から障害原因を調査できない。実行中のコンテナの名前空間に管理用ツールを外部からアタッチして調査する必要がある。

　第二に、サーバ環境の不足による影響だ。ハードニングされたコンテナでは多くのシステム環境が削ぎ落とされているため、実行時にパッケージを導入するアプリや、特定のシステムツールを前提とするアプリは動作しなくなる。

　第三に、ベンダーへの依存だ。サードパーティーのベースイメージを採用することは、パッチ適用やスキャンの責任を外部に委託することを意味する。SLAの遅延や上流での仕様変更など運用上のリスクを考慮しなければならない。

　ハードニングされたベースイメージへの切り替えは、設定を1行書き換えるだけで完結するものではない。既存資産の棚卸しや動作確認、CI/CDパイプラインの更新を伴う作業となる。

運用チームが取るべき適応策

　新しい運用体制へ移行する際は、以下の実践が効果的だ。

1. 使用中のイメージを把握する：本番環境で使用している全てのベースイメージを棚卸しする。スキャン結果を記録し、移行計画や優先順位を判断する基準とする
2. デバッグ手法を見直す：Kubernetes環境ではエフェメラルコンテナの活用を進め、一元化されたログ収集や分散トレイシング、ヘルスチェックのエンドポイント整備に投資する
3. 本番環境での旧イメージを遮断する：「Kyverno」や「OPA Gatekeeper」などのアドミッションコントローラーを導入し、承認されていないベースイメージの本番適用を防止する
4. 定期的な保守を計画する：ハードニングされたイメージを導入するだけでなく、ベースイメージを自動で定期更新する仕組みを構築する