Cassandra përmes VPN: akses i ndarë për klientët dhe nyjet

Një vendosje Cassandra nuk ka një rrjet të vetëm universal të bazës së të dhënave. Aplikacionet komunikojnë me shërbimin e klientit, anëtarët e grupit komunikojnë me njëri-tjetrin dhe operatorët përdorin ndërfaqe administrative, dhe këto tri grupe audience nuk duhet të trashëgojnë arritshmërinë e njëra-tjetrës. Një rrugë private si VPN është pikë e mirë fillimi, por nuk është identiteti i përdoruesit të bazës së të dhënave dhe nuk është politika e saj e kriptimit. Trajto vendimin për lidhshmërinë dhe vendimin për autorizimin si dy rishikime të ndara.

Secili nga tri grupet merr përgjigjen e vet, dhe seksionet më poshtë i trajtojnë sipas rendit të ekspozimit.

Tri grupe, tri vendime

Përcakto se çfarë i nevojitet vërtet secilit grup përpara se të prekësh një rregull. Klientëve u nevojitet dëgjuesi i klientit dhe informacion i mjaftueshëm për të arritur çdo nyje që mund t'u caktohet, nyjeve partnere u nevojitet njëra-tjetra në portën internode, dhe operatorëve u nevojitet ndërfaqja e menaxhimit për atë që kërkon vërtet runbook-u. Tri lista, tri grupe, tri nivele besimi.

Gabimi i zakonshëm është të ndërtosh një segment privat të sheshtë dhe të supozosh se kufiri i VPN bën pjesën tjetër. Brenda tij, një aplikacion që arrin portën e klientit zakonisht arrin edhe portën internode, dhe mjetet administrative të operatorit shpesh ndodhen në të njëjtin host kërcimi si aplikacioni. Rrafshimi i tyre së bashku do të thotë që një identitet aplikacioni i komprometuar ka tashmë më shumë shtrirje sesa vetë kërkesat e tij. Vizato tri grupet si tri rreshta në dokumentin e projektimit, secili me rregullin që e lejon, dhe boshllëqet bëhen të dukshme përpara se dikush t'i ndërtojë.

Çfarë u nevojitet klientëve, dhe asgjë më shumë

Lejo burimet e synuara të aplikacionit drejt pikave fundore të klientit për versionin e vendosur dhe mbaj shërbimet e palidhura të grupit dhe të menaxhimit jashtë asaj shtrirjeje. Pastaj kontrollo si e zbulon drejtuesi nyjet. Një pikë fillestare kontakti e arritshme nuk vërteton se çdo adresë nyje që drejtuesi zgjedh më pas është e arritshme nga ai kontekst klienti, sepse drejtuesi i kërkon grupit partnerë dhe pastaj lidhet me adresat që grupi shpall.

Kjo është arsyeja pse një mospërputhje e adresave private prodhon modelin e njohur: një lidhje e parë e suksesshme e ndjekur nga skadime kohe. Konfiguro me qëllim adresat e shpallura dhe rrugëtimin e klientit; publikimi i të gjithë grupit në internet për të rregulluar një mospërputhje ndërron një gabim rrugëtimi me një ekspozim që nuk mund ta tërheqësh.

Mbaj gjithashtu vërtetimin e bazës së të dhënave dhe lejet e roleve të aplikacionit. Një adresë VPN e përkthyer dhe e përbashkët mund të përfaqësojë shumë përdorues ose shërbime, prandaj nuk zëvendëson kurrë identitete të veçanta të bazës së të dhënave.

Kripto veçmas klient-nyje dhe internode

Dokumentacioni i sigurisë i Apache i trajton kriptimin klient-nyje dhe internode si konfigurime të ndara, dhe aktivizimi i njërit nuk aktivizon tjetrin. Ky dallim vlen ende brenda një VPN, sepse tuneli mbron segmentin e vet dhe nuk shtrihet automatikisht nga procesi i aplikacionit në procesin e bazës së të dhënave ose midis çdo çifti anëtarësh të grupit.

Një konfigurim që i aktivizon të dyja shprehimisht, në vend që të trashëgojë një vlerë të paracaktuar shablloni, duket afërsisht kështu:

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

Në konfigurimet e serverit që lejojnë kriptim opsional të klientit, pranimi i TLS mund të bashkëjetojë me pranimin e lidhjeve të pakriptuara, prandaj lexo politikën efektive dhe jo qëllimin. Planifiko emrat e certifikatave, shpërndarjen e besimit dhe rinovimin për pikat fundore me të cilat çdo klient kontakton vërtet; zëvendësimi i një emri hosti me një adresë IP ndryshon kontrollin e identitetit të klientit, jo vetëm rrugën e tij.

Mbaj administrimin në rrugën e vet

Trafiku internode ka nevojë për grupin e lejuar të partnerëve dhe politikën e vet të mbrojtjes. Aksesi administrativ, përfshirë JMX aty ku përdoret, ka nevojë për një grup të veçantë dhe vërtetim të vetin. Një aplikacion i lejuar të lëshojë kërkesa të zakonshme nuk ka për këtë arsye nevojë për çdo aftësi menaxhimi, dhe e kundërta është më keq: një rrugë administrative e ekspozuar ndaj segmentit të aplikacionit është rruga më e shkurtër nga një gabim në një rindërtim. Shkruaji veçmas këto dy grupe dhe emërto pronarët e tyre, sepse zakonisht janë ekipe të ndryshme rregullat e të cilëve janë bashkuar aksidentalisht.

Mbaj të rreshtuara rregullat efektive të resë kompjuterike, rregullat e hostit dhe konfigurimin e dëgjuesit. Një dëgjues privat mund të ekspozohet gjithsesi përmes një përkthimi ose përfaqësuesi të paqëllimtë, dhe një rregull publik i gjerë mund të qëndrojë në heshtje pranë një rregulli të ngushtë VPN derisa dikush t'i auditojë të dyja njëherësh.

Aty ku operatorëve u nevojitet vërtet një rrugë menaxhimi, jepi asaj një pronar të emërtuar dhe një jetëgjatësi kredenciale më të shkurtër sesa e aplikacionit. Kjo e mban delegimin të dukshëm kur personi i radhës trashëgon grupin.

Çfarë premton projektimi

Vërteto të tri premtimet me role reale, jo vetëm me teste lidhshmërie. Një aplikacion i miratuar duhet të përfundojë punën e lejuar dhe asgjë më shumë, një burim i përjashtuar duhet të dështojë në hyrjen e klientit, dhe një identitet aplikacioni duhet të refuzohet në rrugët administrative të rezervuara. Shto rilidhjen e klientit dhe përzgjedhjen e nyjeve në të njëjtin test vendosjeje, sepse aty dalin gabimet e zbulimit.

Përfundo me tri fjali në dokumentin e projektimit: cilët klientë mund të kërkojnë, cilat nyje mund të komunikojnë dhe cilët operatorë mund të administrojnë. Të jesh pas një VPN është informacion i dobishëm topologjie, por nuk është përgjigje për asnjë nga ato tri pyetje.