VPN-এর মাধ্যমে Cassandra: ক্লায়েন্ট ও নোডকে আলাদা অ্যাক্সেস দিন

একটি Cassandra স্থাপনার একটিই সর্বজনীন ডেটাবেস নেটওয়ার্ক থাকে না। অ্যাপ্লিকেশনগুলো ক্লায়েন্ট সার্ভিসের সাথে কথা বলে, ক্লাস্টারের সদস্যরা একে অন্যের সাথে কথা বলে, আর অপারেটররা প্রশাসনিক ইন্টারফেস ব্যবহার করে, এবং এই তিন ধরনের ব্যবহারকারী একে অন্যের পৌঁছানোর সীমা উত্তরাধিকার সূত্রে পাওয়া উচিত নয়। VPN-এর মতো একটি ব্যক্তিগত পথ ভালো সূচনা বিন্দু, কিন্তু এটি ডেটাবেসের ব্যবহারকারী পরিচয় নয় এবং এটি তার এনক্রিপশন নীতি নয়। সংযোগের সিদ্ধান্ত ও অনুমোদনের সিদ্ধান্তকে দুটি পৃথক পর্যালোচনা হিসেবে দেখুন।

তিন ধরনের ব্যবহারকারীর প্রত্যেকের নিজস্ব উত্তর আছে, এবং নিচের অংশগুলো ঝুঁকির ক্রম অনুসারে তাদের আলোচনা করে।

তিন ব্যবহারকারী, তিন সিদ্ধান্ত

কোনো নিয়মে হাত দেওয়ার আগে প্রতিটি গোষ্ঠীর আসলে কী দরকার তা চিহ্নিত করুন। ক্লায়েন্টদের দরকার ক্লায়েন্ট লিসেনার এবং তাদের হাতে আসতে পারে এমন প্রতিটি নোডে পৌঁছানোর মতো যথেষ্ট তথ্য, পিয়ার নোডগুলোর দরকার ইন্টারনোড পোর্টে একে অন্যকে, আর অপারেটরদের দরকার ম্যানেজমেন্ট ইন্টারফেস যা রানবুক আসলে দাবি করে। তিনটি তালিকা, তিন ধরনের ব্যবহারকারী, তিন স্তরের আস্থা।

সাধারণ ভুল হলো একটি সমতল ব্যক্তিগত সেগমেন্ট বানিয়ে ধরে নেওয়া যে VPN সীমানা বাকিটা করে দেবে। এর ভেতরে যে অ্যাপ্লিকেশন ক্লায়েন্ট পোর্টে পৌঁছাতে পারে সে সাধারণত ইন্টারনোড পোর্টেও পৌঁছাতে পারে, আর অপারেটরের প্রশাসনিক সরঞ্জাম প্রায়ই অ্যাপ্লিকেশনের মতো একই জাম্প হোস্টে থাকে। এগুলোকে একসাথে সমতল করার অর্থ হলো একটি আপসকৃত অ্যাপ্লিকেশন পরিচয়ের ইতিমধ্যেই নিজের কোয়েরির চেয়ে বেশি পৌঁছানো আছে। নকশা নথিতে তিন ধরনের ব্যবহারকারীকে তিনটি সারি হিসেবে আঁকুন, প্রতিটির সাথে যে নিয়মটি তা অনুমোদন করে, আর ফাঁকগুলো যে কেউ তা বানানোর আগেই দেখা যাবে।

ক্লায়েন্টদের যা দরকার, এবং তার বেশি কিছু নয়

স্থাপিত সংস্করণের জন্য নির্ধারিত অ্যাপ্লিকেশন উৎসগুলোকে ক্লায়েন্ট এন্ডপয়েন্টে অনুমতি দিন, এবং অসংশ্লিষ্ট ক্লাস্টার ও ম্যানেজমেন্ট সার্ভিসগুলোকে সেই পৌঁছানোর বাইরে রাখুন। তারপর ড্রাইভার কীভাবে নোড আবিষ্কার করে তা যাচাই করুন। একটি পৌঁছানো যায় এমন প্রাথমিক যোগাযোগ বিন্দু প্রমাণ করে না যে ড্রাইভার পরে বেছে নেওয়া প্রতিটি নোড ঠিকানা ওই ক্লায়েন্ট প্রসঙ্গ থেকে পৌঁছানো যায়, কারণ ড্রাইভার ক্লাস্টারের কাছে সমকক্ষদের জিজ্ঞাসা করে এবং তারপর ক্লাস্টার যে ঠিকানাগুলো প্রচার করে সেগুলোতে সংযোগ করে।

এই কারণেই একটি ব্যক্তিগত ঠিকানার অমিল পরিচিত ধরনটি তৈরি করে: সফল প্রথম সংযোগ, তারপর সময় শেষ হওয়া। প্রচারিত ঠিকানা ও ক্লায়েন্ট রাউটিং সচেতনভাবে কনফিগার করুন; একটি অমিল সারাতে গিয়ে পুরো ক্লাস্টার ইন্টারনেটে প্রকাশ করা একটি রাউটিং ত্রুটির বিনিময়ে এমন প্রকাশ দেয় যা ফেরানো যায় না।

অ্যাপ্লিকেশনের ডেটাবেস প্রমাণীকরণ ও ভূমিকার অনুমতিও যথাস্থানে রাখুন। একটি ভাগ করা অনূদিত VPN ঠিকানা অনেক ব্যবহারকারী বা সার্ভিসের প্রতিনিধিত্ব করতে পারে, তাই এটি কখনোই আলাদা ডেটাবেস পরিচয়ের বিকল্প নয়।

