पासवर्डचा त्याग करता येत असेल, तर त्याचे संरक्षण तरी कशाला?

आपण ज्याला नेहमीचे मानतो ती समस्या

जवळजवळ प्रत्येक वेब-अॅप्लिकेशनमध्ये प्रशासकीय पॅनेल असते. आणि प्रशासकीय पॅनेलमध्ये सहसा प्रवेशाचा पत्ता, प्रमाणीकरण फॉर्म, लॉगिन आणि पासवर्ड असतो.

आपल्याला या रचनेची इतकी सवय झाली आहे की, सगळे नेमके असेच चालले पाहिजे का, हा प्रश्न आपण जवळजवळ विचारतच नाही.

तुमच्याकडे एकच वेबसाइट असेल, तर ही समस्या फारशी महत्त्वाची वाटत नाही. एक मजबूत पासवर्ड तयार केला, द्वि-घटक प्रमाणीकरण सुरू केले, लॉगिनचे प्रयत्न मर्यादित केले आणि काम सुरू ठेवले.

पण प्रकल्पांची संख्या दहा, वीस किंवा तीस झाली तर काय होते?

माझ्या बाबतीत 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 ची कहाणी माझ्यासाठी याच विचारातून सुरू झाली.