Amazon CodeCatalyst ist nicht mehr offen für neue Kunden. Bestandskunden können den Service weiterhin wie gewohnt nutzen. Weitere Informationen finden Sie unter Wie migriert man von CodeCatalyst.

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Bearbeiten von Paketursprungssteuerungen

In Amazon können Paketversionen zu einem Paket-Repository hinzugefügt werden CodeCatalyst, indem sie direkt veröffentlicht, von einem Upstream-Repository heruntergeladen oder über ein Gateway aus einem externen, öffentlichen Repository aufgenommen werden. Wenn Sie zulassen, dass Versionen eines Pakets sowohl durch direkte Veröffentlichung als auch durch Aufnahme aus öffentlichen Repositorys hinzugefügt werden, sind Sie anfällig für einen Angriff zur Substitution von Abhängigkeiten. Weitere Informationen finden Sie unter Angriffe zur Substitution von Abhängigkeiten. Um sich vor einem Angriff zur Substitution von Abhängigkeiten zu schützen, konfigurieren Sie Paketursprungskontrollen für ein Paket in einem Repository, um einzuschränken, wie Versionen dieses Pakets dem Repository hinzugefügt werden können.

Sie sollten erwägen, die Paketursprungkontrollen so zu konfigurieren, dass neue Versionen verschiedener Pakete sowohl aus internen Quellen wie direkter Veröffentlichung als auch aus externen Quellen wie öffentlichen Repositorys stammen. Standardmäßig werden die Paketursprungskontrollen darauf basierend konfiguriert, wie die erste Version eines Pakets zum Repository hinzugefügt wird.

Einstellungen zur Kontrolle des Paketursprungs

Mit den Paketursprungskontrollen können Sie konfigurieren, wie Paketversionen zu einem Repository hinzugefügt werden können. Die folgenden Listen enthalten die verfügbaren Einstellungen und Werte für die Paketursprungskontrolle.

Veröffentlichen

Diese Einstellung konfiguriert, ob Paketversionen mithilfe von Paketmanagern oder ähnlichen Tools direkt im Repository veröffentlicht werden können.

Upstream

Diese Einstellung konfiguriert, ob Paketversionen aus externen, öffentlichen Repositorys aufgenommen oder aus Upstream-Repositorys aufbewahrt werden können, wenn dies von einem Paketmanager angefordert wird.

Standardeinstellungen für die Kontrolle des Paketursprungs

Die standardmäßigen Paketursprungskontrollen für ein Paket basieren darauf, wie die erste Version dieses Pakets zum Paket-Repository hinzugefügt wird.

Gängige Szenarien zur Paketzugriffskontrolle

In diesem Abschnitt werden einige gängige Szenarien beschrieben, in denen eine Paketversion zu einem CodeCatalyst Paket-Repository hinzugefügt wird. Die Einstellungen zur Paketherkunftskontrolle werden für neue Pakete festgelegt, je nachdem, wie die erste Paketversion hinzugefügt wird.

In den folgenden Szenarien wird ein internes Paket direkt von einem Paketmanager in Ihrem Repository veröffentlicht, beispielsweise ein Paket, das Sie verwalten. Ein externes Paket ist ein Paket, das in einem öffentlichen Repository existiert und über ein Upstream-Gateway-Repository in Ihr Repository aufgenommen werden kann.

Eine externe Paketversion wird für ein vorhandenes internes Paket veröffentlicht

Ziehen Sie in diesem Szenario ein internes Paket, PackageA, in Betracht. Ihr Team veröffentlicht die erste Paketversion für PackageA in einem Paket-Repository. CodeCatalyst Da dies die erste Paketversion für dieses Paket ist, werden die Einstellungen für die Paketursprungskontrolle automatisch auf Veröffentlichen: Zulassen und Upstream: Blockieren gesetzt. Nachdem das Paket in Ihrem Repository veröffentlicht wurde, wird ein Paket mit demselben Namen in einem öffentlichen Repository veröffentlicht, das mit Ihrem CodeCatalyst Paket-Repository verbunden ist. Dies könnte ein versuchter Angriff zur Substitution von Abhängigkeiten gegen das interne Paket sein, oder es könnte ein Zufall sein. Unabhängig davon sind die Paketursprungkontrollen so konfiguriert, dass sie die Aufnahme der neuen externen Version blockieren, um sich selbst vor einem möglichen Angriff zu schützen.

