VPN sempre attiva: percorso, autorizzazione e sessione separati

Tenere un tunnel aperto giorno e notte è una scelta di progetto che ha una versione ragionevole e una versione negligente. Una filiale che ha bisogno di un’applicazione centrale tutto il giorno, più un processo di backup notturno, ha una ragione. Un portatile lasciato connesso tre giorni in una camera d’albergo è un incidente.

Entrambi mostrano la stessa icona verde e rispondono allo stesso modo se si chiede da quanto tempo il tunnel è attivo. Quel numero non è quello interessante. Conta ciò che la connessione tiene disponibile, per chi e cosa la chiude davvero.

Tre orologi che corrono separati

Il primo stato è il percorso. Un tunnel e le sue politiche rendono raggiungibile un insieme di servizi, e un collegamento senza traffico può restare pronto per la richiesta successiva. Quanto a lungo resti pronto è una decisione di implementazione, non un timer universale.

Il secondo stato è l’autorizzazione. Un’identità o un dispositivo accettato può essere autorizzato a usare quel percorso. Questa autorizzazione dovrebbe cambiare quando cambia un ruolo, un dispositivo sparisce o si sospetta una compromissione, ed è indipendente dal fatto che i pacchetti scorrano.

Il terzo stato è la sessione propria dell’applicazione. Un client di database, un desktop remoto o un’applicazione web si autenticano separatamente e mantengono il proprio stato. Chiudere il tunnel non termina necessariamente nessuna di esse.

Una revisione che tratta questi tre come una sola domanda finisce a discutere di timer di inattività. Ciascuno può essere sano o rotto per conto proprio, e un riscontro su uno dice poco sugli altri. Una lista di tre righe è meglio di un dibattito su un solo valore di attesa. Scrivete la risposta per ogni stato separatamente.

Il tunnel è un percorso, non un distintivo

Un tunnel stabilito è prova che esiste un percorso protetto tra due estremi. Non è prova che ogni processo dietro qualsiasi estremo debba raggiungere ogni servizio dall’altra parte.

Le linee guida a fiducia zero del NIST dicono lo stesso dalla direzione opposta: la posizione di rete non va trattata come fiducia implicita. Il collegamento di una sede è un fatto di trasporto, e l’autorizzazione per un host a usare un’applicazione è una decisione separata con il proprio responsabile.

Un peer compromesso può comunque tentare azioni dannose attraverso servizi che è autorizzato a raggiungere. Filtro e monitoraggio riducono rischi specifici senza cancellare le conseguenze di una compromissione dell’estremo. Progettate per il percorso e autorizzate per il servizio.

Giustificare un collegamento di sede permanente

La versione difendibile del sempre attivo nomina con precisione il suo scopo. Quali sorgenti, quali destinazioni, quale direzione e chi possiede ogni voce. Un firewall di filiale che consente a ogni host della filiale ogni sottorete centrale non ha tenuto un collegamento per uno scopo nominato; l’ha tenuto per tutto ciò che qualcuno penserà dopo.

Dove un peer non può raggiungere il livello di fiducia richiesto, restringete il confine o cambiate la disposizione. Contare su una disconnessione manuale occasionale è un controllo di processo, e i controlli di processo sono meno affidabili proprio quando un incidente li rende scomodi.

Conservate la giustificazione con la configurazione. Un’eccezione permanente con uno scopo scritto può essere riesaminata e ritirata. Una senza scopo diventa permanente per impostazione predefinita.

Cambiare chiavi non è revocare

Sostituire le chiavi secondo un calendario mantiene il ciclo di vita della protezione. Rinnova il materiale e preserva la riservatezza. Non toglie il diritto di un estremo.

Se l’estremo conserva ancora credenziali valide e una politica di accesso che lo accetta, la negoziazione successiva ripristina lo stesso percorso consentito. Per questo una rotazione oraria delle chiavi non è una risposta a un dispositivo smarrito: anche il dispositivo smarrito ruota, finché la sua identità è ancora fidata. Controllate il diritto prima del calendario. La rotazione è igiene e la revoca è una decisione di accesso.

La revoca è un altro meccanismo con la propria latenza: un certificato revocato, un account disabilitato, un gruppo cambiato, una regola di rete rimossa. Ognuno agisce in un punto diverso e si comporta diversamente con le sessioni già stabilite.

Chiudere ciò che è già in corso

Chiedete cosa fa l’implementazione con le sessioni stabilite quando l’accesso viene rimosso. Può terminarle, attendere la scadenza o applicare un comportamento documentato nel mezzo. Non date per scontato che il cambio di ammissione di domani chiuda la connessione applicativa di oggi.

Per l’accesso interattivo, mettete i limiti di sessione e le regole di inattività nelle mani dei responsabili di identità e VPN, non solo del team di rete. Per un servizio di sede, stabilite la procedura che manutenzione, un guasto o un incidente di sicurezza usa per disattivare l’accesso.

Poi provate tre esiti: il lavoro consentito funziona ancora, un servizio non correlato viene negato e la procedura di rimozione produce il risultato documentato. Un progetto sempre attivo è accettabile quando scopo, autorizzazione e capacità di spegnimento sono tutti scritti ed esercitati. Altrimenti è una comodità che è sopravvissuta alla sua ragione.