डेटा की सुरक्षा इन दिनों सर्वोच्च प्राथमिकता है। कभी-कभी इसे पीसीआई-डीएसएस या एचआईपीएए जैसे बाहरी नियमों द्वारा लागू किया जाता है, कभी-कभी ऐसा इसलिए होता है क्योंकि आप अपने ग्राहकों के डेटा और अपनी प्रतिष्ठा की परवाह करते हैं। सुरक्षा के कई पहलू हैं जिन्हें आपको ध्यान में रखने की आवश्यकता है - नेटवर्क एक्सेस, ऑपरेटिंग सिस्टम सुरक्षा, अनुदान, एन्क्रिप्शन आदि। इस ब्लॉग पोस्ट में, हम आपको अपने MySQL या MariaDB सेटअप को सुरक्षित करते समय किन बातों का ध्यान रखना चाहिए, इसके बारे में 10 टिप्स देंगे।
1. पासवर्ड के बिना उपयोगकर्ताओं को निकालें
MySQL पूर्व-निर्मित उपयोगकर्ताओं के एक सेट के साथ आता था, जिनमें से कुछ पासवर्ड के बिना डेटाबेस से जुड़ सकते हैं या इससे भी बदतर, अनाम उपयोगकर्ता। यह MySQL 5.7 में बदल गया है, जो डिफ़ॉल्ट रूप से, केवल एक रूट खाते के साथ आता है जो आपके द्वारा इंस्टॉलेशन के समय चुने गए पासवर्ड का उपयोग करता है। फिर भी, ऐसे MySQL इंस्टॉलेशन हैं जिन्हें पिछले संस्करणों से अपग्रेड किया गया था और ये इंस्टॉलेशन लीगेसी यूजर्स को बनाए रखते हैं। साथ ही, सेंटोस 7 पर मारियाडीबी 10.2 अनाम उपयोगकर्ताओं के साथ आता है:
MariaDB [(none)]> select user, host, password from mysql.user where user like '';
+------+-----------------------+----------+
| user | host | password |
+------+-----------------------+----------+
| | localhost | |
| | localhost.localdomain | |
+------+-----------------------+----------+
2 rows in set (0.00 sec)जैसा कि आप देख सकते हैं, वे केवल लोकलहोस्ट से एक्सेस करने के लिए सीमित हैं, लेकिन इसकी परवाह किए बिना, आप इस तरह के उपयोगकर्ता नहीं चाहते हैं। हालांकि उनके विशेषाधिकार सीमित हैं, फिर भी वे कुछ कमांड चला सकते हैं जो डेटाबेस के बारे में अधिक जानकारी दिखा सकते हैं - उदाहरण के लिए, संस्करण हमले के और वैक्टर की पहचान करने में मदद कर सकता है।
[[email protected] ~]# mysql -uanonymous_user
Welcome to the MariaDB monitor. Commands end with ; or \g.
Your MariaDB connection id is 19
Server version: 10.2.11-MariaDB MariaDB Server
Copyright (c) 2000, 2017, Oracle, MariaDB Corporation Ab and others.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
MariaDB [(none)]> SHOW GRANTS\G
*************************** 1. row ***************************
Grants for @localhost: GRANT USAGE ON *.* TO ''@'localhost'
1 row in set (0.00 sec)
MariaDB [(none)]> \s
--------------
mysql Ver 15.1 Distrib 10.2.11-MariaDB, for Linux (x86_64) using readline 5.1
Connection id: 19
Current database:
Current user: [email protected]
SSL: Not in use
Current pager: stdout
Using outfile: ''
Using delimiter: ;
Server: MariaDB
Server version: 10.2.11-MariaDB MariaDB Server
Protocol version: 10
Connection: Localhost via UNIX socket
Server characterset: latin1
Db characterset: latin1
Client characterset: utf8
Conn. characterset: utf8
UNIX socket: /var/lib/mysql/mysql.sock
Uptime: 12 min 14 sec
Threads: 7 Questions: 36 Slow queries: 0 Opens: 17 Flush tables: 1 Open tables: 11 Queries per second avg: 0.049
--------------कृपया ध्यान दें कि बहुत ही सरल पासवर्ड वाले उपयोगकर्ता लगभग उतने ही असुरक्षित होते हैं, जितने बिना पासवर्ड वाले उपयोगकर्ता। "पासवर्ड" या "क्वर्टी" जैसे पासवर्ड वास्तव में मददगार नहीं होते हैं।
2. टाइट रिमोट एक्सेस
सबसे पहले, सुपरयूज़र के लिए रिमोट एक्सेस - नवीनतम MySQL (5.7) या मारियाडीबी (10.2) स्थापित करते समय डिफ़ॉल्ट रूप से इसका ध्यान रखा जाता है - केवल स्थानीय एक्सेस उपलब्ध है। फिर भी, सुपरसर्स को विभिन्न कारणों से उपलब्ध होते देखना बहुत आम है। सबसे आम एक, शायद इसलिए कि डेटाबेस का प्रबंधन उन मनुष्यों द्वारा किया जाता है जो अपना काम आसान बनाना चाहते हैं, इसलिए वे अपने डेटाबेस में रिमोट एक्सेस जोड़ेंगे। यह एक अच्छा तरीका नहीं है क्योंकि रिमोट एक्सेस से MySQL में संभावित (या सत्यापित) सुरक्षा कमजोरियों का फायदा उठाना आसान हो जाता है - आपको पहले होस्ट से कनेक्शन प्राप्त करने की आवश्यकता नहीं है।
एक और कदम - सुनिश्चित करें कि प्रत्येक उपयोगकर्ता केवल विशिष्ट होस्ट से ही MySQL से जुड़ सकता है। आप हमेशा एक ही उपयोगकर्ता के लिए कई प्रविष्टियां परिभाषित कर सकते हैं ([email protected], [email protected]), इससे वाइल्डकार्ड की आवश्यकता को कम करने में मदद मिलनी चाहिए ([email protected]'%')।
3. परीक्षण डेटाबेस निकालें
परीक्षण डेटाबेस, डिफ़ॉल्ट रूप से, प्रत्येक उपयोगकर्ता के लिए उपलब्ध है, विशेष रूप से अनाम उपयोगकर्ताओं के लिए। ऐसे उपयोगकर्ता टेबल बना सकते हैं और उन्हें लिख सकते हैं। यह संभावित रूप से अपने आप में एक समस्या बन सकता है - कोई भी लेखन कुछ ओवरहेड जोड़ देगा और डेटाबेस प्रदर्शन को कम करेगा। वर्तमान में, डिफ़ॉल्ट स्थापना के बाद, Centos 7 पर केवल MariaDB 10.2 इससे प्रभावित होता है - Oracle MySQL 5.7 और Percona Server 5.7 में 'परीक्षण' स्कीमा उपलब्ध नहीं है।
[[email protected] ~]# mysql -uanonymous_user
Welcome to the MariaDB monitor. Commands end with ; or \g.
Your MariaDB connection id is 13
Server version: 10.2.11-MariaDB MariaDB Server
Copyright (c) 2000, 2017, Oracle, MariaDB Corporation Ab and others.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
MariaDB [(none)]> SHOW GRANTS\G
*************************** 1. row ***************************
Grants for @localhost: GRANT USAGE ON *.* TO ''@'localhost'
1 row in set (0.00 sec)
MariaDB [(none)]> USE test;
Database changed
MariaDB [test]> CREATE TABLE testtable (a INT);
Query OK, 0 rows affected (0.01 sec)
MariaDB [test]> INSERT INTO testtable VALUES (1), (2), (3);
Query OK, 3 rows affected (0.01 sec)
Records: 3 Duplicates: 0 Warnings: 0
MariaDB [test]> SELECT * FROM testtable;
+------+
| a |
+------+
| 1 |
| 2 |
| 3 |
+------+
3 rows in set (0.00 sec)बेशक, यह अभी भी हो सकता है कि आपका MySQL 5.7 पिछले संस्करणों से अपग्रेड किया गया है जिसमें 'टेस्ट' स्कीमा को हटाया नहीं गया था - आपको इसका ध्यान रखना चाहिए और जांचना चाहिए कि क्या आपने इसे बनाया है।
4. MySQL तक पहुंच बाधित करें
यह सर्वविदित है कि MySQL पोर्ट 3306 पर चलता है, और इसके सुपरयुसर को 'रूट' कहा जाता है। चीजों को कठिन बनाने के लिए, इसे बदलना काफी सरल है। कुछ हद तक, यह अस्पष्टता के माध्यम से सुरक्षा का एक उदाहरण है, लेकिन यह कम से कम 'रूट' उपयोगकर्ता तक पहुंच प्राप्त करने के स्वचालित प्रयासों को रोक सकता है। पोर्ट बदलने के लिए, आपको my.cnf को संपादित करना होगा और 'पोर्ट' वैरिएबल को किसी अन्य मान पर सेट करना होगा। उपयोगकर्ताओं के लिए - MySQL स्थापित होने के बाद, आपको एक नया सुपरयूज़र बनाना चाहिए (अनुदान विकल्प के साथ सभी को अनुदान दें) और फिर मौजूदा '[email protected]' खातों को हटा दें।
5. नेटवर्क सुरक्षा
आदर्श रूप से, MySQL नेटवर्क के माध्यम से उपलब्ध नहीं होगा और सभी कनेक्शन स्थानीय रूप से यूनिक्स सॉकेट के माध्यम से नियंत्रित किए जाएंगे। कुछ सेटअप में, यह संभव है - उस स्थिति में आप my.cnf में 'स्किप-नेटवर्किंग' वेरिएबल जोड़ सकते हैं। यह MySQL को किसी भी TCP/IP संचार का उपयोग करने से रोकेगा, Linux पर केवल Unix सॉकेट उपलब्ध होगा (नामित पाइप और Windows होस्ट पर साझा मेमोरी)।
हालांकि अधिकांश समय, इतनी कड़ी सुरक्षा संभव नहीं है। ऐसे में आपको दूसरा उपाय तलाशने की जरूरत है। सबसे पहले, आप अपने फ़ायरवॉल का उपयोग केवल विशिष्ट होस्ट से MySQL सर्वर पर ट्रैफ़िक की अनुमति देने के लिए कर सकते हैं। उदाहरण के लिए, एप्लिकेशन होस्ट (हालाँकि वे प्रॉक्सी के माध्यम से MySQL तक पहुँचने के साथ ठीक होना चाहिए), प्रॉक्सी परत, और शायद एक प्रबंधन सर्वर। आपके नेटवर्क के अन्य होस्ट को शायद MySQL सर्वर तक सीधे पहुंच की आवश्यकता नहीं है। यह आपके डेटाबेस पर हमले की संभावनाओं को सीमित कर देगा, यदि आपके नेटवर्क में कुछ होस्टों से समझौता किया जाएगा।
यदि आप ऐसे प्रॉक्सी का उपयोग करते हैं जो प्रश्नों के लिए नियमित अभिव्यक्ति मिलान की अनुमति देते हैं, तो आप उनका उपयोग SQL ट्रैफ़िक का विश्लेषण करने और संदिग्ध प्रश्नों को ब्लॉक करने के लिए कर सकते हैं। सबसे अधिक संभावना है कि आपके एप्लिकेशन होस्ट को "अपने_टेबल से हटाएं *" नहीं चलाना चाहिए; नियमित रूप से। यदि कुछ डेटा को हटाने की आवश्यकता है, तो इसे MySQL इंस्टेंस पर स्थानीय रूप से हाथ से निष्पादित किया जा सकता है। आप ProxySQL जैसी किसी चीज़ का उपयोग करके ऐसे नियम बना सकते हैं:ऐसे प्रश्नों को ब्लॉक करें, फिर से लिखें, पुनर्निर्देशित करें। MaxScale आपको रेगुलर एक्सप्रेशन के आधार पर प्रश्नों को ब्लॉक करने का विकल्प भी देता है।
6. ऑडिट प्लगइन्स
यदि आप डेटा एकत्र करने में रुचि रखते हैं कि किसने और कब निष्पादित किया, तो MySQL के लिए कई ऑडिट प्लगइन्स उपलब्ध हैं। यदि आप MySQL एंटरप्राइज का उपयोग करते हैं, तो आप MySQL एंटरप्राइज ऑडिट का उपयोग कर सकते हैं जो MySQL एंटरप्राइज का विस्तार है। Percona और MariaDB के पास ऑडिट प्लगइन्स का अपना संस्करण भी है। अंत में, MySQL के लिए McAfee प्लगइन का उपयोग MySQL के विभिन्न संस्करणों के साथ भी किया जा सकता है। सामान्यतया, वे प्लगइन्स कमोबेश एक ही डेटा एकत्र करते हैं - घटनाओं को कनेक्ट और डिस्कनेक्ट करें, निष्पादित क्वेरी, एक्सेस की गई टेबल। इन सभी में इस बात की जानकारी होती है कि किस उपयोगकर्ता ने इस तरह के आयोजन में भाग लिया, किस होस्ट से लॉग इन किया, कब हुआ आदि। आउटपुट एक्सएमएल या जेएसओएन हो सकता है, इसलिए सामान्य लॉग सामग्री को पार्स करने की तुलना में इसे पार्स करना बहुत आसान है (भले ही डेटा समान हो)। इस तरह के आउटपुट को syslog और आगे, प्रसंस्करण और विश्लेषण के लिए किसी प्रकार के लॉग सर्वर पर भी भेजा जा सकता है।
7. लोड डेटा स्थानीय जानकारी अक्षम करें
यदि सर्वर और क्लाइंट दोनों में LOAD DATA LOCAL INFILE चलाने की क्षमता है, तो क्लाइंट स्थानीय फ़ाइल से दूरस्थ MySQL सर्वर पर डेटा लोड करने में सक्षम होगा। यह, संभावित रूप से, उन फ़ाइलों को पढ़ने में मदद कर सकता है जिन तक क्लाइंट की पहुंच है - उदाहरण के लिए, किसी एप्लिकेशन सर्वर पर, कोई भी उस फ़ाइल तक पहुंच सकता है जिस तक HTTP सर्वर की पहुंच है। इससे बचने के लिए, आपको my.cnf
. में local-infile=0 सेट करना होगा8. फ़ाइल विशेषाधिकार
आपको यह ध्यान रखना होगा कि MySQL की सुरक्षा भी ऑपरेटिंग सिस्टम सेटअप पर निर्भर करती है। MySQL फाइलों के रूप में डेटा स्टोर करता है। MySQL सर्वर लॉग में बहुत सारी जानकारी लिखता है। कभी-कभी इस जानकारी में डेटा होता है - धीमी क्वेरी लॉग, सामान्य लॉग या बाइनरी लॉग, उदाहरण के लिए। आपको यह सुनिश्चित करने की आवश्यकता है कि यह जानकारी केवल उन उपयोगकर्ताओं के लिए सुरक्षित और सुलभ है, जिन्हें इसे एक्सेस करना है। आम तौर पर इसका मतलब है कि केवल रूट और उपयोगकर्ता जिनके अधिकारों के तहत MySQL चल रहा है, को सभी MySQL से संबंधित फाइलों तक पहुंच होनी चाहिए। अधिकांश समय यह एक समर्पित उपयोगकर्ता होता है जिसे 'mysql' कहा जाता है। आपको MySQL कॉन्फ़िगरेशन फ़ाइलों और MySQL द्वारा जेनरेट किए गए सभी लॉग की जांच करनी चाहिए और सत्यापित करना चाहिए कि वे अन्य उपयोगकर्ताओं द्वारा पढ़ने योग्य नहीं हैं।
9. एसएसएल और ट्रांज़िट में डेटा का एन्क्रिप्शन
लोगों को कॉन्फ़िगरेशन और लॉग फ़ाइलों तक पहुँचने से रोकना एक बात है। दूसरा मुद्दा यह सुनिश्चित करना है कि डेटा नेटवर्क पर सुरक्षित रूप से स्थानांतरित हो। सेटअप के अपवाद के साथ जहां सभी क्लाइंट स्थानीय हैं और MySQL तक पहुंचने के लिए यूनिक्स सॉकेट का उपयोग करते हैं, अधिकांश मामलों में, डेटा जो क्वेरी के लिए परिणाम सेट करता है, सर्वर छोड़ देता है और नेटवर्क पर क्लाइंट को स्थानांतरित कर दिया जाता है। डेटा को MySQL सर्वर के बीच भी स्थानांतरित किया जा सकता है, उदाहरण के लिए मानक MySQL प्रतिकृति के माध्यम से या गैलेरा क्लस्टर के भीतर। नेटवर्क ट्रैफ़िक को सूंघा जा सकता है, और उन माध्यमों से, आपका डेटा उजागर हो जाएगा।
ऐसा होने से रोकने के लिए, सर्वर और क्लाइंट-साइड दोनों, ट्रैफ़िक को एन्क्रिप्ट करने के लिए एसएसएल का उपयोग करना संभव है। आप क्लाइंट और MySQL सर्वर के बीच SSL कनेक्शन बना सकते हैं। आप अपने मास्टर और अपने दासों के बीच, या गैलेरा क्लस्टर के नोड्स के बीच एक एसएसएल कनेक्शन भी बना सकते हैं। यह सुनिश्चित करेगा कि स्थानांतरित किया गया सभी डेटा सुरक्षित है और आपके नेटवर्क तक पहुंच प्राप्त करने वाले हमलावर द्वारा नहीं देखा जा सकता है।
MySQL प्रलेखन में विस्तार से बताया गया है कि SSL एन्क्रिप्शन को कैसे सेटअप किया जाए। यदि आपको यह बहुत बोझिल लगता है, तो ClusterControl कुछ ही क्लिक में MySQL प्रतिकृति या गैलेरा क्लस्टर के लिए एक सुरक्षित वातावरण को परिनियोजित करने में आपकी सहायता कर सकता है:
<एच2>10. आराम से डेटा का एन्क्रिप्शन SSL एन्क्रिप्शन का उपयोग करके ट्रांज़िट में डेटा सुरक्षित करना केवल आंशिक रूप से समस्या का समाधान करता है। आपको आराम से डेटा का भी ध्यान रखना होगा - डेटाबेस में संग्रहीत सभी डेटा। बाकी एन्क्रिप्शन पर डेटा HIPAA या PCI DSS जैसे सुरक्षा नियमों के लिए भी एक आवश्यकता हो सकती है। इस तरह के एन्क्रिप्शन को कई स्तरों पर लागू किया जा सकता है - आप पूरी डिस्क को एन्क्रिप्ट कर सकते हैं जिस पर फाइलें संग्रहीत हैं। आप MySQL या MariaDB के नवीनतम संस्करणों में उपलब्ध कार्यक्षमता के माध्यम से केवल MySQL डेटाबेस को एन्क्रिप्ट कर सकते हैं। एन्क्रिप्शन को एप्लिकेशन में भी लागू किया जा सकता है, ताकि यह डेटाबेस में संग्रहीत करने से पहले डेटा को एन्क्रिप्ट कर सके। प्रत्येक विकल्प के अपने फायदे और नुकसान हैं:डिस्क एन्क्रिप्शन केवल तभी मदद कर सकता है जब डिस्क भौतिक रूप से चोरी हो जाती है, लेकिन फ़ाइलों को चल रहे डेटाबेस सर्वर पर एन्क्रिप्ट नहीं किया जाएगा। MySQL डेटाबेस एन्क्रिप्शन इस समस्या को हल करता है, लेकिन जब रूट खाते से छेड़छाड़ की जाती है तो यह डेटा तक पहुंच को रोक नहीं सकता है। एप्लिकेशन स्तर एन्क्रिप्शन सबसे लचीला और सुरक्षित है, लेकिन फिर आप SQL की शक्ति खो देते हैं - WHERE या JOIN क्लॉज में एन्क्रिप्टेड कॉलम का उपयोग करना बहुत कठिन है।
MySQL के सभी फ्लेवर बाकी एन्क्रिप्शन पर किसी प्रकार का डेटा प्रदान करते हैं। Oracle का MySQL InnoDB टेबलस्पेस को एन्क्रिप्ट करने के लिए ट्रांसपेरेंट डेटा एन्क्रिप्शन का उपयोग करता है। यह वाणिज्यिक MySQL Enterprise पेशकश में उपलब्ध है। यह इनो डीबी टेबलस्पेस को एन्क्रिप्ट करने का एक विकल्प प्रदान करता है, अन्य फाइलें जो किसी न किसी रूप में डेटा स्टोर करती हैं (उदाहरण के लिए, बाइनरी लॉग, सामान्य लॉग, धीमी क्वेरी लॉग) एन्क्रिप्टेड नहीं हैं। यह टूलचेन (MySQL एंटरप्राइज़ बैकअप लेकिन साथ ही xtrabackup, mysqldump, mysqlbinlog) को ऐसे सेटअप के साथ सही ढंग से काम करने की अनुमति देता है।
MySQL 5.7.11 से शुरू होकर, MySQL के सामुदायिक संस्करण को भी InnoDB टेबलस्पेस एन्क्रिप्शन के लिए समर्थन मिला। उद्यम की पेशकश की तुलना में मुख्य अंतर कुंजी को संग्रहीत करने का तरीका है - चाबियाँ एक सुरक्षित तिजोरी में स्थित नहीं हैं, जो नियामक अनुपालन के लिए आवश्यक है। इसका मतलब है कि Percona Server 5.7.11 से शुरू होकर, InnoDB टेबलस्पेस को एन्क्रिप्ट करना भी संभव है। हाल ही में प्रकाशित Percona Server 5.7.20 में, बाइनरी लॉग को एन्क्रिप्ट करने के लिए समर्थन जोड़ा गया है। एक keyring_vault प्लगइन के माध्यम से हाशिकॉर्प वॉल्ट सर्वर के साथ एकीकृत करना भी संभव है, Oracle के MySQL एंटरप्राइज़ संस्करण में उपलब्ध सुविधाओं से मिलान (और यहां तक कि विस्तार - बाइनरी लॉग एन्क्रिप्शन)।
मारियाडीबी ने 10.1.3 में डेटा एन्क्रिप्शन के लिए समर्थन जोड़ा - यह एक अलग, उन्नत कार्यान्वयन है। यह आपको न केवल InnoDB टेबलस्पेस को एन्क्रिप्ट करने की संभावना देता है, बल्कि InnoDB लॉग फ़ाइलों को भी एन्क्रिप्ट करता है। नतीजतन, डेटा अधिक सुरक्षित है लेकिन कुछ उपकरण ऐसे कॉन्फ़िगरेशन में काम नहीं करेंगे। Xtrabackup एन्क्रिप्टेड रीडो लॉग के साथ काम नहीं करेगा - मारियाडीबी ने एक कांटा, मारियाडीबी बैकअप बनाया, जो मारियाडीबी एन्क्रिप्शन के लिए समर्थन जोड़ता है। mysqlbinlog के साथ भी समस्याएं हैं।
कोई फर्क नहीं पड़ता कि आप किस MySQL फ्लेवर का उपयोग करते हैं, जब तक कि यह एक हालिया संस्करण है, आपके पास डेटाबेस सर्वर के माध्यम से डेटा को बाकी एन्क्रिप्शन पर लागू करने के विकल्प होंगे, यह सुनिश्चित करते हुए कि आपका डेटा अतिरिक्त रूप से सुरक्षित है।
MySQL या MariaDB को सुरक्षित करना कोई मामूली बात नहीं है, लेकिन हमें उम्मीद है कि ये 10 टिप्स आपकी मदद करेंगे।
सारांश
आज के परिदृश्य में, डेटा सुरक्षा प्रत्येक डेटाबेस व्यवस्थापक के लिए सर्वोच्च प्राथमिकता है। चाहे आपकी प्रेरणा नियामक आवश्यकताओं का अनुपालन करना हो या अपने ग्राहकों और आपके व्यवसाय की प्रतिष्ठा की रक्षा करना हो, आपके MySQL और MariaDB डेटाबेस को सुरक्षित करने के लिए ये दस युक्तियाँ आपको अपने बुनियादी ढांचे को और सुरक्षित करने और आपको मानसिक शांति प्रदान करने में मदद करेंगी।
आपके डेटाबेस के बुनियादी ढांचे की सुरक्षा सुनिश्चित करते समय विचार करने के लिए कई उपाय हैं। इस पोस्ट में, हमने डेटा एन्क्रिप्शन, नेटवर्क एक्सेस कंट्रोल, उपयोगकर्ता प्रमाणीकरण और विशेषाधिकार, ऑपरेटिंग सिस्टम सुरक्षा, और बहुत कुछ जैसे बुनियादी बातों को कवर किया है।
ClusterControl जैसा डेटाबेस प्रबंधन ऑटोमेशन सॉफ़्टवेयर, आपके संपूर्ण डेटाबेस सुरक्षा प्रयासों में सहायता करने के लिए एक बेहतरीन टूल हो सकता है। यदि आप अपने MySQL डेटाबेस को सुरक्षित करने के लिए प्रत्येक चरण में गहराई से जाना चाहते हैं, तो MySQL को सुरक्षित कैसे करें पर हमारी श्रृंखला के भाग 1 और भाग 2 को देखना सुनिश्चित करें। अन्य डेटाबेस प्रबंधन सर्वोत्तम प्रथाओं के बारे में सूचित रहने के लिए, ट्विटर, लिंक्डइन पर हमें फॉलो करें और अपडेट के लिए हमारे न्यूज़लेटर की सदस्यता लें।
