डेवलपर के लैपटॉप पर एक महत्वपूर्ण डेटाबेस को संग्रहीत करने के लिए एक अच्छा सुरक्षा अभ्यास क्या है?

33

हमारे पास कुछ गिवेन हैं:

डेवलपर्स को अपनी मशीनों पर उत्पादन डेटाबेस की प्रतिकृति की आवश्यकता होती है।
डेवलपर्स के पास App.config फाइलों में उक्त डेटाबेस का पासवर्ड है।
हम उक्त डेटाबेस में डेटा समझौता नहीं चाहते हैं।

कुछ सुझाए गए समाधान और उनकी कमियां:

पूर्ण डिस्क एन्क्रिप्शन। यह सभी समस्याओं को हल करता है, लेकिन लैपटॉप के प्रदर्शन को नीचा दिखाता है, और हम एक स्टार्ट-अप हैं, इसलिए पॉवरहॉर्स के लिए पैसा नहीं है।
एन्क्रिप्टेड हार्ड डिस्क के साथ एक वीएम बनाना, और उस पर डेटाबेस को स्टोर करें। यह अच्छी तरह से काम करता है, लेकिन यह बहुत ज्यादा मदद नहीं करता है, क्योंकि Web.Config में एक पासवर्ड है।
समाधान नंबर 2 + डेवलपर को हर बार कुछ भी चलाने पर डेटाबेस पासवर्ड टाइप करने की आवश्यकता होती है। यह सभी समस्याओं को हल करता है, लेकिन यह डेवलपर्स के लिए वास्तव में बोझिल है जो कभी-कभी एक मिनट में कई बार आवेदन को आग लगा देता है। इसके अलावा, हमारे पास कई एप्लिकेशन हैं जो एक ही डेटाबेस से जुड़ते हैं, और पासवर्ड स्क्रीन के कार्यान्वयन को प्रत्येक में अलग-अलग करना होगा।

तो, मेरा सवाल है, अगर इस तरह की समस्या का कोई आम समाधान है, या उपरोक्त समाधानों में से किसी को कैसे कारगर बनाने के लिए कोई सुझाव है?

database security

— Svarog
स्रोत

26

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

— 5gon12eder

69

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

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

2

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

— Svarog

6

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

— gnasher729

5

मैं दूसरी @ gnasher729 की टिप्पणी। विनियमित वातावरण (वित्तीय और स्वास्थ्य देखभाल) में कई वर्षों तक पूर्ण डिस्क एन्क्रिप्शन का उपयोग करने के बाद इसे प्रदर्शन पर ध्यान देने योग्य नाली नहीं होना पड़ता है। बहुत से लोग अन्य मान्य बिंदुओं को लाते हैं, लेकिन एक HIPAA वातावरण में पूर्ण डिस्क एन्क्रिप्शन के बिना एक उचित नीति रखना मुश्किल है, भले ही डेटाबेस को नोटबुक पर नहीं रखा गया हो। ईमेल और डेटा के अन्य टुकड़े अक्सर वहाँ वैसे भी हवा देते हैं। स्वैप फ़ाइलें .... आदि ... पूर्ण डिस्क एन्क्रिप्शन पर्याप्त नहीं है, लेकिन यह आमतौर पर आवश्यक है।

— joshp

100

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

यदि आपको परीक्षण के लिए उत्पादन-स्केल डेटा की आवश्यकता है, तो आपके पास कुछ विकल्प हैं:

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

विकल्प # 2 के लिए

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

— कॉर्बिन मार्च
स्रोत

31

और डेटाबेस कॉपी का पासवर्ड उत्पादन संस्करण के लिए समान नहीं होना चाहिए .....

— मोनिका के साथ लाइटनेस दौड़

3

