次の方法で共有

ビルド ステージの概要

  • [アーティクル]

コンテナー イメージの構築は、コンテナー セキュア サプライ チェーン (CSSC) フレームワークの第 3 段階です。 一部の企業では外部ソースから基本イメージを直接プルしますが、署名や構成証明に照らしてイメージを検証せずに、内部カタログから基本イメージをプルする企業もあります。 基本イメージが常に内部カタログからプルされ、使用前に検証されるようにすることが重要です。 イメージをビルドした後、一部の企業は脆弱性やマルウェアのスキャンなしでそれらを公開し、SBOM などの構成証明を生成できません。これは、後続のサプライ チェーンの段階では検証できません。 生成されたコンテナー イメージが信頼され、エンタープライズ ポリシーに準拠していることを確認することが不可欠です。

Microsoft の Containers Secure Supply Chain (CSSC) フレームワークは、コンテナー イメージを構築する必要性を特定し、信頼された準拠イメージを安全に構築するのに役立つ一連のベスト プラクティスとツールを提供します。 この記事では、CSSC フレームワークのビルド ステージで使用できる目的、ベスト プラクティス、およびツールについて説明します。

背景

現在、企業はさまざまなアプローチを使用して、準拠しているコンテナー イメージを安全に構築しています。 コンテナー イメージをビルドする前に、内部チームは内部 ゴールデン レジストリから基本イメージをプルする必要があります。 ただし、これらのイメージは使用前に検証されません。ゴールデン レジストリが侵害され、イメージが悪意を持つ可能性がある場合は推奨されません。 また、企業は、品質を確保するためにコンテナー イメージに追加されるライブラリとパッケージのソースも制御します。

コンテナー イメージをビルドした後、企業はコンテナー イメージが準拠していることを確認するために追加のメタデータを生成します。 一部の企業では、SLSA の実証のドキュメントを活用して、コンテナー イメージの生成を担当する Git コミットと、それが再現可能かどうかを把握しています。 他のユーザーは、Docker ラベルを使用して、コンテナー イメージの所有者と、イメージのコミットを担当するユーザーに証明を提供します。 一部の企業では、脆弱性やマルウェアの画像をスキャンし、それに応じてレポートを生成します。

CSSC フレームワークのビルド ステージでは、公開前に信頼できる準拠しているコンテナー イメージを生成するために実装する必要がある一連の手順とセキュリティコントロールが推奨されます。

Microsoft では、準拠しているコンテナー イメージを安全に構築するための次のプラクティスをお勧めします。

  • 攻撃対象領域を減らし、セキュリティを強化するために、内部カタログからのみ基本イメージをプルします。
  • 使用可能な場合は、基本イメージの署名と構成証明を確認してから、それらを使用して信頼でき、準拠していることを確認します。
  • ディストリビューションレス イメージ には、追加のソフトウェアまたはオペレーティング システム コンポーネントなしで、アプリケーションとそのランタイムの依存関係のみが含まれます。 ディストリビューションレス イメージを基本イメージとして使用して、攻撃対象領域を減らし、セキュリティを強化します。
  • ビルド プラットフォームまたはサービスに最小限の特権アクセスを適用して、承認されたユーザーのみが変更または変更を行えるようにすることで、不正アクセス、データ侵害、その他のセキュリティ インシデントのリスクを軽減します。
  • ビルド後にコンテナー イメージで脆弱性とマルウェアをスキャンし、セキュリティの脆弱性が発生するリスクを軽減します。
  • SBOM や実績メタデータなどの追加のメタデータを使用して、ビルド後にコンテナー イメージを強化します。
  • エンタープライズ キーを使用してビルド後にコンテナー イメージと関連メタデータに署名し、整合性を確保し、内部使用の承認の信頼されたスタンプを提供します。
  • 既知の脆弱性に対処するために、タイムリーにコンテナー イメージにパッチを適用します。
  • 脆弱性とセキュリティ修正に対応するために、依存関係を合理的に最新の状態に保ちます。

準拠しているコンテナー イメージを構築するためのワークフロー

ビルド ステージには、組織とセキュリティ ポリシーに準拠したコンテナー イメージを作成するためのワークフローが用意されています。 権限レベルのアクセス制御を、承認されたユーザーのみに対してビルド プラットフォームまたはサービスに適用することが重要です。 カタログで基本イメージを使用できる場合、ビルド ワークフローでは次の処理が行われます。

  1. 内部カタログからのみ基本イメージをプルします。
  2. 基本イメージを使用する前に確認し、信頼でき、準拠していることを確認します。
  3. ビルド用の基本イメージの上に、信頼ソースからフレームワーク、アプリケーション コード、構成を追加します。
  4. ビルド プロセス中に SBOM を生成します。
  5. ビルド後に生成されたコンテナー イメージで既知の脆弱性とマルウェアをスキャンし、セキュリティ上の欠陥の導入を防ぎます。
  6. 既知の脆弱性とマルウェアに対処するために、結果のコンテナー イメージにパッチを適用する
  7. サプライ チェーンの後続のステージで使用するイメージ構成証明として、脆弱性とマルウェアのレポートを添付します。
  8. サプライ チェーンの後続のステージで使用するイメージ構成証明として SBOM をアタッチします。
  9. 結果の画像を、サプライ チェーンの後続のステージで使用する実績メタデータなどの追加のメタデータで強化します。
  10. 結果のイメージと関連するメタデータにエンタープライズ キーを使用して署名し、整合性を確保し、デプロイ ステージの承認の信頼されたスタンプを提供します

ビルド ステージのセキュリティ目標

