Cassandra preko VPN-a: odvojen pristup za klijente i čvorove

Cassandra implementacija nema jednu univerzalnu mrežu baze podataka. Aplikacije razgovaraju sa klijentskim servisom, članovi klastera razgovaraju međusobno, a operateri koriste administrativne interfejse, i te tri publike ne bi trebalo da nasleđuju dostupnost jedna od druge. Privatni put kao što je VPN je dobra početna tačka, ali nije korisnički identitet baze podataka niti njena politika šifrovanja. Tretirajte odluku o povezanosti i odluku o autorizaciji kao dva odvojena pregleda.

Svaka od tri publike dobija sopstveni odgovor, a odeljci ispod ih obrađuju redom po izloženosti.

Tri publike, tri odluke

Identifikujte šta svaka grupa zaista treba pre nego što dirnete pravilo. Klijentima treba klijentski listener i dovoljno informacija da dohvate svaki čvor koji im može biti dodeljen, partnerskim čvorovima treba jedan drugi na internode portu, a operaterima treba interfejs za upravljanje za ono što runbook zaista zahteva. Tri liste, tri publike, tri nivoa poverenja.

Uobičajena greška je izgraditi jedan ravan privatni segment i pretpostaviti da VPN granica radi ostalo. Unutar njega, aplikacija koja dohvata klijentski port obično dohvata i internode port, a operaterovi administrativni alati često stoje na istom jump hostu kao aplikacija. Spljoštavanje toga zajedno znači da kompromitovani identitet aplikacije već ima veći doseg od sopstvenih upita. Nacrtajte tri publike kao tri reda u projektnom dokumentu, svaki sa pravilom koje ga dozvoljava, i praznine postaju vidljive pre nego što ih iko izgradi.

Šta klijentima treba, i ništa više

Dozvolite predviđenim izvorima aplikacije pristup klijentskim endpointima za raspoređenu verziju, i držite nepovezane klaster i upravljačke servise izvan tog dosega. Zatim proverite kako drajver otkriva čvorove. Dostupna početna kontakt tačka ne dokazuje da je svaka adresa čvora koju drajver kasnije izabere dostupna iz tog klijentskog konteksta, jer drajver pita klaster za partnere i zatim se povezuje na adrese koje klaster oglašava.

Zato jedno neslaganje privatnih adresa daje poznat obrazac: uspešna prva veza praćena isteklim vremenima. Konfigurišite oglašene adrese i klijentsko rutiranje namerno; objavljivanje celog klastera na internetu da biste popravili jedno neslaganje menja grešku rutiranja za izloženost koju ne možete povući.

Zadržite i autentifikaciju baze podataka i dozvole uloga aplikacije. Zajednička prevedena VPN adresa može predstavljati mnoge korisnike ili servise, pa nikada ne zamenjuje zasebne identitete baze podataka.

Šifrujte odvojeno klijent-čvor i internode

Zvanična Apache bezbednosna dokumentacija tretira šifrovanje klijent-čvor i internode kao odvojene konfiguracije, a uključivanje jedne ne uključuje drugu. Ta razlika i dalje važi unutar VPN-a, jer tunel štiti sopstveni segment i ne prostire se automatski od procesa aplikacije do procesa baze podataka niti između svakog para članova klastera.

Konfiguracija koja oba uključuje eksplicitno, umesto da nasledi podrazumevanu vrednost šablona, izgleda otprilike ovako:

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

Na serverskim konfiguracijama koje dozvoljavaju opciono klijentsko šifrovanje, prihvatanje TLS-a može koegzistirati sa prihvatanjem nešifrovanih veza, pa čitajte efektivnu politiku, a ne nameru. Planirajte imena sertifikata, distribuciju poverenja i obnavljanje za endpointe koje svaki klijent zaista kontaktira; zamena imena hosta IP adresom menja proveru identiteta klijenta, ne samo njegovu rutu.

Držite administraciju na sopstvenom putu

Internode saobraćaj treba dozvoljeni skup partnera i sopstvenu politiku zaštite. Administrativni pristup, uključujući JMX gde se koristi, treba odvojenu publiku i sopstvenu autentifikaciju. Aplikaciji dozvoljenoj da šalje obične upite nije time potrebna svaka upravljačka mogućnost, a obrnuto je gore: administrativni put izložen aplikativnom segmentu najkraća je ruta od greške do ponovne izgradnje. Zapišite te dve publike odvojeno i navedite njihove vlasnike, jer su to obično različiti timovi čija su pravila slučajno spojena.

Držite usklađene efektivna cloud pravila, pravila hosta i konfiguraciju listenera. Privatni listener i dalje može biti izložen kroz nenamerno prevođenje ili proxy, a široko javno pravilo može tiho stajati pored uskog VPN pravila dok neko ne proveri oba odjednom.

Tamo gde operaterima zaista treba upravljački put, dajte mu imenovanog vlasnika i kraći životni vek akreditiva od aplikacijinog. To održava delegiranje vidljivim kada sledeća osoba nasledi klaster.

Šta dizajn obećava

Validirajte sva tri obećanja stvarnim ulogama, a ne samo testovima povezanosti. Odobrena aplikacija treba da završi dozvoljeni posao i ništa više, isključeni izvor treba da ne uspe na klijentskom ulazu, a identitet aplikacije treba da bude odbijen na rezervisanim administrativnim putevima. Dodajte ponovno povezivanje klijenta i izbor čvorova u isti test uvođenja, jer se tu pojavljuju greške otkrivanja.

Završite sa tri rečenice u projektnom dokumentu: koji klijenti mogu da upituju, koji čvorovi mogu da komuniciraju i koji operateri mogu da administriraju. Biti iza VPN-a je korisna informacija o topologiji, ali nije odgovor na nijedno od tih tri pitanja.