Passkey phishing-এর ঝুঁকি কমায়, কারণ website-এ reusable secret টাইপ করতে হয় না। কিন্তু phone হারালে বা sync account lock হলে recovery plan ছাড়া নিজের account-এই ঢোকা কঠিন হতে পারে। Setup-এর আগে credential কোথায় save হবে, দ্বিতীয় trusted device আছে কি না এবং emergency access কে সামলাবে লিখুন।
Recovery boundary বুঝুন
Public credential service-এর কাছে এবং private credential device বা password manager-এ থাকে। Fingerprint বা PIN website-এ যায় না। Google, Apple, Windows বা অন্য manager—কোথায় sync হচ্ছে ও export সম্ভব কি না official documentation থেকে দেখুন। Recovery email যেন একই locked phone-এর উপর নির্ভরশীল না হয়। Backup code encrypted vault বা offline copy-তে রাখুন, gallery screenshot নয়।
Device ও session audit
Strong screen lock, encryption, update ও remote erase চালু রাখুন। Repair বা বিক্রির আগে device revoke ও factory reset করুন। Shared computer-এ স্থায়ী passkey বানাবেন না। Business account-এ shared password নয়, আলাদা backup administrator রাখুন। QR code দেখলেই scan করবেন না এবং support পরিচয়ে কাউকে backup code বা screen-share দেবেন না।
৮টি check
- Official domain ও HTTPS দেখুন।
- Sync provider লিখুন।
- Recovery email test করুন।
- Backup code নিরাপদে রাখুন।
- দ্বিতীয় device থেকে sign-in করুন।
- Unknown session revoke করুন।
- Backup administrator ঠিক করুন।
- Recovery route মাসে review করুন।
কীভাবে checklist ব্যবহার করবেন
Checklist শুধু পড়ে রাখবেন না। প্রথমে বর্তমান অবস্থার ছোট audit করুন, তারপর risk ও impact অনুযায়ী কাজ সাজান। প্রতিটি step-এর owner, evidence এবং review date লিখুন। অনুমানকে pass ধরবেন না; official setting, test result, screenshot বা export file দেখে সিদ্ধান্ত নিন। বড় পরিবর্তন live environment-এ না করে sample data বা test account-এ চালান। কাজ শেষে নতুন user দিয়ে একই task করিয়ে hidden assumption ধরুন।
নিরাপদ implementation-এর নিয়ম
একবারে সব বদলানোর বদলে ছোট reversible change করুন। শুরু করার আগে backup বা fallback পরীক্ষা করুন এবং failure হলে কে সিদ্ধান্ত নেবে ঠিক রাখুন। Sensitive data minimum নিন, access role অনুযায়ী দিন এবং কাজ শেষে temporary permission সরান। Vendor documentation-এর date ও policy পড়ুন; marketing claim-কে evidence ভাববেন না। Team-এ change log রাখলে পরের মানুষ বুঝতে পারে কেন সিদ্ধান্ত নেওয়া হয়েছিল।
ফল মাপুন ও আবার review করুন
কাজ শেষ মানেই সফল নয়। সময়, error, user feedback, support request এবং recovery test-এর মতো measurable signal নোট করুন। নতুন update, device, team member বা policy change-এর পরে critical step আবার চালান। কোনো rule বাস্তবে কাজে না এলে কারণ বুঝে process বদলান; শুধু compliance দেখাতে অপ্রয়োজনীয় step রাখবেন না। এই cycle workflow-কে সহজ, নিরাপদ ও maintainable রাখে।
Evidence, priority ও ownership
Review করার সময় প্রতিটি finding-কে critical, important এবং improvement—এই তিন level-এ ভাগ করুন। যে issue account access, payment, personal data, customer delivery বা recovery বন্ধ করতে পারে সেটি critical। Cosmetic বা convenience change-এর আগে critical কাজ শেষ করুন। Evidence হিসেবে শুধু “checked” লিখবেন না; setting-এর নাম, test-এর date, expected result এবং actual result রাখুন। কোনো external service জড়িত হলে official help page বা policy link save করুন। Owner-এর সঙ্গে backup person-ও ঠিক করুন, যাতে একজন অনুপস্থিত থাকলে জরুরি কাজ থেমে না যায়।
Human review ও communication
Automation, scanner বা AI দ্রুত signal দিতে পারে, কিন্তু final decision মানুষের context ধরে নিতে হবে। Tool pass দেখালেও edge case, বাংলা text, mobile network, assistive use এবং ভুল input দিয়ে পরীক্ষা করুন। Change customer বা team-কে প্রভাবিত করলে আগে ছোট notice দিন—কী বদলাবে, কবে বদলাবে, user কী করবে এবং সমস্যা হলে কোথায় যোগাযোগ করবে। Error message-এ blame নয়, clear next step দিন। Support query ও complaint লিখে রাখলে documentation কোথায় দুর্বল তা বোঝা যায়।
Maintenance calendar তৈরি করুন
একটি simple calendar-এ weekly quick check, monthly review এবং quarterly deep audit আলাদা করুন। Weekly check-এ failure alert ও urgent update দেখুন। Monthly review-তে permission, backup, usage এবং unresolved issue মিলান। Quarterly audit-এ vendor policy, cost, export, recovery এবং owner list পুনরায় যাচাই করুন। কোনো service বন্ধ বা team member বদলালে calendar-এর অপেক্ষা না করে সঙ্গে সঙ্গে access review করুন। পুরোনো evidence ও unnecessary personal data retention policy অনুযায়ী সরান। নিয়মিত maintenance ছোট সমস্যাকে বড় incident হওয়ার আগে ধরে এবং future migration বা handover সহজ করে।
Final sign-off-এর আগে result, owner, fallback এবং next review date এক জায়গায় লিখে রাখুন। এতে পরে decision audit ও handover পরিষ্কার থাকে।
দ্রুত উত্তর
সাধারণ প্রশ্ন ও উত্তর
Phone হারালে কী করব?
Recovery email, backup code বা দ্বিতীয় trusted device ব্যবহার করে হারানো device revoke করুন।
কখন আবার review করব?
Major update বা workflow change-এর পরে এবং অন্তত তিন মাস অন্তর review করুন।
সব step একদিনে করতে হবে?
না, risk অনুযায়ী ছোট reversible ধাপে কাজ করুন এবং evidence রাখুন।