जब एक उत्पादन वातावरण में वेब एप्लिकेशन (.net) को तैनात किया जाता है, तो क्या एकीकृत सुरक्षा का उपयोग करना बेहतर है या क्या यह भी मायने रखता है?
यह मुझे लगता है कि अगर कोई हैकर वेब सर्वर को तोड़ता है, तो यह वास्तव में कोई फर्क नहीं पड़ेगा क्योंकि वे मशीन को आसानी से लगा सकते हैं।
विचार?
जवाबों:
मैं कहता हूँ कि SQL नीति का उपयोग करने के केवल दो वैध कारण हैं:
आपके द्वारा प्रस्तावित किए जा रहे परिदृश्य के लिए (वेब सर्वर होस्ट पूरी तरह से समझौता किया हुआ है) कुछ भी आपकी रक्षा नहीं कर सकता है। हैकर डीबी सर्वर पर कम से कम वह सब कुछ कर सकता है जो वेब सर्वर कर सकता है । और मैं कहूंगा कि गहराई में रक्षा आपको ऐसे मामले में नुकसान को कम करने के लिए सिखा सकती है: उर वेब सर्वर द्वारा उपयोग किए जाने वाले खाते के डीबी अधिकारों को बिल्कुल कम से कम न्यूनतम आवश्यक और कुछ नहीं। दूसरा सुनिश्चित करें कि यदि वेब सर्वर होस्ट से छेड़छाड़ की जाती है, तो इसका उपयोग वेब सर्वर खाते की तुलना में विशेषाधिकारों को ऊंचा करने के लिए नहीं किया जा सकता है (यानी WWW होस्ट की कोई अन्य सेवा नहीं है जो WWW खाते की तुलना में DB पर उच्च विशेषाधिकार के साथ क्रेडेंशियल्स का उपयोग करता है)। ये बुनियादी सुरक्षा सिद्धांत हैं और इनका इस्तेमाल प्रमाणीकरण योजना से कोई लेना-देना नहीं है।
हालांकि sql ऑक्टाट बनाम विंडोज़ ऑर्टोरेज़ न तो आपके परिदृश्य में स्पष्ट लाभ देता है, विचार करने के लिए अन्य मुद्दे हैं:
एक आखिरी नोट: टीडीएस प्रोटोकॉल ट्रैफ़िक पर स्पष्ट पाठ में sql ऑक्टोरिअल पासवर्ड को उजागर करता है, लेकिन ट्रैफ़िक के SSL एन्क्रिप्शन का अनुरोध करके इसे आमतौर पर कम कर दिया जाता है।
तो क्यों आप अभी भी sql को देख रहे हैं WWW मेजबान कि web.config में स्पष्ट में पासवर्ड स्टोर? जो बुरे डेवलपर / व्यवस्थापक हैं, उनमें से एक मत बनो।
msdn.microsoft.com/en-us/library/aa378326(VS.85).aspx
technet.microsoft.com/en-us/library/ms189067.aspx
यदि आप SSPI का उपयोग नहीं करते हैं, तो आप उपयोगकर्ता नाम और पासवर्ड को स्रोत फ़ाइलों में हार्डकोड कर रहे हैं।
यदि आप स्रोत फ़ाइलों में उपयोगकर्ता नाम और पासवर्ड को हार्डकोड कर रहे हैं, तो आपके सभी कर्मचारियों तक इसकी पहुंच है।
यह अपेक्षाकृत असुरक्षित है। एक असंतुष्ट पूर्व कर्मचारी दुर्भावनापूर्ण रूप से जानकारी का उपयोग कर सकता है। एक आगंतुक कहीं स्क्रीन पर कोड को देख सकता है। या स्रोत कोड गलती से जंगली में निकल सकता है।
SSPI का लाभ यह है कि पासवर्ड कभी भी स्पष्ट रूप से कहीं भी संग्रहीत नहीं किया जाता है।
अब तक के अन्य उत्तर अच्छे रहे हैं, लेकिन मैं एक और एक में फेंक दूंगा: प्रबंधन।
जल्दी या बाद में, आप संभवतः कई SQL सर्वर के साथ समाप्त करने जा रहे हैं। अपने ऐप और कई SQL सर्वर के बीच SQL प्रमाणीकरण का प्रबंधन करना थोड़ा दर्दनाक हो जाता है, खासकर जब आप सुरक्षा समस्याओं में भाग लेते हैं। यदि आप एक बार Windows प्रमाणीकरण पासवर्ड बदलते हैं, तो यह आपके सभी सर्वरों पर तुरंत बदल जाता है। यदि आपको अपने SQL प्रमाणीकरण पासवर्ड को घुमाने की आवश्यकता है, तो यह अधिक दर्दनाक है - उस बिंदु पर जहां आप शायद ऐसा बिल्कुल नहीं करेंगे। यह एक सुरक्षा जोखिम है।
मैं यहां 100% निश्चित नहीं हूं, लेकिन मुझे लगता है कि मुख्य बिंदु यह है कि SQL ऑर्किटेक्ट असुरक्षित है, इसलिए विंडोज ऑर्कुट का उपयोग करना बेहतर है। इस बात पर निर्भर करता है कि आपका ऐप कैसे सेटअप है, आप विंडोज ऑर्टिक का उपयोग करके मशीन पर एन्क्रिप्टेड रूप में उचित क्रेडेंशियल्स भी स्टोर कर सकते हैं। मुझे नहीं लगता कि यह एसक्यूएल के साथ वास्तव में संभव है। आप इसे बाधित कर सकते हैं, लेकिन अंततः यह स्पष्ट होना चाहिए।
इसके अलावा, सिर्फ इसलिए कि एक हैकर एक सर्वर में मिल सकता है इसका मतलब यह नहीं है कि यह खेल खत्म हो गया है। एक हैकर एक अप्रकाशित प्रक्रिया पर नियंत्रण हासिल कर सकता है लेकिन सर्वर पर कुछ और नहीं करता। इसलिए यह महत्वपूर्ण है कि सब कुछ व्यवस्थापक या सिस्टम के रूप में न चलाएं, बल्कि न्यूनतम विशेषाधिकार सेवा खातों का उपयोग करें।
सबसे अच्छी बात यह है कि वे क्या कर सकते हैं अगर वे / जब वे वेब सर्वर में तोड़ते हैं। इसका मतलब है कि एप्लिकेशन को कार्य करने के लिए केवल SQL अधिकारों की आवश्यकता है। एप्लिकेशन को डीबीओ अधिकार देना बहुत आसान है, लेकिन यह वेबसर्वर पर एक सफल हमले की स्थिति में डीबी को अधिक कमजोर बनाता है।
मैं यह कहते हुए यह सब करने जा रहा हूं कि मैं यह धारणा बना रहा हूं कि आप आंतरिक निजी नेटवर्क पर आंतरिक वेब सर्वर के बारे में बात कर रहे हैं।
चलो मशीन लगाने के साथ शुरू करते हैं। यदि एप्लिकेशन पूल पहचान नेटवर्क सेवा है और .NET अनुप्रयोग में कोई प्रतिरूपण नहीं है, तो हां, वेब एप्लिकेशन मशीन के कंप्यूटर खाते का उपयोग करके बैक-एंड SQL सर्वर से कनेक्ट होगा। और इसका मतलब है कि आपने उक्त मशीन खाते तक पहुंच प्रदान की है। Microsoft का CRM इस तरह काम करता है।
हालाँकि, यदि आपने कोई पहचान निर्दिष्ट की है, तो उस उपयोगकर्ता खाते को SQL सर्वर तक पहुँच की आवश्यकता होगी। जब आप सही होते हैं कि यदि कोई हमलावर वेब सर्वर से समझौता करता है तो उनके पास प्रभावी रूप से पहचान खाते के समान पहुंच होती है, इस मामले की सच्चाई यह है कि SQL सर्वर लॉगऑन का उपयोग करने से यहां कुछ भी नहीं बदलता है। एक बार जब मेरे पास पहुंच होती है, तो मैं वेब एप्लिकेशन को संशोधित कर सकता हूं कि मैं क्या चाहता हूं और यह होगा, बैक-एंड SQL सर्वर पर आपके सुरक्षा परमिट को अधिकतम करने के लिए।
अब SSPI का उपयोग क्यों करें। और सबसे पहले, आप SQL सर्वर आधारित लॉगिन का उपयोग नहीं कर रहे हैं। इसका मतलब है कि सक्रिय निर्देशिका सुरक्षा के लिए एकमात्र स्रोत है। इसका मतलब है कि आपके पास अमान्य पहुंच का निर्धारण करने के लिए सामान्य ऑडिट साधन है। दूसरा, इसका मतलब है कि जब तक कि अन्य एप्लिकेशन की आवश्यकता नहीं है, तब तक आप अपने SQL सर्वर को केवल विंडोज प्रमाणीकरण में छोड़ सकते हैं। इसका मतलब है कि कोई SQL सर्वर लॉगिन की अनुमति नहीं है। इसका मतलब है कि सा के खिलाफ कोई भी हमला शुरू होने से पहले ही रोक दिया जाता है। और अंत में, यह वसूली को आसान बनाता है। यदि आप SQL सर्वर आधारित लॉगिन का उपयोग करते हैं, तो आपको SID और एन्क्रिप्टेड पासवर्ड के साथ लॉगिन निकालना होगा। यदि आप एक नए SQL सर्वर पर लॉग इन बनाकर, "सेवा खाता" के रूप में विंडोज आधारित उपयोगकर्ता खाते का उपयोग कर रहे हैं,
सवाल यह है कि "बेहतर" कौन है? इसका उत्तर कठिन है क्योंकि यह प्रश्नकर्ता के संदर्भ, मूल्यों और प्राथमिकताओं पर निर्भर करता है।
निजी तौर पर, मुझे एसक्यूएल ऑर्ट पसंद है।
अंतिम बिंदु: आप प्रत्येक कनेक्शन स्ट्रिंग को आज़माने के लिए अपने कनेक्शन प्रबंधक वर्ग को कोड करते हैं, इस तरह आप पासवर्ड को पहले कॉन्फिगर में बदल सकते हैं, परिवर्तन को धकेल सकते हैं, और यह दूसरे कनेक्शन में विफल हो जाएगा, तो आप MSQL पर पासवर्ड अपडेट करें और पहले वाले को फिर से इस्तेमाल किया जाएगा। अगली बार पहले से तैयार दूसरे पासवर्ड को पहले की तरह सेट करने के लिए अंतिम कॉन्फिग चेंज की जरूरत होती है।
यदि उपयोगकर्ता डेटाबेस में सीधे हेरफेर नहीं करेंगे (अन्य क्लाइंट टूल्स जैसे कि SQL सर्वर मैनेजमेंट स्टूडियो के माध्यम से) तो मैं आमतौर पर आवेदन के लिए केवल एक ही एसक्यूएल लॉगिन बनाऊंगा और इसे एक्सेस की आवश्यकता प्रदान करूंगा। उस बिंदु पर उपयोगकर्ता वेब एप्लिकेशन इंटरफ़ेस द्वारा अनुमति के अनुसार वे क्या कर सकते हैं में प्रतिबंधित है।