क्या मेरे ओरेकल डीबीए को रूट एक्सेस की आवश्यकता है?


14

मेरा ओरेकल डीबीए सहयोगी हमारे उत्पादन सर्वर पर रूट एक्सेस का अनुरोध कर रहा है
वह तर्क दे रहा है कि उसे कुछ ऑपरेशन करने की आवश्यकता है जैसे सर्वर को रिबूट करना और कुछ अन्य कार्य।

मैं उससे सहमत नहीं हूँ क्योंकि मैंने उसे एक Oracle उपयोगकर्ता / समूह और एक dba समूह सेट किया है जहाँ Oracle उपयोगकर्ता हैं। सब कुछ सुचारू रूप से चल रहा है और डीबीए के बिना वर्तमान में रूट एक्सेस नहीं है।
मुझे यह भी लगता है कि इन्फ्रास्ट्रक्चर इंटरैक्शन की गलतफहमी से संबंधित किसी भी तरह के मुद्दों से बचने के लिए सभी प्रशासनिक कार्यों जैसे अनुसूचित सर्वर रिबूट को उचित प्रशासक (हमारे मामले पर सिस्टम प्रशासक) द्वारा किए जाने की आवश्यकता है।

मैं दोनों sysadmins और Oracle DBAs से इनपुट चाहूंगा - क्या Oracle DBA के लिए प्रोडक्शन के माहौल में जड़ तक पहुँचने का कोई अच्छा कारण है ?

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

मैं पेशेवरों / विपक्षों की तलाश नहीं कर रहा हूं, बल्कि इस स्थिति से निपटने के लिए मुझे कैसे सलाह लेनी चाहिए, इस पर सलाह दे रहा हूं।


12
उसके बाद केवल उन कमांड को अनुमति देने के लिए अपनी sudoers फ़ाइल को दर्ज़ करने के लिए उसे अपनी ज़रूरतों की सूची के लिए पूछें।
dmourati

मैं कहता हूं कि सुडोलर्स रास्ता, जैसा कि ऊपर सुझाया गया है, स्पष्ट रूप से सही तरीका है।
सामी लाईन

मैं sudo का उपयोग नहीं करूंगा, यह एक प्रतिबंधित एक्सेस और नियंत्रित संवेदनशील सर्वर है, मैं इसे POSIX राइट्स और Chrooted / सीमित प्रॉम्प्ट शेल का उपयोग करके कठिन तरीके से करूँगा।
डॉ।

एक sysadmin के रूप में IMHO मैं हमेशा sudoers के साथ जाता हूं और जहां तक ​​संभव हो पहुंच को प्रतिबंधित करता हूं। नंगे न्यूनतम के साथ शुरू करने के लिए बेहतर है और फिर आवश्यकतानुसार कमांड को एक्सेस जोड़ें। +1 @ ममौरती
sgtbeano

7
आपके DBA को रूट पासवर्ड की उतनी ही आवश्यकता है जितनी की आपको SYSDBAपहुँच की आवश्यकता है ।
माइकल हैम्पटन

जवाबों:


14
  • सर्वर पर ओरेकल कौन स्थापित करता है?
    यदि यह डीबीए है, तो उन्हें रूट एक्सेस की आवश्यकता है। यदि यह sysadmin है, तो DBA नहीं है।

  • डेटाबेस सर्वर डाउन होने पर देर रात किसे कहा जाता है?
    यदि आप यह सुनिश्चित नहीं कर सकते कि sysadmins 24/7 उपलब्ध हैं तो आप DBA को रूट एक्सेस देना चाह सकते हैं।

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

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


3
आप sudoरूट एक्सेस देने के बजाय sudo नियमों का उपयोग और मान्य कर सकते हैं ।
jirib

3
@ जिरी:% dba ALL = (ALL) ALL in / etc / sudoers जैसा कुछ होना वास्तव में रूट एक्सेस दे रहा है। Dba के लिए कमांड के एक प्रतिबंधित सेट को सूचीबद्ध करना जिसे मैं "नियमित शेल एक्सेस" कहता हूं।

