Ha ancora bisogno di una VPN se usa un Identity-Aware Proxy?
Un proxy di autenticazione autentica una singola richiesta; una VPN instradata ammette un client in una rete. Confronti le operazioni reali, il flusso del client e i percorsi alternativi.
L'assunto è questo: una volta che un proxy che conosce l'identità si mette davanti alle applicazioni interne, la VPN è solo decorazione e il client può andarsene. Vale per un caso ristretto, un'applicazione HTTPS interattiva usata da una persona in un browser, e fallisce silenziosamente ovunque altro. Un proxy autorizza una richiesta nei confronti di una risorsa; una VPN ammette un client in un perimetro di rete, e questi due confini raramente coincidono. Prima di dismettere un tunnel, confronti le operazioni che le sue persone svolgono davvero, non le etichette di prodotto sul diagramma.
Le due porte autorizzano cose diverse
Una porta applicativa decide se questa richiesta, da questa identità, può raggiungere questa risorsa protetta. La panoramica di Identity-Aware Proxy di Google descrive esattamente questa forma: uno strato di autorizzazione centrale davanti alle applicazioni HTTPS, guidato da un ruolo IAM. Il confine è la risorsa, e l'unità di accesso è la richiesta. Una VPN instradata fa qualcosa di più grossolano e ampio: ammette un client in un perimetro di rete definito, dopodiché l'applicazione decide ancora cosa può fare quel client.
Nessuno dei due modelli implica l'altro. Superare la porta non dice nulla sulla lettura di un record specifico, ed essere sulla rete non dice nulla sul permesso di agire.
Ciò che il proxy non copre, e che la VPN copre
Le sessioni SSH, i client di database, i broker di messaggi e i nomi host interni che nessun browser apre mai non diventano raggiungibili perché esiste un proxy web. Ognuno parla il proprio protocollo, e ognuno ha bisogno o del proprio percorso autenticato o di una rete che lo trasporti. È il divario che le persone scoprono il primo giorno di una migrazione, di solito da un ingegnere di turno con un portatile che non risolve più un nome host.
Il divario inverso è altrettanto reale. Una VPN che ammette un client in una sottorete non autentica la persona al suo interno, e un dispositivo compromesso su quella sottorete eredita ciò che la rete consente. Se il requisito è l'autorizzazione per richiesta con un'identità verificabile, il solo instradamento non può produrla. La maggior parte delle organizzazioni finisce per gestire entrambi, e la domanda interessante è quali risorse ciascuno sia autorizzato a coprire.
Il flusso del client decide più del diagramma di architettura
Un accesso dal browser con reindirizzamento e una sfida MFA occasionale è una buona esperienza per chi clicca su un segnalibro. Un'attività cron, una CLI o un agente di build non ha un browser e non può rispondere a un prompt interattivo, quindi ha bisogno di un percorso non interattivo documentato o del tunnel. La scoperta di questo requisito avviene di solito dopo l'approvazione del progetto.
Conti i client prima di contare le applicazioni. Una dashboard può servire cento persone; una porta di database può bloccare un intero team.
La postura del dispositivo non è una proprietà di nessuna delle due porte
Installare un client VPN non è un controllo di conformità, e un progetto basato sul browser non è automaticamente incapace di rispettare la politica sui dispositivi gestiti. Entrambi possono integrarsi con segnali di postura, ed entrambi possono essere distribuiti senza. Chieda quale applicazione esiste, a chi appartiene la politica e cosa succede a un dispositivo che la viola, invece di dedurlo dalla forma del prodotto.
La stessa cautela vale per la rimozione dell'accesso. Eliminare un'appartenenza a un gruppo nel proxy e revocare un certificato per il tunnel sono operazioni diverse con ritardi diversi, e una delle due viene di solito dimenticata durante l'uscita.
Trovi i percorsi alternativi prima di dismettere qualsiasi cosa
Un'origine non protetta dietro il proxy, un secondo nome host che lo aggira o una rotta privata ampia ereditata da un progetto precedente decideranno quale porta è realmente in vigore. Testi un'operazione consentita e una negata attraverso il client reale, non attraverso la console, e le testi da un dispositivo che non è mai stato registrato. Il caso negato è quello che le dice se la porta sta facendo qualcosa.
Poi scriva il passaggio di consegne: registrazione, aggiornamenti, rimozione dell'accesso e il percorso di ripristino per qualcuno chiuso fuori alle 2 di notte. Rimuovere un prompt o un'applicazione client sposta la responsabilità tra i team; non cancella la responsabilità.
Se decide questa settimana, parta da un elenco di operazioni invece che da un elenco di prodotti, segni quali può eseguire un browser e lasci che il resto giustifichi l'accesso di rete che sopravvive.