Repositórios seguros e pedidos de extração

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

Proteja os Repositórios do Azure combinando controlo de acesso, políticas de pull request e verificações de estado nos seus ramos mais importantes. Este artigo mostra-lhe como restringir alterações diretas, exigir os revisores certos, impor requisitos de itens de trabalho e compilação, e adicionar verificações avançadas de segurança no GitHub antes da fusão dos pull requests.

Tip

Pode usar IA para ajudar nesta tarefa mais adiante neste artigo, ou consultar Habilitar assistência de IA com Azure DevOps MCP Server para começar.

Ameaças e controlos

Use os seguintes controlos em conjunto para reduzir os riscos mais comuns de pull request.

Ameaça Risco Controlo recomendado
Empurrões diretos para ramos protegidos Alterações bypassam a revisão e validação Permissões de ramo e políticas de ramo
Aprovação por uma só pessoa A qualidade das críticas depende de uma pessoa Exigir um número mínimo de revisores
Falta de revisão por especialistas de ficheiros sensíveis Alterações críticas de segurança são integradas sem os revisores adequados Revisores incluídos automaticamente
Alterações de código não rastreadas Reduzida auditabilidade e rastreabilidade de alterações Verificar itens de trabalho vinculados
Código quebrado ou não testado As regressões atingem ramos partilhados Validação de build
Feedback de avaliação não resolvido Problemas conhecidos são agrupados sem resposta Verificar a resolução de comentários
Novas vulnerabilidades elevadas ou críticas Regressões de segurança são fundidas através de pull requests Verificações avançadas de estado de segurança no GitHub

Prerequisites

Category Requirements
Acesso ao Projeto Membro de um projeto.
Permissions - Ver código em projetos privados: Pelo menos acesso básico .
- Clone ou contribua para o código em projetos privados: Membro do grupo de segurança Contributors ou permissões correspondentes no projeto.
- Definir permissões de branch ou repositório: Gerir permissões para o branch ou repositório.
- Definir políticas de ramo, verificações de estado ou alterar o ramo predefinido: Editar políticas de permissão para o repositório ou ramo, ou pertença ao grupo de segurança Project Administrators.
- Importar um repositório: Membro do grupo de segurança Administradores de Projeto ou com permissão de Criar repositório ao nível do projeto Git definida como Permitir. Para obter mais informações, consulte Definir permissões do repositório Git.
Services Repos ativado.
Tools Optional. Use az repos comandos: Azure DevOps CLI.
Category Requirements
Acesso ao Projeto Membro de um projeto.
Permissions - Visualização de código: Pelo menos acesso básico.
- Clonar ou contribuir para o código: Membro do grupo de segurança Contribuidores ou com permissões correspondentes no projeto.
Services Repos ativado.

Antes de configurar qualquer política de ramo:

  • Certifica-te de que o repositório alvo e o ramo já existem.
  • Decida quais os grupos que podem gerir permissões, contornar políticas e aprovar pull requests.
  • Se planeias precisar de validação de build ou verificações de estado do GitHub Advanced Security, cria primeiro o pipeline de build.

Base de segurança para a maioria das equipas

Para um ramo de produção típico como main, comece com esta linha base:

Área de controlo Linha de base recomendada Porquê
Acesso ao repositório Limitar a permissão de escrita aos colaboradores que trabalham ativamente no repositório Reduz o número de identidades que podem alterar o código-fonte ou as definições do repositório.
Permissões de ramificação Restringa políticas de Bypass ao concluir pull requests e políticas de Bypass ao enviar para um pequeno grupo de administradores Impede que os utilizadores ignorem as revisões obrigatórias, as validações e outras proteções das ramificações.
Política de revisão Exigir pelo menos dois revisores para main Melhora a qualidade da avaliação e reduz o risco de uma aprovação errada ou tendenciosa.
Ficheiros sensíveis Incluir automaticamente revisores para percursos sensíveis à segurança, infraestrutura ou conformidade Garante que as alterações em áreas de alto risco sejam avaliadas pelas pessoas ou equipas certas.
Rastreabilidade Ativar Verificar itens de trabalho ligados Preserva um registo de auditoria entre as alterações ao código e o trabalho que as justificou.
Validation Adicionar validação de build para o ramo PR Detém falhas de compilação e teste antes de o código se fundir numa ramificação protegida.
Conclusão da revisão Ativar verificação da resolução dos comentários Ajuda a garantir que as preocupações dos revisores são resolvidas antes da conclusão.
Portas de vulnerabilidade Adicionar AdvancedSecurity/NewHighAndCritical depois de configurar a análise do Advanced Security Bloqueia pull requests que introduzem novas descobertas de segurança elevadas ou críticas.