2
ओरेकल + डॉकटर आपदा के लिए एक नुस्खा की तरह लगता है। सूडो को अनुमति नहीं है? लगता है कि जो कोई भी पर्यावरण को प्रतिबंधित कर रहा है उसे पता नहीं है कि वे क्या कर रहे हैं।
dmourati

4
@DrI निकाला जा रहा है sudoऔर लोगों को अप्रतिबंधित रूट पहुँच दे रही है एक बहुत बड़ा कदम है पीछे की ओर सिस्टम सुरक्षा में। अगर आपकी बॉस की बातें sudo"गूढ़ तकनीक" हैं, तो मैं फ्रैंक हो जाऊंगा ।
voretaq7

1
@ voretaq7 मैं जानता हूं कि, लेकिन जैसा कि मैंने पहले ही कहा था, मैं एक बड़े निगम के लिए काम कर रहा हूं, खुद नहीं, इसलिए मैं अपने आईटी के हर पहलू को नहीं संभालता हूं और मुझे अपने टूल से निपटना पड़ता है ;-) मेरा मुख्य सवाल संबंधित था; डीबीए की जड़ तक पहुँच के लिए NEEDS की आवश्यकता होती है, और अधिकांश लोग इसके विपरीत सोचते हैं, इसलिए मैं उसकी ज़रूरतों के बारे में futhermerm की जाँच करता हूँ ;-) और फिर उसके साथ एक समझौता की हुई स्थिति के लिए सौदा करता हूँ।
डॉ। १

6

डीबीए के लिए सामान्य तौर पर और विशिष्ट नहीं है - जो rootकोई वैध कारण बताए बिना पहुंच की मांग करता है:

  1. कोई है जो नहीं जानता कि वे क्या कर रहे हैं।
  2. अभिमानी और असहयोगी।
  3. ऊपर के दोनों।

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

ऐसे मामलों में जहां मुझे इस तरह के लोगों के साथ झगड़ा करना पड़ा है, मैंने जोर देकर कहा है कि समय से पहले समय निर्धारित किया जाए ताकि मैं उनके साथ सर्वर पर हो सकता हूं कि वे मुद्दों को संभाल सकें क्योंकि वे उत्पन्न होते हैं। और यह वास्तव में अच्छी तरह से काम किया है।

एक अन्य विकल्प- जो कि व्यावहारिक नहीं हो सकता है - यह है कि प्रश्न में सर्वर का एक सटीक क्लोन बनाना और rootउस पर उनकी पहुँच देना । निश्चित रूप से उनके लिए कुछ विशिष्ट पासवर्ड बदलने के लिए सुनिश्चित करें। उन्हें एक पृथक विकास बॉक्स को उड़ाने दें।

लेकिन सामान्य तौर पर, यदि आप वह हैं जो देर रात को फोन किया जाता है कि यह गंदगी पैदा हो सकती है, तो आप इसे प्राप्त करने के लिए कंबल अनुरोध नहीं करने का अधिकार रखते हैं root


4

सैद्धांतिक रूप से डीबीए रूट प्राइवेट के बिना काम कर सकता है, लेकिन यह दोनों पक्षों के लिए पीटा है। के माध्यम से सुलभ होने के लिए कमांड की सूची को परिभाषित करना व्यावहारिक रूप से असंभव है sudo

डीबीए को मूल निजी दें यदि:

  • आप केवल सर्वर को रिबूट करने के लिए रात के बीच में जागना नहीं चाहते हैं
  • आप त्वरित और सुचारू घटना प्रबंधन चाहते हैं
  • यदि आपका विचलन केवल डीबी सर्वर के लिए समर्पित है

DBA को हमारे लिए मूल निजी चाहिए: कर्नेल पैरामीटर समायोजन (sysctl), भंडारण हेरफेर, समस्या जांच।

उचित ऑडिशनिंग सुरक्षा नियमों को सख्ती से परिभाषित करने की तुलना में बेहतर रन की स्थिति सुनिश्चित करते हैं। यदि आपके पास ऑडिटिंग लागू है, तो आप हमेशा पूछ सकते हैं कि उन्होंने कुछ क्यों किया / बदल दिया। यदि आपके पास ऑडिटिंग नहीं है, तो आपके पास वैसे भी सुरक्षा नहीं है।

