यूजर्स पासवर्ड आखिर क्यों स्टोर करते हैं?

10

मैं कभी-कभी ऐसे प्रश्न देखता हूं जो पूछ रहा है कि वेब एप्लिकेशन के लिए उपयोगकर्ता पासवर्ड कैसे सुरक्षित रखें (RDBMS का उपयोग करके, मैं फेसबुक या ट्विटर की बात नहीं कर रहा हूं)। सामान्य उत्तर "नमक को पासवर्ड है, फिर इसे एक मजबूत एल्गोरिथम जैसे कि TDES या SHA512" के साथ हैश करें।

मेरा प्रश्न है: एक RDBMS उपयोगकर्ता के रूप में, मुझे पासवर्ड को समस्याग्रस्त करने के लिए बिल्कुल परेशान क्यों होना चाहिए क्योंकि अधिकांश इंजन में अंतर्निहित प्रमाणीकरण तंत्र होता है।

उदाहरण के लिए, यदि कुछ उपयोगकर्ता X मेरे वेब एप्लिकेशन पर खाता उपयोगकर्ता पासवर्ड Y बनाना चाहते हैं, तो निम्न क्वेरी को गलत कैसे जारी कर रहा है:

CREATE USER X WITH ENCRYPTED PASSWORD Y IN GROUP baseuser;

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

मुझे इस विधि के कई फायदे दिखाई देते हैं:

अगर RDBMS यह निर्णय लेता है कि एन्क्रिप्शन एल्गोरिथ्म को बदलने की आवश्यकता है, तो मुझे सुरक्षा अद्यतन लागू करने के लिए कुछ भी छूने की आवश्यकता नहीं है;
उपयोगकर्ता प्राधिकरणों को प्रबंधित करना मेरे लिए आसान है। यदि किसी उपयोगकर्ता को व्यवस्थापक की भूमिका में पदोन्नत किया जाता है, तो मुझे उपयोगकर्ता को संबंधित समूह में जोड़ना होगा;
SQL इंजेक्शन अब व्यर्थ हैं, क्योंकि मैं डेटाबेस में प्रत्येक उपयोगकर्ता को अनुमति देने के लिए अनुमति देने का प्रबंधन करता हूं (उदाहरण के लिए, SO जैसे फ़ोरम में, नए पोस्ट जोड़ना, पोस्ट का उत्तर देना, टिप्पणी करना और संपादन करना / अपने प्रश्न हटाना / उत्तर / टिप्पणियों);
एक उपयोगकर्ता खाता "अनाम" का उपयोग मेरे आवेदन के लिए अनधिकृत कनेक्शन के लिए किया जा सकता है;
प्रत्येक उपयोगकर्ता उसके द्वारा प्रदत्त डेटा का स्वामी होता है।

लेकिन वस्तुतः इस विषय पर मेरे द्वारा देखे गए प्रत्येक प्रश्न पर, एक आम सहमति प्रतीत होती है कि यह उस तरह से नहीं है जैसे चीजों को करना है। मेरा सवाल है: क्यों?

नोट: तीसरा बिंदु द्वारा अनुमति दी है नीतियों PostgreSQL में, और सुरक्षा नीतियों Microsoft SQL सर्वर में। मुझे एहसास है कि ये अवधारणाएं नए लोग हैं, लेकिन वैसे भी, अब जब वे यहां हैं, तो मैं जिस तकनीक का वर्णन करता हूं, वह खातों को संभालने का मानक तरीका क्यों नहीं है?

security users

— फेबियन पिज्के
स्रोत

2

टिप्पणियाँ विस्तारित चर्चा के लिए नहीं हैं; इस वार्तालाप को बातचीत में स्थानांतरित कर दिया गया है ।

— पॉल व्हाइट 9

संयोग से, सामान्य उत्तर गलत है। आपको पासवर्ड को नमक करना चाहिए, फिर इसे धीमी एल्गोरिथम जैसे bcrypt या argon2 के साथ हैश करें ।

— TGR

27

