IP अनुमति-सूची बनाम स्वीकृत लैपटॉप: दो अलग नियंत्रण

केवल स्वीकृत लैपटॉप ही जुड़ सके, ऐसे नियम के अनुरोध अक्सर दफ़्तर के सार्वजनिक पते के लिए फ़ायरवॉल प्रविष्टि के रूप में समाप्त होते हैं। वह नियम अब पते के पीछे के हर डिवाइस को प्रवेश देता है। आवश्यकता और कार्यान्वयन एक ही चीज़ नहीं हैं। नीति क्या चाहती है और पता क्या सिद्ध कर सकता है, इन्हें अलग करें।

एक नीति अनुरोध में तीन प्रश्न

अनुरोध को तीन भागों में बाँटें: कनेक्शन कहाँ से आता है, यह किस सेवा तक पहुँच सकता है, और कौन-सा कंप्यूटर प्रमाण प्रस्तुत करता है। स्रोत-पता नियम पहले का उत्तर देता है, और गंतव्य-सेवा नियम दूसरे का। इनमें से कोई भौतिक मशीन की पहचान नहीं करता, क्योंकि दोनों ऐसे नेटवर्क क्षेत्रों पर काम करते हैं जिन्हें कई डिवाइस साझा करते हैं। तीसरे के लिए उस डिवाइस को जारी और चुपचाप दोबारा प्रयोग न होने वाला प्रमाण चाहिए।

तीनों उत्तर अलग-अलग लिखें। एक फ़ायरवॉल पंक्ति तीन चीज़ों का नाम लेने वाली आवश्यकता पूरी नहीं कर सकती।

स्रोत पता आपको क्या बता सकता है

पता अनुवाद ही सामान्य कारण है कि नेटवर्क-स्रोत नियम बहुत अधिक अनुमति देता है। एक दफ़्तर निर्गम के पीछे का सब कुछ एक ही सार्वजनिक पते के रूप में दिखता है, इसलिए नियम पूरे समूह को अनुमति दे देता है। VPN के अंदर स्थिर पता उसी कमज़ोरी को दूसरी जगह रखता है: यह सत्र से जुड़ा आवंटन है, हार्डवेयर का गुण नहीं। स्वीकृत प्रमाण वाला कोई भी डिवाइस वह सत्र खोल सकता है। पते को नेटवर्क प्रतिबंध मानें और इसी तरह वर्णित करें।

यह जोखिम सीमित करने के लिए अब भी उपयोगी है, और यह डिवाइस प्रमाणीकरण नहीं है।

पहुँच को पंजीकृत प्रमाण से बाँधें

यदि आवश्यकता डिवाइस प्रतिबंध है, तो VPN द्वारा समर्थित प्रति-डिवाइस नामांकन का उपयोग करें और हर कंप्यूटर को अलग पहचान दें।

certutil -store My <thumbprint>
openssl verify -CAfile vpn-ca.pem device.pem

स्टोर सूची प्रमाणपत्र और निजी कुंजी की उपस्थिति दिखाती है, और सत्यापन दिखाता है कि श्रृंखला इच्छित एंकर तक पहुँचती है या नहीं। प्रमाणपत्र कॉन्फ़िगर की गई नीति के अंतर्गत स्वीकृत निजी कुंजी के स्वामित्व को सिद्ध करता है; यह नहीं सिद्ध करता कि किस भौतिक मशीन के पास वह थी जब उस कुंजी को निर्यात और प्रतिलिपि किया जा सकता है। प्रोफ़ाइल का नाम लैपटॉप पर रखने से रहस्य पहले जितना ही स्थानांतरणीय रहता है। जहाँ प्लेटफ़ॉर्म समर्थन देता है, प्रमाणन नीति के साथ हार्डवेयर-संरक्षित कुंजियाँ अधिक मज़बूत बंधन देती हैं, और नामांकन को अब भी तय करना है कि प्रमाण कौन प्राप्त कर सकता है।

सीमा को परखें, फिर हटाने की योजना बनाएँ

दो स्थितियों का मूल्यांकन करें: स्वीकृत लैपटॉप और उपयोगकर्ता जुड़ सकें, और केवल उपयोगकर्ता का खाता रखने वाला दूसरा डिवाइस न जुड़े। यदि डिज़ाइन में उपयोगकर्ता और डिवाइस दोनों की जाँच आवश्यक है, तो सत्यापित करें कि चुनी गई विधि दोनों को एक ही सत्र में लागू करती है, दो स्वतंत्र सेटिंग्स के मिल जाने को मानने के बजाय।

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -cert device.pem -key device.key

निरसन को स्वीकृत डिवाइस पहचान हटानी चाहिए, और सक्रिय सत्रों की देखभाल अपनी अलग जाँच की हक़दार है। TPM या प्रबंधित-डिवाइस ध्वज मशीन की हर प्रक्रिया के लिए स्वच्छ स्वास्थ्य प्रमाणपत्र नहीं है।

नेटवर्क प्रतिबंध, डिवाइस प्रमाण और नामांकन निर्णय को तीन स्वामियों के साथ तीन नियंत्रणों के रूप में दर्ज करें। यह सीमा को समीक्षा-योग्य बनाता है, और केवल एक पता कभी यह नहीं दे सकता।