Passo 1: Restringir o acesso a repositórios e branches

Começa pelas permissões. As políticas são mais eficazes quando apenas um pequeno conjunto de utilizadores pode contorná-las.

Rever permissões de repositório

Use permissões de repositório para controlar quem pode ler, contribuir, administrar definições ou contribuir para pull requests. Para a referência detalhada de permissões, veja Definir permissões do repositório Git.

Use o seguinte padrão:

  • Conceda aos Colaboradores as permissões de que precisam para trabalhar em ramos de funcionalidades.
  • Reserve a administração do repositório para um pequeno grupo administrativo.
  • Evite concessões amplas de permissões para contornar políticas.

Limitar permissões de ramificação

Para agências protegidas, reveja e limite cuidadosamente estas permissões:

  • Ignorar políticas ao concluir solicitações pull
  • Ignorar políticas ao fazer push
  • Force push (reescrever histórico, excluir ramificações e tags)
  • Editar políticas
  • Gerenciar permissões

Utilize Definir permissões do ramo para configurar estas definições.

Padrão recomendado para main:

Group Permissões recomendadas para ramificações
Contribuidores Permita contribuições regulares através de pull requests, mas não conceda permissões de bypass
Administradores de projetos Permitir políticas de Edição e Gestão de permissões
Responsáveis pelo lançamento de emergência Atribua permissões para contornar restrições apenas se o seu processo de gestão de incidentes as exigir

Importante

Mantém as políticas de Bypass ao concluir pull requests e as políticas de Bypass ao fazer push limitadas a um pequeno conjunto de administradores de confiança. Estas permissões contornam as proteções criadas pelos revisores obrigatórios, pela validação e pelas verificações de estado.

Passo 2: Exigir uma revisão rigorosa dos pull requests

Exigir um número mínimo de revisores

Utilize Exigir um número mínimo de revisores em ramificações importantes, como main e ramificações de lançamento.

Configurações recomendadas:

  • Revisores mínimos: 2 para ramificações partilhadas de elevado valor
  • Exigir pelo menos uma aprovação na última iteração
  • Permitir que os solicitantes aprovem as suas próprias alterações: Off
  • Proibir o empurrador mais recente de aprovar as suas próprias mudanças: On quando quiser uma separação de funções mais forte

Configurar a política de número mínimo de revisores

  1. Vá a Definições do Projeto>Repositórios.
  2. Selecione o seu repositório e depois selecione o ramo protegido.
  3. Em Políticas, ative Exigir um número mínimo de revisores.
  4. Defina as opções de revisão para a filial.

Verifique o resultado:

  • A lista de políticas de ramificações mostra a política de revisão como ativada.
  • Os pull requests destinados à ramificação não podem ser concluídos enquanto não existir o número obrigatório de aprovações.

Para detalhes das políticas, consulte políticas e definições da Filial.

Incluir automaticamente revisores para ficheiros sensíveis

Use revisores automaticamente incluídos quando certos ficheiros ou pastas requerem aprovação de uma pessoa ou equipa específica.

Os bons candidatos incluem:

  • Código de implementação e infraestrutura
  • Código de autenticação e autorização
  • Pastas relevantes para a conformidade
  • Modelos de pipeline partilhados

Configure a política de revisores automaticamente incluída

  1. Vá a Definições do projeto>Repositórios.
  2. Abra o ramo alvo sob as políticas do Ramo.
  3. Adicione uma política de revisores incluída automaticamente .
  4. Adicione as pessoas ou grupos necessários.
  5. Escolha se a apólice é Obrigatória ou Opcional.
  6. Adicione filtros de caminho para os ficheiros ou pastas que necessitem de revisão.
  7. Permitir que os solicitantes aprovem as suas próprias alterações.

Verifique o resultado:

  • Um pull request que altera ficheiros correspondentes adiciona automaticamente os revisores configurados.
  • O pull request não pode ser concluído até que a política de revisores exigida seja cumprida.

Para mais informações, consulte Incluir automaticamente revisores de código.

Passo 3: Fazer cumprir a rastreabilidade e validação

Verificar itens de trabalho vinculados

