Migrare una VPN: licenze, funzioni e policy in un unico registro

Le sessioni che funzionano ancora sul vecchio concentratore sembrano una prova che la migrazione sia quasi finita. Sono una sola voce dell’inventario, e la meno interessante. Ciò che serve al passaggio è un registro che leghi il gateway di destinazione, il client supportato, il diritto acquistato e la policy di ammissione applicata in un unico artefatto di cui qualcuno è responsabile. Senza di esso, la migrazione è una serie di ipotesi che, prese singolarmente, sembrano ragionevoli.

Quattro colonne, non una lista di controllo

Che cosa l’hardware può sopportare, che cosa il contratto consente e che cosa l’insieme di regole ammette sono tre domande separate, e mescolarle produce un piano che nessuno può verificare. Tenetele in colonne separate e fate sì che ciascuna citi la propria fonte. Un dispositivo che accetta una connessione dimostra che un dispositivo può connettersi, e non spiega nulla sull’ambito delle funzioni né sulla base di conteggio. Tre colonne che non concordano sono molto più utili di un paragrafo che suona sicuro.

Il registro è completo quando tutte e quattro le colonne sono compilate da qualcuno che ha il diritto di compilarle. Una colonna firmata dal proprietario sbagliato è una voce con una data sopra.

Piattaforma e diritto

Registrate il gateway supportato, i sistemi operativi del client, il percorso di autenticazione e gli strumenti di gestione. Non tenete in vita un client obsoleto solo perché il suo vecchio profilo si apre ancora, dato che quel profilo è un’affermazione di compatibilità che il fornitore potrebbe non onorare più. Confrontate la dichiarazione di supporto attuale con la versione che intendete distribuire.

Per il diritto, registrate il prodotto, il tipo di licenza, la durata e la base di conteggio, poi riconciliatelo tramite il proprietario dell’account. Dedurre diritti da un contatore storico di sessioni è il modo in cui un’organizzazione scopre una carenza dopo il passaggio invece che prima.

Le guide all’ordine dei fornitori mostrano perché queste distinzioni contano. La guida all’ordine di Secure Client di Cisco, per esempio, separa i livelli Advantage, Premier e VPN Only, ciascuno con la propria misura e il proprio ambito di funzioni. Usate l’accordo attuale invece di tradurre meccanicamente una vecchia etichetta.

Funzioni e policy applicata

Elencate le capacità di cui la distribuzione ha davvero bisogno: modalità tunnel consentite, valutazione dei dispositivi, integrazione dell’autenticazione e qualsiasi altro modulo. Verificate supporto e diritto per ciascuna separatamente, perché una funzione può essere supportata e senza licenza, oppure con licenza e non supportata nella versione scelta. Conta solo una riga che risponda sì a entrambe le domande.

Quando la destinazione è un ASA, la colonna delle funzioni si legge dal dispositivo e non dal contratto, quindi catturate il gateway prima del giorno del passaggio. show vpn-sessiondb summary fornisce l’inventario delle sessioni attive e i conteggi su cui si misura il vostro diritto, show vpn-sessiondb detail anyconnect mostra quale tipo di client e quale profilo ha realmente usato ogni sessione attribuita, e show running-config webvpn cattura la configurazione del gateway da cui dipendono quelle sessioni, ed è l’unica parte del registro che nessun documento di licenza può contenere.

show vpn-sessiondb summary
show vpn-sessiondb detail anyconnect
show running-config webvpn

Dopo il passaggio, eseguite gli stessi tre sul nuovo gateway e confrontateli con le copie catturate. Che i conteggi delle sessioni si muovano è atteso; un tipo di client o una stanza webvpn che compare da un lato e non dall’altro è il risultato, e appartiene al registro con una spiegazione, non a un commento di ticket. Salvate le catture grezze oltre alle differenze, perché il prossimo revisore vorrà vedere che cosa è stato confrontato. Presso un altro fornitore l’equivalente è la tabella delle sessioni e l’esportazione dei profili di quella piattaforma, in un formato che non coinciderà, quindi confrontate le domande che gli vengono poste e non il testo.

Poi associate utenti e dispositivi alle regole della destinazione, ai permessi delle risorse e al comportamento di rifiuto. Una licenza che abilita una funzione non è una configurazione che la esercita, e il divario fra le due è dove vivono la maggior parte delle sorprese della migrazione.

Scrivete i casi di rifiuto con la stessa cura dei casi consentiti. Un piano che dimostra solo che un amministratore può connettersi ha testato il percorso più facile e nessuno dei confini.

Accettate su entrambi i lati della decisione

Prima del passaggio, eseguite un piano di accettazione approvato sui tipi di client previsti, sui metodi di autenticazione e sulle risorse. Includete un dispositivo o un’identità che deve essere rifiutata, e confermate quale regola l’ha selezionata e che cosa può raggiungere la sessione risultante. Concordate i casi di diniego prima che si apra la finestra di cambiamento, così che nessuno possa scartarli in silenzio sotto pressione di tempo. Un piano senza alcun caso di diniego ha testato il percorso felice e nient’altro.

Mantenete un percorso di rollback e una via di gestione che non dipenda da ciò che viene migrato. Conservate in sicurezza la configurazione e i registri delle identità, e lasciate indietro le impostazioni crittografiche obsolete invece di portarle avanti. Non incollate mai identificatori di licenza o registri utente in note pubbliche.

Fate firmare al proprietario il diritto e la mappatura della policy insieme. Il registro finito risponde a due domande insieme: che cosa l’organizzazione ha licenza di distribuire, e quali regole ammettono e vincolano realmente i suoi utenti.