रेल के साथ डेटाबेस में उपयोगकर्ता डेटा कैसे सुरक्षित करें?

Question

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

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

Answer 1

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

हमेशा मान लें कि यदि कोई हैकर आपकी सुरक्षा के किसी भी हिस्से से समझौता कर सकता है, तो वे इससे समझौता कर सकते हैं। चेन केवल सबसे कमजोर लिंक और वह सब जितना मजबूत है।

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

Answer 2

क्रेडिट कार्ड नंबर, एसएसएन, आदि हमेशा एन्क्रिप्टेड संग्रहित किया जाना चाहिए।

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

मुझे लगता है कि मेरे ऐप में, मैं एन्क्रिप्टेड प्रतिनिधित्व दर्द रहित से निपटने के लिए, मेरी कक्षा में अनएन्क्रिप्टेड _ **** पाठकों और लेखकों को जोड़ना चाहता हूं।

class User 
    # has db column encrypted_cc_number 
    def unencrypted_cc_number 
    WhateverEncryptionClassYouUse.decrypt(encrypted_cc_number) 
    end 
    def unencrypted_cc_number=(val) 
    self.encrypted_cc_number = WhateverEncryptionClassYouUse.encrypt(val) 
    end 
end 

Answer 3

स्तरित सुरक्षा तंत्र और मजबूत क्रिप्टोग्राफी का उपयोग करना अच्छा अभ्यास है यदि आप बड़ी मात्रा में संवेदनशील डेटा संग्रहीत कर रहे हैं। यह भुगतान कार्ड उद्योग के डेटा सुरक्षा मानक (पीसीआई डीएसएस) द्वारा आवश्यक है। मेरा सुझाव है कि आप निम्नलिखित दिशानिर्देश दस्तावेज़ पढ़ें: https://www.pcisecuritystandards.org/pdfs/pci_fs_data_storage.pdf।

आपको निश्चित रूप से "यह मानना ​​नहीं चाहिए कि यह कभी समझौता नहीं किया जाएगा"