"उदाहरण के लिए, अमेरिका में, आप उत्पादन डेटा को उत्पादन वातावरण से बाहर स्थानांतरित नहीं कर सकते हैं यदि इसमें विनियमित जानकारी शामिल है" क्या? क्या इसके लिए आपके पास स्रोत है? क्या आप, उदाहरण के लिए, स्टेजिंग वातावरण के लिए डेटा के रूप में, या डेवलपर मशीनों पर परीक्षण डेब्स के रूप में उत्पादन डेटाबेस के बैकअप का उपयोग नहीं कर सकते हैं?

— नानी

12

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

— कॉर्बिन मार्च

4

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

— कॉर्बिन मार्च

5

कड़ाई से बोलना, जब तक आप सरकारी काम नहीं कर रहे हैं, तब तक PPI के साथ लापरवाही करना ILLEGAL नहीं है, तब शीर्षक 32 खेल में आता है ... लेकिन यह एक गंभीर नागरिक दायित्व जोखिम है। यह अन्यथा एक महान जवाब है। upvoted।

— dwoz

9

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

— ब्रायन नॉब्लुच
स्रोत

यह एक टिप्पणी की तरह अधिक पढ़ता है, देखें कैसे जवाब दें

— gnat

5

@gnat, यह जवाब छोटा हो सकता है लेकिन यह एक बहुत अच्छा सुझाव दिया गया विकल्प है।

इस तरह के एक पेडेंट मत बनो, @gnat ... यह एक अच्छा जवाब है।

— dwoz

@ dan1111 यही समस्या है। इसका जवाब नहीं है। यह एक विकल्प है। यह एक टिप्पणी है, एक जवाब नहीं है।

— corsiKa

2

@corsiKa, सवाल के आधार को चुनौती देने वाले उत्तरों की अनुमति है और अक्सर बहुत अच्छे उत्तर होते हैं। XY समस्या देखें: meta.stackexchange.com/questions/66377/what-is-the-xy-problem । और अधिक विस्तृत उत्तर बेहतर हो सकते हैं, लेकिन यह अभी भी एक उत्तर है।

8

यदि संभव हो तो अपना काम करने का तरीका बदलें।

जैसा कि दूसरों ने बताया है:

विकास के लिए उत्पादन डेटा का उपयोग करना अच्छा अभ्यास नहीं है।
सादे पाठ में संग्रहीत पासवर्ड होना अच्छा अभ्यास नहीं है।

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

वास्तविक दुनिया में, हालांकि, इसे बदलना संभव नहीं है। यह मानते हुए कि आप जो कर रहे हैं वह कानूनी है, आपको इस व्यवस्था के साथ (कम से कम अस्थायी रूप से) रहना पड़ सकता है।

यदि यह वास्तव में आवश्यक है, तो आपको केवल पूर्ण-डिस्क एन्क्रिप्शन करने की आवश्यकता है।

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

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

1

"एक आदर्श समाधान नहीं" को "पूरी तरह से मूर्ख विचार" के लिए बदल दिया जाना चाहिए "IMO

— Darkhogg

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

मैं पहले बिंदु से सहमत हूं, लेकिन दूसरे से नहीं। यदि आप अपने पासवर्ड को प्लेनटेक्स्ट में स्टोर नहीं कर रहे हैं, तो आप इसे (1) सिफरटेक्स्ट या (2) अपने मस्तिष्क को कहाँ स्टोर कर रहे हैं। यदि (1) तो आप साइफर के लिए पासवर्ड कहाँ संग्रहीत कर रहे हैं (अनंत लूप का पता चला)। यदि (2), तो मुझे आशा है कि आप सेवा को पुनः आरंभ करने के लिए पासवर्ड में टाइप करने के लिए 2:00 बजे जागना पसंद करेंगे।

— एमरी

1

कॉर्बिन मार्च का जवाब बहुत अच्छा है, मैं बस एक अतिरिक्त विवरण जोड़ूंगा, कि आपके पास आमतौर पर आपके उत्पादन डेटाबेस में डेटा के दो वर्ग हैं: सिस्टम / एप्लिकेशन मेटाडेटा; और ग्राहक उपयोगकर्ता डेटा / लेनदेन डेटा। यह बाद में कभी भी विकास के माहौल में उपयोग नहीं किया जाना चाहिए "जैसा है।"

