SaaS MFA और passkeys: सुरक्षित account setup checklist
SaaS accounts के लिए multi-factor authentication और passkeys की योजना बनाएँ—enrollment, recovery, administrator protection और सुलभ rollout सहित।
इस मार्गदर्शिका में
SaaS product में कौन-से MFA विकल्प होने चाहिए?
Multi-factor authentication (MFA) में व्यक्ति को दो अलग authentication factors के नियंत्रण का प्रमाण देना होता है। Passkey या security key phishing-resistant sign-in दे सकती है; authenticator app password के साथ दूसरा factor जोड़ सकती है। हर device, user या risk के लिए एक ही विकल्प सही नहीं होता, इसलिए साफ विकल्प दें और recovery को sign-in जितनी सावधानी से बनाएँ। NIST SP 800-63B-4 तकनीकी reference है, हर commercial SaaS product पर लागू कानूनी बाध्यता नहीं।
मजबूत sign-in के लिए passkey या security key दें
Passkey public-key authentication को website domain से जोड़ती है, जिससे मिलती-जुलती नकली phishing site पर वही sign-in response इस्तेमाल करना कठिन होता है। दूसरा authenticator या सावधानी से बनाया recovery रास्ता भी दें क्योंकि user device खो सकता है। बताएँ कि passkey user के platform account से sync हो सकती है या नहीं, और registered authenticators देखने तथा हटाने दें।
जहाँ उपयुक्त हो authenticator-app का विकल्प दें
Time-based one-time password तब दूसरा factor हो सकता है जब hardware-backed sign-in उपलब्ध न हो। Enrollment के दौरान setup secret केवल एक बार दिखाएँ, device bind करने से पहले सही code माँगें और recovery codes दें। One-time code उपयोगी है, लेकिन phishing-resistant नहीं; हर MFA तरीके को समान रूप से मजबूत न बताएँ।
Text-message code को risk के अनुसार fallback मानें
SMS code number takeover, message interception या social engineering से उजागर हो सकता है और user इसे नकली website पर डाल सकता है। Administrators और high-impact actions के लिए अधिक मजबूत default पर विचार करें। SMS उपलब्ध रहे तो उसकी सीमाएँ बताएँ और MFA कमजोर किए बिना phone number बदलने की सुरक्षित प्रक्रिया दें।
| Account group / action | Primary MFA option | Fallback और recovery | Enrollment test | Owner / review date |
|---|---|---|---|---|
| Workspace administrators | ||||
| Standard members | ||||
| Billing या data export |
SaaS team authenticators को सुरक्षित कैसे enroll और recover करे?
नया device bind करने से पहले signed-in account verify करें
Authenticator जोड़ने, बदलने या हटाने से पहले authenticated session और जरूरत के अनुसार दोबारा authentication लें। पहले से जुड़े channel पर account को सूचना दें और event record करें। User पहले ही lock out हो तो enrollment का कमजोर version देने की जगह अलग, अधिक सुरक्षित recovery प्रक्रिया अपनाएँ।
Recovery codes उपयोगी हों, पर उनका दुरुपयोग कठिन हो
High-entropy, one-time codes बनाएँ; enrollment के बाद दिखाएँ और सुरक्षित रखने का तरीका समझाएँ। हर code उपयोग के बाद invalid करें और current authenticator की पुष्टि के बाद पूरी set बदलने दें। Reusable codes ईमेल न करें और support staff को उन्हें पढ़ने की अनुमति न दें।
Recovery को सुरक्षित रखें और लोगों को बाहर न करें
जहाँ संभव हो एक से अधिक सुरक्षित authenticator दें। Instructions assistive technology और shared devices इस्तेमाल करने वालों के लिए समझने योग्य हों। किसी inaccessible phone या खोई हुई एकमात्र security key को account access का अकेला रास्ता न बनाएँ। High-risk recovery के लिए documented जाँच, स्पष्ट सीमा और audit record रखें।
Customers को lock out किए बिना MFA rollout कैसे करें?
पहले high-impact accounts और actions सुरक्षित करें
Internal administrators, customer workspace owners और payment details बदलने, sensitive data export या credentials बनाने जैसे actions से शुरू करें। Enforcement से पहले MFA requirement और recovery route तैयार रखें। Test accounts, साफ सूचना और तुरंत मदद की योजना के साथ rollout चरणों में करें।
Sensitive बदलावों के लिए step-up check करें
हाल में authenticated session होना irreversible या high-impact action के लिए पर्याप्त नहीं हो सकता। MFA बदलने, privileged user जोड़ने, recovery information बदलने या बहुत संवेदनशील data export करने से पहले नया authenticator check लें। Prompt को उसी action से जोड़ें और बार-बार ऐसे prompt न दें कि user बिना सोचे approve करने लगे।
Lost-device, replacement और incident रास्ते test करें
खोया phone, चोरी laptop, expired session, unavailable email, suspected account takeover और employee departure का अभ्यास करें। खोया authenticator revoke करना, active sessions बंद करना, access लौटाना और activity review करना जाँचें। Enrollment failure और lockout का डेटा देखें, ताकि control कमजोर किए बिना usability ठीक हो।
SaaS MFA और passkeys से जुड़े सवाल
क्या passkeys phishing-resistant होती हैं?
WebAuthn-based passkeys authentication को relying-party domain से bind करती हैं, जिससे नकली domain द्वारा response को दोबारा इस्तेमाल करना कठिन होता है। Device, sync-provider, account recovery और implementation के चुनाव फिर भी मायने रखते हैं; passkey महत्वपूर्ण जोखिम घटाती है, लेकिन account या पूरी service को अचूक नहीं बनाती।
क्या SMS MFA केवल password से बेहतर है?
यह कुछ attacks में अतिरिक्त बाधा दे सकती है, लेकिन number takeover और phishing जैसे risk हैं। जहाँ संभव हो मजबूत तरीके दें, खासकर privileged accounts के लिए, और text-message code को phishing-resistant authenticator के बराबर न बताएं।
क्या एक authenticator कई accounts के लिए इस्तेमाल हो सकता है?
Compatible authenticator एक से अधिक accounts के लिए इस्तेमाल हो सकता है, लेकिन हर SaaS account का credential संबंध अलग से bind और manage करें। User को registered authenticators दिखाएँ और खोया या unwanted authenticator हटाने दें, बिना दूसरे accounts की जानकारी खोले।
क्या हर customer को पहले दिन MFA enroll करने के लिए बाध्य करें?
सही rollout product risk, customer commitment और support क्षमता पर निर्भर करता है। पहले high-impact accounts सुरक्षित करें; पूरी customer base पर enforcement जरूरी हो तो साफ deadline और पहले से सुलभ recovery route दें।
संबंधित व्यावहारिक मार्गदर्शिकाएँ
संबंधित मुद्दों की मार्गदर्शिकाएँ
स्रोत और प्रकाशन रिकॉर्ड
Draft prepared 27 September 2026; engineering, security and editorial review pending · स्रोत जाँचे गए .