Steuerelemente für den Paketursprung bearbeiten

In Amazon können Paketversionen zu einem Paket-Repository hinzugefügt werden CodeCatalyst, indem sie direkt veröffentlicht, aus 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 Angriffe, die Abhängigkeiten ersetzen. Weitere Informationen finden Sie unter Angriffe durch Substitution von Abhängigkeiten. Um sich vor einem Angriff durch die Substitution von Abhängigkeiten zu schützen, konfigurieren Sie die Kontrolle über den Paketursprung für ein Paket in einem Repository, um einzuschränken, wie Versionen dieses Pakets dem Repository hinzugefügt werden können.

Sie sollten in Erwägung ziehen, die Kontrolle über die Herkunft von Paketen so zu konfigurieren, dass neue Versionen verschiedener Pakete sowohl aus internen Quellen wie Direktveröffentlichungen als auch aus externen Quellen wie öffentlichen Repositorien stammen. Standardmäßig werden die Kontrollen für den Paketursprung darauf konfiguriert, wie die erste Version eines Pakets zum Repository hinzugefügt wird.

Einstellungen für die Kontrolle des Paketursprungs

Mit den Steuerelementen für den Paketursprung 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 Steuerung des Paketursprungs.

Veröffentlichen

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

• ZULASSEN: Paketversionen können direkt veröffentlicht werden.

• BLOCK: Paketversionen können nicht direkt veröffentlicht werden.

Upstream

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

• ALLOW: Jede Paketversion kann aus anderen CodeCatalyst Repositorys beibehalten werden, die als Upstream-Repositorys konfiguriert sind, oder aus einer öffentlichen Quelle mit einer externen Verbindung aufgenommen werden.

• BLOCKIEREN: Paketversionen können nicht aus anderen CodeCatalyst Repositorys aufbewahrt werden, die als Upstream-Repositorys konfiguriert sind, oder von einer öffentlichen Quelle mit einer externen Verbindung aufgenommen werden.

Standardeinstellungen für die Kontrolle des Paketursprungs

Die Standardkontrollen für den Paketursprung für ein Paket basieren darauf, wie die erste Version dieses Pakets dem Paket-Repository hinzugefügt wird.

• Wenn die erste Paketversion direkt von einem Paketmanager veröffentlicht wird, lauten die Einstellungen Publish: ALLOW und Upstream: BLOCK.

• Wenn die erste Paketversion aus einer öffentlichen Quelle aufgenommen wurde, lauten die Einstellungen Publish: BLOCK und Upstream: ALLOW.

Allgemeine 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 Kontrolle des Paketursprungs werden für neue Pakete festgelegt, je nachdem, wie die erste Paketversion hinzugefügt wurde.

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

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

Stellen Sie sich in diesem Szenario ein internes Paket, PackageA, vor. 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 Kontrolle des Paketursprungs 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 auf das interne Paket sein, oder es könnte ein Zufall sein. Unabhängig davon sind die Kontrollen zur Paketherkunft so konfiguriert, dass sie die Aufnahme der neuen externen Version blockieren, um sich 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 Blockieren 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 Repository verbundener Paketmanager PackageB anfordert, wird die Paketversion aus dem öffentlichen Repository in Ihr Repository aufgenommen. Da dies die erste Paketversion von PackageB ist, die zu Ihrem Repository hinzugefügt wurde, sind die Einstellungen für den Paketursprung auf Publish: BLOCK und Upstream: ALLOW konfiguriert. Später versuchen Sie, eine Version mit demselben Paketnamen im Repository zu veröffentlichen. Möglicherweise kennen Sie das öffentliche Paket nicht und versuchen, ein nicht verwandtes Paket mit demselben Namen zu veröffentlichen, oder Sie versuchen möglicherweise, eine gepatchte Version zu veröffentlichen, oder Sie versuchen möglicherweise, genau die Paketversion, die bereits extern existiert, direkt zu veröffentlichen. 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 bei Bedarf veröffentlichen.

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 eingestellt ist, kann Version 1.2 nicht veröffentlicht werden.

Veröffentlichen 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 Repository verbundener Paketmanager PackageB anfordert, wird die Paketversion aus dem öffentlichen Repository in Ihr Repository aufgenommen. Da dies die erste Paketversion von PackageB ist, die zu Ihrem Repository hinzugefügt wurde, sind die Einstellungen für den Paketursprung auf Publish: BLOCK und Upstream: ALLOW konfiguriert. Ihr Team beschließt, gepatchte Paketversionen dieses Pakets im Repository zu veröffentlichen. Um Paketversionen direkt veröffentlichen zu können, ändert Ihr Team die Einstellungen zur Kontrolle des Paketursprungs in 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 Einstellungen für den Paketursprung auf Publish: BLOCK und Upstream: ALLOW zurück.

