एपले mTLS र SSO प्रयोग गर्दा तपाईंलाई अझै साइट VPN चाहिन्छ?
तपाईंको एप लगइनले कहिल्यै नढाक्ने च्यानलहरू हुँदै हिँड्नुहोस्, त्यसपछि निजी नेटवर्क पहुँच अनावश्यक हो कि होस्टसम्मको एकमात्र बाटो हो भनेर निर्णय गर्नुहोस्।
तपाईं mTLS मार्फत साइन इन गर्नुहुन्छ, ड्यासबोर्ड लोड हुन्छ, र साइट VPN अब अनावश्यक छ भन्ने दाबी राति दुई बजे डेटाबेस पुनर्स्थापना गर्नुपर्नेसम्म मात्र उचित सुनिन्छ। एपको TLS सीमाले एउटा मात्र च्यानल वर्णन गर्छ। होस्ट, डेटाबेस, ब्याकअप लक्ष्य र क्लाउड खाता प्रत्येकले आफ्नै प्रवेश मार्ग, आफ्नै पहिचान र आफ्नै अनुमोदक बोक्छन्, र तीमध्ये कुनै पनि सफल लगइनले परीक्षण गरिँदैन।
लगइन स्क्रिनबाट बाहिरतिर हिँड्नुहोस्
सामान्य प्रयोगकर्ताले जस्तै साइन इन गर्नुहोस् र अनुरोधले छुने प्रत्येक पाइला लेख्नुहोस्: ब्राउजर, एज, एप्लिकेसन श्रोता, सत्र भण्डार, ब्याकएन्ड API। प्रत्येक पाइलाको एक मालिक र एक प्रमाणीकरण निर्णय हुन्छ। अब होस्ट प्याच गर्ने व्यक्तिका लागि र रातको ब्याकअप लेख्ने कामका लागि यो हिँडाइ दोहोर्याउनुहोस्। ती बाटा सामान्यतया पहिलो पाइलामै फरक पर्छन्।
त्यही फरक नै उत्तर दिन लायक प्रश्न हो। साइट VPN तब मात्र अनावश्यक हुन्छ जब त्यो दोस्रो हिँडाइको प्रत्येक च्यानलसँग स्वतन्त्र रूपमा उभिने प्रवेश र अधिकार नीति हुन्छ।
एप लगइनले कहिल्यै नढाक्ने पाँच च्यानल
तलको तालिका एक सूची टेम्प्लेट हो, परिनियोजन जाँचसूची होइन। दोस्रो स्तम्भ तपाईंको वातावरणले आज वास्तवमै लागू गर्ने कुराले भर्नुहोस्।
| Channel | Access decision to identify |
|---|---|
| Application API | Accepted TLS peer, application identity, permitted operations |
| Operating-system administration | Approved entry path, administrative identity, host permissions |
| Database maintenance | Database identity, protected connection, authorized maintenance role |
| Backup and restore | Service identity, allowed source, access to stored copies |
| Cloud control plane | Account and role permissions governing infrastructure changes |
एउटै पहिचान प्रदायक साझा गर्नाले यी अधिकारहरू एक हुँदैनन्। API अनुरोध पठाउन सक्ने प्रयोगकर्ता यसैले VM डिस्क परिवर्तन गर्न वा एपको प्रमाणहरूले डेटाबेस पुनर्स्थापना गर्न अधिकृत हुँदैन। NIST शून्य-विश्वास वास्तुकला सारांशमा ठ्याक्कै यही कारणले स्रोत प्रमाणीकरण र अधिकारलाई नेटवर्क स्थानबाट अलग राख्छ।
टिकट पढ्न सक्ने समर्थन इन्जिनियर त्यसैले यसको पछाडिको होस्टमा कन्सोल खोल्न अधिकृत हुँदैन।
बाटो तब मात्र वास्तविक हुन्छ जब विकल्प बन्द रहन्छ
निजी प्रशासनिक श्रोताहरूमा पहुँच सीमित गर्नु साइट VPN को वैध विकल्प हो, तर सीमा लागू गर्नुपर्छ, केवल कोरिएको हुनुहुँदैन। सामान्य असफलता भनेको कसैले सम्झना नगरेको वैकल्पिक श्रोता हो: सबै इन्टरफेसमा अझै बाँधिएको सेवा, ठेकेदारका लागि खोलिएको सुरक्षा समूह नियम, इन्टरनेटबाट पुग्न सकिने व्यवस्थापन पोर्ट।
रेखाचित्र होइन, श्रोताहरू जाँच्नुहोस्। होस्टमा ss -ltnp प्रयोग गरेर वास्तवमा के बाँधिएको छ सूची बनाउनुहोस् र प्रशासनिक पोर्टहरू निजी ठेगानामा छन् भनी पुष्टि गर्नुहोस्। क्लाउड कन्सोलमा कार्यभार उपजालका आगत नियमहरू पढ्नुहोस् र कुनै पनि प्रशासनिक कुरामा 0.0.0.0/0 खोज्नुहोस्। त्यसपछि निजी बाटोको बाहिरबाट जडान प्रयास गर्नुहोस्, किनकि त्यही परीक्षणले प्रश्नको उत्तर दिन्छ।
SSH मा एउटै विश्व-खुला नियमले सुरुङ डिजाइनका सबै तर्क रद्द गर्छ।
डिजाइन तुलना गर्नुअघि नक्सा लेख्नुहोस्
सूचीको प्रत्येक पङ्क्तिका लागि कसले पहिचान स्वीकृत गर्छ, कसले पहुँच नियम अद्यावधिक गर्छ, कोही गएपछि कसले प्रमाणहरू हटाउँछ र बाटो आफैं टुट्दा कसले पुनर्स्थापना सम्हाल्छ लेख्नुहोस्। प्रत्येक पङ्क्तिमा चार नाम ती पङ्क्ति पहिल्याउन पर्याप्त छन् जहाँ उत्तर साझा खाता र तीन वर्ष पुरानो विकी पृष्ठ हो।
त्यसपछि प्रत्येक च्यानलका लागि एक अनुमति र एक अस्वीकृति प्रमाणित गर्नुहोस्। अनुमतिले इच्छित पहिचानले इच्छित बाटोबाट स्रोतसम्म पुग्न सक्ने प्रमाणित गर्छ। अस्वीकृतिले समान पहिचानले पुग्न नसक्ने प्रमाणित गर्छ, र यही त्यो परीक्षण हो जुन मानिसहरूले छोड्छन्, त्यसैले वैकल्पिक श्रोताहरू लेखापरीक्षणबाट बच्छन्। प्रस्तावित डिजाइनलाई यी नतिजासँग तुलना गर्नुहोस्, एपको TLS कन्फिगरेसनसँग होइन, जसले यीमध्ये कुनै पनि कहिल्यै परीक्षण गरेन।
साइट VPN अझै कहाँ आफ्नो स्थान कमाउँछ
स्रोतसँग प्रत्येक अनुरोधका लागि आफ्नै प्रमाणीकरण नभएको अवस्थामा सुरुङ वा साँघुरो गेटवे सही उत्तर हो: डेटाबेस मर्मत पोर्ट, ब्याकअप लक्ष्य, हाइपरभाइजर कन्सोल, ब्यान्डबाहिरको व्यवस्थापन। ती श्रोताहरू नेटवर्कमाथि भरोसा गर्छन्, त्यसैले कलरलाई प्रमाणित गर्ने नेटवर्क नै हुनुपर्छ।
यो एकमात्र उत्तर होइन। प्रत्येक स्रोतको अधिकार अन्त्य गर्ने गेटवे पूरै उपजालको सुरुङभन्दा साँघुरो हुन सक्छ र साझा जम्प होस्टभन्दा राम्रो लेखापरीक्षण ट्रेल छोड्छ।
कामको क्रम: सूची पूरा गर्नुहोस्, विकल्पहरू बन्द गर्नुहोस्, प्रत्येक पङ्क्तिका लागि एक अस्वीकृति प्रमाणित गर्नुहोस्, र त्यसपछि मात्र सुरुङ हटाउनुहोस्। कुनै पङ्क्तिले अस्वीकृति उत्पन्न गर्न सक्दैन भने, सक्नेसम्म निजी बाटो राख्नुहोस्।