Compartilhar via

Proteja-se contra pacotes públicos maliciosos

  • Artigo

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

Com as fontes upstream do Azure Artifacts, os desenvolvedores obtêm a conveniência de usar um feed unificado para publicar e consumir pacotes de feeds do Artifact e registros públicos populares, como NuGet.org ou npmjs.com. Anteriormente, os feeds de artefato combinavam uma lista de versões de pacote disponíveis do próprio feed e de todas as fontes upstream configuradas.

Uma ilustração mostrando o conteúdo de um feed.

O recurso Permitir versões de origem externa é um recurso que permite que os desenvolvedores escolham se desejam consumir versões de pacote de origem externa. Ele rege quais pacotes podem ser acessados a partir dos registros públicos para pacotes específicos.

Quando você desabilita a opção Permitir versões externas, as versões do registro público são bloqueadas e ficam indisponíveis para download. Isso adiciona uma camada extra de segurança, impedindo a exposição a pacotes potencialmente maliciosos de registros públicos.

No entanto, se os usuários preferirem, eles podem habilitar a alternância Permitir Versões Externas para permitir o acesso e consumir pacotes de registros públicos.

Observação

Essa configuração não fará alterações em nenhuma versão do pacote que já esteja salva no feed. O acesso a essas versões de pacote não será alterado como resultado da alteração dessa configuração.

Cenários aplicáveis

A seção a seguir ilustra vários cenários comuns em que a configuração de versão externa bloqueia versões de pacote de origem externa e outros cenários em que não há necessidade de bloquear o acesso a pacotes públicos.

As versões públicas estão bloqueadas

Versão do pacote privado tornada pública

Nesse cenário, uma equipe tem um pacote privado que foi tornado público. A configuração de versões externas, nesse caso, fará com que o feed bloqueie o consumo de novas versões com esse nome de pacote de uma fonte pública.

Uma ilustração mostrando uma versão do pacote interno tornada pública.

Ter pacotes públicos e privados

Nesse cenário, se uma equipe usar uma combinação de pacotes privados e públicos, não permitir pacotes de origem externa bloqueará todas as novas versões de pacote do registro público.

Uma ilustração mostrando os pacotes públicos e privados disponíveis.

As versões públicas não serão bloqueadas

Todos os pacotes são privados*

Se todos os pacotes existentes forem privados e a equipe não tiver planos de usar nenhum pacote público, a configuração de versões externas não terá efeito no fluxo de trabalho da equipe nesse cenário.

Uma ilustração mostrando feed apenas com pacotes privados.

Todos os pacotes são públicos

Nesse cenário, se a equipe consumir exclusivamente pacotes públicos, seja do registro público ou de outros repositórios de software livre, a configuração não afetará o fluxo de trabalho de forma alguma.

Uma ilustração mostrando feed apenas com pacotes públicos.

Pacote público tornado privado

Nessa situação, quando um pacote público é convertido em um pacote privado, a configuração de versões externas não afeta o fluxo de trabalho da equipe de forma alguma.

Uma ilustração mostrando um pacote convertido de público para privado.

Permitir versões externas

Observação

Você deve ser um proprietário do feed para permitir versões de origem externa. Para obter mais informações, consulte Permissões de feed.

  1. Entre na sua organização do Azure DevOps e navegue até seu projeto.

  2. Selecione Artefatos e, em seguida, selecione o feed no menu suspenso.

  3. Selecione seu pacote e, em seguida, selecione o botão de reticências para obter mais opções. Selecione Permitir versões de origem externa.

    Uma captura de tela mostrando como permitir versões de origem externa.

  4. Selecione o botão de alternância para permitir versões externas. Selecione Fechar quando terminar.

    Uma captura de tela mostrando como habilitar versões externas.

Permitir versões externas usando a API REST

Permitir versões externas usando o PowerShell

  1. Crie um token de acesso pessoal com permissões de leitura, gravação e gerenciamento de pacotes>.

    Captura de tela mostrando como selecionar permissões de empacotamento.

  2. Crie uma variável de ambiente para seu token de acesso pessoal.

    $env:PATVAR = "YOUR_PERSONAL_ACCESS_TOKEN"

  3. Converta seu token de acesso pessoal em uma string codificada em baser64 e construa o cabeçalho da solicitação HTTP.

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

  4. Construa o URL do seu endpoint. Exemplo: //pkgs.dev.azure.com/MyOrg/MyProject/_apis/packaging/feeds/MyFeed/nuget/packages/pkg1.0.0.nupkg/upstreaming?api-version=6.1-preview.1

    • Feed no escopo do projeto:

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

    • Feed no escopo da organização:

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

Execute o comando a seguir para recuperar o estado de comportamento upstream do pacote. $url e $headers são as mesmas variáveis que usamos na seção anterior.

Invoke-RestMethod -Uri $url -Headers $headers