जब पासवर्ड छोड़ सकते हैं, तो उसकी सुरक्षा क्यों करें?

वह समस्या जिसे हम सामान्य मानने के आदी हो चुके हैं

लगभग हर वेब एप्लिकेशन में एक प्रशासनिक पैनल होता है। और प्रशासनिक पैनल में आम तौर पर लॉगिन का पता, प्रमाणीकरण फ़ॉर्म, उपयोगकर्ता नाम और पासवर्ड होता है।

हम इस व्यवस्था के इतने आदी हो चुके हैं कि लगभग यह सवाल पूछना ही बंद कर दिया है: क्या सब कुछ इसी तरह काम करना ज़रूरी है?

जब आपके पास एक ही वेबसाइट होती है, तो समस्या खास बड़ी नहीं लगती। एक मज़बूत पासवर्ड बनाइए, दो-कारक प्रमाणीकरण चालू कीजिए, लॉगिन के प्रयासों की सीमा तय कीजिए—और काम करते रहिए।

लेकिन जब परियोजनाओं की संख्या दस, बीस या तीस हो जाए, तो क्या होता है?

मेरे मामले में बात DigiMeld इकोसिस्टम की है, जिसमें तीस से अधिक स्वतंत्र सॉफ़्टवेयर परियोजनाएँ शामिल हैं। हर परियोजना की अपनी संरचना, सर्वर लॉजिक और प्रशासनिक इंटरफ़ेस है।

इसलिए, हर परियोजना को प्रशासनिक पहुँच के लिए एक व्यवस्था चाहिए।

लंबे समय तक मैंने सामान्य तरीका अपनाया: अलग-अलग प्रशासनिक लॉगिन विवरण, मज़बूत पासवर्ड और उन्हें ब्राउज़र में सहेजकर रखना।

यह काम करता था।

लेकिन एक समय पर मैंने सोचा: मुझे इतने सारे प्रशासनिक पासवर्ड सहेजकर रखने ही क्यों चाहिए? मुझे सिर्फ़ सर्वरों की ही नहीं, बल्कि उन तक पहुँच पाने के साधनों की भी सुरक्षा क्यों करनी पड़ती है?

और क्या इस ज़रूरत को ही छोड़ा नहीं जा सकता?

मज़बूत पासवर्ड मूल समस्या को हल नहीं करता

आज के साधनों से बहुत अधिक एन्ट्रॉपी वाले पासवर्ड बनाए जा सकते हैं। सही तरीके से बनाया गया लंबा, यादृच्छिक पासवर्ड सीधे हर संभव संयोजन आज़माकर लगभग कभी नहीं तोड़ा जा सकता।

लेकिन पासवर्ड कितना भी जटिल हो, उसे कहीं न कहीं सहेजना और फिर इस्तेमाल करना पड़ता है।

पासवर्ड मैनेजर, हार्डवेयर कुंजियाँ, बहु-कारक प्रमाणीकरण और अतिरिक्त पाबंदियाँ इस्तेमाल की जा सकती हैं। और ये सभी वास्तव में सुरक्षा बढ़ाते हैं।

फिर भी मूल संरचना बनी रहती है: एक निश्चित इंटरफ़ेस होता है, जिसके ज़रिए उपयोगकर्ता अपने लॉगिन विवरण प्रस्तुत करता है।

उस पर अनुरोध भेजे जा सकते हैं। उसे स्कैन किया जा सकता है। वह स्वचालित हमलों का निशाना बन सकता है।

प्रशासनिक पैनल का पता छिपाया जा सकता है, सामान्य पथ की जगह अक्षरों और प्रतीकों का लंबा, यादृच्छिक क्रम रखा जा सकता है या IP के आधार पर पहुँच सीमित की जा सकती है।

लेकिन तब एक नया सवाल उठता है: इस पते को कहाँ सहेजें और इसका इस्तेमाल कैसे करें?