क्योंकि कई अनुप्रयोगों के लिए, वे अलग-अलग उपयोगकर्ता खातों को डेटाबेस से कनेक्ट नहीं करना चाहते हैं। उपयोगकर्ताओं / पासवर्ड / अधिकारों / अनुमतियों को सभी आवेदन परत पर संभाला जाता है, और एक एकल समर्पित सेवा खाते का उपयोग डेटाबेस बैक-एंड से कनेक्ट करने के लिए किया जाता है।

एक डीबीए के रूप में, मुझे डेटाबेस स्तर पर, कुछ मध्यम आकार के सार्वजनिक-सामना करने वाले वेब एप्लिकेशन के 10,000 सक्रिय उपयोगकर्ताओं, या शायद कुछ अचानक लोकप्रिय ऐप के 2+ मिलियन उपयोगकर्ताओं को प्रबंधित करने की आवश्यकता नहीं है।

एक बहुत ही वास्तविक अर्थ में, यह एप्लिकेशन डेवलपर्स और डेटाबेस डेवलपर्स / डीबीए के बीच दर्शन में अंतर है।

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

कुछ मामलों में, यह अदूरदर्शी हो सकता है; कई RDBMSes में कमाल की विशेषताएं हैं जो ऐप देव को बहुत आसान बना सकती हैं (पंक्ति-स्तरीय सुरक्षा, स्तंभ अनुक्रमणिका, फ़ाइलस्ट्रीम संग्रहण, आदि)।

लेकिन इनमें से कुछ कूलर सुविधाएँ केवल नए संस्करणों में उपलब्ध हैं, और संगठन हमेशा मौजूदा वातावरण को अपग्रेड करने के लिए त्वरित नहीं हैं ( 2014 से इस चार्ट को देखें )।

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

— BradC
स्रोत

2

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

— Nick.McDermaid

1

@ Nick.McDermaid मुझे यह सुनिश्चित करना पसंद है कि मैं डीबी और एप्लिकेशन के बीच व्यावसायिक तर्क को काफी मिलाता हूं, ताकि भविष्य के डेवलपर्स के लिए संभावित संभावनाओं को खत्म करने में मदद मिल सके, जो भी चल रहा है, वह मुझे अपनी नौकरी की सुरक्षा बनाए रखने में मदद करता है क्योंकि कोई भी पागल नहीं है। इसे प्रबंधित करना चाहते हैं।

— डेर कोमिसर

वहाँ एक वेब सेवा और एक टॉमकैट एप्लिकेशन सर्वर फेंको और आप आईबीएम के लिए काम कर सकते हैं

— Nick.McDarten

8

उस बिंदु पर विभाजन रेखा थोड़ी सी फूली जा रही है, लेकिन मैं उपयोगकर्ताओं और डेटाबेस स्तर पर उपयोगकर्ताओं और अनुमतियों पर विचार करूंगा कि स्कीमा का हिस्सा डेटा का हिस्सा न हो, और सामान्य अनुप्रयोगों में स्कीमा को संशोधित करने का कोई स्थान नहीं है (वहाँ हैं,) हमेशा की तरह, इस नियम के अपवाद)।

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

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

यदि डेटाबेस इंजनों के बीच पोर्टेबिलिटी एक लक्ष्य है (शायद आपका ऐप mysql और पोस्टग्रेज दोनों पर चलने में सक्षम होना चाहता है?) तो आपके अनुप्रयोगों को प्रत्येक इंजन के लिए उपयोगकर्ता / लॉगिन प्रबंधन कार्यों को सार करने की आवश्यकता होगी क्योंकि वे उन दोनों के बीच मानक नहीं हैं। - यदि आप उस प्रयास में जा रहे हैं, तो आप पासवर्ड को स्वयं लागू कर सकते हैं और उन प्रबंधन विकल्पों को प्राप्त कर सकते हैं जो आप सबसे सामान्य सामान्य सुविधा-इंजन ऑफ़र को स्वीकार करने के बजाय चाहते हैं।

— डेविड स्पिलेट
स्रोत

1

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

— फैबियन पिज्के

