VPN orqali Cassandra: mijozlar va tugunlar uchun alohida kirish

Cassandra o‘rnatishida yagona umumiy ma’lumotlar bazasi tarmog‘i bo‘lmaydi. Ilovalar mijoz xizmati bilan gaplashadi, klaster a’zolari bir-biri bilan gaplashadi, operatorlar esa ma’muriy interfeyslardan foydalanadi, va bu uchta auditoriya bir-birining yetib borish imkoniyatini meros olmasligi kerak. VPN kabi xususiy yo‘l yaxshi boshlanish nuqtasi, lekin u ma’lumotlar bazasining foydalanuvchi identifikatsiyasi emas va uning shifrlash siyosati ham emas. Ulanish qarori va avtorizatsiya qarorini ikkita alohida ko‘rib chiqish deb qarang.

Uchta auditoriyaning har biri o‘z javobini oladi, quyidagi bo‘limlar esa ularni ta’sir darajasi tartibida ko‘rib chiqadi.

Uchta auditoriya, uchta qaror

Har bir guruhga aslida nima kerakligini qoidaga tegishdan oldin aniqlang. Mijozlarga mijoz tinglovchisi va ularga berilishi mumkin bo‘lgan har bir tugunga yetib borish uchun yetarli ma’lumot kerak, hamkor tugunlarga internode portida bir-biri kerak, operatorlarga esa runbook aslida talab qiladigan narsa uchun boshqaruv interfeysi kerak. Uchta ro‘yxat, uchta auditoriya, uchta ishonch darajasi.

Odatiy xato — bitta tekis xususiy segment qurib, VPN chegarasi qolganini bajaradi deb o‘ylash. Uning ichida mijoz portiga yetadigan ilova odatda internode portiga ham yetadi, operatorning ma’muriy vositalari esa ko‘pincha ilova bilan bir xil sakrash xostida turadi. Ularni birga tekislash buzilgan ilova identifikatsiyasi o‘z so‘rovlaridan ko‘ra ko‘proq kirishga ega bo‘lishini bildiradi. Uchta auditoriyani loyiha hujjatida uchta qator qilib chizing, har biriga ruxsat beruvchi qoida bilan, va bo‘shliqlar kimdir ularni qurishidan oldin ko‘rinadi.

Mijozlarga nima kerak, va bundan ortiq hech narsa

Joylashtirilgan versiya uchun mo‘ljallangan ilova manbalariga mijoz oxirgi nuqtalariga ruxsat bering, aloqasi bo‘lmagan klaster va boshqaruv xizmatlarini esa bu kirishdan tashqarida tuting. So‘ng drayver tugunlarni qanday topishini tekshiring. Yetib borish mumkin bo‘lgan dastlabki aloqa nuqtasi drayver keyin tanlaydigan har bir tugun manzili shu mijoz kontekstidan yetib borish mumkinligini isbotlamaydi, chunki drayver klasterdan hamkorlarni so‘raydi va keyin klaster e’lon qilgan manzillarga ulanadi.

Shu sababli xususiy manzillarning bitta nomuvofiqligi tanish naqshni keltiradi: muvaffaqiyatli birinchi ulanish va keyin vaqt tugashi. E’lon qilingan manzillar va mijoz marshrutlashini ataylab sozlang; bitta nomuvofiqlikni tuzatish uchun butun klasterni internetga e’lon qilish marshrutlash xatosini qaytarib olib bo‘lmaydigan fosh etish bilan almashtiradi.

Ilovaning ma’lumotlar bazasi autentifikatsiyasi va rol ruxsatlarini ham saqlang. Umumiy tarjima qilingan VPN manzili ko‘plab foydalanuvchilar yoki xizmatlarni ifodalashi mumkin, shuning uchun u hech qachon alohida ma’lumotlar bazasi identifikatsiyalarining o‘rnini bosmaydi.

Mijozdan tugungacha va internode aloqasini alohida shifrlang

Apache xavfsizlik hujjati mijozdan tugungacha va internode shifrlashni alohida konfiguratsiyalar deb qaraydi, va birini yoqish ikkinchisini yoqmaydi. Bu farq VPN ichida ham amal qiladi, chunki tunnel o‘z segmentini himoya qiladi va ilova jarayonidan ma’lumotlar bazasi jarayoniga yoki klaster a’zolarining har bir juftligi orasida avtomatik tarqalmaydi.

Ikkalasini ham shablon standartini meros olish o‘rniga aniq yoqadigan konfiguratsiya taxminan shunday ko‘rinadi:

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

Mijozning ixtiyoriy shifrlashiga ruxsat beruvchi server konfiguratsiyalarida TLSni qabul qilish shifrlanmagan ulanishlarni qabul qilish bilan birga mavjud bo‘lishi mumkin, shuning uchun niyatni emas, amaldagi siyosatni o‘qing. Har bir mijoz aslida aloqaga kirishadigan oxirgi nuqtalar uchun sertifikat nomlari, ishonchni taqsimlash va yangilashni rejalashtiring; xost nomini IP manzil bilan almashtirish mijozning identifikatsiya tekshiruvini o‘zgartiradi, nafaqat uning marshrutini.

Boshqaruvni o‘z yo‘lida tuting

Internode trafigiga ruxsat berilgan hamkorlar to‘plami va o‘z himoya siyosati kerak. Ma’muriy kirish, ishlatiladigan joyda JMX ham, alohida auditoriya va o‘z autentifikatsiyasini talab qiladi. Oddiy so‘rovlar yuborishga ruxsat berilgan ilova shu sababli har bir boshqaruv imkoniyatiga muhtoj emas, teskarisi esa yomonroq: ilova segmentiga ochilgan ma’muriy yo‘l xatodan qayta qurishgacha eng qisqa yo‘ldir. Bu ikki auditoriyani alohida yozing va ularning egalarini nomlang, chunki odatda ular qoidalari tasodifan birlashtirilgan turli jamoalardir.

Amaldagi bulut qoidalari, xost qoidalari va tinglovchi konfiguratsiyasini bir chiziqda tuting. Xususiy tinglovchi baribir tasodifiy tarjima yoki proksi orqali ochilishi mumkin, keng ommaviy qoida esa kimdir ikkalasini birga tekshirmaguncha tor VPN qoidasi yonida jim turishi mumkin.

Operatorlarga haqiqatan boshqaruv yo‘li kerak bo‘lgan joyda unga nomlangan egasi va ilovanikidan qisqaroq hisob ma’lumotlari muddatini bering. Bu keyingi odam klasterni meros olganda vakolatni ko‘rinadigan qilib turadi.

Loyiha nima va’da qiladi

Uchala va’dani faqat ulanish testlari bilan emas, haqiqiy rollar bilan tasdiqlang. Tasdiqlangan ilova ruxsat etilgan ishini bajarishi va ortiq hech narsa qilmasligi kerak, chiqarib tashlangan manba mijoz kirishida muvaffaqiyatsiz bo‘lishi kerak, va ilova identifikatsiyasi ajratilgan ma’muriy yo‘llarda rad etilishi kerak. Mijozning qayta ulanishi va tugun tanlashni o‘sha joylashtirish testiga qo‘shing, chunki aniqlash xatolari aynan o‘sha yerda ko‘rinadi.

Loyiha hujjatida uchta gap bilan yakunlang: qaysi mijozlar so‘rov yuborishi mumkin, qaysi tugunlar aloqa qilishi mumkin va qaysi operatorlar boshqarishi mumkin. VPN ortida bo‘lish foydali topologiya ma’lumoti, lekin u o‘sha uchta savolning hech biriga javob emas.