खोया VPN प्रमाणक: MFA बंद किए बिना बदलें

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

चरण 1: पंजीकृत कारकों को रिकॉर्ड से पढ़ें, स्मृति से नहीं

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

Get-MgUserAuthenticationMethod -UserId [email protected]

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

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

चरण 2: अनुरोधकर्ता को असफल मार्ग से बाहर सत्यापित करें

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

जब अनुरोध तात्कालिकता और जाँच छोड़ने के दबाव के साथ आता है, तभी धीमे होने का समय है। पुनर्प्राप्ति धोखाधड़ी बिल्कुल जल्दबाज़ मददगार सहकर्मी जैसी दिखती है।

चरण 3: प्रतिस्थापन पंजीकृत करें, फिर पुराना कारक सेवानिवृत्त करें

नया प्रमाणक सामान्य पंजीकरण प्रवाह से पंजीकृत करें, कभी प्रशासनिक बाईपास से नहीं। फिर खोई हुई विधि को स्पष्ट रूप से हटाएँ, क्योंकि प्रतिस्थापन पंजीकृत करने से पिछला प्रमाणक तब तक अधिकृत रहता है जब तक कोई उसे सेवानिवृत्त न करे। यदि पुराना उपकरण किसी और के हाथ में हो सकता है, तो हटाने को तात्कालिक मानें और पुनर्प्राप्ति प्रक्रिया के बजाय घटना प्रक्रिया का पालन करें। मौजूदा सत्रों को उसी पास में रद्द करें, क्योंकि बदलाव से पहले बनाया गया सत्र उसे टिक सकता है:

Revoke-MgUserSignInSession -UserId [email protected]

बाकी सबके लिए कारक हटाना, या गेटवे की प्रमाणपत्र जाँच ढीली करना, एक व्यक्ति की पुनर्प्राप्ति को पूरे परिनियोजन को छूने वाली रुकावट से बदल देता है। बदलाव को एकल खाते तक सीमित रखें और यदि सबूत व्यापक समझौते की ओर इशारा करें तो ऊपर बढ़ाएँ। टिकट में लिखें कि कौन सा कारक सेवानिवृत्त हुआ और किसने उसकी जगह ली।

चरण 4: साबित करें कि खाता दोनों दिशाओं में काम करता है

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

फिर उपयोगकर्ता से वही लॉगिन बिना मार्गदर्शन के पूरा करने को कहें। आपका सफल परीक्षण कॉन्फ़िगरेशन साबित करता है; उनका प्रयास हैंडओवर साबित करता है।

सफल लॉगिन के टाइमस्टैम्प और अब उपयोग हो रहे कारक के नाम के साथ टिकट बंद करें। उसी पास में पुनर्प्राप्ति रिकॉर्ड अपडेट करें, ताकि अगला नुकसान पुरानी नहीं, सटीक इन्वेंटरी से शुरू हो।

चरण 5: वह शर्त हटाएँ जिसने इसे कष्टदायक बनाया

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

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