Cassandra VPN bidez: sarbide bereizia bezeroentzat eta nodoentzat

Cassandra inplementazio batek ez du datu-base sare unibertsal bakarra. Aplikazioek bezero-zerbitzuarekin hitz egiten dute, klusterreko kideek elkarren artean hitz egiten dute, eta operadoreek administrazio-interfazeak erabiltzen dituzte, eta hiru publiko horiek ez lukete elkarren irismena heredatu behar. VPN baten antzeko bide pribatu bat abiapuntu ona da, baina ez da datu-basearen erabiltzaile-identitatea eta ez da haren zifratze-politika. Trata itzazu konektibitatearen erabakia eta baimenaren erabakia berrikuspen bereizi gisa.

Hiru publikoetako bakoitzak bere erantzuna jasotzen du, eta beheko atalek esposizio-ordenan lantzen dituzte.

Hiru publiko, hiru erabaki

Egiaztatu talde bakoitzak benetan zer behar duen arau bat ukitu aurretik. Bezeroek bezero-entzulea behar dute eta eman dakiekeen nodo guztietara iristeko informazio nahikoa, nodo parekideek elkar behar dute nodoen arteko portuan, eta operadoreek kudeaketa-interfazea behar dute runbookak benetan eskatzen duenerako. Hiru zerrenda, hiru publiko, konfiantza-maila hiru.

Ohiko akatsa segmentu pribatu lau bakarra eraikitzea eta VPN mugak gainerakoa egingo duela suposatzea. Haren barruan, bezero-portura iristen den aplikazio bat normalean nodoen arteko portura ere iristen da, eta operadore baten administrazio-tresnak maiz aplikazioarekin host jauzi berean egoten dira. Hauek elkarrekin lauatzeak esan nahi du aplikazio-identitate konprometitu batek jada bere kontsultak baino irismen handiagoa duela. Marraztu hiru publikoak diseinu-dokumentuan hiru errenkada gisa, bakoitza onartzen duen arauarekin, eta hutsuneak ikusgarri bihurtuko dira inork eraiki aurretik.

Bezeroek zer behar duten, eta ez gehiago

Baimendu aurreikusitako aplikazio-iturriei bezeroen amaierako puntuetara iristea zabaldu den bertsiorako, eta eduki kluster eta kudeaketa zerbitzu erlazionatugabeak irismen horretatik kanpo. Gero egiaztatu nola aurkitzen dituen nodoak kontrolatzaileak. Ukigarria den hasierako kontaktu-puntu batek ez du frogatzen kontrolatzaileak geroago hautatzen duen nodo-helbide bakoitza bezero-kontestu horretatik irisgarria denik, kontrolatzaileak klusterrari parekideak galdegin eta gero klusterrak iragartzen dituen helbideetara konektatzen baita.

Horregatik helbide pribatu baten desberdintasun bakarrak eredu ezaguna sortzen du: lehen konexio arrakastatsua eta ondoren denbora-mugak. Konfiguratu iragarritako helbideak eta bezeroaren bideratzea nahita; desberdintasun bat konpontzeko kluster osoa internetera argitaratzeak bideratze-hutsegite bat ezin duzun esposizio baten truke aldatzen du.

Eutsi aplikazioaren datu-base autentifikazioari eta rol-baimenei ere. Partekatutako VPN helbide itzuli batek erabiltzaile edo zerbitzu asko ordezkatu ditzake, beraz ez da inoiz datu-base identitate desberdinen ordezko.

Zifratu bereizita bezerotik nodora eta nodoen artekoa

Apache-ren segurtasun-dokumentazioak bezerotik nodora eta nodoen arteko zifratzea konfigurazio bereizi gisa tratatzen ditu, eta bat gaitzeak ez du bestea gaitzen. Bereizketa hori VPN baten barruan ere aplikatzen da, tunelak bere segmentua babesten baitu eta ez baita automatikoki hedatzen aplikazio-prozesutik datu-base prozesura ezta klusterreko kideen pare bakoitzaren artean ere.

Biak modu esplizituan pizten dituen konfigurazioak, txantiloiaren balio lehenetsia heredatu ordez, gutxi gorabehera horrela dirudi:

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

Bezero-zifratze hautazkoa ahalbidetzen duten zerbitzari-konfigurazioetan, TLS onartzeak zifratu gabeko konexioak onartzearekin batera egon daiteke, beraz irakurri politika eraginkorra, ez asmoa. Planifikatu ziurtagiri-izenak, konfiantza-banaketa eta berritzea bezero bakoitzak benetan ukitzen dituen amaierako puntuetarako; ostalari-izena IP helbide batekin ordezkatzeak bezeroaren identitate-egiaztapena aldatzen du, ez soilik haren bidea.

Eduki administrazioa bere bidean

Nodoen arteko trafikoak onartutako pare-multzoa eta bere babes-politika behar ditu. Administrazio-sarbideak, erabiltzen den lekuan JMX barne, publiko bereizi bat eta bere autentifikazioa behar ditu. Kontsulta arruntak egiteko baimena duen aplikazio batek ez du horregatik kudeaketa-gaitasun guztiak behar, eta alderantzizkoa okerragoa da: aplikazio-segmentuari emandako administrazio-bidea hutsegitetik berreraikuntzara doan biderik laburrena da. Idatzi bi publiko horiek bereizita, eta izenda itzazu haien jabeak, normalean talde desberdinak baitira eta haien arauak nahi gabe bateratu baitziren.

Eduki bat etorriz hodeiko arau eraginkorrak, ostalari-arauak eta entzulearen konfigurazioa. Entzule pribatu bat oraindik ere agerian geratu daiteke nahi gabeko itzulpen edo proxy baten bidez, eta arau publiko zabal bat isilik egon daiteke VPN arau estu baten ondoan, norbaitek biak batera ikuskatu arte.

Operadoreek benetan kudeaketa-bide bat behar dutenean, eman iezaiozu jabe izendatu bat eta aplikazioarena baino kredentzialen bizitza laburragoa. Horrek delegazioa ikusgarri mantentzen du hurrengo pertsonak klusterra heredatzen duenean.

Zer agintzen duen diseinuak

Balidatu hiru promesak benetako rolekin, ez soilik konektibitate-probekin. Onartutako aplikazio batek baimendutako lana osatu behar du eta ez gehiago, baztertutako iturri batek bezero-sarreran huts egin behar du, eta aplikazio-identitate bat ukatzea behar da gordetako administrazio-bideetan. Gehitu bezeroaren berrikonexioa eta nodo-hautaketa zabalkuntza-proba berberean, han agertzen baitira aurkikuntza-hutsegiteak.

Amaitu hiru esaldirekin diseinu-dokumentuan: zein bezerok kontsultatu dezaketen, zein nodok komunika daitezkeen eta zein operadorek administratu dezaketen. VPN baten atzean egotea topologia-informazio erabilgarria da, baina ez da hiru galdera horietako ezein erantzutea.