Identity-Aware Proxy ব্যবহার করলে কি আপনার এখনও VPN দরকার?

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

দুই গেট ভিন্ন জিনিস অনুমোদন করে

অ্যাপ্লিকেশন গেট সিদ্ধান্ত নেয় এই অনুরোধ এই পরিচয় থেকে এই সুরক্ষিত রিসোর্সে পৌঁছাতে পারবে কি না। Google-এর Identity-Aware Proxy পর্যালোচনা ঠিক এই আকারই বর্ণনা করে: HTTPS অ্যাপের সামনে IAM ভূমিকা দ্বারা পরিচালিত কেন্দ্রীয় অনুমোদন স্তর। সীমানা হলো রিসোর্স, আর প্রবেশের একক হলো অনুরোধ। রাউটেড VPN আরও মোটা ও বিস্তৃত কাজ করে: এটি একটি নির্দিষ্ট নেটওয়ার্ক পরিধিতে ক্লায়েন্ট প্রবেশ করায়, তারপর অ্যাপ্লিকেশনই ঠিক করে ওই ক্লায়েন্ট কী করতে পারবে।

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

প্রক্সি যা ঢাকে না, VPN যা ঢাকে

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

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

ক্লায়েন্টের কর্মপ্রবাহ আর্কিটেকচার ডায়াগ্রামের চেয়ে বেশি ঠিক করে

রিডাইরেক্ট ও মাঝে মাঝে MFA চ্যালেঞ্জসহ ব্রাউজার সাইন-ইন বুকমার্কে ক্লিক করা মানুষের জন্য ভালো অভিজ্ঞতা। একটি cron জব, একটি CLI বা একটি বিল্ড এজেন্টের ব্রাউজার নেই এবং ইন্টারঅ্যাকটিভ প্রম্পটের উত্তর দিতে পারে না, তাই এর প্রয়োজন নথিভুক্ত নন-ইন্টারঅ্যাকটিভ পথ অথবা টানেল। সেই প্রয়োজনীয়তার আবিষ্কার সাধারণত ডিজাইন অনুমোদনের পরে ঘটে।

অ্যাপ গোনার আগে ক্লায়েন্ট গুনুন। একটি ড্যাশবোর্ড একশো মানুষকে সেবা দিতে পারে; একটি ডেটাবেস পোর্ট পুরো একটি দলকে আটকে দিতে পারে।

ডিভাইসের অবস্থা কোনো গেটের বৈশিষ্ট্য নয়

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

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

কিছু অবসর দেওয়ার আগে বিকল্প পথগুলো খুঁজুন

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

তারপর হ্যান্ডঅফ লিখুন: নথিভুক্তি, আপডেট, প্রবেশাধিকার সরানো, এবং রাত 2টায় লকআউট হওয়া কারও জন্য পুনরুদ্ধারের পথ। একটি প্রম্পট বা ক্লায়েন্ট অ্যাপ সরানো দলগুলোর মধ্যে দায়িত্ব স্থানান্তর করে; এটি দায়িত্ব মুছে দেয় না।

এই সপ্তাহে সিদ্ধান্ত নিলে পণ্যের তালিকা নয়, কাজের তালিকা দিয়ে শুরু করুন, কোনগুলো ব্রাউজার করতে পারে তা চিহ্নিত করুন, আর বাকিগুলো টিকে থাকা নেটওয়ার্ক প্রবেশাধিকারের যৌক্তিকতা জোগাক।