Acceso do contratista ao repositorio: entrada pública ou ruta VPN?

Un contratista necesita un repositorio privado para un proxecto limitado, e a solicitude chega como «fai o repositorio público» ou «dálles acceso VPN». Ambas as respostas esquivan a pregunta real. A autorización do repositorio e a entrada de rede son capas separadas, e o permiso que importa é o que permite a esa persoa ler ou facer push nese único repositorio. Todo o demais de calquera dos dous paquetes é risco adicional. Deseñe primeiro a capa de autorización e despois decida canta pouca ruta de rede necesita.

Un encargo ilustrativo faino concreto: un desenvolvedor externo, un repositorio, ningún host de produción, ningunha interface de administración. Manteña ese alcance fixo mentres compara as entradas.

Dúas entradas, dúas fronteiras distintas

Un servizo de repositorio accesible publicamente segue aplicando autenticación HTTPS ou SSH e autorización de aplicación. A accesibilidade pública non significa lexibilidade anónima. O custo é un oínte que hai que manter, vixiar e parchear.

Unha entrada VPN pode manter ese oínte fóra da ruta pública, pero unha conta VPN ampla pode expor servizos non relacionados. Un nome de host público esquecido, un oínte SSH ou unha familia de enderezos que esqueceu poden anular a fronteira só VPN que cría ter. Por iso un deseño só VPN necesita un inventario de oíntes, non só unha regra de devasado.

Compare rutas permitidas, non etiquetas. En calquera caso, manteña a autenticación de aplicación e a validación normal de identidade do servidor.

Os roles do repositorio son a unidade de permiso

Dea ao contratista unha identidade individual co rol máis pequeno que complete a tarefa. Ver, facer push, manter e administrar son roles distintos, e un grupo que concede todos os proxectos internos non é o mesmo que o acceso a un repositorio. Comprobe os nomes reais dos roles na súa plataforma en lugar de supor que o nome dun grupo corresponde a un só rol.

Enumere cada operación que o encargo necesita realmente. O acceso desde o navegador e o transporte Git poden usar credenciais ou oíntes distintos. As compilacións automatizadas, as descargas de paquetes e os webhooks poden executarse como identidades separadas coas súas propias rutas de entrega, e unha VPN no portátil non as conecta.

Protexer o contido do repositorio é un traballo aparte. Cambiar a ruta de entrada non elimina un segredo que xa está no historial, non restrinxe un clon autorizado nin protexe a estación de traballo dun colaborador.

Credenciais que sobreviven á persoa

A baixa é onde o acceso ao repositorio e o acceso á rede volven diverxir. Elimine a autorización do repositorio e o dereito VPN a través dos seus respectivos propietarios e despois revise os tokens persoais, as claves SSH, as credenciais de automatización e as sesións activas. Unha clave de despregamento é o supervivente clásico: pode conservar o seu acceso configurado de lectura ou escritura despois de que a persoa deixe a organización. Quitar a alguén dunha lista de membros non é unha baixa completa.

Inventaríe as credenciais de máquina por propietario e propósito antes de que remate o encargo, non despois. Un token creado para unha compilación dunha semana pode sobrevivir ao proxecto un ano se ninguén escribiu por que existe.

Verifique a operación, a denegación e a baixa

Antes da entrega, probe tres cousas: a operación permitida no repositorio ten éxito, un repositorio non relacionado é denegado e a identidade retirada falla. Se o deseño é só VPN, confirme que a antiga ruta pública directa xa non pode realizar a operación.

Conserve o código e os rexistros de revisión, pero non deixe que o acceso esquecido se converta no plan de recuperación. Unha lista escrita de identidades, roles e datas de caducidade é o que fai que a próxima solicitude de contratista sexa un proceso repetible.