MongoDB असुरक्षा के स्तर और उनसे कैसे बचें

अधिकांश डेटाबेस प्रबंधन प्रणालियों में अपने डेटा को किसी बाहरी व्यक्ति या किसी अनधिकृत व्यक्ति या एप्लिकेशन से सुरक्षित करने की कई तकनीकें होती हैं। तकनीकें आपके डेटा को उपयोगकर्ता की अनुमति के बिना पढ़ने या कॉपी करने से रोकती हैं।

MongoDB कोई अलग नहीं है क्योंकि इसमें कुछ असुरक्षा के स्तर हैं। इस ब्लॉग पोस्ट में, हम MongoDB में असुरक्षा के स्तर और उनसे बचने के तरीके पर चर्चा करेंगे ताकि आप अपने MongoDB इंस्टॉलेशन को सुरक्षित रख सकें।

आपके MongoDB की सुरक्षा और सुरक्षा के लिए, निम्नलिखित कुछ प्रमुख सुरक्षा उपाय हैं जिन पर सख्ती से विचार किया जाना चाहिए:
 

1. उपयोगकर्ता कनेक्शन का प्रमाणीकरण।

2. प्राधिकरण/भूमिका-आधारित अभिगम नियंत्रण।

3. नेटवर्क एन्क्रिप्शन/ट्रांसपोर्ट एन्क्रिप्शन।

4. संग्रहण एन्क्रिप्शन/एन्क्रिप्शन-एट-रेस्ट।

5. ऑडिटिंग।

इस लेख में, हम प्रमाणीकरण और प्राधिकरण पर अधिक ध्यान देने के साथ उपरोक्त सुरक्षा उपायों को विस्तार से देखेंगे।

प्रमाणीकरण और प्राधिकरण

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

भूमिका-आधारित अभिगम नियंत्रण कॉन्फ़िगर करने के लिए;

1. पहले उपयोगकर्ता व्यवस्थापक बनाएं।

2. अतिरिक्त उपयोगकर्ता बनाएं।

3. फिर सिस्टम तक पहुंचने वाले प्रत्येक व्यक्ति/एप्लिकेशन के लिए एक अद्वितीय MongoDB उपयोगकर्ता बनाएं।

4. कम से कम विशेषाधिकार के सिद्धांत का पालन करके, आपको ऐसी भूमिकाएं बनानी चाहिए जो एक सेट के लिए आवश्यक सटीक पहुंच अधिकारों को परिभाषित करती हों उपयोगकर्ताओं की।

5. फिर उपयोगकर्ताओं को केवल वही भूमिकाएं सौंपें जिनकी उन्हें अपने कार्यों में प्रदर्शन करने की आवश्यकता है। उपयोगकर्ता क्लाइंट एप्लिकेशन या व्यक्ति हो सकता है।

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

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

प्रमाणीकरण और प्राधिकरण के बीच समानताएं

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

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

प्रमाणीकरण और प्राधिकरण के बीच अंतर

• ये दोनों अलग हैं क्योंकि ये सॉफ़्टवेयर के दो भाग हैं जिनके अलग-अलग कार्य हैं।

प्रमाणीकरण ==उपयोगकर्ता पहचान, क्रेडेंशियल जांच के माध्यम से।

Authorization ==डीबी ऑब्जेक्ट और डीबी कमांड अनुमतियां असाइन करना और लागू करना।

• आरंभिक सेटअप के दौरान, लोकलहोस्ट कनेक्शन के लिए प्रमाणीकरण अक्षम है। यह संक्षिप्त है, हालांकि जब आपको पहला उपयोगकर्ता बनाने का एक अवसर मिलता है, तो अपवाद (प्रमाणीकरण और प्राधिकरण एक साथ नियम पर) विशेषाधिकार छोड़ दिया जाता है।

कैसे जांचें कि प्रमाणीकरण और प्राधिकरण सक्षम हैं या नहीं

मोंगोडीबी के पहले संस्करणों में डिफ़ॉल्ट रूप से "- प्रमाणीकरण" सेट किया गया था और इसे व्यापक रूप से एक खराब कदम माना जाता है। संस्करण 4.0 में भी यह अभी भी डिफ़ॉल्ट रूप से बंद था। स्टार्टअप चेतावनियों और विभिन्न जोखिम में कमी के बावजूद खाली कॉन्फ़िगरेशन अभी भी प्राधिकरण के बंद होने के बराबर है  जैसे कि लोकलहोस्ट MongoDB v3.6 में एकमात्र डिफ़ॉल्ट-बाउंड नेटवर्क डिवाइस बन गया है।

