Identity-Aware Proxy वापरत असल्यास तुम्हाला अजूनही VPN आवश्यक आहे का?

गृहीतक असे आहे: ओळख जाणणारा प्रॉक्सी अंतर्गत ऑप्ससमोर उभा राहिला की VPN फक्त सजावट राहतो आणि क्लायंट जाऊ शकतो। हे एका अरुंद प्रकरणासाठी खरे आहे — ब्राउझरमध्ये व्यक्ती वापरत असलेले इंटरॅक्टिव्ह HTTPS ऑप — आणि बाकी सर्वत्र ते शांतपणे अपयशी ठरते। प्रॉक्सी संसाधनाविरुद्ध विनंती अधिकृत करतो; VPN क्लायंटला नेटवर्क कक्षेत प्रवेश देतो, आणि या दोन सीमा क्वचितच जुळतात। टनेल निवृत्त करण्यापूर्वी, आकृतीवरील उत्पादन नावे नव्हे, तुमचे लोक प्रत्यक्षात करत असलेल्या क्रियांची तुलना करा।

दोन्ही गेट वेगळ्या गोष्टींना अधिकृत करतात

ऑप्लिकेशन गेट ठरवते की ही विनंती, या ओळखीतून, या संरक्षित संसाधनापर्यंत पोहू शकते का। Google चे Identity-Aware Proxy विहंगावलोकन नेमके तेच स्वरूप वर्णन करते: HTTPS ऑप्ससमोर IAM भूमिकेने चालवलेला केंद्रीय अधिकृतता स्तर। सीमा संसाधन आहे, आणि प्रवेशाचे एकक विनंती आहे। राउटेड VPN अधिक स्थूळ आणि रुंद काम करते: क्लायंटला निर्धारित नेटवर्क कक्षेत प्रवेश देते, त्यानंतर ऑप त्या क्लायंटला काय करता येईल हे ठरवते।

दोन्हीपैकी कोणतेही मॉडेल दुसर्याला सूचित करत नाही। गेट पार करणे विशिष्ट रेकॉर्ड वाचण्याबद्दल काहीही सांगत नाही, आणि नेटवर्कवर असणे कृतीच्या परवानगीबद्दल काहीही सांगत नाही।

प्रॉक्सी काय व्यापत नाही, आणि VPN काय व्यापते

SSH सत्रे, डेटाबेस क्लायंट, संदेश ब्रोकर आणि कोणताही ब्राउझर कधीही न उघडणारी अंतर्गत होस्टनावे फक्त वेब प्रॉक्सी आहे म्हणूनच पोहोचण्यायोग्य होत नाहीत। प्रत्येकजण स्वतःचे प्रोटोकॉल बोलते, आणि प्रत्येकाला स्वतःचा प्रमाणित मार्ग किंवा तो वाहून नेणारे नेटवर्क आवश्यक आहे। हीच ती दरी आहे जी लोक स्थलांतराच्या पहिल्या दिवशी शोधतात, सामान्यतः हॉस्टनाव आता सोडवू न शकणाऱ्या लॅपटॉपसह ऑन-कॉल अभियंत्याकडून।

उलटी दरीही तितकीच खरी आहे। क्लायंटला सबनेटमध्ये प्रवेश देणारा VPN आतील व्यक्तीचे प्रमाणन करत नाही, आणि त्या सबनेटवरील समजोत झालेले उपकरण नेटवर्क जे परवानगी देते ते वारसाहक्काने घेते। आवश्यकता लेखापरीक्षणयोग्य ओळखीसह प्रति-विनंती अधिकृतता असेल, तर फक्त राउटिंग ती निर्माण करू शकत नाही। बहुतेक संस्था शेवटी दोन्ही चालवतात, आणि रसप्रद प्रश्न हा की कोणत्या संसाधनांसमोर कोणते उभे राहू शकते।

क्लायंट कार्यप्रवाह आर्किटेक्चर आकृतीपेक्षा जास्त ठरवतो

रीडायरेक्ट आणि अधूनमधून MFA आव्हानासह ब्राउझर साइन-इन बुकमार्कवर क्लिक करणाऱ्या व्यक्तीसाठी चांगला अनुभव आहे। cron काम, CLI किंवा बिल्ड एजंटकडे ब्राउझर नाही आणि ते इंटरॅक्टिव्ह प्रॉम्प्टला उत्तर देऊ शकत नाही, म्हणून त्याला दस्तऐवजीकृत बिगर-इंटरॅक्टिव्ह मार्ग किंवा टनेल आवश्यक आहे। त्या आवश्यकतेचा शोध सामान्यतः डिझाइन मंजूर झाल्यानंतर होतो।

ऑप्स मोजण्यापूर्वी क्लायंट मोजा। एक डॅशबोर्ड शंभर लोकांना सेवा देऊ शकते; एक डेटाबेस पोर्ट संपूर्ण टीमला अडवू शकते।

उपकरणाची स्थिती कोणत्याही गेटचा गुणधर्म नाही

VPN क्लायंट स्थापित करणे हे अनुपालन तपासणी नाही, आणि ब्राउझर-आधारित डिझाइन व्यवस्थापित उपकरण धोरणाचे पालन करण्यास स्वयंचलितरित्या असमर्थ नाही। दोन्ही स्थिती संकेतांशी एकत्रित होऊ शकतात, आणि दोन्ही त्यांशिवाय तैनात करता येतात। उत्पादनाच्या आकारावरून अनुमान करण्याऐवजी कोणती अंमलबजावणी आहे, धोरण कोणाचे आहे आणि ते अपयशी होणाऱ्या उपकरणाला काय होते हे विचारा।

प्रवेश काढून टाकण्यासाठीही तीच काळजी लागू होते। प्रॉक्सीमधील गट सदस्यत्व हटवणे आणि टनेलसाठी प्रमाणपत्र रद्द करणे हे वेगळ्या विलंबाचे वेगळी क्रिया आहेत, आणि त्यापैकी एक सामान्यतः निघताना विसरली जाते।

काहीही निवृत्त करण्यापूर्वी पर्यायी मार्ग शोधा

प्रॉक्सीमागील असुरक्षित मूळ, त्याला टाळणारे दुसरे हॉस्टनाव, किंवा मागील डिझाइनमधून उरलेला रुंद खाजगी मार्ग कोणते गेट प्रत्यक्षात लागू आहे हे ठरवतील। परवानगी दिलेली आणि नाकारलेली क्रिया खर्या क्लायंटद्वारे तपासा, कन्सोलद्वारे नव्हे, आणि कधीही नोंदणी न झालेल्या उपकरणातून तपासा। नाकारलेली घटनाच गेट काहीतरी करत आहे का हे सांगते।

मग हस्तांतरण लिहा: नोंदणी, अद्ययतने, प्रवेश काढणे आणि रात्री 2 वाजता बाहेर कुलूपबंद झालेल्यासाठी पुनर्प्राप्तीचा मार्ग। प्रॉम्प्ट किंवा क्लायंट अॅप काढून टाकणे जबाबदारी टीममध्ये हलवते; ती जबाबदारी पुसत नाही।

या आठवड्यात निर्णय घेतला, तर उत्पादनांच्या यादीऐवजी क्रियांच्या यादीपासून सुरुवात करा, ब्राउझर कोणत्या करू शकतो हे चिन्हांकित करा, आणि उर्वरितांना टिकून राहणाऱ्या नेटवर्क प्रवेशास न्याय ठरवू देऊ।