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

Cassandra implementacija nema jednu univerzalnu mrežu baze podataka. Aplikacije razgovaraju s klijentskom uslugom, članovi klastera razgovaraju međusobno, a operateri rabe administrativna sučelja, i te tri publike ne bi smjele naslijediti dostupnost jedna druge. Privatni put poput VPN-a dobro je polazište, ali on nije identitet korisnika baze podataka i nije njezina politika šifriranja. Tretirajte odluku o povezivosti i odluku o autorizaciji kao dva odvojena pregleda.

Svaka od tri publike dobiva vlastiti odgovor, a odjeljci u nastavku obrađuju ih redom izloženosti.

Tri publike, tri odluke

Utvrdite što svaka skupina doista treba prije nego što dirnete pravilo. Klijentima treba klijentski slušatelj i dovoljno informacija da dosegnu svaki čvor koji im se može dodijeliti, partnerskim čvorovima trebaju jedni drugi na međučvornom portu, a operaterima treba upravljačko sučelje za ono što runbook doista zahtijeva. Tri popisa, tri publike, tri razine povjerenja.

Uobičajena je pogreška izgraditi jedan ravni privatni segment i pretpostaviti da će VPN granica odraditi ostalo. Unutar njega aplikacija koja doseže klijentski port obično doseže i međučvorni port, a operaterov administrativni alat često stoji na istom preskočnom hostu kao i aplikacija. Spljoštiti to zajedno znači da kompromitirani identitet aplikacije već ima veći doseg od vlastitih upita. Nacrtajte tri publike kao tri retka u projektnom dokumentu, svaku s pravilom koje je dopušta, i praznine postaju vidljive prije nego ih itko izgradi.

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

Dopustite namijenjenim izvorima aplikacije pristup klijentskim krajnjim točkama za postavljenu inačicu i držite nepovezane klaster i upravljačke usluge izvan tog dosega. Zatim provjerite kako upravljački program otkriva čvorove. Dostupna početna kontaktna točka ne dokazuje da je svaka adresa čvora koju program zatim odabere dostupna iz tog klijentskog konteksta, jer program pita klaster za partnere i zatim se povezuje na sve adrese koje klaster oglašava.

Zato jedno nepodudaranje privatne adrese stvara poznat uzorak: uspješna prva veza nakon koje slijede isteci. Konfigurirajte oglašene adrese i usmjeravanje klijenta namjerno; objavljivanje cijelog klastera na internetu da popravite jedno nepodudaranje mijenja pogrešku usmjeravanja za izloženost koju ne možete povući.

Zadržite i autentifikaciju baze podataka aplikacije i dopuštenja uloga. Zajednička prevedena VPN adresa može predstavljati mnoge korisnike ili usluge, pa nikada nije zamjena za različite identitete baze podataka.

Šifrirajte klijent-prema-čvoru i međučvorno odvojeno

Apacheova sigurnosna dokumentacija tretira šifriranje klijent-prema-čvoru i međučvorno kao odvojene konfiguracije, i omogućavanje jedne ne omogućuje drugu. Ta razlika vrijedi i unutar VPN-a, jer tunel štiti vlastiti segment i ne širi se automatski od procesa aplikacije do procesa baze podataka ili između svakog para članova klastera.

Konfiguracija koja oboje uključuje izričito, umjesto da naslijedi zadanu vrijednost predloška, izgleda otprilike ovako:

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

Na poslužiteljskim konfiguracijama koje dopuštaju neobavezno klijentsko šifriranje, prihvaćanje TLS-a može postojati uz prihvaćanje nešifriranih veza, pa čitajte stvarnu politiku, a ne namjeru. Planirajte imena certifikata, distribuciju povjerenja i obnovu za krajnje točke s kojima svaki klijent doista kontaktira; zamjena imena hosta IP adresom mijenja provjeru identiteta klijenta, a ne samo njegovu rutu.

Držite administraciju na vlastitom putu

Međučvorni promet treba dopušten skup partnera i vlastitu politiku zaštite. Administrativni pristup, uključujući JMX gdje se rabi, treba odvojenu publiku i vlastitu autentifikaciju. Aplikacija kojoj je dopušteno izdavati obične upite time ne treba svaku upravljačku mogućnost, a obrnuto je gore: administrativni put izložen aplikacijskom segmentu najkraći je put od pogreške do ponovne izgradnje. Zapišite te dvije publike odvojeno i imenujte njihove vlasnike, jer su to obično različiti timovi čija su pravila slučajno spojena.

Držite stvarne cloud pravila, pravila hosta i konfiguraciju slušatelja usklađenima. Privatni slušatelj ipak može biti izložen kroz nenamjerno prevođenje ili proxy, a široko javno pravilo može tiho stajati uz usko VPN pravilo dok netko ne provjeri oboje odjednom.

Gdje operateri doista trebaju upravljački put, dajte mu imenovanog vlasnika i kraći rok trajanja vjerodajnica od aplikacijskog. To održava delegiranje vidljivim kada sljedeća osoba naslijedi klaster.

Što dizajn obećava

Provjerite sva tri obećanja stvarnim ulogama, a ne samo testovima povezivosti. Odobrena aplikacija treba dovršiti svoj dopušteni posao i ništa više, isključeni izvor treba pasti na klijentskom ulazu, a identitet aplikacije treba biti odbijen na rezerviranim administrativnim putevima. Dodajte ponovno povezivanje klijenta i odabir čvora u isti test uvođenja, jer se tu otkrivaju pogreške pronalaženja.

Završite s tri rečenice u projektnom dokumentu: koji klijenti mogu postavljati upite, koji čvorovi mogu komunicirati i koji operateri mogu administrirati. Biti iza VPN-a korisna je informacija o topologiji, ali nije odgovor ni na jedno od tih tri pitanja.