मैं उत्पादन डेटाबेस के साथ गलती से जैकिंग कैसे रोक सकता हूं?


31

अभी हाल ही में, मेरे पास एक डेवलपर गलती से उत्पादन के लिए एक डेटाबेस को बहाल करने की कोशिश कर रहा था, जब उसे एक स्टेजिंग कॉपी को पुनर्स्थापित करना चाहिए था। यह करना आसान है, यह देखते हुए कि db नाम समान हैं, अर्थात, CustomerName_Staging बनाम CustomerName_Production।

आदर्श रूप से, मेरे पास ये पूरी तरह से अलग बक्से पर होंगे, लेकिन यह निषेधात्मक है, और, कड़ाई से बोलना, यह उसी चीज को होने से नहीं रोकता है यदि उपयोगकर्ता गलत बॉक्स से जोड़ता है।

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

मैं इसे रोकने के तरीके पर अभ्यास, विन्यास और नियंत्रण के संदर्भ में कुछ सलाह सुनना पसंद करूंगा।


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

12
@ मिचेल हैम्पटन - यह मैं और वह। मैं भी एक डेवलपर हूँ। आपकी क्या सलाह है?
क्रिस बी। 21

10
प्रत्येक भूमिका के लिए अलग उपयोगकर्ता खाते (देव बनाम ऑप्स / डीबीए)। और सावधानी की एक बहुतायत।
माइकल हैम्पटन

2
मैं दृढ़ता से सलाह दूंगा कि आपके पास एक अलग बॉक्स पर अपने उत्पादन का माहौल है। अन्यथा स्टेजिंग और प्रोडक्शन में संसाधनों को साझा करना होता है - डिस्क, सीपीयू, आदि - और यदि स्टेजिंग एक संसाधन का एकाधिकार कर रहा है तो आपके उत्पादन पर्यावरण को नुकसान हो सकता है।
थोरबजोरन राव एंडरसन

1
बस उन डेटाबेस के लिए अलग उपयोगकर्ता / पासवर्ड है।
न्यूट्रिनस

जवाबों:


32

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

  • सत्यापित करें कि आप सही सर्वर पर पुनर्स्थापित कर रहे हैं (यानी कोई देव -> ठेस पुनर्स्थापित करता है)
  • सत्यापित करें कि यह डेटाबेस का सही "प्रकार" है (आपके मामले में, "स्टेजिंग" और "प्रोडक्शन")
  • एमएसडीबी में बैकअप तालिकाओं को देखकर स्वचालित रूप से पुनर्स्थापित करने के लिए कौन से बैकअप का पता लगाएं

Et cetera। आप केवल अपनी कल्पना द्वारा सीमित हैं।


1
यह एक दिलचस्प विचार है ... हमारे पास पहले से ही कोड है जो DB restores (स्वचालित परीक्षण के लिए) का प्रबंधन करता है। हम बीच में एक अमूर्त परत डाल सकते हैं जो केवल कभी मंचन पर इंगित करता है ताकि उत्पादन को बहाल करना एक पूरी तरह से अलग प्रक्रिया थी ...
क्रिस बी। बेहरेंस

11
अब आप पोर्टल्स के साथ सोच रहे हैं। :)
बेन थुल

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

2
मुझे लगता है कि किसी को भी डिफ़ॉल्ट रूप से उत्पादन तक पहुंच नहीं होनी चाहिए। एक ठेस पासवर्ड को पुनः प्राप्त करने के लिए आपके पास एक विशेष प्रक्रिया होनी चाहिए। यह असुविधाजनक है लेकिन वास्तव में न्यूनतम है।
ओलिवर

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

32

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

आप गलती से उत्पादन के लिए कुछ भी करने में सक्षम नहीं होना चाहिए !

जिसमें गलती से स्वचालित चीजें करना शामिल है।

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

आपको अपने वर्कफ़्लो को छाँटकर शुरू करना होगा।

  • आपके डेवलपर खाते अपनी प्रतियां, संस्करण नियंत्रण और शायद परीक्षण नियंत्रण में संस्करण नियंत्रण से खींचने के लिए लिखने में सक्षम होना चाहिए।

  • बैकअप उपयोगकर्ताओं को केवल उत्पादन से पढ़ने और अपने बैकअप स्टोर पर लिखने में सक्षम होना चाहिए (जिसे उपयुक्त रूप से संरक्षित किया जाना चाहिए)।

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

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

स्वचालन समाधान का हिस्सा है।

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

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

लेकिन अकेले , स्वचालन बेकार से भी बदतर है। यह आपको कम विचार के साथ बड़ी गलतियाँ करने में मदद करेगा।

सभी आकारों की टीमों के लिए उपयुक्त।

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