In der folgenden Abbildung ist RepoA Ihr CodeCatalyst Paket-Repository mit einer Upstream-Verbindung zum Repository. npm-public-registry-gateway Ihr Repository enthält die Versionen 1.1 und 2.1 von PackageA, aber Version 3.0 ist im öffentlichen Repository veröffentlicht. Normalerweise würde RepoA Version 3.0 aufnehmen, nachdem das Paket von einem Paketmanager angefordert wurde. Da die Paketaufnahme auf Block gesetzt ist, wird Version 3.0 nicht in Ihr CodeCatalyst Paket-Repository aufgenommen und steht den damit verbundenen Paketmanagern nicht zur Verfügung.

Eine interne Paketversion wird für ein vorhandenes externes Paket veröffentlicht

In diesem Szenario existiert ein Paket, PackageB, extern in einem öffentlichen Repository, das Sie mit Ihrem Repository verbunden haben. Wenn ein mit Ihrem Projektarchiv verbundener Paketmanager PaketB anfordert, wird die Paketversion aus dem öffentlichen Projektarchiv in Ihr Projektarchiv aufgenommen. Da dies die erste Paketversion von PackageB ist, die zu deinem Repository hinzugefügt wurde, sind die Paketursprungseinstellungen auf Publish: BLOCK und Upstream: ALLOW konfiguriert. Später versuchst du, eine Version mit demselben Paketnamen im Repository zu veröffentlichen. Möglicherweise sind Sie sich des öffentlichen Pakets nicht bewusst und versuchen, ein anderes Paket mit demselben Namen zu veröffentlichen, oder Sie versuchen möglicherweise, eine gepatchte Version zu veröffentlichen, oder Sie versuchen möglicherweise, direkt die genaue Paketversion zu veröffentlichen, die bereits extern existiert. CodeCatalyst lehnt die Version ab, die Sie zu veröffentlichen versuchen, aber Sie können die Ablehnung explizit außer Kraft setzen und die Version veröffentlichen, falls erforderlich.

In der folgenden Abbildung ist RepoA Ihr CodeCatalyst Paket-Repository mit einer Upstream-Verbindung zum Repository. npm-public-registry-gateway Ihr Paket-Repository enthält Version 3.0, die es aus dem öffentlichen Repository aufgenommen hat. Sie möchten Version 1.2 in Ihrem Paket-Repository veröffentlichen. Normalerweise könnten Sie Version 1.2 in RepoA veröffentlichen, aber da die Veröffentlichung auf Blockieren gesetzt ist, kann Version 1.2 nicht veröffentlicht werden.

Veröffentlichung einer gepatchten Paketversion eines vorhandenen externen Pakets

In diesem Szenario existiert ein Paket, PackageB, extern in einem öffentlichen Repository, das Sie mit Ihrem Paket-Repository verbunden haben. Wenn ein mit Ihrem Projektarchiv verbundener Paketmanager PaketB anfordert, wird die Paketversion aus dem öffentlichen Projektarchiv in Ihr Projektarchiv aufgenommen. Da dies die erste Paketversion von PackageB ist, die zu deinem Repository hinzugefügt wurde, sind die Paketursprungseinstellungen auf Publish: BLOCK und Upstream: ALLOW konfiguriert. Ihr Team entscheidet, gepatchte Paketversionen dieses Pakets im Repository zu veröffentlichen. Um Paketversionen direkt veröffentlichen zu können, ändert Ihr Team die Einstellungen zur Paketherkunftskontrolle auf Publish: ALLOW und Upstream: BLOCK. Versionen dieses Pakets können jetzt direkt in Ihrem Repository veröffentlicht und aus öffentlichen Repositorys aufgenommen werden. Nachdem Ihr Team die gepatchten Paketversionen veröffentlicht hat, setzt Ihr Team die Paketursprungseinstellungen auf Publish: BLOCK und Upstream: ALLOW zurück.

