Outras considerações de segurança para o Azure Pipelines

Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2020

Quando se trata de proteger o Azure Pipelines, há várias outras considerações a serem lembradas, como proteger a infraestrutura compartilhada, repositórios, projetos e muito mais.

Proteja a infraestrutura compartilhada

Recursos protegidos no Azure Pipelines são uma abstração da infraestrutura real. Siga estas recomendações para proteger a infraestrutura subjacente.

Usar pools hospedados pela Microsoft

Os pools hospedados pela Microsoft oferecem isolamento e uma máquina virtual limpa para cada execução de um pipeline. Se possível, use pools hospedados pela Microsoft em vez de pools auto-hospedados.

Separar agentes para cada projeto

Um agente pode ser associado apenas a um único pool. Você pode compartilhar agentes entre projetos associando o pool a vários projetos. Na prática, vários projetos podem utilizar o mesmo agente consecutivamente. Embora econômica, essa abordagem pode introduzir riscos de movimento lateral.

Para mitigar o movimento lateral e evitar a contaminação cruzada entre projetos, mantenha pools de agentes separados, cada um dedicado a um projeto específico.

Usar contas de baixo privilégio para executar agentes

Embora você possa ficar tentado, executar o agente em uma identidade com acesso direto aos recursos do Azure DevOps pode ser arriscado. Essa configuração é predominante em organizações que usam a ID do Microsoft Entra, mas apresenta riscos. Se você executar o agente em uma identidade com suporte da ID do Microsoft Entra, ele poderá acessar diretamente as APIs do Azure DevOps sem depender do token de acesso do trabalho. Para obter melhor segurança, considere executar o agente usando uma conta local sem privilégios, como Serviço de Rede.

Importante

No Azure DevOps, há um grupo chamado Contas do Serviço de Coleção de Projetos, que pode ser enganoso. Por herança, os membros das Contas do Serviço de Coleção de Projetos também são considerados membros dos Administradores de Coleção de Projetos. Alguns clientes executam seus agentes de build usando uma identidade com suporte da ID do Microsoft Entra e essas identidades podem fazer parte das Contas do Serviço de Coleção de Projetos. Mas, se os adversários executarem um pipeline em um desses agentes de build, eles poderão obter controle sobre toda a organização do Azure DevOps.

Há casos em que os agentes auto-hospedados operam em contas altamente privilegiadas. Esses agentes geralmente utilizam essas contas privilegiadas para acessar segredos ou ambientes de produção. Mas, se os adversários executarem um pipeline comprometido em um desses agentes de compilação, eles obterão acesso a esses segredos. Em seguida, os adversários podem se mover lateralmente por meio de outros sistemas acessíveis por meio dessas contas.

Para aprimorar a segurança do sistema, recomendamos usar a conta com privilégios mais baixos para executar agentes auto-hospedados. Por exemplo, considere usar sua conta de computador ou uma identidade de serviço gerenciado. Além disso, confie ao Azure Pipelines o gerenciamento do acesso a segredos e ambientes.

Minimizar o escopo das conexões de serviço

Certifique-se de que as conexões de serviço tenham acesso apenas aos recursos necessários. Sempre que possível, considere usar a federação de identidade de carga de trabalho no lugar de uma entidade de serviço para sua conexão de serviço do Azure. A federação de identidade de carga de trabalho usa o OIDC (Open ID Connect), uma tecnologia padrão do setor, para facilitar a autenticação entre o Azure e o Azure DevOps sem depender de segredos.

Verifique se a conexão de serviço do Azure está no escopo para acessar apenas os recursos necessários. Evite conceder amplos direitos de colaborador para toda a assinatura do Azure aos usuários.

Ao criar uma nova conexão de serviço do Azure Resource Manager, sempre escolha um grupo de recursos específico. Verifique se o grupo de recursos contém apenas as VMs ou os recursos necessários para o build. Da mesma forma, ao configurar o aplicativo GitHub, conceda acesso somente aos repositórios que você pretende criar usando o Azure Pipelines.

Proteja projetos

