Compartilhar via

Garanta a segurança do Azure Pipelines

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

Os pipelines oferecem recursos avançados para executar scripts e implantar código em ambientes de produção, mas é crucial equilibrar esse poder com a segurança. Você nunca quer que um pipeline se torne um canal para código mal-intencionado. Equilibrar a segurança com a flexibilidade e o poder necessários para as equipes de desenvolvimento é essencial.

Este artigo fornece uma visão geral das configurações necessárias relacionadas à segurança para proteger seus pipelines contra ameaças e vulnerabilidades.

Pré-requisitos

Categoria Requisitos
Azure DevOps – Implementar recomendações para tornar o Azure DevOps seguro.
– Conhecimento básico do YAML e do Azure Pipelines. Para mais informações, veja Como criar seu primeiro pipeline.
Permissões – Para modificar permissões de pipelines: membro do grupo Administradores do Projeto.
– Para modificar as permissões da organização: membro do grupo Administradores de Coleção de Projetos.

Restringir o acesso ao projeto, ao repositório e à conexão de serviço

Para aprimorar a segurança, considere separar seus projetos, usar políticas de branch e adicionar mais medidas de segurança para os forks. Minimize o escopo das conexões de serviço e use os métodos de autenticação mais seguros.

  • Projetos separados: gerenciar cada produto e equipe em projetos separados. Isso impede que os pipelines de um produto acessem inadvertidamente recursos abertos de outro produto, minimizando a exposição lateral.
  • Use identidades no nível do projeto: use uma identidade de construção baseada em projeto para pipelines em vez de uma identidade no nível da coleção. As identidades no nível do projeto só podem acessar recursos em seu projeto associado, minimizando o risco de acesso não autorizado por atores mal-intencionados. Para obter mais informações, consulte as identidades de build delimitadas e a delimitação de autorização de trabalho.
  • Usar políticas de ramo: Para garantir alterações seguras no código e no pipeline, aplique permissões e políticas de ramo. Além disso, considere adicionar permissões de pipeline e verificações a repositórios.
  • Adicione segurança adicional para bifurcações: quando você trabalha com repositórios públicos do GitHub, considere cuidadosamente sua abordagem para compilações de bifurcação. Ramificações provenientes de fora de sua organização representam riscos específicos.
    • Não forneça segredos para builds de fork: por padrão, os pipelines são configurados para executar forks, mas segredos e recursos protegidos não são expostos automaticamente aos jobs nesses pipelines. É essencial não desabilitar essa proteção para manter a segurança.
    • Considere disparar manualmente builds de bifurcação: desative os builds automáticos de bifurcação e use comentários de pull request para construir manualmente essas contribuições. Essa configuração oferece a oportunidade de examinar o código antes de disparar um build. Para obter mais informações, consulte Desativar builds automáticos de fork.
    • Não forneça segredos para builds de fork: por padrão, os segredos associados ao seu pipeline não são disponibilizados para validações de pull requests de bifurcações. Não habilite a opção de disponibilizar segredos para builds de bifurcações. Para obter instruções sobre como localizar e verificar essa configuração, consulte Contribuições de forks.
    • Considere disparar manualmente builds de bifurcação: desative os builds automáticos de bifurcação e use comentários de pull request para construir manualmente essas contribuições. Essa configuração oferece a oportunidade de examinar o código antes de disparar um build. Para obter instruções sobre como fazer isso, veja Desativar compilações automáticas de fork.
    • Use agentes hospedados pela Microsoft para builds de forks: evite executar builds de forks em agentes hospedados por você. Isso pode permitir que organizações externas executem código externo em computadores em sua rede corporativa. Sempre que possível, use agentes hospedados pela Microsoft.
    • Use o aplicativo GitHub do Azure Pipelines para limitação de escopo de token: Quando você cria uma solicitação de pull de um fork do GitHub, o Azure Pipelines garante que o pipeline não possa alterar nenhum conteúdo do repositório GitHub. Essa restrição só se aplicará se você usar o aplicativo GitHub do Azure Pipelines para se integrar ao GitHub.

Proteger conexões de serviço

  • Minimizar o escopo das conexões de serviço: as conexões de serviço só devem ter acesso aos recursos necessários. Ao criar uma nova conexão de serviço do Azure Resource Manager, escolha sempre um grupo de recursos específico. Verifique se o grupo de recursos contém apenas as VMs ou recursos necessários para o build. Para obter instruções sobre como configurar conexões de serviço, consulte Usar uma conexão de serviço do Azure Resource Manager.
  • Use a federação de identidade de carga de trabalho para autenticação: Sempre que possível, use a federação de identidade de carga de trabalho em vez de um principal de serviço para sua conexão de serviço do Azure. A federação de identidade 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. Para obter instruções sobre como fazer isso, consulte Criar uma conexão de serviço com a federação de identidade de tarefas (automática).
  • Minimizar o acesso ao aplicativo GitHub: ao configurar o aplicativo GitHub para o Azure DevOps, conceda acesso somente aos repositórios que você pretende criar usando pipelines.

