সাময়িক IP অনুমোদন-তালিকার লিঙ্ক: অনুদানটি আসলে কী অনুমোদন করে

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

অনুদানটি কোন প্রশ্নের উত্তর দেয় তা ঠিক করুন

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

ব্যবহারকারীমুখী অ্যাপ্লিকেশনের জন্য ঠিকানা-অনুমোদন বেছে নিলে প্রকৃত অনুমোদন সমস্যাটি অন্য জায়গায় সরে যায়, আর তারপর পোর্টাল এমন একটি ফাঁকের দায় উত্তরাধিকারসূত্রে পায় যা এটি কখনো বন্ধ করেনি।

সার্ভারে অনুরোধের সীমা নির্ধারণ করুন

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

তারপর যাচাই করুন যে পোর্টাল ও সেবা একই উৎস দেখছে। বিভক্ত টানেলিং, একটি প্রক্সি হপ এবং IPv4 বনাম IPv6 দুটি গন্তব্যকে দুটি ভিন্ন ঠিকানা দিতে পারে, তাই এক পথ থেকে সক্রিয় করা অনুদান পরের অনুরোধটি ঢাকতে নাও পারে।

স্থাপনের আগে অনুদানটি দেখান

লিঙ্ক খুললে প্রস্তাবিত সেবা, পর্যবেক্ষিত উৎস ও সময়কাল দেখানো উচিত, এবং তখনো কিছুই বদলানো উচিত নয়। এই একটি ধাপই ইমেইলে আসা লিঙ্ককে কাজ থেকে প্রস্তাবে বদলে দেয়, এবং প্রিভিউ বট বা মেইল স্ক্যানারকে কেবল তা লোড করেই প্রবেশাধিকার দেওয়া থেকে বিরত রাখে।

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

টোকেন সরবরাহ নিয়মটির মতোই যত্ন দাবি করে। মেয়াদোত্তীর্ণ বা ইতিমধ্যে ব্যবহৃত একটি লিঙ্ক যদি এখনো নিয়ম তৈরি করে, তবে তা একই চাবি দিয়ে লাগানো দ্বিতীয় দরজা।

অনুদান সক্রিয় থাকলেও ঠিকানাটি ভাগাভাগি হয়

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

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

চারটি ক্ষেত্র এবং উভয় ঠিকানা-পরিবার পরীক্ষা করুন

একটি অনুদান ততটুকুই ভালো যতগুলো ক্ষেত্র এটি টিকে থাকে: একটি নতুন অনুমোদিত অনুরোধ, একটি অননুমোদিত অনুরোধকারী, একই লিঙ্কের পুনরাবৃত্তি, এবং মেয়াদ শেষের পরে একই অনুরোধ।

তারপর প্রতিটি পরিবার আলাদাভাবে পরীক্ষা করুন, কারণ সেবা যে উৎস-ঠিকানা পর্যবেক্ষণ করে তা এদের মধ্যে ভিন্ন হতে পারে।

dig +short A service.example.com
dig +short AAAA service.example.com
curl -4 -sS -o /dev/null -w "%{http_code}\n" https://service.example.com
curl -6 -sS -o /dev/null -w "%{http_code}\n" https://service.example.com

উপকারী ফল হলো সাধারণ ব্যবহারকারী অনুমোদনের অধীনে থাকা একটি সাময়িক, নিরীক্ষাযোগ্য প্রবেশ-সিদ্ধান্ত, প্রথমে যে ক্লিক করেছিল তার নাম বহনকারী স্থায়ী খোলা দ্বার নয়।