आप प्रमाणीकरण का उपयोग नहीं कर रहे हैं या यों कहें कि आपके पास प्रमाणीकरण सक्षम नहीं है यदि mongod कॉन्फ़िगरेशन फ़ाइलें नहीं हैं:

1. सुरक्षा.प्राधिकरण को 'सक्षम' पर सेट करें।

2. एक Security.keyfile शामिल करें।

3. एक security.clusterAuthMode सेटिंग शामिल करें जो प्रमाणीकरण को चालू रखने के लिए बाध्य करती है।

यह जांचने के लिए कि आपके पास प्रमाणीकरण और प्राधिकरण सक्षम है या नहीं, आप इस त्वरित मोंगो शेल वन-लाइनर को आज़मा सकते हैं (बिना उपयोगकर्ता क्रेडेंशियल तर्क सेट के):

mongo --host : --quiet --eval 'db.adminCommand({listDatabases:1})'

आपको जो प्रतिक्रिया मिलनी चाहिए वह एक "अनधिकृत" त्रुटि है। लेकिन, दूसरी ओर, यदि आपको डेटाबेस नामों की एक सूची मिलती है, तो स्वचालित रूप से इसका मतलब है कि आपके पास एक नग्न MongoDB परिनियोजन है।

बाहरी प्रमाणीकरण

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

बस, बाहरी प्रमाणीकरण सेवा एक Kerberos KDC, या एक ActiveDirectory या OpenLDAP सर्वर होगी। आपको ध्यान देना चाहिए कि बाहरी प्रमाणीकरण का उपयोग आपको एक ही समय में सामान्य MongoDB उपयोगकर्ता खाते रखने से नहीं रोकता है।

आंतरिक प्रमाणीकरण

इसके विपरीत, MongoDB आंतरिक प्रमाणीकरण का अर्थ बाहरी प्रमाणीकरण के विपरीत नहीं है। ऐसा इसलिए है क्योंकि प्रमाणीकरण सक्षम के साथ चलने वाला एक मोंगोड नोड इस बात पर भरोसा नहीं करेगा कि कोई भी टीसीपी पीयर एक और मोंगोड या मोंगोस नोड है क्योंकि यह एक जैसा संचार करता है। इसके बजाय, यह आवश्यक है कि सहकर्मी साझा रहस्य के प्रमाण द्वारा प्रमाणित करे।

MongoDB में दो प्रकार के आंतरिक प्रमाणीकरण तंत्र हैं:

1. कीफाइल आंतरिक प्रमाणीकरण।

2. SCRAM या x.509 आंतरिक प्रमाणीकरण।

कीफ़ाइल आंतरिक प्रमाणीकरण

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

यदि किसी के पास कीफाइल की एक प्रति है, तो वे पासवर्ड स्ट्रिंग बनाने के लिए कीफाइल से नियंत्रण और गैर-मुद्रण वर्णों को आसानी से हटा सकते हैं जो उन्हें "_ _ सिस्टम" उपयोगकर्ता के रूप में कनेक्ट करने की अनुमति देगा।

हालांकि, यदि ऐसा होता है और आप अपने MongoDB सर्वर में से एक पर mongod (या रूट) उपयोगकर्ता के रूप में नीचे दिए गए कमांड को चलाते हैं और सफल होते हैं, तो आपको चिंता नहीं करनी चाहिए क्योंकि कोई आकस्मिक रीड-प्रिविलेज लीक नहीं होगा। . ऐसा इसलिए है क्योंकि अगर कीफाइल 400 (या 600) फ़ाइल अनुमति मोड के अलावा किसी अन्य चीज़ में है, तो स्टार्टअप पर मोंगॉड निरस्त हो जाएगा।

mongo --authenticationDatabase local -u __system -p "$(tr -d '\011-\015\040' < /path/to/keyfile)"

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

एक अत्यधिक जोखिम तब बढ़ जाता है जब कीफाइल को "मोंगोड" या अन्य डीबीए टीम के स्वामित्व वाले यूनिक्स उपयोगकर्ता के बजाय एप्लिकेशन टीम के यूनिक्स उपयोगकर्ताओं में से एक के स्वामित्व वाले और चलाए जाने वाले मोंगोस नोड्स के साथ वितरित किया जाता है।