इस सेटिंग के साथ यदि कोई हैकर अनाम उपयोगकर्ता के रूप में डेटाबेस तक पहुँच प्राप्त करता है, तो वह जितने चाहे उतने उपयोगकर्ता बना सकेगा, लेकिन यह कोई सुरक्षा समस्या नहीं है, वह डेटाबेस में से किसी एक का उपयोग करके निश्चित रूप से ब्लोट कर सकता है बनाए गए खाते, जो कष्टप्रद होंगे, लेकिन फिर से कोई सुरक्षा मुद्दा नहीं होगा (और वह इसे मानक इंटरफ़ेस का उपयोग भी कर सकता है, वैसे भी यह धीमा हो सकता है: p)

— Fabian Pijcke

3

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

— a_horse_with_no_name

6

प्रश्न को बहाल करना

यूजर्स पासवर्ड आखिर क्यों स्टोर करते हैं?

सबसे सरल उत्तर यह है कि आपको ऐसा करना होगा। आप अभी भी पासवर्ड को अपनी वैकल्पिक विधि में संग्रहीत करते हैं। यह सिर्फ इतना है कि आप भंडारण को प्रबंधित करने के लिए डेटाबेस की अंतर्निहित प्रणाली का उपयोग करते हैं। तो आपका तरीका केवल आपके डेटाबेस के रूप में अच्छा है। जो अभी तक आप अन्यथा कर सकते हैं, उससे बेहतर हो सकता है, लेकिन यह भंडारण से परहेज नहीं है। यह वास्तव में सिर्फ कोडिंग स्टोरेज से बचना है।

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

लेकिन जो आप वास्तव में पूछ रहे हैं वह है

जब डेटाबेस पहले से ही है तो एप्लिकेशन स्तर प्रमाणीकरण योजना का उपयोग क्यों करें?

सुरक्षा

इस संभावना को अनदेखा करते हुए कि आप अधिक सुरक्षित संस्करण लिख सकते हैं, दूसरों ने कई कारण सुझाए हैं। मैं आमतौर पर सहमत हूँ। लेकिन एक और है जिसका अभी तक किसी ने उल्लेख नहीं किया है। आप अपने डेटाबेस की सुरक्षा से समझौता कर रहे हैं।

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

सुरक्षा प्याज की परतों में, सामान्य प्रणाली है:

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

इस प्रणाली में:

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

हमने सुरक्षा के संपूर्ण अनुप्रयोग स्तर को खो दिया है। और हमने स्वेच्छा से डेटाबेस लेयर का हिस्सा छोड़ दिया है। इसलिए हमें केवल दो कारनामे चाहिए:

एक अधिकृत सर्वर को स्पूफ या समझौता करना।
सीमित विशेषाधिकार खाते की पहुंच बढ़ाएं।

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

आप इन खातों का बहुत प्रबंधन करने जा रहे हैं। अगर आप गलती करते हैं तो क्या होगा? उपयोगकर्ता एक्स को केवल कुछ पंक्तियों तक सीमित करने के बजाय, आप उन्हें एक महत्वपूर्ण तालिका तक सभी पहुंच प्रदान करते हैं। इस तरह का सामान सामान्य रूप से मैन्युअल रूप से किया जाता है और उनमें से कुछ ही होते हैं, इसलिए उन्हें ऑडिट करना आसान होता है। लेकिन आपके सिस्टम में, आप हजारों या लाखों या अरबों उपयोगकर्ता खाते बना सकते हैं, जिनमें से प्रत्येक अपनी स्वयं की idiosyncratic पहुंच के साथ होता है।

उस मामले के लिए, डेटाबेस का सिस्टम लाखों या अरबों उपयोगकर्ताओं को स्केल करता है? यदि ऐसा होता है, तो नियमों की संख्या के बारे में क्या? यदि प्रत्येक उपयोगकर्ता एक सौ या अधिक नियम लेता है जो वे कर सकते हैं और उपयोग नहीं कर सकते हैं, तो क्या यह बिलियन उपयोगकर्ताओं तक होता है? आप सामान्य रूप से छोटे पैमाने पर प्रणाली ले रहे हैं और इसे बड़े पैमाने पर बना रहे हैं। यह जरूरी काम नहीं होगा। जैसे-जैसे आप बढ़ते हैं, आपको सिस्टम की सीमाएँ मिल सकती हैं।

