Accesul contractorului la depozit: intrare publică sau cale VPN?

Un contractor are nevoie de un depozit privat pentru un proiect limitat, iar cererea vine fie ca «faceți depozitul public», fie ca «dați-le acces VPN». Ambele răspunsuri ocolesc întrebarea reală. Autorizarea depozitului și intrarea de rețea sunt straturi separate, iar permisiunea care contează este cea care îi permite acelei persoane să citească sau să facă push în acel singur depozit. Orice altceva din orice pachet este risc suplimentar. Proiectați mai întâi stratul de autorizare, apoi decideți cât de puțină cale de rețea îi trebuie.

Un angajament ilustrativ face acest lucru concret: un dezvoltator extern, un depozit, niciun host de producție, nicio interfață de administrare. Păstrați acest domeniu fix în timp ce comparați intrările.

Două intrări, două granițe diferite

Un serviciu de depozit accesibil public aplică în continuare autentificare HTTPS sau SSH și autorizare a aplicației. Accesibilitatea publică nu înseamnă lizibilitate anonimă. Costul este un ascultător pe care trebuie să îl întrețineți, monitorizați și patchuiți.

O intrare VPN poate ține acel ascultător în afara căii publice, dar un cont VPN larg poate expune servicii fără legătură. Un nume de gazdă public rămas, un ascultător SSH sau o familie de adrese uitată pot anula granița doar-VPN pe care credeați că o aveți. De aceea un design doar-VPN are nevoie de un inventar al ascultătorilor, nu doar de o regulă de firewall.

Comparați căile permise, nu etichetele. În orice caz, păstrați autentificarea aplicației și validarea normală a identității serverului.

Rolurile din depozit sunt unitatea de permisiune

Dați contractorului o identitate individuală cu cel mai mic rol care finalizează sarcina. Vizualizarea, push, întreținerea și administrarea sunt roluri diferite, iar un grup care acordă fiecare proiect intern nu este același lucru cu accesul la un singur depozit. Verificați numele reale ale rolurilor în platforma dvs. în loc să presupuneți că numele unui grup corespunde unui singur rol.

Enumerați fiecare operațiune de care angajamentul are cu adevărat nevoie. Accesul prin browser și transportul Git pot folosi acreditări sau ascultători diferiți. Buildurile automate, descărcările de pachete și webhook-urile pot rula ca identități separate cu propriile căi de livrare, iar un VPN pe laptop nu le conectează.

Protejarea conținutului depozitului este o muncă separată. Schimbarea căii de intrare nu elimină un secret deja aflat în istoric, nu restricționează o clonă autorizată și nu securizează stația de lucru a unui contribuitor.

Acreditări care supraviețuiesc persoanei

Offboardingul este locul unde accesul la depozit și accesul la rețea diverg din nou. Eliminați autorizarea depozitului și dreptul VPN prin proprietarii respectivi, apoi verificați tokenurile personale, cheile SSH, acreditările de automatizare și sesiunile active. O cheie de implementare este supraviețuitorul clasic: poate păstra accesul configurat de citire sau scriere după ce persoana părăsește organizația. Eliminarea dintr-o listă de membri nu este un offboarding complet.

Inventariați acreditările de mașină după proprietar și scop înainte ca angajamentul să se încheie, nu după. Un token creat pentru un build de o săptămână poate supraviețui proiectului cu un an dacă nimeni nu a scris de ce există.

Verificați operațiunea, refuzul și offboardingul

Înainte de predare, testați trei lucruri: operațiunea permisă asupra depozitului reușește, un depozit fără legătură este refuzat, iar identitatea retrasă eșuează. Dacă designul este doar-VPN, confirmați că vechea rută publică directă nu mai poate executa operațiunea.

Păstrați codul și înregistrările de revizuire, dar nu lăsați accesul uitat să devină planul de recuperare. O listă scrisă de identități, roluri și date de expirare este ceea ce face din următoarea cerere de contractor un proces repetabil.