सभी को sa लॉगिन का उपयोग करने की अनुमति देना एक बुरा अभ्यास क्यों है?

Question

यहां तक ​​कि Microsoft SQL सर्वर प्रमाणीकरण मोड के उपयोग को हतोत्साहित करता है , लेकिन हमारे अनुप्रयोगों को इसकी आवश्यकता होती है।

मैंने पढ़ा है कि saविंडोज ऑथेंटिकेशन का उपयोग करने और उन खातों (या खाता समूहों) sysadmin विशेषाधिकारों का उपयोग करने के बजाय उपयोगकर्ताओं को सीधे लॉगिन का उपयोग न करने देना एक सर्वोत्तम अभ्यास है ।

• अनिवार्य रूप से एक ही बात नहीं है? फायदे / नुकसान क्या हैं?
• मेरे एसक्यूएल सर्वर इंस्टेंसेस की सुरक्षा में सबसे अच्छा अभ्यास कैसे बढ़ता है?
• क्या यह केवल उत्पादन के उदाहरणों पर, या हमारे आंतरिक विकास के उदाहरणों पर भी लागू होता है?

Comments

मैं इस आधे को एक विहित संदर्भ के रूप में पूछ रहा हूं क्योंकि मुझे Google के माध्यम से कुछ भी नहीं मिला (एक पहलू में संपादित करने के लिए स्वतंत्र महसूस हो रहा है), और प्रबंधन को समझाने के लिए आधा लाभ है कि यह बदलाव करना एक अच्छी बात है (टीएम)।

— जॉन सिगेल

यह उतना ही अच्छा है जितना कि हर किसी को अपने घर की चाभी देना। ;)

— जेरेमिया पेस्का

उल्लेख नहीं है, 'sa' SQL सर्वर के लिए एक पारंपरिक रूप से ज्ञात लॉगिन नाम है, इसलिए यह एक आसान लक्ष्य है। कोई अनुमान वास्तव में शामिल नहीं है। मैंने देखा है कि कंपनियां 'सा' से नाम बदलकर कुछ अलग करती हैं। यहां तक ​​कि अगर केवल एक छोटे स्तर पर, यह साइबर घुसपैठियों को किसी चीज़ के बारे में जानने के लिए थोड़ा कठिन बनाता है।

— थॉमस स्ट्रिंगर

आपके अनुप्रयोगों को इसकी आवश्यकता नहीं है । कृपया हमें बताएं कि आपको क्या लगता है कि वे ऐसा क्यों करते हैं।

— nvogel

बड़ा सवाल है। यदि केवल अन्य डेटाबेस पेशेवरों ने रोका और यह वही सवाल पूछा, तो बहुत कम सुरक्षा छेद होंगे।

— थॉमस स्ट्रिंगर

Answer 1

आपके यहाँ कई अलग-अलग प्रश्न हैं, इसलिए मैं उन्हें व्यक्तिगत रूप से बताऊंगा:

"मैंने पढ़ा है कि विंडोज प्रमाणीकरण का उपयोग करने के बजाय उपयोगकर्ताओं को सीधे सा लॉगइन का उपयोग न करने देना एक सर्वोत्तम अभ्यास है"

आप यहां दो चीजों को मिला रहे हैं: SA की अवधारणा, और SQL प्रमाणीकरण और Windows प्रमाणीकरण की अवधारणा।

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

यदि आप SQL प्रमाणीकरण का उपयोग करना चुनते हैं, तो SA सिर्फ एक SQL प्रमाणीकरण लॉगिन है। यह डिफ़ॉल्ट व्यवस्थापक उपयोगकर्ता नाम है, जैसे प्रशासक विंडोज प्रमाणीकरण में है। यह उस एक उदाहरण पर स्थानीय सुपरपॉवर है, लेकिन सभी उदाहरणों में वैश्विक सुपरपॉवर नहीं है।

"... और उन खातों (या खाता समूहों) को sysadmin विशेषाधिकारों की अनुमति देता है।"

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

उन्हें केवल लॉगिन मत समझो - वे लोग हैं जो आपको निकाल सकते हैं। यदि वे डेटाबेस को छोड़ देते हैं या गलती से आपकी बैकअप नौकरियों को निष्क्रिय कर देते हैं, तो वे निकाल नहीं सकते हैं, क्योंकि डिफ़ॉल्ट रूप से, SQL यह ट्रैक नहीं करता है कि किसने क्या किया। आप वह हैं जो निकाल दिया जाएगा क्योंकि यह होने जा रहा है, और आप यह कहने में सक्षम नहीं होंगे कि किस व्यक्ति ने ऐसा किया।

