डेटा बड़ी कंपनियों और संगठनों के लिए नया सोना है इसे अधिकांश आधुनिक व्यवसायों की जीवनदायिनी माना जाता है और इंटरनेट के बड़े दर्शकों को बेचने या बाजार में बेचने के अवसरों का एक बोनस है। बड़ी ई-कॉमर्स या सोशल मीडिया कंपनियों के लिए, डेटा बड़े राजस्व और कमाई उत्पन्न करने की उनकी क्षमता को बढ़ाता है, जिसके लिए डेटा को कसकर सुरक्षित किया जाता है और किसी भी दुर्भावनापूर्ण और घुसपैठ के हमलों के खिलाफ ऑनलाइन परिष्कृत सुरक्षा होती है।
इसलिए डेटा जैसे सोना, इसकी मूल्यवान स्थिति संसाधित होते ही शुरू हो जाती है। इसका कच्चा मूल्य एक गड़बड़ी से भरा है जैसे कि यह एक विशाल अनसुलझा कुतरना है एक बार इसका सार संरचित होने के बाद, डेटा का मूल्य कई गुना बढ़ जाता है। ज़रा सोचिए, अगर आपके पास ऐसी शिक्षा साइट है जो उपयोगकर्ताओं को भुगतान करने की अनुमति देती है। एक बार जब आपके पास ढेर सारे व्याख्यान और मॉड्यूल होते हैं जो आपके लक्षित दर्शक सीख सकते हैं, विकसित कर सकते हैं, और उत्पादकता की एक डिग्री अर्जित कर सकते हैं, तो आपने अवसर और सफलता का स्वाद समझ लिया है क्योंकि आपके पास संरचित डेटा प्राप्त करने से पहले फीस को विनियमित करने का द्वार है। . हालांकि यह हर किसी के सफलता के सपने जैसा लगता है, जब बड़े डेटा और इसके अंतर्निहित सार की बात आती है, तो इसे संसाधित करने में कई जटिलताएं होती हैं और महत्वपूर्ण चिंता आपके डेटाबेस के लिए खतरा है।
डेटाबेस के खतरों को देखने और जांचने के लिए सामान्य रूप से कई और व्यापक क्षेत्र हैं। हालांकि, सबसे आम कारण डेटा चोरी और डेटा उल्लंघन हैं। एक और आम खतरा व्यापक विशेषाधिकार या गलत तरीके से असाइन किए गए और/या उपयोगकर्ता को प्रदान किए गए डेटाबेस तक पहुंच है। किसी डेटाबेस को प्रबंधित करने वाले किसी भी व्यक्ति के लिए संपूर्ण सर्वर होस्ट की सुरक्षा एक चिंता का विषय है। न केवल डेटाबेस के लिए, बल्कि इसके संपूर्ण अंतर्निहित स्टैक के लिए भी जो आपके डेटा स्टोरेज के साथ एक्सेस या इंटरफेस करता है, अपनी सुरक्षा को कड़ा कर दिया है और सभी प्रकार के लागू हमलों जैसे कि छिपकर बातें करना, बदलना, प्लेबैक करना और सेवा से इनकार करना (DDoS) से निपटना है।
इस ब्लॉग में, हम इस बात पर चर्चा करेंगे कि आपको डेटाबेस एक्सेस विशेषाधिकारों को समझने और प्राप्त करने की आवश्यकता क्यों है।
गलत पहुंच विशेषाधिकारों के खतरे
हमें अनिवार्य रूप से भौतिक और तकनीकी स्तर पर एक उपयोगकर्ता को साझा करना होगा या कम से कम एक उपयोगकर्ता बनाना होगा। जबकि, किसी और को एक्सेस देने का मतलब है कि आप उस पर भरोसा करते हैं। इसका मतलब यह भी है कि अधिकृत व्यक्ति को बाहरी दुनिया से एक्सेस और डेटा साझा करने के खतरे और जोखिम को समझना होगा।
आपके एक्सेस विशेषाधिकारों को सुरक्षित करने का सबसे महत्वपूर्ण बिंदु आपके इंजीनियरों जैसे डेटाबेस व्यवस्थापक, सुरक्षा इंजीनियर, या सर्वर व्यवस्थापक के बीच सुरक्षा पर समझ का स्तर है। यदि समझ खराब है या विशेष रूप से सबसे अद्यतित कमजोरियों और जोखिमों के बारे में ज्ञान और अनुभव की कमी है, तो यह संगठन या कंपनी के लिए एक समस्या हो सकती है।
ऐसी बुनियादी चीजें हैं जिन्हें समझना और ध्यान में रखना है ताकि इसमें न्यूनतम या कम से कम घुसपैठ या उजागर न हो सके। अन्यथा, यह आपके डेटा को बाहरी दुनिया से या कम से कम गलत व्यक्ति या लोगों के लिए खतरे में डाल सकता है। संभवतः आपके डेटा को चुराने और आर्थिक रूप से लाभ प्राप्त करने के लिए इसका उपयोग करने के लिए या वे इसे आपसे फिरौती दे सकते हैं और आपके खराब सुरक्षा कार्यान्वयन के बदले में पैसे मांग सकते हैं।
इस अनुभाग में, आइए इन सुरक्षा खतरों के कुछ सामान्य कारणों को देखें।
रूट पहुंच विशेषाधिकार साझा करना
ऑन-प्रिमाइसेस वातावरण के लिए, डेटाबेस उल्लंघन का एक सामान्य मामला ज्यादातर OS स्तर पर या डेटाबेस सॉफ़्टवेयर स्तर पर रूट एक्सेस देने के जोखिम पर निर्भर करता है। ऐसे मामले हैं जहां रूट पासवर्ड वितरित किया जाता है और कई लोगों को उजागर किया जाता है जो केवल सिस्टम पर काम करने वाले प्रशासकों तक ही सीमित होना चाहिए। एक्सेस विशेषाधिकारों को लागू करने से पहले प्रोटोकॉल में सुरक्षा चेकलिस्ट या उपायों की कमी के कारण ऐसा हो सकता है। सुरक्षा चेकलिस्ट होने से किसी भी एक्सेस और विशेषाधिकारों को ट्रैक करने में मदद मिलती है जो जोखिम और खतरे को उजागर कर सकते हैं, खासकर जब एक विशिष्ट ओएस उपयोगकर्ता घुसपैठिए के संपर्क में आता है। चेकलिस्ट आपके संगठन के लिए प्रोटोकॉल के रूप में लागू और लागू किए गए सुरक्षा उपायों पर चर्चा करने या उनका अवलोकन करने में भी आपकी सहायता करती है।
उदाहरण के लिए, एक उपयोगकर्ता जिसके पास रूट एक्सेस है, वह बहुत नुकसान कर सकता है जैसे कि आपके भौतिक स्टोरेज ड्राइव से आपके सभी डेटा को हटाना, रूट पासवर्ड रीसेट करना, अपना खुद का उपयोगकर्ता/पासवर्ड बनाना जो दिखता है एक वैध उपयोगकर्ता की तरह (जब तक कि जल्दी पकड़ा नहीं जाता है, तब तक डेटा की कटाई के लिए बहुत लंबे समय तक इस्तेमाल किया जा सकता है), एक अलग ओएस उपयोगकर्ता के लिए sudo जैसे पोस्टग्रेज उपयोगकर्ता, और घुसपैठिए द्वारा आनंद लेने के लिए बहुत अधिक डरावनी चीजें।
यदि आप MongoDB का उपयोग कर रहे हैं, तो रूट एक्सेस वाला उपयोगकर्ता आपके डेटाबेस सर्वर में लॉग इन कर सकता है। जब तक घुसपैठिया आपकी /etc/mongod.conf या आपकी mongodb कॉन्फ़िगरेशन फ़ाइल का पता लगा सकता है और आपकी कुंजी के पथ का पता लगा सकता है, तब तक लॉगिन करना आसान है। उदाहरण के लिए, इस कमांड का उपयोग करने से आप लॉगिन कर सकते हैं,
[[email protected] ~]# mongo -u __system -p "$(tr -d '\011-\015\040' < /etc/mongo-cluster.key)" --authenticationDatabase local --eval "db.adminCommand( { listDatabases: 1, nameOnly:1 } )"
एक MySQL सामान्य इंस्टॉलेशन सेटअप पर विचार करें, लोकलहोस्ट एक्सेस के लिए रूट एक्सेस को पासवर्ड के बिना छोड़ा जा सकता है। एक बार जब आप रूट हो जाते हैं तो पहुंच प्राप्त करना आसान होता है। फ़ाइल पहुँच जैसे $HOME/.my.cnf या /etc/my.cnf की सामग्री को देखने से आप आसानी से पहुँच प्राप्त कर सकेंगे।
केवल सीमित करने या अपनी रूट एक्सेस y को कम से कम उन लोगों तक सीमित करने की दृढ़ता से अनुशंसा की जाती है जो सर्वर के साथ सीधे काम कर रहे हैं ताकि पैकेज, सुरक्षा अपडेट और आवश्यक पैच लागू करने के लिए सर्वर के साथ काम किया जा सके। विकास दल।
sudoers का ठीक से उपयोग करना
मेनस्ट्रीम ओपन सोर्स डेटाबेस सॉफ़्टवेयर जैसे PostgreSQL, MySQL/MariaDB, MongoDB को एक विशिष्ट OS उपयोगकर्ता बनाने की आवश्यकता होती है। ओएस उपयोगकर्ता को डेटाबेस कार्यक्षमता के भीतर अपनी क्षमताओं के प्रबंधन की अनुमति देने के लिए सीमित एक विशिष्ट भूमिका की आवश्यकता होती है। अंतर्निहित स्टोरेज डिवाइस पथ के लिए उचित पढ़ने और लिखने की अनुमतियां सेट करने की आवश्यकता है। हालाँकि, कुछ ऐसे मामले हैं जो डेटाबेस सॉफ़्टवेयर के लिए इन विशिष्ट उपयोगकर्ताओं का उपयोग कर रहे हैं, उनके पास sudo विशेषाधिकार हैं जो केवल डेटाबेस पहुँच के लिए निर्दिष्ट उपयोगकर्ता तक पहुँचने में सक्षम हैं। OS में उपयोगकर्ता के विशेषाधिकार सीमित होने चाहिए और भूमिका के आधार पर इसकी पहुँच को सीमित करना सबसे अच्छा है। उदाहरण के लिए, Percona Server CVE-2016-6664 के लिए, हालांकि इसे ठीक कर दिया गया है, इस प्रकार की भेद्यता एक विशिष्ट उपयोगकर्ता के संभावित हमले का एक उदाहरण है जिसके पास MySQL खाते तक पहुंच है और रूट एक्सेस प्राप्त है। सूडो उपयोगकर्ताओं की समीक्षा की जानी चाहिए और उन्हें समझाना चाहिए कि भूमिका केवल एक विशिष्ट कार्य करने तक ही सीमित है।
लिनक्स ऑडिटिंग सिस्टम को सक्षम करना जैसे कि ऑडिटड सुरक्षा को बेहतर बनाने में मदद कर सकता है क्योंकि यह ओएस स्तर पर अनदेखी एक्सेस विशेषाधिकारों को बढ़ाता है जिससे आपके डेटाबेस की सुरक्षा कमजोरियां हो सकती हैं। SELinux और AppArmor आपके Linux वातावरण के लिए सुरक्षा मॉड्यूल के अच्छे उदाहरण हैं जो घुसपैठियों या उल्लंघनों के खिलाफ आपकी सुरक्षा को बेहतर बनाने में मदद करने के लिए आपके डेटाबेस सिस्टम को होस्ट करते हैं जिससे आपका डेटा खतरे में पड़ सकता है।
डेटाबेस एक्सेस विशेषाधिकार प्रदान करना
मुख्यधारा के ओपन सोर्स डेटाबेस विशेषाधिकारों की एक विस्तृत सूची प्रदान करते हैं जिन्हें केवल एक विशिष्ट उपयोगकर्ता के लिए एक विशिष्ट क्रिया के लिए निर्दिष्ट करने के लिए अनुकूलित किया जा सकता है। यह डेटाबेस प्रशासकों को विशिष्ट विशेषाधिकारों के आधार पर डेटा पृथक्करण और लक्ष्य कार्रवाई में सुरक्षित रूप से मदद करने का एक व्यापक तरीका है।
सामान्य पहुंच विशेषाधिकार
आपके सबसे अधिक उपयोग किए जाने वाले विशेषाधिकार इन तीन श्रेणियों पर आधारित होंगे:
-
पढ़ने/खोजने में सक्षम जैसे कि चुनें, देखें, देखें, खोजें
-
इन्सर्ट, अपडेट, डिलीट, रिमूव जैसे इन्सर्ट/अपडेट/डिलीट करने में सक्षम
-
उपयोगकर्ता बनाएं, भूमिका बनाएं, परिवर्तन करें, प्रतिकृति बनाएं, उपयोगकर्ता छोड़ें/टेबल/ SCHEMA's, किल ऑपरेशंस, आदि।
इन श्रेणियों को आपकी सुरक्षा जांच सूची के आधार पर अधिक परिष्कृत विशेषाधिकारों में विस्तारित किया जा सकता है। किसी विशिष्ट कार्य के लिए विशिष्ट विशेषाधिकारों के साथ बनाए जाने वाले विशिष्ट उपयोगकर्ता को परिभाषित करना अच्छा है। उदाहरण के लिए, एक एप्लिकेशन में कई उपयोगकर्ता हो सकते हैं जिनके अपने निर्दिष्ट विशेषाधिकार निर्दिष्ट हैं। हालांकि आवेदन इस प्रकार के कार्यान्वयन के साथ एक जटिल के रूप में हो सकता है। ऐसे मामले हैं कि प्रति-उपयोगकर्ता कनेक्टिविटी संसाधन-गहन हो सकती है जैसे ओआरएम जैसे हाइबरनेट का उपयोग करना, उदाहरण के लिए। दूसरी ओर, यह आपके आवेदन के वास्तुशिल्प डिजाइन पर निर्भर करता है। किसी एप्लिकेशन में प्रति-उपयोगकर्ता आधार का उद्देश्य अधिक परिष्कृत डेटाबेस एक्सेस विशेषाधिकार को बनाए रखने में मदद कर सकता है और आपके डेटा को अवांछित डिलीट, अपडेट या आपके डेटाबेस पर हमला करने वाले SQL इंजेक्शन से नुकसान से बचा सकता है।
ज्यादातर मामलों में, कोई एप्लिकेशन डेटाबेस से कनेक्ट करने के लिए एक उपयोगकर्ता का उपयोग करता है, जो विशेष रूप से एप्लिकेशन को चलाने के लिए उसके कार्यों तक ही सीमित होता है। यह सबसे अच्छा है कि आप अपने एप्लिकेशन उपयोगकर्ता विशेषाधिकार को केवल पढ़ने-लिखने की पहुंच के लिए डिज़ाइन करें। जबकि यदि प्रशासनिक कार्यों की आवश्यकता है, तो आपके एप्लिकेशन एक्सेस में एक विशिष्ट स्क्रिप्ट, डेमॉन या मॉड्यूल को सामान्य उपयोगकर्ताओं से अलग करना होगा।-।
डेटाबेस एक्सेस से बचना चाहिए
PostgreSQL और MySQL/MariaDB के पास सभी विशेषाधिकारों का उपयोग करके उपयोगकर्ता को अनुदान देने का यह विकल्प है। PostgreSQL के लिए, अपने उपयोगकर्ता को NOSUPERUSER के साथ रखना भी सबसे अच्छा है। यदि संभव हो तो इससे हर कीमत पर बचना होगा। यह विशेषाधिकार हर उस कार्य को कर सकता है जो आपके मूल्यवान डेटा को संभावित रूप से नष्ट या नुकसान पहुंचा सकता है। आप अपने व्यवस्थापक या रूट एक्सेस के लिए सभी विशेषाधिकारों का उपयोग कर सकते हैं लेकिन केवल उन उपयोगकर्ताओं तक सीमित हैं जिन्हें प्रशासनिक कार्यों को करने और डेटा का प्रबंधन करने के लिए सुपर विशेषाधिकारों की आवश्यकता होती है।
प्रति-तालिका या प्रति-स्कीमा आधार पर पहुंच
केवल आवश्यक तालिकाओं के लिए उपयोगकर्ता को एक्सेस प्रदान करना एक अच्छा अभ्यास है। . इसलिए, भले ही उपयोगकर्ता के पास कुछ प्रशासनिक विशेषाधिकार हों, कोई भी क्षति केवल तालिकाओं के सीमित सेट तक ही होती है। या तो आप एक स्कीमा-वाइड पर सेट कर सकते हैं; एक सीमित तालिका तक पहुंच प्रदान करने से एक विस्तृत प्रकार के विशेषाधिकार मिलते हैं और यह आपके डेटा को नुकसान से बचाने में आपकी मदद करता है।
केवल-होस्ट तक सीमित पहुंच
इसके संसाधन आईपी पते के माध्यम से कनेक्ट करने से आपके डेटा तक पहुंच सीमित करने में मदद मिलती है। उदाहरण के लिए MySQL में '%' का उपयोग करने से बचें, जैसे कि,
GRANT SELECT, INSERT, DELETE ON mydb TO [email protected]'%' IDENTIFIED BY 'password';किसी भी होस्ट से कनेक्ट होने के लिए नुकसान की सीमा को उजागर किया जाता है और यह वह नहीं है जो आप करना चाहते थे। यह भेद्यता लगाता है और आपके डेटाबेस में घुसपैठ करने की चुनौती बहुत कम है।
PostgreSQL के लिए, सुनिश्चित करें कि आपने अपना pg_hba.conf और उपयोगकर्ता को उसके होस्ट की विशिष्ट सीमा तक ही सेट किया है। यह MongoDB पर भी लागू होता है जिसके लिए आप इसे अपनी MongoDB कॉन्फ़िगरेशन फ़ाइल या /etc/mongodb.conf में सेट कर सकते हैं। MongoDB में, आप प्रमाणीकरण प्रतिबंधों के साथ खेल सकते हैं और क्रमशः क्लाइंटसोर्स या सर्वरएड्रेस सेट कर सकते हैं, लेकिन केवल जिसके लिए आपको क्लाइंट या उपयोगकर्ता से कनेक्ट होने या मान्य होने की आवश्यकता होती है।
भूमिका-आधारित अभिगम नियंत्रण
डेटाबेस में भूमिका-आधारित अभिगम नियंत्रण (RBAC) उपयोगकर्ता को प्रबंधित करने का एक सुविधाजनक तरीका प्रदान करता है या उपयोगकर्ताओं की सूची या उपयोगकर्ताओं के समूह से जुड़े अपने निर्दिष्ट विशेषाधिकार वाले उपयोगकर्ता को समूहबद्ध करने का एक आसान तरीका प्रदान करता है।
हालांकि आपको इस बात का ध्यान रखना होगा कि किसी भी ओपन सोर्स डेटाबेस में भूमिकाओं को अलग तरह से हैंडल किया जाता है। उदाहरण के लिए, MySQL ने भूमिकाओं को निम्नलिखित के रूप में परिभाषित किया है,
MySQL भूमिका विशेषाधिकारों का एक नामित संग्रह है। उपयोगकर्ता खातों की तरह, भूमिकाओं को विशेषाधिकार दिए जा सकते हैं और उनसे निरस्त किए जा सकते हैं।
एक उपयोगकर्ता खाते को भूमिकाएं दी जा सकती हैं, जो खाते को प्रत्येक भूमिका से जुड़े विशेषाधिकार प्रदान करता है। यह खातों को विशेषाधिकारों के सेट के असाइनमेंट को सक्षम बनाता है और व्यक्तिगत विशेषाधिकार देने के लिए एक सुविधाजनक विकल्प प्रदान करता है, दोनों वांछित विशेषाधिकार असाइनमेंट की अवधारणा और उन्हें लागू करने के लिए।
MongoDB RBAC के साथ भूमिका को परिभाषित करता है,
MongoDB एक MongoDB सिस्टम तक पहुंच को नियंत्रित करने के लिए रोल-बेस्ड एक्सेस कंट्रोल (RBAC) का उपयोग करता है। एक उपयोगकर्ता को एक या अधिक भूमिकाएँ दी जाती हैं जो डेटाबेस संसाधनों और संचालन के लिए उपयोगकर्ता की पहुँच को निर्धारित करती हैं। भूमिका असाइनमेंट के बाहर, उपयोगकर्ता के पास सिस्टम तक पहुंच नहीं है।
जबकि PostgreSQL में,
PostgreSQL भूमिकाओं की अवधारणा का उपयोग करके डेटाबेस एक्सेस अनुमतियों का प्रबंधन करता है। भूमिका को कैसे सेट किया जाता है, इस पर निर्भर करते हुए एक भूमिका को डेटाबेस उपयोगकर्ता या डेटाबेस उपयोगकर्ताओं के समूह के रूप में माना जा सकता है। भूमिकाएँ डेटाबेस ऑब्जेक्ट्स (उदाहरण के लिए, टेबल और फ़ंक्शंस) की मालिक हो सकती हैं और उन ऑब्जेक्ट्स पर अन्य भूमिकाओं को विशेषाधिकार प्रदान कर सकती हैं ताकि यह नियंत्रित किया जा सके कि किसके पास ऑब्जेक्ट्स तक पहुंच है। इसके अलावा, किसी अन्य भूमिका की भूमिका में सदस्यता देना संभव है, इस प्रकार सदस्य भूमिका को किसी अन्य भूमिका को सौंपे गए विशेषाधिकारों का उपयोग करने की अनुमति मिलती है।
भूमिकाओं की अवधारणा "उपयोगकर्ताओं" और "समूहों" की अवधारणाओं को समाहित करती है। 8.1 से पहले पोस्टग्रेएसक्यूएल संस्करणों में, उपयोगकर्ता और समूह अलग-अलग प्रकार की संस्थाएं थे, लेकिन अब केवल भूमिकाएं हैं। कोई भी भूमिका उपयोगकर्ता, समूह या दोनों के रूप में कार्य कर सकती है।
यद्यपि ये डेटाबेस अपने उपयोग के लिए विशिष्ट भूमिकाओं को लागू करते हैं, वे उपयोगकर्ता को आसानी से विशेषाधिकार प्रदान करने के लिए भूमिकाएँ सौंपने की अवधारणा साझा करते हैं। भूमिकाओं का उपयोग करने से डेटाबेस व्यवस्थापकों को आवश्यक उपयोगकर्ताओं को लॉग इन करने या डेटाबेस तक पहुँचने के लिए प्रबंधित करने की अनुमति मिलती है।
कल्पना करें कि क्या आपके पास उन उपयोगकर्ताओं की सूची है जिन्हें आपको प्रबंधित करना है या उन उपयोगकर्ताओं की सूची है जिन्हें अब आवश्यकता न होने पर छोड़ा या निरस्त किया जा सकता है। कुछ विशिष्ट मामलों में, यदि किसी निश्चित कार्य के लिए कार्य की आवश्यकता होती है, तो डेटाबेस व्यवस्थापक पहले से मौजूद भूमिकाओं वाले उपयोगकर्ता बना सकते हैं। बनाए गए इन प्रयोक्ताओं को केवल एक छोटी अवधि के लिए एक विशिष्ट भूमिका सौंपी जा सकती है, फिर आवश्यकता न होने पर निरस्त कर दी जाती है।
ऑडिट उन उपयोगकर्ताओं को अलग करने में भी मदद करता है जिन्हें कमजोरियों या डेटा जोखिम का संदेह है, इसलिए उस स्थिति में, यह उपयोगकर्ताओं को भूमिकाओं के साथ बहुत आसानी से प्रबंधित करने में मदद करता है।
उपयोगकर्ता प्रबंधन प्रणाली
यदि आपकी डेटा सुरक्षा को उचित रूप से संभाला और कार्यान्वित किया जाता है, तो यह आपके लिए सफलता का मार्ग प्रशस्त करता है। हालांकि कोई सही समाधान नहीं है क्योंकि कमजोरियां और घुसपैठ हमेशा विकसित होती है। यह एक कीड़ा की तरह है क्योंकि यह हर समय दुबकने की कोशिश करता है जब तक कि यह आपकी सुरक्षा को भंग करने और आपके डेटा तक पहुंच प्राप्त करने के अपने लक्ष्य तक पहुंचने में सक्षम न हो जाए। किसी भी असुरक्षा और कमजोरियों के लिए चेतावनी प्रणाली या सलाह जैसे उचित उपकरणों के बिना, आपके डेटा की सुरक्षा करना मुश्किल होगा।
ClusterControl आपको अपने उपयोगकर्ताओं को प्रबंधित करने और मुख्य डेटाबेस उपयोगकर्ताओं के लिए लोड बैलेंसर से आपके उपयोगकर्ता के विशेषाधिकारों को सत्यापित या जांचने में मदद करता है। यह सलाहकार और अलर्ट भी प्रदान करता है ताकि यह आपको संभावित कमजोरियों या घुसपैठ के बारे में सूचित करे।
उदाहरण के लिए, प्रॉक्सीएसक्यूएल के साथ एक MySQL/MariaDB का उपयोग करके उपयोगकर्ताओं को आयात करना और जोड़ना। उपयोगकर्ताओं को आयात करने के लिए, यह उन उपयोगकर्ताओं की सूची एकत्र करता है जो आपके वर्तमान MySQL/MariaDB क्लस्टर में मौजूद हैं और आपको इसके वर्तमान विशेषाधिकारों की समीक्षा करने की पेशकश करते हैं। नीचे देखें,
इसके अलावा, इस उदाहरण में, एक प्रॉक्सीएसक्यूएल उपयोगकर्ता को जल्दी से निष्क्रिय किया जा सकता है यदि ऐसी भेद्यता विशिष्ट उपयोगकर्ता के लिए जाना जाता है।
ClusterControl आपको अपने डेटाबेस जैसे MySQL/MariaDB या PostgreSQL के लिए सीधे उपयोगकर्ताओं को प्रबंधित करने की भी पेशकश करता है। MySQL/MariaDB के लिए, आप <अपने क्लस्टर का चयन करें> → प्रबंधित करें → स्कीमा और उपयोगकर्ता पर जा सकते हैं।
PostgreSQL के लिए, <अपना क्लस्टर चुनें> → प्रबंधित करें → उपयोगकर्ता प्रबंधन।
ClusterControl के साथ, आप सलाहकारों का उपयोग करके अपने अलर्ट को कस्टमाइज़ कर सकते हैं। सलाहकार स्क्रिप्ट-आधारित इकाइयाँ हैं जो परिवर्तनीय हैं। उदाहरण के लिए, यह एक MySQL/MariaDB क्लस्टर में है जैसा कि नीचे दिखाया गया है, जिसे <अपने क्लस्टर का चयन करें> → प्रदर्शन → सलाहकार:
के माध्यम से एक्सेस किया जा सकता है। 
संपादित करें बटन पर क्लिक करके, आप अनुकूलित कर सकते हैं कि क्लस्टरकंट्रोल कैसे प्रतिक्रिया करेगा यदि यह किसी भी होस्ट या '%' या पासवर्ड के बिना उपयोगकर्ता के साथ उपयोगकर्ताओं को ढूंढता है। देखें कि एक बार जब आप हिट करते हैं तो स्क्रिप्ट कैसे दिखाई जाती है संपादित करें बटन।
एक बार जब ClusterControl को पता चलता है कि इनमें से किसी भी सलाहकार को ट्रिगर किया गया है, तो एक अलर्ट प्रदर्शित किया जाएगा और आपके द्वारा सेटअप किए गए ईमेल पर भी भेजा जाएगा या यदि कोई तृतीय-पक्ष सूचनाएं एकीकृत हैं, तो इसे अधिसूचित किया जाएगा। वहाँ भी।
निष्कर्ष
डेटाबेस एक्सेस विशेषाधिकार डेटा उल्लंघनों और घुसपैठ के लिए चिंता के प्रमुख लक्ष्यों में से एक है। यदि आपका डेटाबेस उपयोगकर्ता उजागर हो गया है या यदि वर्तमान डेटाबेस संस्करण के लिए एक बड़ा खतरा था जिसे पैच नहीं किया गया था, हैक होने की संभावना या रैंसमवेयर और चोरी का लक्ष्य बहुत अधिक है। एक्सेस विशेषाधिकारों को समझना और सही सीमाएं निर्धारित करने से आपको अपने मूल्यवान डेटा को उजागर करने के खतरों को कम करने में मदद मिलती है।
