取得ステージの概要

  • [アーティクル]

基本イメージまたはユーティリティ イメージとして使用する外部コンテナー イメージの取得は、コンテナーのサプライ チェーンの最初の段階です。 企業には、ソースからすべてのソフトウェアを構築するための専門知識やリソースが不足しており、コンテナー イメージの外部ソースに依存する必要がある場合があります。 このようなイメージの例としては、オペレーティング システムまたはフレームワーク イメージ、NGINX や Envoy などのサービス プロキシ、Fluentd や Kafka などのログとメトリックのイメージなどがあります。 使用する前に特定の品質チェックを確立し、そのようなイメージがエンタープライズ ポリシーに準拠していることを確認することが重要です。

Microsoft の Containers Secure Supply Chain (CSSC) フレームワークは、外部イメージの取得の必要性を特定します。 CSSC フレームワークでは、内部で使用するために外部コンテナー イメージを安全に取得するのに役立つ一連の標準プラクティスとツールが推奨されています。 この記事では、CSSC フレームワークの Acquire ステージで使用できる目的、標準のプラクティス、およびツールについて説明します。

背景

現時点では、企業は外部コンテナー イメージを取得するための確立されたプロセスを持っていません。 アプローチは、企業の規模と専門知識によって大きく異なります。

セキュリティ重視の企業は、Docker Hub などの外部ソースから事前に承認されたイメージを内部 検疫 レジストリに取り込みます。 これらのイメージは、内部使用のためにリリースされる前に脆弱性とマルウェアがないか検査されます。 ただし、このプロセスは統一されていないか、完全に自動化されていません。 また、企業には、サプライ チェーン全体でこれらのイメージの信頼性と整合性を保証する方法がありません。 最後に、サプライ チェーンの後続のステージで追加のメタデータを使用してイメージを強化する一貫した方法はありません。

セキュリティ体験を開始する企業は、ビルド スクリプトとデプロイ スクリプトで外部レジストリのコンテナー イメージを直接使用します。 このアプローチでは、脆弱性、マルウェア、非準拠ソフトウェアが発生し、イメージ ビルドとコンテナー化されたサービスの可用性が損なわれます。

CSSC フレームワークの取得ステージでは、内部で使用する前に外部イメージが検証され、エンタープライズ ポリシーに準拠していることを確認するために実装する必要がある一連の手順とセキュリティ制御が推奨されます。

可能な限り、ソースからソフトウェアをビルドすることをお勧めします。 企業でそれができない場合は、外部コンテナー イメージとクラウド ネイティブ成果物を取得するための次のプラクティスをお勧めします。

  • 外部イメージを企業の管理下にある内部レジストリにインポートして、サード パーティへの依存関係を削除し、可用性への影響を軽減します。 イメージは、信頼できるソースからのみインポートする必要があります。
  • 使用可能な場合は、外部イメージの署名を確認して、インポート プロセス中に発行元の信頼性とイメージの整合性を確認します。
  • 内部使用を許可する前に、コンテナー イメージをスキャンして脆弱性とマルウェアを検出し、セキュリティ上の欠陥が発生するリスクを軽減します。
  • SBOM、実証、ライフサイクルなどの追加のメタデータを使用してコンテナー イメージを強化し、ソフトウェア サプライ チェーンの後続のステージでポリシーを有効にします。
  • コンテナー イメージと関連するメタデータにエンタープライズ キーを使用して署名し、整合性を確保し、内部使用の承認の信頼されたスタンプを提供します。

Microsoft の CSSC フレームワーク ガイダンスは、CNCF ソフトウェア サプライ チェーンのベスト プラクティスのマテリアルをセキュリティで 保護するためのガイダンスにも一致します。

外部画像取得ワークフロー

信頼できる企業はベンダーまたはオープンソース プロジェクトに組み込まれているにもかかわらず、外部ソースから取得したソフトウェアを常に検証する必要があります。 コンテナー イメージとクラウドネイティブ成果物も例外ありません。 CSSC フレームワークでは、外部イメージの取得に次のワークフローが推奨されます。

  1. コンテナー イメージとクラウドネイティブ成果物をエンタープライズ管理下の内部レジストリにインポートします。
  2. 内部レジストリ内のイメージを検疫して、検証されるまで内部で使用されないようにします。
  3. 外部レジストリに署名が存在する場合は、イメージに関連付けられている署名を検証して、イメージの信頼性と整合性を確認します。
  4. 外部レジストリに追加のメタデータが存在する場合は、SBOM や実績など、イメージに関連付けられているその他のメタデータを検証して、非準拠ライセンスなどのエンタープライズ ポリシーの違反を防ぎます。
  5. 既知の脆弱性とマルウェアの画像をスキャンして、セキュリティ上の欠陥の導入を防ぎます。
  6. サプライ チェーンの後続のステージで使用するイメージ構成証明として、脆弱性とマルウェアのレポートを添付します。
  7. 使用できない場合は、イメージの SBOM と実績を生成し、サプライ チェーンの後続のステージで使用するイメージ構成証明として添付します。
  8. サプライ チェーンの後続のステージで使用するライフサイクル メタデータなどの追加のメタデータを使用してイメージを強化します。
  9. 整合性を確保し、内部使用の承認の信頼されたスタンプを提供するために、エンタープライズ キーを使用してイメージと関連するメタデータに署名します。
  10. イメージが内部ポリシーを満たしている場合は、内部使用のためにイメージを ゴールデン レジストリに 発行します。

