एन्क्रिप्ट किए गए फ़ील्ड के साथ MySQL डेटाबेस कैसे खोजें

Question

मान लीजिए कि मुझे एक MySQL डेटाबेस के कुछ टेबल-फ़ील्ड्स को एन्क्रिप्ट करने की आवश्यकता है । इसके अतिरिक्त, मुझे उन क्षेत्रों में से कुछ को खोजने की आवश्यकता है जो मैंने एन्क्रिप्ट किया था।

वैसे भी उन खेतों को कोई कैसे खोजेगा?

प्रत्येक रिकॉर्ड को चरण दर चरण डिक्रिप्ट करना कोई विकल्प नहीं है: मान लीजिए कि मेरे पास हजारों रिकॉर्ड हैं। प्रत्येक रिकॉर्ड को डिक्रिप्ट करने और जाँच करने में बहुत समय और स्थान लगेगा कि क्या प्रत्येक एकल रिकॉर्ड खोज से मेल खाता है।

अद्यतन 2012-09-07

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

अद्यतन 2012-09-08

एन्क्रिप्शन इस प्रश्न का कर्नेल है।

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

यह औपचारिक आवश्यकता है नहीं भुगतान कार्ड उद्योग डेटा सुरक्षा मानक [पीसीआई]।

Answer 1

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

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

यदि आप की जरूरत है, तो आप संभवतः "हैश का" पूर्ण पाठ सूचकांक बनाकर इसे बढ़ा सकते हैं, लेकिन यह वास्तव में तेजी से जटिल हो सकता है।

परिशिष्ट

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

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

पासवर्ड जैसी चीजों से निपटने के दौरान यह हमला खतरनाक है: यदि आप लोकप्रिय पासवर्ड हैश का शब्दकोश बनाते हैं, तो आप उस हैश मान के लिए तालिका को जल्दी से खोज सकते हैं और उस उपयोगकर्ता की पहचान कर सकते हैं जिसके पास ऐसा पासवर्ड है और उस उपयोगकर्ता की पहचान को चोरी करने के लिए प्रभावी रूप से क्रेडेंशियल निकालते हैं। ।

यह उच्च स्तर की कार्डिनलिटी वाली वस्तुओं के लिए कम खतरनाक है, जैसे SSN, क्रेडिट कार्ड नंबर, GUIDs, आदि (लेकिन इनको संग्रहीत करने से जुड़े विभिन्न जोखिम [पढ़ें: कानूनी] हैं, इसलिए मैं इन्हें स्टोर करने की सलाह देने के लिए इच्छुक नहीं हूं। )।

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

यदि आप किसी व्यक्ति के लिए SSN से मिलान करने का प्रयास कर रहे हैं, तो आप एक विशिष्ट SSN या क्रेडिट कार्ड नंबर भी देख सकते हैं । फिर, आमतौर पर एक शब्दकोश हमले की बात नहीं है, लेकिन ऐसा करना संभव है, इसलिए यदि यह एक जोखिम है जिसे आपको बचने की आवश्यकता है, तो मेरा जवाब आपके लिए एक अच्छा समाधान नहीं है।

इसलिए यह अब आपके पास है। सभी एन्क्रिप्टेड डेटा के साथ के रूप में, यह आमतौर पर एक कारण के लिए एन्क्रिप्टेड है, इसलिए अपने डेटा के बारे में पता होना चाहिए और आप इसे से बचाने के लिए क्या प्रयास कर रहे हैं।

Comments

इस उत्तर पर चर्चा को चैट में स्थानांतरित कर दिया गया है ।

— पॉल व्हाइट 9

Answer 2

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

CryptDB द्वारा उपयोग किए जाने वाले विभिन्न एन्क्रिप्शन तरीकों में शामिल हैं:

• RND , एक पूरी तरह से IND-CPA सुरक्षित एन्क्रिप्शन योजना है जो डेटा के बारे में कोई जानकारी लीक नहीं करता है (इसकी उपस्थिति को छोड़कर, चर-लंबाई प्रकारों, लंबाई के लिए) लेकिन केवल भंडारण और पुनर्प्राप्ति की अनुमति देता है, कोई प्रश्न नहीं।

