Che cos’altro c’è nel vostro agente VPN? Una revisione modulo per modulo

Confrontare un agente VPN gestito con il client integrato del sistema operativo parte male quando il confronto è tra un tunnel e un tunnel. L’installer di solito porta diversi componenti, e solo uno di essi trasporta traffico di rete privato. Gli altri possono occuparsi di visibilità, postura, policy DNS o inventario degli endpoint, ciascuno con la propria configurazione e il proprio flusso di dati. Chiedete l’elenco dei componenti installati prima di confrontare qualsiasi cosa, perché il nome del prodotto non è la distribuzione.

Chiedete l’elenco dei componenti, non il nome del prodotto

Per ogni componente installato, annotate cinque fatti: lo scopo, chi possiede la sua configurazione, con quali privilegi viene eseguito, come viene aggiornato e come viene rimosso. Queste cinque risposte trasformano una preoccupazione vaga in un inventario verificabile. Rivelano anche i componenti che nessuno ha guardato dal pilota.

Separate il servizio tunnel da qualsiasi funzione di visibilità, DNS o postura distribuita in modo indipendente. Un modulo che osserva i flussi è cosa diversa da un modulo che li instrada, anche quando entrambi arrivano nello stesso pacchetto.

Non deducete l’inventario da un logo o da una pagina di licenza. Deducetelo dai file installati, dai servizi in esecuzione e dalla configurazione realmente inviata al dispositivo.

Tre domande decidono se l’agente resta

Primo, qualche flusso di lavoro obbligatorio dipende da un modulo che un profilo nativo non può sostituire? I controlli di postura, la policy DNS del tunnel diviso e la visibilità dei flussi sono le risposte abituali, e ciascuna ha un costo di sostituzione diverso. Secondo, quali dati lasciano il dispositivo, verso chi, con quale policy e per quanto tempo? Questa domanda riguarda la configurazione del modulo, non la sua esistenza.

Terzo, chi mantiene la cosa? Un modulo che nessuno aggiorna è un peso, che sia comodo o no. Se la risposta è che ci arriveremo, il confronto onesto è tra una capacità gestita e una non gestita.

Rispondete a tutte e tre prima di confrontare le interfacce, perché un’interfaccia più piccola non è una distribuzione più piccola.

Che cosa documenta il modulo di visibilità e che cosa no

Il modulo di visibilità di rete di Cisco Secure Client è un esempio concreto utile. La sua guida amministrativa per la versione 5.1 descrive la raccolta del contesto di flusso, comprese le informazioni su endpoint e applicazioni, e documenta le policy di raccolta che decidono che cosa viene raccolto.

Questo stabilisce una capacità di un modulo in una versione. Non stabilisce che la vostra organizzazione lo abbia installato, abbia attivato ogni campo o invii il risultato da qualche parte. Sono fatti di distribuzione, e solo la distribuzione può rispondervi.

Trattate la documentazione del fornitore come il limite del possibile e la configurazione del dispositivo stesso come il limite di ciò che accade.

Confrontare un profilo nativo con gli stessi criteri

Un profilo nativo può essere la soluzione approvata e più semplice, e può anche essere un tunnel che lascia cadere un flusso di lavoro che nessuno ha pensato di verificare. La compatibilità dei protocolli, il metodo di autenticazione, la policy di rotte e DNS, la gestione dei guasti e i requisiti di amministrazione sono i cinque punti di confronto, e vanno risposti per entrambe le parti.

Non rimuovete un modulo obbligatorio in silenzio. Ottenete l’approvazione dell’alternativa e documentate dove si sposta ogni responsabilità, perché una responsabilità che non va da nessuna parte è quella che diventa un incidente.

La disponibilità open source, un fornitore familiare e una finestra più piccola sono tre fatti diversi, e nessuno descrive la riservatezza di una configurazione distribuita.

Verificate l’inventario sul dispositivo stesso

Partite dagli artefatti installati e dai servizi in esecuzione invece che da un foglio di calcolo. L’elenco degli artefatti è breve, è locale e chiude discussioni che i documenti di policy non possono chiudere.

Poi correlate ciò che avete trovato con la policy che dovrebbe applicarsi a quel dispositivo.

systemextensionsctl list
ls /opt/cisco/secureclient 2>/dev/null
pgrep -fl vpnagentd

Su Windows le stesse prove arrivano da servizi, processi e dalla chiave di registro del fornitore, e l’elenco dei moduli è di solito visibile nella directory di installazione. Raccogliete i tre output, allegateli alla revisione e chiedete al proprietario di confermare quali di questi componenti sono intenzionali. Quando ogni componente ha uno scopo, un proprietario e un percorso di rimozione, la scelta tra agente e profilo nativo diventa una decisione e non un dibattito.