ক্লায়েন্ট-থেকে-নোড ও ইন্টারনোড আলাদাভাবে এনক্রিপ্ট করুন

Apache-এর নিরাপত্তা নথি ক্লায়েন্ট-থেকে-নোড ও ইন্টারনোড এনক্রিপশনকে আলাদা কনফিগারেশন হিসেবে দেখে, এবং একটি চালু করলে অন্যটি চালু হয় না। এই পার্থক্য VPN-এর ভেতরেও প্রযোজ্য, কারণ টানেল নিজের সেগমেন্ট রক্ষা করে এবং অ্যাপ্লিকেশন প্রসেস থেকে ডেটাবেস প্রসেসে বা ক্লাস্টারের প্রতিটি জোড়া সদস্যের মধ্যে স্বয়ংক্রিয়ভাবে বিস্তৃত হয় না।

যে কনফিগারেশন টেমপ্লেটের ডিফল্ট উত্তরাধিকার না করে দুটিই স্পষ্টভাবে চালু করে, তা মোটামুটি এমন দেখায়:

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

যেসব সার্ভার কনফিগারেশন ঐচ্ছিক ক্লায়েন্ট এনক্রিপশন অনুমোদন করে, সেখানে TLS গ্রহণ করা অনেনক্রিপ্টেড সংযোগ গ্রহণের সাথে সহাবস্থান করতে পারে, তাই উদ্দেশ্য নয়, কার্যকর নীতি পড়ুন। সার্টিফিকেটের নাম, আস্থা বিতরণ ও নবায়ন প্রতিটি ক্লায়েন্ট যে এন্ডপয়েন্টে আসলে যোগাযোগ করে তার জন্য পরিকল্পনা করুন; হোস্টনেমের জায়গায় IP ঠিকানা বসালে ক্লায়েন্টের পরিচয় যাচাই বদলে যায়, শুধু তার রুট নয়।

প্রশাসনকে নিজের পথে রাখুন

ইন্টারনোড ট্রাফিকের দরকার অনুমোদিত সমকক্ষ সেট ও নিজস্ব সুরক্ষা নীতি। প্রশাসনিক অ্যাক্সেস, যেখানে ব্যবহৃত হয় সেখানে JMX সহ, দরকার আলাদা ব্যবহারকারীগোষ্ঠী ও নিজস্ব প্রমাণীকরণ। সাধারণ কোয়েরি দেওয়ার অনুমতি পাওয়া একটি অ্যাপ্লিকেশনের তাই প্রতিটি ম্যানেজমেন্ট সক্ষমতা দরকার হয় না, আর উল্টোটা আরও খারাপ: অ্যাপ্লিকেশন সেগমেন্টে উন্মুক্ত প্রশাসনিক পথ বাগ থেকে পুনর্নির্মাণ পর্যন্ত সবচেয়ে ছোট পথ। ওই দুটি ব্যবহারকারীগোষ্ঠীকে আলাদাভাবে লিখে রাখুন এবং তাদের মালিকদের নাম দিন, কারণ এরা সাধারণত ভিন্ন দল যাদের নিয়ম দুর্ঘটনাক্রমে মিলিয়ে ফেলা হয়েছে।

কার্যকর ক্লাউড নিয়ম, হোস্ট নিয়ম ও লিসেনার কনফিগারেশন সামঞ্জস্যপূর্ণ রাখুন। একটি ব্যক্তিগত লিসেনারও অনিচ্ছাকৃত অনুবাদ বা প্রক্সির মাধ্যমে উন্মুক্ত থাকতে পারে, আর একটি প্রশস্ত পাবলিক নিয়ম নীরবে একটি সংকীর্ণ VPN নিয়মের পাশে বসে থাকতে পারে যতক্ষণ না কেউ একসাথে দুটিই নিরীক্ষা করে।

যেখানে অপারেটরদের সত্যিই ম্যানেজমেন্ট পথ দরকার, সেখানে তাকে একটি নামযুক্ত মালিক ও অ্যাপ্লিকেশনের চেয়ে কম মেয়াদের প্রমাণপত্র দিন। এতে পরবর্তী ব্যক্তি ক্লাস্টারের দায়িত্ব পেলে প্রতিনিধিত্ব দৃশ্যমান থাকে।

নকশা যা প্রতিশ্রুতি দেয়

তিনটি প্রতিশ্রুতিই কেবল সংযোগ পরীক্ষা দিয়ে নয়, বাস্তব ভূমিকা দিয়ে যাচাই করুন। অনুমোদিত একটি অ্যাপ্লিকেশন তার অনুমোদিত কাজ শেষ করবে এবং তার বেশি কিছু নয়, বাদ দেওয়া একটি উৎস ক্লায়েন্ট প্রবেশপথে ব্যর্থ হবে, এবং একটি অ্যাপ্লিকেশন পরিচয় সংরক্ষিত প্রশাসনিক পথে প্রত্যাখ্যাত হবে। একই রোলআউট পরীক্ষায় ক্লায়েন্টের পুনঃসংযোগ ও নোড নির্বাচন যোগ করুন, কারণ আবিষ্কারের ভুলগুলো ঠিক সেখানেই প্রকাশ পায়।

নকশা নথিতে তিনটি বাক্যে শেষ করুন: কোন ক্লায়েন্টরা কোয়েরি করতে পারে, কোন নোডগুলো যোগাযোগ করতে পারে এবং কোন অপারেটররা প্রশাসন করতে পারে। VPN-এর পেছনে থাকা দরকারি টপোলজি তথ্য, কিন্তু এটি ওই তিনটি প্রশ্নের কোনোটিরই উত্তর নয়।