संपादित

यह स्टैंडअलोन पर सामान्य ओरेकल आवश्यकताओं की एक सूची है (गैर-संकुल अधिष्ठापन)

  • कर्नेल पैरामीटर

    • मेमोरी संबंधी (बड़े / विशाल पृष्ठ कॉन्फ़िगरेशन, साझा किए गए RAM (ipcs), गैर-स्वैप करने योग्य (लॉक किए गए) RAM)
    • संबंधित नेटवर्क (खिड़की का आकार भेजने, प्राप्त करने, टीसीपी रखने)
    • भंडारण से संबंधित (खुली फ़ाइलों की संख्या, I

    लगभग 15-20 sysctl पैरामीटर हो सकते हैं। उनमें से प्रत्येक के लिए ओरेकल एक अनुशंसित मूल्य या एक समीकरण प्रदान करता है। कुछ मापदंडों के लिए अनुशंसित समीकरण समय (aync io) में बदल सकता है या कुछ मामलों में Oracle उसी पैरामीटर के लिए एक से अधिक समीकरण प्रदान करता है।

  • भंडारण: लिनक्स udev नियम बूट लगातार डिवाइस नामों की गारंटी नहीं देते हैं। इसलिए ओरेकल ने कर्नेल ड्राइवर और टूल (AsmLib) प्रदान किए। ये आपको रूट के रूप में भौतिक विभाजन के "ना" लेबल की अनुमति देता है और फिर डेटाबेस स्टोरेज को प्रशासित करते समय आप इन लेबल को देख सकते हैं
  • समस्या की जांच:
    • जब डेटाबेस क्रैश हो जाता है क्योंकि यह अधिक फ़ाइल हैंडल नहीं खोल सकता है, तो एकमात्र समाधान कर्नेल सीमा को बढ़ाना है, 'sysctl -p' निष्पादित करें और फिर DB शुरू करें।
    • इसके अलावा जब आप पाते हैं कि भौतिक रैम बहुत अधिक खंडित है और डेटाबेस बड़े पृष्ठों को आवंटित नहीं कर सकता है, तो सर्वर को रिबूट करने का एकमात्र विकल्प है।
    • (डीसीडी) - मृत कनेक्शन का पता लगाना। उदाहरण के लिए AIX नेटस्टैट PID को प्रिंट नहीं करता है। PID के साथ TCP कनेक्शन को जोड़ने का एकमात्र तरीका कर्नेल डीबगर है।
    • नज़र (एचपी-यूएक्स पर शीर्ष की तरह) को रूट प्राइवेट की आवश्यकता होती है
    • विभिन्न वेरिटास स्तर की जांच
    • और कई अन्य

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


4
यह उत्पादन सर्वरों को रिबूट करने के लिए डीबीए की भूमिका नहीं है, उत्पादन सर्वर के कर्नेल पैरामीटर को ट्विक करता है, उत्पादन सर्वर भंडारण में हेरफेर करता है, आदि उसकी भूमिका यह परिभाषित करने के लिए है कि उत्पादन सर्वर को कैसे कॉन्फ़िगर किया जाना चाहिए और कार्यान्वयन कार्य को sysadmins को करने देना चाहिए। इंसिडेंट मैनेजमेंट जो प्रोडक्शन सर्वर को प्रभावित करता है, उसे हमेशा sysadmin पर जाना चाहिए, dba से नहीं।
स्टीफन

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

2
@ स्टेफेन ओरेकल इस मामले में बहुत विशिष्ट है। यह kernels के लिए आवश्यकताएं हैं ट्यूनाबल्स गैर-तुच्छ हो सकते हैं, यह स्वयं LVM है (ASM कहा जाता है) और Oracle RAC के मामले में इसके अलावा यह कुछ है CLusterwares रूट निजी के साथ चलता है और यह भंडारण और NIC में भी हेरफेर करता है। कभी-कभी DBA को vxdisk resizeकमांड निष्पादित करना आसान होता है, फिर रात के मध्य में ईमेल पिंग-पोंग खेलते हैं। यह विश्वास और ऑडिटिंग के बारे में और फिर "सुरक्षा" के बारे में है।
ibre5041

ओरेकल एक स्टीमिंग पाइल है। सबसे अच्छे डॉक्स हैं: puschitz.com
dmourati

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

1

मैं ओरेकल डीबीए हूं और मेरा जवाब है, आमतौर पर डीबीए को रूट एक्सेस की आवश्यकता नहीं है। लेकिन एक आरएसी डीबीए? निश्चित रूप से उसे सीआरएस, हाउस कीपिंग और सभी का प्रबंधन करने के लिए रूट एक्सेस की आवश्यकता है।


0

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

हमारे आरएसी डेटाबेस सिस्टम के साथ समस्याओं के लिए "उच्च उपलब्धता" और "तत्काल सुधारात्मक" के लिए आज की मांग के साथ, सिस्टम प्रशासक और डेटाबेस प्रशासक अपने कार्यात्मक व्यापारिक समुदायों की सेवा करते हैं, एक टीम के रूप में एक साथ काम करते हैं। "विश्वास" के साथ कोई चिंता नहीं होनी चाहिए, क्योंकि दोनों पक्षों का आरएसी डेटाबेस सर्वर को 100% समय के पास ऑन-लाइन रखने में निहित स्वार्थ है। ध्यान में रखते हुए, DBA के पास पहले से ही एक डेटाबेस एडमिनिस्ट्रेटर के रूप में शेल एक्सेस है (कुछ कमांड्स के साथ या बिना वह sudo के माध्यम से चला सकता है; या बिना chrooted जा रहा है), इसलिए स्पष्ट रूप से th DBA एक "विश्वसनीय" एजेंट है। तो, वास्तव में सवाल यह होना चाहिए, "ओरेकल डीबीए की आवश्यकता क्यों नहीं है?"

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

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


0

यदि सर्वर Oracle ग्रिड इन्फ्रास्ट्रक्चर सॉफ़्टवेयर जैसे CRS, RAC या Oracle Restart का उपयोग करते हैं, तो कई महत्वपूर्ण डेटाबेस सेवाएँ रूट के रूप में चलती हैं, और कई महत्वपूर्ण डेटाबेस कॉन्फ़िगरेशन फ़ाइल रूट के स्वामित्व में हैं। यह सॉफ्टवेयर की एक अंतर्निहित डिजाइन विशेषता है। यदि यह आपकी नीतियों का उल्लंघन है तो नीतियों को संशोधित करने की आवश्यकता है।

इन सुविधाओं को प्रबंधित करने के लिए DBA को रूट एक्सेस की आवश्यकता होगी। सैद्धांतिक रूप से आप उनसे आज्ञाओं की एक सूची के लिए पूछ सकते हैं जो वह सूडो में प्रवेश करने के लिए चलाने की उम्मीद करेंगे, लेकिन जवाब बहुत लंबी सूची होगी। बस उन सभी बायनेरिज़ की सूची के लिए $ GRID_HOME / bin में एक नज़र डालें जिन्हें DBA नियमित आधार पर उपयोग कर सकता है। यदि वे पैचिंग गतिविधियाँ कर रहे हैं (जो उन्हें होनी चाहिए) तो सूची और भी लंबी हो सकती है।


0

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

लेकिन अगर यह कारण है, तो डीबीए भी केवल और केवल सिसडमिन होना चाहिए। और इसका कारण सरल है। यदि जवाबदेही और जिम्मेदारी को अलग करने की आवश्यकता है, तो sysadmin भी DBA हो सकता है। वह ओरेकल अकाउंट को इंप्रूव कर सकता है, वह SYSDBA के रूप में डेटाबेस में प्रवेश कर सकता है और SYS या सिस्टम पासवर्ड की आवश्यकता के बिना, जो कुछ भी कर सकता है।

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

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

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


0

Oracle ग्रिड इंस्टॉलेशन और पैचिंग के लिए रूट एक्सेस आवश्यक है। इसके आसपास कोई रास्ता नहीं है। अगर ऐसी जरूरतों के लिए DBA को अस्थायी रूट एक्सेस देने का कोई तरीका होता, तो यह आदर्श होता।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.