TLS nativo, inoltro SSH o VPN per un singolo servizio cloud

La domanda raramente è se crittografare qualcosa tra due macchine cloud; è quale interfaccia si crittografa e chi verifica l’identità di chi. Inizio queste conversazioni dal servizio anziché dal diagramma di rete, perché il servizio sa già di cosa ha bisogno. Tre confini coprono la maggior parte dei casi: il TLS proprio dell’applicazione, una singola porta TCP inoltrata via SSH e un overlay instradato che dà un indirizzo a ogni partecipante. Non sono classificati per forza, ma per quanto del problema coprono.

Iniziate dal servizio, non dalla rete

Procedete dal processo verso l’esterno. Quale protocollo parla, quale nome verificherà il client e chi è autorizzato ad aprire una connessione? Queste tre risposte eliminano opzioni più rapidamente di qualsiasi tabella comparativa, e la configurazione del servizio di solito le fornisce in un paio di minuti.

Prendete una piccola API interna che già serve HTTPS sulla porta 8443 con un certificato per api.internal.example. ss -ltnp sull’host mostra a cosa si lega, e openssl s_client -connect 127.0.0.1:8443 -verify_hostname api.internal.example mostra se il certificato è valido per il nome che il client userà davvero. Se entrambi sono sani, il servizio può proteggere il proprio flusso e resta solo la raggiungibilità. È un problema molto più piccolo che costruire una rete.

Passo 1: il servizio protegge se stesso?

È l’opzione da scegliere quando si adatta, e si adatta più spesso di quanto i team presuppongano. La crittografia del servizio copre l’intero percorso tra client e server, compreso ogni salto intermedio, che nessun tunnel attorno al centro migliora. Configurate il nome atteso e la fiducia in modo esplicito invece di affidarvi a ciò che l’archivio predefinito del client contiene per caso.

Crittografia e raggiungibilità restano controlli separati, ed è la loro fusione il punto in cui questa opzione sbaglia. Un servizio TLS su un listener pubblico senza restrizioni accetta ancora tentativi di connessione da chiunque, quindi il listener e le regole di rete vanno delimitati indipendentemente dal fatto che il payload sia protetto. Poi controllate le dipendenze, perché un’API su TLS non dice nulla sull’endpoint di scoperta, sulla porta di amministrazione o sul canale di trasferimento massivo accanto. Ognuno ha bisogno della propria risposta, e un solo fratello non protetto basta a rendere l’intero confine una finzione.

Passo 2: una sola porta TCP è l’intero requisito?

Quando il requisito è davvero una sola porta TCP, un inoltro è la cosa più piccola che funziona. Un inoltro locale SSH trasporta quella porta attraverso una connessione autenticata già esistente.

La forma è ssh -N -L 8443:127.0.0.1:8443 [email protected], e il dettaglio che conta è l’indirizzo di destinazione: 127.0.0.1 viene risolto sul lato remoto, quindi la connessione al servizio si apre dal bastion e non dal vostro portatile. Legate il listener locale in modo stretto come -L 127.0.0.1:8443:... per non pubblicare il servizio sulla vostra rete locale per errore. Sul lato server, limitate ciò che l’account può inoltrare invece di fidarvi del buon comportamento del client. PermitOpen, AllowTcpForwarding local e un GatewayPorts no predefinito sono le tre impostazioni che trasformano un relè generico in un canale specifico.

Il contratto è stretto in entrambe le direzioni. SSH protegge il proprio canale, e un ulteriore salto dal bastion a un’altra applicazione richiede una propria protezione. Un servizio in ascolto solo sul loopback del bastion ha un’esposizione molto diversa da uno raggiunto attraverso un’altra rete, e l’inoltro non lo cambia. Mantenete l’autenticazione e i controlli TLS dell’applicazione invece di trattare il tunnel come loro sostituto.

Funziona bene per una connessione con un proprietario. Su scala diventa un sistema: conflitti di porte locali, supervisione, rotazione delle chiavi e la domanda su chi riavvia l’inoltro dopo un riavvio.

Passo 3: l’instradamento è il requisito reale?

Quell’elenco è il costo onesto dell’opzione più piccola, ed è per questo che i team finiscono per sostituire una manciata di comandi in background dimenticati con qualcosa di gestito. La sostituzione non è automaticamente una VPN. Se il requisito è ancora una sola porta TCP, un inoltro supervisionato con un proprietario documentato costa meno da gestire di un overlay e fallisce in modi che potete vedere. Misurate la proprietà operativa prima di misurare l’eleganza.

L’instradamento diventa la risposta giusta quando l’instradamento è il requisito. Diverse applicazioni che necessitano di connettività IP ordinaria, protocolli che un inoltro TCP non può trasportare o servizi che si spostano tra host puntano tutti nella stessa direzione.

Un overlay dà ai partecipanti un indirizzo e una rotta, poi inizia il lavoro vero: intervalli non sovrapposti, proprietà delle rotte, DNS, registrazione, revoca e cosa succede quando un peer scompare. Niente di tutto ciò arriva con l’indirizzo. Un peer ammesso all’overlay non è nemmeno automaticamente autorizzato per ogni operazione sulla destinazione, quindi l’autenticazione a livello di servizio resta.

Cosa possedete dopo

Due cose appartengono al registro che lasciate. La prima è l’identità che il client deve verificare, perché ciascuno di questi confini peggiora in silenzio appena un controllo del nome viene allentato per far funzionare qualcosa. La seconda è il passo di rimozione: quale chiave, quale regola o quale rotta scompare quando l’accesso termina, e chi lo esegue.

Il percorso termina dove è iniziato, al servizio. Scegliete il confine che copre il traffico reale e verifica i peer che intendevate verificare, poi annotate come l’accesso viene aggiornato, monitorato e rimosso. La referenza OpenSSH è il posto dove confermare le opzioni di inoltro prima di promettere un contratto stretto. Se non riuscite a descrivere il passo di rimozione in una frase, il confine è più grande del problema.