取得ステージでのセキュリティ目標

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

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

公開レジストリは、オープンな性質と厳格なセキュリティ対策がないため、さまざまな種類の攻撃の影響を受けやすくなります。 企業内のユーザーが外部レジストリからイメージを直接プルできるようにすることで、依存関係の混乱や入力ミスなどの攻撃にさらされます。

CSSC フレームワークの Acquire ステージでは、外部成果物の取得と管理を一元化し、内部ユーザーにすべてのイメージとクラウドネイティブ成果物の単一の信頼できるソースを提供することで、このリスクに対処します。

セキュリティ上の欠陥が発生するリスクを最小限に抑える

パブリック レジストリ内のイメージに対して厳密な検証と承認プロセスが存在しないということは、誰もが厳密な調査を行わずにイメージをプッシュできることを意味します。 これにより、セキュリティの脆弱性がエンタープライズ アプリケーションに発生する可能性がある侵害されたイメージを誤って使用するリスクが高まります。

Acquire ステージでは、内部使用が承認される前に、イメージの脆弱性とマルウェア スキャンに必要な手順を追加することで、このリスクに対処します。 内部レジストリにイメージをインポートするもう 1 つの利点として、これらのイメージを定期的にスキャンして修正プログラムを適用できるようになりました。

コンテナーのビルドとデプロイの可用性を向上させる

グローバル規模でコンテナー イメージを配布する必要があるため、パブリック レジストリは調整の影響を受けやすくなります。 パブリック レジストリは、イメージの配布に影響を与える可能性がある DDoS 攻撃のターゲットでもあります。 最後に、パブリック レジストリは、エンタープライズ管理下にないインフラストラクチャでホストされ、停止の影響を受ける可能性があります。 これらすべてが、エンタープライズ ビルドとデプロイで遅延または失敗を引き起こす可能性があります。

外部レジストリから内部レジストリにイメージをインポートすることで、Acquire ステージでは、外部レジストリへの依存関係を削除し、企業が内部レジストリからイメージをプルする速度を制御できるようにすることで、このリスクに対処します。 プライベート レジストリは、外部攻撃からより適切に保護し、エンタープライズの可用性要件に準拠することもできます。

外部イメージのライフサイクルを制御する

ソフトウェア発行元は、外部レジストリ内のイメージを予告なく更新できます。 これにより、エンタープライズ ビルドとデプロイで予期しない変更が発生する可能性があります。 また、外部レジストリからイメージを予告なしに削除できるため、エンタープライズ ビルドとデプロイが失敗する可能性があります。

外部イメージをホストする中間レジストリを導入することで、Acquire ステージでは、内部使用に必要なイメージのキャッシュ されたバージョンを提供することで、このリスクに対処します。 これにより、企業はイメージのライフサイクルを制御し、エンタープライズ ポリシーに従って削除されるようにすることができます。

最小限の画質を確保する

外部イメージの一部の発行元は、SBOM や実証などの構成証明を含めるだけでなく、コンテナー イメージに署名しますが、パブリック レジストリ内の多くのイメージにはそのような構成証明がありません。 これは、特定のパブリック レジストリがそのような機能をサポートしていないためでもあります。 これにより、企業は、取得したイメージがポリシーに準拠していることを確認することが困難になります。

CSSC フレームワークの取得ステージでは、企業は、SBOM、実績、ライフサイクル、ポリシーを満たすその他の内部メタデータを含む追加のメタデータを使用してイメージを強化できます。 また、整合性を確保し、内部使用の承認の信頼されたスタンプを提供するために、エンタープライズ キーを使用して成果物に署名することもできます。

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

外部イメージをインポートするためのツールとサービス

Azure Container Registry (ACR) は、コンテナー イメージとその他のクラウドネイティブ成果物の配布をサポートする、マネージド OCI 準拠のレジストリです。 ACR は最新の OCI 仕様に準拠しており、サプライ チェーン成果物の格納に使用できます。

ACR インポート 機能を使用して、外部レジストリから ACR にイメージをインポートできます。 インポートでは、イメージ ダイジェストとタグが保持され、Docker Registry V2 API をサポートするパブリック レジストリとプライベート レジストリからイメージをインポートできます。

ORAS は、OCI レジストリと対話するためのオープンソース CLI とライブラリを提供する、Microsoft が支援する CNCF プロジェクトです。 ORAS を使用して、外部レジストリから ACR にイメージやその他の OCI 成果物をコピーすることもできます。

外部イメージを検証するためのツールとサービス

ACR タスク は、Azure Container Registry の一連の機能です。これにより、企業は脆弱性スキャンや SBOM、署名検証などのさまざまなタスクを自動化できます。 ACR タスクは、Azure Container Registry にインポートされた外部イメージを検証するために使用できます。 ACR タスクを使用して、外部レジストリから Azure Container Registry へのイメージのインポートを自動化することもできます。

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

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

OCI レジストリを操作するための汎用ツールとして、 ORAS を使用して注釈を追加し、メタデータをコンテナー イメージにアタッチすることもできます。 ORAS を使用して、SBOM、実証、ライフサイクル、およびその他のメタデータを追加して、サプライ チェーン内の後続のステージのイメージを強化できます。

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

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

次のステップ

内部で使用するためにコンテナー イメージを安全にホストする場合は 、Catalog ステージ の概要を参照してください。