Die Einstellungen für den Paketursprung werden bearbeitet

Die Kontrollen zur Paketherkunft 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 Steuerungen für den Paketursprung für ein CodeCatalyst Paket in einem Paket-Repository hinzuzufügen oder zu bearbeiten.

Um Steuerelemente für den Paketursprung hinzuzufügen oder zu bearbeiten

1. Wählen Sie im Navigationsbereich Packages (Pakete) aus.

2. Wählen Sie das Paket-Repository aus, das das Paket enthält, das Sie bearbeiten möchten.

3. Suchen Sie in der Tabelle Pakete nach dem Paket, das Sie bearbeiten möchten, und wählen Sie es aus.

4. Wähle auf der Seite mit der Paketübersicht Origin Controls aus.

5. Wähle unter Origin Controls die Kontrollen für den Paketursprung aus, die du für dieses Paket einrichten möchtest. Beide Einstellungen zur Kontrolle des Paketursprungs, Publish und Upstream, müssen gleichzeitig festgelegt werden.

   • Um das direkte Veröffentlichen von Paketversionen zuzulassen, wählen Sie unter Veröffentlichen die Option Zulassen aus. Um die Veröffentlichung von Paketversionen zu blockieren, wählen Sie Blockieren aus.

   • Um die Aufnahme von Paketen aus externen Repositorys und das Abrufen von Paketen aus Upstream-Repositorys zuzulassen, wählen Sie unter Upstream-Quellen die Option Zulassen aus. Um die gesamte Aufnahme und das Abrufen von Paketversionen aus externen und Upstream-Repositorys zu blockieren, wählen Sie Blockieren.

6. Wählen Sie Speichern.

Veröffentlichung und Upstream-Repositorys

In können Sie keine Paketversionen veröffentlichen CodeCatalyst, die in erreichbaren Upstream-Repositorys oder öffentlichen Repositorys vorhanden sind. Nehmen wir zum Beispiel an, 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 Stellen Sie sich die folgenden Szenarien vor.

1. Die Einstellungen für die Kontrolle des Paketursprungs lodash lauten Publish: ALLOW und Upstream: ALLOW. Wenn im Upstream-Repository oder auf npmjs.com vorhanden lodash@1.0 ist, CodeCatalyst lehnt es jeden Versuch ab, in diesem Verzeichnis zu veröffentlichen, myrepo indem es einen 409-Konfliktfehler ausgibt. Sie könnten immer noch eine andere Version veröffentlichen, z. B. lodash@1.1

2. Die Einstellungen für die Kontrolle des Paketursprungs lodash lauten Publish: ALLOW und Upstream: BLOCK. Sie können jede Version von lodash in Ihrem Repository veröffentlichen, die noch nicht existiert, da Paketversionen nicht erreichbar sind.

3. Die Einstellungen zur Kontrolle des Paketursprungs lodash lauten Publish: BLOCK und Upstream: ALLOW. Sie können keine Paketversionen direkt in Ihrem Repository veröffentlichen.

Angriffe durch 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 über öffentliche Paket-Repositorys verteilt werden. Bei der Anforderung von Paketen verlassen sich Entwickler auf ihren Paketmanager, um neue Versionen ihrer Abhängigkeiten abzurufen. Angriffe zur Substitution von Abhängigkeiten, auch bekannt als Dependency Confusion Attacks, nutzen die Tatsache aus, dass ein Paketmanager normalerweise 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 bezeichnet werden. Ein Angriff auf die Software-Lieferkette ist ein Angriff, bei dem Sicherheitslücken überall in der Software-Lieferkette ausgenutzt werden.

Ein Angriff zur Substitution von Abhängigkeiten kann sich gegen jeden richten, der sowohl intern entwickelte Pakete als auch Pakete verwendet, die aus öffentlichen Repositorien abgerufen wurden. Die Angreifer identifizieren interne Paketnamen und platzieren dann strategisch bösartigen 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 bösartigen Code aus diesen öffentlichen Feeds ab, weil sie glauben, dass es sich bei den bösartigen Paketen um die neuesten Versionen des Pakets handelt. Dies führt zu einer „Verwechselung“ oder einer „Ersetzung“ zwischen dem gewünschten Paket und dem bösartigen Paket, was dazu führt, dass der Code kompromittiert wird.

Um Angriffe durch die Substitution von Abhängigkeiten zu verhindern, CodeCatalyst bietet Amazon Kontrollen zur Herkunft von Paketen. Kontrollen zur Paketherkunft sind 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, wodurch Sie vor Angriffen durch die Substitution von Abhängigkeiten geschützt sind. Weitere Informationen zu den Kontrollen zur Paketherkunft und zu deren Änderung finden Sie unter. Steuerelemente für den Paketursprung bearbeiten