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

ट्रांसपोर्ट चुनने से पहले ज़रूरत का नाम दें

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

तीनों ज़रूरतें एक ट्रांसपोर्ट साझा नहीं करतीं:

NeedWhat actually carries it
Management commands and profilesThe enrolled device pulls from a service it can reach; APNs only wakes it
Interactive screen sharingA remote-support tool or private desktop path with its own authentication
Private application accessThat application's permitted network path, which may well be a VPN

उलझन आम तौर पर पुरानी सर्वर चेकलिस्ट से शुरू होती है। OS X Server का एक ऐतिहासिक दस्तावेज़ पोर्ट की लंबी सूची देता है, और कोई उन सबको किनारे पर फ़ॉरवर्ड कर देता है क्योंकि प्रबंधन सेवा कहीं उसी के अंदर है। यह प्रबंधन आर्किटेक्चर नहीं है, और यह खुली सतह को उस कंट्रोल प्लेन से कहीं आगे बढ़ा देता है जिसे आप प्रकाशित करना चाहते थे।

पुश सूचना वास्तव में क्या करती है

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

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

अनुमत रास्तों को स्पष्ट रखें, बीच में मौजूद किसी भी प्रॉक्सी और TLS निरीक्षण नीति सहित। अपेक्षित प्रमाणपत्र श्रृंखला तोड़ने वाला निरीक्षण उपकरण ठीक टूटे हुए नामांकन जैसा दिखेगा।

जब VPN गलत जवाब है

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

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

जब VPN सही जवाब है

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

स्क्रीन शेयरिंग और निजी ऐप पहुँच आम तौर पर रेखा के उसी तरफ़ आते हैं। दोनों कमांड चैनल से कहीं ज़्यादा उजागर करते हैं, और दोनों नामांकन पहचान पर सवारी करने के बजाय अपना प्रमाणीकरण पाने के हक़दार हैं।

बूटस्ट्रैप जाल जो रिकवरी तोड़ता है

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

रिकवरी के लिए दूसरा, स्वतंत्र रास्ता रखें, चाहे वह आउट-ऑफ़-बैंड प्रबंधन चैनल हो, स्थानीय व्यवस्थापक हो, या ऐसी प्रबंधन सेवा हो जो टनल के बिना गम्य रहती है। इसका परीक्षण तब करें जब सब कुछ चल रहा हो, क्योंकि किसी घटना के दौरान आपको साफ़ परीक्षण नहीं मिलेगा।

फिर लिखें कि हर रास्ता तीनों ज़रूरतों में से किसकी सेवा करता है, और उन पोर्ट फ़ॉरवर्डिंग को हटा दें जो किसी की भी सेवा नहीं करते। जिस फ्लीट को सामान्य टनल के बिना प्रबंधित किया जा सके, और जब टनल ही टूटी हो तब भी मरम्मत की जा सके, वही नतीजा है जिसके लिए डिज़ाइन करना लायक है।

संबंधित लेख