Accesso del fornitore al repository: ingresso pubblico o percorso VPN?

Un fornitore ha bisogno di un repository privato per un progetto limitato, e la richiesta arriva come «rendi il repository pubblico» oppure «dai loro accesso VPN». Entrambe le risposte saltano la domanda vera. L’autorizzazione del repository e l’ingresso di rete sono livelli separati, e il permesso che conta è quello che consente a quella persona di leggere o fare push in quel solo repository. Tutto il resto, in entrambi i pacchetti, è rischio aggiuntivo. Progettate prima il livello di autorizzazione, poi decidete quanto poco percorso di rete serve.

Un incarico illustrativo lo rende concreto: uno sviluppatore esterno, un repository, nessun host di produzione, nessuna interfaccia di amministrazione. Tenete fisso questo perimetro mentre confrontate gli ingressi.

Due ingressi, due confini diversi

Un servizio di repository raggiungibile pubblicamente applica comunque l’autenticazione HTTPS o SSH e l’autorizzazione applicativa. La raggiungibilità pubblica non significa leggibilità anonima. Il costo è un listener che dovete mantenere, monitorare e correggere.

Un ingresso VPN può tenere quel listener fuori dal percorso pubblico, ma un account VPN ampio può esporre servizi non correlati. Un nome host pubblico rimasto, un listener SSH o una famiglia di indirizzi dimenticata possono vanificare il confine solo VPN che pensavate di avere. Per questo un progetto solo VPN richiede un inventario dei listener, non solo una regola del firewall.

Confrontate i percorsi consentiti, non le etichette. In ogni caso, mantenete l’autenticazione applicativa e la normale convalida dell’identità del server.

I ruoli del repository sono l’unità di permesso

Date al fornitore un’identità individuale con il ruolo più piccolo che completa l’attività. Visualizzare, fare push, mantenere e amministrare sono ruoli diversi, e un gruppo che concede ogni progetto interno non equivale all’accesso a un repository. Controllate i nomi reali dei ruoli nella vostra piattaforma invece di supporre che il nome di un gruppo corrisponda a un solo ruolo.

Elencate ogni operazione di cui l’incarico ha davvero bisogno. L’accesso dal browser e il trasporto Git possono usare credenziali o listener diversi. Le build automatizzate, i download di pacchetti e i webhook possono girare come identità separate con i propri percorsi di consegna, e una VPN sul portatile non le collega.

Proteggere il contenuto del repository è un lavoro separato. Cambiare il percorso d’ingresso non rimuove un segreto già presente nella cronologia, non limita un clone autorizzato e non mette in sicurezza la postazione di un collaboratore.

Credenziali che sopravvivono alla persona

L’uscita è il punto in cui l’accesso al repository e l’accesso alla rete divergono di nuovo. Rimuovete l’autorizzazione del repository e il diritto VPN tramite i rispettivi proprietari, poi controllate token personali, chiavi SSH, credenziali di automazione e sessioni attive. Una chiave di distribuzione è il sopravvissuto classico: può conservare l’accesso configurato in lettura o scrittura dopo che la persona lascia l’organizzazione. La rimozione da un elenco di membri non è un’uscita completa.

Inventariate le credenziali macchina per proprietario e scopo prima che l’incarico finisca, non dopo. Un token creato per una build di una settimana può sopravvivere al progetto di un anno se nessuno ha scritto perché esiste.

Verificate l’operazione, il rifiuto e l’uscita

Prima della consegna, provate tre cose: l’operazione consentita sul repository riesce, un repository non correlato viene negato e l’identità ritirata fallisce. Se il progetto è solo VPN, confermate che la vecchia rotta pubblica diretta non possa più eseguire l’operazione.

Conservate il codice e i registri di revisione, ma non lasciate che un accesso dimenticato diventi il piano di ripristino. Un elenco scritto di identità, ruoli e date di scadenza è ciò che rende la prossima richiesta di fornitore un processo ripetibile.