Toegang van de opdrachtnemer tot de repository: publieke ingang of VPN-pad?

Een opdrachtnemer heeft één privérepository nodig voor een beperkt project, en het verzoek komt binnen als «maak de repo openbaar» of «geef ze VPN-toegang». Beide antwoorden slaan de echte vraag over. Repository-autorisatie en netwerkingang zijn aparte lagen, en de toestemming die ertoe doet, is degene die die persoon laat lezen of pushen naar precies die ene repository. Al het andere in elke bundel is extra risico. Ontwerp eerst de autorisatielaag en beslis daarna hoe weinig netwerkpad die nodig heeft.

Een illustratieve opdracht maakt dit concreet: één externe ontwikkelaar, één repository, geen productiehosts, geen beheerinterface. Houd deze scope vast terwijl u de ingangen vergelijkt.

Twee ingangen, twee verschillende grenzen

Een publiek bereikbare repositorydienst handhaaft nog steeds HTTPS- of SSH-authenticatie en applicatieautorisatie. Publieke bereikbaarheid betekent niet anonieme leesbaarheid. De prijs is een listener die u moet onderhouden, monitoren en patchen.

Een VPN-ingang kan die listener buiten het publieke pad houden, maar een breed VPN-account kan niet-gerelateerde diensten blootleggen. Een achtergebleven publieke hostnaam, een SSH-listener of een adresfamilie die u vergat, kunnen de grens van alleen VPN doorbreken waarvan u dacht dat u die had. Daarom heeft een ontwerp met alleen VPN een inventaris van listeners nodig, niet alleen een firewallregel.

Vergelijk toegestane paden, geen labels. Houd in ieder geval applicatie-authenticatie en normale validatie van de serveridentiteit in stand.

Repository-rollen zijn de eenheid van toestemming

Geef de opdrachtnemer een individuele identiteit met de kleinste rol die de taak voltooit. Bekijken, pushen, onderhouden en beheren zijn verschillende rollen, en een groep die elk intern project toekent is niet hetzelfde als toegang tot één repository. Controleer de werkelijke rolnamen in uw platform in plaats van aan te nemen dat een groepsnaam op één rol past.

Som elke bewerking op die de opdracht echt nodig heeft. Browsertoegang en Git-transport kunnen verschillende inloggegevens of listeners gebruiken. Geautomatiseerde builds, pakketdownloads en webhooks kunnen als afzonderlijke identiteiten met eigen leveringspaden draaien, en een VPN op de laptop verbindt die niet.

De inhoud van de repository beschermen is apart werk. Het wijzigen van het ingangspad verwijdert geen geheim dat al in de geschiedenis staat, beperkt geen geautoriseerde kloon en beveiligt geen werkstation van een bijdrager.

Inloggegevens die de persoon overleven

Bij het offboarden lopen repositorytoegang en netwerktoegang weer uiteen. Verwijder de repository-autorisatie en het VPN-recht via hun respectieve eigenaren en controleer daarna persoonlijke tokens, SSH-sleutels, automatiseringsgegevens en actieve sessies. Een deploy-sleutel is de klassieke overlevende: die kan zijn geconfigureerde lees- of schrijftoegang behouden nadat de persoon de organisatie verlaat. Verwijdering uit een ledenlijst is geen volledige offboarding.

Inventariseer machinegegevens per eigenaar en doel voordat de opdracht eindigt, niet daarna. Een token dat voor een weekbuild is gemaakt, kan het project een jaar overleven als niemand heeft opgeschreven waarom het bestaat.

Verifieer de bewerking, de weigering en de offboarding

Test voor de overdracht drie dingen: de toegestane repositorybewerking slaagt, een niet-gerelateerde repository wordt geweigerd en de uitgefaseerde identiteit faalt. Als het ontwerp alleen VPN is, bevestig dan dat de oude directe publieke route de bewerking niet meer kan uitvoeren.

Bewaar de code en de reviewregistraties, maar laat vergeten toegang niet het herstelplan worden. Een schriftelijke lijst van identiteiten, rollen en vervaldatums is wat het volgende verzoek van een opdrachtnemer tot een herhaalbaar proces maakt.