信頼できる準拠しているコンテナー イメージを構築するための明確に定義されたワークフローを使用すると、企業はセキュリティを強化し、コンテナーのサプライ チェーンの攻撃対象領域を減らすことができます。 CSSC フレームワークのビルド ステージは、次のセキュリティ目標を満たすことを目的としています。

不適切なアクセス制御により攻撃対象領域を減らす

内部ユーザーは、ビルド インフラストラクチャで予期しない変更や正しくない構成を行う可能性があります。 CSSC フレームワークのビルド ステージでは、既定で最小限の特権アクセス制御を適用することで、このリスクに対処します。これにより、リソース所有者は、適切なユーザーが変更と構成を行う適切なアクセス許可を確実に持ち、攻撃対象領域を減らすことができます。

悪意のある内部ユーザーからの攻撃対象領域を減らす

ID 盗難は、ビルド プラットフォームへのアクセス、バイナリの変更、元の開発者やユーザーに見えない不正な変更の挿入に使用できます。 また、内部ユーザーが脆弱なコードを挿入したり、構成を誤ったりするリスクもあります。 CSSC フレームワークのビルド ステージでは、Azure ロールベースのアクセス制御 (Azure RBAC) を適用し、さまざまなコード所有者からのコード レビューを適用することで、このリスクに対処します。

外部の依存関係により攻撃対象領域を減らす

外部ソースからのベース イメージは悪意のある可能性があります。 外部レジストリが侵害される可能性があります。 CSSC フレームワークのビルド ステージでは、カタログの基本イメージのみを使用し、使用する前に署名、脆弱性とマルウェアのレポート、およびその他の画像メタデータに対して検証することで、このリスクに対処します。

バックドアが非表示の悪意のあるオープン ソース ソフトウェア (OSS) パッケージは、パッケージのバイナリがソース コードと一致しない可能性があります。 依存関係またはオープンソース コンポーネントの有効性が期限切れになる可能性があります。この場合、アップストリームから最新のセキュリティ修正プログラムがブロックされる可能性があります。 CSSC フレームワークのビルド ステージでは、承認されたライブラリを使用し、脆弱性とマルウェアを定期的にスキャンし、ライブラリを最新の状態に保つことで、このリスクに対処します。

ビルドが侵害されたために攻撃対象領域を減らす

脆弱なビルド エージェントは、サイド バイナリや悪意のあるコードを挿入して、SolarWinds 攻撃のような攻撃を引き起こす可能性があります。 CSSC フレームワークのビルド ステージでは、ビルド エージェントに定期的に修正プログラムを適用することで、このリスクに対処します。

最小限の画質を確保する

CSSC フレームワークのビルド ステージでは、企業はビルド後にイメージの脆弱性とマルウェア スキャンに必要な手順を構成し、レポートを生成できます。 また、企業は、SBOM、実績メタデータ、ポリシーを満たすその他の内部メタデータなど、追加のメタデータを使用して、ビルド後にイメージを強化することもできます。 また、整合性を確保し、デプロイ ステージの承認の信頼されたスタンプを提供するために、エンタープライズ キーを使用して成果物に署名することもできます。

Microsoft では、企業がビルド ステージ ワークフローで推奨される手順を実装し、上記のセキュリティ目標に対処するのに役立つ一連のツールとサービスを提供しています。

ビルド後に最新の状態を維持するためのツール

Dependabot は、プル要求を使用して依存関係の更新を自動化するためのツールです。 詳細と次の手順については、このガイドを参照してください。

コパは、Microsoft が支援するオープンソース プロジェクトであり、脆弱性スキャンの結果に基づいて、コンテナー イメージの Linux OS パッケージの脆弱性に対処します。 詳細と次の手順については、このガイドを参照してください。

継続的な脆弱性スキャンと画像の修正プログラムの適用のためのツールとサービス

Microsoft Defender for Cloud は、コンテナー化されたワークロードのセキュリティを向上、監視、およびメインするためのクラウドネイティブ ソリューションです。 Microsoft Defender for Cloud には、Azure Container Registry に格納されているイメージの脆弱性評価と管理ツールが用意されています。

コパは、Microsoft が支援するオープンソース プロジェクトであり、脆弱性スキャンの結果に基づいて、コンテナー イメージの Linux OS パッケージの脆弱性に対処します。 詳細と次の手順については、このガイドを参照してください。

エンタープライズ メタデータを使用して外部イメージを強化するためのツールとサービス

ORAS は、OCI レジストリと対話するためのオープンソース CLI とライブラリを提供する、Microsoft が支援する CNCF プロジェクトです。 ORAS を使用して、注釈を追加し、メタデータをコンテナー イメージにアタッチできます。 ORAS を使用して、SBOM、実績メタデータ、およびその他のメタデータを追加して、サプライ チェーン内の後続のステージのイメージを強化できます。

Microsoft の SBOM ツール は、さまざまな成果物に対して SPDX 2.2 互換の SBOM を作成するための、オープンソースの高度にスケーラブルでエンタープライズ対応のツールです。 SBOM ツールを使用して、コンテナー イメージの詳細な SBOM を生成できます。

公証人プロジェクト は、ソフトウェア成果物の署名と検証のための仕様とツールを開発する、Microsoft が支援する CNCF プロジェクトです。 公証プロジェクトの notation ツールを使用して、コンテナー イメージやその他のクラウドネイティブ成果物にエンタープライズ キーを使用して署名できます。

Azure Key Vault は、暗号化キー、シークレット、証明書を格納および管理するためのセキュリティで保護された一元化された場所を提供するクラウドベースのサービスです。 AKV は、エンタープライズ キーを安全かつ確実に格納および管理するために使用できます。

次のステップ

コンテナー イメージを安全にデプロイするためのデプロイ ステージの概要を参照してください。