Cassandra prek VPN: ločen dostop za odjemalce in vozlišča

Namestitev Cassandra nima enotnega univerzalnega omrežja podatkovne baze. Aplikacije govorijo s storitvijo odjemalca, člani grozda govorijo med seboj, operaterji pa uporabljajo administrativne vmesnike, in ta tri občinstva ne bi smela podedovati dosegljivosti drug od drugega. Zasebna pot, kot je VPN, je dobro izhodišče, vendar ni uporabniška identiteta podatkovne baze in ni njena politika šifriranja. Odločitev o povezljivosti in odločitev o avtorizaciji obravnavajte kot dva ločena pregleda.

Vsako od treh občinstev dobi svoj odgovor, razdelki spodaj pa jih obravnavajo po vrstnem redu izpostavljenosti.

Tri občinstva, tri odločitve

Ugotovite, kaj vsaka skupina v resnici potrebuje, preden se dotaknete pravila. Odjemalci potrebujejo odjemalčev poslušalec in dovolj informacij, da dosežejo vsako vozlišče, ki jim je lahko dodeljeno, partnerska vozlišča potrebujejo drugo drugega na vratih internode, operaterji pa potrebujejo vmesnik za upravljanje za tisto, kar runbook v resnici zahteva. Trije seznami, tri občinstva, tri ravni zaupanja.

Pogosta napaka je zgraditi en raven zasebni segment in domnevati, da bo meja VPN naredila ostalo. Znotraj njega lahko aplikacija, ki doseže odjemalčeva vrata, običajno doseže tudi vrata internode, administrativna orodja operaterja pa pogosto stojijo na istem skočnem gostitelju kot aplikacija. Zravnanje teh skupaj pomeni, da ima kompromitirana identiteta aplikacije že večji doseg kot njene lastne poizvedbe. Narišite tri občinstva kot tri vrstice v načrtovalskem dokumentu, vsako s pravilom, ki jo dovoljuje, in vrzeli postanejo vidne, preden jih kdo zgradi.

Kaj odjemalci potrebujejo, in nič več

Dovolite predvidenim virom aplikacije dostop do odjemalčevih končnih točk za nameščeno različico in nepovezane storitve grozda in upravljanja držite izven tega dosega. Nato preverite, kako gonilnik odkriva vozlišča. Dosegljiva začetna kontaktna točka ne dokazuje, da je vsak naslov vozlišča, ki ga gonilnik pozneje izbere, dosegljiv iz tega odjemalčevega konteksta, ker gonilnik vpraša grozd za partnerje in se nato poveže na naslove, ki jih grozd oglašuje.

Zato eno neskladje zasebnih naslovov ustvari znan vzorec: uspešna prva povezava, ki ji sledijo časovne prekinitve. Oglaševane naslove in usmerjanje odjemalca nastavite namerno; objava celotnega grozda na internetu za popravilo enega neskladja zamenja napako usmerjanja za izpostavljenost, ki je ne morete preklicati.

Ohranite tudi preverjanje pristnosti podatkovne baze in dovoljenja vlog aplikacije. Skupni prevedeni naslov VPN lahko predstavlja mnoge uporabnike ali storitve, zato nikoli ne nadomesti ločenih identitet podatkovne baze.

Šifrirajte ločeno odjemalec-vozlišče in internode

Dokumentacija o varnosti Apache obravnava šifriranje odjemalec-vozlišče in internode kot ločeni konfiguraciji in omogočanje enega ne omogoči drugega. Ta razlika še vedno velja znotraj VPN, ker tunel ščiti svoj segment in se ne razširi samodejno iz procesa aplikacije v proces podatkovne baze ali med vsak par članov grozda.

Konfiguracija, ki oba izrecno vklopi, namesto da bi podedovala privzeto vrednost predloge, izgleda približno takole:

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

Na konfiguracijah strežnika, ki dovoljujejo izbirno šifriranje odjemalca, lahko sprejemanje TLS obstaja skupaj s sprejemanjem nešifriranih povezav, zato berite dejansko politiko in ne namena. Načrtujte imena potrdil, distribucijo zaupanja in obnovitev za končne točke, s katerimi vsak odjemalec dejansko komunicira; zamenjava imena gostitelja z naslovom IP spremeni preverjanje identitete odjemalca, ne le njegove poti.

Upravljanje držite na lastni poti

Promet internode potrebuje dovoljeno množico partnerjev in lastno politiko zaščite. Administrativni dostop, vključno z JMX, kjer se uporablja, potrebuje ločeno občinstvo in lastno preverjanje pristnosti. Aplikacija, ki sme pošiljati običajne poizvedbe, zato ne potrebuje vseh upravljavskih zmožnosti, obratno pa je slabše: administrativna pot, izpostavljena segmentu aplikacije, je najkrajša pot od napake do ponovne gradnje. Ti dve občinstvi zapišite ločeno in poimenujte njune lastnike, ker sta običajno različni ekipi, katerih pravila so bila pomotoma združena.

Dejanska pravila oblaka, pravila gostitelja in konfiguracijo poslušalca držite usklajene. Zasebni poslušalec je lahko še vedno izpostavljen prek nenamernega prevajanja ali posrednika, široko javno pravilo pa lahko tiho stoji poleg ozkega pravila VPN, dokler nekdo ne pregleda obeh hkrati.

Kjer operaterji resnično potrebujejo upravljavsko pot, ji dajte imenovanega lastnika in krajšo življenjsko dobo poverilnic kot aplikacija. Tako delegiranje ostane vidno, ko grozd prevzame naslednja oseba.

Kaj načrt obljublja

Vse tri obljube preverite z resničnimi vlogami, ne le s preskusi povezljivosti. Odobrena aplikacija mora dokončati dovoljeno delo in nič več, izključen vir mora spodleteti na odjemalčevem vhodu, identiteta aplikacije pa mora biti zavrnjena na rezerviranih administrativnih poteh. Ponovno povezovanje odjemalca in izbiro vozlišč dodajte istemu preskusu uvajanja, ker se prav tam pokažejo napake odkrivanja.

Zaključite s tremi stavki v načrtovalskem dokumentu: kateri odjemalci lahko poizvedujejo, katera vozlišča lahko komunicirajo in kateri operaterji lahko upravljajo. Biti za VPN je koristna informacija o topologiji, vendar ni odgovor na nobeno od teh treh vprašanj.