パッケージオリジンコントロールの編集

Amazon では CodeCatalyst、パッケージバージョンを直接公開するか、アップストリームリポジトリからプルダウンするか、ゲートウェイを介して外部パブリックリポジトリから取り込むことで、パッケージバージョンをパッケージリポジトリに追加できます。パッケージのバージョンを直接公開してパブリックリポジトリから取り込むことで、パッケージのバージョンを追加することを許可すると、依存関係置換攻撃に対して脆弱になります。詳細については、「依存関係置換攻撃」を参照してください。依存関係置換攻撃から保護するには、リポジトリ内のパッケージのパッケージオリジンコントロールを設定して、そのパッケージのバージョンをリポジトリに追加する方法を制限します。

異なるパッケージの新しいバージョンを、直接公開などの内部ソースとパブリックリポジトリなどの外部ソースの両方から取得するようにパッケージオリジンコントロールを設定することを検討する必要があります。デフォルトでは、パッケージオリジンコントロールは、パッケージの最初のバージョンがリポジトリに追加された方法に基づいて設定されます。

パッケージオリジンコントロール設定

パッケージオリジンコントロールでは、パッケージバージョンをリポジトリに追加する方法を設定できます。以下のリストには、使用可能なパッケージオリジンコントロールの設定と値が含まれています。

公開

この設定は、パッケージマネージャーや類似のツールを使用してパッケージのバージョンをリポジトリに直接公開できるかどうかを設定します。

• 許可: パッケージバージョンを直接公開できます。

• ブロック: パッケージバージョンは直接公開できません。

アップストリーム

この設定は、パッケージマネージャーからのリクエストに応じて、パッケージバージョンを外部のパブリックリポジトリから取り込むことができるか、アップストリームリポジトリから保持できるかを設定します。

• 許可: 任意のパッケージバージョンは、アップストリーム CodeCatalyst リポジトリとして設定された他のリポジトリから保持することも、外部接続を持つパブリックソースから取り込むこともできます。

• ブロック: パッケージバージョンは、アップストリーム CodeCatalyst リポジトリとして設定された他のリポジトリから保持したり、外部接続を持つパブリックソースから取り込んだりすることはできません。

パッケージオリジンコントロールのデフォルト設定

パッケージのデフォルトのパッケージオリジンコントロールは、そのパッケージの最初のバージョンがパッケージリポジトリに追加された方法に基づきます。

• 最初のパッケージバージョンがパッケージマネージャーによって直接公開された場合、設定は [公開: 許可] と [アップストリーム: ブロック] になります。

• 最初のパッケージバージョンがパブリックソースから取り込まれた場合、設定は [公開: ブロック] と [アップストリーム: 許可] になります。

一般的なパッケージアクセスコントロールシナリオ

このセクションでは、パッケージバージョンが CodeCatalyst パッケージリポジトリに追加されるときの一般的なシナリオについて説明します。パッケージオリジンコントロールの設定は、最初のパッケージバージョンの追加方法に応じて、新しいパッケージに設定されます。

次のシナリオでは、内部パッケージがパッケージマネージャーから、維持するパッケージなどのリポジトリに直接公開されます。外部パッケージは、ゲートウェイリポジトリのアップストリームを介してリポジトリに取り込むことができるパブリックリポジトリに存在するパッケージです。

外部パッケージバージョンが既存の内部パッケージに公開される

このシナリオでは、内部パッケージ「packageA」について考えてみます。チームは packageA の最初のパッケージバージョンを CodeCatalyst パッケージリポジトリに公開します。これはパッケージの最初のパッケージバージョンであるため、パッケージオリジンコントロール設定は自動的に [公開: 許可] および [アップストリーム: ブロック] に設定されます。パッケージがリポジトリで公開されると、同じ名前のパッケージが CodeCatalyst 、パッケージリポジトリに接続されているパブリックリポジトリに公開されます。これは、内部パッケージに対する依存関係置換攻撃の試みであったり、偶然であったりする可能性があります。いずれの場合でも、パッケージオリジンコントロールは、潜在的な攻撃からパッケージバージョンを保護するために、新しい外部バージョンの取り込みをブロックするように設定されています。

