Due VPN insieme? Definire prima il confine dell’endpoint

Due client VPN connessi insieme collocano un endpoint in due domini di risorse, e questa è una questione di autorizzazione prima che una questione di routing. Il fatto che i tunnel siano cifrati non dice nulla sulla necessità che le applicazioni di quel portatile raggiungano entrambe le reti, né sul fatto che un peer di una rete debba raggiungere l’altra attraverso di esso. Percorrete i controlli seguenti in ordine e fermatevi al primo a cui nessuno sa rispondere. Approvare la sovrapposizione senza quelle risposte è il modo in cui una sistemazione comoda diventa silenziosamente un ponte.

Partite dal lavoro reale: quali risorse in ciascuna rete servono alla persona, e i due proprietari delle reti consentono l’accesso simultaneo da un solo dispositivo?

Verificate chi consente la sovrapposizione

Due reti che autenticano ciascuna lo stesso utente hanno comunque proprietari separati, e questi proprietari possono avere ipotesi incompatibili su dispositivi collegati anche altrove. Chiedete a entrambi prima di progettare qualsiasi cosa. Una politica di accesso remoto scritta per portatili isolati spesso non ha alcuna risposta per una macchina che si trova contemporaneamente dentro una rete partner.

Ottenete la risposta per iscritto e conservatela con la registrazione della modifica. Se una parte dice no, il resto di questo elenco è accademico, e vi siete risparmiati una revisione di progettazione.

Non trattate due interfacce come un router

Due interfacce attive non rendono automaticamente il dispositivo un router né un bridge Ethernet. Verificate la configurazione supportata di inoltro, bridging, NAT e proxy prima di descrivere qualcosa come percorso di transito, e preservate eventuali compiti di routing autorizzati e non correlati che il dispositivo già svolge. Un portatile che esegue una rete di container locale o un host di virtualizzazione non è qui un osservatore neutrale.

Se il requisito è davvero un transito da A a B, appartiene a un dispositivo di rete con un proprietario, un insieme di regole verificabile e un processo di modifica. Farlo per caso attraverso una workstation è il risultato che questo controllo esiste per evitare.

Trattate l’endpoint anche come punto di accesso

Il dispositivo non è solo un client di entrambe le reti; è un host che offre servizi. Un servizio consentito su quella macchina può essere raggiungibile da un peer VPN secondo il firewall dell’host e la politica del client, quindi una porta di gestione esposta sul portatile fa ora parte della superficie d’attacco della rete remota. Elencate cosa è in ascolto prima di discutere di rotte, perché una porta di debug associata pesa più di qualsiasi politica di tunnel. Limitate i servizi dell’host alle loro fonti e finalità previste.

Trattate ogni rete remota come un dominio di risorse con permessi espliciti invece di concedere fiducia ampia perché il traffico è arrivato cifrato. L’architettura zero trust del NIST separa l’autorizzazione delle risorse dalla fiducia implicita nella posizione di rete, ed è esattamente la distinzione che un portatile con due tunnel confonde.

Fate un’altra domanda finché siete qui: se un servizio locale o un’applicazione autorizzata venissero compromessi, quali risorse e credenziali diventerebbero raggiungibili da quel punto d’appoggio? Scrivete la risposta, perché è la dichiarazione di rischio reale per l’intera progettazione.

Scegliete il confine di lavoro adatto al modello di minaccia

Il routing per applicazione può assegnare i programmi ai tunnel previsti, e profili di lavoro, utenti o aree di lavoro virtuali supportate possono aggiungere confini di identità e di dati a seconda della piattaforma. Allineate il confine al modello di minaccia e non alla dimostrazione: una separazione di routing senza separazione di identità lascia ancora un solo profilo del browser con entrambe le sessioni.

Un namespace di rete isola il routing e lo stato di rete; non isola ogni percorso del file system, gli appunti o l’agente delle credenziali. Una macchina virtuale o un profilo gestito richiedono ugualmente una politica deliberata di condivisione e amministrazione dell’host. Annotate quali cartelle, assistenti di autenticazione e percorsi di copia e incolla restano disponibili, perché sono i canali che trasportano davvero i dati tra i due domini.

Per il lavoro sequenziale, un passaggio intenzionale è di solito più semplice del mantenere l’accesso simultaneo. Completate l’operazione dipendente e poi verificate identità e rotta dell’area di lavoro successiva invece di lasciare strumenti in background legati a un contesto ambiguo.

Scrivete l’approvazione come un compito, non come uno slogan

Un verbale di approvazione dovrebbe leggersi come un compito: l’area di lavoro di supporto può raggiungere la console dei servizi della Rete A e il portale dei ticket della Rete B, senza inoltro autorizzato da A a B, senza agente delle credenziali condiviso e senza sincronizzazione automatica dei file. Ogni clausola di quella frase corrisponde a qualcosa che potete configurare e testare.

Poi verificate i casi negativi, non solo quelli positivi. Provate a raggiungere una risorsa che dovrebbe restare fuori dal confine, confermate che il servizio dell’host non risponde dall’altro lato e controllate che l’assistente delle credenziali non serva silenziosamente entrambi i domini.

Conservate il verbale con il dispositivo, non solo nel ticket, così la persona successiva che eredita la sistemazione sa quale confine era intenzionale. Un portatile con due tunnel e senza confine scritto è indistinguibile da una configurazione errata.