अस्थायी 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

उपयोगी परिणाम सामान्य उपयोगकर्ता-प्राधिकरण के अधीन एक अस्थायी, अंकेक्षण-योग्य स्वीकृति निर्णय है, न कि पहले क्लिक करने वाले का नाम ढोने वाला स्थायी द्वार।