VPN के पीछे SaaS एडमिन क्षेत्र: किस पते पर भरोसा करें?

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

टनल के बाद ओरिजिन वास्तव में क्या प्राप्त करता है

जब कोई ब्राउज़र ऐसे VPN से सार्वजनिक साइट पर पहुँचता है जो इंटरनेट ट्रैफ़िक भी ले जाता है, गेटवे कनेक्शन के बाहर निकलने से पहले उसका अनुवाद करता है। SaaS गेटवे का सार्वजनिक एग्रेस पता देखता है, आमतौर पर एक पता या छोटी श्रेणी, और लैपटॉप का टनल पता कभी नहीं देखता। इसीलिए 10.90.0.42 को अनुमत सूची में जोड़ना विफल होता है, और इसीलिए पूरे RFC 1918 को जोड़ना और भी ज़ोर से विफल होता है: दूसरा हर उस निजी नेटवर्क को अंदर लेता है जो आप तक पहुँच सकता है। शर्त लगाने योग्य एकमात्र पता वह है जो आपका संगठन वास्तव में एग्ज़िट पर रखता है।

curl -s https://ifconfig.me
dig +short admin.example.com

स्प्लिट टनलिंग इस धारणा को चुपचाप तोड़ देती है। यदि VPN केवल निजी ऑफ़िस मार्ग ले जाता है, तो सार्वजनिक एडमिन होस्टनेम का अनुरोध स्थानीय ISP से बाहर जाता है और ओरिजिन एक आवासीय पता देखता है। कनेक्टेड VPN आइकन इस विशिष्ट गंतव्य के बारे में कुछ साबित नहीं करता, इसलिए टनल नहीं, गंतव्य को जाँचें।

यदि एग्ज़िट पता प्रति उपयोगकर्ता बदलता है तो कोई भी नीति लिखने से पहले रुकें और रूटिंग ठीक करें। ऐसी शर्त जो केवल कुछ एडमिन से मेल खाती है, कोई शर्त न होने से बुरी है, क्योंकि यह घटना होने तक समस्या छिपाती है।

केवल उस प्रॉक्सी पर भरोसा करें जो पता फिर से लिखता है

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

set_real_ip_from 192.0.2.0/24;
real_ip_header X-Forwarded-For;
real_ip_recursive on;
curl -H 'X-Forwarded-For: 198.51.100.27' https://origin.example.com/admin

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

शर्त को हर संरक्षित ऑपरेशन से जोड़ें

जाँच को उस प्राधिकरण सीमा पर रखें जिससे होकर हर संरक्षित ऑपरेशन गुज़रता है, न कि उस पेज में जो मेनू रेंडर करता है। रूट समूह, मिडलवेयर या नीति परत सभी काम करते हैं; प्रति हैंडलर प्रतिलिपि नहीं, क्योंकि अगली तिमाही में कोई जो हैंडलर जोड़ेगा उसके पास यह नहीं होगी।

user = requireAuthenticatedSession()
requirePermission(user, "admin")
requireVpnEgress(verifiedClientAddress(request))
performProtectedOperation(user, request)

यही सीमा JSON API, निर्यात, हस्ताक्षरित डाउनलोड URL और WebSocket हैंडशेक को भी कवर करनी चाहिए, क्योंकि इनमें से किसी को भी पहले HTML पेज का अनुरोध करने की आवश्यकता नहीं है। VPN चालू रहते बनाया गया डाउनलोड लिंक बाद में भी वैध रहता है जब तक डाउनलोड एंडपॉइंट फिर से जाँच न करे। लंबे समय तक चलने वाले सत्रों को भी पुनर्मूल्यांकन नियम चाहिए, अन्यथा एक प्रमाणित अनुरोध स्थायी छूट बन जाता है। डिफ़ॉल्ट अस्वीकृति ही एकमात्र सेटिंग है जो कर्मचारी बदलाव में टिकती है।

साझा कैश जाँच के चारों ओर दूसरा रास्ता हैं। जिस कैश में पहले से संरक्षित प्रतिक्रिया है वह ओरिजिन से संपर्क किए बिना उसे परोस सकता है, इसलिए एडमिन प्रतिक्रियाओं को निजी चिह्नित करें और उन्हें साझा भंडारण से बाहर रखें। यदि कैश को उन्हें परोसना ही है, तो पहुँच जाँच परोसने से पहले चलनी चाहिए, जिसका आम अर्थ है कि यह बिल्कुल भी साझा कैश नहीं हो सकता।

अभी-अभी बंद किए गए बायपास जाँचें

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

curl -sI https://admin.example.com/export.csv
curl -s -H 'X-Forwarded-For: 198.51.100.27' https://origin.example.com/admin
curl -s https://admin.example.com/api/me -o /dev/null -w '%{http_code}\n'

हर अनुरोध को वह स्थिति लौटानी चाहिए जिसका नीति वादा करती है, और लॉग में दर्ज होना चाहिए कि कौन-सा पता साक्ष्य इस्तेमाल हुआ। IPv6 को अलग से कवर करें, क्योंकि दोहरे स्टैक वाला ओरिजिन उससे अलग स्रोत परिवार देख सकता है जिसे आपने जाँचा। सामान्य ग्राहक ऑपरेशन VPN के बाहर चालू रखें, अन्यथा किसी ग्राहक की पहली शिकायत पर बदलाव वापस ले लिया जाएगा। हर पंक्ति का अपेक्षित परिणाम चलाने से पहले लिखें, ताकि कोई चौंकाने वाला पास दिखाई दे।

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