लो-कोड/नो-कोड ऐप्स में उपयोगकर्ता प्रतिरूपण से सावधान रहें

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

यहां बताया गया है कि किसी और के साथ अपने एंटरप्राइज़ क्रेडेंशियल साझा करना बुरा व्यवहार क्यों है। मान लें कि मैं एक बार के उपयोगकर्ता-व्यवहार विश्लेषण के लिए उत्पादन लॉग को क्वेरी करने के लिए एक सहयोगी को अपने क्रेडेंशियल पास करना चाहता हूं। एक विशिष्ट उद्यम में, किसी को नए डेटा स्रोत को क्वेरी करने की अनुमति देने का मतलब एक लंबी पहुंच समीक्षा प्रक्रिया हो सकती है, खासकर जब उत्पादन या संवेदनशील डेटा की बात आती है। मेरे सहयोगी आसानी से निराश हो सकते हैं। "मैं बस इतना चाहता था कि यह छोटी सी एक बार की क्वेरी करें, और मैं पहले से ही एक महीने से इंतजार कर रहा हूं!" वे कह सकते थे। मैं सिर्फ उनके लिए क्वेरी चला सकता था, लेकिन मैं अपने दिन-प्रतिदिन के कार्यों से घिरा हुआ हूं, और एक बार के प्रश्न जटिल हो जाते हैं।

मेरे पास एक त्वरित समाधान बचा है: मैं बस अपने सहयोगी के साथ अपना उपयोगकर्ता नाम/पासवर्ड साझा कर सकता हूं। अगर उन्हें एमएफए चुनौती मिलती है, तो मैं सहर्ष स्वीकृति दूंगा। मुझे क्वेरी चलाने में समय नहीं लगाना पड़ता है, और मेरा सहयोगी अनब्लॉक हो जाता है। हर कोई जीतता है! सही?

ठीक है, आप अपने विश्लेषण में सही होंगे, लेकिन आप बड़ी तस्वीर को याद कर रहे हैं। हालांकि यह उद्यम के लिए महत्वपूर्ण है कि आपके सहयोगी अपने उपयोगकर्ता व्यवहार विश्लेषण करवाएं, यह उतना ही महत्वपूर्ण है, यदि अधिक नहीं, तो यह महत्वपूर्ण है कि आपका उद्यम गोपनीयता और सुरक्षा मानकों की एक पूरी मेजबानी के अनुरूप बना रहे और सुरक्षा के लिए कंपनी की प्रतिबद्धता को बनाए रखते हुए ग्राहकों का विश्वास बनाए रखता है। .

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

एक वास्तविक दुनिया का उदाहरण

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

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

एप्लिकेशन बनाते समय, जेन को कई मुद्दों पर काम करना पड़ा, जिनमें से सबसे बड़ी अनुमति थी। पूरे संगठन में कर्मचारियों के पास ग्राहक डेटाबेस को क्वेरी करने के लिए उनकी आवश्यक जानकारी प्राप्त करने के लिए सीधी पहुंच नहीं है। अगर उन्होंने किया, तो जेन को यह एप्लिकेशन नहीं बनाना पड़ेगा। इस समस्या को दूर करने के लिए, जेन ने डेटाबेस में लॉग इन किया और अपने प्रमाणित सत्र को सीधे एप्लिकेशन में एम्बेड किया। जब एप्लिकेशन को एक उपयोगकर्ता से अनुरोध प्राप्त होता है, तो वह उस क्वेरी को निष्पादित करने के लिए जेन की पहचान का उपयोग करेगा और फिर उपयोगकर्ता को परिणाम लौटाएगा। यह क्रेडेंशियल-एम्बेडिंग सुविधा, जैसा कि हमने पिछले महीने खोजा था, लो-कोड/नो-कोड प्लेटफॉर्म की एक प्रमुख विशेषता है। जेन ने एप्लिकेशन में रोल-बेस्ड एक्सेस कंट्रोल (आरबीएसी) स्थापित करना सुनिश्चित किया ताकि प्रत्येक उपयोगकर्ता केवल उन ग्राहक मामलों तक पहुंच सके जिन्हें उन्हें सौंपा गया है।

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

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