यह वास्तव में बहुत दुर्लभ है कि आपको विकास करने के लिए वास्तविक उत्पादन ग्राहक जानकारी की आवश्यकता है।

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

— dwoz
स्रोत

5

client user data/transactional data... should NEVER be used in a development environment "as is." - यह मुझे अटूट लगता है। उत्पादन-संबंधी प्रोग्रामिंग समस्याएँ जो एक विशिष्ट ग्राहक के डेटा के साथ होती हैं, इस व्यवस्था के तहत असाध्य होगी। इसके अलावा, वास्तविक लाइव डेटा परीक्षण के दृष्टिकोण से अत्यंत उपयोगी है। निजीकरण या गुमनामी प्रयास को केवल उस डेटा पर केंद्रित किया जाना चाहिए जो विशेष रूप से विनियमित है।

— रॉबर्ट हार्वे

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

— dwoz

4

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

— रॉबर्ट हार्वे

1

NEVER के लिए -1। आपके उत्तर की तुलना में आपकी अधिक सूक्ष्म टिप्पणियाँ बेहतर हैं; आपको उन्हें इसमें संपादित करना चाहिए।

1

@ dan1111 हम तब असहमत हो सकते हैं। ग्राहक डेटा "जैसा है" को कभी भी देव प्रणालियों में उपयोग नहीं किया जाना चाहिए। इसे हमेशा साफ रखना चाहिए। आप इस पर विश्वास नहीं करते हैं क्योंकि आप अभी तक इस पागल mongoose द्वारा काट नहीं लिया गया है ... और यह तब होता है, जब यह होता है। एक पागल पागल कृंतक जो आपके रक्त को खींचने का इरादा रखता है। मेरी सलाह ले, रबिड मोंगोसे से बचें।

— dwoz

1

आप यह नहीं बता सकते हैं कि कौन सा डेटाबेस और कौन सा वातावरण।

यदि आप एकीकृत सुरक्षा का उपयोग कर सकते हैं तो डेटाबेस उस उपयोगकर्ता के रूप में लॉग किए बिना सुलभ नहीं है। हां अगर डेटा हार्ड डिस्क पर है तो उसे हैक किया जा सकता है लेकिन यह एक प्रथम स्तर का बचाव है।

App.config को लगता है कि यह एक .NET हो सकता है। एक अंगूठे ड्राइव में विन्यास रखो और इसे अंगूठे ड्राइव से पढ़ें। अगर ड्राइव मौजूद नहीं है तो पासवर्ड में यूजर टाइप करें।

क्या पासवर्ड को मेमोरी में स्टोर करने का एक तरीका है जब यह पहली बार दर्ज किया गया है और सभी द्वारा पढ़ा गया है। फिर से आप पर्यावरण का वर्णन नहीं करते हैं। मेमोरी-मैप्ड फ़ाइलें

कुछ TDE के साथ आप कुंजी को एक अलग डिवाइस पर संग्रहीत कर सकते हैं ताकि वे डेटाबेस की शुरुआत होने पर कुंजी की आपूर्ति करें।

— paparazzo
स्रोत

0

एक संभावित विकल्प डेटाबेस की एक प्रतिलिपि बनाना है और एक स्क्रिप्ट के साथ कॉपी करना है ताकि आप अलग-अलग डेटा के साथ समाप्त हो सकें जो वास्तव में उत्पादन में है। आप उत्पादन के समान डेटा के साथ समाप्त नहीं होंगे, लेकिन आपके पास समान पैमाने होंगे।

— जेसन क्रॉस्बी
स्रोत

यह केवल दोहराने के लिए बनाया गया लगता है और समझाया गया है एक हफ्ते पहले किया गया शीर्ष उत्तर में गया है

— gnat