Proteja seus Pipelines do Azure

2025-04-17

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

Os pipelines oferecem recursos poderosos 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 malicioso. 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 relacionadas à segurança necessárias para proteger seus pipelines contra ameaças e vulnerabilidades.

Pré-requisitos

Categoria	Requerimentos
Azure DevOps	- Implemente recomendações em Tornar seu Azure DevOps seguro. - Conhecimentos básicos de YAML e Azure Pipelines. Para obter mais informações, consulte Criar seu primeiro pipeline.
Permissões	- Para modificar permissões de pipelines: Membro do grupo administradores de projetos. - Para modificar as permissões da organização: Membro do grupo Administradores da Coleção de Projetos.

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

Para aumentar a segurança, considere separar seus projetos, usar políticas de filial 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: gerencie cada produto e equipe em projetos separados. Isso evita que pipelines de um produto acessem inadvertidamente recursos abertos de outro produto, minimizando a exposição lateral.
Usar identidades ao nível do projeto: use uma identidade de compilação baseada no projeto para pipelines em vez de uma identidade ao nível da coleção. As identidades no nível do projeto só podem acessar recursos dentro de 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 ramificação: para garantir alterações seguras no código e no pipeline, aplique permissões e políticas de ramificação. Além disso, considere adicionar permissões e verificações de pipeline aos repositórios.
Adicione segurança adicional para forks: quando você trabalha com repositórios públicos do GitHub, considere cuidadosamente sua abordagem para fork builds. As bifurcações originárias de fora da sua organização representam riscos específicos.
- Não forneça segredos para compilações de forks: Por padrão, os pipelines são configurados para criar forks, mas os segredos e os recursos protegidos não são expostos automaticamente aos jobs nesses pipelines. É essencial não desativar essa proteção para manter a segurança.
- Considere acionar manualmente as compilações de fork: desative as compilações de fork automáticas e use comentários de pull request para criar manualmente essas contribuições. Essa configuração lhe dá a oportunidade de revisar o código antes de acionar uma compilação. Para obter mais informações, consulte Desativar compilações automáticas de ramificação.
- Não forneça segredos para construções de forks: por padrão, os segredos associados ao seu pipeline não são disponibilizados para validar solicitações pull de forks. Não habilite a opção Disponibilizar segredos para compilações de forks. Para obter instruções sobre como localizar e verificar esta configuração, consulte Contribuições de ramificações.
- Considere acionar manualmente as compilações de fork: desative as compilações de fork automáticas e use comentários de pull request para criar manualmente essas contribuições. Essa configuração lhe dá a oportunidade de revisar o código antes de acionar uma compilação. Para obter instruções sobre como fazer isso, consulte Desativar compilações automáticas de fork.
- Use agentes hospedados pela Microsoft para compilações de forks: evite executar compilações de forks 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.
- Use o aplicativo GitHub do Azure Pipelines para limitação de escopo de token: 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.

Conexões de serviço seguras

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, 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. Para obter instruções sobre como configurar conexões de serviço, consulte Usar uma conexão de serviço do Azure Resource Manager.
Usar federação de identidade de carga de trabalho para autenticação: sempre que possível, use federação de identidade de carga de trabalho em vez de um principal de serviço para a 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. Para obter instruções sobre como fazer isso, consulte Criar uma conexão de serviço com federação de identidade de carga de trabalho (automática).
Minimizar o acesso ao aplicativo GitHub: ao configurar o aplicativo GitHub para o Azure DevOps, conceda acesso apenas aos repositórios que você pretende criar usando pipelines.

Utilize pipelines de YAML em vez de pipelines clássicos

Para maior segurança e para reduzir o risco de configurações incorretas acidentais, use pipelines YAML em vez de pipelines clássicos. Esta precaução evita uma preocupação de segurança que surge do YAML e dos pipelines clássicos que compartilham os mesmos recursos, como conexões de serviço. Se a sua organização estiver a usar pipelines clássicos, migre as pipelines para YAML.