Bearbeitung der Steuerelemente für den Paket-Ursprung

Die Paketursprungskontrollen werden automatisch konfiguriert, je nachdem, wie die erste Paketversion eines Pakets zum Paket-Repository hinzugefügt wird. Weitere Informationen finden Sie unter Standardeinstellungen für die Kontrolle des Paketursprungs. Gehen Sie wie folgt vor, um Paketursprungskontrollen für ein CodeCatalyst Paket in einem Paket-Repository hinzuzufügen oder zu bearbeiten.

Repositorys für Veröffentlichungen und Upstream-Re

In können Sie keine Paketversionen veröffentlichen CodeCatalyst, die in erreichbaren Upstream-Repositorys oder öffentlichen Repositorys vorhanden sind. Angenommen, Sie möchten ein NPM-Paket in einem Repository veröffentlichen und myrepo haben ein Upstream-Repository mit einer externen Verbindung lodash@1.0 zu npmjs.com. myrepo Betrachten Sie die folgenden Szenarien.

Angriffe zur Substitution von Abhängigkeiten

Paketmanager vereinfachen das Verpacken und Teilen von wiederverwendbarem Code. Bei diesen Paketen kann es sich um private Pakete handeln, die von einer Organisation zur Verwendung in ihren Anwendungen entwickelt wurden, oder es kann sich um öffentliche Pakete handeln, in der Regel Open-Source-Pakete, die außerhalb einer Organisation entwickelt und von öffentlichen Paket-Repositorys verteilt werden. Bei der Anforderung von Paketen verlassen sich Entwickler darauf, dass ihr Paketmanager neue Versionen ihrer Abhängigkeiten abruft. Angriffe zur Substitution von Abhängigkeiten, auch bekannt als Angriffe zur Verwechslung von Abhängigkeiten, nutzen die Tatsache aus, dass ein Paketmanager in der Regel keine Möglichkeit hat, legitime Versionen eines Pakets von bösartigen Versionen zu unterscheiden.

Angriffe zur Substitution von Abhängigkeiten gehören zu einer Untergruppe von Angriffen, die als Software-Supply-Chain-Angriffe bekannt sind. Ein Angriff auf die Softwarelieferkette ist ein Angriff, der Sicherheitslücken überall in der Software-Lieferkette ausnutzt.

Ein Angriff zur Substitution von Abhängigkeiten kann jeden ins Visier nehmen, der sowohl intern entwickelte Pakete als auch Pakete verwendet, die aus öffentlichen Repositorys abgerufen wurden. Die Angreifer identifizieren interne Paketnamen und platzieren dann strategisch schädlichen Code mit demselben Namen in öffentlichen Paket-Repositorys. In der Regel wird der bösartige Code in einem Paket mit einer hohen Versionsnummer veröffentlicht. Paketmanager rufen den Schadcode aus diesen öffentlichen Feeds ab, weil sie glauben, dass es sich bei den schädlichen Paketen um die neuesten Versionen des Pakets handelt. Dies führt zu einer „Verwechslung“ oder einer „Substitution“ zwischen dem gewünschten Paket und dem schädlichen Paket, was dazu führt, dass der Code kompromittiert wird.

Um Angriffe zur Substitution von Abhängigkeiten zu verhindern, CodeCatalyst bietet Amazon Kontrollen zur Herkunft von Paketen an. Bei den Kontrollen zur Paketherkunft handelt es sich um Einstellungen, die steuern, wie Pakete zu Ihren Repositorys hinzugefügt werden können. Die Steuerelemente werden automatisch konfiguriert, wenn die erste Paketversion eines neuen Pakets zu einem CodeCatalyst Repository hinzugefügt wird. Sie können sicherstellen, dass Paketversionen nicht sowohl direkt in Ihrem Repository veröffentlicht als auch aus öffentlichen Quellen aufgenommen werden können, was Sie vor Angriffen zur Substitution von Abhängigkeiten schützt. Weitere Informationen zu den Steuerelementen für die Paketherkunft und wie Sie sie ändern können, finden Sie unter. Bearbeiten von Paketursprungssteuerungen