Kontraktörens åtkomst till repositoriet: offentlig ingång eller VPN-väg?

En kontraktör behöver ett privat repositorium för ett avgränsat projekt, och förfrågan kommer antingen som «gör repot offentligt» eller «ge dem VPN-åtkomst». Båda svaren hoppar över den egentliga frågan. Repositorieauktorisering och nätverksingång är separata lager, och den behörighet som spelar roll är den som låter personen läsa eller pusha till just det ena repositoriet. Allt annat i varje paket är extra risk. Designa först auktoriseringslagret och avgör sedan hur lite nätverksväg det behöver.

Ett illustrativt uppdrag gör detta konkret: en extern utvecklare, ett repositorium, inga produktionsvärdar, inget administrationsgränssnitt. Håll detta omfång fast medan du jämför ingångarna.

Två ingångar, två olika gränser

En offentligt nåbar repositorietjänst upprätthåller fortfarande HTTPS- eller SSH-autentisering och applikationsauktorisering. Offentlig nåbarhet betyder inte anonym läsbarhet. Priset är en lyssnare som du måste underhålla, övervaka och patcha.

En VPN-ingång kan hålla den lyssnaren utanför den offentliga vägen, men ett brett VPN-konto kan exponera orelaterade tjänster. Ett kvarlämnat offentligt värdnamn, en SSH-lyssnare eller en adressfamilj du glömde kan bryta den enbart-VPN-gräns du trodde du hade. Därför behöver en design med enbart VPN en inventering av lyssnare, inte bara en brandväggsregel.

Jämför tillåtna vägar, inte etiketter. Behåll ändå applikationsautentisering och normal validering av serveridentitet.

Repositorieroller är enheten för behörighet

Ge kontraktören en individuell identitet med den minsta roll som slutför uppgiften. Visa, pusha, underhålla och administrera är olika roller, och en grupp som ger varje internt projekt är inte samma sak som åtkomst till ett repositorium. Kontrollera de faktiska rollnamnen i din plattform i stället för att anta att ett gruppnamn motsvarar en roll.

Lista varje operation som uppdraget faktiskt behöver. Webbläsaråtkomst och Git-transport kan använda olika autentiseringsuppgifter eller lyssnare. Automatiserade byggen, paketnedladdningar och webhooks kan köras som separata identiteter med egna leveransvägar, och en VPN på den bärbara datorn kopplar inte ihop dem.

Att skydda repositoriets innehåll är ett separat arbete. Att ändra ingångsvägen tar inte bort en hemlighet som redan finns i historiken, begränsar inte en auktoriserad klon och säkrar inte en bidragsgivares arbetsstation.

Autentiseringsuppgifter som lever längre än personen

Offboarding är där repositorieåtkomst och nätverksåtkomst åter går isär. Ta bort repositorieauktoriseringen och VPN-rätten genom deras respektive ägare och kontrollera sedan personliga tokens, SSH-nycklar, automatiseringsuppgifter och aktiva sessioner. En deploy-nyckel är den klassiska överlevaren: den kan behålla sin konfigurerade läs- eller skrivåtkomst efter att personen lämnat organisationen. Att ta bort någon från en medlemslista är inte fullständig offboarding.

Inventera maskinautentiseringsuppgifter per ägare och syfte innan uppdraget slutar, inte efteråt. En token som skapades för ett veckobygga kan överleva projektet med ett år om ingen skrev ned varför den finns.

Verifiera operationen, avvisningen och offboardingen

Före överlämningen, testa tre saker: den tillåtna repositorieoperationen lyckas, ett orelaterat repositorium avvisas och den avvecklade identiteten misslyckas. Om designen är enbart VPN, bekräfta att den gamla direkta offentliga vägen inte längre kan utföra operationen.

Behåll koden och granskningsposterna, men låt inte glömd åtkomst bli återställningsplanen. En skriftlig lista över identiteter, roller och utgångsdatum är det som gör nästa kontraktörsförfrågan till en repeterbar process.