विशिष्ट उपयोगकर्ताओं को अनुदान देने के लिए उचित विशेषाधिकार क्या हैं? [बन्द है]

Question

मुझे लगता है कि MySQL द्वारा प्रदान किए गए विशेषाधिकारों की सूची थोड़ी भारी है। मुझे यकीन नहीं है कि किसके पास क्या विशेषाधिकार होने चाहिए। मेरे दिमाग में मेरी स्थिति के लिए तीन विशिष्ट उपयोगकर्ता हैं:

1. root
2. developer
3. application

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

SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, FILE, REFERENCES, INDEX, ALTER, SHOW DATABASES, CREATE TEMPORARY TABLES, LOCK TABLES, EXECUTE, CREATE VIEW, SHOW VIEW, CREATE ROUTINE, ALTER ROUTINE, EVENT, TRIGGER ON

applicationएक और भी अधिक सीमित सेट है। यह केवल एक विशिष्ट डेटाबेस में हेरफेर करने के लिए सीमित होना चाहिए।

मुझे यकीन नहीं है कि विशेषाधिकार का एक उचित सेट क्या अनुदान देना है। एक डेवलपर और एक आवेदन देने के लिए विशेषाधिकारों का एक उचित सेट क्या है और क्यों?

Comments

बता दें, इस उदाहरण के लिए, कि सभी एप्लिकेशन वर्डप्रेस परिनियोजन हैं। मुझे पता है कि आप स्वयं वर्डप्रेस से DB को प्रशासित कर सकते हैं, लेकिन कभी-कभी सर्वर पर ही कूदने की आवश्यकता होती है। डेवलपर को डेटाबेस से डेटाबेस में आसानी से स्विच करने में सक्षम होना चाहिए ...

— Avery

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

— एवरी

Answer 1

एक विशिष्ट उपयोगकर्ता के पास होना चाहिए:

SELECT, INSERT, DELETE, UPDATE, CREATE TEMPORARY TABLES, EXECUTE

पहले चार बहुत स्पष्ट हैं - हालांकि आप "केवल पढ़ने वाले" उपयोगकर्ताओं को ही सेट कर सकते हैं SELECT।

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

EXECUTEआपके सिस्टम के प्रकार पर निर्भर करता है। क्या आपके पास रूटीन है? क्या आप अपने उपयोगकर्ताओं को उन्हें एक्सेस करना चाहेंगे? सुनिश्चित करें कि आप SECURITY=DEFINER/INVOKERसंग्रहीत दिनचर्या के लिए परिभाषा के बारे में भी जानते हैं।

किसी भी स्थिति में, विशिष्ट स्कीमा पर उपरोक्त सभी लागू करना सुनिश्चित करें । उपयोग करने से बचें :

GRANT SELECT, INSERT, UPDATE, DELETE ON *.* TO 'some_user'@'some_host';

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

GRANT SELECT, INSERT, UPDATE, DELETE ON some_schema.* TO 'some_user'@'some_host';
GRANT SELECT, INSERT, UPDATE, DELETE ON another_schema.* TO 'some_user'@'some_host';

Comments

MariaDB में, इसके बजाय CREATE TEMPORARY TABLES का उपयोग करें। डेटाबेस विशेषाधिकार अनुभाग यहां देखें : mariadb.com/kb/en/mariadb/grant

— adolfoabegg

Answer 2

किसी भी वास्तविक पैमाने पर प्रणाली में (अर्थात एक व्यक्तिगत परियोजना नहीं) उन उपयोगकर्ता प्रकार पर्यावरण के अनुसार अलग-अलग होंगे इसलिए यह बहुत सरल नहीं है।

सभी वातावरणों में एप्लिकेशन के पास यह होना चाहिए और अधिक नहीं होना चाहिए (आमतौर पर यह "सभी तालिकाओं पर चयन करें / डालें / अपडेट करें" और "सभी प्रक्रियाओं पर अमल करें" है। बड़े सिस्टम के लिए जहां आपके पास अलग-अलग कार्यों के लिए अलग-अलग एप्लिकेशन उपयोगकर्ता हो सकते हैं (के लिए) उदाहरण के लिए एक एप्लिकेशन सेंसर डेटा में फीड करने के लिए और दूसरा रिपोर्ट तैयार करने के लिए जिम्मेदार है) आपको उनके विशेषाधिकारों को अलग करना चाहिए ताकि उनके पास कम से कम उनकी जरूरत हो (रिपोर्टिंग उपयोगकर्ता को अधिकारों की आवश्यकता नहीं है और राइट करें)। सुनिश्चित करें कि आप इसे अपने परीक्षण में दोहराते हैं। अगर आपके पास वातावरण है: मैंने देखा है कि जब टेस्ट में काम किया गया था तो पदोन्नत होने पर कोड गिर गया क्योंकि परीक्षण के माहौल में सब कुछ DB sa(MSSQL के बराबर root) के रूप में पहुंच रहा था ।आदर्श रूप से एक एप्लिकेशन उपयोगकर्ता के पास आमतौर पर कोई विशेषाधिकार नहीं होना चाहिए जो इसे आपके स्कीमा को बदलने की अनुमति देता है (CREATE, DROP...) - इसके अपवाद हैं लेकिन वे कुछ और दूर के बीच हैं।

rootहै, ठीक है root,। उत्पादन में यह केवल आपका डीबीए है और इसका उपयोग शायद ही कभी किया जाना चाहिए - सिर्फ सिस्टम मेंटेनेंस (डीबी डिजाइन को आगे बढ़ाना) और निगरानी के लिए। एक बड़ी प्रणाली के लिए, विशेष रूप से विनियमित वातावरण में जहां आपको जवाबदेही उद्देश्यों के लिए व्यक्तियों का घनिष्ठ नियंत्रण बनाए रखना चाहिए, आप एक भी rootउपयोगकर्ता को अनुमति नहीं दे सकते हैं और विशेषाधिकारों को छोटे रोल में अलग करने की कोशिश कर सकते हैं (मुझे यकीन नहीं है कि आप कितनी दूर जा सकते हैं mysql में इसके साथ, लेकिन आप MSSQL, Oracle और इसके बाद के संस्करण में काफी बारीक हो सकते हैं)।

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

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