एस क्यू एल मध्ये वापरकर्ते आणि भूमिकांसाठी प्रवेश नियंत्रणे

अनधिकृत परदेशी आणि त्यांच्या अधिकारांपेक्षा अधिक करण्याचा प्रयत्न करणार्या अंतर्दृश्यांकडून महत्वाच्या व्यवसाय डेटाचे त्यांचे गीगाबाईट्स संरक्षित करण्यासाठी डाटाबेस प्रशासकांना सुरक्षा आवश्यक असते. सर्व रिलेशनल डाटाबेस मॅनेजमेंट सिस्टम काही धोकादायक सुरक्षा यंत्रणा पुरवतात जे या धमक्या कमीत कमी करण्यासाठी डिझाइन केले जातात. ते मायक्रोसॉफ्ट अॅक्सेसद्वारे देऊ केलेल्या सोप्या पासवर्ड संरक्षण / ऑरेकल आणि मायक्रोसॉफ्ट एस क्यू एल सर्व्हर सारख्या प्रगत रिलेशनल डाटाबेसद्वारे समर्थित जटिल वापरकर्ता / भूमिकाच्या संरचनेतील श्रेणी आहेत. हे लेख स्ट्रक्चर्ड क्वेरी लॅंग्वेज (किंवा एस क्यू एल ) लागू करणाऱ्या सर्व डाटाबेसमध्ये असलेल्या सुरक्षा यंत्रणा वर केंद्रित आहे. एकत्रितपणे, आम्ही डेटा ऍक्सेस नियंत्रणे मजबूत करण्याच्या प्रक्रियेतून चालतो आणि आपल्या डेटाची सुरक्षितता सुनिश्चित करू.

वापरकर्ते

सर्व्हर-आधारित डेटाबेस सर्व संगणक ऑपरेटिंग सिस्टममध्ये वापरल्याप्रमाणेच एक वापरकर्ता संकल्पना समर्थन देतात. जर आपण Microsoft Windows NT आणि Windows 2000 मध्ये आढळलेले वापरकर्ता / गट पदानुक्रम परिचित असाल तर आपल्याला आढळेल की SQL सर्व्हर आणि Oracle द्वारे समर्थित वापरकर्ता / भूमिका गट खूप समान आहेत.

हे अत्यंत शिफारसीय आहे की आपण आपल्या डेटाबेसमध्ये प्रवेश करणार्या प्रत्येक व्यक्तीसाठी व्यक्तिगत डेटाबेस वापरकर्ता खाती तयार करा. वापरकर्त्यांमधे खाती शेअर करणे किंवा आपल्या डेटाबेसमध्ये प्रवेश करण्याची आवश्यकता असलेल्या प्रत्येक प्रकारच्या युजरसाठी फक्त एक वापरकर्ता खाते वापरणे तांत्रिकदृष्ट्या शक्य आहे, परंतु या कारणास्तव मी दोन कारणांमुळे कठोरपणे परावृत्त करतो. प्रथम, ते वैयक्तिक जबाबदारी दूर करेल - जर वापरकर्ता आपल्या डेटाबेसमध्ये बदल घडविला तर (आपण स्वत: 5,000 डॉलर्स वाढवून असे म्हणू), आपण ऑडिट लॉगच्या वापराद्वारे विशिष्ट व्यक्तीला तो परत शोधण्यास सक्षम राहणार नाही. शिवाय, जर विशिष्ट वापरकर्त्याने आपली संस्था सोडून दिली आणि आपण डेटाबेसवरून त्याचा प्रवेश काढू इच्छित असाल तर आपल्याला वापरकर्त्याचे पासवर्ड बदलण्याची सक्ती केली जाईल जे सर्व वापरकर्त्यांवर अवलंबून आहे