— mdfst13
स्रोत

5

आप जो भी वर्णन करते हैं वह प्रमाणीकरण को नियंत्रित करेगा, लेकिन प्राधिकरण नहीं (उपयोगकर्ता किस डेटा तक पहुंच सकता है) या केवल उपयोग के मामले में सबसे सरल में।

Stackexechange के साथ अपने उदाहरण को जारी रखने के लिए: आप हटाए गए पोस्ट को केवल उच्च प्रतिनिधि उपयोगकर्ता को कैसे दिखाई देंगे? इसलिए एक्सेस नियमों के लिए, आपको कोड में तर्क की आवश्यकता होगी। डेटाबेस नियमों, और एप्लिकेशन एक्सेस नियमों के बीच एक्सेस लॉजिक को साझा करने के बजाय, अधिकांश डेवलपर एक ही स्थान पर उन सभी को पसंद करते हैं।

उपयोगकर्ता की जानकारी संग्रहीत करने के लिए आपको एक तालिका की भी आवश्यकता होगी: एक उपयोगकर्ता सिर्फ उपयोगकर्ता नाम + पासवर्ड नहीं है। उसके पास एक ईमेल, एक प्रतिष्ठा और इतने पर है। तो आपको अभी भी उपयोगकर्ता तालिका की आवश्यकता है, जिसे आपको सुनिश्चित करना है कि डेटाबेस उपयोगकर्ता तालिका के साथ सिंक है, बशर्ते आप इसे एक्सेस कर सकते हैं।

अपने समाधान के साथ, आप बस एक पासवर्ड कॉलम को छोड़ सकते हैं, जिसे भरना मुश्किल नहीं है: इसमें पासवर्ड / हैश पासवर्ड को संभालने के तरीके के बारे में अच्छे पुस्तकालय और प्रलेखन हैं।

एक अन्य बिंदु: आप एक कनेक्शन पूल कैसे बनाएंगे? मैं केवल jdbc (java <-> db) जानता हूं, और आपको कनेक्शन पाने के लिए एक उपयोगकर्ता नाम + पासवर्ड की आपूर्ति करने की आवश्यकता है, जिसे आप तब पूल कर सकते हैं।

मैंने कुछ अन्य बिंदुओं के बारे में सोचा जो स्थापित तरीके से लागू करने के लिए कठिन / अधिक जटिल होंगे:

पासवर्ड पुनर्प्राप्ति से निपटने
प्रारंभिक कार्यान्वयन के 2 साल बाद, आपका उत्पाद प्रबंधक आपसे ओउथ योजना के लिए समर्थन जोड़ने के लिए कहता है, या डबल फैक्टर ऑर्थर की अनुमति देता है

— थियरी
स्रोत

CREATE POLICY deleted_posts_high_rep ON posts FOR SELECT TO baseuser USING ((SELECT rep FROM users WHERE name = current_user()) > 10000)

आपके पहले प्रश्न का उत्तर कुछ इस तरह है। मैंने कभी नहीं कहा कि मुझे अब किसी उपयोगकर्ता तालिका की आवश्यकता नहीं है, और db उपयोगकर्ता तालिका के साथ सिंक सुनिश्चित करना कुछ मुश्किल है लेकिन संभव है। चर्चा की गई तकनीक का मुख्य बिंदु सुरक्षा है। कनेक्शन पूल के लिए के रूप में, मैं OCaml के साथ काम करता हूं और मुझे कहना होगा कि मुझे नहीं मिलता है कि मुझे कनेक्शन के पूल की आवश्यकता क्यों होगी। मैं वर्तमान में 0-एरी फ़ंक्शंस के कनेक्शन वापस करने के लिए कुकी मानों को जोड़ने वाले हैश मैप का उपयोग करता हूं :-)

