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