ثبت کاربر VPN: نخست مالک هویت را پیدا کنید
افزودن کاربر VPN از سامانه هویت آغاز میشود، نه از پوسته. بیابید کدام بکاند حساب را اعتبارسنجی میکند، حق دسترسی را بدهید و لغو آن را برنامهریزی کنید.
کسی درخواست دسترسی VPN میکند و نخستین واکنش اجرای adduser روی سرور است. این واکنش تنها در مجموعه محدودی از استقرارها درست است. پیش از ساختن هر چیزی، پیکربندی سرور را باز کنید و دریابید کدام محصول آنجا اجرا میشود و اعتبارنامهها را کجا اعتبارسنجی میکند، زیرا حساب ممکن است در پایگاه داده محصول، نزد ارائهدهنده هویت یا در پشته احراز هویت خود میزبان باشد. ساختن نوع نادرست حساب، فرد را با ورودی کارکننده و بدون تونل رها میکند.
پروفایل کاربری که میگوید OpenVPN پروتکل را توصیف میکند، نه سامانه هویت پشت آن را.
از سرور شروع کنید، نه از adduser
نخست محصول را شناسایی کنید. Community OpenVPN همان دیمن بههمراه هر احراز هویتی است که به آن متصل کردهاید، در حالی که Access Server محصولی با لایه کاربری خودش است. پیکربندی، نام واحد و فهرست بستهها را بخواهید و بررسی کنید آیا رابط وبی برای مدیریت کاربران وجود دارد. سپس ببینید پروفایل مستقر چگونه انتظار دارد کاربران هویت خود را اثبات کنند: گواهی، نام کاربری و گذرواژه، یا هر دو. این پاسخ سامانهای را نام میبرد که مالک حساب است.
تنها پس از آن است که عبارت ساختن کاربر معنا پیدا میکند. در استقراری که تنها بر گواهی تکیه دارد، یعنی صدور هویت دستگاه از طریق فرایند تأییدشده، و ورود Unix چیزی را تغییر نمیدهد. در استقرار مبتنی بر گذرواژه، یعنی همان بکاندی که واقعاً گذرواژه را اعتبارسنجی میکند.
چهار بکاند، چهار جای ساخت حساب
احراز هویت محلی Access Server حسابها را در پایگاه داده خودش نگه میدارد، پس رابط ساخت آنها متعلق به محصول است نه میزبان. PAM اعتبارسنجی را به پشته سیستمعامل واگذار میکند، و به همین دلیل حساب محلی Unix میتواند بخشی از ثبت باشد وقتی سرویس همان پشته را انتخاب کرده است. LDAP و RADIUS و SAML اعتبارسنجی را به سرویس بیرونی منتقل میکنند، جایی که تأمین، سیاست گذرواژه و MFA زندگی میکند. Access Server در هر چهار حالت همچنان میتواند گواهیها و مجوزهای هر کاربر را نگه دارد، و همین تفکیک را گیجکننده میکند.
روش مؤثر برای همین کاربر خاص را بررسی کنید، نه پیشفرض سراسری را. Access Server نسخه 2.10 و بعد از آن میتواند روشهای احراز هویت متفاوت را برای هر گروه یا هر کاربر اعمال کند، پس پیشفرض محلی بودن اثبات نمیکند حسابی که پیش روی شماست بهصورت محلی اعتبارسنجی میشود.
حق دسترسی تصمیمی جداگانه است
احراز هویت پاسخ میدهد فرد چه کسی است؛ حق دسترسی پاسخ میدهد به چه چیزی میتواند برسد. این دو را دو گام نگه دارید، زیرا ورود موفق اعطای دسترسی نیست. مسیرهای موردنظر، مجوزهای منابع و حقوق مدیریتی را آگاهانه تعیین کنید و تأیید کنید دسترسی نامرتبط همچنان رد میشود. جایی که استقرار هویتهای فردی را پشتیبانی میکند، برای هر شخص یکی صادر کنید نه اینکه پروفایل دیگری را جلو بفرستید، زیرا پروفایل مشترک را نمیتوان فقط برای یک نفر لغو کرد.
ماده کاربر نیز اهمیت دارد. پروفایل ورود خودکار و ورود تعاملی کاربر روابط احراز هویت متفاوتی را نمایندگی میکنند و جایگزینی یکی با دیگری تغییر میدهد که سرور واقعاً چه چیزی را بررسی میکند.
لغو دسترسی بخشی از ثبت است
هنگام ساختن کاربر سه مالک را بنویسید: چه کسی حساب را اعتبارسنجی میکند، چه کسی دسترسی VPN را مجاز میکند و کدام دستگاه یا پروفایل نماینده اتصال است. اینها میتوانند سه سامانه متفاوت باشند و طرح لغوی که تنها یکی از آنها را نام میبرد مسیری را باز میگذارد. وقتی فرد میرود، حق دسترسی را از مالکش بردارید و هر اعتبارنامه صادرشده را نزد مالکش لغو کنید. حذف یک فایل بارگیریشده لغو نیست، و حذف یک ورودی محلی نیز نیست اگر هویت بیرونی هنوز احراز هویت میشود.
سپس ثبت را همانگونه که یک مهاجم میآزماید، بیازمایید: یک بار با هویت جدید متصل شوید، دسترسی به منبع موردنظر را تأیید کنید و تأیید کنید منبع نامرتبط همچنان امتناع میکند. اتصال اولی که کار میکند بههمراه یک آزمون منفی، ثبت کاملشده است.
سابقه را همراه پروفایلی که به آن تعلق دارد نگه دارید. ممیز بعدی خواهد پرسید در یک ماه معین چه کسی میتوانست متصل شود، و پاسخ در همان سه مالک است.