• डीईटी , आरएनडी का एक प्रकार जो नियतात्मक है, ताकि दो समान मूल्य (एक ही कॉलम में) एक ही सिफरटेक्स्ट में एन्क्रिप्ट हो जाएं। फॉर्म के समानता प्रश्नों का समर्थन करता है WHERE column = 'constant'।

• OPE , एक ऑर्डर-प्रोटेक्टिंग एनक्रिप्शन स्कीम है जो असमानता के प्रश्नों का समर्थन करती है WHERE column > 'constant'।

• HOM , एक आंशिक रूप से होमोमोर्फिक एन्क्रिप्शन स्कीम (Paillier) है जो कूटशब्दों को गुणा करके एन्क्रिप्टेड मूल्यों को एक साथ जोड़ने की अनुमति देता है। SUM()प्रश्नों, जोड़ और वृद्धि का समर्थन करता है ।

• खोज , एक योजना जो फ़ॉर्म की कीवर्ड खोजों का समर्थन करती है WHERE column LIKE '% word %'।

• जॉइन और ओपीई-जोइन , डीईटी और ओपीई के वेरिएंट जो विभिन्न कॉलमों में एक दूसरे के साथ तुलना करने की अनुमति देते हैं। समता और सीमा का समर्थन क्रमशः होता है।

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

यदि आप रुचि रखते हैं, तो आपको पॉप , रेडफील्ड, ज़ेल्डोविच और बालकृष्णन ( SOSP 2011 ) द्वारा CryptDB वेबसाइट, विशेष रूप से "CryptDB: प्रोटेक्टिंग कॉन्फिडेंस विद एनक्रिप्टेड क्वेरी प्रोसेसिंग से जुड़े कागजात पर एक नज़र डालने की सलाह दी जाती है ।" वे कागजात विभिन्न सुरक्षा और प्रदर्शन ट्रेडऑफ़ का वर्णन करते हैं जो विभिन्न क्वेरी प्रकारों को अधिक विस्तार से समर्थन करने में शामिल हैं।

Comments

It works by encrypting and decrypting data as it passes between the application and the database: निश्चित रूप से यह समस्या पैदा कर सकता है यदि खोजा जा रहा डेटा पहले से ही डेटाबेस (एन्क्रिप्टेड) ​​में है, लेकिन जाहिर है कि डेटाबेस को खोजने वाली क्वेरी केवल तब ही CryptDB (और फिर एन्क्रिप्टेड?) को पारित हो जाती है। मुझे समझ नहीं आ रहा है कि यह तरीका कैसे कुशल हो सकता है?

— मार्टिन

Answer 3

मुझे समझ में नहीं आता है कि वर्तमान उत्तरों ने आवश्यकताओं पर पूरी तरह से सवाल क्यों नहीं उठाया है, इसलिए मैं इसे उत्तर के रूप में पूछूंगा और छोड़ूंगा।

व्यावसायिक कारण क्या हैं? एन्क्रिप्ट करने के लिए आपको किस डेटा की आवश्यकता है और क्यों? यदि आप PCI अनुपालन की तलाश कर रहे हैं, तो मैं एक निबंध लिख सकता हूं।

अपनी आवश्यकता के बारे में प्रश्न:

• क्या आपको परिणाम / वास्तविक डेटा के रूप में मौजूद / मौजूद नहीं होना चाहिए?
• क्या आपको LIKE '% OMG_SEKRIT%' क्षमता की आवश्यकता है?
• कौन डेटा नहीं देख सकता है और क्यों?

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

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

Comments

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

— SteAp

"अधिक महत्वपूर्ण डेटा?" के मानदंड क्या हैं?

— आर्केनिन

Answer 4

मैं इस पर गौर कर रहा हूं और आपके सवाल पर आया हूं। मैं "इनक्रिप्टेड डेटा पर खोजों के लिए व्यावहारिक तकनीक" http://www.cs.berkeley.edu/~dawnsong/papers/se.pdf "पेपर की प्रैक्टिकल तकनीकों के बारे में उल्लिखित दृष्टिकोण की ओर झुकाव कर रहा हूं ।

बुनियादी सार एक सूचकांक बनाना है जिसमें एन्क्रिप्ट किए गए कीवर्ड शामिल हैं जो एन्क्रिप्ट किए गए खोज दस्तावेज़ में मौजूद हैं। चाल भी दस्तावेज़ (या डेटाबेस) में उन स्थानों को एन्क्रिप्ट करने के लिए है जहां उन कीवर्ड मौजूद हैं।

