فیلڈ ڈیوائس میں TLS اور VPN: کون سی حد کس چیز کی حفاظت کرتی ہے

ایک فیلڈ ڈیوائس کسی سروس سے کنکشن کھولتی ہے اور ڈیزائن کا سوال VPN اور TLS کے درمیان انتخاب کی صورت میں سامنے آتا ہے۔ یہ فریمنگ غلط ہے، کیونکہ دونوں مختلف کام کرتے ہیں۔ TLS ایپلیکیشن اینڈ پوائنٹ کی تصدیق کرتا ہے اور گفتگو کی حفاظت کرتا ہے؛ جبکہ VPN رسائی کو کنٹرول کرتا ہے اور ہم منزلوں کے درمیان پیکٹوں کی حفاظت کرتا ہے۔ کنکشن کو ڈیوائس سے باہر کی طرف چلتے ہوئے دیکھیں اور ہر پرت کا اپنا جواب ہے۔

اگر آپ یہ نہیں بتا سکتے کہ TLS کہاں ختم ہوتا ہے، تو آپ یہ بھی نہیں بتا سکتے کہ ایپلیکیشن واقعی کس چیز پر بھروسا کرتی ہے۔

معلوم کریں کہ TLS واقعی کہاں ختم ہوتا ہے

ڈیوائس کی ایپلیکیشن سے شروع کریں اور کنکشن کو اس عمل تک لے جائیں جو ہینڈ شیک مکمل کرتا ہے۔ اگر کوئی پراکسی مین فریم سے پہلے TLS ختم کرتی ہے تو محفوظ راستہ اسی پراکسی پر ختم ہوتا ہے۔ باقی ہاپ کو اپنی دستاویزی حفاظت درکار ہے۔

اسے مفروضے کی بنیاد پر اینڈ ٹو اینڈ کہنا ہی وہ طریقہ ہے جس سے ڈیزائن ریویو کسی خلا کی منظوری دیتا ہے۔ اختتامی نقطہ اور اعتماد کا اینکر ایک ہی خاکے پر بنائیں۔

TLS درخواستیں اور جوابات دونوں سمتوں میں لے کر جاتا ہے، اس لیے دو طرفہ ایپلیکیشن کو بذات خود TLS کے بجائے VPN کی ضرورت نہیں ہوتی۔ اس کا الٹ بھی درست ہے: کسی تعیناتی کو اسی ڈیوائس پر دیگر پروٹوکولز کے لیے پھر بھی VPN درکار ہو سکتا ہے۔

طے کریں کہ ڈیوائس کو کس چیز کی تصدیق کرنی ہے

سرور کی شناخت کی جانچ اور مطلوبہ اعتماد کی جڑیں ترتیب دیں۔ اگر ہر ڈیوائس کو اپنی شناخت ثابت کرنی ہے تو کوئی معاون کلائنٹ تصدیق کا ماڈل منتخب کریں اور ہر ڈیوائس کے لیے الگ اسناد رجسٹر کریں۔ مشترکہ اسناد ایک چوری شدہ ڈیوائس کو پورے بیڑے کا مسئلہ بنا دیتی ہیں۔

شپمنٹ سے پہلے کلید کی حفاظت، تجدید، منسوخی اور بحالی کی منصوبہ بندی کریں۔ میدان میں موجود ایسی ڈیوائس جو ناکام تجدید کے بعد دوبارہ رجسٹر نہ ہو سکے، ایک ٹرک رول بن جاتی ہے، اور یہ لاگت ہینڈ شیک سے زیادہ ڈیزائن کی تشکیل کرتی ہے۔

کوئی معاون لائبریری اور موجودہ رہنمائی استعمال کریں۔ جدید TLS تعیناتی رہنمائی TLS 1.0 اور 1.1 پر بات چیت کو ممنوع قرار دیتی ہے، اور کسی پرانے ڈیزائن نوٹ میں TLSv1 کا حوالہ کوئی تقاضا نہیں ہے۔

ہینڈ شیک ناکام ہو تو بند حالت اختیار کریں

ناکام ہینڈ شیک یا شناخت کی جانچ خاموشی سے اصل کلیئر ٹیکسٹ پروٹوکول پر واپس نہیں گرنی چاہیے۔ یہی واپسی وہ کمزوری ہے جسے TLS کا کام بند کرنے کے لیے تھا۔ ناکامی کو ڈیوائس آپریٹر اور سروس دونوں کے لیے نظر آنے والا بنائیں، اور حساس کارروائیوں کے لیے محفوظ چینل لازمی قرار دیں۔ پھر ایپلیکیشن کی اجازت کاری کو فیصلہ کرنے دیں کہ تصدیق شدہ ڈیوائس کیا کر سکتی ہے۔

کنکشن کی مدت، فریمنگ، ٹائم آؤٹ اور دوبارہ کوشش کا رویہ معاہدے کا حصہ قرار دیں۔ انکرپشن کسی دہرائے گئے کمانڈ کو محفوظ نہیں بناتی، اور غیر یقینی سابقہ کارروائی کے بعد دوبارہ کوشش کو ایپلیکیشن کی سطح پر جواب درکار ہوتا ہے۔

واپسی کا قاعدہ لکھ دیں۔ "اگر ہینڈ شیک ناکام ہو تو یہ TLS کے بغیر دوبارہ جڑ جاتا ہے" ایک ڈیزائن فیصلہ ہے، اور اسے واضح طور پر بیان شدہ فیصلہ ہونا چاہیے۔

VPN کو صرف وہی کام دیں جو وہ کر سکتا ہے

VPN رسائی کو محدود کر سکتا ہے اور اپنے ہم منزل تک پیکٹوں کی حفاظت کر سکتا ہے۔ TLS منتخب اینڈ پوائنٹ کے ساتھ ایپلیکیشن کے تعلق کی حفاظت کرتا ہے۔ ان کے اختتامی مقامات مختلف ہو سکتے ہیں، اور کوئی بھی اینڈ پوائنٹ کے ذخیرہ شدہ ڈیٹا یا انتظامی رسائی کی حفاظت نہیں کرتا۔

ہینڈ شیک کی لاگت، مستقل حالت میں پیغام رسانی اور دوبارہ جڑنے کو اصل ڈیوائس پر ناپیں، بجائے اس کے کہ فرض کریں کوئی طریقہ تیز تر ہے۔ پھر وہ چار صورتیں آزمائیں جو اہم ہیں: مطلوبہ تبادلہ، غلط سرور شناخت، غیر مجاز ڈیوائس، اور غیر یقینی کارروائی کے بعد دوبارہ جڑنا۔ ہر صورت کا نتیجہ ریکارڈ کریں، بشمول وہ خرابی جو ڈیوائس دکھاتی ہے۔