Utilize pipelines YAML em substituição a pipelines clássicos

Para aumentar a segurança e reduzir o risco de erros acidentais de configuração, use pipelines YAML em vez de pipelines clássicos. Essa precaução previne preocupações de segurança que surgem do compartilhamento de recursos, como as ligações de serviço, entre YAML e pipelines clássicos. Se sua organização estiver usando pipelines clássicos, migre os pipelines para o YAML.

  • O YAML oferece os benefícios da infraestrutura como código: trate pipelines YAML como qualquer outro código porque as etapas e as dependências são definidas no código. Também há uma visibilidade clara das configurações do pipeline e um risco reduzido de erros de configuração acidentais.
  • Os pipelines YAML podem ser combinados com medidas de segurança aprimoradas: por meio de revisões de código e solicitações de pull, use políticas de branch para configurar um processo de revisão para solicitações de pull para evitar mesclagens incorretas.
  • Gerenciamento de acesso a recursos: os proprietários de recursos controlam se um pipeline YAML pode acessar recursos específicos. Esse recurso de segurança impede ataques como roubar outro repositório. Use Aprovações e verificações para fornecer controle de acesso para a execução de cada etapa do pipeline.
    • Verificação de ramo protegido: se você tiver processos manuais de revisão de código para ramos específicos, poderá estender essa proteção aos pipelines. Uma verificação de branch protegida para um recurso impede que os pipelines sejam executados automaticamente em branches não autorizados.
    • Verificação manual de aprovação: use uma verificação de aprovação manual para impedir que as solicitações de pipeline usem um recurso protegido até serem aprovadas manualmente por usuários ou grupos especificados.
    • Verificação de horário comercial: use essa verificação para garantir que uma implantação de pipeline seja iniciada dentro de um dia e uma janela de tempo especificados.
  • Desabilitar a criação de pipelines clássicos: Desabilite a criação de pipelines de build clássicos e pipelines de lançamento clássicos de forma independente. Quando ambos estão desabilitados, nenhum pipeline de build clássico, pipeline de versão clássico, grupos de tarefas ou grupos de implantação podem ser criados por meio da interface do usuário ou da API REST. Para obter mais informações, consulte Desabilitar a criação de pipelines clássicos.

Agentes seguros

Para proteger contêineres, marque volumes como somente leitura, defina limites de recursos, use imagens confiáveis, procure vulnerabilidades e imponha políticas de segurança.

  • Use agentes hospedados pela Microsoft em vez de auto-hospedados: agentes hospedados pela Microsoft oferecem isolamento e uma máquina virtual limpa para cada execução de um pipeline. Use agentes hospedados pela Microsoft em vez de agentes auto-hospedados. Para obter mais informações, consulte agentes hospedados pela Microsoft.
  • Agentes separados para cada projeto: para atenuar a movimentação lateral e evitar a contaminação cruzada entre projetos, mantenha pools de agentes separados, cada um dedicado a um projeto específico.
  • Use contas de baixo privilégio para executar agentes: para aprimorar a segurança do sistema, use 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 gerenciada. Não execute um agente em uma identidade com acesso direto aos recursos do Azure DevOps.
  • Isolar artefatos de produção e pools de agentes sensíveis: use diferentes pools de agentes para evitar problemas de segurança.
    • Use um pool de agentes separado para artefatos de produção: isole artefatos de produção usando um pool de agentes distinto, impedindo implantações acidentais de branches de não-produção.
    • Segmentar pools sensíveis: Crie pools separados para cargas de trabalho sensíveis e não sensíveis. Permita apenas credenciais em definições de compilação associadas ao pool apropriado.
  • Configurar firewalls restritivos para agentes auto-hospedados: configure firewalls para serem o mais restritivos possível e, ao mesmo tempo, permitir que os agentes funcionem, equilibrando a segurança e a usabilidade.
  • Atualize regularmente os pools de agentes auto-hospedados: mantenha seus agentes auto-hospedados atualizados com atualizações regulares para garantir que o código vulnerável não esteja em execução, reduzindo o risco de exploração.

Usar variáveis e parâmetros com segurança

