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

Serviços de DevOps do Azure | Azure DevOps Server 2022 | Azure DevOps Server 2020

Quando se trata de proteger os Pipelines do Azure, há várias outras considerações a ter em mente, como proteger infraestruturas compartilhadas, repositórios, projetos e muito mais.

Proteja a infraestrutura compartilhada

Os 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.

Agentes separados 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 seja rentável, esta 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 com privilégios baixos para executar agentes

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

Importante

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

Há casos em que agentes auto-hospedados operam sob 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 terão acesso a esses segredos. Então, os adversários podem se mover lateralmente através de outros sistemas acessíveis através dessas contas.

Para melhorar a segurança do sistema, recomendamos o uso da conta com privilégios mais baixos para executar agentes auto-hospedados. Por exemplo, considere usar sua conta de máquina 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 identidades 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 identidades de carga de trabalho usa o Open ID Connect (OIDC), uma tecnologia padrão do setor, para facilitar a autenticação entre o Azure e o Azure DevOps sem depender de segredos.

Certifique-se de que sua conexão de serviço do Azure tenha escopo para acessar apenas os recursos necessários. Evite conceder amplos direitos de contribuidor 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. Certifique-se de que o grupo de recursos contém apenas as VMs ou recursos necessários para a compilação. Da mesma forma, ao configurar o aplicativo GitHub, conceda acesso apenas aos repositórios que você pretende criar usando o Azure Pipelines.

Proteger 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, scripts e tarefas em execução em seu pipeline ainda podem acessá-lo. 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 do 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.

Projetos separados

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 a sua organização do Azure DevOps tiver sido 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 sua organização deve rever uma definição de segurança crítica no Azure Pipelines que permite o isolamento de projetos 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

Nos 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 ramificação. Além disso, considere adicionar permissões e verificações de pipeline aos repositórios.

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

Lembre-se de que o design do Git significa que a proteção em nível de ramificação tem limitações. Os usuários com acesso por 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 pode bifurcar seu repositório e propor contribuições. Como os pipelines estão associados a um repositório (não a ramificações específicas), é 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 fork. As bifurcações, originárias de fora da sua organização, representam riscos específicos. Para proteger seus produtos de códigos de contribuição potencialmente não confiáveis, leve em consideração as seguintes recomendações

Nota

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

Não forneça segredos para fork builds

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 desativar essa proteção para manter a segurança.

Nota

Quando você habilita compilações de bifurcação para acessar segredos, o Azure Pipelines restringe o token de acesso usado por padrão. Este 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, habilite a configuração Fazer com que as compilações de bifurcação tenham as mesmas permissões que as compilações regulares.

Considere acionar manualmente compilações de fork

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

Usar agentes hospedados pela Microsoft para compilações fork

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

Rever alterações de código

Antes de executar seu pipeline em uma solicitação pull-forked, analise cuidadosamente as alterações propostas e certifique-se de que está confortável em executá-lo.

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

Limitação do escopo do token GitHub

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

Sucursais de utilizadores

Os usuários em sua organização com as permissões certas podem criar novas ramificações contendo código novo ou atualizado. Esse código pode ser executado através do mesmo pipeline que suas ramificações protegidas. Se o arquivo YAML na nova ramificação for alterado, o YAML atualizado será usado para executar o pipeline. Embora este design permita grande flexibilidade e autosserviço, nem todas as alterações são seguras (feitas maliciosamente ou não).

Se seu pipeline consome código-fonte ou está definido no Azure Repos, você deve entender completamente o modelo de permissões do Azure Repos. Em particular, um usuário com permissão Criar ramificação no nível do repositório pode introduzir código no repositório, mesmo que esse usuário não tenha permissão de contribuição .

Outras considerações de segurança

Há a seguir um punhado de outras coisas que você deve considerar ao proteger pipelines.

Confie no PATH

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

Segredos de registo

O Azure Pipelines tenta limpar segredos de logs sempre que possível. Essa filtragem é baseada no melhor esforço e não pode capturar todas as maneiras pelas quais os segredos podem ser vazados. Evite ecoar segredos para o console, usá-los em parâmetros de linha de comando ou registrá-los em arquivos.

Bloquear contentores

Os contêineres têm alguns mapeamentos de montagens de volume fornecidos pelo sistema nas tarefas, no espaço de trabalho e nos componentes externos necessários para se comunicar com o agente do host. Você pode marcar qualquer um ou todos esses volumes como 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 escrever no work diretório em um trabalho ou etapa específica, sinta-se à vontade para fazer work somente leitura também. Mas, se suas tarefas de pipeline envolverem automodificação, talvez seja necessário manter tasks como leitura-gravação.

Controlar tarefas disponíveis

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

As tarefas instaladas diretamente com tfx estão sempre disponíveis. Com ambos os recursos habilitados, apenas 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 mal-intencionada tenha passado. Visite https://dev.azure.com/ORG-NAME/_settings/audit para começar.

Próximos passos

Revise a visão geral de segurança