एन्क्रिप्शन बाकी है
रेस्ट पर एन्क्रिप्शन डेटाबेस में डेटा है जब इसका उपयोग / एक्सेस या अपडेट नहीं किया जा रहा है। चलते-फिरते एन्क्रिप्शन TLS . जैसी चीज़ें हैं जहां डेटा (डेटाबेस से ) को सर्वर से सर्वर तक ब्राउज़र, सर्वर से, ब्राउजर आदि में ले जाया जाता है। टीएलएस ज्यादातर स्थितियों में पूरी तरह से अच्छा होता है यदि इसे सावधानी से संभाला जाता है और इस दृष्टिकोण से संपर्क किया जाता है कि आपको न्यूनतम से अधिक करने की आवश्यकता है वास्तव में इसे वास्तविक रूप से सुरक्षित बनाने के लिए।
एक विशिष्ट उदाहरण यह है कि लोग अपने डोमेन पर LetsEncrypt से TLS प्रमाणपत्र डालते हैं और सोचते हैं कि अचानक उनका सारा सामान सुरक्षित है; लेकिन वे अपने सत्र या अपनी कुकी को एन्क्रिप्ट नहीं करते हैं इसलिए उनके बचाव में एक बड़ा संभावित छेद छोड़ रहा है।
MySQL के अंतर्निहित एन्क्रिप्शन सिस्टम का उपयोग न करें।
मैं इस पर अधिक जोर नहीं दे सकता हूं; MySQL में अंतर्निहित एन्क्रिप्शन सिस्टम वास्तविक सुरक्षित डेटा सुरक्षा के लिए उपयुक्त नहीं है।
कृपया एक बहुत ही समान प्रश्न का मेरा उत्तर यहां पढ़ें विवरण के अनुसार (मैं केवल कॉपी/पेस्ट नहीं करना चाहता )।
ठीक है, तो, क्योंकि आप जोर देते हैं... यहाँ:
मैंने इस विषय पर अपने स्वयं के शोध में जो पढ़ा है, उसमें से मैग्नस द्वारा प्रदान किया गया लिंक defuse/php -एन्क्रिप्शन MySQL प्रोग्राम/सर्वर को कभी भी आपके डेटा का प्लेनटेक्स्ट मान देखने की अनुमति न देकर, MySQL को कभी भी आपके डेटा से समझौता करने से रोकने के सर्वोत्तम तरीकों में से एक है।
-- 7 मई 2017 को पोस्ट किया गया उत्तर।
साथ ही बिल कार्विन का इसी प्रश्न का उत्तर कुछ मूल्यवान अतिरिक्त जानकारी देता है:
-- 7 मई 2017 को पोस्ट किया गया उत्तर।
समापन बिंदु:
सुरक्षा जटिल है। यदि आप इसे ठीक से करना चाहते हैं और अपनी सुरक्षात्मक प्याज की खाल में विश्वास करना चाहते हैं तो आपको बहुत सी चीजें करने की आवश्यकता है (नीचे गोलियां देखें); लेकिन पहली चीज़ जो आपको करने की ज़रूरत है वह है:
-
परिभाषित करें कि आप किसके विरुद्ध सुरक्षा कर रहे हैं
गंभीरता से। आपको किसी ऐसे व्यक्ति के खिलाफ अलग-अलग रणनीतियों की आवश्यकता है जो आपके सादे टेक्स्ट नाम और पते चोरी करना चाहता है, जो आपके सर्वर को लेना चाहता है, जो किसी ऐसे व्यक्ति के विरुद्ध है जो केवल डेटा को मिटा देना चाहता है। यह एक मिथक है कि आप हर समय हर किसी से रक्षा कर सकते हैं, अवधारणा से यह असंभव है*; इसलिए आपको सबसे अधिक संभावित हमलावरों को परिभाषित करने और फिर उनकी प्रगति को कम करने के लिए सर्वोत्तम तरीके से काम करने की आवश्यकता है।
विशेष रूप से MySQL के लिए, कुछ स्पष्ट अनुशंसाएँ:
-
SQL और PHP को एक ही सर्वर पर रखें। MySQL डेटा को दूरस्थ रूप से एक्सेस न करें।
-
SQL के बाहरी एक्सेस को बाहर करें (इसलिए यह
localhostहै केवल) -
अपने टेबल नामों और कॉलम नामों को अस्पष्ट करें; अगर कोई आपके डेटा में सेंध लगाता है और आपके पास
HDTBJ^BTUETHNUYT. है कॉलम के तहतusernameतब वे जानते हैं कि यह गारबल शायद एक उपयोगकर्ता नाम है इसलिए आपके एन्क्रिप्शन को तोड़ने की कोशिश में उनकी बहुत अच्छी शुरुआत है। -
महत्वपूर्ण :वास्तव में अपने टेबल एक्सेस को लॉक करें; बहुत सारे MySQL उपयोगकर्ता सेट अप करें, जिनमें से प्रत्येक के पास केवल न्यूनतम विशेषाधिकार हैं जो उन्हें चाहिए; आप चाहते हैं कि कोई उपयोगकर्ता तालिका को पढ़े (केवल ) और केवल कुछ तालिकाओं को पढ़ें; उपयोगकर्ताओं को कुछ तालिकाओं में लिखने के लिए लेकिन अन्य तालिकाओं तक पहुंच नहीं है। यह चिंता का विषय है कि यदि MySQL पर किसी एक उपयोगकर्ता से समझौता किया जाता है; आपने वहां डेटा का हर टुकड़ा स्वचालित रूप से नहीं खोया है।
-
PHP एन्क्रिप्शन सेवाओं का प्रयोग करें। एन्क्रिप्शन कुंजियों को पूरी तरह से अलग जगह पर स्टोर करें; उदाहरण के लिए आपके पास एक और सर्वर है जिसका उपयोग आप पूरी तरह से बैकअप के लिए करते हैं जिसे आप एन्क्रिप्शन कुंजियों को हथियाने के लिए पूरी तरह से एक्सेस कर सकते हैं, इसलिए यदि आपके PHP/MySQL सर्वर से समझौता किया गया है तो आपके पास कुंजी सर्वर को काटने और लॉक करने के लिए कुछ जगह है ताकि आप कर सकें क्षति को सीमित करें। यदि कुंजी सर्वर में भी बैकअप है तो वास्तव में आप बहुत बुरी तरह से समझौता नहीं कर रहे हैं (स्थिति पर निर्भर )।
-
आपको यह बताने के लिए बहुत सारे वॉचर्स और ईमेल मुखबिर सेट करें कि कुछ प्रक्रियाएँ कब चल रही हैं और कौन से सर्वर उपयोगकर्ता (लोग नहीं बल्कि प्रोग्राम) क्या कर रहे हैं। तो आप देख सकते हैं कि MySQL तालिकाओं के आकार को मापने और मापने के लिए 5 बजे एक अप्रत्याशित प्रक्रिया क्यों शुरू होती है। डब्ल्यूटीएफ?
-
आपके MySQL AES_ENCRYPT'ed डेटा को "सूँघने" की बहुत संभावना है, भले ही वह DB में आराम से न हो, लेकिन अगर वेबसाइट से समझौता किया जाता है (या इससे भी बदतर, PHP कोड असुरक्षित है) तो टाइमिंग अटैक काम कर सकता है समय क्वेरी लुकअप और डेटा पैकेट रिटर्न द्वारा डेटा सामग्री।
-
सुरक्षा एक ब्लैक होल है; किसी बिंदु पर या किसी अन्य पर आप सोचने जा रहे हैं "इसे सॉड करें, मैंने काफी किया है"। किसी के पास कभी भी पूरी सुरक्षा नहीं होती, कुछ बहुत ही समर्पित संगठनों के पास पर्याप्त है सुरक्षा। दूरी तय करने से पहले आपको यह पता लगाना होगा कि आप कितनी दूर चलने को तैयार हैं।
* असंभव क्यों? क्योंकि आपके डेटा को सभी खतरों से बचाने के लिए, इसे हर समय हैश की तरह अपठनीय, अनुपयोगी होना चाहिए। एक हैश हर समय हर किसी से सुरक्षित रहता है। लेकिन हैश को कभी भी हैश नहीं किया जा सकता।