Além dos recursos individuais, é crucial considerar os grupos de recursos no Azure DevOps. Os recursos são organizados por projetos de equipe, e entender o que seu pipeline pode acessar com base nas configurações e contenção do projeto é essencial.

Cada trabalho em seu pipeline recebe um token de acesso com permissões para ler recursos abertos. Em alguns casos, os pipelines também podem atualizar esses recursos. Isso significa que, embora sua conta de usuário possa não ter acesso direto a um recurso específico, os scripts e as tarefas em execução no pipeline ainda poderão acessá-la. Além disso, o modelo de segurança do Azure DevOps permite o acesso a esses recursos de outros projetos dentro da organização. Se você decidir restringir o acesso ao pipeline a determinados recursos, essa decisão se aplicará a todos os pipelines dentro de um projeto — pipelines específicos não podem receber acesso seletivo a recursos abertos.

Separar projetos

Dada a natureza dos recursos abertos, considere gerenciar cada produto e equipe em projetos separados. Ao fazer isso, você evita que pipelines de um produto acessem inadvertidamente recursos abertos de outro produto, minimizando assim a exposição lateral. Mas, quando várias equipes ou produtos compartilham um projeto, o isolamento granular de seus recursos se torna um desafio.

Se sua organização do Azure DevOps foi criada antes de agosto de 2019, as execuções ainda poderão ter acesso a recursos abertos em todos os projetos da sua organização. O administrador da organização deve examinar uma configuração de segurança crítica no Azure Pipelines que habilita o isolamento do projeto para pipelines.

Você pode encontrar essa configuração em Configurações da>organização, Configurações de>pipelines ou diretamente: . https://dev.azure.com/Organization_Name/_settings/pipelinessettings

Proteger repositórios

Em repositórios de controle de versão, você pode armazenar o código-fonte, o arquivo YAML do pipeline e os scripts e ferramentas necessários. Para garantir alterações seguras no código e no pipeline, é crucial aplicar permissões e políticas de branch. Além disso, considere adicionar permissões e verificações de pipeline aos repositórios.

Além disso, revise as configurações de controle de acesso padrão para seus repositórios.

Lembre-se de que o design do Git significa que a proteção no nível da ramificação tem limitações. Os usuários com acesso push a um repositório normalmente podem criar novas ramificações. Se você estiver trabalhando com projetos de código aberto do GitHub, qualquer pessoa com uma conta do GitHub poderá bifurcar seu repositório e propor contribuições. Como os pipelines estão associados a um repositório (não a branches específicos), é essencial tratar o código e os arquivos YAML como potencialmente não confiáveis.

Forks

Quando você está trabalhando com repositórios públicos do GitHub, é essencial considerar cuidadosamente sua abordagem para compilações de bifurcação. As bifurcações, originadas de fora da sua organização, representam riscos específicos. Para proteger seus produtos contra códigos de contribuição potencialmente não confiáveis, leve em conta as seguintes recomendações

Observação

Essas recomendações se aplicam principalmente à criação de repositórios públicos do GitHub.

Não fornecer segredos para builds de fork

Por padrão, seus pipelines são configurados para criar bifurcações, mas segredos e recursos protegidos não são expostos automaticamente aos trabalhos nesses pipelines. É essencial não desabilitar essa proteção para manter a segurança.

Observação

Quando você habilita builds de bifurcação para acessar segredos, o Azure Pipelines restringe o token de acesso usado por padrão. Esse token tem acesso limitado a recursos abertos em comparação com um token de acesso regular. Para conceder às compilações de bifurcação as mesmas permissões que as compilações regulares, ative a configuração Fazer com que as compilações de bifurcação tenham as mesmas permissões que as compilações regulares.

Considere disparar manualmente builds de fork

Você pode desativar builds automáticos de bifurcação e, em vez disso, usar comentários de solicitação de pull como uma maneira de criar manualmente essas contribuições. Essa configuração oferece a oportunidade de revisar o código antes de disparar uma compilação.

Usar agentes hospedados pela Microsoft para builds de bifurcação

