হারানো VPN প্রমাণক: MFA বন্ধ না করে প্রতিস্থাপন

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

ধাপ 1: নিবন্ধিত ফ্যাক্টরগুলো স্মৃতি থেকে নয়, রেকর্ড থেকে পড়ুন

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

Get-MgUserAuthenticationMethod -UserId [email protected]

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

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

ধাপ 2: ব্যর্থ পথের বাইরে অনুরোধকারীকে যাচাই করুন

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

যখন অনুরোধ তাড়াহুড়ো ও যাচাই এড়ানোর চাপ নিয়ে আসে, তখনই ধীর হওয়ার সময়। পুনরুদ্ধার জালিয়াতি দেখতে ঠিক তাড়াহুড়ো করা সহায়ক সহকর্মীর মতোই লাগে।

ধাপ 3: প্রতিস্থাপন নিবন্ধন করুন, তারপর পুরোনো ফ্যাক্টর অবসর দিন

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

Revoke-MgUserSignInSession -UserId [email protected]

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

ধাপ 4: অ্যাকাউন্ট দুই দিকেই কাজ করে প্রমাণ করুন

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

তারপর ব্যবহারকারীকে নির্দেশনা ছাড়াই একই লগইন সম্পূর্ণ করতে বলুন। আপনার সফল পরীক্ষা কনফিগারেশন প্রমাণ করে; তাদের প্রচেষ্টা হস্তান্তর প্রমাণ করে।

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

ধাপ 5: যে শর্ত এটিকে কষ্টকর করেছে তা সরান

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

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