Acceso del contratista al repositorio: ¿entrada pública o ruta VPN?

Un contratista necesita un repositorio privado para un proyecto limitado, y la solicitud llega como «haz el repositorio público» o «dales acceso VPN». Ambas respuestas esquivan la pregunta real. La autorización del repositorio y la entrada de red son capas separadas, y el permiso que importa es el que permite a esa persona leer o hacer push en ese único repositorio. Todo lo demás de cualquiera de los dos paquetes es riesgo adicional. Diseñe primero la capa de autorización y después decida cuánta poca ruta de red necesita.

Un encargo ilustrativo lo hace concreto: un desarrollador externo, un repositorio, ningún host de producción, ninguna interfaz de administración. Mantenga ese alcance fijo mientras compara las entradas.

Dos entradas, dos fronteras distintas

Un servicio de repositorio accesible públicamente sigue aplicando autenticación HTTPS o SSH y autorización de aplicación. La accesibilidad pública no significa legibilidad anónima. El costo es un oyente que hay que mantener, supervisar y parchear.

Una entrada VPN puede mantener ese oyente fuera de la ruta pública, pero una cuenta VPN amplia puede exponer servicios no relacionados. Un nombre de host público olvidado, un oyente SSH o una familia de direcciones que olvidó pueden anular la frontera solo VPN que creía tener. Por eso un diseño solo VPN necesita un inventario de oyentes, no solo una regla de cortafuegos.

Compare rutas permitidas, no etiquetas. En cualquier caso, mantenga la autenticación de aplicación y la validación normal de identidad del servidor.

Los roles del repositorio son la unidad de permiso

Dé al contratista una identidad individual con el rol más pequeño que complete la tarea. Ver, hacer push, mantener y administrar son roles distintos, y un grupo que concede todos los proyectos internos no es lo mismo que el acceso a un repositorio. Compruebe los nombres reales de los roles en su plataforma en lugar de suponer que el nombre de un grupo corresponde a un solo rol.

Enumere cada operación que el encargo necesita realmente. El acceso desde el navegador y el transporte Git pueden usar credenciales u oyentes distintos. Las compilaciones automatizadas, las descargas de paquetes y los webhooks pueden ejecutarse como identidades separadas con sus propias rutas de entrega, y una VPN en el portátil no las conecta.

Proteger el contenido del repositorio es un trabajo aparte. Cambiar la ruta de entrada no elimina un secreto que ya está en el historial, no restringe un clon autorizado ni protege la estación de trabajo de un colaborador.

Credenciales que sobreviven a la persona

La baja es donde el acceso al repositorio y el acceso a la red vuelven a divergir. Elimine la autorización del repositorio y el derecho de VPN a través de sus respectivos propietarios y después revise los tokens personales, las claves SSH, las credenciales de automatización y las sesiones activas. Una clave de despliegue es el superviviente clásico: puede conservar su acceso configurado de lectura o escritura después de que la persona deje la organización. Quitar a alguien de una lista de miembros no es una baja completa.

Inventaríe las credenciales de máquina por propietario y propósito antes de que termine el encargo, no después. Un token creado para una compilación de una semana puede sobrevivir al proyecto un año si nadie escribió por qué existe.

Verifique la operación, la denegación y la baja

Antes de la entrega, pruebe tres cosas: la operación permitida en el repositorio tiene éxito, un repositorio no relacionado se deniega y la identidad retirada falla. Si el diseño es solo VPN, confirme que la antigua ruta pública directa ya no puede realizar la operación.

Conserve el código y los registros de revisión, pero no deje que el acceso olvidado se convierta en el plan de recuperación. Una lista escrita de identidades, roles y fechas de caducidad es lo que hace que la próxima solicitud de contratista sea un proceso repetible.