2
इसके अलावा, एक चीज जो मुझे करना पसंद है वह है प्रति उपयोगकर्ता दो नामित खातों का उपयोग करना। एक सामान्य उपयोगकर्ता लॉगिन, संचालन, दिन के काम करने के लिए दिन, आदि के लिए है, जबकि दूसरा खाता (आमतौर पर + या अंडरस्कोर जैसे किसी तरह के प्रत्यय के साथ) को उपयोगकर्ता के लिए आवश्यक अधिकार और देवता के पूर्ण अधिकार होते हैं। इस तरह, उपयोगकर्ता को देव के विपरीत ठेस पहुंचाने के लिए एक सक्रिय निर्णय लेना चाहिए। यह ऊपर वर्णित बुलेट 3 के समान है, लेकिन मूल्य को प्रदर्शित करने के लिए महत्वपूर्ण अतिरिक्त बुनियादी ढांचे या खर्च की आवश्यकता नहीं है।
user24313

3
यह कुछ भी करने की आदत से बचने के लिए महत्वपूर्ण है, लेकिन आपके ठेस खाते में रखरखाव करना। उस अंत तक, सुनिश्चित करें कि ठेस स्रोत कोड नहीं देख सकते हैं, आईडीई शुरू नहीं कर सकते हैं, आदि
एरिक लॉयड

मुझे उनमें से एक साथ-साथ दोहरे कुंजी के उल्लंघन कहां से मिलते हैं और क्या यह यूएसबी के साथ आता है?
लीलिएन्थल

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

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

12

मेरे सहकर्मियों में से एक के लिए एक दिलचस्प दृष्टिकोण है। उत्पादन के लिए उनकी टर्मिनल कलर स्कीम फगली है । ग्रे और गुलाबी और पढ़ने में कठिन, जो सैद्धांतिक रूप से यह सुनिश्चित करने के लिए माना जाता है कि वह जो कुछ भी लिखता है, वह वास्तव में लिखने का इरादा रखता है।

आपका माइलेज अलग-अलग हो सकता है ... और मुझे शायद यह कहने की ज़रूरत नहीं है कि यह मुश्किल से ही बुलेटप्रूफ है। :)


2
मैं उत्पादन सर्वरों के लिए टर्मिनलों / डीबी कनेक्शनों पर एक बड़े लाल पृष्ठभूमि रंग का उपयोग करता हूं, साथ ही पीसी पर व्यवस्थापक-प्रशंसा के लिए उज्ज्वल लाल वॉलपेपर ...
फाल्को

हाँ, मैं यही सोच रहा था। प्रोडक्शन फायर इंजन को लाल करें ...
क्रिस बी।

कलर कोडिंग से मदद मिलती है। जिस तरह एक आई.डी.ई.
थोरबजोरन राव एंडरसन

1

डेवलपर्स को उत्पादन डेटाबेस का पासवर्ड नहीं पता होना चाहिए। ठेस पासवर्ड यादृच्छिक होना चाहिए और यादगार नहीं होना चाहिए - कीबोर्ड मैशिंग ( Z^kC83N*(#$Hx) के परिणामस्वरूप कुछ । आपका देव पासवर्ड हो सकता है $YourDog'sNameया correct horse battery stapleया जो कुछ भी।

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

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


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

1
@ फाल्को यह वही है जो मैं हालांकि सुझाव दे रहा हूं। असुविधाजनक लेकिन व्यवहार्य।
200_सेकंड

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

2
@Falco चूंकि वायुमंडल के वातावरण को देव वातावरणों को निकट से देखना चाहिए, इसलिए विन्यास फाइल को ठंढे सर्वर पर समान स्थान पर होना चाहिए क्योंकि यह देव मशीनों पर है। किसी भी सक्षम डेवलपर को पता होना चाहिए कि कहां देखना है, और अगर वे नहीं जानते कि कहां देखना है, तो आप चाहते हैं कि देरी - सवाल में बताए गए प्रकार के नुकसान को रोकने के लिए।
२०० से २०

पासवर्ड न जानना दुर्घटनाओं में बाधा नहीं बनता है। इसके विपरीत, यह केवल एक बार केवल पासवर्ड लुकअप करने के लिए प्रेरणा बनाता है, और उसके बाद डेवलपर बैश इतिहास का उपयोग करना शुरू कर सकता है या डेटाबेस से जुड़ने के लिए एक उपनाम भी बना सकता है। और फिर, दुर्घटनाएं होने की अधिक संभावना है।
k0pernikus

0

संक्षिप्त उत्तर RBAC - भूमिका-आधारित अभिगम नियंत्रण है।

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

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

क्या यह कष्टप्रद है? पूर्ण रूप से। लेकिन क्या यह [सहायता] आपके वातावरण को खराब करने से रोकता है? पूर्ण रूप से।


0

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

एक ही दृष्टिकोण का उपयोग किया जा सकता है यदि आपके पास दो वेबसाइटें हैं, या दो सर्वर हैं, या दो पूरे वातावरण हैं: एक उपयोगकर्ता के पास विकास के लिए कोई पहुंच नहीं है (या कम से कम कोई लेखन नहीं है ), उत्पादन प्रणाली पर काम करने के लिए एक और उपयोगकर्ता खाता ( रों)।


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

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