Cassandra cez VPN: oddelený prístup pre klientov a uzly

Nasadenie Cassandra nemá jednu univerzálnu databázovú sieť. Aplikácie komunikujú s klientskou službou, členovia klastra komunikujú medzi sebou a operátori používajú administratívne rozhrania, a tieto tri skupiny používateľov by nemali dediť dosiahnuteľnosť jedna od druhej. Súkromná cesta, akou je VPN, je dobrý východiskový bod, ale nie je používateľskou identitou databázy ani jej šifrovacou politikou. Rozhodnutie o konektivite a rozhodnutie o autorizácii berte ako dve samostatné revízie.

Každá z troch skupín dostane vlastnú odpoveď a nižšie uvedené časti ich berú v poradí podľa expozície.

Tri skupiny, tri rozhodnutia

Zistite, čo každá skupina skutočne potrebuje, skôr než sa dotknete pravidla. Klienti potrebujú klientsky listener a dosť informácií na dosiahnutie každého uzla, ktorý im môže byť pridelený, partnerské uzly potrebujú jeden druhý na porte internode a operátori potrebujú rozhranie správy pre to, čo runbook skutočne vyžaduje. Tri zoznamy, tri skupiny, tri úrovne dôvery.

Častou chybou je postaviť jeden plochý súkromný segment a predpokladať, že hranica VPN urobí zvyšok. Vnútri neho aplikácia, ktorá dosiahne klientsky port, zvyčajne dosiahne aj port internode, a administratívne nástroje operátora často sedia na tom istom jump hoste ako aplikácia. Zlúčenie týchto vrstiev znamená, že kompromitovaná identita aplikácie má už väčší dosah než jej vlastné dopyty. Nakreslite tri skupiny ako tri riadky v návrhovom dokumente, každú s pravidlom, ktoré ju povoľuje, a medzery sa stanú viditeľnými skôr, než ich niekto postaví.

Čo klienti potrebujú, a nič viac

Povoľte zamýšľaným zdrojom aplikácie prístup ku klientskym koncovým bodom pre nasadenú verziu a držte nesúvisiace služby klastra a správy mimo tohto dosahu. Potom skontrolujte, ako driver objavuje uzly. Dosiahnuteľný počiatočný kontaktný bod nedokazuje, že každá adresa uzla, ktorú driver neskôr vyberie, je dosiahnuteľná z tohto klientskeho kontextu, pretože driver sa pýta klastra na partnerov a potom sa pripojí k adresám, ktoré klaster oznamuje.

Preto jedna nezhoda súkromných adries vytvára známy obrazec: úspešné prvé pripojenie a potom časové limity. Nakonfigurujte oznamované adresy a klientske smerovanie zámerne; zverejnenie celého klastra na internete na opravu jednej nezhody vymení chybu smerovania za expozíciu, ktorú už nemôžete vziať späť.

Zachovajte aj databázové overovanie a oprávnenia rolí aplikácie. Zdieľaná preložená adresa VPN môže zastupovať mnohých používateľov alebo služby, takže nikdy nenahrádza samostatné databázové identity.

Šifrujte oddelene klient-uzol a internode

Dokumentácia bezpečnosti Apache považuje šifrovanie klient-uzol a internode za samostatné konfigurácie a zapnutie jedného nezapne druhé. Tento rozdiel stále platí vnútri VPN, pretože tunel chráni svoj vlastný segment a automaticky sa nerozširuje z procesu aplikácie do procesu databázy ani medzi každú dvojicu členov klastra.

Konfigurácia, ktorá obe výslovne zapne, namiesto dedenia predvolenej hodnoty šablóny, vyzerá približne takto:

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

Na konfiguráciách servera, ktoré povoľujú voliteľné šifrovanie klienta, môže prijímanie TLS existovať spolu s prijímaním nešifrovaných pripojení, preto čítajte účinnú politiku a nie zámer. Naplánujte názvy certifikátov, distribúciu dôvery a obnovu pre koncové body, ktoré každý klient skutočne kontaktuje; nahradenie názvu hostiteľa IP adresou mení overenie identity klienta, nielen jeho trasu.

Držte administráciu na vlastnej ceste

Prevádzka internode potrebuje povolenú množinu partnerov a vlastnú politiku ochrany. Administratívny prístup, vrátane JMX tam, kde sa používa, potrebuje samostatnú skupinu a vlastné overovanie. Aplikácia povolená na bežné dopyty preto nepotrebuje každú možnosť správy a opak je horší: administratívna cesta vystavená aplikačnému segmentu je najkratšia trasa od chyby k prestavbe. Zapíšte tie dve skupiny oddelene a pomenujte ich vlastníkov, pretože sú to zvyčajne rôzne tímy, ktorých pravidlá sa omylom zlúčili.

Držte účinné cloudové pravidlá, pravidlá hostiteľa a konfiguráciu listenera v súlade. Súkromný listener môže byť stále vystavený cez neúmyselný preklad alebo proxy a široké verejné pravidlo môže ticho stáť vedľa úzkeho pravidla VPN, kým niekto neaudituje obe naraz.

Tam, kde operátori skutočne potrebujú cestu správy, dajte jej pomenovaného vlastníka a kratšiu životnosť poverení než má aplikácia. Delegovanie tak zostane viditeľné, keď klaster prevezme ďalšia osoba.

Čo návrh sľubuje

Overte všetky tri prísľuby skutočnými rolami, nie iba testami konektivity. Schválená aplikácia má dokončiť povolenú prácu a nič viac, vylúčený zdroj má zlyhať na klientskom vstupe a identita aplikácie má byť odmietnutá na vyhradených administratívnych cestách. Pridajte opätovné pripojenie klienta a výber uzlov do toho istého testu nasadenia, pretože práve tam sa objavujú chyby objavovania.

Ukončite to tromi vetami v návrhovom dokumente: ktorí klienti môžu dopytovať, ktoré uzly môžu komunikovať a ktorí operátori môžu administrovať. Byť za VPN je užitočná informácia o topológii, ale nie je odpoveďou na žiadnu z tých troch otázok.