Ative Verificar itens de trabalho ligados quando a sua equipa precisar de alterações na rastreabilidade entre pull requests e acompanhamento de trabalho.

Configurar a política de itens de trabalho associados

  1. Vá a Definições do projeto>Repositórios.
  2. Abra o ramo alvo sob as políticas do Ramo.
  3. Ative Verificar itens de trabalho ligados.
  4. Selecione Obrigatório se os pull requests tiverem de ter itens de trabalho associados antes de serem concluídos.

Verifique o resultado: Pull requests sem itens de trabalho ligados mostram a política como não satisfeita.

Para mais informações, consulte Verificar itens de trabalho relacionados.

Validação de compilação

Utilize a validação da compilação para exigir que o pipeline seja executado com êxito para pull requests antes da fusão.

Importante

Antes de configurar a validação de compilação, crie o pipeline de compilação que deverá validar o pull request.

Definições recomendadas para ramificações protegidas:

  • Acionamento: Automático
  • Requisito da política: Required
  • Expiração da build: Escolha um valor que corresponda à frequência com que a ramificação protegida muda

Configurar a política de validação da compilação

  1. Abra o ramo alvo sob as políticas do Ramo.
  2. Adicione uma política de validação de builds .
  3. Selecione o pipeline de compilação.
  4. Escolha se a apólice é obrigatória.
  5. Guardar a política.

Verifique o resultado:

  • Abrir ou atualizar um pull request coloca em fila a compilação de validação configurada.
  • O pull request não pode ser concluído até que a build necessária tenha sucesso.

Para mais informações, veja Validação de builds.

Verificar a resolução de comentários

Use Verificar a resolução de comentários para garantir que os tópicos de revisão são resolvidos antes de o pull request ser concluído.

Configurar a política de resolução de comentários

  1. Abra o ramo alvo sob as políticas do Ramo.
  2. Ative Verificação da resolução dos comentários.
  3. Escolha Obrigatório se os comentários não resolvidos bloquearem a conclusão.

Verifique o resultado: Os pull requests com comentários não resolvidos permanecem bloqueados até que os revisores ou autores resolvam os tópicos.

Para mais informações, consulte Verificar a resolução dos comentários.

Limitar tipos de fusão

Utilize Limitar tipos de fusão como uma definição de governação do histórico do repositório. Esta política ajuda a padronizar como os commits de pull request aparecem após a fusão, mas não é um controlo direto de segurança.

Escolha uma estratégia de fusão com base na forma como a sua equipa revisa, rastreia e audita o histórico.

Exemplos de utilização:

  • Exigir fusões de squash para trabalhos de curta duração em funcionalidades.
  • Proibir rebase ou squash nas ramificações em que o seu processo de auditoria espera commits de fusão.

Considerações de auditoria e rastreabilidade:

  • O squash cria um histórico de branch-alvo mais limpo, mas colapsa múltiplos commits de origem num único commit no momento da fusão.
  • Se o seu modelo de auditoria depender da preservação da sequência exata de confirmações de um ramo de funcionalidade, privilegie estratégias de merge commit em vez de squash.
  • Mantenha a sua política em consonância com a forma como os programadores inspecionam e depuram o histórico nos pedidos de pull e no ramo de destino.

Azure DevOps CLI exemplo:

az repos policy merge-strategy create \
  --blocking true \
  --branch main \
  --enabled true \
  --repository-id <repository-id> \
  --allow-no-fast-forward true \
  --allow-rebase false \
  --allow-rebase-merge false \
  --allow-squash false

Para mais informações, veja Limites de tipos de fusão.

Passo 4: Adicionar verificações avançadas de estado de segurança no GitHub

As verificações de estado do GitHub Advanced Security ajudam a evitar a fusão de pull requests quando são introduzidas novas vulnerabilidades críticas ou de alta gravidade.

Importante

O GitHub Advanced Security for Azure DevOps está disponível apenas para Azure DevOps Services e apenas para repositórios Git de código.

Antes de adicionar a política de verificação de estado:

  1. Ative o GitHub Advanced Security no repositório.
  2. Configure as tarefas necessárias do pipeline de Segurança Avançada.
  3. Adicione uma política de validação de compilação para a ramificação da pull request.
  4. Ative Wait for Processing: true para as tarefas documentadas de Segurança Avançada.
  5. Execute o pipeline com êxito pelo menos uma vez para que a verificação de estado apareça na lista Estado a verificar.

