Accés del contractista al repositori: entrada pública o camí VPN?

Un contractista necessita un repositori privat per a un projecte limitat, i la petició arriba com «fes el repositori públic» o «dona’ls accés VPN». Totes dues respostes esquiven la pregunta real. L’autorització del repositori i l’entrada de xarxa són capes separades, i el permís que importa és el que permet a aquesta persona llegir o fer push en aquest únic repositori. Tota la resta de qualsevol paquet és risc addicional. Dissenyeu primer la capa d’autorització i després decidiu quant poc camí de xarxa necessita.

Un encàrrec il·lustratiu ho fa concret: un desenvolupador extern, un repositori, cap amfitrió de producció, cap interfície d’administració. Mantingueu aquest abast fix mentre compareu les entrades.

Dues entrades, dues fronteres diferents

Un servei de repositori accessible públicament encara aplica autenticació HTTPS o SSH i autorització d’aplicació. L’accessibilitat pública no significa llegibilitat anònima. El cost és un oient que cal mantenir, monitorar i pedaçar.

Una entrada VPN pot mantenir aquest oient fora del camí públic, però un compte VPN ampli pot exposar serveis no relacionats. Un nom d’amfitrió públic oblidat, un oient SSH o una família d’adreces que heu oblidat poden derrotar la frontera només VPN que pensàveu que teníeu. Per això un disseny només VPN necessita un inventari d’oients, no només una regla de tallafocs.

Compareu camins permesos, no etiquetes. En qualsevol cas, manteniu l’autenticació d’aplicació i la validació normal d’identitat del servidor.

Els rols del repositori són la unitat de permís

Doneu al contractista una identitat individual amb el rol més petit que completi la tasca. Visualitzar, fer push, mantenir i administrar són rols diferents, i un grup que concedeix tots els projectes interns no és el mateix que l’accés a un repositori. Comproveu els noms reals dels rols a la vostra plataforma en lloc de suposar que el nom d’un grup correspon a un sol rol.

Llisteu cada operació que l’encàrrec necessita realment. L’accés pel navegador i el transport Git poden fer servir credencials o oients diferents. Les compilacions automatitzades, les baixades de paquets i els webhooks poden funcionar com a identitats separades amb els seus propis camins de lliurament, i una VPN a l’ordinador portàtil no les connecta.

Protegir el contingut del repositori és una feina separada. Canviar el camí d’entrada no elimina un secret que ja és a l’historial, no restringeix un clon autoritzat ni protegeix l’estació de treball d’un col·laborador.

Credencials que sobreviuen a la persona

La baixa és on l’accés al repositori i l’accés a la xarxa tornen a divergir. Elimineu l’autorització del repositori i el dret VPN a través dels seus respectius propietaris, i després reviseu els testimonis personals, les claus SSH, les credencials d’automatització i les sessions actives. Una clau de desplegament és el supervivent clàssic: pot conservar el seu accés configurat de lectura o escriptura després que la persona deixi l’organització. Treure algú d’una llista de membres no és una baixa completa.

Inventarieu les credencials de màquina per propietari i propòsit abans que acabi l’encàrrec, no després. Un testimoni creat per a una compilació d’una setmana pot sobreviure al projecte un any si ningú no ha escrit per què existeix.

Verifiqueu l’operació, la denegació i la baixa

Abans del lliurament, proveu tres coses: l’operació permesa al repositori té èxit, un repositori no relacionat és denegat i la identitat retirada falla. Si el disseny és només VPN, confirmeu que l’antic camí públic directe ja no pot fer l’operació.

Conserveu el codi i els registres de revisió, però no deixeu que l’accés oblidat es converteixi en el pla de recuperació. Una llista escrita d’identitats, rols i dates de caducitat és el que fa que la propera petició de contractista sigui un procés repetible.