Use com segurança variáveis e parâmetros em seus pipelines seguindo as práticas recomendadas para definir segredos. As práticas recomendadas incluem restringir o uso de segredo, usar variáveis de tempo de fila e habilitar a validação de argumentos de tarefa do shell para proteger seu pipeline contra ameaças e vulnerabilidades.

  • Restringir o acesso a segredos: remova todos os segredos ou chaves de serem exibidos em pipelines. Mova para métodos de autenticação sem segredo, como federação de identidade de carga de trabalho ou definir segredos na interface do usuário, um grupo de variáveis ou um grupo de variáveis proveniente do Azure Key Vault.
  • Habilitar a validação de parâmetros do shell: quando a configuração Habilitar validação de parâmetros de argumentos de tarefas do shell está ativada, há uma verificação adicional para caracteres como ponto-e-vírgula, aspas e parênteses. Ative Habilitar a validação dos argumentos de tarefas de shell no nível da organização ou do projeto em Configurações> de Pipelines>Configurações.
  • Limitar variáveis que podem ser definidas no tempo de fila: impedir que os usuários definam novas variáveis no momento da fila, habilitando a configuração limitar variáveis que podem ser definidas no momento da fila nas Configurações da Organização, >>Configurações.
  • Use parâmetros em vez de variáveis: ao contrário das variáveis, um pipeline em execução não pode modificar parâmetros de pipeline. Os parâmetros têm tipos de dados como number e stringpodem ser restritos a subconjuntos de valor específicos. Essa restrição é valiosa quando um aspecto configurável pelo usuário do pipeline só deve aceitar valores de uma lista predefinida, garantindo que o pipeline não aceite dados arbitrários.
  • Referenciar segredos a partir de modelos: Em vez de incluir scripts inline com parâmetros secretos diretamente no seu YAML de pipeline, use modelos para abstrair informações sensíveis do pipeline principal. Para implementar essa abordagem, crie um arquivo YAML separado para o script e armazene esse script em um repositório separado e seguro. Em seguida, você pode fazer referência ao modelo e passar uma variável secreta em seu YAML como um parâmetro. A variável segura deve vir do Azure Key Vault, de um grupo de variáveis ou da interface do usuário do pipeline. Para mais informações, veja Use modelos.
  • Limite segredos com políticas de ramificação e permissões de grupo de variáveis: você pode usar uma combinação de permissões de grupo de variáveis, inserção condicional de trabalhos e políticas de ramificação para garantir que os segredos fiquem atrelados à main ramificação. Para obter mais informações, consulte Proteger segredos.
  • Use setvariable para limitar a definição de variáveis: Use o settableVariables atributo para configurar quais variáveis os autores de pipeline têm permissão para definir em um pipeline. Sem essa configuração, os autores de pipeline podem declarar novas variáveis ilimitadas com o comando de registro em log setvariable. Quando você especifica uma lista with settableVariablesvazia, todas as configurações de variáveis não são permitidas. Para obter mais informações, consulte o settableVariables atributo no esquema YAML.

O melhor método para proteger um segredo é não ter um segredo em primeiro lugar. Evite usar segredos quando possível, nunca armazene-os em arquivos YAML e verifique se eles não são registrados ou impressos para manter a segurança.

  • Evite usar segredos quando possível: verifique se o pipeline pode usar um método diferente do uso de um segredo para executar uma tarefa, como uma conexão de serviço com federação de identidade de carga de trabalho ou uma identidade gerenciada. As identidades gerenciadas permitem que seus aplicativos e serviços se autentiquem com o Azure sem a necessidade de credenciais explícitas. Para obter mais informações, consulte Usar entidades de serviço e identidades gerenciadas. Não coloque segredos no YAML: nunca armazene valores confidenciais como texto sem formatação em um arquivo .yml do Azure Pipelines.
  • Não registre ou imprima segredos: evite ecoar segredos no console, usá-los em parâmetros de linha de comando ou registrá-los em arquivos. O Azure Pipelines tenta remover segredos dos logs sempre que possível, mas não consegue capturar todas as maneiras pelas quais os segredos podem ser vazados.
  • Não use dados estruturados como JSON como segredos: crie segredos individuais para cada valor confidencial. Essa abordagem garante melhor precisão de redação e minimiza o risco de expor dados confidenciais inadvertidamente.

Auditar e girar segredos

