फोन पर MFA कोड माँगा जाए तो देर हो चुकी—FIDO2 पर कैसे जाएँ

फोन पर MFA कोड माँगा जा रहा है तो सामाजिक अभियांत्रिकी आपकी तकनीकी सुरक्षा-सीमा तक पहुँच चुकी है। इसका अर्थ यह नहीं कि खाता अवश्य चोरी हो गया, बल्कि यह कि साझा किया जा सकने वाला SMS, ईमेल OTP या पुश अब अंतिम बचाव है। समाधान है: पहले प्रशासकों और वित्त टीम को FIDO2 सुरक्षा कुंजी या पासकी दें, नामांकन सुरक्षित करें और सफल परीक्षण के बाद कमजोर विकल्प चरणबद्ध ढंग से हटाएँ।

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

क्यों साझा किया जा सकने वाला कोड पर्याप्त नहीं है

Microsoft का फिशिंग-प्रतिरोधी MFA ढाँचा SMS, ईमेल OTP और साधारण पुश को सामाजिक अभियांत्रिकी, बीच-में-हमलावर तकनीक और लगातार पुश भेजकर स्वीकृति लेने जैसे हमलों के सामने कमजोर मानता है। ये विधियाँ पासवर्ड से अतिरिक्त सुरक्षा देती हैं, पर उपयोगकर्ता अब भी कोड बता सकता है या हमलावर के अनुरोध को स्वीकार कर सकता है।

FIDO2 में सेवा सार्वजनिक कुंजी रखती है और निजी कुंजी प्रमाणक में रहती है। W3C का WebAuthn विनिर्देश सार्वजनिक-कुंजी प्रमाण को संबंधित सेवा से बाँधता है; नकली डोमेन वास्तविक सेवा के लिए उपयोगी प्रमाण नहीं बनवा सकता। स्थानीय PIN या बायोमेट्रिक जाँच प्रमाणक खोल सकती है, लेकिन फोन पर बताने योग्य OTP पैदा नहीं करती।

पहले दायरा और वापसी मार्ग बनाइए

पहचान प्रदाता, ईमेल, लेखांकन, भुगतान, ग्राहक प्रबंधन, कोड भंडार, क्लाउड प्रशासन और दूरस्थ पहुँच की सूची बनाइए। हर सेवा के सामने दर्ज करें कि वह FIDO2 या WebAuthn स्वीकार करती है, FIDO2-सक्षम SSO के पीछे लाई जा सकती है, केवल OTP लेती है या साझा खाते पर निर्भर है। इससे स्पष्ट होगा कि नीति कहाँ सीधे लागू हो सकती है और कहाँ सीमित अपवाद चाहिए।

हर उपयोगकर्ता के लिए प्राथमिक प्रमाणक के साथ स्वतंत्र दूसरा तरीका रखें—मसलन रोजमर्रा की पासकी और अलग सुरक्षित स्थान पर रखी FIDO2 कुंजी। यह दूसरा प्रमाणक SMS को स्थायी वापसी मार्ग बनाने से बचाता है। खोई कुंजी हटाने, नई कुंजी जारी करने और आपातकालीन प्रशासनिक खाते के उपयोग की जिम्मेदारी पहले तय करें; उस खाते की पहुँच सीमित हो और उसका प्रत्येक उपयोग दर्ज किया जाए।

प्रशासक, फिर वित्त, फिर बाकी कर्मचारी

1. छोटा परीक्षण समूह: अलग उपकरणों और ब्राउज़र पर नामांकन, प्रवेश, प्रमाणक खोने और पुनर्प्राप्ति की जाँच करें। किसी उत्पादन प्रशासक के लिए परीक्षण वाला प्रमाणक अकेला प्रवेश मार्ग न बने।
2. प्रशासक: पहचान प्रदाता, क्लाउड, ईमेल और सुरक्षा उपकरणों के विशेषाधिकार प्राप्त खातों पर FIDO2 अनिवार्य करें। जहाँ संभव हो, दैनिक काम की पहचान से प्रशासनिक पहचान अलग रखें।
3. वित्त और भुगतान अनुमोदक: बैंक विवरण, चालान, वेतन या भुगतान बदल सकने वाले लोगों को अगला समूह बनाना सीमित बजट में जोखिम-आधारित प्राथमिकता है। उन्हें संगठन-नियंत्रित बैकअप कुंजी दें और नामांकन स्वतंत्र पहचान-जाँच के बाद कराएँ।
4. शेष कर्मचारी: विभाग-दर-विभाग पासकी या सुरक्षा कुंजी उपलब्ध कराएँ। वास्तविक प्रवेश और सहायता अनुरोध देख लेने के बाद ही उस समूह के पुराने MFA विकल्प बंद करें। ठेकेदारों और अतिथियों के अपवादों के लिए मालिक तथा समाप्ति तिथि तय करें।

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