वापरकर्ता खाती तयार करण्यासाठीच्या पद्धती प्लॅटफॉर्मपासून प्लॅटफॉर्म पर्यंत बदलतात आणि आपल्याला योग्य पद्धतींसाठी आपल्या DBMS- विशिष्ट दस्तऐवजीकरणाचा सल्ला घ्यावा लागेल. Microsoft SQL सर्व्हर वापरकर्त्यांनी sp_adduser संग्रहित प्रक्रियेच्या वापराचे अन्वेषण केले पाहिजे. Oracle डेटाबेस प्रशासक CREATE USER कमांडला उपयुक्त दिसेल. आपण वैकल्पिक प्रमाणीकरण योजनांचा तपास करू शकता उदाहरणार्थ, मायक्रोसॉफ्ट एस क्यू एल सर्व्हर विंडोज एनटी इंटिग्रेटेड सिक्युरिटीच्या वापरास समर्थन देते. या योजनेअंतर्गत, वापरकर्ते त्यांच्या Windows NT वापरकर्ता खात्यांद्वारे डेटाबेसला ओळखले जातात आणि डेटाबेस वापरण्यासाठी अतिरिक्त वापरकर्ता आयडी आणि पासवर्ड प्रविष्ट करणे आवश्यक नाही. ही पद्धत डेटाबेस प्रशासकांदरम्यान अत्यंत लोकप्रिय आहे कारण हे खाते व्यवस्थापनाचे ओझे नेटवर्क प्रशासकीय कर्मचा-यांमधे बदलते आणि अंतिम वापरकर्त्यास सिंगल साइन-ऑनची सोय देते.

भूमिका

जर तुम्ही छोट्या वापरकर्त्यांसह वातावरणात असाल, तर आपणास असे वाटेल की वापरकर्ता खाती तयार करणे आणि त्यांना थेट परवानगी देणे आपल्या गरजा पूर्ण आहे. तथापि, आपल्याकडे मोठ्या संख्येत वापरकर्ते असल्यास, आपण खाती आणि योग्य परवानग्या ठेवण्याचे ओझे आपल्याला सर्वात जास्त अभिमानित केले जाईल. हे ओझे कमी करण्यासाठी, रिलेशनल डेटेबेसमुळे भूमिका स्पष्ट होते. डेटाबेसची भूमिका विंडोज एनटी समूहाप्रमाणे कार्य करते. वापरकर्ता खाती भूमिका (नों) असा नियुक्त केली जातात आणि परवानग्या नंतर वैयक्तिक वापरकर्ता खात्यापेक्षा पूर्ण भूमिका नियुक्त केली जातात. उदाहरणार्थ, आम्ही डीबीएची भूमिका तयार करू शकलो आणि नंतर या भूमिकेसाठी आमच्या प्रशासकीय कर्मचाऱ्याच्या उपयोगकर्ता खाती जोडा. एकदा आम्ही हे पूर्ण केल्यावर, आम्ही भूमिकाची परवानगी सोपवून फक्त सर्व वर्तमान (आणि भविष्य) प्रशासकांना विशिष्ट परवानगी नियुक्त करू शकतो. पुन्हा एकदा, भूमिका तयार करण्यासाठी कार्यपद्धती व्यासपीठ ते प्लॅटफॉर्ममध्ये बदलते. महेंद्रसिंग एस क्यू एल सर्व्हर प्रशासकांनी sp_addrol संग्रहीत कार्यपद्धतीची तपासणी केली पाहिजे परंतु ओरेकल डीबीएने रोर सिंटेक्स बनवायला पाहिजे.

परवानग्या मंजूर करणे

आता आम्ही वापरकर्त्यांना आमच्या डेटाबेसमध्ये जोडलेले आहे, परवानग्या जोडून सुरक्षा बळकट करण्याची वेळ आहे आमचे प्रथम चरण आमच्या वापरकर्त्यांसाठी योग्य डेटाबेस परवानग्या मंजूर करणे असेल. एसक्यूएल पीआरसीआर स्टेटमेंटच्या वापराद्वारे आम्ही हे पूर्ण करू.

येथे विधान च्या वाक्यरचना आहे:

GRANT <परवानग्या>
[ऑन <टेबल>]
ते <वापरकर्ता / भूमिका>
[GRANT OPTION सह]

आता, हे स्टेटमेंट लाइन-बाय-लाइन पहा. प्रथम ओळ, GRANT <परवानग्या>, आम्हाला अनुमती असलेल्या विशिष्ट सारणी परवानग्या निर्दिष्ट करण्यास अनुमती देते. हे सारणी-स्तरीय परवानग्या (जसे की SELECT, INSERT, UPDATE आणि DELETE) किंवा डेटाबेस परवानग्या (जसे की सारणी, बदल डेटा आणि GRANT) असू शकतात. एकाहून अधिक परवानग्या एकल GRANT विधानात मंजूर केल्या जाऊ शकतात परंतु सारणी-स्तरीय परवानग्या आणि डेटाबेस-स्तरीय परवानग्या एका वक्तव्यात एकत्रित केल्या जाऊ शकत नाहीत.