और सबसे अहम बात—जब प्रशासनिक पहुँच की ज़रूरत सिर्फ़ कुछ खास समय पर होती है, तो प्रवेश का स्थायी बिंदु बनाए रखने की ज़रूरत ही क्या है?

मैं एक ऐसे विचार पर पहुँचा जो आगे चलकर मेरे समाधान का आधार बना:

शायद स्थायी प्रवेश-द्वार की सुरक्षा करने के बजाय, अस्थायी रूप से पहुँच पाने के अधिकार की सुरक्षा करनी चाहिए।

अगर लॉगिन का पारंपरिक पेज हो ही नहीं तो?

मैंने अपनी परियोजनाओं में प्रशासनिक प्रमाणीकरण के पारंपरिक मॉडल को छोड़ने का निर्णय लिया।

सिर्फ़ लॉगिन फ़ॉर्म छिपाना नहीं।

पते का नाम बदलना नहीं।

पासवर्ड की जगह उससे भी ज़्यादा जटिल पासवर्ड रखना नहीं।

बल्कि पासवर्ड से लॉगिन की स्थायी व्यवस्था की ज़रूरत ही ख़त्म करना।

बेशक, प्रशासनिक इंटरफ़ेस कहीं गायब नहीं हुए। एप्लिकेशन प्रबंधित करने के लिए वे अब भी ज़रूरी हैं।

बदला है उन तक पहुँच पाने का तरीका।

अब जुड़े हुए प्रोजेक्टों के प्रशासनिक पैनल में प्रवेश करने के लिए सहेजा हुआ उपयोगकर्ता नाम और पासवर्ड डालने की ज़रूरत नहीं है।

इसके बजाय, मैं पहचान और पहुँच प्रबंधन की अपनी प्रणाली MeldID का इस्तेमाल करता हूँ।

इसका विचार काफ़ी सरल है: प्रशासनिक पहुँच केवल तभी दी जाती है जब सचमुच उसकी ज़रूरत हो—किसी खास उपयोगकर्ता को और किसी खास परियोजना के लिए।

और केवल खाता होना अपने आप में प्रशासनिक पैनल खोलने का अधिकार नहीं देता।

यह अधिकार अलग से दिया जाना चाहिए।

ऐसी पहुँच जो एक मिनट पहले मौजूद नहीं थी

शायद यह पूरी अवधारणा का सबसे दिलचस्प हिस्सा है।

पारंपरिक मॉडल में, व्यवस्थापक के पास लॉगिन के साधन हमेशा मौजूद रहते हैं। जब तक वे मान्य हैं, वह आज, कल या एक महीने बाद उनका इस्तेमाल कर सकता है।

मैंने इस सिद्धांत को बदलने का फ़ैसला किया।

स्थायी प्रशासनिक लॉगिन विवरणों की जगह, लॉगिन शुरू करने की एक अस्थायी सुविधा इस्तेमाल की जाती है।

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

लेकिन ऐसी अस्थायी लिंक का होना भी अपने आप में पहुँच पाने का मतलब नहीं है।

यह एक बुनियादी बात है।

मान लीजिए किसी को किसी तरह वह लिंक मिल गई। केवल पते की गोपनीयता पर निर्भर सामान्य प्रणाली में, ऐसा लीक होना गंभीर समस्या बन सकता है।

मेरे मॉडल में लिंक सिर्फ़ पुष्टि की प्रक्रिया शुरू करने देती है।

आगे बढ़ने के लिए MeldID के भरोसेमंद मोबाइल डिवाइस से अलग अनुमति चाहिए।

उचित पुष्टि के बिना प्रशासनिक सत्र नहीं बनता।

इसीलिए मैं अस्थायी लिंक को पासवर्ड के विकल्प के रूप में नहीं, बल्कि पहुँच देने की प्रक्रिया के एक हिस्से के रूप में देखता हूँ।

यह जानना कि कहाँ जाना है और वहाँ प्रवेश करने का अधिकार होना—दो बिल्कुल अलग बातें हैं।

