VPN سرٹیفکیٹ جاری کرنا بنیادی کلید کے بغیر تفویض کریں

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

رجسٹریشن کے کام کو تین سوالوں کی صورت میں لکھیں: کون درخواست کر سکتا ہے، کون منظور کرتا ہے، اور جاری کرنے والا حصہ کس چیز پر دستخط کر سکتا ہے۔

فیصلہ کریں کہ آپ کون سی صلاحیت دے رہے ہیں

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

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

درمیانی سرٹیفکیٹ اختیار کو محدود کرتا ہے

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

جانچیں کہ VPN تصدیق کرنے والے زنجیر کو آپ کی توقع کے مطابق بناتے ہیں۔ زنجیر بنانے کے لیے درمیانی سرٹیفکیٹ بھیجنا اور اسے براہِ راست قابلِ اعتماد انکر کے طور پر نصب کرنا دو مختلف ترتیبیں ہیں۔

pathLen صفر کا مطلب وہ نہیں جو آپ سوچتے ہیں

RFC 5280 کا حصہ 4.2.1.9 بنیادی پابندیاں بیان کرتا ہے، اور اس کا راستے کی لمبائی کا فیلڈ محدود کرتا ہے کہ ایک درست راستے میں کتنے خود جاری نہ کیے گئے درمیانی سرٹیفکیٹ آ سکتے ہیں۔ صفر کی قدر مزید درمیانی گہرائی کو محدود کرتی ہے؛ یہ آخری ادارے کے سرٹیفکیٹوں کی تعداد کو محدود نہیں کرتی۔ لوگ اسے صفر اجازت یافتہ سرٹیفکیٹ سمجھ کر پڑھتے ہیں اور پھر حیران ہوتے ہیں کہ جاری کرنا اب بھی کیسے کام کرتا ہے۔ فیلڈ کو CA کے لیے گہرائی کی حد سمجھ کر پڑھیں، اور رویہ قابلِ پیش گوئی ہو جاتا ہے۔

وہی حصہ اشارہ کرتا ہے کہ اعتماد کا انکر راستے کی توثیق کے لیے ان پٹ ہے، راستے کے اندر عام سرٹیفکیٹ نہیں۔ اسی لیے خود دستخط شدہ بنیادی کے لیے منسوخی کا اندراج شائع کرنا اسے ہر ذخیرے سے قابلِ اعتماد طور پر نہیں ہٹاتا۔

ملازمت چھوڑنا کلید کی خلاف ورزی نہیں

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

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

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