Kontraktørens tilgang til repositoriet: offentlig inngang eller VPN-vei?

En kontraktør trenger ett privat repositorium for et avgrenset prosjekt, og forespørselen kommer enten som «gjør repoet offentlig» eller «gi dem VPN-tilgang». Begge svarene hopper over det egentlige spørsmålet. Repositorieautorisasjon og nettverksinngang er separate lag, og tillatelsen som betyr noe, er den som lar den personen lese eller pushe til nettopp det ene repositoriet. Alt annet i hver pakke er ekstra risiko. Design autorisasjonslaget først, og avgjør deretter hvor lite nettverksvei det trenger.

Et illustrerende oppdrag gjør dette konkret: én ekstern utvikler, ett repositorium, ingen produksjonsverter, ingen administrasjonsgrensesnitt. Hold dette omfanget fast mens du sammenligner inngangene.

To innganger, to forskjellige grenser

En offentlig tilgjengelig repositorietjeneste håndhever fortsatt HTTPS- eller SSH-autentisering og applikasjonsautorisasjon. Offentlig tilgjengelighet betyr ikke anonym lesbarhet. Prisen er en lytter du må vedlikeholde, overvåke og patche.

En VPN-inngang kan holde den lytteren utenfor den offentlige veien, men en bred VPN-konto kan eksponere urelaterte tjenester. Et gjenglemt offentlig vertsnavn, en SSH-lytter eller en adressefamilie du glemte, kan bryte den VPN-bare grensen du trodde du hadde. Derfor trenger et VPN-bare design en oversikt over lyttere, ikke bare en brannmurregel.

Sammenlign tillatte veier, ikke etiketter. Hold uansett applikasjonsautentisering og normal validering av serveridentitet på plass.

Repositorieroller er enheten for tillatelse

Gi kontraktøren en individuell identitet med den minste rollen som fullfører oppgaven. Vise, pushe, vedlikeholde og administrere er forskjellige roller, og en gruppe som gir hvert internt prosjekt, er ikke det samme som tilgang til ett repositorium. Sjekk de faktiske rollenavnene i plattformen din i stedet for å anta at et gruppenavn tilsvarer én rolle.

List opp hver operasjon oppdraget faktisk trenger. Nettlesertilgang og Git-transport kan bruke forskjellige legitimasjoner eller lyttere. Automatiserte bygg, pakkenedlastinger og webhooks kan kjøre som separate identiteter med egne leveringsveier, og en VPN på den bærbare maskinen kobler dem ikke sammen.

Å beskytte innholdet i repositoriet er en separat jobb. Å endre inngangsveien fjerner ikke en hemmelighet som allerede ligger i historikken, begrenser ikke en autorisert klone eller sikrer ikke arbeidsstasjonen til en bidragsyter.

Legitimasjon som lever lenger enn personen

Offboarding er der repositorietilgang og nettverktilgang igjen skiller lag. Fjern repositorieautorisasjonen og VPN-rettigheten gjennom deres respektive eiere, og sjekk deretter personlige tokens, SSH-nøkler, automatiseringslegitimasjon og aktive økter. En deploy-nøkkel er den klassiske overleveren: den kan beholde den konfigurerte lese- eller skrivetilgangen etter at personen forlater organisasjonen. Fjerning fra en medlemsliste er ikke fullstendig offboarding.

Lag en oversikt over maskinlegitimasjon etter eier og formål før oppdraget slutter, ikke etterpå. Et token laget for et ukesbygg kan overleve prosjektet med et år hvis ingen skrev ned hvorfor det finnes.

Verifiser operasjonen, avvisningen og offboardingen

Før overlevering, test tre ting: den tillatte repositorieoperasjonen lykkes, et urelatert repositorium avvises, og den avsluttede identiteten feiler. Hvis designet er VPN-bare, bekreft at den gamle direkte offentlige ruten ikke lenger kan utføre operasjonen.

Behold koden og gjennomgangsregistreringene, men ikke la glemt tilgang bli gjenopprettingsplanen. En skriftlig liste over identiteter, roller og utløpsdatoer er det som gjør den neste kontraktørforespørselen til en repeterbar prosess.