چرا «احراز هویت چندعاملی فعال است» کافی نیست
یک شرکت فرضی را در نظر بگیرید که دو سال پیش احراز هویت چندعاملی را برای همه کارکنان فعال کرده و روش اصلی آن کد پیامکی و تأیید اعلان روی تلفن همراه است. روزی یکی از کارکنان مالی گذرواژه و کد را در یک صفحه ورود جعلی وارد کرد و مهاجم بی‌درنگ با همان اطلاعات وارد صندوق ایمیل شد و یک قانون بازارسال ساخت. در موقعیتی دیگر، یک مدیر عملیات نیمه‌شب ده‌ها درخواست اعلان دریافت کرد و در حالت خواب‌آلودگی روی تأیید زد. بازبینی بعدی نشان داد مشکل نبودِ احراز هویت چندعاملی نبود، بلکه این بود که همه این روش‌ها به قضاوت کاربر درباره واقعی بودن صفحه یا درخواست پیش رویش وابسته‌اند. همین که کاربر فریب بخورد، عامل دوم هم همراه آن تحویل داده می‌شود.
NIST در ویرایش چهارم رهنمودهای هویت دیجیتال که در ژوئیه ۲۰۲۵ نهایی شد، سطوح اطمینان احراز هویت را به‌روز کرد. در سطح دوم، تأییدکننده باید دست‌کم یک گزینه مقاوم در برابر فیشینگ ارائه دهد و هرجا عملی باشد استفاده از آن را تشویق کند. سطح سوم به یک احرازگر رمزنگاری با کلید خصوصی غیرقابل‌استخراج نیاز دارد که مقاومت در برابر فیشینگ فراهم کند. این رهنمودها همچنین کانال‌های پیامک و تلفن را احرازگر محدودشده می‌دانند که به ارزیابی ریسک و ارائه جایگزین نیاز دارد. این الزامات مستقیماً برای سامانه‌های فدرال آمریکا نوشته شده‌اند و شرکت‌ها می‌توانند آن‌ها را جهت‌نما قرار دهند: کلید مقاومت در برابر فیشینگ این است که احرازگر بررسی می‌کند کدام سایت یا سرویس واقعاً در حال دسترسی است، بنابراین وقتی کاربر به صفحه جعلی کشانده می‌شود، اعتبارنامه در آنجا کار نمی‌کند.
حساب‌ها را بر اساس ریسک مرتب کنید
تغییر همزمان برای همه معمولاً به سیل درخواست کمک و مقاومت می‌انجامد، بنابراین JOTOglobal پیشنهاد می‌کند مدیر هویت و مسئول امنیت ابتدا ترتیبی بر اساس ریسک تعیین کنند. دسته نخست، حساب‌هایی هستند که می‌توانند مجوز دیگران را تغییر دهند یا به حجم زیادی از داده دسترسی دارند: مدیران دامنه، مدیران پلتفرم‌های ابری و هویتی، حساب‌های مدیریتی تجهیزات شبکه و امنیت، و مدیران ایمیل. دسته دوم، نقش‌هایی است که اغلب جعل می‌شوند یا می‌توانند مستقیماً پرداخت آغاز کنند، مانند تأییدکنندگان مالی، خرید، دستیاران مدیران ارشد و سرپرستان خدمات مشتری. دسته سوم کارکنان عادی و پیمانکاران هستند. برای هر دسته، سامانه‌های درگیر، رابط واحدی که کار را پیش می‌برد و تاریخ برنامه‌ریزی‌شده تکمیل را ثبت کنید و مشخص کنید کدام سامانه‌های قدیمی هنوز از روش‌های جدید پشتیبانی نمی‌کنند و به تدابیر موقت جداگانه نیاز دارند.
هنگام انتخاب احرازگر، ابتدا مطمئن شوید پلتفرم هویت و برنامه‌های کلیدی عملاً از کدام روش‌های مقاوم در برابر فیشینگ پشتیبانی می‌کنند؛ برای نمونه کلید عبور وابسته به دستگاه، کلید امنیتی سخت‌افزاری یا احرازگر داخلی پلتفرم، و سپس روش توزیع را بر اساس نقش تعیین کنید. مدیران و نقش‌های پرریسک باید ابتدا احرازگرهای وابسته به دستگاه با کلید خصوصی غیرقابل‌استخراج دریافت کنند و هر نفر یک احرازگر پشتیبان داشته باشد که جداگانه نگهداری شود. اگر سازمان کلیدهای عبور قابل همگام‌سازی را مجاز می‌داند، باید میزان حفاظت از خود حساب همگام‌سازی را ارزیابی کند. تیم‌های خرید و دارایی هر تحویل را ثبت می‌کنند، شامل شماره احرازگر، دریافت‌کننده، زمان تحویل و ثبت‌کننده، تا در صورت گم‌شدن دستگاه یا خروج کارمند بتوان سریع آن را یافت و لغو کرد. بازپس‌گیری احرازگرها نیز باید بخشی از فهرست تحویل کار هنگام خروج باشد و مدیر مستقیم تأیید کند که دستگاه بازگردانده شده یا در پلتفرم هویت لغو شده است.
بازیابی و استثناها را همزمان طراحی کنید
پس از استقرار احراز هویت مقاوم در برابر فیشینگ، ضعیف‌ترین نقطه اغلب به بازیابی حساب منتقل می‌شود. اگر مهاجم با میز خدمت تماس بگیرد و ادعا کند تلفنش گم شده و میز خدمت در همان لحظه احراز هویت را بازنشانی کند، سرمایه‌گذاری قبلی دور زده می‌شود. بنابراین فرایند بازیابی میز خدمت باید تأیید هویت راستی‌آزمایی‌شده را الزامی کند؛ برای نمونه بررسی تصویری همراه با تأیید مدیر مستقیم، یا ارائه حضوری مدرک شناسایی، و پس از بازنشانی هم به خود کاربر و هم به مدیرش اطلاع دهد. بازیابی حساب‌های مدیریتی باید توسط دو نفر با هم انجام شود و برگه درخواست آن نگهداری شود. برای افراد یا سامانه‌هایی که هنوز نمی‌توانند از روش‌های جدید استفاده کنند، دلیل استثنا، تأییدکننده، کنترل‌های جبرانی و تاریخ انقضا را ثبت کنید و هنگام انقضا دوباره ارزیابی کنید، نه این‌که پیامک به‌عنوان در پشتی بلندمدت باقی بماند.
در دوره استقرار، مدیر هویت باید همزمان دامنه استفاده از روش‌های قدیمی را محدودتر کند. کاربرانی که ثبت‌نام کرده‌اند دیگر نباید در برنامه‌های کلیدی بتوانند به پیامک یا تأیید اعلان بازگردند. گروه‌هایی که هنوز از اعلان استفاده می‌کنند دست‌کم باید تطبیق عدد یا نمایش محل ورود را به‌عنوان نشانه کمکی داشته باشند و برای درخواست‌های غیرعادی هشدار تنظیم شود. میز خدمت باید از پیش راهنمای عملیاتی و پرسش‌های متداول را دریافت کند و آموزش‌ها بر شناسایی درخواست‌های کمک جعلی و نحوه گزارش آن‌ها تمرکز داشته باشد، نه فقط بر نمایش ثبت دستگاه. اگر یک سامانه کسب‌وکاری فقط می‌تواند از روش‌های قدیمی استفاده کند، آن را به‌عنوان یک مورد ریسک جداگانه فهرست کنید و از صاحب سامانه بخواهید برنامه ارتقا یا جایگزینی ارائه دهد.
شواهد پذیرش، خطاهای رایج و محدوده کاربرد
پذیرش به رهبری تیم امنیت انجام می‌شود. شواهد عبارت‌اند از: آمار روش‌های احراز هویت به تفکیک دسته که از پلتفرم هویت استخراج شده و نشان می‌دهد همه مدیران و نقش‌های پرریسک احرازگر مقاوم در برابر فیشینگ ثبت کرده‌اند؛ تصویر یا خروجی پیکربندی سیاست که ثابت کند برنامه‌های کلیدی دیگر اجازه بازگشت به روش‌های قدیمی را نمی‌دهند؛ سابقه یک آزمون صفحه جعلی در محیط آزمایشی مجاز که نشان دهد احرازگر جدید نمی‌تواند ورود را در سایت تقلیدی کامل کند؛ و سوابق بررسی نمونه‌ای فرایند بازیابی میز خدمت. یکی از خطاهای رایج این است که فقط درصد حساب‌هایی که احراز هویت چندعاملی دارند شمرده شود، بدون تفکیک روش. خطای دیگر این است که استثناها بدون بازبینی باز بمانند و در نهایت حساس‌ترین حساب‌ها همچنان از روش‌هایی استفاده کنند که قابل فیشینگ هستند.
ترتیب دسته‌ها، فرایند بازیابی و موارد پذیرش در این مقاله، توصیه سازمانی JOTOglobal است. مقررات الزامی رهنمودهای NIST برای نهادهای فدرال آمریکا نوشته شده‌اند و شرکت‌ها باید دامنه کاربرد آن‌ها را با مقررات منطقه‌ای، الزامات صنعت و توانایی سامانه‌های خود بسنجند. احراز هویت مقاوم در برابر فیشینگ عمدتاً ریسک فریب‌خوردن کاربر برای تحویل اعتبارنامه یا عبور آن از یک پراکسی میانی را کاهش می‌دهد. این روش مانع کنترل دستگاهِ واردشده توسط بدافزار، سرقت توکن نشست یا سوءاستفاده افراد داخلی از مجوزها نمی‌شود و این موارد همچنان به حفاظت از نقطه پایانی، مدیریت نشست و ممیزی مجوزها نیاز دارند. تاریخ تکمیل هر دسته و مدت استثناها را هر شرکت باید بر اساس تعداد کارکنان و دشواری ارتقای سامانه‌هایش تعیین کند.