Bastione SSH o accesso VPN diretto: quale politica si applica?

Se gli utenti VPN possano raggiungere i server senza attraversare un host di salto è una questione di politica vestita da rete. Se il bastione esegue un controllo obbligatorio, allora l’accesso alla VPN deve condurre a esso e non aggirarlo. Se l’host di salto si limitava a collegare un segmento prima irraggiungibile, un percorso diretto stretto può essere la sostituzione onesta. Eseguite le verifiche seguenti in ordine e fermatevi alla prima che fallisce, perché quella risposta decide il resto.

Verificate cosa controlla davvero il bastione

Iniziate dalle prove sul presente, non da uno schema del documento di progetto. Guardate la configurazione SSH e il filtro dei pacchetti della destinazione: se la porta 22 in ingresso è accettata solo dall’indirizzo del bastione, l’host di salto è un controllo imposto. Se la stessa porta accetta connessioni da tutto il pool VPN, il bastione era una comodità e l’applicazione vive altrove del tutto. La cronologia dei ticket di solito conferma quale dei due sia esistito prima.

Enunciate il risultato in una frase che nomini il controllo fornito dal bastione: restrizione della destinazione, secondo passaggio di autenticazione, registrazione della sessione o visibilità operativa durante un incidente. È quella frase che la politica sostitutiva deve preservare.

Verificate se la destinazione sa distinguere i percorsi

Le regole sull’indirizzo di origine funzionano solo finché i due percorsi arrivano con indirizzi di origine diversi. Un gateway VPN che maschera il traffico verso la sottorete dei server cancella quella differenza, e allora ogni connessione alla porta 22 sembra provenire dal gateway. La verifica è locale alla destinazione e richiede un attimo: elencate le sessioni SSH stabilite e leggete l’indirizzo del peer di ciascuna.

Quando entrambi i percorsi collassano in un solo indirizzo, la distinzione va fatta prima, tramite le destinazioni che la VPN può inoltrare e i filtri propri del gateway. Aggiungere una regola sulla destinazione in quella situazione crea l’illusione di un confine senza cambiare ciò che arriva.

Verificate cosa conserva davvero ciascun registro

Tre registri diversi descrivono tre eventi diversi, e nessuno sostituisce l’altro. Il registro di connessione della VPN mostra che un’identità è entrata nell’ambito di rete. Il registro di inoltro del bastione mostra un canale TCP che lo lascia verso una destinazione e una porta. Il registro di autenticazione della destinazione mostra che un account ha effettuato l’accesso via SSH. È leggerli insieme che produce una cronologia; leggerne uno solo produce una congettura.

Nessuno di questi registri contiene ciò che è accaduto dentro la sessione cifrata tra client e destinazione. Se la revisione a livello di comando è un requisito, serve un meccanismo di registrazione dispiegato deliberatamente, con regole proprie di trattamento dei dati. Aspettarselo dai registri dell’host di salto è il modo in cui una lacuna di audit resta nascosta finché non conta.

Verificate dove viene applicata davvero la politica

Un’impostazione del client come ProxyJump è una richiesta, non una restrizione. OpenSSH aprirà volentieri una connessione diretta quando la destinazione è raggiungibile, quindi i file di configurazione sui portatili descrivono l’intenzione mentre i firewall decidono l’esito. L’applicazione spetta alle destinazioni consentite del gateway VPN e alle regole di accesso della destinazione stessa, e l’utente non può modificare né l’una né l’altra. Verificate allo stesso tempo i percorsi alternativi: una seconda interfaccia, un listener pubblico, uno strato mesh o un vecchio tunnel tra sedi possono ciascuno ripristinare la scorciatoia appena chiusa.

Configurate comunque ProxyJump, perché rende la rotta approvata quella facile e impedisce al lavoro ordinario di generare eccezioni. Confermate cosa risolve davvero il client prima di fidarvi.

ssh -G app01.lab.internal | grep -iE '^(hostname|port|proxyjump|proxycommand)'

Verificate con un tentativo diretto deliberato

Una politica mai provata è una speranza. Da un client collegato alla VPN, tentate il percorso che ora dovrebbe essere rifiutato, poi tentate quello approvato, e conservate entrambi i risultati. Il tentativo rifiutato è la prova che la modifica ha avuto effetto.

nc -vz -w 3 10.20.30.41 22
ssh -J bastion.lab.internal app01.lab.internal true

Un esito pulito assomiglia a una connessione diretta rifiutata o scaduta verso l’indirizzo della destinazione, seguita da un accesso riuscito all’host di salto e da una voce di autenticazione sul lato destinazione che nomina l’origine supportata. Qualunque altra cosa significa che il confine è ancora poroso, qualunque cosa dica la documentazione. Annotate la data, la regola modificata e i due esiti, poi date al percorso di ripristino un responsabile e una scadenza così che l’accesso di emergenza non diventi silenziosamente la rotta quotidiana.