Centralizza l’accesso VPN dei partner senza unire i partner

La proposta è ragionevole: cinque tunnel dei partner distribuiti su una dozzina di portatili, cinque insiemi di versioni client, cinque script di supporto e un ingegnere che sa come si incastrano. Spostarli su un livello di accesso controllato risolve la dispersione degli endpoint. Crea anche un nuovo oggetto nell’architettura, un servizio di accesso condiviso che ora ha bisogno del proprio modello di autorizzazione, e il guasto che tutti sottovalutano è un apparato centrale con tutti i tunnel abilitati che diventa silenziosamente una rete di transito tra organizzazioni che non hanno mai accettato di essere vicine. Quel rischio è una scelta di progetto, non qualcosa che l’hardware fa da solo. Il lavoro qui sotto è come mantengo la comodità senza accettare l’effetto collaterale accidentale.

Parti dal contratto che ogni partner ha già firmato

Prima di qualsiasi configurazione, conferma che il partner permetta davvero un gateway condiviso o una connessione di sede. Un account personale di accesso remoto, un requisito di postura del dispositivo o un flusso MFA interattivo potrebbero non essere trasferibili a un tunnel condiviso senza sorveglianza, e raggruppare i dipendenti dietro un’unica identità client copiata è il tipo di scorciatoia che sopravvive finché il partner non controlla i propri log. Per ogni connessione consentita, annota gli intervalli di destinazione, i domini DNS privati, le sorgenti interne autorizzate, il responsabile dell’autenticazione e cosa deve succedere se il tunnel fallisce. Chiedi al partner di confermare per iscritto la connessione condivisa, compresi gli intervalli di origine che accetterà. L’approvazione verbale di solito cambia significato la settimana in cui ruota il loro team di sicurezza.

Quel registro è il risultato. Se non riesci a scriverlo per un partner, quel partner non è pronto a essere centralizzato.

Instrada per contesto, non solo per destinazione

Due partner finiranno per usare lo stesso intervallo privato, perché ogni organizzazione sceglie dallo stesso spazio RFC 1918. Una singola tabella di routing ordinaria non può scegliere il partner giusto solo da un indirizzo di destinazione, quindi gli intervalli sovrapposti hanno bisogno di contesti di routing separati o di un altro progetto concordato. Il modello di dominio di inoltro in RFC 4364 spiega perché questa separazione conta, e un deployment non deve eseguire MPLS per pretendere la stessa proprietà dalla propria piattaforma gateway.

Chiedi alla piattaforma una cosa diretta: due partner possono condividere lo stesso prefisso di destinazione ed essere comunque distinti dal contesto del dipendente da cui è arrivata la sessione? Se la risposta è no, quel vincolo plasma il progetto più di qualsiasi elenco di funzioni di un fornitore.

Dove la risposta è sì, il contesto di routing diventa ciò che documenti e verifichi, perché è invisibile in un traceroute.

Decidi cosa digita il dipendente e cosa registra il partner

Parte del lavoro con i partner si adatta a un proxy applicativo o a uno spazio di lavoro remoto aperto nel contesto di quel partner. Altro lavoro richiede accesso di rete instradato da un segmento di dipendenti approvato, e i due producono indirizzi di origine e tracce di controllo diverse all’estremità remota. Un indirizzo di origine tradotto e condiviso può soddisfare una lista di autorizzati nascondendo quale dispositivo ha fatto cosa, quindi conserva un registro affidabile dipendente-sessione e mantieni l’autenticazione applicativa invece di trattare l’indirizzo del gateway come un’identità, cosa comoda fino al momento in cui il partner chiede chi l’ha fatto.

Poi percorri un compito reale dal lato del dipendente: cosa clicca, cosa gli viene chiesto e cosa vedrebbe il partner se chiedesse una voce di log. Se quel percorso non è riproducibile, il progetto non è finito.

Nega esplicitamente il transito tra partner

L’hardware condiviso non dovrebbe mai implicare fiducia condivisa. Aggiungi la negazione come regola deliberata con un responsabile nominato, non come un incidente di configurazione mancante, e verificala in entrambe le direzioni con una richiesta che altrimenti avrebbe successo. Il test conta perché un permesso solo assente può essere ripristinato dall’ingegnere successivo che aggiunge una rotta per risolvere una lamentela non correlata.

Scrivi la negazione nel registro del partner accanto ai permessi, così che l’intenzione sopravviva ai cambi di personale.

Gestiscilo come un servizio condiviso, non come un portatile più grande

Il rinnovo dei tunnel, la rotazione delle credenziali, la capacità e la sostituzione del gateway diventano ora tutti cambiamenti di un servizio condiviso, il che significa che hanno bisogno di un calendario e di un canale di comunicazione che i singoli portatili non hanno mai richiesto. Un certificato del partner che scade di sabato non è più l’interruzione di un solo utente; sono tutte le sessioni di quel partner insieme.

Accetta il livello solo quando una richiesta negata tra partner fallisce esattamente come previsto e una richiesta autorizzata di un dipendente raggiunge la destinazione giusta con l’origine giusta. Rimuovere il conflitto dei portatili mantenendo intatto il confine di ogni partner è tutto il punto; un progetto in cui ogni prefisso remoto è raggiungibile da ogni scrivania ha solo spostato il problema.

Tieni una piccola tabella con partner, contesto, intervalli consentiti e responsabile. Sarà la prima cosa che qualcuno chiederà durante un incidente.