किसी एप्लिकेशन को sa खाते का उपयोग क्यों नहीं करना चाहिए

21

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

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

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

जब मैंने इसे समझा और सर्वर टीम ने विक्रेता से बात की, तो उन्हें 'क्या समस्या है?' और फिर 'अच्छी तरह से हम पासवर्ड को देखकर' फिशिंग को देख सकते हैं

मुझे पता है कि फ़ाइल तक पहुंच को प्रतिबंधित करने के तरीके और साधन हैं लेकिन यह मेरी राय में सुरक्षा में बस एक और कमजोरी है

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

sql-server sql-server-2008 security

— SQLDBAWithABeard
स्रोत

1

saया sysadminWindows लॉगिन सहित किसी भी सदस्य ?

— रेमस रुसानु

sa और sa केवल :-(

— SQLDBAWithABeard

1

आपको विक्रेता से अधिक जानकारी प्राप्त करने की आवश्यकता है। विशेष रूप से वे कौन सी चीजें कर रहे हैं जिनकी saस्पष्ट रूप से आवश्यकता होती है ।

— हारून बर्ट्रेंड

11

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

— डेविड स्पिललेट

डेविड ने इसे सही ढंग से माना है कि मैं विक्रेता के साथ अपने संक्षिप्त व्यवहार से मानता हूं

— SQLDBAWithABeard

21

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

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

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

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

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

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

— SQLDBAWithABeard

+1 मुझे विशेष रूप से यह टिप्पणी पसंद आई कि यह एक है सुरक्षा मुद्दा है, यह मुद्दा नहीं है।

— केनेथ फिशर

2

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

— mdoyle

Mdoyle - समस्या यह है कि जैसा कि मैंने इसके बारे में और अधिक जाना है डेसीडर्स ने £ संकेतों में चीजों को देखा है और जैसा कि यह एक प्राचीन संस्करण से एक उन्नयन है यह सस्ता आ रहा है। मुझे लगता है कि मैं यहां अच्छे लोगों की बदौलत लड़ाई जीत रहा हूं। मैंने कम से कम वर्तमान में इसके लिए वेब सर्वर के हिस्से के परीक्षण में देरी की है

— SQLDBAWithABeard

20

किसी भी एप्लिकेशन को SA का उपयोग करने की आवश्यकता नहीं है - कभी भी। (जब तक इसका एकमात्र उद्देश्य किसी प्रकार का डेटाबेस प्रशासन न हो।)

किसी भी लॉगिन (एप्लिकेशन- या व्यक्तिगत-) को अधिक अधिकार कभी नहीं देना एक सामान्य नियम है, जिसके लिए व्यवसाय को उस लॉगिन की आवश्यकता होती है।

कोई भी एप्लिकेशन पूरी तरह से सुरक्षित नहीं है। अधिकांश में किसी प्रकार का SQL इंजेक्शन या XSS भेद्यता है। यदि कोई घुसपैठिया अपने चुनने के बयान को अंजाम देता है और उसकी 'SA' पहुंच होती है, तो आपके डेटा के लिए बहुत सी चीजें हो सकती हैं जो व्यवसाय को तुरंत मार सकती हैं। (विशेष रूप से अगर डेटा पर भरोसा करने की आवश्यकता है क्योंकि यह कानून प्रवर्तन द्वारा उपयोग किया जाता है।) हितधारकों से पूछें कि उन्हें क्या करना होगा, अगर कोई जानबूझकर एक भी रिकॉर्ड बदलने में सक्षम था और वह जानकारी लीक हो गई थी।

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

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

SA के आवश्यक होने का सबसे संभावित कारण यह है कि एप्लिकेशन को SQL एजेंट के साथ सहभागिता करने की आवश्यकता है। कम से कम यह सही लागू करने के लिए कठिन कार्यों में से एक है और ज्यादातर लोग इसे प्राप्त करने के लिए "SA का उपयोग करें" मार्ग लेते हैं। 'SA' की आवश्यकता स्वयं विक्रेता को हो सकता है कि वह sadadmin अनुमतियों की जांच न करना जानता हो।

दो उपाय हैं जिन्हें आप आजमा सकते हैं:

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

यदि यह सब इस सॉफ़्टवेयर की आवश्यकता से "उन्हें" नहीं रोकता है, तो आखिरी सिफारिश जो मैं आपको दे सकता हूं, वह है। यदि डेटा के लिए कुछ होता है तो आप पहली बार जिम्मेदार होने जा रहे हैं। इसलिए, इस एप्लिकेशन के साथ आपके पास शायद कोई नौकरी की सुरक्षा नहीं है, इसलिए एक नियोक्ता ढूंढें जो आपको कम से कम कुछ देता है।

— सेबस्टियन माइन
स्रोत

4

+1 बस "गैस लाइन सीधे चिमनी के माध्यम से" उपमा के लिए।

— ypercube y

SQL सर्वर में sa खाते का नाम नहीं बदला जा सकता है। हालाँकि, यह अक्षम हो सकता है।

— ग्रीनस्टोन वाकर

1

@GreenstoneWalker: यकीन है कि यह कर सकते हैं alter login sa with name = [as];:।

— रेमस रूसु

रेमुस, जो मुझे SSMS पर भरोसा करने के लिए और पुराने ज्ञान पर भरोसा करने के लिए भी सही काम करेगा। SQL Server 2005 से पहले इसका नाम बदला नहीं जा सका। SSMS सा लॉगिन का नाम बदलने में सक्षम नहीं लगता, लेकिन आपके द्वारा पोस्ट किया गया T-SQL बिल्कुल सही है।

— ग्रीनस्टोन वाकर

12

मुझे इस पर हमला करने की दो लाइनें दिखाई देती हैं।

अनुपालन । क्या आपकी दुकान में कोई अनिवार्य अनुपालन मानदंड है? इसके शब्दांकन के माध्यम से ध्यान से खोजें और देखें कि क्या आपको ऐसा कुछ भी मिलता है जो एप्लिकेशन 'आवश्यकता' के साथ असंगत होगा। यदि आपको ऐसी कोई भी चीज मिलती है जो saकिसी एप्लिकेशन द्वारा उपयोग को रोकती है तो आपके पास बुलेट प्रूफ वाटर टाइट केस है, क्योंकि एप्लिकेशन आपके व्यवसाय को उत्तरदायी बना देगा आदि।
उपयोगकर्ता व्यवस्थापक पहुँच । सुनिश्चित करें कि आप इस मामले को स्पष्ट रूप से प्रस्तुत करते हैं कि एक एप्लिकेशन जिसे saप्रभाव में पहुंच की आवश्यकता होती है, यह saउन सभी कॉर्पोरेट उपयोगकर्ताओं तक पहुंच प्रदान करता है जिनके पास कार्यस्थानों पर व्यवस्थापक अधिकार हैं जहां एप्लिकेशन इंस्टॉल किया गया है। saस्थानीय प्रवेश से पासवर्ड को छुपाने का कोई तरीका नहीं है , जहां आवेदन चलता है, यह एक तथ्य है और 'स्क्रैचिंग' की कोई भी मात्रा इसे रोक नहीं सकती है। विश्वास का कोई स्थानीय रूट नहीं है जो एक स्थानीय व्यवस्थापक को नहीं मिल सकता है, अगर वह चाहता है। यह स्पष्ट कर दें कि एक ऐसा एप्लिकेशन होना जो एप्लिकेशन चलाने वाले सभी उपयोगकर्ताओं saको saविशेषाधिकार देने के लिए समान हो । यह बताएं कि उपयोगकर्ता क्या कर सकते हैं, इसका क्या मतलब है:
- न केवल इस एप्लिकेशन से, बल्कि उस सर्वर पर होस्ट किए गए किसी भी अन्य डेटाबेस से सर्वर में किसी भी डेटा को पढ़ने की क्षमता
- सर्वर पर किसी भी डेटा को संशोधित करने की क्षमता , फिर से उसी सर्वर पर किसी अन्य डेटाबेस से
- एक संशोधन के बाद उसके कार्यों के किसी भी निशान को मिटाने की क्षमता
- किसी भी ऑडिट और इतिहास को बदलने की क्षमता यह प्रकट करने के लिए कि कुछ कार्यों को एक अलग उपयोगकर्ता द्वारा किया गया था
- SQL सर्वर क्रेडेंशियल का उपयोग करने की क्षमता इस सर्वर पर भरोसा करने वाले किसी अन्य संसाधन पर हमले को बढ़ाने के लिए । यह किसी भी अन्य SQL सर्वर लेकिन अन्य संसाधनों के रूप में अच्छी तरह से कर सकते हैं, सहित, लेकिन फ़ाइल शेयर, एक्सचेंज सर्वर आदि के लिए प्रतिबंधित नहीं है, क्योंकि SQL सर्वर सिर्फ एक कदम पत्थर के रूप में इस्तेमाल किया जा सकता है।

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

— रेमस रुसानु
स्रोत

धन्यवाद रेमुस ठीक यही उत्तर मुझे चाहिए। मैं धीरे-धीरे लड़ाई जीत रहा हूं और यह सब मदद कर रहा है

— SQLDBAWithABeard

7

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

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

यह लीव प्रिविलेज का सिद्धांत है।

जैसे कि एप्लिकेशन को sa खाते का उपयोग करने की आवश्यकता क्यों है, यह एक सवाल है कि PerfMon या विस्तारित ईवेंट का जवाब देने में सक्षम होना चाहिए। T-SQL टेम्पलेट का उपयोग करके एक PerfMon ट्रेस बनाएं, शायद एप्लिकेशन के नाम से फ़िल्टर किया गया हो।

मेरे सिर के ऊपर, यहाँ sa का उपयोग करने के खिलाफ एक और तर्क दिया गया है: sa खाते का उपयोग करने के लिए SQL सर्वर सेवा को मिश्रित प्रमाणीकरण मोड में होना आवश्यक है। केवल प्रमाणीकरण बेहतर है क्योंकि हम करबरोस की सभी सुरक्षित सुविधाओं का लाभ उठा सकते हैं।

— ग्रीनस्टोन वाकर
स्रोत

4

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

यदि आपके पास यह एप्लिकेशन है तो मैं इसे एक अलग उदाहरण पर चलाऊंगा जिस पर कुछ और नहीं है।

— mrdenny
स्रोत

मुझे लगता है कि यह शायद जांचता है कि क्या यह सा के रूप में चल रहा है और फिर विफल रहता है क्योंकि यह sysadmin के साथ एक खाते के तहत नहीं चलेगा

— SQLDBAWithABeard

1

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

— mrdenny

4

शायद आपका विक्रेता अनुरोध कर रहा है / "सा" की आवश्यकता है क्योंकि कहीं न कहीं उनके आवेदन में वे XP_CMDSHELL का उपयोग कर रहे हैं। (XP_CMDSHELL तक अप्रतिबंधित पहुंच के साथ मुझे संभव नुकसान की शुरुआत न करें। यह कहने के लिए पर्याप्त है कि यह संभावित रूप से आपके डेटा को नहीं बल्कि मेजबान मशीन को खोलता है और शायद, आपके नेटवर्क पर कुछ और भी व्यवस्थापक जैसी पहुंच के लिए।

यदि कोई कानूनी आवश्यकता है, तो आप प्रॉक्सी खाते के माध्यम से प्रतिबंधित पहुंच दे सकते हैं। उदाहरण के लिए देखें, BOL: http://msdn.microsoft.com/en-us/library/ms175046.aspx

— TheDataBeagle
स्रोत

4

किसी भी एप्लिकेशन को संचालित करने के लिए एसए खाते और पासवर्ड की आवश्यकता नहीं होनी चाहिए।

हालाँकि, मैंने एक IT सेवा प्रबंधन उत्पाद स्थापित किया है, और स्थापना प्रक्रिया के दौरान आपके पास SA खाता क्रेडेंशियल्स की आपूर्ति करने का विकल्प है जो इंस्टॉलर को DB बनाने और सॉफ़्टवेयर के उपयोग के लिए DB को एक खाता संलग्न करने की अनुमति देता है। SA खाता क्रेडेंशियल एप्लिकेशन या इंस्टॉलर लॉग में कहीं भी सहेजे नहीं जाते हैं। यह सॉफ्टवेयर इंस्टॉलेशन के दौरान पूर्व-निर्मित डेटाबेस का उपयोग करने का विकल्प भी प्रदान करता है।

इसलिए मैं सिर्फ इस बात की पुष्टि करूंगा कि संस्थापन के लिए SA खाते की आवश्यकता है या इस IT सेवा प्रबंधन सॉफ्टवेयर के संचालन की।

यदि इंस्टॉलेशन: एक अस्थायी 'सा' खाता बनाएं - इंस्टॉल करें - और खाते को हटा दें।

यदि ऑपरेशन: प्लेग की तरह उस सॉफ्टवेयर से बचें। (या एक स्टैंडअलोन SQL सर्वर को सेटअप करेगा जो केवल उस एक डेटाबेस को घर देगा।)

— ब्रेंट
स्रोत

समर्पित SQL सर्वर आवृत्ति के लिए +1। यह असली सर्वर पर सा देने के लिए एक अच्छा अंतिम विकल्प होगा।

— डैन

0

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

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

— इवान स्टैंकोविक
स्रोत

1

क्या यह एक दुर्घटना या जानबूझकर था - एक ही सटीक उत्तर के साथ 2 प्रश्नों का उत्तर देना?

— ypercube y

टिप्पणी के लिये आपका धन्यवाद। बस सोचा था कि स्पष्टीकरण दोनों मामलों में मदद कर सकता है।

— इवान स्टेनकोविक

दिलचस्प है, लेकिन विशेष रूप से ओपी के लिए उपयोगी नहीं है।

— डैन