इस ब्लॉग श्रृंखला में, हम आपको पूरी तरह से एन्क्रिप्टेड मारियाडीबी सर्वर को एट-रेस्ट और इन-ट्रांजिट एन्क्रिप्शन के लिए कॉन्फ़िगर करने के तरीके पर एक संपूर्ण वॉकथ्रू देने जा रहे हैं, ताकि डेटा की अधिकतम सुरक्षा सुनिश्चित हो सके। शारीरिक रूप से चोरी या अन्य मेजबानों के साथ स्थानांतरण और संचार करते समय। मूल विचार यह है कि हम अपने "सादे" परिनियोजन को पूरी तरह से एन्क्रिप्टेड मारियाडीबी प्रतिकृति में बदलने जा रहे हैं, जैसा कि निम्नलिखित आरेख में सरल है:
हम कई एन्क्रिप्शन घटकों को कॉन्फ़िगर करने जा रहे हैं:
- इन-ट्रांजिट एन्क्रिप्शन, जिसमें निम्न शामिल हैं:
- क्लाइंट-सर्वर एन्क्रिप्शन
- प्रतिकृति एन्क्रिप्शन
- एट-रेस्ट एन्क्रिप्शन, जिसमें निम्न शामिल हैं:
- डेटा फ़ाइल एन्क्रिप्शन
- बाइनरी/रिले लॉग एन्क्रिप्शन।
ध्यान दें कि यह ब्लॉग पोस्ट केवल पारगमन एन्क्रिप्शन को कवर करता है। हम इस ब्लॉग श्रृंखला के दूसरे भाग में आराम से एन्क्रिप्शन को कवर करने जा रहे हैं।
इस परिनियोजन पूर्वाभ्यास ने माना कि हमारे पास पहले से ही एक मारियाडीबी प्रतिकृति सर्वर चल रहा है। यदि आपके पास एक नहीं है, तो आप 5 से कम क्लिक के साथ मिनटों के भीतर एक नया मारियाडीबी प्रतिकृति तैनात करने के लिए क्लस्टरकंट्रोल का उपयोग कर सकते हैं। सभी सर्वर मारियाडीबी 10.4.11 पर CentOS 7 सिस्टम पर चल रहे हैं।
इन-ट्रांजिट एन्क्रिप्शन
डेटा को ट्रांज़िट और आराम दोनों समय में जोखिम का सामना करना पड़ सकता है और दोनों राज्यों में सुरक्षा की आवश्यकता होती है। इन-ट्रांजिट एन्क्रिप्शन आपके डेटा की सुरक्षा करता है यदि संचार को इंटरसेप्ट किया जाता है, जबकि डेटा नेटवर्क के माध्यम से होस्ट के बीच, आपकी साइट और क्लाउड प्रदाता से, सेवाओं के बीच या क्लाइंट और सर्वर के बीच स्थानांतरित होता है।
MySQL/MariaDB के लिए, डेटा तब गति में होता है जब कोई क्लाइंट डेटाबेस सर्वर से कनेक्ट होता है, या जब कोई स्लेव नोड मास्टर नोड से डेटा की प्रतिकृति बनाता है। मारियाडीबी टीएलएस (ट्रांसपोर्ट लेयर सिक्योरिटी) प्रोटोकॉल का उपयोग करके क्लाइंट और सर्वर के बीच एन्क्रिप्टेड कनेक्शन का समर्थन करता है। टीएलएस को कभी-कभी एसएसएल (सिक्योर सॉकेट्स लेयर) के रूप में जाना जाता है, लेकिन मारियाडीबी वास्तव में एन्क्रिप्टेड कनेक्शन के लिए एसएसएल प्रोटोकॉल का उपयोग नहीं करता है क्योंकि इसका एन्क्रिप्शन कमजोर है। इसके बारे में अधिक जानकारी MariaDB दस्तावेज़ीकरण पृष्ठ पर है।
क्लाइंट-सर्वर एन्क्रिप्शन
इस सेटअप में हम स्व-हस्ताक्षरित प्रमाणपत्रों का उपयोग करने जा रहे हैं, जिसका अर्थ है कि हम अपनी पहचान सत्यापित करने के लिए Google, कोमोडो या किसी भी लोकप्रिय प्रमाणपत्र प्राधिकरण प्रदाता जैसे बाहरी पक्षों का उपयोग नहीं करते हैं। एसएसएल/टीएलएस में, पहचान सत्यापन पहला कदम है जिसे सर्वर और क्लाइंट द्वारा अपने प्रमाणपत्रों और चाबियों का आदान-प्रदान करने से पहले पारित किया जाना चाहिए।
MySQL mysql_ssl_rsa_setup नामक एक बहुत ही आसान टूल प्रदान करता है जो स्वचालित रूप से कुंजी और प्रमाणपत्र निर्माण का ख्याल रखता है। दुर्भाग्य से, मारियाडीबी सर्वर के लिए अभी तक ऐसा कोई उपकरण नहीं है। इसलिए, हमें अपनी मारियाडीबी टीएलएस जरूरतों के लिए एसएसएल-संबंधित फाइलों को मैन्युअल रूप से तैयार और उत्पन्न करना होगा।
निम्नलिखित फाइलों की एक सूची है जिसे हम OpenSSL टूल का उपयोग करके जेनरेट करेंगे:
- CA key - पीईएम प्रारूप में आरएसए निजी कुंजी। गुप्त रखा जाना चाहिए।
- CA प्रमाणपत्र - पीईएम प्रारूप में X.509 प्रमाणपत्र। सार्वजनिक कुंजी और प्रमाणपत्र मेटाडेटा शामिल है।
- सर्वर CSR - प्रमाणपत्र हस्ताक्षर अनुरोध। फ़ॉर्म भरते समय सामान्य नाम (CN) महत्वपूर्ण है, उदाहरण के लिए CN=mariadb-server
- सर्वर कुंजी - आरएसए निजी कुंजी। गुप्त रखा जाना चाहिए।
- सर्वर प्रमाणपत्र - सीए कुंजी द्वारा हस्ताक्षरित X.509 प्रमाणपत्र। सार्वजनिक कुंजी और प्रमाणपत्र मेटाडेटा शामिल है।
- क्लाइंट CSR - प्रमाणपत्र हस्ताक्षर अनुरोध। सर्वर के CSR से भिन्न सामान्य नाम (CN) का उपयोग करना चाहिए, उदाहरण के लिए CN=client1
- क्लाइंट कुंजी - आरएसए निजी कुंजी। गुप्त रखा जाना चाहिए।
- क्लाइंट प्रमाणपत्र - सीए कुंजी द्वारा हस्ताक्षरित X.509 प्रमाणपत्र। सार्वजनिक कुंजी और प्रमाणपत्र मेटाडेटा शामिल है।
सबसे पहले और सबसे महत्वपूर्ण, इन-ट्रांजिट एन्क्रिप्शन के लिए हमारे प्रमाणपत्रों और कुंजियों को संग्रहीत करने के लिए एक निर्देशिका बनाएं:
$ mkdir -p /etc/mysql/transit/
$ cd /etc/mysql/transit/
आपको केवल यह बताने के लिए कि हम निर्देशिका का नाम क्यों बताते हैं, क्योंकि इस ब्लॉग श्रृंखला के अगले भाग में, हम /etc/mysql/rest पर एट-रेस्ट एन्क्रिप्शन के लिए एक और निर्देशिका बनाएंगे।
प्रमाणपत्र प्राधिकरण
हमारे अपने प्रमाणपत्र प्राधिकरण (CA) के लिए एक कुंजी फ़ाइल जेनरेट करें:
$ openssl genrsa 2048 > ca-key.pem
Generating RSA private key, 2048 bit long modulus
.......................+++
...............................................................................................................................................................................................................................................+++
e is 65537 (0x10001)
3650 दिनों की समाप्ति के साथ पहले जेनरेट किए गए ca-key.pem के आधार पर हमारे अपने सर्टिफिकेट अथॉरिटी (CA) के लिए सर्टिफिकेट जेनरेट करें:
$ openssl req -new -x509 -nodes -days 3650 -key ca-key.pem -out ca.pem
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [XX]:SE
State or Province Name (full name) []:Stockholm
Locality Name (eg, city) [Default City]:Stockholm
Organization Name (eg, company) [Default Company Ltd]:Severalnines
Organizational Unit Name (eg, section) []:
Common Name (eg, your name or your server's hostname) []:CA
Email Address []:[email protected]
अब हमारे पास इस कार्यशील निर्देशिका के अंतर्गत ca-key.pem और ca.pem होना चाहिए।
सर्वर के लिए कुंजी और प्रमाणपत्र
अगला, MariaDB सर्वर के लिए निजी कुंजी जेनरेट करें:
$ openssl genrsa 2048 > server-key.pem
Generating RSA private key, 2048 bit long modulus
.............................................................................................................+++
..................................................................................................................+++
e is 65537 (0x10001)
एक विश्वसनीय प्रमाणपत्र एक प्रमाणपत्र प्राधिकरण द्वारा हस्ताक्षरित एक प्रमाणपत्र होना चाहिए जिससे यहां, हम अपने स्वयं के सीए का उपयोग करने जा रहे हैं क्योंकि हम नेटवर्क में मेजबानों पर भरोसा करते हैं। इससे पहले कि हम एक हस्ताक्षरित प्रमाणपत्र बना सकें, हमें सर्टिफिकेट साइनिंग रिक्वेस्ट (CSR) नामक एक अनुरोध प्रमाणपत्र जेनरेट करना होगा।
मारियाडीबी सर्वर के लिए एक सीएसआर बनाएं। हम प्रमाणपत्र को सर्वर-req.pem के रूप में कॉल करने जा रहे हैं। यह वह प्रमाणपत्र नहीं है जिसका उपयोग हम मारियाडीबी सर्वर के लिए करने जा रहे हैं। अंतिम प्रमाणपत्र वह है जिस पर हमारी अपनी CA निजी कुंजी द्वारा हस्ताक्षर किए जाएंगे (जैसा कि अगले चरण में दिखाया गया है):
$ openssl req -new -key server-key.pem -out server-req.pem
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [XX]:SE
State or Province Name (full name) []:Stockholm
Locality Name (eg, city) [Default City]:Stockholm
Organization Name (eg, company) [Default Company Ltd]:Severalnines
Organizational Unit Name (eg, section) []:
Common Name (eg, your name or your server's hostname) []:MariaDBServer
Email Address []:[email protected]
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
उस सामान्य नाम पर ध्यान दें जहां हमने "MariaDBServer" निर्दिष्ट किया था। यह कोई भी नाम हो सकता है लेकिन मान क्लाइंट प्रमाणपत्र के समान नहीं होना चाहिए। आम तौर पर, यदि एप्लिकेशन FQDN या होस्टनाम (स्किप-नाम-समाधान =OFF) के माध्यम से मारियाडीबी सर्वर से जुड़ते हैं, तो आप शायद मारियाडीबी सर्वर के एफक्यूडीएन को सामान्य नाम के रूप में निर्दिष्ट करना चाहते हैं।
फिर हम अंतिम X.509 प्रमाणपत्र (सर्वर-सर्टिफिकेट.पेम) जेनरेट कर सकते हैं और सीए के प्रमाणपत्र (सीए.पीईएम) और सीए की निजी कुंजी (सीए) के साथ सीएसआर (सर्वर-req.pem) पर हस्ताक्षर कर सकते हैं। -key.pem):
$ openssl x509 -req -in server-req.pem -CA ca.pem -CAkey ca-key.pem -CAcreateserial -out server-cert.pem -days 3650 -sha256
Signature ok
subject=/C=SE/ST=Stockholm/L=Stockholm/O=Severalnines/CN=MariaDBServer/[email protected]
Getting CA Private Key
इस समय, हमारे पास अब यही है:
$ ls -1 /etc/mysql/transite
ca-key.pem
ca.pem
server-cert.pem
server-key.pem
server-req.pem
हमें केवल CA प्रमाणपत्र (ca.pem), सर्वर के हस्ताक्षरित प्रमाणपत्र (server-cert.pem) और मारियाडीबी सर्वर के लिए सर्वर की निजी कुंजी (server-key.pem) की आवश्यकता है। CSR (सर्वर-req.pem) की अब आवश्यकता नहीं है।
ग्राहक के लिए कुंजी और प्रमाणपत्र
अगला, हमें MariaDB क्लाइंट के लिए कुंजी और प्रमाणपत्र फ़ाइलें जेनरेट करने की आवश्यकता है। मारियाडीबी सर्वर केवल उस क्लाइंट से रिमोट कनेक्शन स्वीकार करेगा जिसके पास ये प्रमाणपत्र फाइलें हैं।
क्लाइंट के लिए 2048-बिट कुंजी जनरेट करके प्रारंभ करें:
$ openssl genrsa 2048 > client-key.pem
Generating RSA private key, 2048 bit long modulus
.............................................................................................................+++
..................................................................................................................+++
e is 65537 (0x10001)
क्लाइंट-req.pem नामक क्लाइंट के लिए सीएसआर बनाएं:
$ openssl req -new -key client-key.pem -out client-req.pem
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [XX]:SE
State or Province Name (full name) []:Stockholm
Locality Name (eg, city) [Default City]:Stockholm
Organization Name (eg, company) [Default Company Ltd]:Severalnines
Organizational Unit Name (eg, section) []:
Common Name (eg, your name or your server's hostname) []:Client1
Email Address []:[email protected]
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
सामान्य नाम पर ध्यान दें जहां हम "क्लाइंट1" निर्दिष्ट करते हैं। क्लाइंट का प्रतिनिधित्व करने वाला कोई भी नाम निर्दिष्ट करें। यह मान सर्वर के सामान्य नाम से भिन्न होना चाहिए। उन्नत उपयोग के लिए, आप इस सामान्य नाम का उपयोग इस मान से मेल खाने वाले प्रमाणपत्र वाले कुछ उपयोगकर्ता को अनुमति देने के लिए कर सकते हैं, उदाहरण के लिए:
MariaDB> GRANT SELECT ON schema1.* TO 'client1'@'192.168.0.93' IDENTIFIED BY 's' REQUIRE SUBJECT '/CN=Client2';
फिर हम अंतिम X.509 प्रमाणपत्र (client-cert.pem) जेनरेट कर सकते हैं और CA के प्रमाणपत्र (ca.pem) और CA की निजी कुंजी (ca) के साथ CSR (क्लाइंट-req.pem) पर हस्ताक्षर कर सकते हैं। -key.pem):
$ openssl x509 -req -in client-req.pem -CA ca.pem -CAkey ca-key.pem -CAcreateserial -out client-cert.pem -days 3650 -sha256
Signature ok
subject=/C=SE/ST=Stockholm/L=Stockholm/O=Severalnines/CN=Client1/[email protected]
Getting CA Private Key
इन-ट्रांजिट एन्क्रिप्शन सेटअप के लिए आवश्यक सभी प्रमाणपत्र जेनरेट किए जाते हैं। सत्यापित करें कि दोनों प्रमाणपत्र सीए द्वारा सही ढंग से हस्ताक्षरित हैं:
$ openssl verify -CAfile ca.pem server-cert.pem client-cert.pem
server-cert.pem: OK
client-cert.pem: OK
SSL को MariaDB के लिए कॉन्फ़िगर करना
हर गुलाम पर एक नई निर्देशिका बनाएं:
(slave1)$ mkdir -p /etc/mysql/transit/
(slave2)$ mkdir -p /etc/mysql/transit/
एन्क्रिप्शन फाइलों को सभी गुलामों में कॉपी करें:
$ scp -r /etc/mysql/transit/* [email protected]:/etc/mysql/transit/
$ scp -r /etc/mysql/transit/* [email protected]:/etc/mysql/transit/
सुनिश्चित करें कि "mysql" उपयोगकर्ता के लिए certs निर्देशिका का स्वामी है और सभी प्रमुख फ़ाइलों की अनुमतियों को बदल दें ताकि यह विश्व स्तर पर पढ़ने योग्य न हो:
$ cd /etc/mysql/transit
$ chown -R mysql:mysql *
$ chmod 600 client-key.pem server-key.pem ca-key.pem
यहां बताया गया है कि "ट्रांजिट" निर्देशिका के तहत फाइलों को सूचीबद्ध करते समय आपको क्या देखना चाहिए:
$ ls -al /etc/mysql/transit
total 32
drwxr-xr-x. 2 root root 172 Dec 14 04:42 .
drwxr-xr-x. 3 root root 24 Dec 14 04:18 ..
-rw-------. 1 mysql mysql 1675 Dec 14 04:19 ca-key.pem
-rw-r--r--. 1 mysql mysql 1383 Dec 14 04:22 ca.pem
-rw-r--r--. 1 mysql mysql 1383 Dec 14 04:42 client-cert.pem
-rw-------. 1 mysql mysql 1675 Dec 14 04:42 client-key.pem
-rw-r--r--. 1 mysql mysql 1399 Dec 14 04:42 client-req.pem
-rw-r--r--. 1 mysql mysql 1391 Dec 14 04:34 server-cert.pem
-rw-------. 1 mysql mysql 1679 Dec 14 04:28 server-key.pem
-rw-r--r--. 1 mysql mysql 1415 Dec 14 04:31 server-req.pem
अगला, हम मारियाडीबी के लिए एसएसएल कनेक्शन को सक्षम करेंगे। प्रत्येक MariaDB होस्ट (मास्टर और दास) पर कॉन्फ़िगरेशन फ़ाइल संपादित करें और [mysqld] अनुभाग के अंतर्गत निम्न पंक्तियाँ जोड़ें:
ssl-ca=/etc/mysql/transit/ca.pem
ssl-cert=/etc/mysql/transit/server-cert.pem
ssl-key=/etc/mysql/transit/server-key.pem
MariaDB सर्वर को एक बार में एक नोड को रीस्टार्ट करें, स्लेव से शुरू होकर अंत में मास्टर पर:
(slave1)$ systemctl restart mariadb
(slave2)$ systemctl restart mariadb
(master)$ systemctl restart mariadb
पुनरारंभ करने के बाद, मारियाडीबी अब बिना किसी एसएसएल-संबंधित पैरामीटर के या एन्क्रिप्टेड कनेक्शन के साथ कनेक्ट करके सादे कनेक्शन स्वीकार करने में सक्षम है, जब आप कनेक्शन स्ट्रिंग में एसएसएल-संबंधित पैरामीटर निर्दिष्ट करते हैं।
ClusterControl उपयोगकर्ताओं के लिए, आप क्लिक के मामले में क्लाइंट-सर्वर एन्क्रिप्शन को सक्षम कर सकते हैं। बस क्लस्टरकंट्रोल -> सुरक्षा -> एसएसएल एन्क्रिप्शन -> सक्षम करें -> प्रमाणपत्र बनाएं -> प्रमाणपत्र समाप्ति -> एसएसएल सक्षम करें पर जाएं:
ClusterControl आवश्यक कुंजी, X.509 प्रमाणपत्र और CA प्रमाणपत्र जेनरेट करेगा और क्लस्टर में सभी नोड्स के लिए क्लाइंट-सर्वर कनेक्शन के लिए एसएसएल एन्क्रिप्शन सेट करें। MySQL/MariaDB प्रतिकृति के लिए, SSL फ़ाइलें /etc/ssl/replication/cluster_X के अंतर्गत स्थित होंगी, जहां X प्रत्येक डेटाबेस नोड पर क्लस्टर आईडी है। सभी नोड्स पर समान प्रमाणपत्रों का उपयोग किया जाएगा और मौजूदा प्रमाणपत्रों को अधिलेखित किया जा सकता है। इस कार्य के पूर्ण होने के बाद नोड्स को व्यक्तिगत रूप से पुनरारंभ करना होगा। हम अनुशंसा करते हैं कि आप पहले एक प्रतिकृति दास को पुनरारंभ करें और सत्यापित करें कि एसएसएल सेटिंग्स काम करती हैं।
हर नोड को रीस्टार्ट करने के लिए, ClusterControl -> Nodes -> Node Actions -> Restart Node. दासों से शुरू करते हुए, एक समय में एक नोड को पुनरारंभ करें। अंतिम नोड मास्टर नोड होना चाहिए जिसमें फ़ोर्स स्टॉप फ़्लैग सक्षम हो:
आप यह बता सकते हैं कि कोई नोड क्लाइंट-सर्वर एन्क्रिप्शन को संभालने में सक्षम है या नहीं ओवरव्यू ग्रिड में डेटाबेस नोड के ठीक बगल में हरे रंग के लॉक आइकन को देख रहे हैं:
इस बिंदु पर, हमारा क्लस्टर अब MySQL से SSL कनेक्शन स्वीकार करने के लिए तैयार है उपयोगकर्ता।
एन्क्रिप्टेड कनेक्शन के माध्यम से कनेक्ट करना
मारियाडीबी क्लाइंट को क्लाइंट से संबंधित सभी एसएसएल फाइलों की आवश्यकता होती है जो हमने सर्वर के अंदर उत्पन्न की हैं। उत्पन्न क्लाइंट प्रमाणपत्र, CA प्रमाणपत्र और क्लाइंट कुंजी को क्लाइंट होस्ट में कॉपी करें:
$ cd /etc/mysql/transit
$ scp client-cert.pem client-key.pem ca.pem [email protected]:~
**ClusterControl क्लाइंट एसएसएल फाइलों को /etc/ssl/replication/cluster_X/ के तहत हर डेटाबेस नोड पर जेनरेट करता है, जहां X क्लस्टर आईडी है।
एक डेटाबेस उपयोगकर्ता बनाएं जिसके लिए मास्टर पर एसएसएल की आवश्यकता हो:
MariaDB> CREATE SCHEMA sbtest;
MariaDB> CREATE USER [email protected]'%' IDENTIFIED BY 'mysecr3t' REQUIRE SSL;
MariaDB> GRANT ALL PRIVILEGES ON sbtest.* to [email protected]'%';
क्लाइंट होस्ट से, SSL-संबंधित पैरामीटर के साथ MariaDB सर्वर से कनेक्ट करें। हम "STATUS" स्टेटमेंट का उपयोग करके कनेक्शन की स्थिति को सत्यापित कर सकते हैं:
(client)$ mysql -usbtest -p -h192.168.0.91 -P3306 --ssl-cert client-cert.pem --ssl-key client-key.pem --ssl-ca ca.pem -e 'status'
...
Current user: [email protected]
SSL: Cipher in use is DHE-RSA-AES256-GCM-SHA384
...
एसएसएल लाइन पर ध्यान दें जहां एन्क्रिप्शन के लिए सिफर का उपयोग किया जाता है। इसका मतलब है कि क्लाइंट एन्क्रिप्टेड कनेक्शन के माध्यम से मारियाडीबी सर्वर से सफलतापूर्वक जुड़ा हुआ है।
इस बिंदु पर, हमने क्लाइंट-सर्वर कनेक्शन को MariaDB सर्वर से एन्क्रिप्ट किया है, जैसा कि निम्नलिखित आरेख में हरे दो-सिर वाले तीर द्वारा दर्शाया गया है:
अगले भाग में, हम नोड्स के बीच प्रतिकृति कनेक्शन एन्क्रिप्ट करने जा रहे हैं।
प्रतिकृति एन्क्रिप्शन
प्रतिकृति के लिए एन्क्रिप्टेड कनेक्शन सेट करना क्लाइंट/सर्वर कनेक्शन के लिए ऐसा करने के समान है। हम उसी क्लाइंट प्रमाणपत्र, कुंजी और सीए प्रमाणपत्र का उपयोग कर सकते हैं ताकि प्रतिकृति उपयोगकर्ता एन्क्रिप्शन चैनल के माध्यम से मास्टर के सर्वर तक पहुंच सके। यह अप्रत्यक्ष रूप से नोड्स के बीच एन्क्रिप्शन को सक्षम करेगा जब दास IO थ्रेड मास्टर से प्रतिकृति घटनाओं को खींचता है।
आइए इसे एक बार में एक स्लेव पर कॉन्फ़िगर करें। पहले दास के लिए, 192.168.0.92, MariaDB कॉन्फ़िगरेशन फ़ाइल के अंदर [क्लाइंट] अनुभाग के अंतर्गत निम्न पंक्ति जोड़ें:
[client]
ssl-ca=/etc/mysql/transit/ca.pem
ssl-cert=/etc/mysql/transit/client-cert.pem
ssl-key=/etc/mysql/transit/client-key.pem
गुलाम पर प्रतिकृति धागा बंद करो:
(slave)MariaDB> STOP SLAVE;
मास्टर पर, मौजूदा प्रतिकृति उपयोगकर्ता को SSL का उपयोग करके कनेक्ट करने के लिए बाध्य करने के लिए उसे बदलें:
(master)MariaDB> ALTER USER [email protected] REQUIRE SSL;
दास पर, मास्टर से कनेक्टिविटी का परीक्षण करें, 192.168.0.91 mysql कमांड लाइन के माध्यम से --ssl ध्वज के साथ:
(slave)MariaDB> mysql -urpl_user -p -h192.168.0.91 -P 3306 --ssl -e 'status'
...
Current user: [email protected]
SSL: Cipher in use is DHE-RSA-AES256-GCM-SHA384
...
सुनिश्चित करें कि आप बिना किसी त्रुटि के मास्टर होस्ट से जुड़ सकते हैं। फिर, स्लेव पर, नीचे दिए गए SSL पैरामीटर के साथ CHANGE MASTER स्टेटमेंट निर्दिष्ट करें:
(slave)MariaDB> CHANGE MASTER TO MASTER_SSL = 1, MASTER_SSL_CA = '/etc/mysql/transit/ca.pem', MASTER_SSL_CERT = '/etc/mysql/transit/client-cert.pem', MASTER_SSL_KEY = '/etc/mysql/transit/client-key.pem';
प्रतिकृति स्लेव प्रारंभ करें:
(slave)MariaDB> START SLAVE;
सत्यापित करें कि संबंधित SSL पैरामीटर के साथ प्रतिकृति ठीक चल रही है:
MariaDB> SHOW SLAVE STATUS\G
...
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Master_SSL_Allowed: Yes
Master_SSL_CA_File: /etc/mysql/transit/ca.pem
Master_SSL_Cert: /etc/mysql/transit/client-cert.pem
Master_SSL_Key: /etc/mysql/transit/client-key.pem
...
दास अब टीएलएस एन्क्रिप्शन के माध्यम से मास्टर से सुरक्षित रूप से नकल कर रहा है।
उपरोक्त सभी चरणों को शेष दास पर दोहराएं, 192.168.0.93। फर्क सिर्फ इतना है कि मास्टर पर निष्पादित किए जाने वाले उपयोगकर्ता के बयान को बदल दिया जाता है, जहां हमें इसके संबंधित होस्ट में बदलना होता है:
(master)MariaDB> ALTER USER [email protected] REQUIRE SSL;
इस बिंदु पर हमने इन-ट्रांजिट एन्क्रिप्शन को पूरा कर लिया है जैसा कि निम्नलिखित आरेख में मास्टर से दास तक हरी रेखाओं द्वारा दिखाया गया है:
आप इंटरफ़ेस eth1 के लिए tcpdump आउटपुट को देखकर एन्क्रिप्शन कनेक्शन को सत्यापित कर सकते हैं गुलाम पर। निम्नलिखित एन्क्रिप्शन के बिना मानक प्रतिकृति का एक उदाहरण है:
(plain-slave)$ tcpdump -i eth1 -s 0 -l -w - 'src port 3306 or dst port 3306' | strings
tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 262144 bytes
H"-'
binlog.000008Ulw
binlog.000008Ulw
sbtest
sbtest
create table t1 (id INT AUTO_INCREMENT PRIMARY KEY, data VARCHAR(255))
binlog.000008
sbtest
BEGIN3
sbtest
test data3
Ok*Z
binlog.000008*Z
^C11 packets captured
11 packets received by filter
0 packets dropped by kernel
हम उस पाठ को स्पष्ट रूप से देख सकते हैं जैसा कि दास द्वारा स्वामी द्वारा पढ़ा गया था। एन्क्रिप्टेड कनेक्शन पर, आपको नीचे की तरह अस्पष्ट वर्ण दिखाई देने चाहिए:
(encrypted-slave)$ tcpdump -i eth1 -s 0 -l -w - 'src port 3306 or dst port 3306' | strings
tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 262144 bytes
:|f^yb#
O5~_
@#PFh
k)]O
jtk3c
@NjN9_a
!\[email protected]
NrF
?7&Y
^C6 packets captured
6 packets received by filter
0 packets dropped by kernel
निष्कर्ष
इस ब्लॉग श्रृंखला के अगले भाग में, हम अपने पूरी तरह से एन्क्रिप्टेड सेटअप को मारियाडीबी एट-रेस्ट एन्क्रिप्शन के साथ पूरा करने पर विचार करने जा रहे हैं। बने रहें!