次のイメージでは、repoA は、リポジトリへのアップストリーム接続を持つ CodeCatalyst パッケージnpm-public-registry-gatewayリポジトリです。リポジトリには packageA のバージョン 1.1 と 2.1 が含まれていますが、バージョン 3.0 はパブリックリポジトリに公開されています。通常、repoA はパッケージがパッケージマネージャーによってリクエストされた後にバージョン 3.0 を取り込みます。パッケージの取り込みはブロック に設定されているため、バージョン 3.0 は CodeCatalyst パッケージリポジトリに取り込まれず、パッケージリポジトリに接続されているパッケージマネージャーでは使用できません。

内部パッケージバージョンが既存の外部パッケージに公開される

このシナリオでは、パッケージ packageB、リポジトリに接続したパブリックリポジトリに外部で存在します。リポジトリに接続しているパッケージマネージャーが packageB をリクエストすると、パッケージバージョンはパブリックリポジトリからリポジトリに取り込まれます。これは packageB の最初のパッケージバージョンであるため、パッケージオリジンコントロール設定は自動的に [公開: ブロック] および [アップストリーム: 許可] に設定されます。その後、ユーザーは同じパッケージ名のバージョンをリポジトリに公開しようとします。パブリックパッケージを認識しておらず、同じ名前で無関係なパッケージを公開しようとしている場合や、パッチが適用されたバージョンを公開しようとしている場合、または既に外部に存在する正確なパッケージバージョンを直接公開しようとしている場合があります。 は公開しようとしているバージョン CodeCatalyst を拒否しますが、必要に応じて明示的に拒否を上書きしてバージョンを公開できます。

次のイメージでは、repoA は、リポジトリへのアップストリーム接続を持つ CodeCatalyst パッケージnpm-public-registry-gatewayリポジトリです。パッケージリポジトリには、パブリックリポジトリから取り込んだバージョン 3.0 が含まれています。バージョン 1.2 をパッケージリポジトリに公開したい。通常、バージョン 1.2 を repoAに発行することはできますが、発行がブロック に設定されているため、バージョン 1.2 は発行できません。

既存の外部パッケージにパッチを適用したパッケージバージョンを公開する

このシナリオでは、パッケージ packageBは、パッケージリポジトリに接続したパブリックリポジトリに外部で存在します。リポジトリに接続しているパッケージマネージャーが packageB をリクエストすると、パッケージバージョンはパブリックリポジトリからリポジトリに取り込まれます。これは packageB の最初のパッケージバージョンであるため、パッケージオリジンコントロール設定は自動的に [公開: ブロック] および [アップストリーム: 許可] に設定されます。チームは、このパッケージのパッチ適用されたパッケージバージョンをリポジトリに公開することにしました。パッケージバージョンを直接公開するために、チームはパッケージのオリジンコントロール設定を [公開: 許可] および アップストリーム: ブロック] に変更します。これで、このパッケージのバージョンをリポジトリに直接公開し、パブリックリポジトリから取り込むことができます。チームがパッチを適用したパッケージバージョンを公開した後、チームはパッケージオリジンの設定を [公開: ブロック] および [アップストリーム: 許可] に戻します。

パッケージオリジンコントロールの編集

パッケージオリジンコントロールは、パッケージの最初のパッケージバージョンがパッケージリポジトリに追加された方法に基づいて自動的に設定されます。詳細については、「パッケージオリジンコントロールのデフォルト設定」を参照してください。パッケージリポジトリ内のパッケージの CodeCatalyst パッケージオリジンコントロールを追加または編集するには、以下の手順を実行します。

パッケージオリジンコントロールを追加または編集するには

1. ナビゲーションペインで、[Packages (パッケージ)] を選択します。

2. 編集するパッケージを含むパッケージリポジトリを選択します。

3. パッケージ テーブルで、編集するパッケージを検索して選択します。

4. パッケージの概要ページから、オリジンコントロール を選択します。