Começa por AdvancedSecurity/NewHighAndCritical se o repositório já tiver alertas por resolver. Depois de reduzir o atraso, considere mudar para AdvancedSecurity/AllHighAndCritical.

Caminho do navegador:

  1. Abra o ramo alvo sob as políticas do Ramo.
  2. Em Verificações de Estado, selecione +.
  3. Definir o Estado para verificar em AdvancedSecurity/NewHighAndCritical.
  4. Deixe as Opções Avançadas nos valores predefinidos.
  5. Guardar a política.

As verificações do estado da Segurança Avançada são configuradas em Verificações de estado no navegador depois de ativar a análise da Segurança Avançada e a validação da compilação do repositório. Para a configuração necessária, consulte Configurar verificações de estado de pull requests.

Verifique o resultado:

  • Pull requests com novos resultados altos ou críticos mostram que a verificação de estado falhou.
  • A política de ramo bloqueia a conclusão até que as conclusões sejam resolvidas ou a política se torne opcional.

Para detalhes de configuração, veja:

Exemplos de planos de implementação

Linha de base de repositório de menor sensibilidade

Se o repositório tiver sensibilidade mais baixa e quiser um ponto de partida gerível:

  1. Restrinja as permissões para ignorar ramificações no main.
  2. Exige pelo menos um ou dois revisores.
  3. Ativa os itens de trabalho ligados.
  4. Adicionar validação de compilação.
  5. Ativar a resolução de comentários.

Repositório de alta sensibilidade

Se o repositório contiver ativos críticos de implementação, identidade ou conformidade:

  1. Restringa permissões para contornar políticas aos administradores.
  2. Exigir dois revisores para main.
  3. Adicione revisores adicionados automaticamente para caminhos protegidos.
  4. Exigir itens de trabalho associados.
  5. Adicionar validação de compilações.
  6. Adicione verificações de estado de segurança GitHub Advanced se estiver a usar Azure DevOps Services.

Opcional: Utilizar assistência de IA para rever a configuração da política de agências

A assistência de IA é opcional. As permissões, políticas e verificações de estado do seu ramo aplicam a proteção do repositório, quer utilize IA ou não.

Pode usar estes prompts para rever a configuração da política, identificar lacunas e obter recomendações de base mais rapidamente. Se configurar o Azure DevOps MCP Server, o assistente pode usar o seu contexto Azure DevOps para melhorar as respostas. Para orientações de configuração, consulte Ativar assistência de IA com Azure DevOps MCP Server.

Utilize instruções como as seguintes para começar:

Goal Exemplo de prompt
Rever as proteções das ramificações Summarize the branch policies on main and explain which ones are required.
Identificar o risco de bypass Find users or groups that can bypass branch policies on the main branch.
Verificar a cobertura da revisão List the reviewer and comment-resolution policies configured for this repository.
Verificar o acompanhamento do trabalho Check whether pull requests into main require linked work items.
Inspeção das portas de validação Show the build validation policy for main and explain what pipeline it uses.
Investigar verificações de estado de segurança List the status checks configured for main and tell me whether GitHub Advanced Security is one of them.
Planeie uma base mais segura Recommend a secure branch policy baseline for this repository based on its current settings.

Valide sempre os comandos e recomendações gerados contra as permissões do seu repositório, definições de branch e a documentação atual do Azure DevOps antes de os aplicar.

Sugestões de resolução de problemas

Problema Causa provável Ação recomendada
Não aparece uma opção de política de ramificação Não tens permissão de Editar políticas ou o ramo não foi selecionado Confirmar permissões de acesso a branches e políticas
Os pull requests ainda podem fundir-se sem cumprir a política Um utilizador tem permissões para ignorar Revise as políticas de Bypass ao concluir pull requests e as políticas de Bypass ao fazer push
Os revisores obrigatórios não são adicionados O filtro de caminho da política do revisor não corresponde aos ficheiros alterados Verifique novamente os filtros de caminho e as identidades dos revisores
A verificação do estado de Segurança Avançada não está disponível O repositório não completou uma execução de análise bem-sucedida com as tarefas necessárias Verifique a validação da build, as tarefas do pipeline e as definições de Wait for Processing
Uma política de itens de trabalho vinculados não bloqueia A apólice é opcional em vez de obrigatória Reabrir a política da agência e confirmar o nível de requisitos

Conteúdo relacionado

  • Last updated on