قطع سرویس MFA: پیش از شکست درباره ورود به VPN تصمیم بگیرید

ورود به VPN متوقف می‌شود و هشدار می‌گوید سرویس عامل دوم در دسترس نیست. اینکه آیا هنوز کسی می‌تواند متصل شود، پرسش سیاستی است که باید پیش از قطعی پاسخ داده می‌شد، نه در حین آن. تأییدکننده‌ای که در دسترس نیست، مدرکی بر گذر یک عامل نیست، و چالش ردشده همان رویداد چالش در دسترس‌نیست نیست. راهنمای زیر این تمایز را به قاعده‌ای نوشتاری تبدیل می‌کند که می‌توانید بیازمایید.

گام 1: سه نتیجه را جداگانه نام‌گذاری کنید

سه حالت را بنویسید و از یکی کردن آن‌ها خودداری کنید: احراز هویت اولیه شکست خورد، چالش عامل دوم رد شد یا منقضی شد، و سرویس MFA هرگز پاسخ نداد. هر یک مالک متفاوت، خط گزارش متفاوت و پاسخ درست متفاوتی دارد. یک پیام عمومی مهلت، پنهان می‌کند که در کدام‌یک هستید، و همین ابهام است که یک قطعی را به بحث تبدیل می‌کند. حالت‌ها را پیش از آنکه لازم شوند در راهنما نام‌گذاری کنید.

رد یعنی تأییدکننده پاسخ داد و نه گفت، که نتیجه سیاست است نه مشکل دسترس‌پذیری. تلاش منقضی یعنی چالش وجود داشت و کسی آن را به‌موقع کامل نکرد. سرویس در دسترس‌نیست یعنی به پرسش هرگز پاسخ داده نشد. تنها سومین حالت یک قطعی است.

گام 2: حالت شکستی را بخوانید که پراکسی واقعاً استفاده می‌کند

تنظیمی را بیابید که رفتار را وقتی سرویس قابل تماس نیست اداره می‌کند، و آن را از پیکربندی در حال اجرا بخوانید نه از یک الگو. در پراکسی RADIUS شرکت Duo، مقدارهای مستند failmode عبارت‌اند از safe و secure، که safe تنها وقتی اجازه تلاش می‌دهد که احراز هویت اولیه موفق شود، و secure تلاش را در آن شرایط رد می‌کند.

radtest alice '' 127.0.0.1 0 testing123
journalctl -u duo-authproxy -n 50 --no-pager

نام safe یک انتخاب دسترس‌پذیری را توصیف می‌کند، نه تضمینی بر اینکه هر نشست پذیرفته‌شده عامل دوم تازه داشته است. آن جمله جای‌اش در دفتر ریسک است، چون دقیقاً همان معامله‌ای است که تنظیم انجام می‌دهد. مقدار را به ارائه‌دهنده دیگر، یکپارچه‌سازی دیگر یا حالت پراکسی متفاوت تعمیم ندهید؛ مستندات آن محصول را برای معادل خودش بخوانید. پیکربندی کپی‌شده از نمونه فروشنده بدون این درک، غافلگیری‌ای است که منتظر قطعی بعدی است.

اگر هیچ‌کس نمی‌تواند بگوید کدام حالت فعال است، توقف کنید. بقیه راهنما به همان پاسخ وابسته است.

گام 3: تلاش‌های مجدد را با جریان هم‌تراز کنید

مهلت و رفتار تلاش مجدد دروازه را با جریان احراز هویتی که هدایت می‌کند هم‌تراز کنید. تلاش‌های مجدد ناهماهنگ اعلان‌های متعدد می‌سازند، تطبیق تلاش‌ها را به‌هم می‌ریزند و گزارش را ناتوان می‌گذارند از اینکه بگوید کدام نتیجه به کدام ورود تعلق دارد. مهلت بسیار طولانی طراحی دسترس‌پذیری نیست؛ انتظاری طولانی‌تر برای همان پاسخ است.

ss -lunp 'sport = :1812'
tail -n 50 /var/log/duo/authproxy.log

مهلت درخواست خود پراکسی محدودیتی جداست: درخواست احراز هویتی که صادر می‌شود و هرگز کامل نمی‌شود رد می‌شود، و آن رد یک قطعی برای عقب‌نشینی نیست. رد، چالش ناتمام و سرویس در دسترس‌نیست را سه ورودی متفاوت برای جدول تصمیم خود بگیرید. سپس جدول را صریح کنید: کدام حالت می‌پذیرد، کدام حالت نگه می‌دارد و کدام حالت به یک انسان ارجاع می‌دهد.

اگر دو مؤلفه هر دو تلاش مجدد می‌کنند، نخست مالکیت تلاش مجدد را درست کنید. اعلان‌های تکراری نشانه دو مالک است، نه سرویس کند.

گام 4: دسترسی اضطراری را جداگانه اداره کنید

اگر دسترسی اضطراری لازم است، دامنه، هویت، مجوز و ردپای حسابرسی خودش را به آن بدهید. غیرفعال‌کردن بی‌صدای MFA برای همه کاربران رویه اضطراری نیست؛ تضعیف دائمی با یک حادثه پیوست است. مالک امنیت از پیش قاعده ورود، دیدپذیری و مسیر ارجاع را تأیید می‌کند.

grep -R failmode /etc/duo /etc/radiusclient 2>/dev/null
systemctl status duo-authproxy

کل ماتریس را در محیطی غیرتولیدی بیازمایید: شکست احراز هویت اولیه، رد عمدی، انقضای چالش و در دسترس نبودن سرویس. برای هر یک، نتیجه ورود و دلیلی که ثبت شده را ثبت کنید. برای کشف رفتار پیکربندی‌شده، قطعی تولیدی نسازید، و مسیر اضطراری را برای نخستین بار در همان حادثه‌ای که برایش نوشته شده است امتحان نکنید. رویه بازیابی‌ای که هرگز اجرا نشده سند است، نه کنترل.

راهنما وقتی پایان می‌یابد که سه حالت نام‌گذاری شده باشند، حالت شکست از سامانه در حال اجرا خوانده شده باشد، تلاش‌های مجدد یک مالک داشته باشند و دسترسی اضطراری تأیید و بازبینی خودش را داشته باشد. اجرای قابل پیش‌بینی به‌همراه مسیر بازیابی شناخته‌شده همان نتیجه‌ای است که ارزش مستندکردن دارد.