Garanta a segurança do Azure Pipelines

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

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

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

Para aumentar a segurança, considere separar seus projetos, usar políticas de ramificação e adicionar mais medidas de segurança para bifurcações. 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 pipelines de um produto acessem inadvertidamente recursos abertos de outro produto, minimizando a exposição lateral.
• Usar identidades em nível de projeto: use uma identidade de compilação baseada em projeto para pipelines em vez de uma identidade em nível de 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 identidades de compilação com escopo e escopo 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, adicione permissões e verificações de pipeline aos 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. Bifurcações provenientes de fora de sua organização representam riscos específicos.
  • Não fornecer segredos para compilações de bifurcações: 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 Disponibilizar segredos para compilações de bifurcações. Para obter instruções sobre como localizar e verificar essa configuração, consulte Contribuições de forks.
  • Considere acionar manualmente compilações de bifurcações: desative os compilações automáticos de bifurcações e use os comentários do pull request para compilar 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.
  • Revise os requisitos de comentários do pull request para ambas as origens: os requisitos de comentários do pull request para acionar execuções de validação podem ser configurados independentemente, dependendo se o pull request se origina do mesmo repositório ou de um bifurcação. Examine as configurações de ambas as fontes para garantir que a postura de segurança pretendida seja aplicada a contribuições externas (fork), bem como solicitações de pull internas.
  • Use agentes hospedados pela Microsoft para compilações de bifurcações: evite executar compilações de bifurcações em agentes auto-hospedados. 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 do escopo do token: ao compilar um pull request 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 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 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 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.
• Restringir conexões de serviço a ramificações específicos: use uma verificação de controle de ramificação para limitar quais ramificações podem usar sua conexão de serviço. Ter uma verificação de controle de ramificação garante que as conexões de serviço sejam executadas apenas em ramificações autorizadas e que todos os recursos de pipeline vinculados sejam criados a partir de ramificações permitidas.
• Use a conexão de serviço Azure DevOps para acesso sem PAT a recursos Azure DevOps: Azure DevOps Services dá suporte a uma conexão de serviço Azure DevOps que é autenticada usando Microsoft Entra identidades de carga de trabalho (uma entidade de serviço ou identidade gerenciada) em vez de PATs (tokens de acesso pessoal) ou tokens de sessão. Considere-a como uma alternativa mais segura quando os pipelines precisarem acessar recursos do Azure DevOps, como checkout de repositório entre organizações, reutilização de modelos YAML ou feeds do Azure Artifacts.

Use pipelines YAML em vez de 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 usa pipelines clássicos, migre os pipelines para 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.
• Pipelines YAML podem ser combinados com medidas de segurança aprimoradas: por meio de revisões de código e pull requests, use políticas de ramificação para configurar um processo de revisão para pull requests e evitar merges incorretos.
• 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 cada execução de pipeline.
  • Verificação de ramificação protegida: se você tiver processos manuais de revisão de código para ramificações específicas, poderá estender essa proteção aos pipelines. Se você tiver processos manuais de revisão de código para ramificações específicas, poderá estender essa proteção aos pipelines.
  • 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.
• Desativar a criação de pipelines clássicos: desativa independentemente a criação de pipelines de compilação clássicos e pipelines de lançamento clássicos. Quando ambos estão desativados, nenhum pipeline de compilação clássico, pipeline de lançamento clássico, grupos de tarefas ou grupos de implantação pode ser criado por meio da interface do usuário ou da API REST. Para obter mais informações, consulte Desativar 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.

• Usar agentes hospedados pela Microsoft em vez de agentes auto-hospedados: os 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 confidenciais: use pools de agentes diferentes para evitar problemas de segurança.
  • Usar um pool de agentes separado para artefatos de produção: isole os artefatos de produção usando um pool de agentes distinto, evitando implantações acidentais de ramificações que não sejam de produção.
  • Agrupar pools sensíveis ao segmento: crie pools separados para cargas de trabalho confidenciais e não confidenciais. 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 quaisquer segredos ou chaves que apareçam nos pipelines. Migre para métodos de autenticação sem segredos, como a federação de identidade de carga de trabalho, ou defina 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 validação de parâmetros de argumentos de tarefas de shell no nível da organização ou do projeto em Configurações>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.
• Usar parâmetros em vez de variáveis: ao contrário das variáveis, um pipeline em execução não pode modificar os parâmetros do 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 de modelos: em vez de incluir scripts embutidos com parâmetros secretos diretamente no YAML do seu pipeline, use modelos para abstrair informações confidenciais 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 obter mais informações, consulte Usar modelos.
• Limitar 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 tarefas e políticas de ramificação para garantir que os segredos estejam vinculados à ramificação main. Para obter mais informações, consulte Proteger segredos.
• Usar setvariable para limitar a configuração de variáveis: use o atributo settableVariables para configurar quais variáveis os autores de pipeline podem definir em um pipeline. Sem essa configuração, os autores de pipeline podem declarar um número ilimitado de novas variáveis com o comando de registro 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. Da mesma forma, evite armazenar ou usar tokens de acesso pessoal (PATs) para autenticação do Azure DevOps para o Azure DevOps quando a conexão de serviço do Azure DevOps estiver disponível, pois ela substitui tokens de longa duração por identidades de carga de trabalho do Microsoft Entra. 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 tratamento de segredos em tarefas e logs, revise e remova segredos desnecessários e rotacione segredos para minimizar os riscos de segurança.

• Auditar o tratamento de segredos em tarefas e logs: verifica as tarefas para garantir que os segredos não sejam enviados aos hosts nem impressos nos 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 usar PATH em scripts: confiar na configuração PATH do agente é perigoso, pois ela pode ser alterada por um script ou ferramenta anterior. Sempre use um caminho completo.
• 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: os contêineres incluem montagens de volume fornecidas pelo sistema para tarefas, ferramentas e componentes externos necessários para trabalhar com o agente do 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 que não são da Microsoft 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.

• Usar modelos estendidos: os modelos estendidos 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.

Artigos relacionados

• Ciclo de vida de desenvolvimento de segurança da Microsoft
• Central de Confiabilidade do Azure