साझा सबडोमेन, दो प्रवेश द्वार: कौन कौन-से रिकॉर्ड देखता है?

क्लिनिक A और क्लिनिक B एक ही कोडबेस, दो सबडोमेन और ऑफ़िस तथा VPN से आने वाले आगंतुकों का मिश्रण साझा करते हैं। नेटवर्क टीमें आम तौर पर दोनों प्रवेश द्वार अलग-अलग कॉन्फ़िगर करती हैं, और यह ठीक है, जब तक ऐप्लिकेशन ऐसा न करे। नीचे दी गई जाँचें ऐप्लिकेशन में होनी चाहिए और अनुरोध किस दरवाज़े से आया, इससे अलग हटकर एक जैसा व्यवहार करना चाहिए।

पहला: होस्टनाम केवल एक टेनेंट का नाम बताता है

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

एक ही होस्टनाम लुकअप से संदर्भ और अनुमति दोनों लौटाने वाला साझा सहायक फ़ंक्शन बग की शुरुआत है।

दूसरा: सदस्यता सत्र से आती है

प्रमाणित उपयोगकर्ता की सक्रिय सदस्यताएँ खोजें और उन्हें पहली जाँच के टेनेंट से तुलना करें। जो उपयोगकर्ता दोनों क्लिनिकों में है वह बदल सकता है, लेकिन बदलाव अनुरोध के संदर्भ में दर्ज एक स्पष्ट क्रिया होना चाहिए, URL से निकाला गया अनुमान नहीं। जो उपयोगकर्ता एक क्लिनिक में है और दूसरे का अनुरोध करता है, उसे अस्वीकार किया जाता है, डाउनलोड और API कॉल सहित।

नकारात्मक स्थिति की जाँच रिकॉर्ड पहचानकर्ता और टेनेंट पैरामीटर बदलकर करें। यदि दोनों में से कोई भी बदलाव डेटा लौटाता है, तो दायरा अनुरोध से पढ़ा जा रहा है, सत्यापित सदस्यता से नहीं।

कुकी दायरा और एकल साइन-ऑन तय करते हैं कि खाता कहाँ प्रस्तुत किया जा सकता है। वे यह तय नहीं करते कि वह खाता क्या पढ़ सकता है।

तीसरा: नेटवर्क व्यक्ति के बारे में कुछ भी साबित नहीं करता

VPN गेटवे सुरंग को प्रमाणित करता है, और सार्वजनिक अनुमति-सूची पता श्रेणी को प्रमाणित करती है। इनमें से कोई भी किसी व्यक्ति की पहचान नहीं करता। NAT कई उपयोगकर्ताओं को एक स्रोत पते में समेट देता है, और ऑफ़िस श्रेणी इमारत में सभी के लिए वही करती है। दोनों को परिवहन-तथ्य मानें और अनुमोदन ऐप्लिकेशन में रखें, या ऐसे एकीकरण में रखें जो पहचान स्पष्ट रूप से घोषित करे और उसी रूप में समीक्षित हो।

DNS तीसरा परिवहन-तथ्य है। निजी उत्तर के लिए निजी मार्ग चाहिए, और सार्वजनिक फ़्रंटएंड के लिए समर्थित मूल-पथ चाहिए। इनमें से कोई भी अनुमति नहीं रखता।

दीवार पर टाँगने के लिए एक वाक्य: नेटवर्क तय करता है कि अनुरोध कैसे आता है, और ऐप्लिकेशन तय करता है कि वह क्या पढ़ सकता है।

चौथा: दोनों प्रवेश द्वारों पर मैट्रिक्स चलाएँ

नियंत्रित खातों का उपयोग करके A को A पर, B को B पर, A को B पर, एक अज्ञात होस्टनाम और बिना सदस्यता वाला प्रमाणित खाता जाँचें। चौथे और पाँचवें को बंद रूप में विफल होना चाहिए और कभी डिफ़ॉल्ट टेनेंट पर नहीं गिरना चाहिए। वही मैट्रिक्स VPN प्रवेश द्वार से भी चलाएँ, प्रत्येक खाते के लिए एक सत्र-जार के साथ:

curl -s -o /dev/null -w '%{http_code}' -b jar.txt https://clinic-b.example.com/records/42
curl -s -o /dev/null -w '%{http_code}' -b jar.txt https://clinic-a.example.com/records/42

फिर अनुमति-सूची की एक प्रविष्टि बदलें और दोबारा चलाएँ। जो परिणाम हिलता है उसका अर्थ है कि कोई नेटवर्क नियंत्रण अनुमोदन का निर्णय ले रहा है।

फ़्रंटएंड में किसी भी बदलाव के बाद मैट्रिक्स दोहराएँ, क्योंकि जाँच को छोड़ देने वाला दूसरा कोड-पथ इस सीमा के क्षरण का सबसे आम तरीका है। अपेक्षित परिणाम उबाऊ है: हर प्रवेश द्वार वही उत्तर देता है।