क्या एक ही लॉगिन का उपयोग करके दो डेटाबेस को जोड़ने के लिए 3 डी डेटाबेस के माध्यम से जाना अधिक सुरक्षित है?

Question

हमारे पास निम्नलिखित सेटअप है:

• निजी डेटा युक्त एकाधिक उत्पादन डेटाबेस जो डेस्कटॉप सॉफ़्टवेयर द्वारा उपयोग किया जाता है
• एक सार्वजनिक वेबसाइट के लिए एक वेब डेटाबेस जिसे निजी डेटाबेस से कुछ डेटा की आवश्यकता होती है
• एक मध्यस्थ डेटाबेस जिसमें कुछ दृश्य और संग्रहीत कार्यविधियाँ होती हैं जो निजी डेटाबेस से डेटा खींचती हैं

वर्तमान में वेबसाइट वेब डेटाबेस में लॉग करती है, और वेब डेटाबेस डेटा को खींचने या उत्पादन डेटाबेस पर संग्रहीत प्रक्रियाओं को निष्पादित करने के लिए मध्यस्थ डेटाबेस से जुड़ता है। सभी डेटाबेस एक ही SQL उदाहरण पर हैं, और पूरी प्रक्रिया एक ही उपयोगकर्ता खाते का उपयोग करती है।

उपयोगकर्ता खाते की वेब डेटाबेस और मध्यस्थ डेटाबेस तक पूरी पहुंच है, लेकिन केवल और निजी डेटाबेस के विशिष्ट विचारों और संग्रहीत प्रक्रियाओं तक ही पहुंच सकता है

क्या यह वास्तव में सार्वजनिक डेटाबेस को सीधे निजी लोगों से जोड़ने की तुलना में अधिक सुरक्षित है?

ऐसा लगता है कि मध्यस्थ डेटाबेस केवल चीजों को जटिल करने के लिए है क्योंकि सभी डेटाबेस में डेटा का उपयोग करने के लिए एक ही लॉगिन का उपयोग किया जाता है, और यह पहले से ही केवल उन विचारों / एसपी तक ही सीमित है, जिनकी इसे निजी डेटाबेस में जरूरत है। मैं इसे हटाने की उम्मीद कर रहा हूं।

Comments

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

— बेन ब्रोका

@BenBrocka वही है जो मैं सोच रहा था, लेकिन इससे पहले कि मैं इसे पूरी तरह से हटा दूं, मैं दोबारा जांच करना चाहता था

— राहेल

Answer 1

एक बात यहाँ कूदती है:

पूरी प्रक्रिया लॉगिन क्रेडेंशियल के एक ही सेट का उपयोग करती है

मुसीबत

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

हालाँकि, आप इस तरह से स्वामित्व को खो देते हैं।

चलो WebDB.dbo.SomeProcबुलावा आया PrivateDB.dbo.SomeTable। UserX को दोनों ऑब्जेक्ट पर अनुमति की आवश्यकता होती है। यदि यह OneDB.WebGUI.SomeProcउपयोग कर रहा था, OneDB.dbo.SomeTableतो केवल OneDB.WebGUI.SomeProcअनुमतियों की आवश्यकता है। एक ही मालिक के साथ संदर्भित वस्तुओं पर अनुमतियों की जाँच नहीं की जाती है।

नोट: मैंने क्रॉस डेटाबेस स्वामित्व चाइनिंग पर बहुत गहराई से नहीं देखा है । मैं केवल सादे पुराने "स्वामित्व चांग" को अच्छी तरह से जानता हूं

अब, टिप्पणियों के अनुसार आपके पास वास्तव में 2 डेटाबेस हैं जिन्हें संयुक्त किया जा सकता है। 3 नहीं जो मूल रूप से निहित था। हालांकि, मध्यवर्ती और वेब को जोड़ा जा सकता है।

अन्य "निजी" डेटाबेस को शायद संयुक्त किया जा सकता है, लेकिन यह एक अलग मुद्दा होगा। "एक डेटाबेस या कई" की पूरी चर्चा के लिए नीचे का लिंक देखें

समाधान?

यदि अतिरिक्त डेटाबेस केवल कोड कंटेनर हैं, तो स्कीमा एक बेहतर विचार है।

ऐसा लगता है कि आपने "डेटाबेस" का उपयोग किया है, जहां आपको "स्कीमा" का उपयोग करना चाहिए (SQL सर्वर अर्थ में, MySQL भावना नहीं)। मेरे पास एक WebGUI स्कीमा, एक हेल्पर या कॉमन स्कीमा (इंटरमीडिएट डेटाबेस को बदलने के लिए) और डेस्कटॉप स्कीमा होगा। इस तरह से आप क्लाइंट्स के आधार पर अलग-अलग परमिशन लेते हैं और सिर्फ एक डेटाबेस होता है

एक डेटाबेस के साथ ("स्वामित्व जंजीर" के अलावा) आप अनुक्रमित विचारों पर विचार करना भी शुरू कर सकते हैं, SCHEMABINDING (मैं इसका हमेशा उपयोग करता हूं) और ऐसे जो अलग डेटाबेस के साथ नहीं किया जा सकता है

स्कीमा पर अधिक जानकारी के लिए, इन प्रश्नों को देखें:

• स्कीमा डिजाइन - सर्वोत्तम अभ्यास?
• स्कीमा का अधिक उपयोग / सही उपयोग?

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

Comments

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

— राहेल

