Portatile di lavoro su una VPN personale: cosa attraversa davvero

Collegare un portatile aziendale a una VPN domestica lo colloca in due luoghi contemporaneamente, e la domanda interessante è più piccola e più utile di quella allarmante. Nessuno ha steso un cavo Ethernet tra l'ufficio e la casa, e nessuna rotta rende la rete domestica un'estensione della sottorete aziendale. Ciò che esiste è un unico endpoint con accesso a entrambi gli ambienti, e tre meccanismi separati decidono cosa può realmente spostarsi tra loro. Percorrere questi tre, dall'endpoint verso l'esterno, produce una risposta su cui un amministratore può agire invece di un dibattito sulle etichette.

Partite dall'endpoint, non dal diagramma di rete

L'endpoint è il punto in cui entrambe le connessioni si incontrano, quindi è lì che inizia la revisione: quali processi girano, cosa possono raggiungere e chi li controlla. Un diagramma che mostra due nuvole collegate a un portatile è preciso e inutile, perché implica un collegamento che potrebbe non esistere. Sostituitelo con un elenco delle applicazioni che possono parlare con ciascun ambiente, e annotate sotto quale account ciascuna viene eseguita. Questa impostazione mantiene anche la revisione proporzionata, poiché un portatile con due tunnel non è lo stesso oggetto di due reti unite.

Quell'elenco è l'inventario da cui lavora il resto della revisione. Se contiene un client di sincronizzazione, un profilo del browser connesso a entrambi gli ambienti e un agente di build con credenziali, la revisione ha già i suoi soggetti.

Tre punti di attraversamento, esaminati separatamente

L'accesso delle applicazioni è il primo punto di attraversamento e non richiede alcun inoltro. Una scheda del browser, un client di sincronizzazione o un agente di build sull'endpoint possono leggere da una risorsa in un ambiente e inviare dati a una risorsa nell'altro. Questa capacità esiste indipendentemente dal fatto che il sistema operativo inoltri pacchetti tra le interfacce, ed è il meccanismo che le persone trascurano quando concludono che senza ponte non c'è rischio. Leggere l'elenco delle applicazioni è quindi più informativo che leggere l'elenco delle interfacce.

Identità e dati formano il secondo punto di attraversamento. Le credenziali aziendali, i cookie di sessione, i documenti scaricati e i diritti di gestione vivono sull'endpoint, e unirsi a un'altra rete non li divulga da solo. Ciò che cambia è l'insieme delle parti che potrebbero influenzare l'endpoint mentre detiene quelle credenziali, ed è una questione di affidabilità della rete personale, non di routing. È un giudizio che il proprietario dell'endpoint non può dare da solo, e non è risolto dall'assenza di una regola di inoltro.

L'inoltro di rete è il terzo, e l'unico che può trasformare il portatile in un dispositivo di transito. L'inoltro IP, la condivisione della connessione Internet, un proxy o una funzione di ponte possono farlo, e ciascuno è una configurazione che è attiva oppure no. Ispezionate quello stato direttamente invece di dedurlo dalla presenza di un client VPN. Su una macchina gestita la risposta è di solito no, e verificarlo trasforma un'ipotesi in un fatto che vale la pena registrare.

Chiedete una risorsa, non due reti

La maggior parte dei requisiti reali è più stretta di quanto sembri all'inizio: una console, una condivisione file, un'applicazione web interna. Formulate il requisito così e lasciate che il proprietario della risorsa decida se appartiene a questo endpoint. Una richiesta formulata come unione di due reti è difficile da approvare e facile da rifiutare; una richiesta per un servizio nominato ha una risposta.

Se la risposta è sì, preferite il percorso supportato più stretto e mantenete lo all'interno dei controlli esistenti dell'organizzazione. Un secondo profilo gestito o una voce di applicazione con ambito limitato preservano monitoraggio e criteri; una configurazione personale concorrente li sostituisce in silenzio, e nessuno sa quale vince dopo il prossimo aggiornamento.

Includete gli effetti di DNS e rotte

La risoluzione dei nomi cambia nel momento in cui un secondo profilo è attivo. Un client personale può imporre il proprio resolver, un browser può usare il proprio DNS cifrato, e una tabella di criteri può instradare nomi interni verso un server diverso da quello che la configurazione aziendale si aspetta. Nessuno di questi richiede inoltro, e ciascuno può inviare un nome host interno nel posto sbagliato.

Resolve-DnsName intranet.corp.example -Type A
Get-DnsClientNrptPolicy -Effective
route print 0.0.0.0

Catturate questi tre output prima e dopo la connessione del secondo profilo. La differenza tra loro è l'effetto che raggiunge davvero l'utente, ed è spesso maggiore del cambiamento di routing descritto dal ticket. Conservate entrambe le catture così che un revisore successivo veda cosa è cambiato e non cosa era previsto.

Verificate e tenete una via d'uscita

Provate l'applicazione approvata dal processo e dal contesto utente reale, non da una shell di amministratore sulla stessa macchina. Poi confermate che le destinazioni non correlate restano irraggiungibili dove il progetto lo richiede: un confine che nessuno ha testato è un confine che nessuno può rivendicare. Disconnettere il tunnel personale dovrebbe ripristinare lo stato precedente, e quel ripristino vale la pena di essere verificato mentre qualcuno guarda ancora.

Test-NetConnection -ComputerName files.corp.example -Port 443
Get-NetConnectionProfile

Le linee guida NIST su architettura a fiducia zero sono utili qui perché rimuovono la posizione di rete come fonte automatica di fiducia, che è esattamente l'ipotesi in discussione. La domanda non è se la rete domestica sia affidabile per natura; è chi può raggiungere quale risorsa, da quale endpoint e attraverso quale punto di applicazione. Rispondete a queste tre, e conservate le prove insieme alla decisione.