कोई केंद्रीय डेटाबेस नहीं


31

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

मैं ऐसा करने का एक अच्छा, विश्वसनीय तरीका नहीं सोच सकता और मुझे यकीन नहीं है कि कोई एक है। जिसके कारण मैं यहां हूं। क्या किसी को पता है कि मैं इस डेटा से कैसे निपट सकता हूं?

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


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

2
क्या यह सहकर्मी से सहकर्मी की समस्या है? या सिर्फ 1 डेस्कटॉप 1 स्मार्ट फोन (प्रत्येक डेटा स्पेस के लिए) से बात कर रहा है?
ebyrob

7
आप एक कुंजी के साथ सर्वर पर डेटा एन्क्रिप्ट करके डेटाबेस में गोपनीयता सुनिश्चित कर सकते हैं जो केवल उपयोगकर्ता के लिए जाना जाता है।
फिलीपींस

26
यह एक ऐसी योजना की तरह लगता है जिसे कोई व्यक्ति सुरक्षा के बारे में नहीं समझता है। जो कोई भी इस आवश्यकता के साथ आया था, उसे Security.SE पर डेटा सुरक्षित करने के बारे में एक प्रश्न तैयार करना चाहिए ।
jpmc26

4
@ user2424495: यदि डेटा को किसी वेबसाइट के माध्यम से उपलब्ध कराने की आवश्यकता है, तो डेटा उपलब्ध होना चाहिए जहां आपकी वेबसाइट से सेवा की जाती है - जो आमतौर पर एक केंद्रीय सर्वर है। या आपको एक ब्राउज़र प्लगइन लिखना होगा जो डेटा क्लाइंट-साइड की आपूर्ति करता है।
बरगी

जवाबों:


60

बहुत सारी संवेदनशील जानकारी डेटाबेस में जमा हो जाती है। वास्तव में, एक केंद्रीय डेटाबेस शायद इस डेटा को संग्रहीत करने का सबसे सुरक्षित तरीका है। बड़े एंटरप्राइज़ डेटाबेस में एन्क्रिप्टेड संवेदनशील जानकारी जैसी चीज़ों को करने के लिए कार्यक्षमता होती है, जो ऑडिट करने के लिए होती है, जो इसे एक्सेस करता है, डेटा को देखने से DBA सहित लोगों को सीमित करने या रोकने के लिए, आदि। आप पेशेवर सुरक्षा विशेषज्ञ पर्यावरण की निगरानी कर सकते हैं और पेशेवर DBAs बैकअप की देखरेख कर सकते हैं। कि आप डेटा खोना नहीं है। लगभग निश्चित रूप से कुछ यादृच्छिक उपयोगकर्ता के मोबाइल डिवाइस या लैपटॉप पर संग्रहीत डेटा को अच्छी तरह से डिज़ाइन किए गए सुरक्षा ढांचे में घुसना और एक उचित केंद्रीय डेटाबेस से समझौता करना बहुत आसान होगा।

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


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

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

2
@mrr यदि डेटाबेस केवल एन्क्रिप्टेड डेटा (डिवाइस को छोड़ने से पहले एन्क्रिप्ट किया गया) संग्रहीत करता है, तो इससे कोई फर्क नहीं पड़ता कि अदालत का आदेश क्या कहता है, यह भौतिक रूप से एन्क्रिप्शन कुंजी के बिना डिक्रिप्ट नहीं किया जा सकता है, जो केवल उपयोगकर्ता के पास है।
रिचर्ड टिंगल

9
@RichardTingle <tinfoil> जब तक नहीं कहा गया कि सरकारी एजेंसी ने एन्क्रिप्शन को पहले ही तोड़ दिया है। </ tinfoil>
Bob

3
मैंने कभी नहीं कहा कि समस्या "दिलचस्प" नहीं थी, मैं अब तक बहुत पेचीदा और सोचा उत्तेजक सवाल और जवाब ढूंढता हूं। यह वास्तव में इस साइट को महान बनाने वाला प्रश्न है। मैं वास्तव में आवश्यकताओं और कुछ मान्यताओं पर सवाल उठा रहा हूं जो संभवतः डेटा के बारे में किए जा रहे हैं। मेरे spidey भावना सिर्फ मेरे लिए चिल्लाती है कि इन आवश्यकताओं और डेटा के महत्व के बारे में मान्यताओं एक bloviated और आत्म पूजा कंपनी के चिंतन कि पसंद ही वास्तविकता शेष भाग में ... सूचित और व्यावहारिक लेकिन कर रहे हैं
maple_shaft

38

आपको कुछ कदम उठाने की जरूरत है और, अपने ग्राहक के परामर्श से, खतरे के मॉडल पर काम करें । (हां, यह एक 600-पृष्ठ पुस्तक का एक लिंक है; हां, मैं आपको पूरी बात पढ़ने के लिए गंभीरता से सिफारिश कर रहा हूं।)

एक धमकी मॉडल की तरह सवाल पूछने से शुरू होता है

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

एक बार जब आप इन सवालों के जवाब जान लेते हैं, तो आपको पता चल जाएगा कि क्या करना है।

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

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


4
यह वास्तव में प्रश्न का उत्तर देने की कोशिश नहीं करता है या इसे अस्वीकार नहीं करता है, लेकिन यह वास्तव में एक प्रश्न का भयानक उत्तर है जो नहीं पूछा गया था।
maple_shaft

11
@maple_shaft: ठीक है, यह उस प्रश्न का उत्तर देता है जो ओपी से पूछना था। चूंकि सवाल अच्छी तरह से XY समस्या से ग्रस्त देखा जा सकता है , यह एक अच्छा जवाब लगता है।
साल्स्के

8

सिंक्रनाइज़ेशन करने का एक विकल्प यह होगा कि वह सहकर्मी से सहकर्मी हो। इसके लिए अभी भी एक केंद्रीय सर्वर की आवश्यकता होगी, लेकिन वह सर्वर किसी भी डेटा को हैंडल नहीं करेगा।

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

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


1
दो उपकरणों के बीच हर समय सभी डेटा को आगे और पीछे भेजने से बचने के लिए एक संस्करण योजना की तरह लगता है ...
ebyrob

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

1
@DavidPacker यह मानते हुए कि आपने पहले सर्वर सेट किया है और अतिरिक्त सेटअप चरण क्या हैं?
एरोब्र

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

1
@ डेविड, फिलिप संवेदनशील डेटा का सहकर्मी से सहकर्मी आदान-प्रदान करने का सुझाव दे रहा है, इस प्रकार केंद्रीय सर्वर के माध्यम से या यहां तक ​​कि उसे नहीं भेजा जा रहा है। केंद्रीय सर्वर केवल एक सहकर्मी को दूसरे सहकर्मी को खोजने की सुविधा के लिए है; फिर यह रास्ते से हट जाता है।
एरिक इद्दत

5

इसे किसी और की समस्या बनाओ।

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

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


1

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

यदि आपका ग्राहक कहीं भी संग्रहीत डेटा नहीं चाहता है, तो क्या वे चाहते हैं कि उपयोगकर्ता हर बार मेरे हाथ में आए?

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