دو بررسی ورود، دو عامل نیستند: VPN و RADIUS

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

بک‌اند دوم در واقع چه چیزی را اثبات می‌کند

جست‌وجوی حساب محلی اثبات می‌کند که نامی در پایگاه داده وجود دارد و رمز عبوری با آن مطابقت داشته است. تبادل RADIUS اثبات می‌کند که یک سرور RADIUS برای ویژگی‌های دریافتی Access-Accept برگردانده است. هیچ‌یک از این دو گزاره نوع عامل را ذکر نمی‌کند، زیرا هر دو دانش را بررسی می‌کنند. و راهنمای هویت دیجیتال NIST انواع متمایز عامل و احرازکننده‌های آن‌ها را می‌شمارد، نه سرورها یا اعلان‌ها را.

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

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

AND، OR و پشتیبان محصولات متفاوتی هستند

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

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

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

بررسی دوگانه OpenVPN یک مورد مشخص است

OpenVPN جامعه 2.6 وقتی هر دو فعال باشند هم گواهی کلاینت و هم اسکریپت پیکربندی‌شده auth-user-pass-verify را الزامی می‌کند. این یک AND مستند میان بررسی گواهی و اسکریپت اعتبارنامه است، و واقعاً دو بررسی است. با این حال به‌طور خودکار دو نوع عامل نیست، چون اسکریپت ممکن است فقط یک رمز عبور را اعتبارسنجی کند.

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

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

سازندگان دستگاه لوله‌کشی خود را می‌سازند، غالباً یک ماژول PAM یا افزونه RADIUS پشت یک کنسول وب. رفتار جامعه مرجعی برای اینکه بررسی‌های دوگانه چه شکلی هستند است، نه توصیفی از اینکه یک دستگاه آن‌ها را چگونه ترکیب می‌کند.

ترکیب را روی دروازه خود بررسی کنید

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

grep -E 'verify-client-cert|auth-user-pass-verify|plugin' /etc/openvpn/server.conf
openssl x509 -in /etc/openvpn/pki/issued/client01.crt -noout -subject -serial
radtest alice 'wrong-password' 127.0.0.1 0 testing123

grep نشان می‌دهد آیا گواهی لازم است و کدام اسکریپت پس از آن اجرا می‌شود، و ترتیب مهم‌تر از آن است که نام‌ها القا می‌کنند. خروجی گواهی هویتی را می‌دهد که دروازه می‌بیند، از جمله CN و شماره سریالی که برای نگاشت پیوند لازم دارید. آزمون RADIUS حالت منفی است: رمز اشتباه باید Access-Reject بدهد و رمز درست Access-Accept. اگر اعتبارنامه ردشده هنوز نشستی بدهد، اسکریپت اصلاً روی مسیر احراز هویت نیست.

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

نیازمندی را به‌صورت حالت‌های منفی بنویسید

یک نیازمندی قابل‌استفاده اثبات‌ها، حساب‌هایی که مجاز به ارائه آن‌ها هستند و نتیجه‌ای را که وقتی بررسی‌کننده غایب است نام می‌برد. همچنین جفت‌شدن مجاز میان هویت دستگاه و هویت شخص را بیان می‌کند. این دقیق‌تر از نام محصولات در سفارش خرید است و قابل آزمون است.

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

پس از هر تغییر افزونه یا میان‌افزار، چهار رد را دوباره اجرا کنید. ارزان هستند، و سیاستی که از آن محافظت می‌کنند بخشی است که مهاجم نخست بررسی می‌کند.