O YAML oferece os benefícios da infraestrutura como código: Trate os pipelines YAML como qualquer outro código porque as etapas e dependências são definidas no código. Há também uma visibilidade clara das configurações do pipeline e um risco reduzido de configurações incorretas acidentais.
Os pipelines YAML podem ser combinados com medidas de segurança aprimoradas: por meio de revisões de código e solicitações pull, use políticas de ramificação para configurar um processo de revisão para solicitações 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 evita 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 para pipelines. Uma verificação de ramificação protegida para um recurso impede que os pipelines sejam executados automaticamente em ramificações não autorizadas.
- Verificação de aprovação manual: use uma verificação de aprovação manual para impedir que solicitações de pipeline usem um recurso protegido até que sejam aprovadas manualmente por usuários ou grupos especificados.
- Verificação de horário comercial: use esta verificação para garantir que a implantação de um pipeline comece dentro de uma janela de dia e hora especificada.
Desativar a criação de pipelines clássicos: desative de forma independente a criação de pipelines de compilação clássicos e pipelines de liberação clássicos. Quando ambos estão desabilitados, nenhum pipeline de compilação clássico, pipeline de liberaçã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 os volumes como somente leitura, defina limites de recursos, use imagens confiáveis, verifique vulnerabilidades e aplique políticas de segurança.

Use 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 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.
Use contas com privilégios baixos para executar agentes: para melhorar a segurança do sistema, use a conta com privilégios mais baixos para executar agentes autohospedados. Por exemplo, considere usar sua conta de máquina ou uma identidade de serviço gerenciado. Não execute um agente sob uma identidade com acesso direto aos recursos do Azure DevOps.
Isolar artefactos de produção e pools de agentes confidenciais: Utilize pools de agentes distintos 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, evitando implantações acidentais de ramificações que não sejam de produção.
- Segmente os 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 segurança e 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.

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

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

Restringir o acesso a segredos: Remova quaisquer segredos ou chaves para que não apareçam em pipelines. Mude para métodos de autenticação sem segredo, como federação de identidade de carga de trabalho ou defina segredos na interface do usuário, em um grupo de variáveis ou em um grupo de variáveis originado do Cofre de Chaves do Azure.
Habilitar validação de parâmetros do shell: quando a configuração Habilitar validação de parâmetros de argumentos de tarefas do shell estiver habilitada, haverá uma verificação adicional de caracteres como ponto-e-vírgula, aspas e parênteses. Ative Habilitar validação de parâmetros de argumentos de tarefas do shell ao nível da organização ou do projeto em Configurações>Pipelines>Configurações.
Limitar variáveis que podem ser definidas no momento da fila: impeça que os utilizadores definam novas variáveis no momento da fila, habilitando a configuração limitar variáveis que podem ser definidas no momento da fila em Configurações da organização>Pipelines>Configurações.
Use parâmetros em vez de variáveis: diferente das variáveis, um pipeline em execução não pode modificar os seus próprios parâmetros. Os parâmetros têm tipos de dados como number e string, e podem ser restritos a subconjuntos de valores específicos. Essa restrição é valiosa quando um aspeto 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 embutidos com parâmetros secretos diretamente no seu pipeline YAML, use modelos para abstrair informações confidenciais fora do pipeline principal. Para implementar essa abordagem, crie um arquivo YAML separado para seu script e, em seguida, armazene esse script em um repositório separado e seguro. Você pode então referenciar o 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 branches e permissões de grupo variável: Pode-se usar uma combinação de permissões de grupo variável, inserção de tarefas condicionais e políticas de branches para garantir que os segredos estejam vinculados ao main branch. Para obter mais informações, consulte Proteger segredos.
Use setvariable para limitar a definição de variáveis: Use o atributo settableVariables para configurar quais variáveis os autores do pipeline têm permissão para definir num pipeline. Sem essa configuração, os autores do pipeline podem declarar novas variáveis ilimitadas com o setvariable comando log. 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 certifique-se de que eles não sejam registrados ou impressos para manter a segurança.

Evite usar segredos quando possível: verifique se seu 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 exigir credenciais explícitas. Para obter mais informações, consulte Usar entidades de serviço ou 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 para o console, usá-los em parâmetros de linha de comando ou registrá-los em arquivos. O Azure Pipelines tenta limpar segredos de logs sempre que possível, mas não consegue detetar 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 uma 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 alterne segredos para minimizar os riscos de segurança.