Evite executar builds de bifurcações em agentes auto-hospedados. Isso pode permitir que organizações externas executem código externo em computadores dentro de sua rede corporativa. Sempre que possível, use agentes hospedados pela Microsoft. Para agentes auto-hospedados, implemente o isolamento de rede e certifique-se de que os agentes não persistam seu estado entre os trabalhos.

Revisar alterações de código

Antes de executar o pipeline em uma solicitação de pull bifurcada, examine cuidadosamente as alterações propostas e verifique se você está confortável em executá-las.

A versão do pipeline YAML que você executa é a da solicitação de pull. Portanto, preste atenção especial às alterações no código YAML e ao código que é executado quando o pipeline é executado, como scripts de linha de comando ou testes de unidade.

Limitação do escopo do token do GitHub

Quando você cria uma solicitação de pull bifurcado do GitHub, o Azure Pipelines garante que o pipeline não possa alterar nenhum conteúdo do repositório do GitHub. Essa restrição se aplicará somente se você usar o aplicativo GitHub do Azure Pipelines para se integrar ao GitHub. Se você usar outras formas de integração com o GitHub, por exemplo, o aplicativo OAuth, a restrição não será imposta.

Branches de usuário

Os usuários em sua organização com as permissões corretas podem criar novos branches contendo código novo ou atualizado. Esse código pode ser executado por meio do mesmo pipeline que seus branches protegidos. Se o arquivo YAML no novo branch for alterado, o YAML atualizado será usado para executar o pipeline. Embora esse design permita grande flexibilidade e autoatendimento, nem todas as alterações são seguras (sejam feitas de forma mal-intencionada ou não).

Se o pipeline consumir o código-fonte ou estiver definido no Azure Repos, você deverá entender completamente o modelo de permissões do Azure Repos. Especificamente, um usuário com permissão Criar Branch no nível do repositório poderá introduzir o código no repositório mesmo ele que não tenha a permissão Contribuir.

Outras considerações de segurança

Há o seguinte punhado de outras coisas que você deve considerar ao proteger pipelines.

Confie no PATH

Confiar na configuração PATH do agente é perigoso. Pode não apontar onde você acha que sim, já que foi potencialmente alterado por um script ou ferramenta anterior. Para scripts e binários críticos de segurança, sempre use um caminho totalmente qualificado para o programa.

Segredos de log

O Azure Pipelines tenta tirar segredos dos logs sempre que possível. Essa filtragem é feita na base do melhor esforço e não pode capturar todas as formas com que os segredos podem ser vazados. Evite ecoar segredos no console, usá-los em parâmetros de linha de comando ou registrá-los em arquivos.

Bloquear contêineres

Os contêineres têm alguns mapeamentos de montagem de volume fornecidos pelo sistema nas tarefas, no workspace e nos componentes externos necessários para se comunicar com o agente de host. Você pode marcar qualquer um ou todos esses volumes somente leitura.

resources:
  containers:
  - container: example
    image: ubuntu:22.04
    mountReadOnly:
      externals: true
      tasks: true
      tools: true
      work: false  # the default; shown here for completeness

Normalmente, a maioria das pessoas deve definir os três primeiros diretórios como somente leitura e deixar work como leitura/gravação. Se você não gravar no work diretório em um trabalho ou etapa específica, sinta-se à vontade para tornar work somente leitura também. Mas, se as tarefas do pipeline envolverem automodificação, talvez seja necessário manter tasks como leitura/gravação.

Controlar tarefas disponíveis

Você pode desabilitar a capacidade de instalar e executar tarefas do Marketplace, o que permite maior controle sobre o código executado em um pipeline. Você também pode desativar todas as tarefas prontas para uso (exceto Checkout, que é uma ação especial no agente). Recomendamos que você não desabilite tarefas integradas na maioria das circunstâncias.

As tarefas instaladas diretamente com tfx estão sempre disponíveis. Com esses dois recursos habilitados, somente essas tarefas estão disponíveis.

Usar o serviço de Auditoria

Muitos eventos de pipeline são registrados no serviço de auditoria. Revise o log de auditoria periodicamente para garantir que nenhuma alteração maliciosa tenha passado. Acesse https://dev.azure.com/ORG-NAME/_settings/audit para começar.

Próximas etapas

Revise a visão geral da segurança