फ़ोन पहुँच प्रबंधन का साधन बन जाता है

इस मॉडल में मोबाइल डिवाइस की भूमिका सामान्य एक-बार इस्तेमाल होने वाले कोड बनाने वाले साधन से कहीं ज़्यादा अहम है।

इसका इस्तेमाल प्रशासनिक पहुँच से जुड़ी कार्रवाइयों की पुष्टि के लिए किया जाता है।

जब मैं प्रशासनिक पैनल खोलना चाहता हूँ, तो सिस्टम MeldID के ज़रिए पुष्टि माँगता है।

मुझे भरोसेमंद डिवाइस पर संबंधित अनुरोध दिखाई देता है और मैं उस कार्रवाई की पुष्टि करता हूँ।

सफल जाँच के बाद ही सिस्टम लॉगिन प्रक्रिया आगे बढ़ाने की अनुमति देता है।

यह पुष्टि किसी खास कार्रवाई से जुड़ी होती है, न कि केवल इस बात से कि फ़ोन अनलॉक किया गया है।

मोबाइल बायोमेट्रिक्स डिवाइस पर ही उपयोगकर्ता की जाँच करते हैं, जबकि सर्वर की ओर से पंजीकृत डिवाइस से मिली क्रिप्टोग्राफ़िक पुष्टि की जाँच की जाती है।

इस तरीके से केवल पासवर्ड या इस सूचना पर निर्भर नहीं रहना पड़ता कि उपयोगकर्ता ने कथित तौर पर लॉगिन की पुष्टि कर दी है।

यहाँ एक और फ़ायदा सामने आता है: भरोसेमंद डिवाइसों का प्रबंधन किया जा सकता है।

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

इसके बाद वह संबंधित कार्रवाइयों के प्रमाणीकरण का मान्य साधन नहीं रहता।

एक प्रणाली—कई स्वतंत्र परियोजनाएँ

जब मैंने यह व्यवस्था विकसित करना शुरू किया, तो मुख्य लक्ष्यों में से एक था हर परियोजना की स्वतंत्रता बनाए रखना।

मैं सभी प्रशासनिक पैनलों को एक बहुत बड़े एप्लिकेशन में नहीं मिलाना चाहता था।

DigiMeld की हर सेवा को अपने लॉजिक, सेटिंग्स, उपयोगकर्ताओं और डेटा का प्रबंधन पहले की तरह ख़ुद करना चाहिए।

इसलिए मैंने दो कामों को अलग रखा।

MeldID पहचान और प्रशासनिक पहुँच की अनुमति देने के लिए ज़िम्मेदार है।

और हर परियोजना अपने प्रशासनिक कार्यों तथा मौजूदा अधिकारों की जाँच के लिए ज़िम्मेदार है।

इस तरह, एप्लिकेशन को केंद्रीकृत किए बिना पहुँच प्रबंधन का एक केंद्रीकृत मॉडल तैयार हुआ।

इसके अलावा, अधिकार अलग-अलग दिए जाते हैं।

किसी एक परियोजना का व्यवस्थापक सिर्फ़ इसलिए बाकी परियोजनाओं तक अपने आप पहुँच नहीं पा जाता कि उसके पास MeldID खाता है।

हर प्रशासनिक क्षेत्र के लिए उन उपयोगकर्ताओं का अपना समूह तय किया जा सकता है जिन्हें पहुँच की अनुमति है।

सामान्य उपयोगकर्ताओं के अधिकार और प्रशासनिक अधिकार भी एक-दूसरे से अलग रहते हैं।

दर्जनों सेवाओं वाले इकोसिस्टम के लिए यह विशेष रूप से सुविधाजनक साबित हुआ।

मुझे अस्थायी पहुँच स्थायी पहुँच से बेहतर क्यों लगती है

एक और सिद्धांत है जिसे मैंने जानबूझकर प्रणाली में शामिल किया।

