O GitHub colocou em pré-visualização pública o Proof of Presence, traduzido aqui como prova de presença: um controle do Enterprise Cloud que permite aos administradores exigir nova autenticação ou desafio de MFA antes de ações de alto impacto, como criar tokens de acesso, editar webhooks, alterar configurações de segurança da organização e visualizar códigos de recuperação. O recurso ataca um vetor que sustentou ataques recentes à cadeia de suprimentos de software: a sessão válida usada por alguém que não é o dono da conta. A ação prioritária para equipes que administram empresas no GitHub Enterprise Cloud com SSO pelo Microsoft Entra ID é revisar as políticas do provedor de identidade e planejar a ativação no modo MFA, que oferece a barreira mais alta contra credenciais comprometidas.
O que mudou na plataforma
A novidade expande o sudo mode, mecanismo que já pedia confirmação de identidade antes de operações sensíveis. Com a prova de presença ativada, o GitHub deixa de aceitar a simples posse de uma sessão autenticada e redireciona o usuário ao provedor de identidade da empresa no momento exato da ação crítica. A operação só prossegue se a pessoa voltar do provedor com a comprovação de que satisfez a política exigida, que pode incluir autenticação multifator, verificação de conformidade do dispositivo ou um novo login.
Existem dois modos de configuração. No modo reautenticação, o membro autentica novamente no provedor e, dependendo da política configurada, uma senha pode ser suficiente. No modo MFA, além do novo login é preciso cumprir um desafio adicional, como aplicativo autenticador ou biometria. Para empresas que buscam resistência real a credenciais roubadas, o segundo modo é o caminho recomendado, porque uma senha reaproveitada ou interceptada não basta para passar pelo desafio.
Depois de um desafio concluído, o membro continua executando ações protegidas na mesma sessão do navegador até a expiração da janela do sudo mode, sem novo desafio a cada clique. O GitHub também anunciou que o suporte à prova de presença antes da fusão de pull requests chega em breve, o que estenderá a proteção ao momento em que código entra na base principal.
Por que a mudança importa
A motivação declarada pelo GitHub conecta o recurso a incidentes reais: cookies de sessão roubados e tokens de autenticação de longa duração apareceram em vários ataques recentes à cadeia de suprimentos. Nesses casos, o invasor não precisa quebrar senha nenhuma; basta reutilizar o material de sessão coletado por infostealers, phishing ou malwares de acesso remoto para criar tokens, alterar webhooks e abrir caminhos duradouros dentro do ambiente de desenvolvimento.
A prova de presença muda a pergunta que a plataforma faz. Em vez de verificar se existe um token válido, ela verifica se uma pessoa autorizada está presente no instante da ação. Essa distinção acompanha a mesma linha de raciocínio de orientações recentes sobre proteção de tokens em ambientes de nuvem, como as recomendações do guia que endurece tokens de acesso, e dialoga com a adoção de credenciais resistentes a phishing no lugar de segredos reutilizáveis. Para setores regulados, o GitHub cita ainda que a reautenticação fresca antes de operações sensíveis ajuda a atender exigências de conformidade, como as do padrão FDA Part 11.
Como o desafio funciona
O fluxo é simples do ponto de vista do usuário final. Ao tentar uma ação protegida, o membro é levado ao provedor de identidade da empresa, cumpre os prompts definidos na política, incluindo qualquer multifator exigido, e retorna ao GitHub para concluir a operação. Se a pessoa não concluir o desafio, o caminho indicado é procurar o administrador da empresa ou o administrador do provedor responsável pela autenticação.
Do lado da administração, a ativação segue quatro passos: acessar a página da empresa no GitHub, abrir as configurações, entrar em segurança de autenticação e escolher o requisito desejado no menu de prova de presença. A política vale para toda a empresa, o que exige alinhar comunicação e suporte antes do lançamento, para que equipes de desenvolvimento não descubram o novo desafio no meio de um deploy.
Escopo e limitações
A pré-visualização tem recorte claro: vale apenas para empresas com usuários gerenciados no github.com e GHEC-DR que usam o Microsoft Entra ID como provedor de identidade, via SAML ou OIDC. Durante a fase de pré-visualização, o Entra ID é o único provedor suportado, e o recurso está sujeito a mudanças. Empresas que usam outros provedores de identidade ou contas pessoais ficam fora do alcance, e o sudo mode padrão continua sendo a única barreira disponível para elas.
Há duas armadilhas de configuração. Primeira: no modo reautenticação, a política do provedor determina a força do desafio, e uma política permissiva pode permitir que apenas a senha satisfaça a verificação, o que reduz o ganho de segurança. Segunda: como o desafio vale pela janela da sessão do sudo mode, uma estação comprometida após um desafio legítimo continua capaz de executar ações protegidas até a expiração; o controle reduz a janela de abuso, não a elimina.
Checklist de adoção
| Prioridade | Ação |
|---|---|
| P1 | Confirmar se a empresa usa EMU ou GHEC-DR com Entra ID via SAML ou OIDC; sem esse pré-requisito o recurso não aparece |
| P1 | Endurecer a política do Entra ID para exigir MFA real no desafio, evitando que senha isolada satisfaça a verificação |
| P1 | Ativar a prova de presença no modo MFA em Authentication security e comunicar as equipes antes da vigência |
| P2 | Revisar logs de auditoria do enterprise em busca de ações de alto impacto inesperadas, como criação de tokens e edição de webhooks fora de janelas conhecidas |
| P2 | Acompanhar o anúncio da extensão para fusão de pull requests e planejar a inclusão desse gatilho no runbook |
| P2 | Reduzir a vida útil de tokens clássicos e revisar permissões de aplicativos instalados, já que o recurso não protege o que já foi emitido |
Decisão operacional
Para a maioria das empresas elegíveis, a decisão racional é ativar no modo MFA o quanto antes. O custo é um redirect a mais em operações que já são raras por natureza, e o benefício é fechar o caminho mais barato que um invasor tem hoje dentro de plataformas de desenvolvimento: a sessão roubada que silenciosamente emite credenciais duradouras. Combine o controle com rotação de tokens existentes, inventário de credenciais e monitoramento das ações protegidas nos logs, porque defesa de sessão funciona melhor quando a detecção acompanha a prevenção.