SaaS फीचर के रूप में सुरक्षा को कैसे शामिल करें: एक गाइड

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

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

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

— जोएल स्पोल्स्की , स्टैक ओवरफ्लो के संस्थापक

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

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

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

उस समय, दो अलग-अलग नेटवर्कों को जोड़ना एक स्पष्ट और भौतिक रूप से ठोस वास्तविकता थी।

हम सभी उन दिनों से आगे बढ़ चुके हैं। अब, आधुनिक तकनीक स्टैक अधिक जटिल हैं; दुनिया भर में फैले परस्पर जुड़े ऐप्स की एक श्रृंखला, 'सर्वश्रेष्ठ नस्ल' उत्पाद कंपनियों द्वारा क्लाउड में चलाए जाते हैं। दशकों से, हम विकसित हुए हैं। आज, यह दुर्लभ है कि दो अलग-अलग कंपनियां वास्तव में अपने पूरे नेटवर्क को एक-दूसरे से जोड़ना चाहती हैं - यह प्रत्येक नेटवर्क के भीतर विशिष्ट ऐप्स और वर्कलोड हैं जिन्हें संवाद करने की आवश्यकता है।

फिर भी, हमने अपने सिस्टम को "सुरक्षित" तरीके से जोड़ने के लिए पुराने तरीकों का उपयोग करना जारी रखा है।

केबलों का वास्तविक संचालन समाप्त हो गया है, लेकिन हम वस्तुतः वही काम कर रहे हैं। ये पुराने तरीके आपको असंख्य नेटवर्कों के संपर्क में लाते हैं, जो शोषण के लिए एक बहुत बड़ा हमला है।

निजी सिस्टम से जुड़ने की आवश्यकता

पिछले दशकों में जब लोग "क्लाउड" या "ऑन-प्रीम" कहते हैं तो उनका मतलब धुंधला हो गया है। किसी भी भ्रम से बचने के लिए, मैं हमारे लिए एक काल्पनिक परिदृश्य बनाऊंगा:

• इनिटेक प्लेटफ़ॉर्म: यह एक SaaS प्लेटफ़ॉर्म है जिसे आप संचालित करते हैं। यह लचीला और स्केलेबल है और प्रमुख क्लाउड प्रदाताओं में से एक पर होस्ट किया गया है। ग्राहक अपने DevOps प्रक्रियाओं को बेहतर बनाने के लिए प्लेटफ़ॉर्म खरीदते हैं क्योंकि यह उपयोगी मेट्रिक्स के एक समूह पर दृश्यता प्रदान करता है और सीधे उनके विकास वर्कफ़्लो में उपयोगी फ़ीडबैक प्रदान करता है।

• ACME Corp: यह Initech का एक बड़ा ग्राहक है जिसे आप समर्थन देना चाहते हैं। वे विभिन्न स्थानों पर बहुत सारे बुनियादी ढांचे चलाते हैं। क्या यह उनके अपने डेटा सेंटर के अंदर होने के पारंपरिक अर्थ में "ऑन-प्रीम" है? क्या यह किसी प्रमुख क्लाउड प्रदाता पर उनके अपने VPC के अंदर है? इससे कोई फर्क नहीं पड़ता! ग्राहक सिस्टम एक या अधिक नेटवर्क में चल रहे हैं जिन्हें Initech नियंत्रित नहीं करता है, जिन तक हमारी पहुँच नहीं है, और जो सार्वजनिक इंटरनेट से सीधे पहुँच योग्य नहीं हैं।

डेवलपर वर्कफ़्लो में सक्रिय सहभागिता

इनिटेक प्लेटफ़ॉर्म के शुरुआती संस्करण के निर्माण में, उत्पाद-बाज़ार फ़िट साबित करने के लिए काम करने के लिए बहुत सारे संभावित ग्राहक हैं। यह प्रमुख संस्करण नियंत्रण प्रणाली प्रदाताओं (उदाहरण के लिए, GitHub, GitLab, Bitbucket, आदि) के सार्वजनिक API के साथ एकीकृत होगा, घटनाओं पर प्रतिक्रिया करने के लिए कमिट/वेबहुक का उपयोग करेगा, परिणामों को वर्कफ़्लो में धकेलेगा, और सब कुछ उम्मीद के मुताबिक काम करेगा।

यह तब बहुत अच्छा है जब उत्पाद निष्क्रिय हो और केवल ACME Corp में किसी व्यक्ति द्वारा शुरू की गई घटनाओं पर प्रतिक्रिया करता हो। कई सेवाएँ दुनिया में बाहरी परिवर्तनों का आकलन करके और अपने ग्राहकों के लिए सुधार लाने में सक्रिय होकर मूल्य प्रदान करना चाहती हैं।

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

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

निजी डेटा तक पहुंच

इनिटेक को अपने कस्टम रिपोर्टिंग समाधान को प्रदर्शित करने के लिए डेटाबेस को क्वेरी करने की आवश्यकता है। यह ऐसी समस्या नहीं है जो इनिटेक के लिए अद्वितीय है क्योंकि लगभग हर ग्राहक डेटा प्लेटफ़ॉर्म (सीडीपी) या विज़ुअलाइज़ेशन टूल में एक ही समस्या है: ग्राहक अपने निजी डेटा को सार्वजनिक इंटरनेट से सुलभ नहीं बनाना चाहते हैं, इसलिए यह आमतौर पर एक निजी सबनेट में डेटाबेस में होगा।