Auditoria do tratamento de segredos em tarefas e logs: verifica as tarefas para garantir que os segredos não sejam enviados para anfitriões nem impressos em logs. Verifique se não há segredos em nenhum arquivo de log, incluindo os logs de erro.
Revise os segredos registrados: confirme se os segredos em seu pipeline ainda são necessários e remova os que não são mais necessários para reduzir a desordem e os riscos potenciais à segurança.
Rodar segredos: Rode os segredos regularmente para minimizar o período de tempo durante o qual um segredo comprometido pode ser explorado.

Impeça a execução de códigos maliciosos

Para garantir que apenas o código testado e higienizado seja executado em seu pipeline, revise 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 comandos shell. Você pode usar o GitHub Advanced Security for Azure DevOps para automatizar a verificação de código.
Validar entradas e usar parâmetros: valide parâmetros e argumentos de entrada para evitar comportamentos não intencionais. Use consultas parametrizadas em scripts para evitar a injeção de SQL. Os parâmetros de tempo de execução ajudam a evitar problemas de segurança relacionados a variáveis, como injeção de argumentos.
Não use PATH em scripts: depender da configuração do PATH do agente é perigoso, pois pode ser modificada por um script ou ferramenta executado previamente. Em vez disso, use sempre um caminho totalmente qualificado.
Controle as tarefas disponíveis: desative a capacidade de instalar e executar tarefas do Marketplace, o que lhe dá maior controle sobre o código que é executado em um pipeline.

Contentores seguros

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

Marcar volumes como somente leitura: os contentores incluem montagens de volume fornecidas pelo sistema para tarefas, ferramentas e componentes externos necessários para trabalhar com o agente do host. Defina externals, taskse tools para ler somente para maior segurança.
Definir limites de recursos específicos do contêiner: defina limites de CPU e memória para evitar que os 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 confiáveis, como o Registro de Contêiner do Azure ou o Docker Hub. Sempre especifique uma versão ou tag específica para manter a consistência e a confiabilidade, em vez de depender da tag latest. Atualize regularmente as imagens de base para incluir os patches de segurança e correções de bugs mais recentes.
Analise contêineres em busca de vulnerabilidades e imponha proteção contra ameaças em tempo de execução: use ferramentas como o Microsoft Defender for Cloud para monitorar e detetar riscos de segurança. Além disso, o Registro de Contêineres do Azure oferece verificação de vulnerabilidade integrada para ajudar a garantir que as imagens de contêineres estejam seguras antes de serem implantadas. Você também pode integrar ferramentas de verificação de terceiros por meio das extensões do Azure DevOps para verificações de segurança adicionais.
Implemente políticas de segurança para evitar o escalonamento de privilégios e garantir que os contêineres sejam executados com a menor quantidade de privilégios necessários: por exemplo, o Serviço Kubernetes do Azure (AKS),o controle de acesso baseado em função e a Admissão de Segurança de Pod permitem aplicar políticas que restringem os privilégios de contêiner, garantem a execução não raiz e limitam o acesso a recursos críticos.
Utilize políticas de rede: as diretivas de rede podem ser usadas para restringir a comunicação entre contêineres, garantindo que apenas contêineres autorizados possam acessar recursos confidenciais em sua rede. Além disso, a Política do Azure para AKS pode ser aplicada 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 aplicar as práticas recomendadas

Comece com um modelo mínimo e, gradualmente, aplique extensões. Essa abordagem garante que, ao implementar práticas de segurança, você tenha um ponto de partida centralizado que abranja 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 estendidos pode impedir que códigos maliciosos se infiltrem em um pipeline.
Restrinja o acesso com etapas: limite o acesso à rede fazendo com que etapas como o download de pacotes sejam executadas em um contêiner em vez de no host. Quando as etapas são executadas em um contêiner, você impede que um agente mal-intencionado modifique a configuração do agente ou deixe código mal-intencionado para execução posterior.