क्या मुझे डेटाबेस में डेटा एन्क्रिप्ट करना चाहिए?

16

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

समस्या यह है कि यह संवेदनशील डेटा, रोगी का इतिहास और ऐसा है।

क्लाइंट डेटाबेस स्तर पर डेटा एन्क्रिप्ट करने पर जोर देता है, लेकिन मुझे लगता है कि यह वेब ऐप के प्रदर्शन को खराब करने वाला है। (लेकिन शायद मुझे इस बारे में चिंतित नहीं होना चाहिए)

मैंने स्वास्थ्य संबंधी मुद्दों (पुर्तगाल) पर डेटा संरक्षण के बारे में कानूनों को पढ़ा है, लेकिन इस बारे में बहुत विशिष्ट नहीं है (मैंने सिर्फ इस बारे में उनसे सवाल किया था, मैं उनकी प्रतिक्रिया की प्रतीक्षा कर रहा हूं)।

मैंने निम्नलिखित लिंक पढ़ा है , लेकिन मेरा प्रश्न अलग है, क्या मुझे डेटाबेस में डेटा एन्क्रिप्ट करना चाहिए, या नहीं।

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

यहां तक कि उपयोगकर्ता पासवर्ड में एक यादृच्छिक नमक जोड़ने से समस्या का समाधान नहीं हो रहा है क्योंकि मैं इसे हमेशा एक्सेस कर सकता हूं, और इसलिए डेटा को डिक्रिप्ट करता हूं।

php mysql encryption

— Tio
स्रोत

1

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

— एरिक रिपेन

4

क्या आप पूरे डेटाबेस को एक एन्क्रिप्टेड वॉल्यूम पर रख सकते हैं और इसे एक दिन कह सकते हैं। जरूर पढ़े / लिखे धीमे होंगे, लेकिन आप RDMS (या जो भी आप उपयोग कर रहे हैं) का सभी लाभ रखें, जबकि डिस्क पर डेटा एन्क्रिप्टेड है

— DXM

2

इसका मतलब यह भी है कि आप mysql कार्यक्षेत्र में डेटा को देखने में सक्षम नहीं होंगे? डिबगिंग के लिए शुभकामनाएँ।

— मनोज आर

4

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

— 8 अक्टूबर को रिएक्टगुलर

1

ब्रिटेन के एक अस्पताल पर £ 300,000 का जुर्माना लगाया गया क्योंकि डिस्क ड्राइव भटक गए थे जिसमें अनएन्क्रिप्टेड डेटाबेस थे। स्वास्थ्य की जानकारी बहुत संवेदनशील है।

— MarkJ

9

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

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

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

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

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

— एम अफफी
स्रोत

1

IANAL, लेकिन जब संभव देयता बड़ी हो तो IMO आमजन को "कानूनों की जाँच" नहीं करनी चाहिए। उन्हें एक वकील से सलाह लेनी चाहिए।

— केविन क्लाइन

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

— ज़ालबाज़ोज़

13

हां, आपको डेटाबेस को एन्क्रिप्ट करना चाहिए।

संग्रहीत डेटा के लिए मूल एन्क्रिप्शन ("आराम पर डेटा") एक आम तौर पर स्वीकृत सुरक्षा सिद्धांत है, और संभवतः कानून द्वारा अनिवार्य है यदि आपके देश में ऐसे कानून हैं जो व्यक्तिगत या स्वास्थ्य जानकारी की रक्षा करते हैं।

हम SQL Server 2008 का उपयोग कर रहे हैं, इसलिए हम Microsoft के TDE का उपयोग करते हैं; MySQL के लिए कुछ तृतीय-पक्ष समाधान हो सकता है या शायद केवल एक सामान्य वॉल्यूम एन्क्रिप्शन दृष्टिकोण (जैसे TrueCrypt) काम करेगा (हालांकि मैं कुछ ऐसा करना चाहता हूं जिसे डेटाबेस के साथ उपयोग के लिए प्रमाणित किया गया है)।

यदि ठीक से किया जाता है, तो प्रदर्शन हिट छोटा होना चाहिए।

वैसे, आपके द्वारा उल्लिखित लिंक (संवेदनशील जानकारी के पृथक्करण के बारे में) कुछ ऐसा है जिसे आपको बुनियादी डेटाबेस एन्क्रिप्शन के शीर्ष पर विचार करना चाहिए।

संपादित करें: ऊपर उल्लिखित एन्क्रिप्शन वॉल्यूम को एन्क्रिप्ट करेगा। अगर किसी को हार्ड ड्राइव चोरी करना था, तो वे डेटा को एन्क्रिप्टेड पाएंगे। हालाँकि, अगर किसी को डेटाबेस पर प्रश्न चलाने होते थे, तो वे अनएन्क्रिप्टेड डेटा को देखेंगे (इसीलिए मैंने जानकारी के पृथक्करण का उल्लेख किया, भले ही ओपी इस पर चर्चा नहीं करना चाहता था)।

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

— jdigital
स्रोत

2