"सबसे अच्छा अभ्यास मेरे SQL सर्वर इंस्टेंसेस की सुरक्षा कैसे बढ़ाता है?"

आप दो काम करना चाहते हैं:

1. सर्वर को तोड़ने से लोगों को रोकें
2. जब वे सर्वर को तोड़ते हैं, तो यह पहचानने में सक्षम होते हैं कि यह किसने किया

पहला कम से कम विशेषाधिकार के सिद्धांत के साथ पूरा किया गया है: लोगों को केवल उन अनुमतियों को देना, जिनकी उन्हें आवश्यकता है, और अधिक कुछ नहीं।

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

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

"यह केवल उत्पादन उदाहरणों पर लागू होता है, या हमारे आंतरिक विकास के उदाहरणों के लिए भी?"

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

Comments

SA एक उदाहरण से जुड़े सर्वरों, ntfs आदि के कारण सभी मामलों में भगवान के अधिकारों को प्रदान कर सकता है

— gb

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

— ब्रेंट ओजेर

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

— gbn

ठीक है, यह एक अलग समस्या है। सबसे सुरक्षित संगठनों में मैंने देखा है, प्रत्येक सर्वर को अपने स्वयं के सेवा खाते के तहत रखना मानक अभ्यास है। यह मेरे एसक्यूएल सर्वर सेटअप चेकलिस्ट का हिस्सा भी है। ज़रूर, अगर आप उस बुनियादी स्पष्ट कदम को अनदेखा करते हैं, तो आप कम सुरक्षित हैं - लेकिन बात क्या है?

— ब्रेंट ओजार

Answer 2

वास्तव में यदि आप इस श्वेतपत्र को पढ़ते हैं: कर्तव्यों के श्वेतपत्र का SQL सर्वर पृथक्करण

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

मैं अक्षम करता हूं और "सा" खाते का नाम बदल देता हूं, ठीक उसी तरह जैसे आप ओएस पर अंतर्निहित व्यवस्थापक खाते के साथ करते हैं। केवल आपातकाल में उपयोग किया जाना है।

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

Comments

+1000 वह श्वेतपत्र उत्कृष्ट है। मैंने इससे बहुत कुछ सीखा।

— जॉन सिगेल

Answer 3

यदि आप बाहरी विनियामक नियंत्रण या मानकों (SOX, PCI आदि) के अधीन हैं, तो आप

• एक ऑडिट विफल हो जाएगा
• आपके मासिक PCI चेक पर विफल हो रहे हैं

डेवलपर्स के पास केवल विकास के लिए एक नेटवर्क SQL सर्वर पर db_owner होना चाहिए।

यदि आपके SQL सर्वर एक मानक बिल्ड (यानी एक ही सेवा खाते) के साथ नेटवर्क पर हैं, तो उन सभी पर एक ही अधिकार में एक सा है।

यदि सेवा खाता स्थानीय व्यवस्थापक है, तो आपके डेवलपर्स का सर्वरों पर भी पूर्ण नियंत्रण है।

कोई अपशगुन नहीं हैं।

Comments

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

— जॉन ऑफ ऑल ट्रेड्स

Answer 4

सा = सीसादीन

सा के साथ लॉग इन करने से उपयोगकर्ता को निम्न में से सभी करने की शक्ति मिलती है: - ड्रॉप करें और डेटाबेस बनाएं - डेटाबेस में वस्तुओं को संशोधित करें - लॉग इन करें और लॉगिन बनाएं - पासवर्ड बदलें - सभी डेटा हटाएं

एक विंडोज़ खाता sysadmin विशेषाधिकार प्रदान करना एक ही बात को पूरा करता है।

सूची आगे बढ़ती है, लेकिन इससे आपको कुछ अच्छे कारणों के लिए कभी भी एक गैर-व्यवस्थापक का उपयोग करने देना चाहिए।

एप्स को काम करने के लिए आपको नंगे न्यूनतम विशेषाधिकारों के साथ एक विंडो या एसक्यूएल खाता बनाना चाहिए। (अर्थात लॉगिन, संग्रहीत प्रक्रियाओं और विचारों का उपयोग)

Answer 5

सबसे अच्छा अभ्यास सा कुछ मजबूत पासवर्ड डाल रहा है और इसे भूल जाओ।

Answer 6

मेरे पास इस समय दो विकल्प हैं, जैसे कि एक कमजोर एसए खाता क्यों नहीं होना चाहिए। यदि आपके पास SA एक दुष्ट व्यक्ति के लिए एक कमजोर / खाली पासवर्ड है (अनुवाद करें कि 'अनुकूल सहयोगी'):

