FortiGate VPN MFA: স্থানীয় টোকেন, RADIUS নাকি SAML?

প্রতিটি FortiGate VPN MFA নকশা প্রথমে একটি প্রশ্নের উত্তর দেয়: দ্বিতীয় ফ্যাক্টর কে যাচাই করে? গেটওয়ে নিজেই এটি করতে পারে স্থানীয় টোকেন বা ইমেইলে পাঠানো কোড দিয়ে, RADIUS ব্যাকএন্ড এটি প্রয়োগ করে একটি চ্যালেঞ্জ ফিরিয়ে দিতে পারে, অথবা SAML পরিচয় প্রদানকারী ব্রাউজারে পুরো অনুষ্ঠানটি নিজের হাতে নিতে পারে। এগুলোর প্রতিটি ভিন্ন লগইন ক্রম, ভিন্ন ব্যর্থতার ছাপ ও ভিন্ন পুনরুদ্ধার পদ্ধতি তৈরি করে, আর একটির কমান্ড ব্লক অন্যটিতে কপি করলে এমন কনফিগারেশন হয় যা বিশ্বাসযোগ্য দেখায় কিন্তু কাউকে প্রমাণিত করে না। এটি একটি প্রক্রিয়া-নিবন্ধ: লগইনের সময় প্রতিটি নকশা আসলে কী করে এবং কোথায় ভাঙে।

লগইন অনুষ্ঠানই ঠিক করে ফ্যাক্টরের মালিক কে

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

এই পার্থক্যই ঠিক করে আপনি কোন প্রমাণ সংগ্রহ করতে পারবেন। গেটওয়ে যখন যাচাই করে, তার নিজের ডিবাগ আউটপুট আপনাকে বলে কী ঘটেছে। পরিচয় প্রদানকারী যখন যাচাই করে, গেটওয়ে কেবল জানে একটি দাবি এসেছে, আর «MFA কি সত্যিই দরকার ছিল» এর উত্তর থাকে প্রদানকারীর লগে, ফায়ারওয়ালের লগে নয়। ভুল লগ পড়া হলো ঠিক নকশা অনুযায়ী চলা একটি রোলআউটকে ভুলভাবে নির্ণয় করার সবচেয়ে সাধারণ উপায়। সেবাটি নিজেও অনুষ্ঠানকে সীমিত করে: FortiOS 7.6.3 SSL VPN টানেল মোড সরিয়ে দেয় এবং IPsec-এর পক্ষে যায়, আর ওয়েব মোড সমর্থিত মডেলে Agentless VPN হিসেবে চলতে থাকে, তাই এক সেবায় প্রমাণিত অনুষ্ঠান স্বয়ংক্রিয়ভাবে অন্যটিতে পাওয়া যায় না।

স্থানীয় যাচাই: টোকেন ও ইমেইলে পাঠানো কোড

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

config user local
    edit "jdoe"
        set type password
        set two-factor fortitoken
        set fortitoken FTKMOB1234567890
    next
end

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

নিশ্চয়তার প্রয়োজনীয়তাও এখানেই আসে, পণ্য নির্বাচনের আগে। NIST SP 800-63B আউট-অব-ব্যান্ড প্রমাণীকরণের জন্য ইমেইলকে অগ্রহণযোগ্য মনে করে, তাই সম্মতি দাবি করা কোনো স্থাপনা ইমেইল কোডকে দ্বিতীয় ফ্যাক্টর হিসেবে ব্যবহার করতে পারে না, তা যতই সুবিধাজনক হোক। ডিভাইসে একটি বৈশিষ্ট্য থাকা মানে এই নয় যে বৈশিষ্ট্যটি নির্দিষ্ট মানদণ্ড পূরণ করে।

RADIUS: গেটওয়ে জিজ্ঞাসা করে, ব্যাকএন্ড সিদ্ধান্ত নেয়

RADIUS-এ FortiGate ক্রেডেনশিয়াল পাঠায় এমন ব্যাকএন্ডে যা ফ্যাক্টর নীতি ধারণ করে। বিনিময়টি সাধারণ গ্রহণ বা প্রত্যাখ্যান হতে পারে, অথবা এতে এমন চ্যালেঞ্জ থাকতে পারে যার উত্তর ক্লায়েন্টকে দিতে হয়, যার মানে VPN সেবা ও ক্লায়েন্ট উভয়কেই সেই চ্যালেঞ্জের রূপ সমর্থন করতে হবে। যে ব্যাকএন্ড push অনুমোদন প্রয়োগ করে আর যে ক্লায়েন্ট কেবল পাসওয়ার্ডের সঙ্গে ছয় অঙ্কের কোড জুড়তে জানে, তারা মাঝখানে মিলবে না।

config user radius
    edit "corp-radius"
        set server "10.10.20.15"
        set secret ENCXXXXXXXX
        set secondary-server "10.10.20.16"
    next
end
diagnose test authserver radius corp-radius pap jdoe <password>

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

diagnose debug application fnbamd -1
diagnose debug enable

SAML: ব্রাউজার গেটওয়ে ছেড়ে যায়

SAML নকশায় ক্লায়েন্টকে পরিচয় প্রদানকারীর কাছে পুনঃনির্দেশ করা হয়, সেখানে প্রমাণীকরণ হয়, এবং একটি দাবি নিয়ে ফেরে যা গেটওয়ে একটি বিশ্বাস সম্পর্ক ও গ্রুপ ম্যাপিংয়ের বিপরীতে যাচাই করে। গেটওয়ে কখনো পাসওয়ার্ড বা দ্বিতীয় ফ্যাক্টর দেখে না, যা একইসঙ্গে নিরাপত্তার উন্নতি ও পরিচালনগত জটিলতা: ব্যর্থতা এখন ঘটে এমন ব্রাউজার সেশনে যা ফায়ারওয়াল পরিদর্শন করতে পারে না।

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

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

পুনরুদ্ধার প্রক্রিয়ার অংশ

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

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