Partager via

Protection contre les packages publics malveillants

  • Article

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

Avec les sources en amont d’Azure Artifacts, les développeurs bénéficient de la commodité d’utiliser un flux unifié pour publier et consommer des packages à partir de flux Artifact et de registres publics populaires tels que NuGet.org ou npmjs.com. Auparavant, les flux Artifact combinent une liste de versions de package disponibles à partir du flux lui-même et de toutes les sources en amont configurées.

Illustration montrant le contenu d’un flux.

La fonctionnalité Autoriser les versions sources externes est une fonctionnalité qui permet aux développeurs de choisir s’ils souhaitent consommer des versions de package sources externes. Il régit les packages accessibles à partir des registres publics pour des packages spécifiques.

Lorsque vous désactivez le bouton bascule Autoriser les versions externes, les versions du registre public sont bloquées et deviennent indisponibles pour le téléchargement. Cela ajoute une couche de sécurité supplémentaire en empêchant l’exposition à des packages potentiellement malveillants à partir de registres publics.

Toutefois, si les utilisateurs préfèrent, ils peuvent activer le bouton bascule Autoriser les versions externes pour autoriser l’accès aux packages et les consommer à partir de registres publics.

Remarque

Ce paramètre n’apporte aucune modification aux versions de package déjà enregistrées dans le flux. L’accès à ces versions de package ne changera pas suite à la modification de ce paramètre.

Scénarios applicables

La section suivante illustre différents scénarios courants où le paramètre de version externe bloque les versions de package source externe et d’autres scénarios où il n’est pas nécessaire de bloquer l’accès aux packages publics.

Les versions publiques sont bloquées

Version du package privé rendue publique

Dans ce scénario, une équipe dispose d’un package privé rendu public. Le paramètre des versions externes dans ce cas entraîne le blocage de la consommation du flux de toutes les nouvelles versions avec ce nom de package à partir d’une source publique.

Illustration montrant une version interne du package rendue publique.

Avoir des packages privés et publics

Dans ce scénario, si une équipe utilise une combinaison de packages privés et publics, l’interdiction des packages source en externe bloque toutes les nouvelles versions de package du registre public.

Illustration montrant les packages privés et publics disponibles.

Les versions publiques ne seront pas bloquées

Tous les packages sont privés*

Si tous les packages existants sont privés et que l’équipe n’a pas l’intention d’utiliser de packages publics, le paramètre des versions externes n’a aucun effet sur le flux de travail de l’équipe dans ce scénario.

Illustration montrant le flux avec uniquement des packages privés.

Tous les packages sont publics

Dans ce scénario, si l’équipe consomme exclusivement des packages publics, qu’ils proviennent du registre public ou d’autres référentiels open source, le paramètre n’affecte pas leur flux de travail d’une manière quelconque.

Illustration montrant le flux avec uniquement des packages publics.

Package public rendu privé

Dans ce cas, lorsqu’un package public est converti en package privé, le paramètre de versions externes n’affecte pas le flux de travail de l’équipe de quelque manière que ce soit.

Illustration montrant un package converti d’un package public en privé.

Autoriser les versions externes

Remarque

Vous devez être propriétaire du flux pour autoriser les versions sources externes. Pour plus d’informations, consultez Autorisations de flux.

  1. Connectez-vous à votre organisation Azure DevOps puis accédez à votre projet.

  2. Sélectionnez Artefacts, puis sélectionnez votre flux dans le menu déroulant.

  3. Sélectionnez votre package, puis sélectionnez le bouton de sélection pour plus d’options. Sélectionnez Autoriser les versions sources externes.

    Capture d’écran montrant comment autoriser les versions sources externes.

  4. Sélectionnez le bouton bascule pour autoriser les versions externes. Sélectionnez Fermer lorsque vous avez terminé.

    Capture d’écran montrant comment activer des versions externes.

Autoriser les versions externes à l’aide de l’API REST

Autoriser les versions externes à l’aide de PowerShell

  1. Créez un jeton d’accès personnel avec l’empaquetage>en lecture, écriture et gestion des autorisations.

    Capture d’écran montrant comment sélectionner des autorisations d’empaquetage.

  2. Créez une variable d’environnement pour votre jeton d’accès personnel.

    $env:PATVAR = "YOUR_PERSONAL_ACCESS_TOKEN"

  3. Convertissez votre jeton d’accès personnel en chaîne codée en baser64 et construisez l’en-tête de requête HTTP.

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

  4. Construisez votre URL de point de terminaison. Exemple : //pkgs.dev.azure.com/MyOrg/MyProject/_apis/packaging/feeds/MyFeed/nuget/packages/pkg1.0.0.nupkg/upstreaming?api-version=6.1-preview.1

    • Flux dans l’étendue du projet :

      $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"

    • Flux d’étendue de l’organisation :

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

Exécutez la commande suivante pour récupérer l’état de comportement en amont de votre package. $url et $headers sont les mêmes variables que celles que nous avons utilisées dans la section précédente.

Invoke-RestMethod -Uri $url -Headers $headers