第三者のソフトウェアアーティファクトは、明確に定義されたプロセスによって検証および安全な使用としてマークされている場合にのみ、サプライチェーン内で消費します。 このパターンは、開発プロセスにおける運用上のサイドカーです。 このパターンの消費者は、このプロセスを呼び出して、潜在的にセキュリティ上の脆弱性をもたらす可能性があるソフトウェアの使用を確認し、ブロックします。
コンテキストと問題
クラウドソリューションは、多くの場合、外部ソースから入手した第三者のソフトウェアに依存します。 オープンソースバイナリ、パブリックコンテナイメージ、ベンダのOSイメージは、このような種類のアーティファクトの例です。 このような外部アーティファクトはすべて信頼できないものとして扱われる必要があります。
一般的なワークフローでは、アーティファクトは、ソリューションの範囲外のストアから取得した後、配布パイプラインに統合されます。 このアプローチにはいくつかの潜在的な問題があります。 ソースが信頼されていないか、アーティファクトに脆弱性が含まれているか、開発者環境に他の方法で適していないことがあります。
これらの問題が解決されない場合、ソリューションのデータ整合性と機密性が損なわれたり、他のコンポーネントとの互換性がないために不安定な状態になることがあります。
これらのセキュリティ問題の一部は、各アーティファクトにチェックを追加することで回避できます。
解決策
ワークロードに導入する前に、ソフトウェアのセキュリティを検証するプロセスが必要です。 この過程で、各アーティファクトは特定の条件に照らして検証される徹底した操作厳格さを受けます。 アーティファクトがこれらの条件を満たしている場合にのみ、プロセスはアーティファクトを信頼できるものとしてマークします。
検疫プロセスは、アーティファクトが消費される前に使用される一連のチェックポイントで構成されたセキュリティ対策です。 これらのセキュリティチェックポイントは、アーティファクトが信頼できない状態から信頼できる状態に移行することを確認します。
検疫プロセスは、アーティファクトの構成を変更しないことに注意する必要があります。 このプロセスはソフトウェア開発サイクルとは無関係であり、必要に応じて消費者によって呼び出されます。 アーティファクトの消費者として、アーティファクトが検疫を通過するまで使用をブロックします。
次に、典型的な検疫ワークフローを示します。
消費者は、意図を信号で伝え、アーティファクトの入力ソースを指定し、その使用をブロックします。
検疫プロセスは、要求の発信元を検証し、指定されたストアからアーティファクトを取得します。
カスタム検証プロセスは検疫の一部として実行されます。これには、入力制約を検証し、アトリビュート、ソース、およびタイプを確立された標準に基づいてチェックすることが含まれます。
これらのセキュリティチェックには、送信された各アーティファクトに対する脆弱性スキャン、マルウェア検出などがあります。
実際のチェックは、アーティファクトのタイプによって異なります。 たとえば、OSイメージの評価はNuGetパッケージの評価とは異なります。
検証プロセスが成功すると、アーティファクトは明確な注釈を持つ安全なストアに公開されます。 それ以外の場合は、消費者は利用できません。
公開プロセスには、検証の証拠と各チェックの重要性を示す累積レポートが含まれます。 レポートの有効期限をレポートに含めると、レポートは無効であり、アーティファクトは安全でないと見なされます。
このプロセスは、レポートを伴う状態情報でイベントをシグナリングすることによって、検疫の終了をマークします。
この情報に基づいて、消費者は信頼できるアーティファクトを使用するためのアクションを選択することができます。 これらのアクションは検疫パターンの範囲外です。
問題と注意事項
第三者のアーティファクトを消費するチームとして、それが信頼できるソースから取得されていることを確認します。 選択は、第三者ベンダから調達したアーティファクトに関する組織が承認した標準に準拠している必要があります。 ベンダは、ワークロード（および組織）のセキュリティ要件を満たす必要があります。 たとえば、ベンダの責任ある開示計画が組織のセキュリティ要件を満たしていることを確認します。
信頼できるアーティファクトと信頼できないアーティファクトを保存するリソース間のセグメンテーションを作成します。 IDおよびネットワーク制御を使用して、許可されたユーザーへのアクセスを制限します。
検疫プロセスを呼び出す信頼性の高い方法があります。 アーティファクトが信頼できると表示されるまで、誤って使用されないようにしてください。 シグナリングは自動化される必要があります。 たとえば、アーティファクトが開発者環境に取り込まれたときの関係者への通知、GitHubリポジトリへの変更のコミット、プライベートレジストリへのイメージの追加などに関連するタスクです。
検疫パターンを導入する代替案は、アウトソーシングすることです。 公共資産の検証をビジネスモデルとして専門的に行う防疫実務者がいます。 パターンの実装に伴う財務コストと運用コストの両方を評価し、責任をアウトソーシングします。 セキュリティ要件をさらに管理する必要がある場合は、独自のプロセスを実装することをお勧めします。
アーティファクトの収集プロセスとアーティファクトを公開するプロセスを自動化します。 検証タスクには時間がかかることがあるため、自動化プロセスはすべてのタスクが完了するまで継続できる必要があります。
このパターンは、最初の機会の瞬間的な検証として機能します。 検疫を正常に通過しても、アーティファクトが無期限に信頼性を維持することはできません。 アーティファクトは、リリースを促進する前に、継続的なスキャン、パイプライン検証、および最後の機会検証として機能するその他の定期的なセキュリティチェックを継続して行う必要があります。
このパターンは、組織の中央チームまたは個々のワークロードチームによって実装できます。 検疫プロセスのインスタンスまたはバリエーションが多い場合は、これらの操作を組織によって標準化および集中化する必要があります。 この場合、ワークロードチームはプロセスを共有し、オフロードプロセス管理のメリットを享受します。
このパターンを使用する状況
このパターンは次の状況で使用します。
ワークロードは、ワークロードチームの範囲外で開発されたアーティファクトを統合します。 たとえば、次のような場合です。
DockerHub、GitHub Containerレジストリ、Microsoftコンテナレジストリなどのパブリックレジストリからのオープンコンテナイニシアチブ（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 テストおよび検証 |
設計決定と同様に、このパターンで導入される可能性のある他の柱の目標とのトレードオフを考慮してください。
例
この例では、ワークロードチームがパブリックレジストリのOCIアーティファクトをワークロードチームが所有するAzure Container Registry（ACR）インスタンスに統合するシナリオにソリューションワークフローを適用します。 チームは、そのインスタンスを信頼できるアーティファクトストアとして扱います。
ワークロード環境では、KubernetesのAzure Policyを使用してガバナンスを実施します。 コンテナのプルは、信頼できるレジストリインスタンスからのみ制限されます。 さらに、Azure Monitorアラートは、予期しないソースからのそのレジストリへのインポートを検出するように設定されます。
外部イメージの要求は、Azure Web Appsでホストされるカスタムアプリケーションを介してワークロード チームによって行われます。 アプリケーションは、許可されたユーザーからだけ必要な情報を収集します。
セキュリティチェックポイント：要求元のID、宛先コンテナレジストリ、および要求されたイメージ ソースが確認されます。
リクエストはAzure Cosmos DBに保存されます。
セキュリティチェックポイント：監査証跡はデータベースに保持され、イメージの系統と検証を追跡します。 この証跡は、履歴レポートにも使用されます。
リクエストは、耐久性のあるAzure Functionであるワークフローオーケストレーターによって処理されます。 オーケストレータは、すべての検証を実行するために散乱収集アプローチを使用します。
セキュリティチェックポイント：オーケストレータは、検証タスクを実行するのに十分なアクセス権限を持つ管理されたIDを持っています。
オーケストレータは、信頼できないストアと見なされる検疫 Azure Container Registry（ACR）にイメージをインポートするよう要求します。
検疫レジストリのインポートプロセスは、信頼できない外部リポジトリからイメージを取得します。 インポートが成功した場合、検疫レジストリには検証を実行するイメージのローカル コピーがあります。
セキュリティチェックポイント：検疫レジストリは、検証プロセス中に改ざんやワークロードの消費を防止します。
オーケストレータは、イメージのローカルコピーですべての検証タスクを実行します。 タスクには、共通脆弱性・暴露（CVE）検出、ソフトウェア部品表（SBOM）評価、マルウェア検出、画像署名などのチェックが含まれます。
オーケストレータは、チェックのタイプ、実行順序、および実行時間を決定します。 この例では、タスクランナとしてAzure Container Instanceを使用し、結果はCosmos DB監査データベースにあります。 すべての作業にはかなりの時間がかかります。
セキュリティチェックポイント：この手順は、すべての検証チェックを実行する検疫プロセスのコアです。 チェックのタイプは、カスタム、オープンソース、またはベンダ購入ソリューションのいずれかです。
監督は決断を下します。 イメージがすべての検証に合格すると、イベントは監査データベースに記録され、イメージは信頼できるレジストリにプッシュされ、ローカルコピーは検疫レジストリから削除されます。 それ以外の場合は、イメージが誤って使用されないように、検疫レジストリから削除されます。
セキュリティチェックポイント：オーケストレータは、信頼できるリソースロケーションと信頼できないリソースロケーション間のセグメンテーションを維持します。
Note
オーケストレータが決定する代わりに、ワークロードチームがその責任を負うことができます。 この代わりに、オーケストレータはAPIを介して検証結果を公開し、イメージを一定期間隔離レジストリに保持します。
ワークロードチームは、結果を確認してから決定します。 結果がリスク許容値を満たす場合、検疫リポジトリからコンテナインスタンスにイメージをプルします。 このプルモデルは、このパターンを使用して異なるセキュリティリスク許容範囲を持つ複数のワークロード チームをサポートする場合により実用的です。
すべてのコンテナレジストリはMicrosoft Defender for Containersによってカバーされ、新たに見つかった問題を継続的にスキャンします。 これらの問題は、Microsoft Defenderの脆弱性管理に示されています。
次のステップ
このパターンを実装する場合は、次のガイダンスが関連している可能性があります。
開発ライフサイクルのセキュリティ保護に関する推奨事項は、開発ライフサイクルのすべての段階で信頼できるコード単位を使用するためのガイダンスを提供します。
Azure Artifactsドキュメントは、Azure Artifactsを使用したソフトウェアパッケージの管理に関連する情報のライブラリです。