एक त्वरित जांच के बाद, एमी ने एक महत्वपूर्ण जानकारी का खुलासा किया: सभी आईपी पतों और तारीखों में वे सभी प्रश्न एकल उपयोगकर्ता पहचान का उपयोग कर रहे थे, ग्राहक देखभाल टीम से जेन नाम का कोई व्यक्ति।

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

जेन, एमी और ऐपसेक टीम ने समाधान मिलने तक एप्लिकेशन को बंद करने का फैसला किया। पूरे संगठन में एप्लिकेशन उपयोगकर्ता निराश थे क्योंकि वे इस पर भरोसा करने आए थे, और ग्राहक भी इसे महसूस कर रहे थे।

जबकि एमी ने इस मुद्दे को बंद कर दिया और अपने निष्कर्षों का दस्तावेजीकरण किया, ग्राहक सेवा के वीपी ग्राहक संतुष्टि दर में गिरावट को देखकर खुश नहीं थे, इसलिए उन्होंने जेन को स्थायी समाधान तलाशने के लिए कहा। प्लेटफ़ॉर्म के दस्तावेज़ीकरण और संगठन के सेंटर ऑफ़ एक्सीलेंस टीम की मदद से, जेन ने अपनी एम्बेडेड पहचान को एप्लिकेशन से हटा दिया, डेटाबेस को क्वेरी करने के लिए प्रत्येक उपयोगकर्ता की पहचान का उपयोग करने के लिए ऐप को बदल दिया, और सुनिश्चित किया कि उपयोगकर्ता केवल उन ग्राहक मामलों के लिए अनुमति प्राप्त करें जिनसे वे जुड़े हुए हैं . अपने नए और बेहतर संस्करण में, एप्लिकेशन ने ग्राहक डेटाबेस को क्वेरी करने के लिए प्रत्येक उपयोगकर्ता की पहचान का उपयोग किया। जेन और एप्लिकेशन उपयोगकर्ता खुश थे कि एप्लिकेशन ऑनलाइन वापस आ गया है, एमी और ऐपसेक टीम खुश थी कि जेन की पहचान अब साझा नहीं की गई है, और उद्यम ने देखा कि ग्राहक संतुष्टि दर फिर से ऊपर चढ़ने लगी है। सब कुछ ठीक था।

दो हफ्ते बाद, एसओसी को उत्पादन ग्राहक डेटाबेस तक असामान्य पहुंच पर एक और अलर्ट प्राप्त हुआ। यह संदिग्ध रूप से उसी डेटाबेस पर पिछले अलर्ट के समान लग रहा था। फिर से, पूरे संगठन के आईपी पते डेटाबेस को क्वेरी करने के लिए एकल उपयोगकर्ता की पहचान का उपयोग कर रहे थे। फिर, वह उपयोगकर्ता जेन था। लेकिन इस बार, सुरक्षा टीम और जेन को पता था कि ऐप अपने उपयोगकर्ता की पहचान का उपयोग करता है। क्या चल रहा है?

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

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

लो-कोड/नो-कोड सुरक्षा चुनौती को संबोधित करना

ऊपर की कहानी एक बहुराष्ट्रीय B2C कंपनी का वास्तविक जीवन का परिदृश्य है। गोपनीयता की रक्षा के लिए कुछ विवरण छोड़े गए या समायोजित किए गए। हमने देखा है कि कैसे एक नेक कर्मचारी अनजाने में अन्य उपयोगकर्ताओं के साथ अपनी पहचान साझा कर सकता है, जिससे आईटी, सुरक्षा और व्यवसाय में कई तरह की समस्याएं पैदा हो सकती हैं। जैसा कि हमने पिछले महीने पता लगाया, क्रेडेंशियल-साझाकरण कम-कोड/नो-कोड की एक प्रमुख विशेषता है। यह आदर्श है, अपवाद नहीं।

As उद्यम में कम-कोड/नो-कोड खिलता रहता है, होशपूर्वक या नहीं, सुरक्षा और आईटी टीमों के लिए व्यवसाय विकास वार्तालाप में शामिल होना महत्वपूर्ण है। लो-कोड/नो-कोड ऐप्स a . के साथ आते हैं सुरक्षा चुनौतियों का अनूठा सेट, और उनकी विपुल प्रकृति का अर्थ है कि वे चुनौतियाँ पहले से कहीं अधिक तीव्र हो जाती हैं।