VPN multi-tenant: gateway condiviso, per tenant o per host
Un tunnel non è isolamento tra tenant. Confrontate un gateway condiviso, gateway per tenant e connessioni per host su mappatura delle identità, routing e dismissione.
Decidete chi ammette un cliente e cosa impedisce a quel cliente di raggiungere le risorse di un altro tenant. Sono due decisioni, e scegliere IPsec, WireGuard o un prodotto mesh non risponde a nessuna delle due. Un tunnel che sale perfettamente può comunque lasciare ogni tenant in grado di raggiungere tutti gli altri, e una revisione che tratta le due cose come la stessa approva il progetto sbagliato. Scrivete prima la mappa cliente-risorsa: amministratori, accesso del supporto, servizi condivisi e i percorsi che devono restare negati.
Partite dalla mappa, non dal prodotto
Quella mappa è il primo artefatto, e ogni scelta qui sotto è solo una decisione su dove vive il confine che la applica. Tenetela rivedibile: una riga per cliente, una riga per servizio condiviso e i percorsi negati scritti per esteso.
Una mappa che nessuno può leggere è una mappa che nessuno applicherà.
Un solo punto di ammissione e il suo problema di mappatura
Ogni collocazione si decide con una sola domanda operativa, e la tabella è l’intero confronto.
| Placement | The question it lives or dies on |
|---|---|
| One shared gateway | How does an admitted identity end up limited to its own resources and its own routing context? |
| A gateway per tenant | Who owns each gateway, its credentials, its policy, its updates and its eventual retirement? |
| A connection per hosted machine | How do enrollment, per-machine policy and replacement work at fleet scale? |
Un gateway condiviso centralizza l’ammissione e concentra il rischio in un solo punto: l’associazione tra l’identità di un tenant e la sua policy. I gruppi o gli indirizzi del tunnel devono risolversi nei permessi di risorsa corretti, e un’etichetta diversa per cliente non impedisce nulla da sola. Contesti di routing separati possono contenere prefissi sovrapposti quando la piattaforma lo supporta e il progetto è completo. Una semplice tabella di routing condivisa non può distinguere due prefissi di destinazione identici solo perché le persone dietro hanno account diversi.
È il test per la maggior parte dei progetti. Due tenant che numerano internamente con 10.0.0.0/8 hanno bisogno di uno stato di routing separato, non di una convenzione di denominazione.
Un gateway per tenant compra confini e sistemi
Un gateway per cliente rende alcuni confini amministrativi facili da spiegare, perché ammissione e policy di quel cliente stanno insieme. Moltiplica però i sistemi che richiedono credenziali, patch, monitoraggio e un proprietario. E non impone un’unica disposizione prescritta degli indirizzi pubblici: la condivisione degli endpoint, la traduzione e il demultiplexing dei protocolli dipendono da ciò che l’implementazione supporta davvero.
Contate i sistemi e le persone prima di contare il guadagno di sicurezza. Un progetto con quattro gateway in più di quanti il team riesca a patcharne non è più isolato nella pratica.
Se il numero di tenant si muove ogni mese, quel modello ha bisogno di un racconto di automazione invece che di un modello predefinito.
Le connessioni per host spostano il lavoro
Una connessione su ogni macchina ospitata non elimina il lavoro operativo, lo sposta nel ciclo di vita della macchina. Registrazione, policy per macchina, rotazione delle chiavi e sostituzione diventano parte del provisioning, e falliscono nella stessa finestra della macchina stessa. Per una manciata di host di lunga durata su reti distinte è spesso giusto, e per una flotta che ha già perso traccia di quale immagine gira dove raramente lo è.
Nominate un ruolo per l’emissione dell’identità, gli aggiornamenti, la rimozione dell’accesso, il monitoraggio e il ripristino in ogni opzione. Poi chiedete cosa succede il giorno in cui un cliente se ne va.
La dismissione fa parte del confronto
La maggior parte dei confronti salta la dismissione. Rimuovere un tenant dovrebbe invalidare le sue credenziali, scartare la sua policy, liberare i suoi indirizzi e il suo stato di routing e lasciare tutti gli altri intatti. Le linee guida NIST sull’architettura zero trust sono il riferimento giusto qui, perché mettono autenticazione e autorizzazione sulla risorsa invece di fidarsi di una posizione di rete, e questo vale anche dentro il segmento del cliente stesso.
Pesate i flussi consentiti e negati, la gestione degli indirizzi sovrapposti e la procedura di dismissione prima di pesare i benchmark dei protocolli. Poi scegliete un trasporto e un metodo di autenticazione adatti al confine scelto. Un nome di prodotto più vecchio, o l’affermazione che ogni azienda debba standardizzarsi su un solo protocollo, non risolve nulla di tutto ciò. La mappa che avete scritto per prima lo fa.