Cassandra su VPN: accesso separato per client e nodi

Un deployment Cassandra non ha un’unica rete di database universale. Le applicazioni parlano con il servizio client, i membri del cluster parlano tra loro e gli operatori usano interfacce amministrative, e questi tre pubblici non dovrebbero ereditare la raggiungibilità gli uni degli altri. Un percorso privato come una VPN è un buon punto di partenza, ma non è l’identità utente del database e non è la sua politica di crittografia. Trattate la decisione sulla connettività e la decisione sull’autorizzazione come due revisioni separate.

Ciascuno dei tre pubblici riceve la propria risposta, e le sezioni seguenti li trattano in ordine di esposizione.

Tre pubblici, tre decisioni

Identificate ciò di cui ogni gruppo ha realmente bisogno prima di toccare una regola. I client hanno bisogno del listener client e di informazioni sufficienti per raggiungere ogni nodo che può essere loro assegnato, i nodi peer hanno bisogno gli uni degli altri sulla porta internodale, e gli operatori hanno bisogno dell’interfaccia di gestione per ciò che il runbook richiede davvero. Tre elenchi, tre pubblici, tre livelli di fiducia.

L’errore comune è costruire un unico segmento privato piatto e dare per scontato che il confine della VPN faccia il resto. Al suo interno, un’applicazione che raggiunge la porta client di solito raggiunge anche la porta internodale, e gli strumenti amministrativi di un operatore spesso risiedono sullo stesso jump host dell’applicazione. Appiattire tutto questo insieme significa che un’identità applicativa compromessa ha già più portata delle proprie query. Disegnate i tre pubblici come tre righe nel documento di progettazione, ciascuna con la regola che la consente, e le lacune diventano visibili prima che qualcuno le costruisca.

Ciò di cui i client hanno bisogno, e nulla di più

Consentite alle origini applicative previste di raggiungere gli endpoint client per la versione distribuita, e tenete i servizi di cluster e di gestione non correlati fuori da quella portata. Poi controllate come il driver scopre i nodi. Un punto di contatto iniziale raggiungibile non dimostra che ogni indirizzo di nodo scelto successivamente dal driver sia raggiungibile da quel contesto client, perché il driver chiede i peer al cluster e poi si connette agli indirizzi che il cluster annuncia.

Per questo una sola discrepanza di indirizzo privato produce lo schema noto: una prima connessione riuscita seguita da timeout. Configurate deliberatamente gli indirizzi annunciati e il routing del client; pubblicare l’intero cluster su internet per riparare una discrepanza scambia un bug di routing con un’esposizione che non potete riprendervi.

Mantenete anche l’autenticazione al database dell’applicazione e i permessi di ruolo. Un indirizzo VPN condiviso e tradotto può rappresentare molti utenti o servizi, quindi non sostituisce mai identità di database distinte.

Crittografate separatamente client-versus-nodo e internodale

La documentazione di sicurezza di Apache tratta la crittografia client-versus-nodo e internodale come configurazioni separate, e abilitarne una non abilita l’altra. Quella distinzione vale ancora dentro una VPN, perché il tunnel protegge il proprio segmento e non si estende automaticamente dal processo applicativo al processo del database né tra ogni coppia di membri del cluster.

Una configurazione che attiva entrambe esplicitamente, invece di ereditare un valore predefinito di modello, assomiglia più o meno a questo:

client_encryption_options:
  enabled: true
  optional: false
server_encryption_options:
  internode_encryption: all

Nelle configurazioni server che consentono la crittografia client opzionale, l’accettazione di TLS può coesistere con l’accettazione di connessioni non crittografate, quindi leggete la politica effettiva e non l’intenzione. Pianificate nomi dei certificati, distribuzione della fiducia e rinnovo per gli endpoint che ogni client contatta davvero; sostituire un nome host con un indirizzo IP cambia il controllo di identità del client, non solo la sua rotta.

Mantenete l’amministrazione sul proprio percorso

Il traffico internodale ha bisogno dell’insieme di peer consentito e di una propria politica di protezione. L’accesso amministrativo, incluso JMX dove viene usato, ha bisogno di un pubblico separato e di una propria autenticazione. Un’applicazione autorizzata a emettere query ordinarie non ha per questo bisogno di ogni capacità di gestione, e l’inverso è peggio: un percorso amministrativo esposto al segmento applicativo è la strada più breve da un bug a una ricostruzione. Scrivete separatamente questi due pubblici e nominate i loro responsabili, perché di solito sono team diversi le cui regole sono state unite per caso.

Mantenete allineate le regole cloud effettive, le regole host e la configurazione del listener. Un listener privato può comunque essere esposto tramite una traduzione o un proxy involontari, e una regola pubblica ampia può restare in silenzio accanto a una regola VPN stretta finché qualcuno non verifica entrambe insieme.

Dove gli operatori hanno davvero bisogno di un percorso di gestione, dategli un responsabile nominato e una durata delle credenziali più breve di quella dell’applicazione. Questo mantiene visibile la delega quando la persona successiva eredita il cluster.

Ciò che il progetto promette

Validate tutte tre le promesse con ruoli reali e non solo con test di connettività. Un’applicazione approvata dovrebbe completare il lavoro consentito e nulla di più, un’origine esclusa dovrebbe fallire all’ingresso client, e un’identità applicativa dovrebbe essere rifiutata sui percorsi amministrativi riservati. Aggiungete la riconnessione del client e la selezione del nodo allo stesso test di rilascio, perché è lì che emergono gli errori di scoperta.

Concludete con tre frasi nel documento di progettazione: quali client possono interrogare, quali nodi possono comunicare e quali operatori possono amministrare. Essere dietro una VPN è un’informazione di topologia utile, ma non è la risposta a nessuna di quelle tre domande.