— फेबियन पीजेक

5

कनेक्शन पूल प्रदर्शन को बढ़ाने के लिए कार्यान्वित किया जाता है: उनके साथ, आपको प्रत्येक उपयोगकर्ता अनुरोध के लिए कनेक्शन स्थापित करने की आवश्यकता नहीं है (इसलिए आप tcp लिंक + डेटाबेस के साथ सभी कनेक्शन और ऑर्टिक एक्सचेंज बनाने पर cpu / io / विलंबता बचाएं)। पॉलिसी की परिभाषा के अनुसार: आपका डेटाबेस डेटा तक हर पहुंच पर लगातार पहुंच की जाँच कर रहा होगा, तब भी जब आप उन्हें पहले एक बार चेक कर चुके हों। इसके अलावा 'पहुंच अस्वीकृत या निषिद्ध' 'ओके, नो रिजल्ट' के समान नहीं है। सुनिश्चित नहीं है कि सुरक्षा लोग ओके संस्करण को पसंद करेंगे।

— थिएरी

3

फैबियन, कनेक्शन पूलिंग किसी भी तरह के पैमाने पर मौलिक है, यह वास्तव में एक डिफ़ॉल्ट है जिसे आप उपयोग नहीं करने पर भी विचार नहीं करेंगे। यहां कुछ बेंचमार्क दिए गए हैं, जो आपको बता सकते हैं कि यह कितना महत्वपूर्ण है: कनेक्शन पूलिंग के साथ 600x प्रदर्शन में वृद्धि ( vladmihalcea.com/2014/04/17/the-anatomy-of-connection-pooling ) और 4xx प्रदर्शन वृद्धि के साथ कनेक्शन पूलिंग ( प्रगति . com/tutorials/jdbc/… )। यह परिमाण अंतर के कई आदेश हैं, यह "होना अच्छा नहीं" है, इसके बिना ऐप रुक जाएंगे।

— इवान मैका

1

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

— थियरी

ठीक है, मैंने सिर्फ कनेक्शन पूल के बारे में अधिक जानकारी के लिए खोज की है, और मैं मानता हूं कि यह एक बहुत ही मान्य बिंदु है क्योंकि वेबसाइट को प्रति सेकंड एक सौ से अधिक कनेक्शन संभालना है, जो कि उच्च नहीं है। ऐसा लगता है कि PostgreSQL में हर कनेक्शन लगभग 10MiB RAM खाता है! मैंने कभी नहीं सोचा था कि यह बहुत था।

— फाबियान पिज्के

1

एक अन्य बिंदु: कई [1] वेब एप्लिकेशन आपको ऐप के माध्यम से ऑन-लाइन एक उपयोगकर्ता खाता पंजीकृत करने और बनाने की अनुमति देते हैं। जिसका अर्थ है कि आपका अनाम उपयोगकर्ता (जिसके पास कम से कम विशेषाधिकार होने चाहिए) को उपयोगकर्ता बनाने और विशेषाधिकार प्रदान करने के अधिकार होने चाहिए!

ठीक है, यह संभव हो सकता है कि वह कौन से विशेषाधिकार दे सकता है, उसे सीमित करना और उच्च-स्तरीय उपयोगकर्ताओं को अधिक अनुदान विकल्प देना (मुझे पता नहीं है कि यह - हालांकि "विशेषाधिकार विशेषाधिकार" अक्सर नहीं है)। लेकिन फिर भी, इसका मतलब है कि हर किसी को हैक करने के लिए अनुदान विशेषाधिकारों के साथ ऑन-लाइन कुछ डालना। मुझे पूरा यकीन है कि अगर मैंने ऐसा किया तो मेरा डीबीए मुझे पसंद नहीं आएगा :)

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

इसके अलावा, यह जमा या पुन: उपयोग किए गए DB कनेक्शन के किसी भी उपयोग को रोक देगा।

[१] अधिकांश मैं कहूंगा, लेकिन इसे वापस करने के आंकड़े नहीं

— एडम
स्रोत