@ राशेल: "कई निजी डेटाबेस" बिट किसी भी उत्तर के लिए काफी प्रासंगिक है, विशेष रूप से यह एक ... मैंने कुछ अलग कहा होता अगर यह जाना जाता था

— gbn

@ राशेल: आपने प्रश्न पर "मल्टीपल प्राइवेटडीबी" का उल्लेख क्यों नहीं किया? यह सब कुछ बदल देता है ...; - \

— फैब्रिकियो अरूजो

@FabricioAraujo मैंने उस जानकारी को शामिल करने के लिए 2 घंटे पहले अपना प्रश्न संपादित किया। मुझे नहीं लगा कि यह उस समय मायने रखता था जब मैं डेटाबेस व्यवस्था की सुरक्षा के बारे में पूछ रहा था, इसका डिज़ाइन नहीं।

— राहेल

@ फ़ाइब्रिओआराज़ो: आवश्यक डिज़ाइन को परिभाषित करता है, इसलिए सुरक्षित होने से पहले एक डिज़ाइन सही होना चाहिए। एक सुरक्षित गलत डिजाइन बेकार है - एक असुरक्षित सही डिजाइन कभी भी सुरक्षित किया जा सकता है।

— फैब्रिकियो अराउजो

Answer 2

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

यदि नहीं, तो मुझे नहीं लगता कि यह जटिलता के अलावा कुछ भी जोड़ता है।

---

संपादित करें:

ऐसा लगता है कि मैंने आपके प्रश्न को गलत बताया है, तो आइए देखें कि क्या मैं अब ठीक से समझ गया हूं: IntermDb सिर्फ PrivateDB से कनेक्ट करने के लिए एक खाली डेटाबेस है या यह एक DB है जिसके पास स्वयं के विचार / प्रक्रिया है जो डेटा को पुनः प्राप्त करने के लिए PrivateDB से जुड़ता है ?

पहले मामले में, डब्ल्यूटीएफ? चीर डालो। यह तब तक बेकार है, जब तक कि कोई व्यक्ति इसे निजी तौर पर एक एक्सेसरीज़ में प्राइवेटडीबी तक पहुँच के लिए ऑडिट नहीं करना चाहता (और WebApp डेवलपर्स को और अधिक कठिन बना देता है)। SQL Profiler DB_ID का उपयोग करके फ़िल्टर कर सकता है ...

दूसरे मामले में, मैं अपने पिछले उत्तर को बनाए रखता हूं।

संपादित करें: "मैं अभी भी नहीं देखता कि यह निजी db को सीधे सार्वजनिक db से जोड़ने से ज्यादा सुरक्षित कैसे है क्योंकि सभी SQL डेटाबेस पर सभी 3 डेटाबेस एक ही हैं और सभी 3 डेटाबेसों के लिए उपयोग किया जाने वाला लॉगिन समान है, और केवल एक्सेस कर सकता है निजी db वैसे भी विशिष्ट दृश्य और संग्रहीत कार्यविधियाँ "।

मध्यस्थ साधन होने हमलावर अपने कोड में खुदाई करने के लिए होता है कि पता एक IntermDB के अस्तित्व - और यह यह पता करने के लिए, जिसमें किसी ऐसे PrivateDB मौजूद अपने कोड और परिश्रम करना होगा।

यदि आप अपने PrivateDB को अपने संगठन LAN / WAN (यदि संभव हो) पर किसी अन्य सर्वर पर आंतरिक रूप से रखते हैं, तो यह व्यवस्थापक को आक्रमण का प्रयास का पता लगाने और अवरुद्ध करने के लिए पर्याप्त समय दे सकता है। यदि आप समानार्थक शब्द का उपयोग करते हैं, तो यह चाल सुचारू है, क्योंकि आपके पास मौजूद कोड को सही जगह पर जाने के लिए उन्हें फिर से बनाया गया है।

इसके अलावा आप अन्य लाभ प्राप्त करते हैं: चूंकि सभी कोड को PrivateDB में डेटा तक पहुंचने के लिए IntermDB से गुजरना पड़ता है, इसलिए किसी भी डेवलपर को इसे बाईपास करने की कोशिश नहीं की जाएगी - और यह प्रयास SQLD प्रोफाइलर पर PrivateDb डेटा के अनुरोध के DB_ID के रूप में आसानी से देखा जा सकता है। WebAppDb होगा।

Comments

क्या सुरक्षा वैसी ही नहीं होगी जैसे कि आपके पास एक सर्वर पर सार्वजनिक डीबी था, और दूसरे पर निजी? सुरक्षा बढ़ाने के लिए उस योजना में तीसरा डेटाबेस जोड़ने से क्या होता है? हालांकि मेरी स्थिति में, सभी 3 डेटाबेस एक ही SQL सर्वर इंस्टेंस पर हैं (इस जानकारी को मेरे प्रश्न में भी जोड़ा है)

— राहेल

आपके संपादन के जवाब में, मध्य db में स्वयं के दृश्य और संग्रहीत कार्यविधियाँ होती हैं जो निजी db से डेटा लौटाती हैं। मैं अभी भी नहीं देखता कि यह निजी db को सीधे सार्वजनिक db से जोड़ने की तुलना में अधिक सुरक्षित कैसे है क्योंकि सभी 3 डेटाबेस एक ही SQL इंस्टेंस पर और सभी 3 डेटाबेसों के लिए उपयोग किया जाने वाला लॉगिन समान है, और यह केवल विशिष्ट दृश्यों और एक्सेस कर सकता है निजी db वैसे भी संग्रहीत कार्यविधियाँ

— राहेल