दुसरी ओळ, ON

, टेबल-स्तरीय परवानग्यांसाठी प्रभावित टेबल निर्दिष्ट करण्यासाठी वापरली जाते. आम्ही डेटाबेस-स्तरीय परवानग्या मंजूर करत असल्यास ही ओळ वगळली आहे. तिसरे ओळ वापरकर्ता किंवा भूमिका निर्देशीत करते ज्यास परवानग्या दिले जात आहेत.

अखेरीस, अनुदान पर्याय सह चौथ्या ओळी, वैकल्पिक आहे. जर ही ओळ विधानामध्ये समाविष्ट केली असेल, तर प्रभावित झालेल्या वापरकर्त्यांनाही समान परवानग्या अन्य वापरकर्त्यांना मंजूर करण्याची परवानगी आहे. लक्षात घ्या की जेव्हा कृती एक भूमिकेसाठी नियुक्त केल्या जातात तेव्हा GRANT OPTION सह निर्दिष्ट करणे शक्य नाही.

उदाहरणे

चला काही उदाहरण बघूया. आमच्या पहिल्या परिस्थितीमध्ये, आम्ही नुकतेच 42 डेटा एंट्री ऑपरेटरच्या गटाला भाड्याने घेतले आहे जे ग्राहकांच्या नोंदी जोडत आणि ठेवेल. त्यांना ग्राहकांच्या टेबलमध्ये माहिती ऍक्सेस करण्यास, ही माहिती सुधारण्यासाठी आणि टेबलमध्ये नवीन रेकॉर्ड जोडण्यास सक्षम असणे आवश्यक आहे. ते संपूर्णपणे डेटाबेसमधून रेकॉर्ड हटवू शकणार नाहीत. प्रथम, आम्ही प्रत्येक ऑपरेटरसाठी वापरकर्ता खाती तयार केली पाहिजे आणि नंतर त्यांना नवीन भूमिका, डेटा एन्टर्रीला जोडावे. पुढील, त्यांना योग्य परवानग्या देण्यासाठी खालील एस क्यू एल स्टेटमेंटचा उपयोग करावा:

निवडा निवडा, घाला, अद्ययावत करा
ग्राहकांकडे
डेटाएन्ट्रीकडे

आणि त्या सर्व तेथे आहे! आता आपण जिथे डेटाबेस-स्तरीय परवानग्या नियुक्त करीत आहोत त्या प्रकरणाचे परीक्षण करूया. आम्ही आमच्या डेटाबेसमध्ये नवीन सारण्या जोडण्यासाठी DBA च्या सदस्यांच्या सदस्यांना परवानगी देऊ इच्छितो याव्यतिरिक्त, आम्ही अशी अपेक्षा करू इच्छितो की इतर वापरकर्त्यांना तसे करण्यास अनुमती दिली जाईल. येथे एस क्यू एल स्टेटमेंट आहे:

टेबल तयार करा
डीबीए पर्यंत
GRANT OPTION सह

लक्षात घ्या की आमचे डीबीए इतर वापरकर्त्यांना ही परवानगी नियुक्त करू शकतील याची खात्री करण्यासाठी आम्ही GRANT OPTION रेषासह समाविष्ट केले आहे.

परवानग्या काढत आहेत

एकदा आम्ही परवानग्या मंजूर केल्या केल्यावर, हे नंतरच्या तारखेस त्यांना मागे घेण्याची आवश्यकता असल्याचे दर्शविते. सुदैवाने, एस क्यू एल आम्हाला पूर्वी मंजूर परवानगी काढण्यासाठी REVOKE आदेश प्रदान करते. येथे वाक्यरचना आहे:

REVOKE [परवानग्याबद्दल GRANT OPTION] <परवानग्या>
चालू <टेबल> वर
<वापरकर्ता / भूमिका> कडून

आपल्याला दिसेल की या कमांडचा सिन्टॅक्स GRANT कमांड प्रमाणेच आहे. फक्त फरक असा आहे की GRANT OPTION सह आदेश आदेशाच्या शेवटी पेक्षा REVOKE आदेश पंक्तीवर निर्दिष्ट केले आहे. उदाहरण म्हणून, आपण कल्पना करूया की आम्ही ग्राहकांच्या डेटाबेसच्या नोंदी काढण्यासाठी मरीयाची पूर्वी मंजूर परवानगी मागे घेऊ इच्छितो. आम्ही खालील आदेश वापरु इच्छित:

REVOKE DELETE
ग्राहकांकडे
मरीया कडून

आणि त्या सर्व तेथे आहे! मायक्रोसॉफ्ट एस क्यू एल सर्व्हर द्वारे समर्थीत एक अतिरिक्त यंत्रणा आहे जे डीएनआय कमांड नावाचे आहे या आदेशचा वापर वापरकर्त्याला स्पष्टपणे नाकारण्याची परवानगी देण्यासाठी होऊ शकतो जो कदाचित अन्यथा कदाचित वर्तमान किंवा भविष्यातील रोल सदस्यांच्या माध्यमातून असेल. येथे वाक्यरचना आहे:

डेनिस <परवानग्या>
चालू <टेबल> वर
प्रति <वापरकर्ता / भूमिका

उदाहरणे

आमच्या मागील उदाहरणावर परत ये, आपण कल्पना करूया की मेरी देखील व्यवस्थापक भूमिका असणाऱया ग्राहकांच्या टेबलवरही प्रवेश करु शकत होती. मागील REVOKE विधान टेबलमध्ये तिला प्रवेश नाकारण्याचे पुरेसे असू शकत नाही. हे त्याच्या वापरकर्त्याच्या खात्यावर लक्ष्यित GRANT विधानाद्वारे तिच्यावर दिलेल्या परवानगीस काढेल, परंतु व्यवस्थापकाच्या भूमिकेत तिच्या सदस्यतेद्वारे मिळालेल्या परवानग्यावर त्याचा काहीही परिणाम होणार नाही. तथापि, आम्ही DENY विधान वापरल्यास तो परवानगीच्या तिच्या वारसांना अवरोधित करेल. येथे आज्ञा आहे:

डेनी हटवा
ग्राहकांकडे
मरीया

DENY आदेश डेटाबेस एक्सेस नियंत्रणात मूलत: "नकारात्मक परवानगी" तयार करतो. जर आम्ही नंतर ग्राहकांना टेबलवरून पंक्ती काढून टाकण्याची मरीय परवानगी देण्याचा निर्णय घेतला तर आपण फक्त GRANT कमांडचा वापर करू शकणार नाही. विद्यमान डेनीद्वारे त्या आदेशाचा तात्काळ अधिलिखित केला जाईल. त्याऐवजी, आम्ही खालील नकारात्मक परवानगी नोंद काढून टाकण्यासाठी REVOKE कमांड वापरणार आहोत:

REVOKE DELETE
ग्राहकांकडे
मरीया कडून

आपल्याला लक्षात येईल की हा आदेश नक्कीच एक सकारात्मक परवानगी काढण्यासाठी वापरल्याप्रमाणेच आहे. लक्षात ठेवा डेन्वाई आणि ग्रॅन्ट दोन्ही आज्ञा सारख्याच फॅशनमध्ये काम करतात * mdash; ते दोन्ही डेटाबेस प्रवेश नियंत्रण यंत्रणेमध्ये (सकारात्मक किंवा नकारात्मक) परवानगी तयार करतात. REVOKE आदेश विशिष्ट वापरकर्त्यासाठी सर्व सकारात्मक आणि नकारात्मक परवानग्या काढून टाकतो. एकदा ही आज्ञा जारी झाली की, ती परवानगीच्या मालकीची भूमिका असणा-या सदस्य असल्यास ती टेबलमधून पंक्ती काढून टाकण्यास सक्षम असेल. वैकल्पिकरित्या, डीलीटी परवानगी थेट तिच्या खात्यावर प्रदान करण्यासाठी एक GRANT आज्ञा जारी केली जाऊ शकते.

या लेखाच्या संपूर्ण प्रक्रियेत, आपण मानक क्वेरी भाषेद्वारे समर्थित प्रवेश नियंत्रण पद्धतींबद्दल एक चांगले करार शिकला आहात. या परिचयाने आपल्याला एक चांगला प्रारंभ बिंदू दिला पाहिजे, परंतु मी तुम्हाला आपल्या डीबीएमएस दस्तऐवजीकरणाचा संदर्भ देण्यास प्रोत्साहित करतो जी आपल्या सिस्टमद्वारे समर्थित सुधारित सुरक्षा उपाय जाणून घेते. आपल्याला आढळेल की अनेक डेटाबेस अधिक प्रगत प्रवेश नियंत्रण पद्धती समर्थित करतात, जसे की विशिष्ट स्तंभांवर परवानग्या देणे.