5. オリジンコントロール で、このパッケージに設定するパッケージオリジンコントロールを選択します。パッケージオリジン制御設定である Publish と Upstream の両方を同時に設定する必要があります。

   • パッケージバージョンを直接公開できるようにするには、[公開] で [許可] を選択します。パッケージバージョンの公開を禁止するには、[ブロック] を選択します。

   • 外部リポジトリからのパッケージの取り込みとアップストリームリポジトリからのパッケージの取得を許可するには、[アップストリームソース] で [許可] を選択します。外部リポジトリおよびアップストリームリポジトリからのパッケージバージョンの取り込みとプルをすべてブロックするには、[ブロック] を選択します。

6. [保存] を選択します。

公開リポジトリとアップストリームリポジトリ

では CodeCatalyst、到達可能なアップストリームリポジトリまたはパブリックリポジトリに存在するパッケージバージョンを公開することはできません。例えば、npm パッケージをリポジトリ lodash@1.0に公開myrepoし、npmjs.com への外部接続を持つアップストリームリポジトリmyrepoがあるとします。次のシナリオを考えてみます。

1. lodash 上のパッケージオリジンコントロール設定は、[公開: 許可] と [アップストリーム: 許可] です。lodash@1.0 がアップストリームリポジトリまたは npmjs.com に存在する場合、 は 409 競合エラーを発行myrepoして、 でそのリポジトリに発行しようとする試み CodeCatalyst を拒否します。lodash@1.1 などの別のバージョンを公開することもできます。

2. lodash 上のパッケージオリジンコントロール設定は、[公開: 許可] と [アップストリーム: ブロック] です。パッケージバージョンにアクセスできないため、まだ存在しない のバージョンをリポジトリlodashに公開できます。

3. lodash 上のパッケージオリジンコントロール設定は、[公開: ブロック] と [アップストリーム: 許可] です。この場合、どのパッケージバージョンもリポジトリに直接公開することはできません。

依存関係置換攻撃

パッケージマネージャーは、再利用可能なコードをパッケージ化して共有するプロセスを簡素化します。これらのパッケージは、ある組織がアプリケーションで使用するために開発したプライベートパッケージの場合もあれば、組織外で開発され、パブリックパッケージリポジトリによって配布されるパブリックパッケージ (通常はオープンソースパッケージ) の場合もあります。パッケージをリクエストする際、開発者はパッケージマネージャーを使用して依存関係の新しいバージョンを取得します。依存関係置換攻撃 (依存関係かく乱攻撃とも呼ばれる) は、通常、パッケージマネージャーでパッケージの正規バージョンと悪意のあるバージョンを区別できない点を悪用するものです。

依存関係置換攻撃は、ソフトウェアサプライチェーン攻撃と呼ばれる攻撃のサブセットに属します。ソフトウェアサプライチェーン攻撃は、ソフトウェアサプライチェーンのあらゆる場所にある脆弱性を利用する攻撃です。

依存関係置換攻撃は、内部で開発されたパッケージとパブリックリポジトリから取得したパッケージの両方を使用するすべてのユーザーを標的にする可能性があります。攻撃者は内部パッケージ名を特定し、同じ名前の悪意のあるコードを公開パッケージリポジトリに戦略的に配置します。通常、悪意のあるコードはバージョン番号の高いパッケージで公開されます。パッケージマネージャーは、悪意のあるパッケージをパッケージの最新バージョンとみなすため、これらの公開フィードから悪意のあるコードを取得します。これにより、目的のパッケージと悪意のあるパッケージの間に「混乱」または「置換」が発生し、コードが侵害されます。

依存関係置換攻撃を防ぐために、Amazon CodeCatalyst はパッケージオリジンコントロールを提供しています。パッケージオリジンコントロールは、パッケージをリポジトリに追加する方法を制御する設定です。コントロールは、新しいパッケージの最初のパッケージバージョンが CodeCatalyst リポジトリに追加されると自動的に設定されます。 コントロールを使用すると、パッケージバージョンをリポジトリに直接公開したり、パブリックソースから取り込んだりできないため、依存関係置換攻撃から保護できます。パッケージオリジンコントロールとその変更方法については、「パッケージオリジンコントロールの編集」を参照してください。