तात्पुरत्या IP परवानगी-यादीच्या दुव्या: परवानगी प्रत्यक्षात काय स्वीकारते

एका क्लिकला तात्पुरत्या फायरवॉल नियमात बदलणे सोयीचे आहे, आणि ते कोण कशा सेवेपर्यंत पोहोचू शकतो हे ठरवणारी अधिकृतता प्रणालीही उभी करते। ते जारी करते ते व्यक्ती नाही, पत्ता आहे, आणि दोन लोक एकच NAT सामायिक करतात त्या क्षणापासून हा फरक महत्त्वाचा ठरतो। परवानगीची व्याप्ती मर्यादित करा, ती जाणूनबुजून पुष्टी करा, आणि दुवा तयार होण्यापूर्वी समाप्तीला अर्थ द्या। तुमच्यासमोरचा निर्णय सीमा कुठे ठेवायची हा आहे, सीमा असावी की नाही हा नाही।

परवानगी कोणत्या प्रश्नाचे उत्तर देते ते ठरवा

गरजेपासून सुरुवात करा. जर नामनिर्देशित व्यक्तीला सेवेपर्यंत पोहोचायचे असेल आणि अनुप्रयोग त्या व्यक्तीचे आधीच प्रमाणीकरण करत असेल, तर प्रमाणीकृत प्रवेशद्वार ओळख अंमलबजावणीच्या ठिकाणीच ठेवते आणि पत्ता स्वीकारण्याची अजिबात गरज नसते. जर लक्ष्य बिल्ड एजंट, प्रशासकीय जंप पोर्ट किंवा वापरकर्ता लॉगिनमध्ये सहभागी होऊ शकत नाही असे उपकरण असेल, तर मर्यादित व्याप्तीची पत्ता-परवानगी हीच उपलब्ध एकमेव व्यावहारिक नियंत्रण असू शकते।

वापरकर्त्यांकडे पाहणाऱ्या अनुप्रयोगासाठी पत्त्यावर आधारित स्वीकृती निवडल्यास खरी अधिकृतता समस्या दुसरीकडे सरकते, आणि मग पोर्टलला कधीही न भरलेल्या त्या त्रुटीचा दोष वारसा म्हणून मिळतो।

सर्व्हरवर विनंती मर्यादित करा

ब्राउझरने गंतव्य, पोर्ट किंवा उपसर्ग निवडू नये. पोर्टल स्वतःच्या नोंदींमधून सेवा शोधते आणि सर्व्हर-बाजूच्या चाचणीने हक्क तपासते, हे तेच तत्त्व आहे जे OWASP चे अधिकृतता मार्गदर्शन प्रत्येक विनंतीवर लागू करते. पत्त्याची व्युत्पत्तीही संरक्षित सीमेवरच होते: जेव्हा रिव्हर्स प्रॉक्सी ग्राहकाचा पत्ता कळवते, तेव्हा केवळ संरचित प्रॉक्सी-साखळी आणि तिचे दस्तऐवजीकृत हेडर-हाताळणी स्वीकारा. अभ्यागताने दिलेले फॉरवर्डिंग हेडर उगमाबद्दलचा दावा आहे, त्याचा पुरावा नाही.

नंतर पोर्टल आणि सेवा एकच स्रोत पाहतात का ते तपासा. विभाजित टनेलिंग, एक प्रॉक्सी हॉप आणि IPv4 विरुद्ध IPv6 हे दोन गंतव्यांना दोन वेगळे पत्ते देऊ शकतात, त्यामुळे एका मार्गाने सक्रिय केलेली परवानगी पुढील विनंती झाकणार नाही असे होऊ शकते.

स्थापित करण्यापूर्वी परवानगी दाखवा

दुवा उघडल्यावर प्रस्तावित सेवा, निरीक्षण केलेला स्रोत आणि कालावधी दिसला पाहिजे, आणि अजून काहीही बदलू नये. ते एकच पाऊल ईमेलमधून आलेल्या दुव्याचे कृतीतून प्रस्तावात रूपांतर करते, आणि पूर्वावलोकन बॉट किंवा मेल स्कॅनरला केवळ तो घेतल्यामुळे प्रवेश देण्यापासून रोखते.

पुष्टी ही नेहमीच्या क्रॉस-साइट आणि उगम संरक्षणांसह स्थिती बदलणारी विनंती असावी. टोकन एकवेळ वापरण्याचे असावे आणि नियम स्थापित होण्याच्या क्षणीच अणु स्वरूपात खर्च व्हावे, आणि नोंदीत मालक, सेवा, पत्ता, परवानगी ओळखक आणि समाप्ती नोंदवली जावी, कच्चे टोकन कधीही लॉग न करता.

टोकनची डिलिव्हरी नियमासारखीच काळजी मागते. कालबाह्य किंवा आधीच खर्च झालेला दुवा जर अजूनही नियम तयार करत असेल, तर तो त्याच किल्लीसह लावलेला दुसरा दरवाजा आहे.

परवानगी जिवंत असतानाही पत्ता सामायिक असतो

कार्यालयीन NAT, कॅरियर NAT आणि सामायिक VPN निर्गम—प्रत्येक अनेक लोकांना एका पत्त्यामागे ठेवते. तो पत्ता स्वीकारणे म्हणजे त्यामागील सर्वांना स्वीकारणे — सेवेच्या पुढील सीमेपर्यंत —, तर सेवा ज्या खात्याची अपेक्षा करते ते कोणाकडे आहे याचा काहीही पुरावा देत नाही.

नियम काढणेही सार्वत्रिक विच्छेदन नाही. प्रस्थापित कनेक्शन, कॅशे केलेले अनुप्रयोग टोकन आणि दीर्घकालीन सत्रे नियमाच्या पुढे मिनिटांनी किंवा त्याहून बराच काळ टिकू शकतात, म्हणून तुम्ही निवडलेले आयुष्य नियम किती काळ आहे हे नव्हे, तर स्वीकृतीनंतर सेवा काय करते हे प्रतिबिंबित करावे.

चार प्रकरणे आणि दोन्ही पत्ता-कुटुंबे तपासा

परवानगी ती टिकून राहणाऱ्या चार प्रकरणांइतकीच चांगली असते: नवीन परवानगी दिलेली विनंती, न मंजूर केलेला विनंतीकर्ता, त्याच दुव्याची पुनरावृत्ती, आणि समाप्तीनंतरची तीच विनंती.

नंतर प्रत्येक कुटुंब स्वतंत्रपणे तपासा, कारण सेवा जो स्रोत-पत्ता पाहते तो त्यांच्यात वेगळा असू शकतो.

dig +short A service.example.com
dig +short AAAA service.example.com
curl -4 -sS -o /dev/null -w "%{http_code}\n" https://service.example.com
curl -6 -sS -o /dev/null -w "%{http_code}\n" https://service.example.com

उपयुक्त परिणाम म्हणजे नेहमीच्या वापरकर्ता-अधिकृततेखालील तात्पुरता, अंकेक्षणयोग्य स्वीकृती निर्णय, आधी क्लिक केलेल्याचे नाव वाहणारा कायमचा दरवाजा नाही.