VPN-এ MFA অনুরোধ প্রত্যাখ্যাত: ক্লায়েন্টের কী করা উচিত

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

কোন অনুরোধ ব্যর্থ হয়েছে তা যাচাই করুন

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

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

নতুন চ্যালেঞ্জ নিয়ে একবার, সচেতনভাবে আবার চেষ্টা করুন

পুনরায় চেষ্টা হওয়া উচিত নতুন চ্যালেঞ্জসহ নতুন প্রচেষ্টা, পুরোনোটির পুনরাবৃত্তি নয়। ক্লায়েন্ট যখন আগের চ্যালেঞ্জ পুনরায় ব্যবহার করে, পরিচয় প্রদানকারী হয় এটি বাসি বলে প্রত্যাখ্যান করে, নয়তো আরও খারাপ—আগের প্রচেষ্টার জন্য নির্ধারিত অনুমোদন গ্রহণ করে। নতুন চ্যালেঞ্জ চান, তা দেখান, এবং ব্যবহারকারীকে এখন পর্দায় থাকা চ্যালেঞ্জটির উপর কাজ করতে দিন।

মাঝে সংক্ষিপ্ত বিরতি দিয়ে দুটি প্রচেষ্টা যুক্তিসঙ্গত ডিফল্ট; অসীম লুপ নয়। দ্বিতীয় প্রচেষ্টা একইভাবে ব্যর্থ হলে চালিয়ে যাওয়ার বদলে থামুন এবং জানান।

ক্লায়েন্টের যা করা উচিত নয়

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

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

যদি অনুরোধটি কিবোর্ডে থাকা ব্যক্তি শুরু না করে থাকেন, সঠিক কাজটি হলো এটি প্রত্যাখ্যাত রাখা এবং যাচাইকৃত সহায়তা পথে জানানো। শব্দ থামাতে অনুরোধ অনুমোদন করাই ব্যর্থতার ধরন, সমাধান নয়।

সহায়তার জন্য কী লিপিবদ্ধ করবেন

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

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

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

যে নিয়মের বিপরীতে গড়তে হবে তা হলো প্রত্যাখ্যান একটি ফলাফল, বাধা নয়। এটি একবার, স্পষ্টভাবে, কাজ করার মতো যথেষ্ট প্রসঙ্গসহ জানান, এবং পরের প্রচেষ্টাটি নতুন হতে দিন। ফিশিং-প্রতিরোধী MFA নিয়ে CISA-র নির্দেশনা ব্যাখ্যা করে কেন “অনুমোদন পর্যন্ত চাইতে থাকা” ধরনটি শুরুতেই বিপজ্জনক, এবং কেউ পুনরায় চেষ্টার লুপ প্রস্তাব করলে এটি-ই উল্লেখ করার যোগ্য তথ্যসূত্র। প্রত্যাখ্যানের পরে ক্লায়েন্ট যা যোগ করে, তার সবই পরের সিদ্ধান্তটি মানুষের জন্য সহজতর করা উচিত, সিদ্ধান্তটি তার কাছ থেকে কেড়ে নেওয়া নয়।