VPN کے ذریعے Cassandra: کلائنٹس اور نوڈز کے لیے الگ رسائی

Cassandra کی تنصیب میں ڈیٹا بیس کا ایک واحد عالمگیر نیٹ ورک نہیں ہوتا۔ ایپلیکیشنز کلائنٹ سروس سے بات کرتی ہیں، کلسٹر کے ارکان ایک دوسرے سے بات کرتے ہیں، اور آپریٹر انتظامی انٹرفیس استعمال کرتے ہیں، اور یہ تینوں سامعین کو ایک دوسرے کی رسائی کا وارث نہیں ہونا چاہیے۔ VPN جیسا نجی راستہ اچھا نقطہ آغاز ہے، لیکن یہ ڈیٹا بیس کی صارف شناخت نہیں ہے اور نہ اس کی خفیہ کاری کی پالیسی ہے۔ کنیکٹیویٹی کے فیصلے اور اجازت کے فیصلے کو دو الگ جائزوں کے طور پر دیکھیں۔

تینوں سامعین میں سے ہر ایک کو اپنا جواب ملتا ہے، اور نیچے کے حصے انہیں ظہور کی ترتیب سے لیتے ہیں۔

تین سامعین، تین فیصلے

کسی قاعدے کو چھونے سے پہلے پہچانیں کہ ہر گروہ کو حقیقت میں کیا چاہیے۔ کلائنٹس کو کلائنٹ لسنر اور ہر اس نوڈ تک پہنچنے کے لیے کافی معلومات چاہیے جو انہیں دیا جا سکتا ہے، ساتھی نوڈز کو internode پورٹ پر ایک دوسرے کی ضرورت ہے، اور آپریٹر کو انتظامی انٹرفیس کی ضرورت ہے جو runbook واقعی مانگتا ہے۔ تین فہرستیں، تین سامعین، اعتماد کی تین سطحیں۔

عام غلطی یہ ہے کہ ایک ہموار نجی حصہ بنایا جائے اور فرض کیا جائے کہ VPN کی حد باقی کام کر دے گی۔ اس کے اندر، وہ ایپلیکیشن جو کلائنٹ پورٹ تک پہنچتی ہے عام طور پر internode پورٹ تک بھی پہنچتی ہے، اور آپریٹر کے انتظامی اوزار اکثر ایپلیکیشن کے ساتھ اسی جمپ ہوسٹ پر ہوتے ہیں۔ ان سب کو اکٹھا ہموار کرنے کا مطلب یہ ہے کہ سمجھوتہ شدہ ایپلیکیشن شناخت کی رسائی پہلے ہی اس کی اپنی استفسارات سے زیادہ ہے۔ تینوں سامعین کو ڈیزائن دستاویز میں تین قطاروں کے طور پر لکھیں، ہر ایک کے ساتھ وہ قاعدہ جو اسے اجازت دیتا ہے، اور خلا کسی کے بنانے سے پہلے نظر آنے لگیں گے۔

کلائنٹس کو کیا چاہیے، اور اس سے زیادہ کچھ نہیں

نافذ شدہ ورژن کے لیے مطلوبہ ایپلیکیشن ذرائع کو کلائنٹ اینڈ پوائنٹس تک اجازت دیں، اور غیر متعلقہ کلسٹر اور انتظامی خدمات کو اس رسائی سے باہر رکھیں۔ پھر دیکھیں کہ ڈرائیور نوڈز کو کیسے دریافت کرتا ہے۔ ایک قابل رسائی ابتدائی رابطہ نقطہ یہ ثابت نہیں کرتا کہ ڈرائیور بعد میں منتخب کردہ ہر نوڈ پتہ اس کلائنٹ سیاق سے قابل رسائی ہے، کیونکہ ڈرائیور کلسٹر سے ساتھی مانگتا ہے اور پھر ان پتوں سے جڑتا ہے جو کلسٹر اعلان کرتا ہے۔

اسی لیے نجی پتوں کی ایک بے میل صورتحال جانی پہچانی ترتیب پیدا کرتی ہے: کامیاب پہلا کنکشن اور پھر وقت کا خاتمہ۔ اعلان شدہ پتے اور کلائنٹ روٹنگ جان بوجھ کر تشکیل دیں؛ ایک بے میل صورتحال درست کرنے کے لیے پورا کلسٹر انٹرنیٹ پر شائع کرنا روٹنگ کی خرابی کو ایک ایسی نمائش سے بدل دیتا ہے جو واپس نہیں لی جا سکتی۔

ایپلیکیشن کی ڈیٹا بیس توثیق اور کردار کی اجازتیں بھی برقرار رکھیں۔ مشترکہ ترجمہ شدہ VPN پتہ بہت سے صارفین یا خدمات کی نمائندگی کر سکتا ہے، اس لیے یہ کبھی الگ ڈیٹا بیس شناختوں کا متبادل نہیں ہوتا۔

