適切に定義されたプロセスによって検証され、安全な使用としてマークされている場合にのみ、サプライ チェーンでサードパーティ製のソフトウェア成果物を使用します。 このパターンは、開発プロセスの運用サイドカーです。 このパターンのコンシューマーは、このプロセスを呼び出して、セキュリティの脆弱性を引き起こす可能性のあるソフトウェアの使用を検証し、ブロックします。
コンテキストと問題
クラウド ソリューションは、多くの場合、外部ソースから取得したサード パーティ製ソフトウェアに依存します。 オープン ソース バイナリ、パブリック コンテナー イメージ、ベンダー OS イメージは、これらの種類の成果物の例です。 このような外部成果物はすべて、信頼されていない
一般的なワークフローでは、成果物はソリューションのスコープ外のストアから取得され、デプロイ パイプラインに統合されます。 このアプローチには、いくつかの潜在的な問題があります。 ソースが信頼されていないか、成果物に脆弱性が含まれている可能性があります。また、開発環境に適していない場合もあります。
これらの問題に対処しないと、ソリューションのデータの整合性と機密性の保証が損なわれるか、他のコンポーネントとの互換性がないために不安定になる可能性があります。
これらのセキュリティの問題の一部は、各成果物にチェックを追加することで回避できます。
解決
ワークロードに導入する前に、ソフトウェアのセキュリティを検証するプロセスがあります。 プロセス中に、各アーティファクトは、特定の条件に照らして検証する完全な操作の厳しさを受けます。 アーティファクトがこれらの条件を満たした後にのみ、プロセスはそれを信頼されたとしてマーク
検疫のプロセスはセキュリティ対策であり、成果物を使用する前に使用される一連のチェックポイントで構成されます。 これらのセキュリティ チェックポイントにより、成果物が信頼されていない状態から信頼された状態に遷移することを確認します。
検疫プロセスによってアーティファクトの構成が変更されない点に注意することが重要です。 このプロセスはソフトウェア開発サイクルに依存せず、必要に応じてコンシューマーによって呼び出されます。 成果物のコンシューマーとして、検疫に合格するまで成果物の使用をブロックします。
一般的な検疫ワークフローを次に示します。
コンシューマーは意図を通知し、成果物の入力ソースを指定し、その使用をブロックします。
検疫プロセスは、要求の配信元を検証し、指定されたストアから成果物を取得します。
カスタム検証プロセスは、検疫の一部として実行されます。これには、入力制約の検証と、確立された標準に対する属性、ソース、および型のチェックが含まれます。
これらのセキュリティ チェックの一部は、送信された各成果物の脆弱性スキャン、マルウェア検出などです。
実際のチェックは、成果物の種類によって異なります。 たとえば、OS イメージの評価は、NuGet パッケージの評価とは異なります。
検証プロセスが成功した場合、成果物は明確な注釈を持つ安全なストアに発行されます。 それ以外の場合、コンシューマーは使用できなくなります。
発行プロセスには、検証の証明と各チェックの重要度を示す累積レポートを含めることができます。 レポートに有効期限を含めます。その後、レポートは無効で、成果物は安全でないと見なされます。
このプロセスでは、レポートを伴う状態情報でイベントを通知することで、検疫の終了をマークします。
コンシューマーは、情報に基づいて、信頼された成果物を使用するためのアクションを実行することを選択できます。 これらのアクションは、検疫パターンの範囲外です。
問題と考慮事項
サード パーティの成果物を使用するチームとして、信頼できるソースから取得されていることを確認します。 サード パーティベンダーから調達された成果物の組織が承認した標準に合わせて選択する必要があります。 ベンダーは、ワークロード (および組織) のセキュリティ要件を満たすことができる必要があります。 たとえば、ベンダーの責任ある開示計画が組織のセキュリティ要件を満たしていることを確認します。
信頼された成果物と信頼されていない成果物を格納するリソース間のセグメント化を作成します。 ID とネットワーク制御を使用して、承認されたユーザーへのアクセスを制限します。
検疫プロセスを呼び出すための信頼性の高い方法があります。 信頼済みとしてマークされるまで、アーティファクトが誤って消費されないようにします。 シグナリングは自動化する必要があります。 たとえば、成果物が開発環境に取り込まれたときに担当当事者に通知したり、GitHub リポジトリに変更をコミットしたり、プライベート レジストリにイメージを追加したりすることに関連するタスクなどです。
検疫パターンを実装する代わりに、検疫パターンをアウトソーシングすることもできます。 ビジネス モデルとして公共資産の検証を専門とする検疫実務者がいます。 パターンの実装と責任のアウトソーシングに関する財務コストと運用コストの両方を評価します。 セキュリティ要件をさらに制御する必要がある場合は、独自のプロセスを実装することをお勧めします。
成果物の取り込みプロセスと、成果物を発行するプロセスを自動化します。 検証タスクには時間がかかる場合があるため、自動化プロセスは、すべてのタスクが完了するまで続行できる必要があります。
このパターンは、最初の機会の瞬間的検証として機能します。 検疫を正常に渡しても、成果物が無期限に信頼できる状態が維持されるわけではありません。 成果物は、リリースを昇格する前に、継続的なスキャン、パイプライン検証、およびその他の定期的なセキュリティ チェックを引き続き受ける必要があります。
このパターンは、組織の中央チームまたは個々のワークロード チームによって実装できます。 検疫プロセスのインスタンスまたはバリエーションが多数ある場合は、これらの操作を標準化し、組織で一元化する必要があります。 この場合、ワークロード チームはプロセスを共有し、プロセス管理をオフロードすることでメリットを得ることができます。
このパターンを使用する場合
このパターンは、次の場合に使用します。
ワークロードは、ワークロード チームの範囲外で開発された成果物を統合します。 一般的な例を次に示します。
DockerHub、GitHub Container Registry、Microsoft コンテナー レジストリなどのパブリック レジストリからの Open Container Initiative (OCI) 成果物
NuGet ギャラリー、Python パッケージ インデックス、Apache Maven リポジトリなどのパブリック ソースからのソフトウェア ライブラリまたはパッケージ
Terraform モジュール、Community Chef Cookbooks、Azure Verified Modules などの外部のコードとしてのインフラストラクチャ (IaC) パッケージ
ベンダーが提供する OS イメージまたはソフトウェア インストーラー
ワークロード チームは、成果物を軽減する価値のあるリスクと見なします。 チームは、侵害された成果物を統合した場合の悪影響と、信頼できる環境を保証する検疫の価値を理解します。
チームは、成果物の種類に適用する必要がある検証規則を明確かつ共有しています。 コンセンサスがなければ、パターンは効果的ではない可能性があります。
たとえば、OS イメージが検疫に取り込まれるたびに異なる検証チェックのセットが適用される場合、OS イメージの全体的な検証プロセスに一貫性がなくなります。
このパターンは、次の場合には役に立たない場合があります。
ソフトウェア成果物は、ワークロード チームまたは信頼できるパートナー チームによって作成されます。
アーティファクトを検証しないリスクは、検疫プロセスを構築して維持するコストよりも低コストです。
ワークロードの設計
アーキテクトとワークロード チームは、検疫パターンをワークロードの DevSecOps プラクティスの一部として使用する方法を評価する必要があります。 基になる原則については、Azure Well-Architected Framework の柱で説明されています。
| 柱 | このパターンが柱の目標をサポートする方法 |
|---|---|
| セキュリティ 設計上の決定は、ワークロードのデータとシステムの 機密性、整合性、および 可用性 を確保するのに役立ちます。 | セキュリティ検証の最初の責任は、検疫パターンによって提供されます。 外部成果物の検証は、開発プロセスによって使用される前に、セグメント化された環境で実行されます。 - SE:02 セキュリティで保護された開発ライフサイクル - SE:11 テストと検証の |
| オペレーショナル エクセレンス は、標準化されたプロセス とチームの凝集を通じて、ワークロードの品質 を提供するのに役立ちます。 | 検疫パターンは、侵害された成果物がワークロードによって消費されないようにすることで、安全な展開プラクティス (SDP) をサポートします。これは、プログレッシブ 露出のデプロイ中にセキュリティ侵害につながる可能性があります。 - OE:03 ソフトウェア開発プラクティス - OE:11 テストと検証の |
設計上の決定と同様に、このパターンで導入される可能性のある他の柱の目標に対するトレードオフを検討してください。
例
この例では、ワークロード チームがパブリック レジストリからワークロード チームが所有する Azure Container Registry (ACR) インスタンスに OCI 成果物を統合するシナリオに、ソリューション ワークフロー を適用します。 チームは、そのインスタンスを信頼できる成果物ストアとして扱います。
ワークロード環境では、Kubernetes 用の Azure Policy を使用してガバナンスを適用します。 コンテナーのプルは、信頼されたレジストリ インスタンスからのみ制限されます。 さらに、Azure Monitor アラートは、予期しないソースからそのレジストリへのインポートを検出するように設定されています。
外部イメージの要求は、Azure Web Apps でホストされているカスタム アプリケーションを通じてワークロード チームによって行われます。 アプリケーションは、承認されたユーザーからのみ必要な情報を収集します。
セキュリティ チェックポイント: 要求元の ID、宛先コンテナー レジストリ、および要求されたイメージ ソースが検証されます。
要求は Azure Cosmos DB に格納されます。
セキュリティ チェックポイント: 監査証跡はデータベースに保持され、画像の系列と検証を追跡します。 この証跡は、履歴レポートにも使用されます。
要求は、永続的な Azure 関数であるワークフロー オーケストレーターによって処理されます。 オーケストレーターは、すべての検証を実行するために散布図収集アプローチを使用します。
セキュリティ チェックポイント: オーケストレーターには、検証タスクを実行するのに十分なアクセス権を持つマネージド ID があります。
オーケストレーターは、信頼されていないストアと見なされる検疫 Azure Container Registry (ACR) にイメージをインポートするように要求します。
検疫レジストリのインポート プロセスは、信頼されていない外部リポジトリからイメージを取得します。 インポートが成功した場合、検疫レジストリには検証を実行するためのイメージのローカル コピーがあります。
セキュリティ チェックポイント: 検疫レジストリは、検証プロセス中の改ざんやワークロードの消費から保護します。
オーケストレーターは、イメージのローカル コピーですべての検証タスクを実行します。 タスクには、一般的な脆弱性と露出 (CVE) 検出、ソフトウェア部品表 (SBOM) 評価、マルウェア検出、画像署名などのチェックが含まれます。
オーケストレーターは、チェックの種類、実行順序、実行時間を決定します。 この例では、タスク ランナーとして Azure Container Instance を使用し、結果は Cosmos DB 監査データベースに格納されます。 すべてのタスクにかなりの時間がかかる場合があります。
セキュリティ チェックポイント: この手順は、すべての検証チェックを実行する検疫プロセスの中核です。 チェックの種類は、カスタム、オープンソース、またはベンダーが購入したソリューションです。
オーケストレーターが決定を下します。 イメージがすべての検証に合格した場合、イベントは監査データベースに記録され、イメージは信頼されたレジストリにプッシュされ、ローカル コピーは検疫レジストリから削除されます。 それ以外の場合、イメージは検疫レジストリから削除され、誤って使用されるのを防ぎます。
セキュリティ チェックポイント: オーケストレーターは、信頼されたリソースの場所と信頼されていないリソースの場所のセグメント化を維持します。
手記
オーケストレーターが決定を下す代わりに、ワークロード チームがその責任を負うことができます。 この代替方法では、オーケストレーターは API を介して検証結果を発行し、イメージを一定期間検疫レジストリに保持します。
ワークロード チームは、結果を確認した後に決定を下します。 結果がリスク許容度を満たしている場合は、検疫リポジトリからコンテナー インスタンスにイメージをプルします。 このプル モデルは、このパターンを使用して、セキュリティ リスク許容度が異なる複数のワークロード チームをサポートする場合に、より実用的です。
すべてのコンテナー レジストリは、Microsoft Defender for Containers によってカバーされ、新しく見つかった問題を継続的にスキャンします。 これらの問題は、Microsoft Defender 脆弱性管理に表示されます。
次の手順
このパターンを実装する場合は、次のガイダンスが関連する場合があります。
開発ライフサイクル をセキュリティで保護するための推奨事項では、開発ライフサイクルのすべての段階で信頼できるコードユニットを使用する方法に関するガイダンスが提供されます。
セキュリティで保護されたソフトウェア サプライ チェーンのベスト プラクティス、特にアプリケーションに NuGet 依存関係がある場合に使用します。
Azure Artifacts を使用して 悪意のあるパブリック パッケージから保護します。