পোর্টের মাঝের ফায়ারওয়াল কোনো হোস্ট সীমা নয়

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

আলাদা সার্ভিস নাম একটি লেবেল; আলাদা পরিচয় একটি নিরাপত্তা বৈশিষ্ট্য।

পোর্ট নয়, ওয়ার্কারের কর্তৃত্ব গুনুন

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

ডেমন চালু হওয়ার সময় একটি VPN কী পড়া যায় মানে এই নয় যে ওয়েব ওয়ার্কারের সেটি দরকার। ডেমন যে পড়া করে তা অ্যাপ্লিকেশনকে দেওয়া অ্যাক্সেস থেকে আলাদা করুন।

যে সকেট দেখতে যতটা, তার চেয়ে বেশি দেয়

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

ম্যানেজমেন্ট লিসেনারকে লোকাল ঠিকানায় বাঁধা একটি সূচনা, সম্পূর্ণ নিষেধ নয়, কারণ ওই ঠিকানার প্রতিটি প্রবেশপথ এখনও গুরুত্বপূর্ণ। কেবল অভিপ্রেত উৎস ও ইন্টারফেসের অনুমতি দিন।

কনটেইনাররা একটি কার্নেল ভাগ করে

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

যে জটিল ব্যবস্থা কেউ রক্ষণাবেক্ষণ করে না, তা সত্যিই পর্যালোচিত সরল ব্যবস্থার চেয়ে খারাপ।

আগে প্রত্যাখ্যান, তারপর সার্ভিস পরীক্ষা করুন

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

উভয় ভূমিকা এখনও CPU, মেমরি, আপলিংক ক্ষমতা ও রক্ষণাবেক্ষণ ইভেন্ট ভাগ করে। ওই ভাগ করা সম্পদ পরিকল্পনায় থাকা উচিত, এমনকি যখন কর্তৃত্বের সীমা পরিষ্কার।

প্রতিটি প্রক্রিয়া কী করতে পারে, থামলে কী ব্যর্থ হয় এবং কোন সীমা ভাগ করা থাকে তা লিখে রাখুন। পোর্ট গণনা সেই রেকর্ড নয়।