セキュリティチームが初めてコンテナ環境をスキャンすると、しばしば数百の既知の脆弱性を発見しますが、そのほとんどがアプリケーションコードに起因しないものです。
圧倒的多数はベースイメージに付属していたパッケージから来ています。シェル、コンパイラ、デバッグユーティリティ、アプリケーションが呼び出さないライブラリなどです。コンテナを基盤としたソフトウェアサプライチェーンでは、ベースイメージが基盤となります。もしその基礎に不要な部品が付属していると、その上に構築されるすべての作業負荷がリスクを引き継ぎます。
強化イメージは、この ソフトウェアサプライチェーンのセキュリティ 問題をソースから解決します。これらは、アプリケーションが必要とするランタイムコンポーネントのみに絞られた 目的専用のベースイメージ で、継続的にパッチを当てられ、検証可能なメタデータが付属して、セキュリティチームが内部内容や構築方法を正確に確認できるようにします。
キーテイクアウト
- ほとんどのコンテナ脆弱性は、アプリケーションコードからではなく、ベースイメージから継承された不要なパッケージから生じています。
- 強化イメージはコンテナ化されたアプリケーションが必要としないすべてを除去し、攻撃対象を最大 95%削減します。
- 最小化を超えて、強化イメージには検証可能なサプライチェーンメタデータ、すなわちSBOM、ビルドプロヴィナンス、利用可能性データが含まれます。
- コンテナハードニングはVMハードニングとは異なります。これは画像の内容とビルドの整合性に焦点を当てており、OSレベルの構成ベンチマークではありません。
なぜ標準的なコンテナ画像に隠れたリスクがあるのか
標準的なLinuxディストリビューションのような汎用ベースイメージは、 400 以上のインストール済みパッケージが付属している場合があります。典型的なコンテナ化アプリケーションでは、 20 を用いて 30 します。残りは遺伝された荷物です:パッケージマネージャー、テキストエディタ、ネットワーク診断ツール、ドキュメントファイル、そしてコンテナが本来意図していなかったユースケース用のライブラリです。
未使用のパッケージはそれぞれ潜在的な攻撃対象となります。脆弱性スキャナーは、アプリがインポートや実行をしなくても、画像に実際に存在しているためフラグを立てます。その結果、セキュリティチームの能力を消耗させる信号対雑音の問題が生じています。チームが 200 発見に直面し、その 80%が実行中のワークロードタッチがないパッケージに存在すると、即時の対応が必要な本当の脆弱性はトリアージで埋もれてしまいます。
荷物自体が問題のもう半分です。本番コンテナ内のシェルは、攻撃者が初期アクセスを得た場合に作業できるインタラクティブな環境を提供します。パッケージマネージャーを使えば、追加のツールをインストールすることができます。デバッグユーティリティはネットワークのマッピングや横移動のターゲットを特定するのに役立ちます。これらは本番コンテナには適していませんが、ほとんどの汎用ベース画像ではデフォルトで出荷され、侵入時の爆発範囲を静かに拡大します。
コンテナイメージが「ハードン」になるものとは何か
では、実際にはハードドイメージとは何でしょうか?最小化が最も注目されますが、それは3つの要件のうちの1つに過ぎません。真に硬化した画像は継続的に維持され、独立して検証可能です。
簡単な定義: ハード化イメージは、アプリケーションが必要とするランタイムコンポーネントのみを搭載し、SBOM、ビルドの出所、暗号署名などの検証可能なサプライチェーンメタデータと組み合わせた最小限の連続パッチ画像です。
最小化された攻撃面
硬化画像の最も目に見える特徴は最小化です。シェル、パッケージマネージャ、デバッグツールは削除されます。アプリケーションが動作するために必要なランタイムコンポーネントのみが含まれています。これは単にスリムなベースイメージを選ぶよりも積極的です。ハード化された画像は、汎用分布から差し引くのではなく、各コンポーネントを意図的に選択してパッケージレベルから再構築されることが多いです。
その結果、CVEの表面積は劇的に小さくなります。汎用イメージには数百の既知の脆弱性が含まれているかもしれませんが、同じランタイムの強化された同等の脆弱性は通常、一桁数か全く含まれません。
継続的なパッチ適用と再構築
更新されていない硬化したイメージは、作られた日のスナップショットになります。火曜日に強化されたイメージは金曜日にはドリフトし始めることがあります。3つの上流CVEが公開され、2つのライブラリパッチがリリースされ、イメージはすでに設計されていたリスクを蓄積しています。
セキュリティには継続的な保守が必要です。上游プロジェクトの修正を監視し、パッチを取り入れるためのイメージを再構築し、明確なSLAを守った定められたリズムでこれらを行います。最も強化された画像は、四半期ごとやリリース単位のスケジュールではなく、継続的に再構築されます。これが、 本番環境向けのハードイメージ と、一度きりのDockerfileをスリム化する努力を区別するポイントです。
検証可能なサプライチェーンメタデータ
ここで、ハードなイメージは組織が採用しているより広範な サプライチェーンセキュリティのベストプラクティス とつながっています。真に硬いイメージは以下のものを含みます:
- ソフトウェア材料明細書(SBOM)で、画像内のすべてのパッケージ、バージョン、依存関係を一覧表示します
- SLSA のようなフレームワークに準拠した ビルドの出所証明 は、画像がどのように、どこで作成されたかの暗号学的証拠を提供します
- 脆弱性利用可能性交換(VEX)データで、画像内のどのCVEがソフトウェアの設定状況に基づき悪用できないかを識別します
- イメージが構築から展開の間に改ざんされていないことを検証する暗号署名
このメタデータこそが、CI/CDパイプラインにおける自動ポリシー執行を可能にします。ベースイメージに署名されたSBOMと有効な出所証明がない限り、デプロイメントをブロックするCIゲートは、イメージプロバイダーが最初からそのメタデータをサプライチェーンに組み込んでいる場合にのみ実現可能です。規制環境で運営される組織にとっては、セキュリティやコンプライアンスチームが画像の内容をリバースエンジニアリングせずに検証できるようにする手段でもあります。
コンテナハードニングとVMハードニングの違い
「ハード化されたイメージ」という用語はコンテナと仮想マシンの両方の文脈で登場しますが、両者はスタックの異なる層を扱っています。
- VMハードニング はOSの設定に焦点を当てており、不要なサービスを無効化し、ファイアウォールルールを厳格化し、ユーザー権限を制限し、カーネルパラメータを調整します。CIS Linux Benchmarksのようなフレームワークで定義されています。フルオペレーティングシステムをロックする。
- コンテナハードニングは 画像層で動作します。すなわち、何がパッケージ化されるか(最小化)、画像がどのように組み立てられたか(出所)、そして内容が透過的かどうか(SBOMや脆弱性データ)です。最低限の基盤から始め、アプリケーションが求めるものだけを積み上げていきます。
両方の実践は有効であり、しばしば共存しています。多くの組織は、コンテナホストノードにVMハードニングを適用し、そのノード上で動作するイメージにもコンテナハードニングを適用しています。両者は補完し合っていますが、技術や工具、評価基準は異なります。CISハード化されたAMIとハード化されたコンテナベースイメージは、異なるレイヤーで異なる問題を解決します。
硬化画像の評価方法
ハードと販売されているすべての画像が同じ基準を満たしているわけではありません。選択肢を評価する際には、以下の特徴に注目してください:
- 透明性: 画像にすべての荷物が見えますか?完全で機械で読みやすいSBOMは存在しますか?
- 出自: 画像がどのように、どこで作られたかを独自に確認できますか?アタトゥスは署名され、認められた枠組みに整合していますか?
- パッチのケイデンス: 上流のセキュリティ修正はどのくらいの速さで取り入れられるのでしょうか?定義されたSLAはあるのでしょうか、それともパッチ適用はベストエフォートなのでしょうか?
- 相性: これらの画像は既存のDockerファイルやCI/CDパイプラインでドロップイン代替として機能しますか?それともワークフローの変更が必要ですか?
- 脆弱性データの完全性: プロバイダーは画像をきれいに見せるためにCVEデータを抑制またはフィルタリングしているのか、それとも脆弱性の透明性を完全な脆弱性の透明性と脆弱性の文脈で公開しているのか?
これらの質問への答えは、本当に硬い画像と単に最小限の画像を区別します。最小化は必要ですが、十分ではありません。出所、規律のパッチ、透明性がなければ、小さな画像は可視性の低い攻撃対象に過ぎません。
硬化した画像とは異なるもの
「ハードンド」という用語は時に緩やかに使われることがあります。このため、どのアプローチが該当しないかを明確にする価値があります。なぜなら、これらのアプローチは問題の一部を解決しつつ、残りは露出させているからです。
- スリムやアルパインバリアントを選ぶと 画像サイズは小さくなりますが、出所やパッチングのタイミング、サプライチェーンのメタデータには対応しません。画像は小さく、硬化していません。
- スキャナーを実行してフラグが立ったパッケージを手動で除去 することは、継続的な強化イメージではなく、ポイントインタイムの修正を生み出します。次の上流のCVEは、元の場所に戻します。
- ゼロからディストロレスイメージを構築することで 最小化は達成できますが、ポートフォリオ内のすべての画像でパッチの通貨を維持するためには継続的な多大な努力が必要です。定義された再構築の頻度と検証可能なメタデータがなければ、画像数の増加に伴い保守負担が増加します。
サプライチェーンのセキュリティ面でのハードニングとは、これらすべての懸念が体系的に対処されることを意味します。イメージは最小限に抑えられ、維持され、検証可能です。
硬化画像の使い方
ハード化されたコンテナイメージは、安全なコンテナ展開の標準的な基盤となりつつあります。これらは、コンテナ脆弱性の多くが発見される根本原因、すなわち汎用ベースイメージから継承された不要なパッケージに対応しています。そして検証可能なサプライチェーンメタデータにより、セキュリティチームは現代のコンプライアンス要件に求められる透明性と監査の軌跡を提供します。
Docker Hardened Imagesは 、ランタイム、フレームワーク、データベース、インフラストラクチャコンポーネントにまたがる数千の画像にこの基盤を提供します。すべての画像にはSBOM、SLSAビルドレベル 3 出所、VEXデータ、暗号署名が付属しています。コミュニティ層は無料で、Apache 2の下でオープンです。0 使用や再配布に制限はありません。
硬化画像の全カタログをご覧 いただき、今日からベース画像の交換を始めましょう。
よくある質問
硬化画像と最小画像の違いは何ですか?
ミニマルイメージはパッケージ数が少ないですが、それは硬化の一面に過ぎません。強化イメージには、定義されたSLA、検証可能なビルドプロヴィナンス、完全なSBOM、脆弱性の脆弱性脆弱性利用性データを含む継続的なパッチ適用も含まれます。最小化は攻撃面を削減します。硬化により、残りの表面が維持され、透明で検証可能であることが保証されます。
ハード化されたイメージは既存のCI/CDパイプラインで動作しますか?
よく設計された硬化画像は、標準的なベース画像のドロップイン代替として構築されています。もしDockerfileが汎用ランタイムイメージから始まるなら、通常はビルドプロセスを変更せずに強化された同等のものを交換できます。重要なのはシェルへのアクセスです。一部のハードドイメージではシェルを完全に削除するため、シェルコマンドに依存するビルドステップはマルチステージビルドで調整が必要になることがあります。
強化イメージはどのようにしてCVE数を減らすのですか?
コンテナイメージ内のすべてのパッケージは、CVEの潜在的なソースです。アプリケーションが必要としないパッケージを削除することで、ハード化イメージはそれらのパッケージが持つ脆弱性を排除します。400パッケージを含む汎用ベースイメージには既知のCVE200存在するかもしれません。30パッケージの強化版は、脆弱なコンポーネントの大多数が含まれていなかったため、数が5未満になることもあります。これにより攻撃者が狙える範囲が大幅に縮小され、セキュリティチームのトリアージ負担が軽減されます。
