Pular para o conteúdo principal

🔍 Rastreabilidade e Auditoria de Commits no Azure DevOps

· 5 min para ler
Alfredo Fernandez
Alfredo Fernandez
Arquiteto de solução

Em ambientes colaborativos, especialmente em pipelines corporativos e DevOps, a autenticidade dos commits é essencial.
Mas o que acontece se alguém faz um commit “falso” — ou seja, usa um nome/email de outro usuário no Git — e faz o push para um repositório do Azure DevOps?

Este artigo explica como rastrear a autoria real usando audit logging, o que o Azure registra por padrão e quais são as limitações.

🧩 1. O problema: commits com autor falsificado​

O Git permite que qualquer pessoa defina livremente o autor de um commit:

git commit --author="Fulano <fulano@example.com>"

Isso altera apenas o metadado local do commit, sem autenticação real.

Portanto, o author ou committer no log do Git não garante identidade.
A identidade real está no método de autenticação usado para o push — SSH, HTTPS (token/senha) ou serviço automatizado.

🔐 2. Como o Azure DevOps autentica um push​

O Azure DevOps aceita dois principais modos de autenticação Git:

MétodoAutenticaçãoOnde rastrearComentário
SSHChave pública associada a uma conta do DevOpsAudit Log (eventos SSH)Forte, identifica a conta associada
HTTPSUsuário + Senha / Token (PAT)Audit Log (requisições REST/Push) + Logs internosRegistra usuário autenticado, IP e timestamp

👉 Mesmo que o commit tenha Author: outro@email.com, o push é autenticado e rastreável pela conta real que o enviou.

🧾 3. O que é o Audit Logging do Azure DevOps​

O Audit Logging é o sistema de trilhas de auditoria da plataforma Azure DevOps, que registra ações administrativas e operacionais — inclusive algumas relacionadas a Git.

📍 Onde ativar​

  • Vá em Organization Settings → Auditing.
  • Verifique se a auditoria está ativada.
    Em novas organizações, o recurso pode vir desativado por padrão e precisa ser habilitado manualmente.

⚙️ Requisitos​

  • A organização precisa estar associada ao Microsoft Entra ID (antigo Azure AD).
  • Se não estiver, o recurso pode não aparecer no painel.

📊 4. Quais eventos Git são registrados​

Nem todos os eventos Git aparecem na auditoria.
Abaixo, uma visão geral dos principais tipos (conforme documentação e testes práticos):

EventoRegistrado na Auditoria?Detalhes
git push✅ SimMostra usuário autenticado, repositório, IP e horário.
git clone / fetch⚠️ ParcialNem sempre registrado; depende da versão e plano.
git commit (local)❌ NãoO commit é local, só o push é auditável.
Criação de branch / tag✅ SimEvento de criação e exclusão são auditáveis.
Alteração de chave SSH / Token PAT✅ SimEventos de segurança são registrados.
Criação/Exclusão de repositório✅ SimEventos administrativos completos.

🧠 Dica: use o Audit Stream para enviar logs em tempo real ao Azure Monitor, Event Hub ou SIEM (Splunk, Sentinel).

🕵️‍♂️ 5. Investigando um commit suspeito​

Suponha que um commit foi feito com o autor “fulano@example.com”, mas suspeita-se que outro usuário o enviou.

Passos para rastrear:​

  1. Identifique o hash e a data do commit:

    git log --pretty=fuller

  2. No Azure DevOps, vá em:

    Organization Settings → Auditing

  3. Filtre por ação: GitPush ou Repository Push

  4. Verifique:

    • Usuário autenticado (actorDisplayName)
    • Endereço IP (ipAddress)
    • Repositório e branch
    • Data e hora

  5. Compare o timestamp do push com o commit.

Se o commit foi feito localmente por alguém e empurrado via conta alugafacil-org@..., o log mostrará essa conta como a origem real.

⚠️ 6. Limitações e lacunas conhecidas​

  • Commits locais não são registrados — apenas o push final.
  • Clones e fetchs podem não gerar eventos auditáveis.
  • Tokens pessoais (PATs) podem ser reutilizados ou vazados, dificultando a atribuição física.
  • Logs são retidos por 90 dias (por padrão), a menos que você configure Audit Streaming.
  • Organizações não conectadas ao Entra ID podem não ter auditoria disponível.

🧰 7. Boas práticas de rastreabilidade​

MedidaBenefício
Habilitar auditoria e streamingRetém logs por longo prazo e integra com SIEM
Exigir autenticação 2FA/SSOEvita uso indevido de senhas ou tokens
Forçar commits assinados (GPG)Garante autoria criptográfica
Revisar chaves SSH e PATs regularmenteMinimiza risco de uso indevido
Ativar notificações de segurançaDetecta pushes inesperados rapidamente

🧮 8. Exemplo de evidência técnica​

CampoExemplo
Commit Hashe41b9a67c6f1e3...
Author declaradoFulano <fulano@example.com>
Usuário autenticadoalugafacil-org@gmail.com
IP203.0.113.55
MétodoHTTPS (PAT)
Timestamp2025-10-22T14:33:21Z
Fingerprint SSH(se aplicável) SHA256:W8t2xNKl4K7...

🧭 9. Conclusão​

Mesmo que alguém tente falsificar o autor de um commit, o push ao Azure DevOps deixa rastros auditáveis, desde que:

  1. A auditoria esteja habilitada;
  2. O push tenha sido autenticado via SSH, HTTPS ou token válido;
  3. Os logs não tenham expirado (configure retenção).

A combinação de audit logging + GPG signing + políticas de autenticação forte cria um ambiente auditável e juridicamente defensável.

🔒 Referências​