Firebird 3-এর ওয়্যার এনক্রিপশন আর VPN দুটি আলাদা সীমা

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

দুটি সীমা, আর তারা একে অপরকে ছোঁয় না

VPN সীমা ক্লায়েন্ট ও গেটওয়ের মধ্যে প্যাকেট রক্ষা করে। Firebird-এর ওয়্যার এনক্রিপশন ক্লায়েন্ট লাইব্রেরি ও সার্ভার প্রসেসের মধ্যে ডেটাবেস প্রোটোকল রক্ষা করে। দুটোই একসাথে থাকতে পারে, আর কোনোটিই অন্যটির বিকল্প নয়।

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

সীমা এক: কে লিসেনার খুলতে পারে

প্রকৃত সার্ভার ঠিকানা ও কনফিগার করা পোর্ট শনাক্ত করুন, যা পরিবর্তন না করা হলে 3050, তারপর হোস্ট ও নেটওয়ার্ক ফায়ারওয়ালে কেবল অনুমোদিত VPN সূত্রগুলোকে অনুমতি দিন। VPN গেটওয়েতে কোনো ঠিকানা রূপান্তর থাকলে তা হিসাবে নিন, এবং গেটওয়ে আলাদা হলে ডেটাবেস হোস্টকে ক্লায়েন্ট পুলের দিকে ফেরত যাওয়ার রুট দিন।

তারপর নেতিবাচকটি প্রমাণ করুন। যে বাহ্যিক পথ প্রত্যাখ্যাত হওয়া উচিত, তা প্রত্যাখ্যাতই থাকতে হবে, কারণ টানেল খোলা নিজে থেকে Firebird লিসেনারকে সীমাবদ্ধ করে না।

সীমা দুই: Firebird কী নিয়ে নেগোশিয়েট করে

Firebird 3 একটি ওয়্যার-এনক্রিপশন কাঠামো চালু করেছে, যাতে সার্ভার নীতি নিষ্ক্রিয়, সক্রিয় বা বাধ্যতামূলক রাখা যায়। নীতিটি ন্যূনতম সীমা ঠিক করে। প্রকৃত সেশন তবুও নির্ভর করে অ্যাপ্লিকেশন যে ক্লায়েন্ট লাইব্রেরি লোড করে এবং দুই পক্ষ যে প্লাগইন সমর্থন করে তার উপর।

Firebird 3-এর রিলিজ নোটে Arc4-কে ওই রিলিজের ডিফল্ট ওয়্যার-এনক্রিপশন প্লাগইন হিসেবে তালিকাভুক্ত করা হয়েছে। Arc4 একটি ঐতিহাসিক ডিফল্ট, আধুনিক সাইফারের সুপারিশ নয়, আর এটি বাইরের VPN সুরক্ষার সমান কিছু নয়।

প্রমাণীকরণ একই নেগোশিয়েশনে তৃতীয় চলক। সার্ভার একগুচ্ছ প্রমাণীকরণ প্লাগইন গ্রহণ করে, ক্লায়েন্ট লাইব্রেরি তার একটি উপসেট প্রস্তাব করে, এবং দুটিকে অবশ্যই মিলতে হবে।

Legacy_Auth ফাঁদ

Legacy_Auth সমর্থন করতে সার্ভারের ডিফল্ট বাধ্যতামূলক-এনক্রিপশন নীতি শিথিল করতে হয়। এটাই নথিভুক্ত সামঞ্জস্যের খরচ, আর সে কারণেই সংযোগের ত্রুটি চুপ করাতে নীতি নামিয়ে আনা সমাধান নয়, নিরাপত্তার পরিবর্তন।

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

যে সংযুক্তি গুরুত্বপূর্ণ তা যাচাই করুন

যে বিল্ডে কনটেক্সট ভেরিয়েবলটি আছে, সেখানে এই কোয়েরি বর্তমান সংযুক্তি-এর এনক্রিপশন অবস্থা জানায়:

SELECT RDB$GET_CONTEXT('SYSTEM', 'WIRE_ENCRYPTED')
FROM RDB$DATABASE;

এটি অ্যাপ্লিকেশনের নিজের সংযোগ দিয়ে চালান, একই সার্ভারে প্রশাসকের সেশন দিয়ে নয়। এনক্রিপ্টেড অ্যাডমিন সংযুক্তি অন্য ক্লায়েন্ট লাইব্রেরির সেশন সম্পর্কে কিছুই বলে না, আর ভেরিয়েবলটি সমর্থন করে না এমন পুরোনো বিল্ড এনক্রিপশন বন্ধ থাকার প্রমাণ নয়।

ক্লায়েন্ট লাইব্রেরির সংস্করণ, সার্ভার বিল্ড ও ফলাফল একসাথে লিখে রাখুন, কারণ এর যেকোনো একটি একা পড়া যায় না।

অনুমতিসমূহ ও আপগ্রেডের পথ

সূত্র সীমিত করা ও ট্রান্সপোর্ট এনক্রিপ্ট করা প্রমাণীকরণ বা ন্যূনতম-বিশেষাধিকার অনুমতির বিকল্প নয়। সাধারণ ডেটাবেস ব্যবহারকারীর যে বস্তুগুলোতে সত্যিই হাত পড়ে, সেগুলোতে তার অনুমতি যাচাই করুন।

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