Proteger repositórios e solicitações de pull

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

Proteja o Azure Repos combinando controle de acesso, políticas de pull request e verificações de status nos seus branches mais importantes. Este artigo mostra como restringir as alterações diretas, exigir os revisores corretos, impor requisitos de build e item de trabalho e adicionar GitHub verificações de Segurança Avançada antes da mesclagem de solicitações de pull.

Ameaças e controles

Use os controles a seguir juntos para reduzir os riscos mais comuns de solicitação de pull.

Prerequisites

Antes de configurar qualquer política de ramificação:

• Verifique se o repositório de destino e o branch já existem.
• Decida quais grupos podem gerenciar permissões, ignorar políticas e aprovar solicitações de pull.
• Se você planeja exigir a validação de build ou verificações de status do GitHub Advanced Security, crie primeiro o pipeline de build.

Linha de base de segurança para a maioria das equipes

Para um ramo de produção típico, como main, comece com esta configuração básica:

Etapa 1: Restringir o acesso ao repositório e ao branch

Comece com permissões. As políticas são mais eficazes quando apenas um pequeno grupo de usuários pode contorná-las.

Examinar permissões de repositório

Use permissões de repositório para controlar quem pode ler, contribuir, administrar configurações ou contribuir para solicitações de pull. Para obter a referência de permissão detalhada, consulte Definir permissões de repositório Git.

Use o seguinte padrão:

• Conceda aos Colaboradores as permissões necessárias para trabalhar em branches de recursos.
• Reserve a administração do repositório para um pequeno grupo de administradores.
• Evite conceder permissões amplas para ignorar políticas.

Limitar permissões de ramificação

Para branches protegidas, revise e limite essas permissões cuidadosamente:

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

Use Definir permissões da branch para configurar essas configurações.

Padrão recomendado para main:

Etapa 2: Exigir revisão rigorosa de pull requests

Exigir um número mínimo de revisores

Use 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 branches compartilhados de alto valor
• Exigir pelo menos uma aprovação na última iteração
• Permitir que os solicitantes aprovem suas próprias alterações: Off
• Proibir o pusher mais recente de aprovar suas próprias alterações: On quando você quer uma separação mais forte de tarefas

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

az repos policy approver-count create \
  --blocking true \
  --branch main \
  --enabled true \
  --minimum-approver-count 2 \
  --creator-vote-counts false \
  --reset-on-source-push true \
  --repository-id <repository-id>

Verifique o resultado:

• A lista de políticas da ramificação mostra a política de revisores como habilitada.
• As solicitações de pull para o branch não podem ser concluídas até que o número necessário de aprovações esteja presente.

Para obter detalhes da política, consulte políticas e configurações do Branch.

Incluir automaticamente revisores para arquivos confidenciais

Use revisores incluídos automaticamente quando determinados arquivos ou pastas exigirem aprovação de uma pessoa ou equipe específica.

Bons candidatos incluem:

• implantação e código de infraestrutura
• código de autenticação e autorização
• pastas relacionadas à conformidade
• modelos de pipeline compartilhados

Configurar a política de revisores incluída automaticamente

az repos policy required-reviewer create \
  --blocking true \
  --branch main \
  --enabled true \
  --message "Security review required for protected paths." \
  --path-filter "/.azure/*;/infra/*;/pipelines/*" \
  --repository-id <repository-id> \
  --required-reviewer-ids <reviewer-email-or-emails>

Verifique o resultado:

• Uma solicitação de pull que altera arquivos correspondentes adiciona automaticamente os revisores configurados.
• O pull request não pode ser concluído até que a política obrigatória de revisores seja atendida.

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

Etapa 3: Impor a rastreabilidade e a validação

Verificar se há itens de trabalho vinculados

Ative a Verificação de itens de trabalho vinculados quando sua equipe precisar alterar a rastreabilidade entre solicitações de pull e acompanhamento de trabalho.

Configurar a política de itens de trabalho vinculados

az repos policy work-item-linking create \
  --blocking true \
  --branch main \
  --enabled true \
  --repository-id <repository-id>

Verifique o resultado: solicitações de pull sem itens de trabalho vinculados mostram a política como não satisfeita.

Para obter mais informações, consulte Verificar se há itens de trabalho vinculados.

Validação de build

Use a validação de compilação para exigir a execução bem-sucedida de um pipeline para pull requests antes da mesclagem.

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

• Gatilho: Automático
• Requisito de política: Required
• Expiração do build: escolha um valor que corresponda à frequência com que o branch protegido é alterado

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

az repos policy build create \
  --blocking true \
  --branch main \
  --build-definition-id <pipeline-id> \
  --display-name "PR validation" \
  --enabled true \
  --manual-queue-only false \
  --queue-on-source-update-only true \
  --repository-id <repository-id> \
  --valid-duration 0

Verifique o resultado:

• Abrir ou atualizar uma solicitação de pull enfileira o build de validação configurado.
• A solicitação de pull não pode ser concluída até que o build necessário seja bem-sucedido.

Para obter mais informações, consulte a validação de build.

