ALB interno con nome DNS pubblico: è davvero esposto?

Eseguite una query DNS pubblica contro un bilanciatore di carico interno e potreste ricevere un indirizzo privato, cosa che sembra una configurazione errata finché non verificate a cosa serve il record. AWS documenta che i nomi dei bilanciatori interni possono essere risolvibili pubblicamente mentre i loro nodi contengono solo indirizzi privati. Il resolver ha risposto dove si trova il servizio; non ha creato una rotta, non ha aperto un gruppo di sicurezza né ha autenticato nessuno. Se quella risposta sia un problema dipende da fatti che potete verificare in ordine.

Passo uno: leggete lo schema, non l'IP

Il campo schema è la dichiarazione del bilanciatore stesso sul proprio confine. aws elbv2 describe-load-balancers --names app-internal restituisce un Scheme con valore internal o internet-facing, più un tipo di indirizzo per IPv4 o doppio stack. Un bilanciatore rivolto a internet può comunque inoltrare a destinazioni private, quindi vedere indirizzi backend privati non dimostra nulla sul front end.

Annotate lo schema prima di guardare qualsiasi altra cosa, perché ogni giudizio successivo dipende da esso. Indica anche quali controlli esistono, dai gruppi di sicurezza e dalle regole del listener all'insieme di funzioni di quel tipo di bilanciatore. Uno schema copiato da un vecchio screenshot della console è peggio di nessuna nota. Rileggetelo dall'API e incollate il valore nel ticket.

Passo due: vedete in cosa si risolve il nome

Interrogate dall'esterno della VPC con dig +short app-internal-1234567890.eu-west-1.elb.amazonaws.com e annotate se le risposte sono in 10.0.0.0/8, 172.16.0.0/12 o 192.168.0.0/16. Una risposta privata da un resolver pubblico è il comportamento atteso per un nome di bilanciatore interno; non è prova che l'indirizzo sia raggiungibile da internet.

Risolvete lo stesso nome dall'interno della VPC e confrontate. Se le due risposte differiscono, siete davanti a una denominazione split-horizon, e quella differenza è un dettaglio di progettazione, non una fuga.

Passo tre: elencate i percorsi che possono raggiungerlo

Un indirizzo privato è raggiungibile ovunque esistano una rotta e una regola di sicurezza. Elencateli deliberatamente: VPN site-to-site, VPN client, VPC peering, collegamenti transit gateway, Direct Connect e qualsiasi proxy o bastion all'interno della VPC. Uno di essi è il percorso previsto, e gli altri sono quelli che cercherebbe un attaccante.

Poi controllate i controlli su ogni percorso: gruppi di sicurezza sul bilanciatore, ACL di rete sulle subnet e il routing che fa esistere il percorso. La maggior parte dei casi segnalati di servizio interno esposto si risolve qui, o perché esisteva un peering non previsto o perché il percorso era previsto e l'applicazione non aveva autenticazione.

Passo quattro: provate il listener e l'applicazione separatamente

Provate a connettervi da una rete che non dovrebbe raggiungere il servizio e confermate che non potete. Poi provate da una che dovrebbe, e confermate che raggiungete un listener. Questi due risultati separano la raggiungibilità di rete dal comportamento dell'applicazione, e sono l'unica prova che conta per la questione dell'esposizione.

Un listener raggiungibile non è la stessa cosa di un'applicazione accessibile. Controllate il certificato TLS e la politica del protocollo, poi l'autenticazione e l'autorizzazione dell'applicazione stessa. Uno strumento interno che accetta qualsiasi chiamante sulla VPN aziendale è esposto a ogni portatile compromesso su quella VPN, che è un rischio diverso da uno rivolto a internet ma resta un rischio.

Ricordate che i controlli variano per tipo. I firewall a livello applicativo si collegano a una famiglia di bilanciatori e non all'altra, quindi verificate cosa è realmente disponibile per lo schema e il tipo davanti a voi invece di presumere parità.

Passo cinque: decidete se il nome stesso conta

La risolvibilità pubblica può rivelare un nome di servizio, una regione e un intervallo di indirizzi. Trattatelo come una questione di divulgazione di informazioni con risposta di policy, non come un incidente automatico: tenete i termini commerciali sensibili fuori dai nomi delle risorse e annotate la divulgazione nel registro dei rischi se la convenzione di denominazione rivela più di quanto vogliate.

Se l'organizzazione desidera un'esperienza di denominazione privata, una zona ospitata privata può servire un alias che si risolve solo nelle VPC associate. Questo cambia il nome che gli utenti vedono; non rende segreto il nome generato dal provider e non rimuove alcun percorso di rete.

Non provate a fissare gli indirizzi per nascondere la risposta. Gli indirizzi del bilanciatore cambiano, il fissaggio rompe le abitudini di validazione TLS, e il controllo che vi serve davvero è chi può stabilire la connessione e cosa l'applicazione esige da lui. Verificate i quattro fatti, annotateli, e la domanda smette di essere ambigua.