तय करें कि ग्राहक को कौन प्रवेश देता है और क्या उस ग्राहक को किसी दूसरे टेनेंट के संसाधनों तक पहुँचने से रोकता है। ये दो निर्णय हैं, और IPsec, WireGuard या mesh उत्पाद चुनना किसी का भी उत्तर नहीं देता। पूरी तरह उठने वाली टनल भी हर टेनेंट को हर दूसरे तक पहुँचने दे सकती है, और दोनों को एक ही चीज़ मानने वाली समीक्षा गलत डिज़ाइन को मंज़ूरी देती है। पहले ग्राहक-से-संसाधन नक्शा लिखें: प्रशासक, सहायता पहुँच, साझा सेवाएँ और वे रास्ते जो अस्वीकृत ही रहने चाहिए।

उत्पाद से नहीं, नक्शे से शुरू करें

वह नक्शा पहला दस्तावेज़ है, और नीचे का हर विकल्प केवल यह निर्णय है कि उसे लागू करने वाली सीमा कहाँ रहती है। इसे समीक्षा-योग्य रखें: प्रति ग्राहक एक पंक्ति, प्रति साझा सेवा एक पंक्ति और अस्वीकृत रास्ते लिखे हुए।

जो नक्शा कोई पढ़ नहीं सकता वह नक्शा कोई लागू भी नहीं करेगा।

एक प्रवेश बिंदु और उसकी मैपिंग समस्या

हर स्थान एक ही परिचालन प्रश्न से तय होता है, और तालिका ही पूरी तुलना है।

PlacementThe question it lives or dies on
One shared gatewayHow does an admitted identity end up limited to its own resources and its own routing context?
A gateway per tenantWho owns each gateway, its credentials, its policy, its updates and its eventual retirement?
A connection per hosted machineHow do enrollment, per-machine policy and replacement work at fleet scale?

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

अधिकांश डिज़ाइनों के लिए यही परीक्षा है। जो दो टेनेंट आंतरिक रूप से 10.0.0.0/8 से संख्या देते हैं, उन्हें नामकरण परंपरा नहीं, अलग रूटिंग स्थिति चाहिए।

प्रति टेनेंट गेटवे सीमाएँ और प्रणालियाँ खरीदता है

प्रति ग्राहक एक गेटवे कुछ प्रशासनिक सीमाएँ समझाना आसान बनाता है, क्योंकि उस ग्राहक का प्रवेश और नीति साथ रहते हैं। यह उन प्रणालियों को भी कई गुना बढ़ाता है जिन्हें क्रेडेंशियल, पैच, निगरानी और मालिक चाहिए। और यह सार्वजनिक पतों की कोई एक निर्धारित व्यवस्था थोपता नहीं: एंडपॉइंट साझा करना, अनुवाद और प्रोटोकॉल डिमल्टीप्लेक्सिंग इस पर निर्भर हैं कि कार्यान्वयन वास्तव में क्या समर्थन करता है।

सुरक्षा लाभ गिनने से पहले प्रणालियाँ और लोग गिनें। टीम जितना पैच कर सकती है उससे चार अधिक गेटवे वाला डिज़ाइन व्यवहार में अधिक पृथक नहीं है।

अगर टेनेंट की संख्या हर महीने बदलती है, तो उस मॉडल को टेम्पलेट नहीं, ऑटोमेशन की कहानी चाहिए।

प्रति होस्ट कनेक्शन काम को खिसका देते हैं

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

हर विकल्प के तहत पहचान जारी करने, अपडेट, पहुँच हटाने, निगरानी और पुनर्प्राप्ति के लिए भूमिका नाम दें। फिर पूछें कि जिस दिन एक ग्राहक जाता है उस दिन क्या होता है।

सेवानिवृत्ति तुलना का हिस्सा है

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

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

संबंधित लेख