Para proteger seus pipelines, audite regularmente o manejo de segredos em tarefas e logs, reveja e remova segredos desnecessários e faça a rotação de segredos para reduzir os riscos à segurança.

  • Auditar o tratamento de segredo em tarefas e logs: verifica as tarefas para garantir que os segredos não sejam enviados para hosts ou impressos em logs. Verifique se não há segredos em nenhum arquivo de log, incluindo os logs de erros.
  • Examine os segredos registrados: confirme se os segredos em seu pipeline ainda são necessários e remova todos os que não são mais necessários para reduzir a desordem e possíveis riscos à segurança.
  • Rotação de segredos: realize regularmente a rotação dos segredos para minimizar a janela de tempo durante a qual um segredo comprometido pode ser explorado.

Impedir a execução de código mal-intencionado

Para garantir que apenas o código testado e higienizado seja executado em seu pipeline, examine regularmente seus pipelines em busca de problemas comuns.

  • Verificação de código: escape de caracteres especiais em argumentos para evitar a injeção de comando do shell. Você pode usar a Segurança Avançada do GitHub para Azure DevOps para automatizar a verificação de código.
  • Validar entradas e usar parâmetros: validar parâmetros e argumentos de entrada para evitar comportamentos não intencionais. Use consultas parametrizadas em scripts para evitar a injeção de SQL. Parâmetros de runtime ajudam a evitar problemas de segurança relacionados a variáveis, como Injeção de Argumento.
  • Não use PATH em scripts: Depender da configuração do PATH agente é perigoso porque pode ser alterada por um script ou uma ferramenta anterior. Sempre use um caminho totalmente qualificado.
  • Controlar tarefas disponíveis: desabilite a capacidade de instalar e executar tarefas do Marketplace, o que oferece maior controle sobre o código que é executado em um pipeline.

Contêineres de segurança

Saiba como proteger contêineres por meio de alterações de configuração, verificação e políticas.

  • Marcar volumes como somente leitura: Contêineres incluem montagens de volumes fornecidas pelo sistema para tarefas, ferramentas e componentes externos necessários para operar com o agente host. Defina externals, tasks e tools como somente leitura para segurança adicional.
  • Defina limites de recursos específicos do contêiner: defina limites de CPU e memória para impedir que contêineres consumam recursos excessivos, o que pode levar a vulnerabilidades de negação de serviço ou segurança.
  • Usar imagens confiáveis: use imagens oficiais e verificadas de fontes respeitáveis, como o Registro de Contêiner do Azure ou o Docker Hub. Sempre especifique uma versão ou marca específica para manter a consistência e a confiabilidade, em vez de depender da marca latest. Atualize regularmente as imagens base para incluir os patches de segurança mais recentes e correções de bugs.
  • Examine os contêineres em busca de vulnerabilidades e imponha a proteção contra ameaças em runtime: use ferramentas como o Microsoft Defender para Nuvem para monitorar e detectar riscos de segurança. Além disso, o Registro de Contêiner do Azure oferece verificação de vulnerabilidade integrada para ajudar a garantir que as imagens de contêiner estejam seguras antes da implantação. Você também pode integrar ferramentas de verificação de terceiros por meio de extensões do Azure DevOps para verificações de segurança adicionadas.
  • Implemente políticas de segurança para evitar o escalonamento de privilégios e garanta que os contêineres sejam executados com a menor quantidade de privilégios necessários: por exemplo, o AKS (Serviço de Kubernetes do Azure), o controle de acesso baseado em função e a Admissão de Segurança de Pod permitem impor políticas que restringem privilégios de contêiner, garantem a execução não raiz e limitam o acesso a recursos críticos.
  • Utilizar políticas de rede: as políticas de rede podem ser usadas para restringir a comunicação entre contêineres, garantindo que somente contêineres autorizados possam acessar recursos confidenciais em sua rede. Além disso, o Azure Policy para AKS pode ser aplicado para impor práticas recomendadas de segurança de contêiner, como garantir que apenas imagens de contêiner confiáveis sejam implantadas.

Usar modelos para impor práticas recomendadas

Comece com um modelo mínimo e aplique gradualmente as extensões. Essa abordagem garante que, à medida que você implementa as práticas de segurança, você tenha um ponto de partida centralizado que abrange todos os pipelines.

  • Use modelos de extensão: Os modelos de extensão definem a estrutura externa e oferecem pontos específicos para personalizações direcionadas. O uso de modelos de extensões pode impedir que código mal-intencionado se infiltre em um pipeline.
  • Restringir o acesso com etapas: limite o acesso à rede fazendo com que etapas como baixar pacotes sejam executadas em um contêiner e não no host. Quando as etapas são executadas em um contêiner, você impede que um ator incorreto modifique a configuração do agente ou deixe o código mal-intencionado para execução posterior.