Verificar a resolução de comentários

Use Verificar resolução de comentários para garantir que as discussões de revisão sejam resolvidas antes que a solicitação de pull seja concluída.

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

az repos policy comment-required create \
  --blocking true \
  --branch main \
  --enabled true \
  --repository-id <repository-id>

Verifique o resultado: solicitações de pull com comentários não resolvidos permanecem bloqueadas até que revisores ou autores resolvam os threads.

Para obter mais informações, consulte Verificar se há resolução de comentários.

Limitar tipos de mesclagem

Use tipos de mesclagem limite como uma configuração de governança de histórico do repositório. Essa política ajuda a padronizar como as confirmações de solicitação de pull aparecem após a mesclagem, mas não é um controle de segurança direto.

Escolha uma estratégia de mesclagem com base em como sua equipe analisa, rastreia e audita o histórico.

Exemplos de uso:

• Exigir mesclagens por squash para funcionalidades de curta duração.
• Não permitir a rebase ou o squash em branches em que seu processo de auditoria espera confirmações de mesclagem.

Considerações sobre auditoria e rastreabilidade:

• Squash cria um histórico mais limpo do branch de destino, mas colapsa vários commits de origem em um único commit no momento do merge.
• Se o seu modelo de auditoria depende de preservar a sequência exata de commits de um branch de funcionalidade, prefira estratégias de merge commit em vez de squash.
• Mantenha sua política consistente com a forma como os desenvolvedores inspecionam e depuram o histórico em pull requests e na ramificação de destino.

Exemplo da CLI do Azure DevOps:

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 obter mais informações, consulte Limitar tipos de mesclagem.

Etapa 4: Adicionar verificações de status de Segurança Avançada GitHub

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

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

1. Habilite o GitHub Advanced Security no repositório.
2. Configure as tarefas de pipeline de Segurança Avançada necessárias.
3. Adicione uma política de validação de build para o branch do pull request.
4. Ative Wait for Processing: true para as tarefas documentadas de Segurança Avançada.
5. Execute o pipeline com sucesso pelo menos uma vez para que a verificação de status apareça na lista Status to check.

Comece com AdvancedSecurity/NewHighAndCritical se o repositório já tiver alertas não resolvidos. Depois de reduzir o backlog, considere migrar para AdvancedSecurity/AllHighAndCritical.

Caminho do navegador:

1. Abra o branch de destino nas políticas do Branch.
2. Em Verificações de status, selecione +.
3. Defina Status de verificação como AdvancedSecurity/NewHighAndCritical.
4. Deixe as Opções Avançadas em seus valores padrão.
5. Salve a política.

As verificações de status da Segurança Avançada são configuradas em Verificações de status no navegador depois que você habilita a verificação da Segurança Avançada e a validação da build para o repositório. Para a configuração necessária, consulte Configurar verificações de status da solicitação de pull.

Verifique o resultado:

• Solicitações pull com novas descobertas altas ou críticas mostram a verificação de status como falha.
• A política de ramificação impede a conclusão até que os problemas encontrados sejam resolvidos ou que a política se torne opcional.

Para obter detalhes da instalação, consulte:

• Configurar verificações de status da solicitação de pull
• Verificações de status de solicitação de pull disponíveis

Exemplos de planos de implantação

Linha de base do repositório de menor sensibilidade

Se o repositório tiver menor sensibilidade e você quiser um ponto de partida gerenciável:

1. Restringir permissões de bypass de ramificação em main.
2. Exigir pelo menos um ou dois revisores.
3. Ative itens de trabalho vinculados.
4. Adicionar validação de compilação.
5. Ative a resolução de comentários.

Repositório de alta confidencialidade

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

1. Restrinja as permissões para contornar políticas somente aos administradores.
2. Exigir dois revisores em main.
3. Adicione revisores incluídos automaticamente para caminhos protegidos.
4. Exigir itens de trabalho vinculados.
5. Adicionar validação de compilação.
6. Adicione GitHub verificações de status de Segurança Avançada se você estiver usando Azure DevOps Services.

Opcional: use a assistência da IA para revisar a configuração da política de branch

A assistência à IA é opcional. As permissões, as políticas e as verificações de status do branch impõem proteções de repositório se você usa ou não IA.

Você pode usar esses prompts para examinar a configuração de política, identificar lacunas e obter recomendações de linha de base mais rapidamente. Se você configurar o Azure DevOps MCP Server, o assistente poderá usar seu contexto do Azure DevOps para aprimorar as respostas. Para obter orientações de configuração, consulte Habilitar a assistência por IA com o Azure DevOps MCP Server.

Use comandos como os seguintes para começar:

Sempre valide comandos e recomendações gerados em relação às permissões do repositório, às configurações de branch e à documentação Azure DevOps atual antes de aplicá-las.

Dicas de solução de problemas

Conteúdo relacionado

• Definir permissões do repositório Git
• Definir permissões da ramificação
• Políticas e configurações de branch
• Verificações de status de solicitação de pull disponíveis
• Configurar GitHub Segurança Avançada
• Sobre solicitações de pull