नामांकन और पुनर्प्राप्ति को सुरक्षित रखिए

मजबूत प्रमाणक को ऐसे मौजूदा सत्र से पंजीकृत न कराएँ जिसे फोन करने वाला हमलावर प्रभावित कर सकता है। पहचान कार्यालय में अधिकृत व्यक्ति, पहले से पंजीकृत मजबूत प्रमाणक या पहचान प्रदाता के समय-सीमित आरंभिक प्रवेश जैसे स्वतंत्र माध्यम से जाँचें। केवल कर्मचारी क्रमांक, हाल की भुगतान जानकारी या कॉल पर बताया OTP पर्याप्त पहचान-प्रमाण नहीं होना चाहिए।

नामांकन के समय ही प्राथमिक और बैकअप प्रमाणक से अलग-अलग प्रवेश कराएँ। प्रमाणक जोड़ने, हटाने और MFA रीसेट करने की घटनाओं पर चेतावनी लगाएँ। सहायता डेस्क के लिए लिखित प्रक्रिया रखें: कौन पहचान जाँचेगा, कौन रीसेट स्वीकृत करेगा, अस्थायी प्रवेश कितनी देर चलेगा और पुराने प्रमाणक को कब हटाया जाएगा।

FIDO2 के बाद भी सत्र और पुराने ऐप बचते हैं

FIDO2 फिशिंग वाले डोमेन को वैध प्रमाण देने से रोकता है, लेकिन पहले से चोरी सक्रिय सत्र या समझौता किया उपकरण अपने आप ठीक नहीं करता। Google Threat Intelligence Group की UNC6671 जाँच में हमलावरों ने निजी फोन पर सहायता डेस्क बनकर कॉल किए, नकली नामांकन पृष्ठों से MFA टोकन रोके और क्लाउड सत्र स्थापित किए; उसकी नियंत्रण-सिफारिशों में FIDO2, छोटी सत्र अवधि और संवेदनशील संसाधनों पर दोबारा मजबूत प्रमाणीकरण शामिल हैं।

इसलिए नया प्रमाणक जोड़ने, भुगतान विवरण बदलने और अधिकार बढ़ाने पर दोबारा FIDO2 माँगें। विशेषाधिकार प्राप्त खातों के निष्क्रिय और अधिकतम सत्र सामान्य खातों से छोटे रखें। जो पुराना अनुप्रयोग WebAuthn नहीं समझता, उसे संभव हो तो SSO के पीछे रखें; अन्यथा उपयोगकर्ता समूह और नेटवर्क पहुँच सीमित करें तथा अपवाद को मालिक और समाप्ति तिथि दें। सेवा खातों और स्वचालित कार्यप्रवाहों के लिए मानव की सुरक्षा कुंजी के बजाय समर्थित कार्यभार पहचान या प्रमाणपत्र चाहिए।

कमजोर MFA कब बंद करना है

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

सफलता को बाँटी गई कुंजियों से नहीं, वास्तविक प्रवेश से मापें: कितने लक्षित खाते फिशिंग-प्रतिरोधी तरीके से प्रवेश कर रहे हैं, कौन-से अनुप्रयोग अब भी कमजोर विकल्प स्वीकार करते हैं और किन अपवादों की समय-सीमा निकल चुकी है। अंतिम नियम स्पष्ट रहे—वैध कारोबारी प्रवेश फोन पर साझा करने योग्य MFA कोड नहीं माँगता; ऐसा अनुरोध मिले तो बातचीत रोककर पहले से प्रकाशित आधिकारिक सहायता माध्यम से घटना की सूचना दें।