Vi serve ancora una VPN di sito quando l’applicazione usa mTLS e SSO?
Percorrete i canali che l’accesso all’applicazione non copre mai, poi decidete se l’accesso alla rete privata è ridondante o resta l’unica via verso l’host.
Accedete tramite mTLS, la dashboard si carica, e l’affermazione che la VPN di sito sia ormai ridondante suona ragionevole più o meno per tutto il tempo che serve prima che vi serva un ripristino del database alle due di notte. Il confine TLS dell’applicazione descrive un solo canale. L’host, il database, la destinazione dei backup e l’account cloud portano ciascuno il proprio percorso d’ingresso, la propria identità e il proprio approvatore, e nessuno di essi viene esercitato da un accesso riuscito.
Camminate verso l’esterno dalla schermata di accesso
Accedete come farebbe un utente comune e annotate ogni salto che la richiesta tocca: browser, periferia, listener dell’applicazione, archivio delle sessioni, API di backend. Ogni salto ha un proprietario e una decisione di autenticazione. Ora ripetete il percorso per chi applica patch all’host e per il processo che scrive il backup notturno. Quei percorsi di solito divergono già al primo salto.
Questa divergenza è la domanda che vale la pena affrontare. Una VPN di sito è ridondante solo quando ogni canale di quel secondo percorso ha una politica di ingresso e autorizzazione che sta in piedi da sola.
Cinque canali che l’accesso all’applicazione non copre mai
La tabella qui sotto è un modello di inventario, non una lista di controllo per il rilascio. Riempite la seconda colonna con ciò che il vostro ambiente applica davvero oggi.
| Channel | Access decision to identify |
|---|---|
| Application API | Accepted TLS peer, application identity, permitted operations |
| Operating-system administration | Approved entry path, administrative identity, host permissions |
| Database maintenance | Database identity, protected connection, authorized maintenance role |
| Backup and restore | Service identity, allowed source, access to stored copies |
| Cloud control plane | Account and role permissions governing infrastructure changes |
Condividere un provider di identità non unisce queste autorizzazioni. Un utente che può inviare una richiesta API non è per questo autorizzato a sostituire un disco di macchina virtuale né a ripristinare un database con le credenziali dell’applicazione. Il NIST nel riassunto dell’architettura a fiducia zero tiene l’autenticazione e l’autorizzazione delle risorse separate dalla posizione di rete proprio per questo motivo.
Un ingegnere di supporto che sa leggere un ticket non è per questo autorizzato ad aprire una console sull’host che sta dietro.
Un percorso è reale solo se l’alternativa resta chiusa
Limitare la raggiungibilità ai listener amministrativi privati è un sostituto legittimo di una VPN di sito, purché il limite venga applicato e non solo disegnato. Il guasto abituale è un listener alternativo di cui nessuno si ricordava: un servizio ancora legato a tutte le interfacce, una regola di gruppo di sicurezza aperta per un appaltatore, una porta di gestione raggiungibile da internet.
Controllate i listener, non i diagrammi. Sull’host, elencate ciò che è realmente legato con ss -ltnp e confermate che le porte amministrative stiano su un indirizzo privato. Nella console cloud, leggete le regole in ingresso per la sottorete del carico di lavoro e cercate 0.0.0.0/0 su qualunque cosa amministrativa. Poi provate la connessione dall’esterno del percorso privato, perché è quel test a rispondere alla domanda.
Una sola regola aperta al mondo su SSH annulla ogni argomento che il progetto del tunnel ha prodotto.
Scrivete la mappa prima di confrontare i progetti
Per ogni riga dell’inventario, annotate chi approva le identità, chi aggiorna le regole di accesso, chi rimuove le credenziali quando qualcuno se ne va e chi gestisce il recupero quando il percorso stesso si rompe. Quattro nomi per riga bastano a smascherare le righe in cui la risposta è un account condiviso e una pagina wiki di tre anni fa.
Poi validate un permesso e un rifiuto per canale. Un permesso dimostra che l’identità prevista può raggiungere la risorsa attraverso il percorso previsto. Un rifiuto dimostra che un’identità simile non può, ed è il test che le persone saltano, ed è per questo che i listener alternativi sopravvivono agli audit. Confrontate il progetto proposto con questi risultati, non con la configurazione TLS dell’applicazione, che non ne ha mai esercitato nessuno.
Dove una VPN di sito guadagna ancora il suo posto
Un tunnel o un gateway stretto è la risposta giusta quando una risorsa non ha una propria autenticazione per richiesta: porte di manutenzione dei database, destinazioni dei backup, console dell’hypervisor, gestione fuori banda. Quei listener si fidano della rete, quindi la rete deve essere ciò che autentica il chiamante.
Non è l’unica risposta. Un gateway che termina l’autorizzazione per risorsa può essere più stretto di un tunnel sull’intera sottorete e lascia una traccia di audit migliore di un host di salto condiviso.
Ordine del lavoro: completate l’inventario, chiudete le alternative, validate un rifiuto per riga e solo allora dismettete il tunnel. Se una riga non riesce a produrre un rifiuto, tenete il percorso privato finché non ci riesce.