অ্যাপ mTLS ও SSO ব্যবহার করলে সাইট VPN কি এখনও দরকার?
আপনার অ্যাপ লগইন কখনও যে চ্যানেলগুলো ঢাকে না সেগুলো ধরে হাঁটুন, তারপর ঠিক করুন প্রাইভেট নেটওয়ার্ক অ্যাক্সেস অপ্রয়োজনীয় কি না, নাকি হোস্টে পৌঁছানোর একমাত্র পথ এখনও সেটিই।
আপনি mTLS দিয়ে সাইন ইন করেন, ড্যাশবোর্ড লোড হয়, আর সাইট VPN এখন অপ্রয়োজনীয় এই দাবিটি ঠিক ততক্ষণ যুক্তিসঙ্গত শোনায় যতক্ষণ না রাত দুইটায় একটি ডেটাবেস রিস্টোর করতে হয়। অ্যাপের TLS সীমা একটি মাত্র চ্যানেল বর্ণনা করে। হোস্ট, ডেটাবেস, ব্যাকআপ গন্তব্য ও ক্লাউড অ্যাকাউন্ট, প্রত্যেকের নিজস্ব প্রবেশপথ, নিজস্ব পরিচয় ও নিজস্ব অনুমোদনকারী আছে, এবং সফল লগইন তাদের কোনোটিকেই যাচাই করে না।
লগইন স্ক্রিন থেকে বাইরের দিকে হাঁটুন
সাধারণ ব্যবহারকারীর মতো সাইন ইন করুন এবং অনুরোধটি যে প্রতিটি ধাপ স্পর্শ করে তা লিখে রাখুন: ব্রাউজার, এজ, অ্যাপ্লিকেশন লিসেনার, সেশন স্টোর, ব্যাকএন্ড API। প্রতিটি ধাপের একটি মালিক ও একটি প্রমাণীকরণ সিদ্ধান্ত থাকে। এবার হোস্টে প্যাচ দেওয়া ব্যক্তির জন্য এবং রাতের ব্যাকআপ লেখা কাজটির জন্য হাঁটাটি আবার করুন। সাধারণত প্রথম ধাপেই ওই হাঁটাগুলো আলাদা হয়ে যায়।
এই বিচ্ছেদই সেই প্রশ্ন যার উত্তর দেওয়া মূল্যবান। সাইট টানেল তখনই অপ্রয়োজনীয়, যখন দ্বিতীয় ওই হাঁটার প্রতিটি চ্যানেলের নিজস্ব প্রবেশ ও অনুমোদন নীতি স্বতন্ত্রভাবে দাঁড়িয়ে থাকে।
অ্যাপ লগইন কখনও যে পাঁচটি চ্যানেল ঢাকে না
নিচের সারণিটি একটি ইনভেন্টরি টেমপ্লেট, ডিপ্লয়মেন্ট চেকলিস্ট নয়। দ্বিতীয় কলামটি আপনার নিজের পরিবেশ আজ সত্যিই যা প্রয়োগ করে তা দিয়ে পূরণ করুন।
| Channel | Access decision to identify |
|---|---|
| Application API | Accepted TLS peer, application identity, permitted operations |
| Operating-system administration | Approved entry path, administrative identity, host permissions |
| Database maintenance | Database identity, protected connection, authorized maintenance role |
| Backup and restore | Service identity, allowed source, access to stored copies |
| Cloud control plane | Account and role permissions governing infrastructure changes |
একই পরিচয় প্রদানকারী ভাগ করা এই অনুমোদনগুলোকে একত্র করে না। যে ব্যবহারকারী API অনুরোধ পাঠাতে পারেন, তিনি এর দ্বারা VM ডিস্ক বদলাতে বা অ্যাপের ক্রেডেনশিয়াল দিয়ে ডেটাবেস রিস্টোর করতে অনুমোদিত হন না। NIST-এর জিরো-ট্রাস্ট আর্কিটেকচার সারসংক্ষেপ ঠিক এই কারণেই রিসোর্স প্রমাণীকরণ ও অনুমোদনকে নেটওয়ার্ক অবস্থান থেকে আলাদা রাখে।
যে সাপোর্ট ইঞ্জিনিয়ার একটি টিকেট পড়তে পারেন, তিনি এর দ্বারা তার পেছনের হোস্টে কনসোল খুলতে অনুমোদিত হন না।
পথ তখনই বাস্তব, যখন বিকল্পটি বন্ধ থাকে
প্রাইভেট প্রশাসনিক লিসেনারে পৌঁছানোর সীমাবদ্ধতা রাখা সাইট টানেলের বৈধ বিকল্প, শর্ত হলো সীমাবদ্ধতা কার্যকরভাবে প্রয়োগ হয়, শুধু কাগজে আঁকা না থাকে। সাধারণ ব্যর্থতা হলো এমন একটি বিকল্প লিসেনার যা কেউ মনে রাখেনি: সব ইন্টারফেসে বাঁধা থাকা একটি সার্ভিস, ঠিকাদারের জন্য খোলা একটি সিকিউরিটি গ্রুপ নিয়ম, ইন্টারনেট থেকে পৌঁছানো যায় এমন একটি ম্যানেজমেন্ট পোর্ট।
ডায়াগ্রাম নয়, লিসেনার পরীক্ষা করুন। হোস্টে ss -ltnp দিয়ে আসলে কী বাঁধা আছে তা তালিকাভুক্ত করুন এবং প্রশাসনিক পোর্টগুলো প্রাইভেট ঠিকানায় আছে কি না নিশ্চিত করুন। ক্লাউড কনসোলে ওয়ার্কলোড সাবনেটের ইনবাউন্ড নিয়ম পড়ুন এবং প্রশাসনিক কিছুর উপর 0.0.0.0/0 আছে কি না দেখুন। তারপর প্রাইভেট পথের বাইরে থেকে সংযোগটি চেষ্টা করুন, কারণ সেই পরীক্ষাটিই প্রশ্নের উত্তর দেয়।
SSH-এ একটি মাত্র বিশ্ব-উন্মুক্ত নিয়ম টানেল ডিজাইনের প্রতিটি যুক্তি নষ্ট করে দেয়।
ডিজাইন তুলনার আগে মানচিত্র লিখুন
ইনভেন্টরির প্রতিটি সারির জন্য লিখে রাখুন কে পরিচয় অনুমোদন করে, কে অ্যাক্সেস নিয়ম হালনাগাদ করে, কেউ চলে গেলে কে ক্রেডেনশিয়াল সরায়, আর পথ নিজেই ভেঙে গেলে কে পুনরুদ্ধার সামলায়। প্রতি সারিতে চারটি নামই যথেষ্ট সেই সারিগুলো উন্মোচন করতে যেখানে উত্তর হলো একটি ভাগ করা অ্যাকাউন্ট আর তিন বছরের পুরোনো একটি উইকি পাতা।
তারপর প্রতিটি চ্যানেলে একটি অনুমোদন ও একটি প্রত্যাখ্যান যাচাই করুন। অনুমোদন প্রমাণ করে যে উদ্দিষ্ট পরিচয় উদ্দিষ্ট পথে রিসোর্সে পৌঁছাতে পারে। প্রত্যাখ্যান প্রমাণ করে যে অনুরূপ পরিচয় পারে না, আর এই পরীক্ষাটিই মানুষ এড়িয়ে যায়, তাই অডিটেও বিকল্প লিসেনারগুলো টিকে থাকে। প্রস্তাবিত ডিজাইনকে এই ফলাফলের সাথে মেলান, অ্যাপের TLS কনফিগারেশনের সাথে নয়, কারণ তা এগুলোর কোনোটিই কখনও যাচাই করেনি।
কোথায় সাইট টানেল এখনও জায়গা পায়
কোনো রিসোর্সের নিজস্ব প্রতি-অনুরোধ প্রমাণীকরণ না থাকলে টানেল বা সংকীর্ণ গেটওয়েই সঠিক উত্তর: ডেটাবেস রক্ষণাবেক্ষণ পোর্ট, ব্যাকআপ গন্তব্য, হাইপারভাইজার কনসোল, আউট-অব-ব্যান্ড ম্যানেজমেন্ট। ওই লিসেনারগুলো নেটওয়ার্ককে বিশ্বাস করে, তাই কলারকে প্রমাণীকরণ করতে হবে নেটওয়ার্ককেই।
এটিই একমাত্র উত্তর নয়। যে গেটওয়ে প্রতি-রিসোর্স অনুমোদন শেষ করে সেটি সাবনেট-ব্যাপী টানেলের চেয়ে সংকীর্ণ হতে পারে, এবং ভাগ করা জাম্প হোস্টের চেয়ে ভালো অডিট ট্রেইল রাখে।
কাজের ক্রম: ইনভেন্টরি শেষ করুন, বিকল্পগুলো বন্ধ করুন, প্রতি সারিতে একটি প্রত্যাখ্যান যাচাই করুন, তারপরেই টানেল প্রত্যাহার করুন। কোনো সারি প্রত্যাখ্যান তৈরি করতে না পারলে, পারা পর্যন্ত প্রাইভেট পথটি রাখুন।