Freigeben über

Schutz vor böswilligen öffentlichen Paketen

  • Artikel

Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2019

Mit Azure Artifacts-Upstreamquellen profitieren Entwickler von der Verwendung eines einheitlichen Feeds, um Pakete sowohl aus Artifact-Feeds als auch aus beliebten öffentlichen Registries wie NuGet.org oder npmjs.com zu veröffentlichen und zu nutzen.

Externe Quellversionen zulassen

Mit diesem Feature können Entwickler steuern, ob sie Paketversionen aus öffentlichen Registrierungen wie NuGet.org oder npmjs.com nutzen möchten.

Sobald der Umschalter Externe Versionen zulassen für ein bestimmtes Paket aktiviert ist, stehen Versionen aus der öffentlichen Registrierung zum Download zur Verfügung. Diese Option ist standardmäßig deaktiviert und bietet eine zusätzliche Sicherheitsebene, indem sie verhindert, dass potenziell bösartige Pakete aus öffentlichen Registern entdeckt werden. Sie müssen Feed-Besitzer sein, um die Funktion Extern bezogene Versionen zulassen zu aktivieren.

Hinweis

Das Ändern dieser Einstellung wirkt sich nicht auf paketversionen aus, die bereits im Feed gespeichert wurden. Diese Versionen bleiben unabhängig von dieser Einstellung zugänglich.

Zutreffende Szenarios

Im folgenden Abschnitt werden allgemeine Szenarien beschrieben, in denen externe Versionen (Pakete aus öffentlichen Registrierungen) entweder blockiert oder daran gehindert werden, im Feed gespeichert zu werden. Im Rest dieses Artikels beziehen wir uns auf Pakete aus öffentlichen Registrierungen als öffentliche Pakete und Pakete in einem Azure Artifacts-Feed als private Pakete.

Szenario 1: Öffentliche Versionen werden blockiert

Private Paketversion, die öffentlich gemacht wurde

In diesem Szenario verfügt ein Team über ein privates Paket, das öffentlich gemacht wurde. Die Einstellung für externe Versionen in diesem Fall bewirkt, dass der Feed den Verbrauch neuer Versionen mit diesem Paketnamen aus einer öffentlichen Quelle blockiert.

Abbildung einer internen Paketversion, die öffentlich gemacht wurde.

Sowohl private als auch öffentliche Pakete haben

Wenn ein Team eine Kombination aus privaten und öffentlichen Paketen verwendet, verhindert in diesem Szenario die Blockierung externer Pakete, dass neue Paketversionen aus der öffentlichen Registrierung bezogen werden können.

Abbildung der verfügbaren privaten und öffentlichen Pakete.

Szenario 2: Öffentliche Versionen werden nicht blockiert

Alle Pakete sind privat*

Wenn alle vorhandenen Pakete privat sind und das Team keine öffentlichen Pakete verwenden möchte, hat die Einstellung für externe Versionen keine Auswirkungen auf den Workflow des Teams in diesem Szenario.

Abbildung eines Feeds mit nur privaten Paketen.

Alle Pakete sind öffentlich

Wenn das Team in diesem Szenario ausschließlich öffentliche Pakete nutzt, unabhängig davon, ob aus der öffentlichen Registrierung oder anderen Open-Source-Repositorys, hat die Einstellung keine Auswirkungen auf ihren Workflow.

Abbildung eines Feeds mit nur öffentlichen Paketen.

Öffentliches Paket, das privat gemacht wurde

Wenn ein öffentliches Paket in ein privates Paket konvertiert wird, wirkt sich die Einstellung für externe Versionen in diesem Fall nicht auf den Workflow des Teams aus.

Abbildung eines Pakets, das von öffentlich in privat konvertiert wurde.

Externe Versionen zulassen

Hinweis

Sie müssen ein Feedbesitzer sein, um extern stammende Versionen zuzulassen. Weitere Informationen finden Sie unter Feedberechtigungen.

  1. Melden Sie sich bei Ihrer Azure DevOps-Organisation an, und navigieren Sie dann zu Ihrem Projekt.

  2. Wählen Sie Artefakte und dann Ihren Feed im Dropdownmenü aus.

  3. Wählen Sie Ihr Paket aus und klicken Sie dann auf die Schaltfläche mit dem Auslassungszeichen, um weitere Optionen anzuzeigen. Wählen Sie "Externe Versionen zulassen" aus.

    Screenshot, der zeigt, wie externe Versionen zugelassen werden.

  4. Wählen Sie die Umschaltfläche aus, um externe Versionen zuzulassen. Wählen Sie "Schließen" aus, wenn Sie fertig sind.

    Screenshot, der zeigt, wie externe Versionen aktiviert werden.

Zulassen externer Versionen mithilfe der REST-API

Zulassen externer Versionen mit PowerShell

  1. Erstellen Sie ein persönliches Zugriffstoken mit Berechtigungen zum Lesen, Schreiben und Verwalten von Packaging>.

    Screenshot zeigt, wie Sie die Verpackungsberechtigungen auswählen.

  2. Erstellen Sie eine Umgebungsvariable für Ihr persönliches Zugriffstoken.

    $env:PATVAR = "YOUR_PERSONAL_ACCESS_TOKEN"

  3. Konvertieren Sie Ihr persönliches Zugriffstoken in baser64-codierte Zeichenfolge, und erstellen Sie den HTTP-Anforderungsheader.

    $token = [Convert]::ToBase64String(([Text.Encoding]::ASCII.GetBytes("username:$env:PatVar")))
$headers = @{
    Authorization = "Basic $token"
}

  4. Erstellen Sie Ihre Endpunkt-URL. Beispiel: //pkgs.dev.azure.com/MyOrg/MyProject/_apis/packaging/feeds/MyFeed/nuget/packages/pkg1.0.0.nupkg/upstreaming?api-version=6.1-preview.1

    • Projektbezogener Feed:

      $url = "https://pkgs.dev.azure.com/<ORGANIZATION_NAME>/<PROJECT_NAME>/_apis/packaging/feeds/<FEED_NAME>/<PROTOCOL>/packages/<PACKAGE_NAME>/upstreaming?api-version=6.1-preview.1"

    • Organisationsspezifischer Feed:

      $url = "https://pkgs.dev.azure.com/<ORGANIZATION_NAME>/_apis/packaging/feeds/<FEED_NAME>/<PROTOCOL>/packages/<PACKAGE_NAME>/upstreaming?api-version=6.1-preview.1"

Führen Sie den folgenden Befehl aus, um den Upstreamverhaltenszustand des Pakets abzurufen. $url und $headers sind die gleichen Variablen, die wir im vorherigen Abschnitt verwendet haben.

Invoke-RestMethod -Uri $url -Headers $headers