प्रशासनिक पहुँच हमेशा के लिए बनी नहीं रहनी चाहिए।

अनुमति सीमित समय तक ही मान्य रहती है और उपयोगकर्ता ब्राउज़र में काम जारी रखे या नहीं, इसकी परवाह किए बिना समाप्त हो जाती है।

समयसीमा पूरी होने के बाद काम जारी रखने के लिए पुष्टि की एक नई प्रक्रिया ज़रूरी होती है।

इससे एक बार किए गए प्रमाणीकरण को स्थायी अधिकार बनने से रोका जा सकता है।

लेकिन केवल समयसीमा तय करना काफ़ी नहीं है।

पहले से दी गई पहुँच को समय से पहले समाप्त करने की सुविधा भी अहम है।

इसीलिए MeldID में प्रशासनिक अनुमतियों को केंद्रीय रूप से रद्द करने की व्यवस्था है।

अनुमति रद्द होने पर जुड़े हुए प्रोजेक्टों को संबंधित घटना मिलती है और वे उससे जुड़े प्रशासनिक सत्र रद्द कर देते हैं।

इस तरह, उपयोगकर्ता के सफलतापूर्वक लॉगिन करते ही पहुँच प्रबंधन का काम ख़त्म नहीं हो जाता।

मेरे लिए अधिकार देने की क्षमता जितनी अहम है, उन्हें रद्द करने की क्षमता भी उतनी ही अहम है।

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

रोज़मर्रा के काम में क्या बदला?

सबसे पहले, सहेजे हुए प्रशासनिक पासवर्ड बार-बार ढूँढ़ने की ज़रूरत ख़त्म हो गई।

अब मुझे जुड़े हुए हर प्रशासनिक पैनल में लॉगिन करने के लिए उपयोगकर्ता नाम और पासवर्ड का एक पूरा संग्रह ब्राउज़र में रखने की ज़रूरत नहीं है।

इसके बजाय, मैं एक ही व्यवस्था के ज़रिए अनुमतियाँ प्रबंधित करता हूँ।

ज़रूरी परियोजना चुनता हूँ, पहुँच की पुष्टि करता हूँ और काम करता हूँ।

जब प्रशासनिक पहुँच की ज़रूरत नहीं रहती, तो उसे रद्द किया जा सकता है।

नई परियोजना जुड़ने पर प्रशासनिक प्रमाणीकरण की पूरी प्रणाली फिर से डिज़ाइन करने की ज़रूरत नहीं पड़ती—यह विशेष रूप से सुविधाजनक है।

उसे मौजूदा मॉडल से जोड़ना और ज़रूरी अनुमतियाँ तय करना ही काफ़ी है।

बेशक, इसका मतलब यह नहीं है कि सुरक्षा से जुड़े सभी जोखिम ख़त्म हो गए हैं।

अस्थायी अनुमतियों, भरोसेमंद डिवाइसों, सर्वर सत्रों और केंद्रीय बुनियादी ढाँचे को भी सुरक्षित रखना ज़रूरी है।

लेकिन अब मुझे हर एप्लिकेशन के लिए प्रशासनिक पासवर्ड प्रबंधन की एक ही समस्या अलग-अलग हल नहीं करनी पड़ती।

और शुरुआत में मेरे लक्ष्यों में से एक यही था।

क्या ऐसी तकनीकें पहले से मौजूद नहीं हैं?

बिल्कुल मौजूद हैं।

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

ऐसे तरीके Identity and Access Management, Privileged Access Management प्रणालियों और Zero Trust अवधारणाओं में देखने को मिलते हैं।

मैं इन सिद्धांतों का आविष्कार करने का दावा नहीं करता।

मेरा काम कुछ और था।

मुझे एक ऐसी एकीकृत प्रणाली बनानी थी जो DigiMeld के बुनियादी ढाँचे की खास समस्याओं को हल करे और कई स्वतंत्र परियोजनाओं तक प्रशासनिक पहुँच प्रबंधित करने दे।