हमारे वर्तमान दृष्टिकोण की समस्याएं

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

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

सार्वजनिक इंटरनेट पर सिस्टम लगाना

अधिकांश निजी सिस्टम के लिए डिफ़ॉल्ट परिनियोजन विकल्प उन्हें निजी नेटवर्क में, निजी सबनेट के साथ, बिना किसी सार्वजनिक आईपी पते के स्थापित करना है। इसके लिए बहुत अच्छे कारण हैं! इनटेक के लिए इस निजी सिस्टम से जुड़ने का सबसे आसान विकल्प ACME Corp से एक सार्वजनिक आईपी पता या होस्टनाम प्रदान करने के लिए कहना होगा जो इंटरनेट से सुलभ हो सके।

यह तो बुरा हुआ।

किसी सिस्टम को शुरू में दुनिया से अलग एक निजी नेटवर्क में डालने के सभी अच्छे कारण तुरंत गायब हो जाते हैं। यह सिस्टम अब पूरे सार्वजनिक इंटरनेट द्वारा पहुँचा जा सकता है, जिससे हज़ारों संभावित हैकर्स लगातार सिस्टम में घुसने की कोशिश कर सकते हैं या बस इसे DoS कर सकते हैं। आप सिर्फ़ एक लीक क्रेडेंशियल, CVE या किसी अन्य समस्या से स्वामित्व से दूर हैं।

रिवर्स प्रॉक्सी

दूसरा तरीका सिस्टम के सामने रिवर्स प्रॉक्सी लगाना है। मैं सिर्फ़ nginx और HA Proxy जैसी चीज़ों की बात नहीं कर रहा हूँ; होस्टेड या मैनेज्ड सेवाओं की एक पूरी श्रेणी है जो इस विवरण में फिट बैठती है।

इसका लाभ यह है कि ACME Corp अब किसी निजी सिस्टम को सीधे सार्वजनिक इंटरनेट पर नहीं डाल रहा है। रिवर्स प्रॉक्सी संभावित DoS हमलों को कम करने के लिए दर-सीमा या पहुँच प्रतिबंधों को ठीक करने की क्षमता भी जोड़ता है। यह एक गहन सुधार में रक्षा है, लेकिन ACME Corp अभी भी पूरे सार्वजनिक इंटरनेट को प्रॉक्सी तक पहुँचने और हमला करने का प्रयास करने की अनुमति दे रहा है।

यदि इसमें कोई समझौता हुआ तो यह वही करेगा जो एक प्रॉक्सी करता है: ट्रैफिक को इच्छित गंतव्य तक जाने देगा।

आईपी अनुमति सूची

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

इनिटेक में, आप अपने वर्तमान ऐप इंस्टैंस और आईपी पतों के बीच एक सख्त युग्मन नहीं चाहते हैं; आप नए आईपी पतों के बारे में ग्राहकों को लगातार सूचित किए बिना आवश्यकतानुसार बुनियादी ढांचे को बढ़ाने में सक्षम होने के लिए लचीलापन चाहते हैं।

इसलिए, IP पते सबसे अधिक संभावना NAT गेटवे या प्रॉक्सी सर्वर से संबंधित होंगे। ACME Corp यह मान सकता है कि केवल एक या दो स्रोत IP पतों तक पहुँच को लॉक करने का मतलब है कि केवल एक या दो दूरस्थ मशीनों को उनके नेटवर्क तक पहुँच प्राप्त है।

वास्तविकता यह है कि रिमोट नेटवर्क पर मौजूद कोई भी चीज़ जो NAT गेटवे या प्रॉक्सी के ज़रिए अनुरोध भेज सकती है, उसे अब ACME Corp नेटवर्क तक भी पहुँच दी जाएगी। यह किसी एक ऐप या मशीन को अनुमति नहीं दे रहा है; आपने पूरे रिमोट नेटवर्क को अनुमति दे दी है।

इससे भी ज़्यादा चिंता की बात यह है कि IP स्रोत पते को आसानी से नकली बनाया जा सकता है। एक संभावित हमलावर एक अच्छी तरह से तैयार अनुरोध बनाने, स्रोत पते को नकली बनाने और ACME Corp नेटवर्क में डेटा या निर्देश भेजने में सक्षम होगा। SaaS विक्रेताओं, जिसमें Initech भी शामिल है, को अनिवार्य रूप से वर्तमान IP पतों की सूची का दस्तावेजीकरण करना पड़ता है ताकि IP की एक तैयार सूची हो जिसे आजमाया जा सके और प्रतिरूपण किया जा सके।

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

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

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

वर्चुअल प्राइवेट नेटवर्क (वीपीएन)

