بررسی‌های پذیرش برای یک دروازه VPN مجازی با احراز هویت دو مرحله‌ای
دروازه را مرحله به مرحله اثبات کنید: ثبت‌نام، ورود، رد، لغو و بازیابی، هر یک با یک سند و شرط قبولی که پیش از آزمون نوشته شده است.
فروشندگان این دستگاه را مجازی و دارای قابلیت دو مرحله‌ای توصیف می‌کنند، و هیچ‌یک از این دو واژه به پرسش‌هایی که خرید را تعیین می‌کنند پاسخ نمی‌دهد. کدام تصویر هایپروایزر پشتیبانی می‌شود، کدام کلاینت‌ها می‌توانند ثبت‌نام کنند، عامل دوم در واقع چه چیزی را اثبات می‌کند، و وقتی ارائه‌دهنده هویت از کار می‌افتد چه رخ می‌دهد، هنوز باز است. آن‌ها را به مراحل پذیرشی تبدیل کنید که در یک تمرین اجرا می‌کنید، و تصمیم دیگر به این وابسته نیست که برگه مشخصات چقدر متقاعدکننده باشد. برگه زیر ساختاری برای این شواهد است، نه رتبه‌بندی محصولات.
آنچه تأمین‌کننده باید درباره این استقرار تأیید کند
با فشرده کردن استقرار در یک صفحه شروع کنید: هایپروایزر یا ابر، معماری مهمان، تصویر پشتیبانی‌شده و رابط‌هایی که دستگاه انتظار دارد. کاربران را با سیستم‌عامل‌هایشان اضافه کنید، اینکه دستگاه‌ها مدیریت می‌شوند یا نه، و اینکه ثبت‌نام و ورود چگونه باید کار کند. سپس دسترسی خصوصی: برنامه‌ها و پیشوندها، چیدمان DNS، مسیرهای بازگشت، و اینکه خروج اینترنت عمومی بخشی از پیشنهاد است یا نه.
عملیات هم به همان صفحه تعلق دارد: چه کسی دستگاه را نگهداری می‌کند، به‌روزرسانی‌ها از کجا می‌آیند، گزارش‌ها کجا می‌روند، پیکربندی چگونه محافظت می‌شود، و کسب‌وکار واقعاً چه هدف بازیابی را پذیرفته است. از تأمین‌کننده بخواهید دقیقاً همین ترکیب را تأیید کند، نه اینکه نرم‌افزار در ماشین مجازی اجرا می‌شود. وابستگی‌های بیرونی مانند ارائه‌دهنده هویت یا سرویس مجوز را آشکار نگه دارید، چون بخشی از استقرار هستند چه همراه آن عرضه شوند چه نشوند. صفحه استقراری که هیچ وابستگی نام‌برده‌ای ندارد معمولاً صفحه استقراری با وابستگی ناشناخته است.
اثبات کنید که عامل دوم واقعاً عامل دوم است
احرازگر و جریان تأیید را نام ببرید و بگویید هر گام کدام هویت را برقرار می‌کند. دو درخواست پیاپی رمز عبور عامل دوم نیست، و رمز عبور به‌همراه کد یک‌بارمصرف ادعایی متفاوت از یک احرازگر رمزنگاری‌شده وابسته به سرویس است. جریانی را که می‌خرید بنویسید، نه برچسب روی جعبه را.
مقاومت در برابر فیشینگ ویژگی جدایی است، و راهنمای احرازگرهای NIST آن را همین‌گونه می‌بیند: کدی که می‌توان کاربر را فریب داد تا آن را بازفرستد همچنان احراز هویت چندعاملی را برآورده می‌کند اما در آن شرط اضافی شکست می‌خورد. اگر برایتان مهم است، ویژگی را صریح بخواهید. سپس نمایشی از همان نوع کلاینتی که کاربران شما واقعاً اجرا می‌کنند بخواهید، شامل ثبت‌نام، چالشی ردشده یا منقضی، بازیابی پس از گم شدن احرازگر، و لغو یک کاربر در حالی که دیگران متصل می‌مانند. تأیید هویت دروازه را در محدوده نگه دارید، چون کلاینتی که به هر دروازه‌ای اعتماد کند مسئله را جابه‌جا کرده است نه حل.
شرط قبولی را پیش از شکستن هر چیزی بنویسید
جدول زیر بخشی از برگه است که در برخورد با تأمین‌کننده دوام می‌آورد، چون هر ردیف به‌جای اطمینان یک سند می‌خواهد. شرط قبولی را پیش از تمرین پر کنید و ردیف بدون شواهد را ردیف ناموفق بدانید. پنج مرحله آنچه دروازه باید انجام دهد را پوشش می‌دهد.
| Acceptance stage | Evidence to keep | Pass condition |
|---|---|---|
| Enrolment | Enrolment record with the device type and the identity used | A new device enrols once, and nobody else can enrol it afterwards |
| Sign-in with the second factor | Session record naming both factors and the gateway identity that was checked | The session carries the expected identity and the gateway certificate validated |
| Denial of an unapproved destination | Log line from the control that refused the flow, with the policy name | The flow is refused and the refusal is attributable to one control |
| Revocation of one user | Revocation timestamp and the sessions that survived it | The named user is out and unaffected users keep working |
| Restore from configuration backup | Restored version plus a probe of a revoked identity | The revision matches the backup and revoked identities stay revoked |
ثبت‌نام اول می‌آید چون همه چیز پس از آن به آن وابسته است: دستگاهی که نمی‌تواند ثبت‌نام کند آزمون‌پذیر نیست. ورود مرحله‌ای جدا از ثبت‌نام است، و رد مرحله‌ای است که بیشتر برگه‌ها فراموش می‌کنند، چون دروازه‌ای که همه را می‌پذیرد ثابت نکرده که کسی را رد می‌کند. لغو و بازیابی بیشترین ریسک عملیاتی را حمل می‌کنند، و هر دو ارزان‌اند برای تمرین روی یک نسخه.
روی نسخه تمرین کنید، نه روی دروازه فعال
مراحل مخرب را روی نسخه‌ای از سکو و با پیروی از رویه استقرار پشتیبانی‌شده اجرا کنید، و هر شاهد را با تاریخ و نسخه پیکربندی‌اش نگه دارید. ردیف راه‌اندازی مجدد با راه‌اندازی از کنسول پاسخ داده نمی‌شود، و ردیف بازیابی با برون‌بری پیکربندی پاسخ داده نمی‌شود. یادداشت کنید کدام وضعیت خودبه‌خود برمی‌گردد و چه چیزی باید دوباره متصل شود، چون همان تفاوت است که تیم عملیات به ارث می‌برد. تمرین همچنین تنها فرصت اندازه‌گیری زمان بازیابی بدون توضیح یک قطعی است.
وضعیت ارائه‌دهنده هویت را در لحظه هر آزمون ثبت کنید، چون ردیف قطعی که در برابر ارائه‌دهنده سالم آزمون شود عکس آنچه برگه ادعا می‌کند را اثبات می‌کند. دو بازبین در یک تمرین چیزهای متفاوتی می‌گیرند، و دومی معمولاً ردیفی را می‌یابد که شاهدش تصویری از یک داشبورد است. آن شاهد را به ردیفی که به آن تعلق دارد بچسبانید، نه در پوشه‌ای به نام پروژه.
بار کاری‌ای را که تیم شما اجرا خواهد کرد اندازه بگیرید
روی باری شبیه یک هفته معمولی توافق کنید، سپس آن را همان‌جا که می‌خواهید استقرار دهید اندازه بگیرید: هم‌زمانی، ترکیب ترافیک، و پنجره نگهداری‌ای که تیم واقعاً دارد. عدد توان عبوری تبلیغ‌شده یک شرایط آزمایشگاهی را توصیف می‌کند و درباره کاربران شما چیزی نمی‌گوید. بازیابی را در برابر هدف بازیابی بسنجید، نه در برابر برنامه.
برگه زمانی تمام است که هر مرحله سندی داشته باشد و هر سند تاریخی. دستگاهی که کسی نگهداری‌اش می‌کند، با شاهد برای هر ردیف، خریدی متفاوت از بلندترین فهرست جعبه‌های تیک‌خورده است.