आख़िरकार, मैंने अपनी ज़रूरतों के अनुरूप एक संरचना में कई जाने-पहचाने तरीकों को जोड़ा।

और मेरा मानना है कि इंजीनियरिंग के काम का मूल्य हमेशा बिल्कुल नई तकनीक का आविष्कार करने में नहीं होता।

कभी-कभी मूल्य समस्या को सही तरह से समझने और उसके लिए उचित समाधान खोजने में होता है।

MeldID सिर्फ़ प्रशासनिक पैनलों के लिए नहीं है

यहाँ एक अलग बात स्पष्ट करना ज़रूरी है।

MeldID को केवल मेरे अपने प्रशासनिक उपयोग के साधन के रूप में नहीं बनाया गया था।

यह डेवलपरों को अपने एप्लिकेशन में पहचान और लॉगिन की पुष्टि के तंत्र जोड़ने के लिए SDK भी देता है।

और यह SDK मुफ़्त उपलब्ध है।

उदाहरण के लिए, कोई बाहरी डेवलपर MeldID को उपयोगकर्ता के प्रमाणीकरण की पुष्टि के लिए एक अतिरिक्त स्तर के रूप में इस्तेमाल कर सकता है।

भले ही एप्लिकेशन में उपयोगकर्ता नाम और पासवर्ड से लॉगिन की पारंपरिक व्यवस्था बनी रहे, फिर भी इन विवरणों को सही ढंग से दर्ज करना प्रमाणीकरण पूरा करने के लिए पर्याप्त न हो।

उपयोगकर्ता के भरोसेमंद मोबाइल डिवाइस पर एक अनुरोध आता है, जहाँ वह लॉगिन के प्रयास की पुष्टि या उसे अस्वीकार कर सकता है।

इससे लॉगिन विवरणों के लीक हो जाने पर अनधिकृत पहुँच का जोखिम कम किया जा सकता है।

MeldID की आम तौर पर उपलब्ध इस सुविधा और DigiMeld परियोजनाओं के लिए मेरे बनाए प्रशासनिक पहुँच मॉडल के बीच अंतर समझना ज़रूरी है।

दोनों भरोसे और कार्रवाइयों की पुष्टि के समान सिद्धांतों का इस्तेमाल करते हैं, लेकिन अलग-अलग समस्याओं को हल करते हैं।

सुरक्षा का अर्थ सिर्फ़ मौजूदा व्यवस्था को सुरक्षित करना नहीं है

इस प्रणाली पर काम करने के कारण मैंने प्रमाणीकरण के परिचित तरीकों को अलग नज़रिए से देखना शुरू किया।

अक्सर हम उन व्यवस्थाओं को सुरक्षित करने की कोशिश करते हैं जो सिर्फ़ ऐतिहासिक कारणों से मौजूद हैं।

नई जाँचें, पाबंदियाँ, अतिरिक्त पासवर्ड और सुरक्षा की परतें जोड़ते जाते हैं।

कभी-कभी यह सचमुच ज़रूरी होता है।

लेकिन कभी-कभी एक अलग सवाल पूछना ज़्यादा उपयोगी होता है:

क्या जिस व्यवस्था की हम सुरक्षा कर रहे हैं, उसका पुराने रूप में मौजूद रहना ज़रूरी भी है?

मेरे मामले में जवाब था—नहीं।

मुझे प्रशासनिक लॉगिन का ऐसा फ़ॉर्म नहीं चाहिए था जो हर समय उपलब्ध रहे।

मुझे ज़रूरत पड़ने पर सुरक्षित तरीके से प्रशासनिक अधिकार पाने की सुविधा चाहिए थी।

ये दो अलग-अलग काम हैं।

पहले काम से दूसरे की ओर बढ़ने से न सिर्फ़ तकनीकी संरचना बदली, बल्कि परियोजनाओं के साथ रोज़मर्रा का काम करने का तरीका भी बदल गया।