मुझे यकीन नहीं है कि यह मामला है। सवाल डेटाबेस को एन्क्रिप्ट करने के बारे में नहीं है, बल्कि डेटाबेस में डेटा को एन्क्रिप्ट करने के बारे में है। इसका मतलब है कि sql क्वेरी में डेटा एन्क्रिप्ट किया जाएगा।

— मनोज आर

1

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

— mike30

@ मायिक उपरोक्त दृष्टिकोण मात्रा को एन्क्रिप्ट करेगा और इंडेक्सिंग आदि को प्रभावित नहीं करेगा

— jdigital

IMO आपको यहां से अधिक विशेषज्ञता की आवश्यकता है। IANAL, लेकिन मुझे लगता है कि यदि इस डेटा से छेड़छाड़ की जाती है, तो आपके ग्राहक के पास बहुत अधिक एक्सपोज़र है।

— केविन क्लाइन

8

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

अब, इस संदर्भ में कुछ ऐसी चीजें हैं जिनके बारे में आप चिंता कर सकते हैं:

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

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

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

तीसरे परिदृश्य में, सब कुछ उस संदर्भ पर निर्भर करता है जिसमें हमला होता है: यदि यह है, उदाहरण के लिए, एक XSS या CSRF हमला, तो एक हमलावर कुछ भी वैध उपयोगकर्ता कर सकता है, और आपके डेटा को एन्क्रिप्ट करने में मदद नहीं करता है। ।

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

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

— tdammers
स्रोत

2

+1: खतरे के मॉडल के बिना, आप सबसे संभावित रूप से सामने के दरवाजे को बंद कर रहे हैं लेकिन पीछे के दरवाजे को खुला छोड़ रहे हैं।

— केविन क्लाइन

8

एक पल के लिए अनदेखा करना कि ग्राहक क्या माँग रहा है, और जो भी कानून हैं ...

नहीं, आपको संभवतः डेटा को एन्क्रिप्ट नहीं करना चाहिए। यदि आप करते हैं, तो आप इसे आसानी से खोज नहीं पाएंगे। उदाहरण के लिए, like 'Smith%'यदि आप प्रत्येक नाम प्रविष्टि को एन्क्रिप्ट किया जाता है , तो आप अंतिम नाम की खोज कैसे करेंगे ? यदि आप खिचड़ी भाषा का समय पर एक मरीज के रक्तचाप को ग्राफ कैसे करेंगे select .... from.... where patient_id = N?

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

स्पष्टता: यह मान रहा है कि ओपी किस बारे में पूछ रहा था, वास्तव में डेटाबेस में डेटा एन्क्रिप्ट कर रहा है। फ़ाइल सिस्टम डेटाबेस पर नहीं रहता है।

— GrandmasterB
स्रोत

पूरी तरह से सहमत हैं, अभी तक LAWS नहीं करता है :(

— Zalaboza

1

अच्छी तरह से आप AES_DESCRYPT('') LIKE 'Smith%'अविश्वसनीय रूप से धीमी गति से कर सकते हैं । या आप तीव्र हो सकते हैं और नमकीन

— राख के

1

यदि आप CakePHP जैसे प्रभावी MVC फ्रेमवर्क का उपयोग करके वेब अनुप्रयोग को सावधानीपूर्वक विकसित करते हैं। Zend या Rails, तो आपको डेटा मोडल स्तर पर एन्क्रिप्शन को सक्षम / अक्षम करना चाहिए।

उदाहरण के लिए CakePHP में मोडल के एन्क्रिप्टेड डेटा के लिए व्यवहार के कुछ उदाहरण हैं। कंट्रोलर्स और व्यूज के लिए प्रक्रिया को पारदर्शी बनाना।

ऐसा करते समय अनुक्रमण और अन्य तकनीकी डेटाबेस मुद्दों के मुद्दों की अनदेखी करना। यह एक विन्यास विकल्प के रूप में होना संभव है।

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

— Reactgular
स्रोत

1

हां, आपको डेटाबेस को एन्क्रिप्ट करना चाहिए।

चूंकि यह व्यक्तिगत और संवेदनशील जानकारी है, इसलिए मुझे निश्चित रूप से यह मानना चाहिए।

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

— dagnelies
स्रोत

लोग बहुत बार अपने पासवर्ड भूल जाते हैं ... फिर क्या?

— जिज्ञासु

-1

मैं खुद से पूछता हूं कि ग्राहक आपको डीबी को एन्क्रिप्ट करने के लिए क्यों कहता है? यदि वह आपसे उस डेटा की सुरक्षा करने के लिए कहेगा जो मैं सहमत होऊंगा, लेकिन उसका पहले से ही निहित कार्यान्वयन है। इसलिए जब तक वह ठीक से नहीं जानता कि वह किस बारे में बात कर रहा है, वह सिर्फ मेरे दृष्टिकोण से buzzwords फेंक रहा है।

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

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

— sschrass
स्रोत

... हर प्रमुख DBMS सुरक्षा खाता लेता है ... सिवाय जब वे नहीं करते ।

— जे एलस्टन

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

— sschrass

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

— जे एलस्टन