• सक्षम करें xp_cmdshell सिस्टम प्रक्रिया और, Sql सर्वर सेवा खाते के विशेषाधिकारों का उपयोग करते हुए, अपने स्थानीय बॉक्स को नुकसान पहुंचाएं (फ़ाइलें बनाएँ / हटाएं ..)। SA के लिए कम सुरक्षा होने से वास्तव में उदाहरण सेटिंग्स के बारे में बहुत कुछ नहीं कहा जा सकता है, लेकिन इसका अर्थ यह हो सकता है कि सेवा उपयोगकर्ता खराब प्रथाओं का पालन कर सकता है (जैसे कि एक व्यवस्थापक :-) होने के नाते);

• अपने उदाहरण पर मेल सक्षम करें और एक छोटी सी स्पैम फ़न स्क्रिप्ट को तेज़ी से अग्रेषित करें (जिससे आपको अपने इंटरनेट प्रदाता या अपने सहकर्मियों के साथ या तो कुछ परेशानी हो सकती है..जहाँ मेलिंग ;-) जाना);

मैं स्पष्ट तथ्यों को इंगित नहीं करूंगा कि यह डेटाबेस, लॉगिन ... आदि को छोड़ सकता है।

• अनिवार्य रूप से एक ही बात नहीं है? फायदे / नुकसान क्या हैं?

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

• मेरे एसक्यूएल सर्वर इंस्टेंसेस की सुरक्षा में सबसे अच्छा अभ्यास कैसे बढ़ता है?

• जैसा कि इस दुनिया में हर सर्वोत्तम अभ्यास अपना काम करता है..एक संभावित नकारात्मक घटना की संभावना को बढ़ाता है (जैसे: शारीरिक गतिविधि करने का सबसे अच्छा अभ्यास आपके जैसे मेरे होने की संभावना को कम कर देगा .. एक सोफे आलू) जो अन्यथा हो सकता है।

• क्या यह केवल उत्पादन के उदाहरणों पर, या हमारे आंतरिक विकास के उदाहरणों पर भी लागू होता है?

• मान लीजिए कि मैं कम से कम उत्पादन में सुरक्षा सर्वोत्तम प्रथाओं (परीक्षण और आपके पर्यावरण की जरूरतों को संशोधित) को लागू करने का सुझाव दूंगा। लेकिन अगर विकास में आप उत्पादन डेटा (संवेदनशील..इटीसी) का उपयोग करते हैं तो यह आपके लिए एक मजबूत संकेत है कि आप अपने विकास प्रथाओं को भी बदल सकते हैं।

Comments

-1 सवाल में वास्तव में पूछा गया है कि विंडोज इंटीग्रेटेड ऑथेंटिकेशन का पक्ष क्यों लिया जाए और SQL सर्वर ऑथेंटिकेशन से बचें, लेकिन यह पूरा करना असंभव है कि कैसे नहीं या "क्यों एक कमजोर SA अकाउंट नहीं होना चाहिए"

— फुलप्रूफ

@ फुलप्रूफ: मैं समझता हूं कि आप जो कह रहे हैं और प्रतिक्रिया के लिए धन्यवाद। एक कमजोर एसए खाते की मेरी व्याख्या एक कमजोर / बिना पासवर्ड वाला एसए खाता है जो किसी कंपनी में सभी द्वारा उपयोग किया जाता है। लेकिन सवाल पुराना है और मुझे पूरी जानकारी याद नहीं है। और मैं शीर्षक से मुख्य प्रश्न पर एक उच्चारण कर रहा था - सभी को सा लॉगिन का उपयोग करने की अनुमति देना एक बुरा अभ्यास क्यों है?

— मैरियन

Answer 7

आपके अंतिम प्रश्न को संबोधित करते हुए, हम अपने सभी विकास डेटाबेस (पासवर्ड "सा" के साथ, उस पर) एसए खातों का उपयोग करते हैं!)

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

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

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

डेटाबेस की अपनी प्रतियों के साथ डेवलपर्स के एक झुंड के लिए जो विशुद्ध रूप से परीक्षण डेटा रखते हैं, मुझे अभी भी एक मजबूत एसए खाते को बनाए रखने के लिए एक ठोस तर्क ढूंढना है।

Comments

सा के साथ, वे उदाहरण के लिए XP_cmdshell को सक्षम कर सकते हैं और फिर मांग को ठेस में चला जाता है। और जैसा कि मैंने उत्तर दिया, यह सभी सर्वरों पर अधिकार प्रदान कर सकता है। Dbo और आंशिक sa (db बनाएँ) आदि: कोई समस्या नहीं

— gbn

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

— रिचर्ड

Answer 8

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

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