Aliro de kontraktisto al la deponejo: publika eniro aŭ VPN-vojo?

Kontraktisto bezonas unu privatan deponejon por limigita projekto, kaj la peto alvenas aŭ kiel «faru la deponejon publika» aŭ kiel «donu al ili VPN-aliron». Ambaŭ respondoj preterlasas la veran demandon. Deponeja rajtigo kaj reta eniro estas apartaj tavoloj, kaj la permeso, kiu gravas, estas tiu, kiu ebligas al tiu persono legi aŭ push al tiu unu deponejo. Ĉio alia en iu ajn pakaĵo estas plia risko. Unue desegnu la rajtigan tavolon, poste decidu, kiom malmulte da reta vojo ĝi bezonas.

Ilustra engaĝiĝo faras tion konkreta: unu ekstera programisto, unu deponejo, neniuj produktadaj gastigantoj, neniom da administra interfaco. Tenu tiun amplekson fiksita dum vi komparas la enirojn.

Du eniroj, du malsamaj limoj

Publike atingebla deponeja servo ankoraŭ devigas HTTPS aŭ SSH aŭtentikigon kaj aplikaĵan rajtigon. Publika atingeblo ne signifas anoniman legeblecon. La kosto estas aŭskultanto, kiun vi devas prizorgi, monitori kaj fliki.

VPN-eniro povas teni tiun aŭskultanton ekster la publika vojo, sed larĝa VPN-konto povas malkaŝi nerilatajn servojn. Restinta publika gastigantnomo, SSH-aŭskultanto aŭ adresfamilio, kiun vi forgesis, povas venki la limon nur-VPN, kiun vi pensis, ke vi havas. Tial nur-VPN-dezajno bezonas inventaron de aŭskultantoj, ne nur fajroŝirmilan regulon.

Komparu permesitajn vojojn, ne etikedojn. Ĉiuokaze tenu aplikaĵan aŭtentikigon kaj normalan servilan identeckontrolon.

Deponejaj roloj estas la unuo de permeso

Donu al la kontraktisto individuan identecon kun la plej malgranda rolo, kiu plenumas la taskon. Rigardado, push, prizorgado kaj administrado estas malsamaj roloj, kaj grupo, kiu donas ĉiun internan projekton, ne estas la samo kiel aliro al unu deponejo. Kontrolu la faktajn rolnomojn en via platformo anstataŭ supozi, ke grupnomo mapas al unu rolo.

Listigu ĉiun operacion, kiun la engaĝiĝo efektive bezonas. Retumila aliro kaj Git-transporto povas uzi malsamajn akreditaĵojn aŭ aŭskultantojn. Aŭtomataj konstruoj, pakaĵelŝutoj kaj webhook-oj povas funkcii kiel apartaj identecoj kun propraj liveraj vojoj, kaj VPN sur la tekkomputilo ne konektas ilin.

Protekti la enhavon de la deponejo estas aparta tasko. Ŝanĝi la eniran vojon ne forigas sekreton jam en la historio, ne limigas rajtigitan klonon kaj ne sekurigas laborstacion de kontribuanto.

Akreditaĵoj, kiuj vivas pli longe ol la persono

Elserviĝo estas kie deponeja aliro kaj reta aliro denove diverĝas. Forigu la deponejan rajtigon kaj la VPN-rajton per iliaj respektivaj posedantoj, poste kontrolu personajn ĵetonojn, SSH-ŝlosilojn, aŭtomatigajn akreditaĵojn kaj aktivajn sesiojn. Deponeja ŝlosilo estas la klasika postvivanto: ĝi povas konservi sian agorditan legan aŭ skriban aliron post kiam la persono forlasas la organizaĵon. Forigo el membrolisto ne estas kompleta elserviĝo.

Inventaru maŝinajn akreditaĵojn laŭ posedanto kaj celo antaŭ ol la engaĝiĝo finiĝos, ne poste. Ĵetono kreita por unu-semajna konstruo povas postvivi la projekton je jaro, se neniu skribis, kial ĝi ekzistas.

Kontrolu la operacion, la rifuzon kaj la elserviĝon

Antaŭ transdono, testu tri aferojn: la permesita deponeja operacio sukcesas, nerilata deponejo estas rifuzata, kaj la eksigita identeco malsukcesas. Se la dezajno estas nur-VPN, konfirmu, ke la malnova rekta publika vojo ne plu povas plenumi la operacion.

Konservu la kodon kaj la reviziajn registrojn, sed ne lasu forgesitan aliron fariĝi la reakira plano. Skribita listo de identecoj, roloj kaj eksvalidiĝaj datoj estas tio, kio igas la sekvan kontraktistan peton ripetebla procezo.