VPN कई कंपनियों में एक आम समाधान है, जिससे कर्मचारी जब ऑफिस से बाहर होते हैं, तो "कॉर्पोरेट नेटवर्क" से जुड़ सकते हैं। इनका इस्तेमाल दूसरे सिस्टम को मौजूदा नेटवर्क से जुड़ने की अनुमति देने के लिए भी किया जाता है।

हम यहाँ जिस उपयोग के मामले की बात कर रहे हैं वह अलग है। यह दो अलग-अलग कंपनियों, एक SaaS उत्पाद और उनके ग्राहकों को एक दूसरे के साथ संवाद करने में सक्षम बनाने के बारे में है।

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

अगर मैं आपसे इसका भौतिक संस्करण करने के लिए कहूं, अपने उत्पादन वातावरण से सीधे किसी अन्य कंपनी के उत्पादन वातावरण में केबल प्लग करने के लिए, तो आप शायद इस पर कुछ समय के लिए विचार करेंगे। बहुत अधिक विचार। और अच्छे कारण से। लेकिन VPN "वर्चुअल" और "निजी" हैं और इतने आसान हैं (केबल चलाने के सापेक्ष) और इतने सर्वव्यापी हैं कि हम इस पर ज्यादा विचार नहीं करते।

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

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

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

आप नेटवर्क पर भरोसा नहीं कर सकते

क्या होगा यदि मैं आपसे कहूं कि चाहे आप अपने सुरक्षा कार्यक्रम में कितना भी समय, लोग और पैसा निवेश करें, आपका नेटवर्क लगभग निश्चित रूप से एक आसानी से शोषण योग्य सुरक्षा छेद के संपर्क में है? ...

उद्योग के आंकड़ों से पता चलता है कि दुनिया के सबसे बड़े उद्यमों में से 1% से भी कम ने अपने नेटवर्क को इस नए और उभरते खतरे से बचाने के लिए अभी तक कोई कदम नहीं उठाया है...

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

— मिशेल जॉनसन , सोनाटाइप

इनमें से प्रत्येक दृष्टिकोण के साथ समस्या यह है कि इसे सुरक्षित मानने के लिए कई अतिरिक्त मान्यताओं की आवश्यकता होती है: कि इंटरनेट पर कोई भी आपके साथ समझौता करने की कोशिश नहीं करेगा, कि आप अनुरोधों के स्रोत आईपी पर भरोसा कर सकते हैं, कि दूरस्थ नेटवर्क पूरी तरह से अच्छे अभिनेताओं से बना है, कि ये मान्यताएं अब और भविष्य में अनिश्चित काल तक सत्य बनी रहेंगी... और ये सभी मान्यताएं आपके द्वारा कनेक्ट किए गए प्रत्येक नेटवर्क और उनके द्वारा कनेक्ट किए गए किसी भी नेटवर्क और किसी भी नेटवर्क के लिए भी सत्य हैं...

ACME Corp के नजरिए से यह कैसा दिख सकता है, इस पर एक नजर डालें:

अब सिर्फ़ दो नेटवर्क और दो कंपनियाँ ही एक दूसरे से जुड़ी नहीं हैं; यह कई नेटवर्क हैं। प्रत्येक SaaS विक्रेता के पास अपनी सेवाओं का अपना सेट होगा जिसका वे उपयोग करते हैं जो इसे और भी बढ़ा देता है। न केवल आप नेटवर्क पर भरोसा नहीं कर सकते, बल्कि आप किसी और पर भी भरोसा नहीं कर सकते। इस तस्वीर में कोई भी भागीदार केवल एक नेटवर्क गलत कॉन्फ़िगरेशन या समझौता निर्भरता से नेटवर्क के माध्यम से उस जोखिम को संचारित करने से दूर है।

और यह तस्वीर इस समस्या के फ्रैक्टल का सबसे ज़ूम-इन उदाहरण है! ज़ूम आउट करें, और प्रत्येक विक्रेता अपने स्वयं के ग्राहकों के समूह से जुड़ा हुआ है, अपने स्वयं के विक्रेताओं के साथ, अपने स्वयं के ग्राहकों के साथ... जोखिम सतह क्षेत्र तेजी से बढ़ता है।

तो, चलिए इसे हल करें!

हम मिनटों में अपने उत्पाद में सुरक्षा को एक विशेषता के रूप में शामिल कर सकते हैं! हम अधिक केंद्रित और विस्तृत समाधान प्रदान करके सुरक्षा स्तर को बढ़ाएँगे। हम ACME Corp जैसे ग्राहकों पर नेटवर्क-स्तर पर बदलाव करने के लिए कहकर समस्याएँ थोपना भी बंद करने जा रहे हैं।

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

यहाँ दिया गया उदाहरण यह दर्शाएगा कि कैसे Initech Platform एक स्व-होस्टेड GitHub Enterprise सर्वर से कनेक्शन स्थापित कर सकता है, जिसका प्रबंधन ACME Corp द्वारा किया जाता है। अंतिम परिणाम इस प्रकार दिखाई देगा:

सभी आवश्यक भागों को तैयार करने में बस कुछ ही मिनट लगते हैं! यह कैसे करना है यह जानने के लिए, स्व-होस्टेड एजेंट का आधार बनाने के लिए हमारे कोड टूर पर एक नज़र डालें।