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