Answer 5

प्रोग्रामेटिक रूप से, एक कुशल समाधान है

1. केवल उस फ़ील्ड के सभी रिकॉर्ड पुनर्प्राप्त करें जिसे आप रिकॉर्ड आईडी के साथ खोज रहे हैं
2. एक अस्थायी तालिका में उन्हें डिक्रिप्ट करें
3. उस तालिका के विरुद्ध खोज करें
4. खोज मापदंड से मेल खाने वाले पूर्ण रिकॉर्ड (सभी फ़ील्ड) प्राप्त करने के लिए आईडी का उपयोग करें
5. उन को डिक्रिप्ट करें और उन्हें उपयोगकर्ता को लौटा दें

मुद्दा यह है कि शुरुआत में सभी रिकॉर्ड के सभी क्षेत्रों को पुनः प्राप्त करने और डिक्रिप्ट करने की तुलना में 1 और 4 डेटा के छोटे सेट हैं।

उम्मीद है की वो मदद करदे।

Comments

प्लेनटेक्स्ट में अस्थाई टेबल्स अपेक्षाकृत (यानी बहुत आसान) हैं जिन्हें पकड़ना और पढ़ना आसान है, सर्वर को सही समय पर बाधित करना या बस temp/फ़ोल्डर और बैंग को कॉपी करना , पूरे कॉलम के लिए प्लेनटेक्स्ट मान हैं, यह ऑपरेटिंग का सुरक्षित तरीका नहीं है

— मार्टिन

Answer 6

यह MYSQL के आंतरिक एन्क्रिप्शन फ़ंक्शन का उपयोग करके पूर्ण खोज कार्यक्षमता के साथ संभव है।

यहाँ एक उदाहरण है:

!!! मैं MYSQL ENCODE का उपयोग कर रहा हूं () SIMPLICITY के लिए यहां, MYSQL_ENCODE अब उपलब्ध इंसिड्योर है, अन्य आंतरिक MYSQL फंक्शंस में से एक का उपयोग करें !!!

UPDATE my_table
SET field=ENCODE('my_data', 'my_password')
WHERE ID=1;

SELECT DECODE(field, 'my_password') as field FROM my_table
WHERE field LIKE 'data';

जैसा कि ऊपर टिप्पणी से पता चलता है, ENCODE का उपयोग न करें (), अन्य एन्क्रिप्शन कार्यों में से एक का उपयोग करें जो मैं केवल इस सादगी के कारण इस उदाहरण में ENCODE का उपयोग कर रहा हूं

यदि आप ऐसा किसी एप्लिकेशन जैसे php के भीतर कर रहे हैं, तो आप अपने db गेटवे या रिपॉजिटरी कक्षाओं के भीतर अपने संबंधित गेटवे क्लास के भीतर प्रत्येक टेबल के एन्क्रिप्टेड कॉलम की सूची / सरणी को संग्रहीत करके ऐसा कर सकते हैं।

class UserGateway
{
    protected $encrypted_fields = array(
        'username',
        'email'
    );

    public function get($fields, ...)
    {
        foreach ($fields as $k => $field) {
            if (in_array($field, $fields)) {
                $fields[$k] = $this->decodeSelect($field);
            }
        }

        $sql = 'SELECT '.implode(',', $fields);

        //......
    }

    protected function decodeSelect($field)
    {
        return "DECODE($field, $pass) AS $field";
    }
}

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

Answer 7

मान लें कि आप SQL में खोज रहे हैं और पूर्ण मान के विरुद्ध हैं और आंशिक नहीं (उदाहरण के लिए 'मान%') ... खोज डेटा कैप्चर करते समय, डेटा एन्क्रिप्ट किया गया था और उसी के लिए खोज करते समय उपयोग किए गए समान एल्गोरिथ्म का उपयोग करके उस डेटा को एन्क्रिप्ट करें।

उदाहरण के लिए:

क्या होता:

SELECT FieldA, FieldB 
FROM Table1 
WHERE FieldC = 'Value'

इसके बजाय लग सकता है:

SELECT FieldA, FieldB 
FROM Table1 
WHERE FieldC = 'hsk&%67ghhks83'

Comments

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

— मार्टिन