Cassandra prin VPN: acces separat pentru clienți și noduri

O implementare Cassandra nu are o singură rețea universală de baze de date. Aplicațiile vorbesc cu serviciul de client, membrii clusterului vorbesc între ei, iar operatorii folosesc interfețe administrative, iar aceste trei categorii de public nu ar trebui să moștenească accesibilitatea unele de la altele. O cale privată precum un VPN este un punct de plecare bun, dar nu este identitatea de utilizator a bazei de date și nici politica ei de criptare. Tratează decizia de conectivitate și decizia de autorizare ca două evaluări separate.

Fiecare dintre cele trei categorii de public primește propriul răspuns, iar secțiunile de mai jos le iau în ordinea expunerii.

Trei categorii de public, trei decizii

Identifică ce are nevoie fiecare grup înainte de a atinge o regulă. Clienții au nevoie de listenerul de client și de suficiente informații pentru a ajunge la fiecare nod care le poate fi repartizat, nodurile pereche au nevoie unele de altele pe portul internode, iar operatorii au nevoie de interfața de administrare pentru ceea ce cere efectiv runbook-ul. Trei liste, trei categorii de public, trei niveluri de încredere.

Greșeala obișnuită este să construiești un singur segment privat plat și să presupui că granița VPN face restul. În interiorul lui, o aplicație care ajunge la portul de client ajunge de obicei și la portul internode, iar instrumentele administrative ale unui operator stau adesea pe același host de salt ca aplicația. Aplatizarea lor împreună înseamnă că o identitate de aplicație compromisă are deja o acoperire mai mare decât interogările ei. Desenează cele trei categorii de public ca trei rânduri în documentul de proiectare, fiecare cu regula care o permite, iar lacunele devin vizibile înainte ca cineva să le construiască.

De ce au nevoie clienții, și nimic mai mult

Permite sursele de aplicație vizate către punctele finale de client pentru versiunea implementată și ține serviciile de cluster și de administrare necorelate în afara acelei acoperiri. Apoi verifică modul în care driverul descoperă nodurile. Un punct de contact inițial accesibil nu dovedește că fiecare adresă de nod pe care driverul o selectează ulterior este accesibilă din acel context de client, pentru că driverul cere clusterului perechi și apoi se conectează la adresele pe care clusterul le anunță.

De aceea o nepotrivire de adrese private produce tiparul cunoscut: o primă conexiune reușită urmată de expirări de timp. Configurează deliberat adresele anunțate și rutarea clientului; publicarea întregului cluster pe internet pentru a repara o nepotrivire schimbă o eroare de rutare pe o expunere pe care nu o poți retrage.

Păstrează și autentificarea bazei de date și permisiunile de rol ale aplicației. O adresă VPN tradusă partajată poate reprezenta mulți utilizatori sau servicii, așa că nu înlocuiește niciodată identități distincte de bază de date.

Criptează separat client-la-nod și internode

Documentația de securitate Apache tratează criptarea client-la-nod și internode ca configurații separate, iar activarea uneia nu o activează pe cealaltă. Această distincție se aplică în continuare în interiorul unui VPN, pentru că tunelul își protejează propriul segment și nu se extinde automat de la procesul aplicației la procesul bazei de date sau între fiecare pereche de membri ai clusterului.

O configurație care le activează pe ambele explicit, în loc să moștenească o valoare implicită de șablon, arată cam așa:

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

Pe configurațiile de server care permit criptarea opțională a clientului, acceptarea TLS poate coexista cu acceptarea conexiunilor necriptate, așa că citește politica efectivă, nu intenția. Planifică numele certificatelor, distribuția încrederii și reînnoirea pentru punctele finale cu care fiecare client contactează efectiv; înlocuirea unui nume de gazdă cu o adresă IP schimbă verificarea identității clientului, nu doar ruta acestuia.

Ține administrarea pe o cale proprie

Traficul internode are nevoie de setul de perechi permis și de propria politică de protecție. Accesul administrativ, inclusiv JMX acolo unde este folosit, are nevoie de o categorie de public separată și de propria autentificare. O aplicație permisă să emită interogări obișnuite nu are prin aceasta nevoie de fiecare capacitate de administrare, iar inversul este mai rău: o cale administrativă expusă segmentului aplicației este cea mai scurtă rută de la o eroare la o reconstrucție. Notează cele două categorii de public separat și numește-le proprietarii, pentru că de obicei sunt echipe diferite ale căror reguli au fost contopite din greșeală.

Ține aliniate regulile efective de cloud, regulile de gazdă și configurația listenerului. Un listener privat poate fi totuși expus printr-o traducere sau un proxy neintenționat, iar o regulă publică largă poate sta liniștită lângă o regulă VPN îngustă până când cineva le auditează pe amândouă deodată.

Acolo unde operatorii au într-adevăr nevoie de o cale de administrare, dă-i un proprietar numit și o durată de viață a acreditărilor mai scurtă decât a aplicației. Astfel delegarea rămâne vizibilă când următoarea persoană preia clusterul.

Ce promite proiectarea

Validează toate cele trei promisiuni cu roluri reale, nu doar cu teste de conectivitate. O aplicație aprobată ar trebui să își finalizeze munca permisă și nimic mai mult, o sursă exclusă ar trebui să eșueze la intrarea de client, iar o identitate de aplicație ar trebui refuzată pe căile administrative rezervate. Adaugă reconectarea clientului și selecția nodurilor la același test de implementare, pentru că acolo apar erorile de descoperire.

Încheie cu trei propoziții în documentul de proiectare: ce clienți pot interoga, ce noduri pot comunica și ce operatori pot administra. A fi în spatele unui VPN este o informație utilă de topologie, dar nu este un răspuns la niciuna dintre cele trei întrebări.