उत्पादन में मेरे विशेषाधिकारों को कम करने पर कोई संकेत नहीं बल्कि मेरे काम को अत्यधिक कठिन बना रहा है

Question

Windows 2008 R2 पर SQL सर्वर 2005 और 2008 चल रहा है।

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

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

सबसे अच्छा तरीका क्या है? दिन-प्रतिदिन और प्रतिष्ठानों के दौरान उपयोग करने के लिए कम से कम दर्दनाक क्या होगा?

वर्तमान में हमारे पास डीबीए के लिए एक विंडोज़ समूह है जिसमें हमारे सभी सर्वर और डेटाबेस के अधिकार हैं।

मुझे OS / रिमोट लॉगिन अनुमतियाँ कम करने में भी दिलचस्पी होगी - लेकिन मैं DB अधिकारों से सबसे अधिक चिंतित हूं।

हम अनुमान लगा रहे हैं कि हमें अपने पुराने लॉगिन SA अधिकारों को छीनने से पहले कुछ निजी स्वामित्व वाले स्थानों पर sa के रूप में चलाने के लिए निजीकरण की आवश्यकता होगी। हम किन अन्य समस्याओं की उम्मीद कर सकते हैं?

आपकी सलाह और अपने अनुभव साझा करने के लिए धन्यवाद!

Comments

आप किस डेटाबेस प्लेटफ़ॉर्म (एस) का उपयोग कर रहे हैं (SQL सर्वर, Oracle, DB2, MySQL, आदि)? क्या आप डेटाबेस विशेषाधिकारों के बारे में बात कर रहे हैं? या ऑपरेटिंग सिस्टम विशेषाधिकार?

— जस्टिन गुफा

यह मदद करेगा, एह? SQL सर्वर 2005/2008। DB और OS दोनों निजी में रुचि रखते हैं।

— सैम

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

— Gaius

हां, मेरे पास सर्वर पर लाल और देव पर हरा करने के लिए मेरा डेस्कटॉप सेट है। मैं ज्यादातर SSMS में डेटा संशोधन गलतियों के बारे में सोच रहा हूँ।

— सैम

Answer 1

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

जिस प्रकार के अधिकार के तहत userIDs चलते हैं, केवल वही अधिकार हैं जो वास्तव में उनके पास होने चाहिए db_datareader, db_datawriterऔर स्पष्ट GRANT EXECUTE ON x TO y(प्रत्येक संग्रहीत खरीद के लिए और उपयोगकर्ता के xलिए उपयोगकर्ता परिभाषित फ़ंक्शन y)।

यदि आपको उत्पादन में निशान लगाने की आवश्यकता है, तो आपको कुछ समस्याएं हैं और यह सब समझाने के लिए एक शानदार दीवार ऑफ टेक्स्ट ™ लगेगा। मेरी पहली सिफारिश एक क्यूए वातावरण है जो उत्पादन की तरह ही बंद है और अगर निशान को चलाने की आवश्यकता है, तो QA को दिए गए ठेस के बैक-अप को पुनर्स्थापित करें और वहां निशान चलाएं। फिर, यदि आपके पास SOX, HIPAA या PCI-DSS आवश्यकताएं हैं, तो आप QA को पुनर्स्थापित करने से पहले ठेस डेटा को बेहतर तरीके से साफ करते हैं।

वर्तमान में हमारे पास डीबीए के लिए एक विंडोज़ समूह है जिसमें हमारे सभी सर्वर और डेटाबेस के अधिकार हैं।

उन्हें लॉगऑन दें और डेटा अधिकार देखें; हालाँकि DBAly कर्तव्यों का पालन करने के लिए, उन्नत विशेषाधिकारों के साथ एक अलग लॉगिन का उपयोग करें। मैं एक वित्तीय ग्राहक को जानता हूं जो ऐसा करता है - नियमित रूप से विंडोज़ प्रमाणीकरण आधारित लॉगिन उन नुकसानों में सीमित थे जो वे अनजाने में कर सकते थे। अलग SQL प्रमाणीकरण लॉगिन के साथ DML को पुनर्स्थापित करने और चलाने की आवश्यकता है।

एक सरकारी एजेंसी मैंने प्रत्येक सर्वर / डीबी व्यवस्थापक के लिए उपयोग किए गए 2 अलग लॉगिन के साथ काम किया। तो अगर Tangurenaमेरा डोमेन लॉगिन था (इस लॉगिन में नियमित Userविशेषाधिकार होंगे), तो TangurenaAdminमेरा अलग Administratorलॉगिन होगा। यदि आप अपने व्यवस्थापक खाते का उपयोग हर समय करते हैं, तो आप परेशानी में पड़ जाते हैं, लेकिन फिर इसमें अन्य चीजों की अनुमति नहीं होती है (जैसे कोई ईमेल नहीं है। ओह, आप कहते हैं कि जैसे यह एक बुरी बात है ... )।

