Le regole di AWS Client VPN stanno sulla risorsa, non sulla sottorete

Il personale deve raggiungere un'applicazione nella VPC e non deve raggiungere il listener del database sulla stessa istanza, così qualcuno aggiunge una seconda sottorete pubblica per l'endpoint VPN e dichiara soddisfatto il requisito. La posizione della sottorete cambia routing e disponibilità. Non concede né nega una singola porta. L'autorizzazione che esprime il requisito vive nella destinazione, nel gruppo di sicurezza della risorsa, e il confine VPN fornisce la maniglia a cui quella regola si riferisce.

La posizione della sottorete è routing, non autorizzazione

Dove si trova l'associazione di rete dell'endpoint decide quale tabella di routing trasporta il traffico dei client e quali zone di disponibilità sopravvivono a un guasto. Non dice nulla su quale porta, su quale istanza, quel traffico possa raggiungere. Due client associati alla stessa sottorete arrivano comunque con la stessa identità di origine, e la risorsa non può distinguerli dal nome della sottorete.

Parti invece dal requisito: chi chiama, quale risorsa, quale porta di servizio e in quale direzione. Poi scegli il modello di regola in grado di esprimere quei quattro elementi nella destinazione. Questa impostazione di solito elimina del tutto la sottorete aggiuntiva dal progetto.

Il gruppo di associazione di Client VPN è la maniglia

Per un endpoint AWS Client VPN associato a una sottorete, la disposizione documentata è precisa. Applica il gruppo di sicurezza previsto alle associazioni di rete di destinazione dell'endpoint, quindi consenti il traffico necessario nel gruppo di sicurezza della risorsa usando quel gruppo Client VPN come origine.

Concretamente, il gruppo dell'istanza applicativa consente la porta applicativa dal gruppo di associazione, e nulla di più. La procedura di accesso alla risorsa di AWS descrive questa relazione, e vale la pena mantenere la stessa policy di gruppo su ogni sottorete a cui l'endpoint si associa, perché un'associazione obsoleta con un gruppo diverso allarga silenziosamente il confine.

Quella regola non autentica nessuno. L'accesso è un controllo separato, e la rotta verso la risorsa è un terzo. Tutti e tre devono valere prima che arrivi una richiesta. Quello che fallisce decide quale correzione è giusta, e cambiare la regola è la risposta corretta solo per il primo.

Ciò che un solo gruppo di associazione non può distinguere

Ogni client dietro lo stesso gruppo di associazione raggiunge la risorsa come la stessa origine di gruppo di sicurezza. Due utenti con ruoli diversi sono indistinguibili a quel livello, comunque sia nominato o etichettato il gruppo. L'autorizzazione dei gruppi esterni di Client VPN limita l'accesso per prefisso di destinazione per un gruppo di directory o SAML, il che è più grossolano di un ruolo della risorsa e va trattato come un confine di rete, non come un sistema di identità.

Le distinzioni più fini spettano all'applicazione. Un listener del database che deve restare chiuso alla maggior parte del personale è meglio protetto dal non essere affatto raggiungibile sul prefisso consentito che dallo sperare che l'appartenenza al gruppo resti ordinata.

Rinominare il gruppo non crea un'identità, e duplicarlo per team non fa che moltiplicare le associazioni da verificare.

Non copiare quella regola in ogni progetto VPN

Un gateway EC2 VPN autogestito, un apparato di ispezione instradato e un Client VPN gestito sono tre percorsi di pacchetto diversi. Stabilisci quale indirizzo di origine raggiunge davvero la risorsa, se avviene una traduzione nel mezzo e quali meccanismi di riferimento il servizio supporta su quel percorso.

Inoltrare il traffico attraverso un dispositivo intermedio non conserva un riferimento al gruppo di sicurezza di origine come fa il traffico diretto da istanza a istanza. AWS documenta che tali progetti possono richiedere gli indirizzi privati di origine o le CIDR appropriati invece di un riferimento di gruppo. La procedura del Client VPN gestito non è prova che il gruppo collegato di ogni gateway funzioni come token di identità universale per i pacchetti inoltrati.

Un solo salto NAT sul percorso basta a rompere l'ipotesi, e il guasto sembra una regola presente che non corrisponde mai.

Esamina il confine effettivo

Leggi ogni gruppo di sicurezza collegato alla risorsa, perché le regole di autorizzazione si sommano e una regola stretta non annulla una più ampia su un altro gruppo. Poi controlla l'ACL di rete, il firewall dell'host e l'autorizzazione propria dell'applicazione, che sono livelli separati con errori separati.

Chiudi con una richiesta consentita e una deliberatamente esclusa verso la stessa risorsa. La coppia dimostra il confine, mentre una singola connessione riuscita dimostra solo che qualcosa è aperto. Conferma la rotta, l'origine effettiva e la porta di servizio prevista, non la sottorete che contiene l'endpoint.

Ordine di lavoro: scrivi il requisito in quattro parti, collega il gruppo alle associazioni, limita la regola della risorsa alla porta, verifica un'autorizzazione e un rifiuto, e solo dopo valuta di dividere le sottoreti per motivi di routing.