Kontraktørens adgang til repository: offentlig indgang eller VPN-vej?

En kontraktør har brug for ét privat repository til et afgrænset projekt, og anmodningen kommer som enten «gør repoet offentligt» eller «giv dem VPN-adgang». Begge svar springer det egentlige spørgsmål over. Repository-autorisation og netværksindgang er separate lag, og den tilladelse, der betyder noget, er den, der lader den person læse eller push til netop det repository. Alt andet i begge pakker er ekstra risiko. Design først autorisationslaget, og beslut derefter, hvor lidt netværksvej det har brug for.

En illustrativ opgave gør det konkret: én ekstern udvikler, ét repository, ingen produktionsværter, ingen administrationsgrænseflade. Hold det omfang fast, mens du sammenligner indgangene.

To indgange, to forskellige grænser

En offentligt tilgængelig repository-tjeneste håndhæver stadig HTTPS- eller SSH-godkendelse og applikationsautorisation. Offentlig tilgængelighed betyder ikke anonym læsbarhed. Prisen er en listener, du skal vedligeholde, overvåge og patche.

En VPN-indgang kan holde den listener ude af den offentlige vej, men en bred VPN-konto kan blotlægge uvedkommende tjenester. Et efterladt offentligt værtsnavn, en SSH-listener eller en adressefamilie, du glemte, kan nedbryde den VPN-only-grænse, du troede, du havde. Derfor har et VPN-only-design brug for en oversigt over listenere, ikke bare en firewallregel.

Sammenlign tilladte veje, ikke labels. Hold under alle omstændigheder applikationsgodkendelse og normal validering af serveridentitet på plads.

Repository-roller er tilladelsesenheden

Giv kontraktøren en individuel identitet med den mindste rolle, der fuldfører opgaven. Visning, push, vedligeholdelse og administration er forskellige roller, og en gruppe, der giver alle interne projekter, er ikke det samme som adgang til ét repository. Kontroller de faktiske rollenavne på din platform i stedet for at antage, at et gruppenavn svarer til én rolle.

List enhver operation, opgaven faktisk har brug for. Browseradgang og Git-transport kan bruge forskellige legitimationsoplysninger eller listenere. Automatiserede builds, pakkedownloads og webhooks kan køre som separate identiteter med deres egne leveringsveje, og en VPN på den bærbare forbinder dem ikke.

Beskyttelse af repositoryets indhold er et separat arbejde. Ændring af indgangsvejen fjerner ikke en hemmelighed, der allerede er i historikken, begrænser ikke et autoriseret klon, og sikrer ikke en bidragyders arbejdsstation.

Legitimationsoplysninger, der lever længere end personen

Offboarding er der, hvor repository-adgang og netværksadgang igen skilles. Fjern repository-autorisationen og VPN-rettigheden gennem deres respektive ejere, og kontroller derefter personlige tokens, SSH-nøgler, automatiseringsoplysninger og aktive sessioner. En deploy-nøgle er den klassiske overlever: den kan beholde sin konfigurerede læse- eller skriveadgang, efter at personen forlader organisationen. Fjernelse fra en medlemsliste er ikke fuld offboarding.

Opret en oversigt over maskinlegitimationsoplysninger efter ejer og formål, før opgaven slutter, ikke efter. Et token oprettet til et uges build kan overleve projektet med et år, hvis ingen skrev ned, hvorfor det findes.

Verificer operationen, afvisningen og offboardingen

Før overlevering, test tre ting: den tilladte repository-operation lykkes, et uvedkommende repository afvises, og den afgåede identitet fejler. Hvis designet er VPN-only, bekræft, at den gamle direkte offentlige rute ikke længere kan udføre operationen.

Behold koden og gennemgangsregistreringerne, men lad ikke glemt adgang blive genopretningsplanen. En skriftlig liste over identiteter, roller og udløbsdatoer er det, der gør den næste kontraktøranmodning til en gentagelig proces.