संक्षिप्त उत्तर
आप नहीं कर सकते।
यदि पासवर्ड उस आर्टिफैक्ट में संग्रहीत है जिसे अंतिम उपयोगकर्ता को भेज दिया गया है तो आपको जरूरी इसे समझौता समझो! यहां तक कि अगर आर्टिफैक्ट एक संकलित बाइनरी है, तो पासवर्ड प्राप्त करने के लिए हमेशा (अधिक या कम जटिल) तरीके होते हैं।
अपने संसाधनों की सुरक्षा का एकमात्र तरीका अंतिम उपयोगकर्ता के लिए केवल एक सीमित एपीआई को उजागर करना है। या तो एक प्रोग्रामेटिक एपीआई (REST, WS+SOAP, RMI, JavaEE+Servlets, ...) बनाएं या केवल SPROCs (नीचे देखें) के माध्यम से अपने DB में कुछ कार्यात्मकताओं को उजागर करें।
पहले कुछ चीज़ें...
यहां सवाल यह नहीं होना चाहिए कि पासवर्ड कैसे छिपाया जाए, बल्कि डेटाबेस को सुरक्षित कैसे किया जाए। याद रखें कि पासवर्ड केवल अक्सर एक बहुत ही कमजोर सुरक्षा होती है और इसे डीबी की सुरक्षा का एकमात्र तंत्र नहीं माना जाना चाहिए। क्या आप एसएसएल का उपयोग कर रहे हैं? नहीं? ठीक है, तब भी अगर आप एप्लिकेशन कोड में पासवर्ड छिपाने का प्रबंधन करते हैं, इसे नेटवर्क पर अभी भी सूंघना आसान है!
आपके पास कई विकल्प हैं। सभी अलग-अलग डिग्री की सुरक्षा के साथ:
"आवेदन भूमिका"
एप्लिकेशन के लिए एक डेटाबेस-उपयोगकर्ता बनाएं। इस भूमिका के लिए प्राधिकरण लागू करें। एक बहुत ही सामान्य सेटअप केवल CRUD संचालन की अनुमति देना है।
पेशेवरों
- बहुत सेट अप करने में आसान
- रोकता है
DROPक्वेरीज़ (f.ex. SQL इंजेक्शन में?)
विपक्ष
- पासवर्ड देखने वाले प्रत्येक व्यक्ति के पास डेटाबेस के सभी डेटा तक पहुंच होती है। भले ही वह डेटा सामान्य रूप से एप्लिकेशन में छिपा हो।
- यदि पासवर्ड से छेड़छाड़ की गई है, तो उपयोगकर्ता
UPDATEचला सकता है औरDELETEमानदंड के बिना प्रश्न (यानी:पूरी तालिका को एक बार में हटाएं/अपडेट करें)।
परमाणु प्रमाणीकरण
प्रति एप्लिकेशन एक डेटाबेस उपयोगकर्ता बनाएं-/अंतिम उपयोगकर्ता। यह आपको प्रति-स्तंभ के आधार पर भी परमाणु पहुंच अधिकारों को परिभाषित करने की अनुमति देता है। उदाहरण के लिए:उपयोगकर्ता एक्स केवल टेबल फू से दूर और बाज़ कॉलम का चयन कर सकता है। बाकि और कुछ भी नही। लेकिन उपयोगकर्ता Y SELECT कर सकता है सब कुछ, लेकिन कोई अपडेट नहीं, जबकि उपयोगकर्ता Z के पास पूर्ण CRUD (चुनें, सम्मिलित करें, अपडेट करें, हटाएं) पहुंच है।
कुछ डेटाबेस आपको OS-स्तरीय क्रेडेंशियल्स का पुन:उपयोग करने की अनुमति देते हैं। यह उपयोगकर्ता के प्रमाणीकरण को पारदर्शी बनाता है (केवल वर्कस्टेशन में लॉग-इन करने की आवश्यकता होती है, उस पहचान को डीबी को अग्रेषित किया जाता है)। यह एक पूर्ण एमएस-स्टैक (ओएस =विंडोज, ऑथ =एक्टिव डायरेक्टरी, डीबी =एमएसएसक्यूएल) में सबसे आसान काम करता है, लेकिन जहां तक मुझे पता है - अन्य डीबी में भी हासिल करना संभव है।
पेशेवरों
- सेट अप करना काफी आसान है।
- बहुत ही परमाणु प्राधिकरण योजना
विपक्ष
- डीबी में सभी एक्सेस अधिकार सेट अप करने के लिए थकाऊ हो सकता है।
UPDATEवाले उपयोगकर्ता औरDELETEअधिकार अभी भी गलती से (या जानबूझकर?) बिना को हटा/अपडेट कर सकते हैं मानदंड। आप तालिका में सभी डेटा खोने का जोखिम उठाते हैं।
परमाणु प्रमाणीकरण के साथ संग्रहीत कार्यविधियाँ
लिखें नहीं आपके आवेदन में एसक्यूएल प्रश्न। सब कुछ चलाएं एसपीआरओसी के माध्यम से। फिर प्रत्येक उपयोगकर्ता के लिए डीबी-खाते बनाएं और एसपीआरओसी को विशेषाधिकार प्रदान करें केवल ।
पेशेवरों
- सबसे प्रभावी सुरक्षा तंत्र।
- SPROCs उपयोगकर्ताओं को प्रत्येक क्वेरी के लिए मानदंड पारित करने के लिए बाध्य कर सकते हैं (
DELETE. सहित) औरUPDATE)
विपक्ष
- सुनिश्चित नहीं है कि यह MySQL के साथ काम करता है (उस क्षेत्र में मेरा ज्ञान परतदार है)।
- जटिल विकास चक्र:आप जो कुछ भी करना चाहते हैं, उसे पहले एक एसपीआरओसी में परिभाषित किया जाना चाहिए।
अंतिम विचार
आपको कभी भी डेटाबेस व्यवस्थापकीय कार्यों को एप्लिकेशन में अनुमति नहीं देनी चाहिए। अधिकांश समय, किसी एप्लिकेशन को केवल एक ही ऑपरेशन की आवश्यकता होती है SELECT , INSERT , DELETE और UPDATE . यदि आप इस दिशानिर्देश का पालन करते हैं, तो पासवर्ड की खोज करने वाले उपयोगकर्ताओं द्वारा शायद ही कोई जोखिम शामिल हो। ऊपर बताए गए बिंदुओं को छोड़कर।
किसी भी मामले में, बैकअप रखें। मुझे लगता है कि आप आकस्मिक विलोपन या अपडेट के खिलाफ डेटाबेस को प्रोजेक्ट करना चाहते हैं। लेकिन दुर्घटनाएं होती हैं... ध्यान रखें;)
