FortiGate VPN MFA: توکن محلی، RADIUS یا SAML؟

هر طراحی FortiGate VPN MFA نخست به یک پرسش پاسخ می‌دهد: چه کسی عامل دوم را بررسی می‌کند؟ خود دروازه می‌تواند این کار را با توکن محلی یا کدی که با ایمیل فرستاده می‌شود انجام دهد، بک‌اند RADIUS می‌تواند آن را اعمال کند و یک چالش برگرداند، یا ارائه‌دهنده هویت SAML می‌تواند تمام مراسم را در مرورگر بر عهده بگیرد. هر یک از این‌ها توالی ورود متفاوت، امضای خرابی متفاوت و رویه بازیابی متفاوتی تولید می‌کند، و کپی کردن یک بلوک فرمان از یکی به دیگری پیکربندی‌ای می‌سازد که باورپذیر به نظر می‌رسد و هیچ‌کس را احراز هویت نمی‌کند. این مقاله‌ای درباره سازوکار است: هر طراحی در هنگام ورود واقعاً چه می‌کند و کجا می‌شکند.

مراسم ورود تعیین می‌کند که عامل در اختیار کیست

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

این تفاوت تعیین می‌کند چه شواهدی می‌توانید جمع کنید. وقتی دروازه بررسی می‌کند، خروجی اشکال‌زدایی خودش به شما می‌گوید چه رخ داده است. وقتی ارائه‌دهنده هویت بررسی می‌کند، دروازه فقط می‌داند که اظهارنامه‌ای رسیده است، و پاسخ به این پرسش که «آیا MFA واقعاً لازم بود» در گزارش‌های ارائه‌دهنده است، نه در گزارش‌های دیوار آتش. خواندن گزارش اشتباه رایج‌ترین راه برای تشخیص نادرست استقرارهایی است که دقیقاً مطابق طراحی رفتار می‌کنند. خود سرویس نیز مراسم را محدود می‌کند: FortiOS 7.6.3 حالت تونل SSL VPN را حذف می‌کند به نفع IPsec، در حالی که حالت وب به‌عنوان Agentless VPN روی مدل‌های پشتیبانی‌شده ادامه می‌یابد، بنابراین مراسمی که در یک سرویس اثبات شده به‌طور خودکار در سرویس دیگر در دسترس نیست.

بررسی محلی: توکن‌ها و کدهای ایمیلی

عامل‌هایی که FortiGate مدیریت می‌کند به شیء کاربر متصل می‌شوند. FortiToken یا یکپارچه‌سازی مستند توکن به ثبت‌نام، مراسم بررسی پشتیبانی‌شده، مجوزدهی در جایی که اعمال می‌شود و رویه جایگزینی نیاز دارد. کد ایمیلی به مسیر SMTP کارآمد و صندوق پستی‌ای نیاز دارد که کاربر پیش از وجود تونل به آن دسترسی داشته باشد، وابستگی‌ای که هیچ ربطی به رمزنگاری ندارد و همه‌اش به این مربوط است که آیا کسی می‌تواند وارد شود.

config user local
    edit "jdoe"
        set type password
        set two-factor fortitoken
        set fortitoken FTKMOB1234567890
    next
end

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

الزامات تضمین هم به اینجا تعلق دارد، پیش از انتخاب محصول. NIST SP 800-63B ایمیل را برای احراز هویت خارج از باند غیرقابل قبول می‌داند، بنابراین استقراری که ادعای انطباق دارد نمی‌تواند کد ایمیلی را به‌عنوان عامل دوم خود به کار ببرد، هر چقدر هم راحت باشد. وجود یک قابلیت روی دستگاه به معنای آن نیست که آن قابلیت استاندارد مشخصی را برآورده می‌کند.

RADIUS: دروازه می‌پرسد، بک‌اند تصمیم می‌گیرد

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

config user radius
    edit "corp-radius"
        set server "10.10.20.15"
        set secret ENCXXXXXXXX
        set secondary-server "10.10.20.16"
    next
end
diagnose test authserver radius corp-radius pap jdoe <password>

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

diagnose debug application fnbamd -1
diagnose debug enable

SAML: مرورگر دروازه را ترک می‌کند

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

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

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

بازیابی بخشی از سازوکار است

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

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