ফিল্ড ডিভাইসে TLS ও VPN: কোন সীমা কী রক্ষা করে
ফিল্ড ডিভাইসের প্রয়োজন প্রমাণিত অ্যাপ্লিকেশন চ্যানেল, শুধু নেটওয়ার্ক অ্যাক্সেস নয়। TLS কোথায় শেষ হয় তা নির্ণয় করুন এবং ব্যর্থ হলে কী হবে তা ঠিক করুন।
একটি ফিল্ড ডিভাইস কোনো সেবার সঙ্গে সংযোগ খোলে, আর নকশার প্রশ্নটি আসে VPN আর TLS-এর মধ্যে বাছাই হিসেবে। এই কাঠামোটি ভুল, কারণ দুটি আলাদা কাজ করে। TLS অ্যাপ্লিকেশন প্রান্তকে প্রমাণ করে এবং কথোপকথন রক্ষা করে; আর VPN পৌঁছানোর ক্ষমতা নিয়ন্ত্রণ করে ও সহকর্মীদের মধ্যে প্যাকেট রক্ষা করে। ডিভাইস থেকে বাইরের দিকে সংযোগটি অনুসরণ করুন, প্রতিটি স্তরের নিজের উত্তর আছে।
TLS কোথায় শেষ হয় তা বলতে না পারলে অ্যাপ্লিকেশন আসলে কী বিশ্বাস করে তাও বলতে পারবেন না।
TLS আসলে কোথায় শেষ হয় তা খুঁজুন
ডিভাইসের অ্যাপ্লিকেশন থেকে শুরু করুন এবং হ্যান্ডশেক সম্পন্ন করে এমন প্রক্রিয়া পর্যন্ত সংযোগটি অনুসরণ করুন। যদি কোনো প্রক্সি মেইনফ্রেমের আগেই TLS শেষ করে, তবে সুরক্ষিত পথ প্রক্সিতেই শেষ হয়। বাকি ধাপটির নিজস্ব নথিভুক্ত সুরক্ষা দরকার।
অনুমান করে এটিকে এন্ড-টু-এন্ড বলা—এইভাবেই নকশা পর্যালোচনা একটি ফাঁক অনুমোদন করে। সমাপ্তি বিন্দু আর বিশ্বাসের নোঙর একই চিত্রে আঁকুন।
TLS উভয় দিকে অনুরোধ ও উত্তর বহন করে, তাই দ্বিমুখী অ্যাপ্লিকেশনের স্বভাবত TLS-এর বদলে VPN দরকার হয় না। উল্টোটাও সত্য: একই ডিভাইসে অন্য প্রোটোকলের জন্য স্থাপনার এখনও VPN দরকার হতে পারে।
ডিভাইসকে কী প্রমাণ করতে হবে তা ঠিক করুন
সার্ভারের পরিচয় যাচাই ও উদ্দিষ্ট বিশ্বাস-মূল কনফিগার করুন। যদি প্রতিটি ডিভাইসকে নিজের পরিচয় প্রমাণ করতে হয়, তবে সমর্থিত ক্লায়েন্ট-প্রমাণকরণ মডেল বেছে নিন এবং প্রতিটি ডিভাইসের জন্য আলাদা ক্রেডেনশিয়াল নিবন্ধন করুন। ভাগ করা ক্রেডেনশিয়াল একটি চুরি যাওয়া ডিভাইসকে পুরো বহরের সমস্যা বানিয়ে দেয়।
পাঠানোর আগে চাবি সুরক্ষা, নবায়ন, বাতিলকরণ ও পুনরুদ্ধারের পরিকল্পনা করুন। মাঠে থাকা ডিভাইস যদি ব্যর্থ নবায়নের পর পুনরায় নিবন্ধিত হতে না পারে, তবে সেটি মাঠে পরিদর্শনে পরিণত হয়, আর সেই ব্যয় হ্যান্ডশেকের চেয়ে বেশি নকশা গড়ে তোলে।
সমর্থিত লাইব্রেরি ও সাম্প্রতিক নির্দেশনা ব্যবহার করুন। আধুনিক TLS স্থাপনার নির্দেশনা TLS 1.0 ও 1.1 নিয়ে দর-কষাকষি নিষিদ্ধ করে, আর পুরোনো নকশা নোটে থাকা TLSv1 উল্লেখ কোনো বাধ্যবাধকতা নয়।
হ্যান্ডশেক ব্যর্থ হলে বন্ধ রাখুন
ব্যর্থ হ্যান্ডশেক বা পরিচয় যাচাই কদানো নীরবে মূল স্পষ্ট-পাঠ্য প্রোটোকলে ফিরে যেতে পারবে না। সেই প্রত্যাবর্তনই সেই দুর্বলতা যা TLS-এর কাজ বন্ধ করার কথা ছিল। ব্যর্থতা ডিভাইস অপারেটর ও সেবার কাছে দৃশ্যমান করুন, এবং সংবেদনশীল কাজের জন্য সুরক্ষিত চ্যানেল বাধ্যতামূলক করুন। তারপর অ্যাপ্লিকেশন অনুমোদন ঠিক করুক প্রমাণিত ডিভাইস কী করতে পারে।
সংযোগের আয়ু, ফ্রেমিং, সময়সীমা ও পুনঃচেষ্টার আচরণ চুক্তির অংশ হিসেবে নির্ধার্য করুন। এনক্রিপশন বারবার পাঠানো কমান্ডকে নিরাপদ করে না, আর অনিশ্চিত আগের কাজের পর পুনঃচেষ্টার জন্য অ্যাপ্লিকেশন স্তরের উত্তর দরকার।
প্রত্যাবর্তনের নিয়মটি লিখে রাখুন। “হ্যান্ডশেক ব্যর্থ হলে এটি TLS ছাড়াই আবার সংযুক্ত হয়” একটি নকশা সিদ্ধান্ত, এবং তা স্পষ্ট হওয়া উচিত।
VPN-কে কেবল সেই কাজ দিন যা এটি করতে পারে
VPN পৌঁছানোর ক্ষমতা সীমিত করতে পারে এবং নিজের সহকর্মী পর্যন্ত প্যাকেট রক্ষা করতে পারে। TLS নির্বাচিত প্রান্তের সঙ্গে অ্যাপ্লিকেশনের সম্পর্ক রক্ষা করে। তাদের সমাপ্তি বিন্দু ভিন্ন হতে পারে, আর কোনোটিই প্রান্তের সংরক্ষিত তথ্য বা প্রশাসনিক প্রবেশ সুরক্ষিত করে না।
একটি পদ্ধতি দ্রুততর ধরে নেইয়ে প্রকৃত ডিভাইসে হ্যান্ডশেকের ব্যয়, স্থির বার্তালাপ ও পুনঃসংযোগ মাপুন। তারপর গুরুত্বপূর্ণ চারটি ক্ষেত্রে পরীক্ষা করুন: উদ্দিষ্ট বিনিময়, ভুল সার্ভার পরিচয়, অননুমোদিত ডিভাইস, এবং অনিশ্চিত কাজের পর পুনঃসংযোগ। প্রতিটি ক্ষেত্রের ফলাফল লিখুন, ডিভাইস যে ত্রুটি দেখায় তা সহ।