کلائنٹ سے نوڈ اور internode کو الگ الگ خفیہ کریں

Apache سیکیورٹی دستاویز کلائنٹ سے نوڈ اور internode خفیہ کاری کو الگ الگ ترتیبات کے طور پر دیکھتا ہے، اور ایک کو فعال کرنا دوسرے کو فعال نہیں کرتا۔ یہ فرق VPN کے اندر بھی لاگو رہتا ہے، کیونکہ سرنگ اپنے حصے کی حفاظت کرتی ہے اور خود بخود ایپلیکیشن کے عمل سے ڈیٹا بیس کے عمل تک یا کلسٹر ارکان کے ہر جوڑے کے درمیان نہیں پھیلتی۔

ایک ترتیب جو دونوں کو واضح طور پر فعال کرتی ہے، ٹیمپلیٹ کی طے شدہ قدر وراثت میں لینے کے بجائے، تقریباً ایسی دکھتی ہے:

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

ان سرور ترتیبات پر جو اختیاری کلائنٹ خفیہ کاری کی اجازت دیتی ہیں، TLS قبول کرنا غیر خفیہ کنکشنز قبول کرنے کے ساتھ ساتھ رہ سکتا ہے، اس لیے ارادے کے بجائے مؤثر پالیسی پڑھیں۔ ہر اس اینڈ پوائنٹ کے لیے سرٹیفکیٹ کے نام، اعتماد کی تقسیم اور تجدید کی منصوبہ بندی کریں جس سے ہر کلائنٹ واقعی رابطہ کرتا ہے؛ ہوسٹ نام کو IP پتے سے بدلنا کلائنٹ کی شناخت کی جانچ بدلتا ہے، صرف اس کا راستہ نہیں۔

انتظام کو اپنے الگ راستے پر رکھیں

internode ٹریفک کو اجازت یافتہ ساتھیوں کا مجموعہ اور اپنی حفاظتی پالیسی چاہیے۔ انتظامی رسائی، بشمول JMX جہاں استعمال ہوتا ہے، الگ سامعین اور اپنی توثیق چاہتی ہے۔ جس ایپلیکیشن کو عام استفسارات بھیجنے کی اجازت ہے اسے اس بنا پر ہر انتظامی صلاحیت کی ضرورت نہیں، اور اس کا الٹ زیادہ برا ہے: ایپلیکیشن کے حصے کے لیے کھلا انتظامی راستہ کسی خرابی سے دوبارہ تعمیر تک کا سب سے مختصر راستہ ہے۔ ان دو سامعین کو الگ الگ لکھیں اور ان کے مالکان کے نام لیں، کیونکہ یہ عام طور پر مختلف ٹیمیں ہوتی ہیں جن کے قواعد حادثاتی طور پر ضم ہو گئے۔

مؤثر کلاؤڈ قواعد، ہوسٹ قواعد اور لسنر ترتیب کو ایک سیدھ میں رکھیں۔ نجی لسنر پھر بھی کسی غیر ارادی ترجمے یا پراکسی کے ذریعے کھل سکتا ہے، اور ایک وسیع عوامی قاعدہ کسی تنگ VPN قاعدے کے پاس خاموشی سے پڑا رہ سکتا ہے جب تک کوئی دونوں کا ایک ساتھ جائزہ نہ لے۔

جہاں آپریٹر کو واقعی انتظامی راستے کی ضرورت ہو، اسے نامزد مالک اور ایپلیکیشن سے کم عمر اسناد دیں۔ اس سے تفویض اس وقت بھی نظر آتی رہتی ہے جب اگلا شخص کلسٹر وراثت میں لیتا ہے۔

ڈیزائن کیا وعدہ کرتا ہے

تینوں وعدوں کو صرف کنیکٹیویٹی ٹیسٹوں کے بجائے حقیقی کرداروں سے جانچیں۔ منظور شدہ ایپلیکیشن کو اپنا اجازت یافتہ کام مکمل کرنا چاہیے اور اس سے زیادہ کچھ نہیں، خارج شدہ ذریعہ کو کلائنٹ کے داخلے پر ناکام ہونا چاہیے، اور ایپلیکیشن کی شناخت کو مخصوص انتظامی راستوں پر مسترد کیا جانا چاہیے۔ کلائنٹ کے دوبارہ رابطے اور نوڈ کے انتخاب کو اسی رول آؤٹ ٹیسٹ میں شامل کریں، کیونکہ دریافت کی غلطیاں وہیں سامنے آتی ہیں۔

ڈیزائن دستاویز میں تین جملوں کے ساتھ ختم کریں: کون سے کلائنٹس استفسار کر سکتے ہیں، کون سے نوڈز رابطہ کر سکتے ہیں، اور کون سے آپریٹر انتظام کر سکتے ہیں۔ VPN کے پیچھے ہونا مفید ٹوپولوجی معلومات ہے، لیکن یہ ان تینوں سوالوں میں سے کسی کا جواب نہیں ہے۔