احراز هویت VPN گمشده: جایگزینی بدون غیرفعال کردن MFA
عامل گمشده یک کار بازیابی است، نه قطع سرویس. خارج از مسیر خراب بررسی کنید، جایگزین ثبت کنید، روش قدیمی را بازنشسته کنید و سپس ثابت کنید ورود کار می‌کند.
کسی گوشی‌اش را گم می‌کند و تیکت با عنوان «VPN خراب است» می‌رسد. این قالب‌بندی دو بار غلط است: حساب هنوز وجود دارد و دروازه هنوز به ارائه‌دهنده هویت اعتماد می‌کند، پس تنها بخش خراب یک عامل است که فرد دیگر آن را ندارد. با آن مانند بازیابی رفتار کنید نه قطع سرویس: درخواست‌کننده را بررسی کنید، جایگزین ثبت کنید، روش گمشده را بازنشسته کنید و سپس ثابت کنید حساب کار می‌کند. همه این‌ها فرض می‌کند که برنامه پیش از گم شدن نوشته شده است، چون ساختن آن در حین تماس همان راهی است که در پایان MFA برای همه خاموش می‌شود.
گام 1: عوامل ثبت‌شده را از یک سابقه بخوانید، نه از حافظه
پرسش نخست این نیست که کدام دستگاه گم شده، بلکه این است که حساب هنوز چه چیز دیگری می‌تواند استفاده کند. یک حساب می‌تواند گذرواژه به‌همراه پوش، رمز زمان‌محور، کلید سخت‌افزاری و کدهای بازیابی چاپ‌شده داشته باشد، و گم شدن یکی از آن‌ها رویدادی کاملاً متفاوت از گم شدن تنها عامل است. فهرست روش‌ها را از سامانه هویت بخوانید به‌جای اینکه از کاربر بخواهید آن را به یاد بیاورد، و در مستأجر Microsoft Entra پرس‌وجو یک خط است:
Get-MgUserAuthenticationMethod -UserId [email protected]سپس سابقه بازیابی را در حالی که حساب هنوز کار می‌کند بنویسید: شناسه حساب، عوامل ثبت‌شده، محل نگهداری کدهای بازیابی، چه کسی می‌تواند درخواست‌کننده را مستقلاً بررسی کند، و حساب به کدام سامانه‌ها دسترسی دارد. آن را در انبار محافظت‌شده‌ای که تیم پیش‌تر استفاده می‌کند نگه دارید، هرگز در یادداشتی که کدهای فعال را نیز در خود دارد. این پنج فیلد یک تماس پراضطراب را به چک‌لیست تبدیل می‌کند، و راهنمای NIST درباره چرخه عمر احرازگر بازیابی را بخشی از اعتبارنامه می‌داند نه استثنایی بر آن.
کانال بررسی را به‌عنوان فیلد جداگانه ثبت کنید، چون آدم‌ها دقیقاً همین بخش را جا می‌اندازند. شماره تلفنی که به حساب وصل است وقتی درخواست‌کننده خودش تلفن را کنترل می‌کند کانال مستقل نیست.
گام 2: درخواست‌کننده را خارج از مسیر خراب بررسی کنید
بررسی هویت را از کانالی انجام دهید که به VPN، صندوق پستی یا دستگاه گمشده وابسته نیست. تماس برگشتی به شماره‌ای از سابقه منابع انسانی، یا بررسی حضوری با مدیری که از قبل در فهرست است، هر دو کار می‌کنند؛ پیام چتی که از حساب در حال بازیابی فرستاده شود کار نمی‌کند. بررسی درباره خود شخص است، نه درباره توانایی‌اش در پاسخ به پرسش‌های حساب، چون جزئیات حساب لو می‌رود. ثبت کنید چه کسی درخواست را بررسی کرد و چه وقت، زیرا بازبین بعدی هر دو را می‌خواهد.
وقتی درخواست با فوریت و فشار برای رد کردن بررسی می‌رسد، همان لحظه کند شدن است. کلاهبرداری بازیابی دقیقاً شبیه همکارِ کمک‌کننده‌ای است که عجله دارد.
گام 3: جایگزین را ثبت کنید و سپس عامل قدیمی را بازنشسته کنید
احرازگر جدید را از مسیر ثبت عادی ثبت کنید، هرگز از طریق دور زدن اداری. سپس روش گمشده را صریحاً حذف کنید، چون ثبت جایگزین احرازگر قبلی را تا زمانی که کسی بازنشسته‌اش نکند مجاز باقی می‌گذارد. اگر دستگاه قدیمی ممکن است در دست شخص دیگری باشد، حذف را فوری تلقی کنید و فرایند رخداد را دنبال کنید نه فرایند بازیابی را. نشست‌های موجود را در همان گذر لغو کنید، چون نشستی که پیش از تغییر ساخته شده می‌تواند از آن بیشتر عمر کند:
Revoke-MgUserSignInSession -UserId [email protected]حذف عامل برای بقیه، یا سست کردن بررسی‌های گواهی دروازه، بازیابی یک نفر را با قطع سرویسی که کل استقرار را درگیر می‌کند معاوضه می‌کند. تغییر را محدود به همان یک حساب نگه دارید و اگر شواهد به نفوذ گسترده‌تر اشاره دارد، ارجاع دهید. در تیکت بنویسید کدام عامل بازنشسته شد و کدام جایگزینش شد.
گام 4: ثابت کنید حساب در هر دو جهت کار می‌کند
یک بار با عامل جدید از طریق کارخواه پشتیبانی‌شده وارد شوید، سپس تأیید کنید که حساب هنوز به همان منابعی می‌رسد که پیش از گم شدن می‌رسید. یک منبع را که به تونل نیاز دارد و یکی را که ندارد آزمایش کنید، تا خرابی به لایه درست اشاره کند. با عامل بازنشسته تلاش برای ورود کنید و انتظار رد شدن داشته باشید نه اعلان، که ثابت می‌کند حذف اثر کرده است. چالشی که از یک دستگاه ثبت‌شده موجود شکست می‌خورد مشکلی در اعلان است، نه دلیلی برای ثبت دوباره همه‌چیز.
سپس از کاربر بخواهید همان ورود را بدون راهنمایی کامل کند. آزمایش موفق شما پیکربندی را ثابت می‌کند؛ تلاش او تحویل را ثابت می‌کند.
تیکت را با برچسب زمانی ورود موفق و نام عاملی که اکنون استفاده می‌شود ببندید. سابقه بازیابی را در همان گذر به‌روز کنید، تا گم شدن بعدی از انبار دقیق شروع شود نه از انبار کهنه.
گام 5: شرطی را که این را دردناک کرد حذف کنید
هر تماس بازیابی شاهدی درباره طراحی ثبت است. اگر حساب دقیقاً یک عامل داشت، برای همه افراد آن گروه عامل دومی الزامی کنید. اگر کدهای بازیابی روی لپ‌تاپ گمشده بودند، محل نگهداری‌شان را تغییر دهید. اگر بررسی به مدیری نیاز داشت که در مرخصی بود، جانشین تعیین کنید. هر اصلاح یک بعدازظهر وقت می‌گیرد و بدترین ساعت رخداد بعدی را حذف می‌کند.
سپس سابقه گام یک را دوباره در برابر واقعیت بخوانید. آیا عواملی را فهرست می‌کند که واقعاً وجود دارند، و آیا کانال بررسی هنوز به یک انسان می‌رسد؟ راهنمایی که هیچ‌کس به‌روزش نمی‌کند به سندی تبدیل می‌شود که مردم در همان تماسی که برایش نوشته شده نادیده می‌گیرند.