Acesso do prestador ao repositório: entrada pública ou caminho VPN?

Um prestador precisa de um repositório privado para um projeto limitado, e o pedido chega como «torne o repositório público» ou «dê a eles acesso VPN». As duas respostas contornam a pergunta real. A autorização do repositório e a entrada de rede são camadas separadas, e a permissão que importa é a que permite àquela pessoa ler ou fazer push naquele único repositório. Todo o resto em qualquer pacote é risco adicional. Projete primeiro a camada de autorização e depois decida quão pouco caminho de rede ela precisa.

Um trabalho ilustrativo torna isso concreto: um desenvolvedor externo, um repositório, nenhum host de produção, nenhuma interface de administração. Mantenha esse escopo fixo enquanto compara as entradas.

Duas entradas, duas fronteiras diferentes

Um serviço de repositório acessível publicamente ainda aplica autenticação HTTPS ou SSH e autorização de aplicação. Acessibilidade pública não significa legibilidade anônima. O custo é um ouvinte que você precisa manter, monitorar e corrigir.

Uma entrada VPN pode manter esse ouvinte fora do caminho público, mas uma conta VPN ampla pode expor serviços não relacionados. Um nome de host público esquecido, um ouvinte SSH ou uma família de endereços que você esqueceu podem derrubar a fronteira somente VPN que você pensava ter. Por isso um projeto somente VPN precisa de um inventário de ouvintes, não apenas de uma regra de firewall.

Compare caminhos permitidos, não rótulos. Em qualquer caso, mantenha a autenticação de aplicação e a validação normal de identidade do servidor.

Os papéis do repositório são a unidade de permissão

Dê ao prestador uma identidade individual com o menor papel que conclui a tarefa. Visualizar, fazer push, manter e administrar são papéis diferentes, e um grupo que concede todos os projetos internos não é o mesmo que acesso a um repositório. Verifique os nomes reais dos papéis na sua plataforma em vez de supor que o nome de um grupo corresponde a um único papel.

Liste cada operação de que o trabalho realmente precisa. O acesso pelo navegador e o transporte Git podem usar credenciais ou ouvintes diferentes. Builds automatizados, downloads de pacotes e webhooks podem rodar como identidades separadas com seus próprios caminhos de entrega, e uma VPN no notebook não as conecta.

Proteger o conteúdo do repositório é um trabalho separado. Mudar o caminho de entrada não remove um segredo que já está no histórico, não restringe um clone autorizado nem protege a estação de trabalho de um colaborador.

Credenciais que sobrevivem à pessoa

O desligamento é onde o acesso ao repositório e o acesso à rede divergem de novo. Remova a autorização do repositório e o direito VPN pelos respectivos proprietários e depois verifique tokens pessoais, chaves SSH, credenciais de automação e sessões ativas. Uma chave de implantação é o sobrevivente clássico: pode manter o acesso configurado de leitura ou escrita depois que a pessoa deixa a organização. Remover alguém de uma lista de membros não é um desligamento completo.

Inventarie as credenciais de máquina por proprietário e finalidade antes que o trabalho termine, não depois. Um token criado para um build de uma semana pode sobreviver ao projeto por um ano se ninguém escreveu por que ele existe.

Verifique a operação, a negação e o desligamento

Antes da entrega, teste três coisas: a operação permitida no repositório funciona, um repositório não relacionado é negado e a identidade retirada falha. Se o projeto for somente VPN, confirme que a antiga rota pública direta não consegue mais executar a operação.

Guarde o código e os registros de revisão, mas não deixe o acesso esquecido se tornar o plano de recuperação. Uma lista escrita de identidades, papéis e datas de expiração é o que torna o próximo pedido de prestador um processo repetível.