मैं जिस सरकारी एजेंसी के साथ काम कर रहा हूं उसमें प्रत्येक सर्वर / डीबी व्यवस्थापक हैं, जिनके पास मानक उपयोगकर्ता के ऊपर विशेषाधिकार हैं, लेकिन काफी व्यवस्थापक नहीं हैं ( PowerUserसमूह के रूप में सोचें )। डोमेन व्यवस्थापक फ़ंक्शन एक साझा डोमेन व्यवस्थापक खाते के साथ किया जाता है।

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

मुझे लगता है कि हम सा के रूप में निशान चलाने के लिए ऊंचा निजी की आवश्यकता होगी

नहीं, आपको केवल अतिरिक्त अनुमति चाहिए:
http://msdn.microsoft.com/en-us/library/ms187611.aspx

Comments

कृपया प्रश्न में बोल्ड सेक्शन पढ़ें।

— सैम

एक अच्छा जवाब देने के लिए धन्यवाद - और अपने अतीत से विशिष्ट। बहुत सराहना की।

— सैम

क्या आपका मतलब है शायद?

— सैम

@ ससम, तय ....

— तंगुरेना

Answer 2

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

मैं आपको अपना आंतरिक दृष्टिकोण बताऊंगा:

• सभी अनुप्रयोग एक एकल डोमेन उपयोगकर्ता का उपयोग करते हैं जो डेटाबेस पर आवश्यक अनुमतियाँ (आमतौर पर db_owner डेटाबेस भूमिका) दी जाती हैं।

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

• DBA टीम के लिए हमारे पास एक डोमेन समूह है जिसमें मशीन और सर्वर पर सभी विशेषाधिकार हैं (विंडोज़ मशीन पर व्यवस्थापक और sql सर्वर पर sysadmin)

• स्थापना के लिए हमारे पास एक SQL उपयोगकर्ता है जो डेटाबेस पर db_owner है जिसे हम अपडेट चलाते समय उपयोग करते हैं - हम स्कीमा परिवर्तनों की निगरानी के लिए DDL ट्रिगर का उपयोग करते हैं और हमें यह देखना चाहिए कि स्थापना के दौरान या अलग-अलग परिवर्तनों के रूप में कौन से परिवर्तन किए गए थे।

• अनुभवी डेवलपर्स के लिए कुछ सामयिक अपवाद हैं, लेकिन उनकी आवश्यकता पूरी होने के बाद हम उनकी पहुंच को हटा देते हैं - वे अपने डोमेन लॉगिन के आधार पर अनुमति प्राप्त करते हैं, इसलिए हम ट्रैस / ddl दृश्यों में कनेक्शन की निगरानी कर सकते हैं और ddl ट्रिगर के साथ किसी भी संभावित परिवर्तन कर सकते हैं।

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

Comments

कृपया प्रश्न को पुनः पढ़ें। आप में से कोई भी दूर से पास नहीं हो रहा है।

— सैम

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

— मैरिएन

Answer 3

SQL सर्वर में आप एक डेटाबेस उपयोगकर्ता बना सकते हैं और इसे database roleरीड / राइट / ओनरशिप अनुमति (ओं) के साथ असाइन कर सकते हैं । एक बार उपयोगकर्ता के उत्पादन के लिए माइग्रेट हो जाने के बाद, आप उस डेटाबेस उपयोगकर्ता पर जा सकते हैं जो माइग्रेट किया गया था और उन भूमिकाओं को अन-चेक करें जिन्हें आप नहीं चाहते हैं। उदाहरण के लिए, यह बताता है कि उपयोगकर्ता स्टेन परीक्षण में db_owner (डेटाबेस का स्वामित्व) का सदस्य है। एक बार जब उपयोगकर्ता स्टैन उत्पादन के लिए माइग्रेट हो जाता है, तो आप इसे db_owner से निकाल सकते हैं और केवल db_datareader (केवल पढ़ने के लिए) की भूमिका असाइन कर सकते हैं।

SQL 2005+ में अधिक दानेदार नियंत्रण के साथ किया जा सकता है schema। अधिक जानकारी के लिए स्कीमा पर इस लिंक की जाँच करें ।

Comments

कृपया प्रश्न में बोल्ड सेक्शन पढ़ें।

— सैम