Cassandra-ն VPN-ի միջոցով. առանձին հասանելիություն հաճախորդների և հանգույցների համար

Cassandra-ի տեղակայումը չունի մեկ համընդհանուր տվյալների բազայի ցանց։ Հավելվածները խոսում են հաճախորդի ծառայության հետ, կլաստերի անդամները խոսում են միմյանց հետ, իսկ օպերատորները օգտագործում են վարչական ինտերֆեյսներ, և այս երեք լսարանները չպետք է ժառանգեն միմյանց հասանելիությունը։ VPN-ի նման մասնավոր ուղին լավ մեկնարկային կետ է, բայց այն տվյալների բազայի օգտագործողի ինքնությունը չէ և դրա կոդավորման քաղաքականությունը չէ։ Կապակցման որոշումը և լիազորման որոշումը դիտարկեք որպես երկու առանձին վերանայում։

Երեք լսարաններից յուրաքանչյուրը ստանում է իր պատասխանը, և ստորև բաժինները դիտարկում են դրանք ըստ ազդեցության հերթականության։

Երեք լսարան, երեք որոշում

Որևէ կանոնի չհպվելուց առաջ պարզեք, թե ինչ է իրականում անհրաժեշտ յուրաքանչյուր խմբին։ Հաճախորդներին պետք է հաճախորդի լսիչը և բավարար տեղեկատվություն՝ հասնելու յուրաքանչյուր հանգույցի, որը կարող է տրվել նրանց, զուգընկեր հանգույցներին պետք են միմյանց միջհանգույցային պորտում, իսկ օպերատորներին պետք է կառավարման ինտերֆեյսն այն բանի համար, ինչ իրականում պահանջում է runbook-ը։ Երեք ցուցակ, երեք լսարան, վստահության երեք մակարդակ։

Սովորական սխալը մեկ հարթ մասնավոր հատված կառուցելն ու ենթադրելն է, թե VPN-ի սահմանը կանի մնացածը։ Դրա ներսում հաճախորդի պորտին հասնող հավելվածը սովորաբար հասնում է նաև միջհանգույցային պորտին, և օպերատորի վարչական գործիքները հաճախ նստում են նույն ցատկող հոսթի վրա, ինչ հավելվածը։ Դրանք միասին հարթեցնելը նշանակում է, որ վտանգված հավելվածի ինքնությունն արդեն ավելի մեծ հասանելիություն ունի, քան իր իսկ հարցումները։ Դիզայնի փաստաթղթում երեք լսարանները գծեք որպես երեք տող, յուրաքանչյուրը՝ դա թույլատրող կանոնով, և բացերը տեսանելի կդառնան նախքան որևէ մեկը կկառուցի դրանք։

Ինչ է պետք հաճախորդներին, և ոչ ավելին

Թույլատրեք նախատեսված հավելվածային աղբյուրներին հասնել հաճախորդի վերջնակետերին տեղակայված տարբերակի համար, և անկապ կլաստերային ու կառավարման ծառայությունները պահեք այդ հասանելիությունից դուրս։ Այնուհետև ստուգեք, թե ինչպես է դրայվերը հայտնաբերում հանգույցները։ Հասանելի նախնական կապի կետը չի ապացուցում, որ դրայվերի հետագայում ընտրած յուրաքանչյուր հանգույցի հասցե հասանելի է այդ հաճախորդի համատեքստից, քանի որ դրայվերը կլաստերից հարցնում է զուգընկերների մասին և հետո միանում այն հասցեներին, որոնք կլաստերը հայտարարում է։

Այդ պատճառով մասնավոր հասցեի մեկ անհամապատասխանություն ստեղծում է ծանոթ օրինաչափությունը՝ հաջող առաջին միացում, որին հաջորդում են ժամանակի սպառումներ։ Կարգավորեք հայտարարված հասցեները և հաճախորդի երթուղավորումը գիտակցաբար. ամբողջ կլաստերը ինտերնետում հրապարակելը մեկ անհամապատասխանություն շտկելու համար երթուղավորման սխալը փոխանակում է բացահայտման հետ, որը հնարավոր չէ հետ վերցնել։

Պահպանեք նաև հավելվածի տվյալների բազայի նույնականացումը և դերային թույլտվությունները։ Համօգտագործված թարգմանված VPN հասցեն կարող է ներկայացնել շատ օգտագործողների կամ ծառայությունների, ուստի այն երբեք չի փոխարինում առանձին տվյալների բազայի ինքնություններին։

