2010-03-05 21 views
14

मेरे पास एक वेब आधारित (perl/MySQL) सीआरएम सिस्टम है, और मुझे अनुशासनात्मक कार्यों और वेतन के बारे में विवरण जोड़ने के लिए एचआर के लिए एक अनुभाग की आवश्यकता है।सुरक्षित एन्क्रिप्टेड डेटाबेस डिज़ाइन

यह जानकारी जो हम डेटाबेस में संग्रहीत करते हैं उसे एन्क्रिप्ट किया जाना चाहिए ताकि हम डेवलपर इसे देख सकें।

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

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

लेकिन फिर भी एन्क्रिप्टेड डेटा पर बहु-उपयोगकर्ता पहुंच की समस्या है।

मैं कुंजी ऑफ साइट की 'सादे टेक्स्ट' प्रतिलिपि रख सकता हूं, और इसे प्रत्येक नए मानव संसाधन व्यक्ति के पासवर्ड से एन्क्रिप्ट कर सकता हूं। लेकिन फिर मैं मास्टर कुंजी जानता हूं, जो आदर्श प्रतीत नहीं होता है।

क्या किसी ने इससे पहले कोशिश की है और सफल हुआ है?

+0

यह सोचने के लिए एक अच्छा क्षेत्र है। मैं अच्छे जवाब देखने के लिए तत्पर हूं। –

+0

मैं यहां इस सटीक प्रश्न पूछने के लिए आया था। +1। मैं मुख्य डेवलपर हूं और मुझे किसी और के वेतन को देखने की परवाह नहीं है और मैं नहीं चाहता कि मेरे डेवलपर इसे किसी भी को देखें। वह एक बड़ा नंबर नहीं होगा। – Vic

उत्तर

7

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

डेटा बहुत सारी चाबियों का उपयोग करके जीएनयूपीजी द्वारा काफी फूला हुआ होगा: इसे पेलोड के लिए सत्र कुंजी बनाना है और फिर प्रत्येक कुंजी कुंजी का उपयोग करके उस कुंजी को एन्क्रिप्ट करना है। एन्क्रिप्टेड कुंजी डेटा के साथ संग्रहीत हैं।

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

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

+0

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

+0

निजी कुंजी पर पासफ्रेज वास्तव में बदला जा सकता है। – Martin

5

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

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

यह काम कर सकता है, लेकिन व्यापार मालिकों के विचार के मुकाबले यह उतना आसान नहीं है।

+1

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

+1

+1। हालांकि मैंने बड़ी कंपनियों में काम किया है जहां देव, टेस्ट और प्रोडक्शन वातावरण सख्ती से नियंत्रित किए गए थे और यह काम करता था, हालांकि इसने तैनाती के समय में बड़े पैमाने पर वृद्धि की थी (जबकि वास्तव में बग को कम करने के लिए बहुत कुछ नहीं करना)। तब तक जब तक एसए पासवर्ड नहीं मिलता है;) – Macros

+0

@ मैक्रोस - मैंने भी किया लेकिन यह सुंदर नहीं था। तैनाती और समर्थन के लिए समय/जटिलता में भारी वृद्धि के लिए +1। यदि आपको लगता है कि आपको "ऑन-द-फ्लाई फिक्सिंग और तैनाती" करने की आवश्यकता हो सकती है (जो मेरी वर्तमान कंपनी को पूरी तरह से वर्णन करती है) इसे पूरी तरह से अलग करना बेहद मुश्किल/असंभव है। –

0

मैं बस जोर से सोच रहा हूं।

ऐसा लगता है कि यह सार्वजनिक/निजी कुंजी तंत्र के लिए कॉल करता है। जानकारी एचआर सार्वजनिक कुंजी के साथ एन्क्रिप्टेड संग्रहित की जाएगी और केवल संबंधित निजी कुंजी के कब्जे में किसी के द्वारा देखा जा सकता है।

यह मेरे लिए, इन गोपनीय डेटा को देखने के लिए वेब आधारित इंटरफ़ेस को रद्द करना प्रतीत होता है (वेब ​​इंटरफ़ेस के माध्यम से उन्हें दर्ज करना निश्चित रूप से व्यवहार्य है)।

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

1

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

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

    चयन aes_encrypt hrkeys से ('काउंटर', कुंजी) जहां KEY_ID = 'आईडी' कुछ;:

  4. काउंटर धारा डेटाबेस एन्क्रिप्ट होने के लिए करने के लिए भेज दिया जाता है

  5. परिणामी एन्क्रिप्टेड काउंटर वैल्यू क्लीयरक्स्ट की लंबाई तक छंटनी की जाती है, और एन्क्रिप्टेड टेक्स्ट का उत्पादन करने के लिए क्वार्टरक्स्ट के साथ एक्सओआरड किया जाता है।

  6. एन्क्रिप्टेड टेक्स्ट संग्रहीत किया जाता है।
  7. डिक्रिप्शन एन्क्रिप्टेड पाठ पर लागू वही प्रक्रिया है।

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

देखें Wikipedia - Counter Mode

+0

बहुत रोचक! मुझे इसके चारों ओर अपने सिर को पाने के लिए थोड़ी देर लग गई अभी भी यकीन नहीं है कि अगर मैं पूरी तरह से सभी प्रभावों को समझता हूं :) – aidan

0

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

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

जब तक उपयोगकर्ता खाता एक्सेस अधिकार स्थापित करने वाले लोग भरोसेमंद हो सकते हैं या गोपनीय जानकारी देखने के लिए स्वयं ठीक हैं, तो यह काफी सुरक्षित होना चाहिए।

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

संबंधित मुद्दे