SCRAM या x.509 आंतरिक प्रमाणीकरण

x.509 आंतरिक प्रमाणीकरण तंत्र वास्तव में असममित निजी या सार्वजनिक कुंजी का उपयोग करता है और इसका उपयोग टीएलएस/एसएसएल के साथ मिलकर किया जाना चाहिए। इस तंत्र का उपयोग क्लाइंट कनेक्शन के साथ-साथ आंतरिक प्रमाणीकरण के लिए भी किया जा सकता है।

x.509 या SCRAM तंत्र का Keyfile तंत्र पर एक फायदा है क्योंकि x.509 तंत्र में, यह कम संभावना है कि mongod और mongos नोड्स के साथ तैनात कुंजियों में से एक का दुरुपयोग किया जा सकता है घुसपैठिए जो इसकी एक प्रति प्राप्त करता है। हालांकि, यह इस बात पर निर्भर करता है कि x.509 प्रमाणपत्र कितनी सख्ती से स्थापित किए गए हैं। इस तंत्र से अधिकतम सुरक्षा का आनंद लेने के लिए, आपके पास एक समर्पित सुरक्षा टीम होनी चाहिए जो x.509 अवधारणाओं और सर्वोत्तम प्रथाओं को समझती हो। इन सर्वोत्तम प्रथाओं में शामिल है कि यह किस होस्ट पर काम करेगा, और प्रमाणपत्रों को रद्द करने और रोलओवर करने में सक्षम होना।

नेटवर्क एन्क्रिप्शन/ट्रांसपोर्ट एन्क्रिप्शन

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

नेटवर्क एन्क्रिप्शन के लिए, आपको MongoDB को सभी आउटगोइंग और इनकमिंग कनेक्शन के लिए TLS/SSL का उपयोग करने के लिए कॉन्फ़िगर करना चाहिए। MOngoDB परिनियोजन के mongod और mongos घटकों के साथ-साथ TLS/SSL का उपयोग करके सभी एप्लिकेशन और MongoDB के बीच संचार को एन्क्रिप्ट करें।

संस्करण 4.0 में प्रारंभ; MongoDB उन सिस्टम पर TLS 1.0 एन्क्रिप्शन के लिए समर्थन को अक्षम करता है जहां TLS 1.1+ उपलब्ध है और यह निम्नलिखित मूल TLS/SSL लाइब्रेरी का भी उपयोग करता है:

1. Windows - Secure Channel (Schannel)।

2. लिनक्स/बीएसडी - ओपनएसएसएल।

3. macOS - सुरक्षित परिवहन।

नेटवर्क एक्सपोजर सीमित करें

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

सुरक्षित कॉन्फ़िगरेशन विकल्पों के साथ MongoDB चलाएँ

MongoDB निम्नलिखित सर्वर-साइड संचालन के लिए निष्पादन JavaScript कोड का समर्थन करता है:

1. mapReduce.

2. $कहां।

3. $accumulator.

4. $function.

यदि आप उपरोक्त कार्यों का उपयोग नहीं करते हैं तो सर्वर-साइड स्क्रिप्टिंग को अक्षम करने के लिए कमांड लाइन पर -- noscripting विकल्प का उपयोग करें। इनपुट सत्यापन सक्षम रखें, हालांकि MongoDB net.wireObjectCheck सेटिंग के माध्यम से डिफ़ॉल्ट रूप से इनपुट सत्यापन को सक्षम करता है। यह सुनिश्चित करता है कि mongod intsance द्वारा संग्रहीत सभी दस्तावेज़ मान्य BSON हैं।

MongoDB संग्रहण एन्क्रिप्शन/एन्क्रिप्शन-एट-रेस्ट

संग्रहण एन्क्रिप्शन किसी को अंतर्निहित डेटाबेस फ़ाइलों की एक प्रति प्राप्त करने से रोकता है। ऐसा तब हो सकता है जब कोई आपके डेटासेंटर में सेंध लगाता है और आपके सर्वर की हार्ड डिस्क को चुरा लेता है। MongoDB डेटा में डेटा फ़ाइलें, कॉन्फ़िगरेशन फ़ाइलें, ऑडिटिंग लॉग और मुख्य फ़ाइलें शामिल हैं।

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

ऑडिटिंग

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

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

आगे बढ़ना

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