Elenco di IP consentite o portatile approvato: due controlli diversi

Le richieste di una regola che consenta la connessione solo al portatile approvato finiscono spesso come voce del firewall per l'indirizzo pubblico dell'ufficio. Quella regola ora ammette ogni dispositivo dietro l'indirizzo. Il requisito e l'implementazione non sono la stessa cosa. Separate ciò che vuole la politica da ciò che l'indirizzo può dimostrare.

Tre domande in una sola richiesta di politica

Dividete la richiesta in tre parti: da dove arriva la connessione, quale servizio può raggiungere e quale computer presenta la credenziale. Una regola sull'indirizzo di origine risponde alla prima, una regola sul servizio di destinazione alla seconda. Nessuna delle due identifica la macchina fisica, perché entrambe operano su campi di rete condivisi da molti dispositivi. La terza richiede una credenziale emessa per quel dispositivo e non riutilizzabile in silenzio.

Scrivete le tre risposte separatamente. Una sola riga di firewall non può soddisfare un requisito che ne nomina tre.

Che cosa può dirvi l'indirizzo di origine

La traduzione degli indirizzi è il motivo abituale per cui una regola di origine di rete ammette troppo. Tutto ciò che sta dietro un'uscita dell'ufficio appare come lo stesso indirizzo pubblico, quindi la regola concede l'accesso all'intero gruppo. Un indirizzo fisso all'interno della VPN ha la stessa debolezza altrove: è un'assegnazione legata a una sessione, non una proprietà dell'hardware. Qualsiasi dispositivo con una credenziale accettata può aprire quella sessione. Trattate l'indirizzo come una restrizione di rete e descrivetelo così.

Questo resta utile per limitare l'esposizione, e non è autenticazione del dispositivo.

Collegate l'accesso a una credenziale registrata

Se il requisito è la restrizione del dispositivo, usate la registrazione per dispositivo supportata dalla VPN e date a ogni computer un'identità distinta.

certutil -store My <thumbprint>
openssl verify -CAfile vpn-ca.pem device.pem

L'elenco dell'archivio mostra il certificato e se è presente una chiave privata, e la verifica mostra se la catena porta all'ancora prevista. Un certificato dimostra il possesso della chiave privata accettata secondo la politica configurata; non dimostra quale macchina fisica la deteneva quando quella chiave può essere esportata e copiata. Denominare il profilo come il portatile lascia il segreto esattamente altrettanto trasferibile di prima. Dove la piattaforma lo supporta, le chiavi protette dall'hardware con una politica di attestazione offrono un legame più forte, e la registrazione deve comunque decidere chi può ricevere la credenziale.

Provate il confine, poi pianificate la rimozione

Valutate due casi: il portatile approvato e l'utente devono connettersi, e un altro dispositivo che ha solo l'account dell'utente non deve farlo. Se il progetto richiede sia un controllo dell'utente sia uno del dispositivo, verificate che il metodo scelto imponga entrambi nella stessa sessione invece di presumere che due impostazioni indipendenti si combinino.

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -cert device.pem -key device.key

La revoca deve rimuovere l'identità accettata del dispositivo, e la gestione delle sessioni attive merita un test a sé. Un TPM o un indicatore di dispositivo gestito non è un certificato di buona salute per ogni processo sulla macchina.

Registrate la restrizione di rete, la credenziale del dispositivo e la decisione di registrazione come tre controlli con tre responsabili. Questo rende il confine verificabile, ed è ciò che un indirizzo da solo non può mai fornire.