Dai agli utenti VPN accesso a un solo servizio, non alla sottorete

Un fornitore ha bisogno di un’applicazione web interna e di nient’altro, e la risposta facile è dargli un tunnel verso la sottorete dei server. Funziona fino al giorno in cui la scansiona. Il progetto più stretto richiede più riflessione, perché raggiungibilità, routing e permesso dell’applicazione sono tre controlli separati che devono concordare.

Scrivi il requisito come servizio, non come sottorete

Parti dall’host di destinazione, dal protocollo e dalla porta, poi aggiungi il gruppo di utenti o dispositivi che deve raggiungerlo. Includi la zona DNS privata solo se l’applicazione risolve un nome, e includi un provider di identità solo se il flusso di accesso ne ha bisogno. Tutto il resto è una dipendenza che non hai ancora giustificato.

Una sottorete è un dettaglio implementativo del team di rete, mentre un servizio è ciò che l’azienda ha chiesto e l’unità che può essere revisionata e ritirata.

Se l’elenco delle dipendenze supera tre elementi, probabilmente l’applicazione ha bisogno di una propria discussione di progetto.

Instrada in modo stretto, ma applica altrove

Una rotta o un selettore stretto dice al tunnel quali pacchetti trasportare; non è una politica di autorizzazione. Il filtro del gateway, il firewall dell’host di destinazione e il modello di permessi dell’applicazione stessa sono il luogo in cui si decide l’accesso. Una rotta che copre un solo indirizzo è un buon inizio, e non è il controllo che ferma un utente determinato. È quella separazione che ti permette di cambiare il filtro senza riprogettare il tunnel.

Al contrario, una rotta ampia con un filtro rigoroso può essere legittima, ma solo se tutti gli interessati sanno quale delle due applica la regola.

Documenta esplicitamente il punto di applicazione, altrimenti la modifica successiva lo sposterà per errore.

Verifica l’origine che il servizio vede davvero

La destinazione vede l’indirizzo del pool del client o l’indirizzo del gateway, a seconda che tu traduca. Le regole del firewall dell’host e i log devono corrispondere all’origine reale. Se più utenti condividono un’origine tradotta, nessuna regola per utente su quell’host può distinguerli, e questo è un vincolo di progetto, non un bug.

Scegli la traduzione deliberatamente: semplifica il routing e distrugge l’identità dell’origine, cosa che conta per l’audit e per le regole per utente.

Annota quale delle due hai scelto, accanto alla regola che ne dipende.

L’autorizzazione dell’applicazione non è facoltativa

Raggiungere una porta non concede un ruolo. L’applicazione ha comunque bisogno del proprio accesso e dei propri permessi, perché il livello di rete non può esprimere quali record un utente può modificare. Un servizio che si fida di ogni richiesta dalla sottorete interna trasforma un tunnel stretto in accesso completo per una credenziale compromessa. Il tunnel decide chi può aprire il socket, e l’applicazione decide cosa si può fare con esso.

È qui che il progetto stretto ripaga due volte, perché meno host raggiungibili significa meno punti in cui un errore a livello di applicazione può essere sfruttato.

Tieni la regola di rete e il ruolo dell’applicazione in sistemi separati, e ritirali separatamente.

Dimostra sia il percorso consentito sia quello negato

Connettiti come utente autorizzato ed esegui un’operazione rappresentativa innocua, poi prova una destinazione che dovrebbe essere irraggiungibile. Un progetto che verifica solo la prima metà non è verificato, ed è il test negato che dimostra il progetto. Prova una sessione nuova dopo ogni modifica della regola, e guarda il percorso di ritorno se le richieste arrivano ma le risposte no.

Non disattivare i filtri di inoltro per far passare il test di accettazione, perché questo cambia la cosa che viene testata.

Quando l’utente non ha più bisogno del servizio, ritira l’identità remota e il ruolo dell’applicazione nei rispettivi sistemi, e registra entrambi. La guida all’inoltro di strongSwan copre il lato gateway del percorso.