अंतिम पड़ाव नहीं, बल्कि चुनी हुई दिशा

आज यह संरचना DigiMeld इकोसिस्टम के बड़े हिस्से में काम कर रही है।

बाकी परियोजनाओं को धीरे-धीरे प्रशासनिक पहुँच के नए मॉडल पर लाया जा रहा है।

मैं हर एप्लिकेशन के काम की जाँच करते हुए चरणबद्ध तरीके से माइग्रेशन कर रहा हूँ। बदलाव पूरा होने के बाद पूरी प्रणाली का अतिरिक्त ऑडिट करने की योजना है।

इंटरफ़ेस के कुछ हिस्सों और सत्र प्रबंधन के नियमों में अभी बदलाव हो सकते हैं।

लेकिन मूल विचार तय हो चुका है।

मैं उस मॉडल पर वापस नहीं जाना चाहता जिसमें अपनी दर्जनों परियोजनाओं को प्रबंधित करने के लिए मुझे दर्जनों प्रशासनिक पासवर्ड लगातार सहेजकर रखने और इस्तेमाल करने पड़ें।

साथ ही, मैं अपने समाधान को सभी के लिए उपयुक्त नहीं मानता।

हर संगठन की ज़रूरतें, बुनियादी ढाँचा, जोखिम मॉडल और प्रशासन के तरीके अलग होते हैं।

DigiMeld इकोसिस्टम के लिए जो सुविधाजनक और उचित है, ज़रूरी नहीं कि वह किसी दूसरे डेवलपर के लिए भी सबसे अच्छा हो।

फिर भी, अधिकार अस्थायी रूप से देने का सिद्धांत ध्यान देने योग्य है।

निष्कर्ष के तौर पर

मैंने यह अनुभव इसलिए साझा करने का निर्णय नहीं लिया कि मैं ख़ुद को प्रमाणीकरण के किसी नए तरीके का आविष्कारक मानता हूँ।

और न ही इसलिए कि मैं किसी नई प्रणाली को पूरी तरह सुरक्षित बताना चाहता हूँ।

पूर्ण सुरक्षा जैसी कोई चीज़ नहीं होती।

मुझे बस सवाल पूछने का यह तरीका दिलचस्प लगता है।

प्रशासनिक लॉगिन के स्थायी प्रवेश-द्वार को लगातार सुरक्षित करने के बजाय, यह फिर से सोचा जा सकता है कि उसका अस्तित्व ज़रूरी भी है या नहीं।

ढेर सारे पासवर्ड सहेजने के बजाय अस्थायी अनुमतियों का इस्तेमाल किया जा सकता है।

पहले प्रमाणीकरण के बाद अपने आप भरोसा करने के बजाय, खास अधिकार देने की पुष्टि की जा सकती है।

सत्र समाप्त होने का इंतज़ार करने के बजाय, पहुँच को केंद्रीय रूप से रद्द करने की सुविधा रखी जा सकती है।

और अंत में, हर परियोजना में लॉगिन की अलग व्यवस्था रखने के बजाय, एप्लिकेशन की स्वतंत्रता बनाए रखते हुए प्रशासनिक पहुँच प्रबंधन की एक साझा प्रणाली बनाई जा सकती है।

मैं यह दावा नहीं करता कि इस तरीके से सिस्टम के लीक या समझौता होने की संभावना ख़त्म हो जाती है।

यह बस ध्यान को लगातार मौजूद लॉगिन विवरणों की सुरक्षा से हटाकर, अधिकारों को नियंत्रित तरीके से देने और समाप्त करने पर केंद्रित करता है।

शायद कभी-कभी हमले की संभावना वाले क्षेत्र को घटाने का सबसे असरदार तरीका एक और सुरक्षा उपाय जोड़ना नहीं, बल्कि उस चीज़ को छोड़ देना होता है जिसके बिना भी सिस्टम काम कर सकता है।

मेरे लिए MeldID Admin Gateway की कहानी इसी विचार से शुरू हुई।