सुरक्षा के लिए वास्तुकला:MySQL के लिए एक गाइड

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

नेटवर्क

सबसे पहले, हमें MySQL को कहीं तैनात करना होगा। यह स्टैंडअलोन उदाहरण हो, प्राथमिक - प्रतिकृति एसिंक्रोनस प्रतिकृति या अधिक उन्नत, सिंक्रोनस प्रतिकृति टोपोलॉजी जैसे गैलेरा या इनो डीबी क्लस्टर में से एक हो। कोई फर्क नहीं पड़ता कि यह नेटवर्क स्तर पर संरक्षित है। डेटाबेस में डेटा होता है, जो आमतौर पर पूरे संगठन की सबसे मूल्यवान संपत्ति होती है।

पहुंच सुरक्षित करना

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

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

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

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

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

वीपीएन

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

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

फ़ायरवॉल

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

डेटाबेस सुरक्षा

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

उपयोगकर्ता और होस्ट

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

आप यहां जो लागू करना चाहते हैं वह डेटाबेस उपयोगकर्ताओं और होस्ट की एक सूची है जिन्हें डेटाबेस तक पहुंचने की अनुमति है। सबसे अधिक संभावना है कि आपको एक या एक से अधिक उपयोगकर्ता को प्रॉक्सी परत में स्थित मेजबानों से पहुंच प्रदान करनी चाहिए। आपके पास कितना विस्तृत अभिगम नियंत्रण हो सकता है यह आपके पास मौजूद डेटाबेस सिस्टम पर निर्भर करता है। उदाहरण के लिए, MySQL नेटवर्क मास्क पर विस्तृत नियंत्रण की अनुमति नहीं देता है - यह केवल /32, /24, /16 या / 8 का उपयोग करता है। दूसरी ओर, PostgreSQL में, आप किसी भी प्रकार के नेटवर्क मास्क का उपयोग कर सकते हैं।

अनुदान

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

पासवर्ड प्रबंधन

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

ऑडिट लॉग्स

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

एसक्यूएल सुरक्षा

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

एसक्यूएल फ़ायरवॉल

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

SQL इंजेक्शन का पता लगाना

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

अतीत में हमने चर्चा की है कि आप ProxySQL का उपयोग करके SQL फ़ायरवॉल और SQL इंजेक्शन डिटेक्शन को कैसे कार्यान्वित कर सकते हैं, एक लोडबैलेंसर जिसे ClusterControl से तैनात किया जा सकता है:

https://severalnines.com/database-blog/how-protect-your-mysql-or-mariadb-database-sql-injection-part-one

https://severalnines.com/database-blog/how-protect-your-mysql-or-mariadb-database-sql-injection-part-two

डेटा सुरक्षा

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

बैकअप

बैकअप हमेशा एन्क्रिप्टेड होना चाहिए। एन्क्रिप्शन कुंजी को सावधानीपूर्वक बनाए रखा जाना चाहिए और नियमित रूप से घुमाया जाना चाहिए।

ट्रांज़िट में डेटा

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

आराम पर डेटा

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

निष्कर्ष

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