Կոդավորեք առանձին հաճախորդ-հանգույց և միջհանգույցային կապը

Apache-ի անվտանգության փաստաթղթերը հաճախորդ-հանգույց և միջհանգույցային կոդավորումը դիտարկում են որպես առանձին կարգավորումներ, և մեկի միացումը չի միացնում մյուսը։ Այդ տարբերությունը գործում է նաև VPN-ի ներսում, քանի որ թունելը պաշտպանում է իր սեփական հատվածը և ինքնաշխատ չի տարածվում հավելվածի գործընթացից տվյալների բազայի գործընթաց կամ կլաստերի անդամների յուրաքանչյուր զույգի միջև։

Կարգավորումը, որը միացնում է երկուսն էլ բացահայտ, փոխարենը ժառանգելու ձևանմուշի լռելյայն արժեքը, մոտավորապես այսպիսի տեսք ունի.

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

Այն սերվերային կարգավորումներում, որոնք թույլ են տալիս ընտրովի հաճախորդային կոդավորում, TLS-ի ընդունումը կարող է գոյակցել չկոդավորված միացումների ընդունման հետ, ուստի կարդացեք գործող քաղաքականությունը, ոչ թե մտադրությունը։ Պլանավորեք վկայագրերի անունները, վստահության բաշխումը և թարմացումը այն վերջնակետերի համար, որոնց հետ յուրաքանչյուր հաճախորդ իրականում կապվում է. հոսթի անունը IP հասցեով փոխարինելը փոխում է հաճախորդի ինքնության ստուգումը, ոչ միայն նրա երթուղին։

Կառավարումը պահեք իր առանձին ուղու վրա

Միջհանգույցային երթևեկությանը պետք են թույլատրված զուգընկերների հավաքածուն և իր սեփական պաշտպանության քաղաքականությունը։ Վարչական հասանելիությանը, ներառյալ JMX-ը այնտեղ, որտեղ օգտագործվում է, պետք են առանձին լսարան և իր սեփական նույնականացումը։ Սովորական հարցումներ տալու թույլտվություն ունեցող հավելվածին դրա պատճառով պետք չէ կառավարման բոլոր հնարավորությունները, իսկ հակառակը ավելի վատ է. հավելվածային հատվածին բաց վարչական ուղին սխալից վերակառուցման ամենակարճ ճանապարհն է։ Այդ երկու լսարանները գրեք առանձին և անվանեք դրանց տերերին, որովհետև դրանք սովորաբար տարբեր թիմեր են, որոնց կանոնները պատահաբար միաձուլվել են։

Գործող ամպային կանոնները, հոսթի կանոնները և լսիչի կարգավորումը պահեք համաձայնեցված։ Մասնավոր լսիչը դեռ կարող է բաց լինել չնախատեսված թարգմանության կամ պրոքսիի միջոցով, և լայն հանրային կանոնը կարող է լուռ կանգնել նեղ VPN կանոնի կողքին, մինչև ինչ-որ մեկը միաժամանակ աուդիտի երկուսն էլ։

Այնտեղ, որտեղ օպերատորներին իսկապես պետք է կառավարման ուղի, տվեք նրան անվանված տեր և ավելի կարճ հավատարմագրերի կյանք, քան հավելվածինը։ Դա պատվիրակումը տեսանելի է պահում, երբ հաջորդ մարդը ժառանգում է կլաստերը։

Ինչ է խոստանում դիզայնը

Ստուգեք բոլոր երեք խոստումները իրական դերերով, ոչ միայն կապակցման թեստերով։ Հաստատված հավելվածը պետք է ավարտի իր թույլատրված աշխատանքը և ոչ ավելին, բացառված աղբյուրը պետք է ձախողվի հաճախորդի մուտքի մոտ, և հավելվածի ինքնությունը պետք է մերժվի վերապահված վարչական ուղիներում։ Ավելացրեք հաճախորդի վերամիացումը և հանգույցի ընտրությունը նույն տեղակայման թեստին, որովհետև հենց այնտեղ են ի հայտ գալիս հայտնաբերման սխալները։

Ավարտեք երեք նախադասությամբ դիզայնի փաստաթղթում. որ հաճախորդները կարող են հարցումներ անել, որ հանգույցները կարող են հաղորդակցվել և որ օպերատորները կարող են կառավարել։ VPN-ի հետևում լինելը օգտակար տոպոլոգիական տեղեկատվություն է, բայց այն այդ երեք հարցերից ոչ մեկի պատասխանը չէ։