क्या मेरे MySQL सर्वर कनेक्शन एन्क्रिप्टेड और सुरक्षित हैं?

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

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

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

जब आपको किसी नेटवर्क पर सुरक्षित तरीके से जानकारी को स्थानांतरित करना होता है, तो एक अनएन्क्रिप्टेड कनेक्शन अस्वीकार्य होता है। किसी भी प्रकार के डेटा को अपठनीय बनाने के लिए एन्क्रिप्शन का उपयोग करें। एन्क्रिप्शन एल्गोरिदम में कई प्रकार के ज्ञात हमलों का विरोध करने के लिए सुरक्षा तत्व शामिल होने चाहिए जैसे एन्क्रिप्टेड संदेशों का क्रम बदलना या डेटा को दो बार फिर से चलाना।

लेकिन मेरा MySQL सुरक्षित है, है ना?

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

यह निर्धारित करना कि क्या आपका MySQL सर्वर कनेक्शन यानी इन-ट्रांजिट सुरक्षित है या यदि यह एन्क्रिप्ट किया गया है, तो यह इस बात पर निर्भर करता है कि "आपने अपना डेटाबेस कैसे सेटअप किया?" या "आपका डेटाबेस कौन सेटअप करता है?"।

MySQL क्लाइंट और सर्वर के बीच एन्क्रिप्टेड कनेक्शन का समर्थन करता है जो TLS (ट्रांसपोर्ट लेयर सिक्योरिटी) प्रोटोकॉल का उपयोग करता है। टीएलएस को कभी-कभी एसएसएल (सिक्योर सॉकेट्स लेयर) के रूप में जाना जाता है, लेकिन MySQL वास्तव में एन्क्रिप्टेड कनेक्शन के लिए एसएसएल प्रोटोकॉल का उपयोग नहीं करता है क्योंकि इसका एन्क्रिप्शन कमजोर है और एसएसएल को पहले ही टीएलएस के पक्ष में हटा दिया गया है। टीएलएस यह सुनिश्चित करने के लिए एन्क्रिप्शन एल्गोरिदम का उपयोग करता है कि सार्वजनिक नेटवर्क पर प्राप्त डेटा पर भरोसा किया जा सकता है। इसमें डेटा परिवर्तन, हानि, या फिर से खेलना का पता लगाने के लिए तंत्र हैं। TLS में एल्गोरिदम भी शामिल हैं जो X.509 मानक का उपयोग करके पहचान सत्यापन प्रदान करते हैं। एसएसएल या टीएलएस का परस्पर उपयोग किया जा रहा है लेकिन MySQL के साथ एन्क्रिप्शन के संदर्भ में, टीएलएस का उपयोग किया जा रहा है जिसके लिए MySQL TLSv1, TLSv1.1, TLSv1.2, और TLSv1.3 प्रोटोकॉल का उपयोग करके एन्क्रिप्टेड कनेक्शन का समर्थन करता है।

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

ठीक उसी तरह जैसे स्पार्टन्स ने स्केटेल का इस्तेमाल किया

स्काईटेल को एक संदेश को एन्क्रिप्ट और डिक्रिप्ट करने के तरीके के रूप में उपयोग करने के लिए जाना जाता है जिसका उपयोग लगभग 400 ई.पू. स्पार्टन्स द्वारा। वे पेपिरस (एक प्रकार का कागज) की एक शीट पर एक संदेश लिखते थे जो एक कर्मचारी के चारों ओर लपेटा जाता था। प्राप्तकर्ता केवल तभी संदेश को समझ सकता है जब कर्मचारियों का सही व्यास और आकार हो। यह एन्क्रिप्ट करने और लक्षित गंतव्य पर संदेशों या डेटा के अनधिकृत निष्कर्षण से बचने के तरीके के रूप में कार्य करता है।

MySQL की तरह ही, SSL/TLS प्रोटोकॉल और सिफर का उपयोग करना किसी के द्वारा आपके डेटा को निकालने या आपके डेटा को हाईजैक करने से बचने का एक तरीका है क्योंकि यह वायर या इंटरनेट से गुजरता है।

डिफ़ॉल्ट रूप से, यदि सर्वर एन्क्रिप्टेड कनेक्शन का समर्थन करता है, तो MySQL प्रोग्राम एन्क्रिप्शन का उपयोग करके कनेक्ट करने का प्रयास करते हैं, यदि एन्क्रिप्टेड कनेक्शन स्थापित नहीं किया जा सकता है तो एक अनएन्क्रिप्टेड कनेक्शन पर वापस आ जाता है। संस्करण MySQL>=5.7 के बाद से, TLS/SSL और RSA फाइलें चरों के समर्थन से बनाई या उत्पन्न की जा सकती हैं। ओपनएसएसएल का उपयोग करके संकलित MySQL वितरण के लिए, MySQL सर्वर में स्टार्टअप पर लापता एसएसएल और आरएसए फाइलों को स्वचालित रूप से उत्पन्न करने की क्षमता है। Auto_generate_certs, sha256_password_auto_generate_rsa_keys, और caching_sha2_password_auto_generate_rsa_keys (संस्करण>=8.0), सिस्टम वेरिएबल इन फ़ाइलों की स्वचालित पीढ़ी को नियंत्रित करते हैं। ये चर डिफ़ॉल्ट रूप से सक्षम हैं। उन्हें स्टार्टअप पर सक्षम किया जा सकता है और निरीक्षण किया जा सकता है लेकिन रनटाइम पर सेट नहीं किया जा सकता है।

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

एक बार जब ये फ़ाइलें उपलब्ध हो जाती हैं और/या उत्पन्न हो जाती हैं, तो MySQL निम्न कारणों से एन्क्रिप्शन कनेक्शन का उपयोग नहीं करेगा। जैसा कि पहले उल्लेख किया गया है, डिफ़ॉल्ट रूप से, MySQL क्लाइंट प्रोग्राम एक एन्क्रिप्टेड कनेक्शन स्थापित करने का प्रयास करते हैं यदि सर्वर एन्क्रिप्टेड कनेक्शन का समर्थन करता है, आगे नियंत्रण के साथ --ssl-mode (या --ssl <=5.7.11 क्योंकि यह पहले से ही बहिष्कृत है) के माध्यम से उपलब्ध है। विकल्प:

डिफ़ॉल्ट रूप से, यदि MySQL कनेक्शन को --ssl-mode के साथ फ़्लैग नहीं किया जाता है, तो डिफ़ॉल्ट मान को सेट किया जाता है --ssl-मोड=पसंदीदा. इसलिए, यदि एन्क्रिप्टेड कनेक्शन स्थापित नहीं किया जा सकता है, तो क्लाइंट एन्क्रिप्शन का उपयोग करके कनेक्ट करने का प्रयास करते हैं, एक अनएन्क्रिप्टेड कनेक्शन पर वापस आते हैं।
--ssl-mode=REQUIRED के साथ, क्लाइंट को एक एन्क्रिप्टेड कनेक्शन की आवश्यकता होती है और यदि कोई स्थापित नहीं किया जा सकता है तो विफल हो जाता है।
--ssl-mode=DISABLED के साथ, क्लाइंट एक अनएन्क्रिप्टेड कनेक्शन का उपयोग करते हैं।
--ssl-mode=VERIFY_CA या --ssl-mode=VERIFY_IDENTITY के साथ, क्लाइंट को एक एन्क्रिप्टेड कनेक्शन की आवश्यकता होती है और इसके प्रमाणपत्र में सर्वर होस्ट नाम के विरुद्ध सर्वर CA प्रमाणपत्र और (VERIFY_IDENTITY के साथ) सत्यापन भी करते हैं।

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

जैसा कि पहले उल्लेख किया गया है, auto_generate_certs, sha256_password_auto_generate_rsa_keys, और caching_sha2_password_auto_generate_rsa_keys (संस्करण>=8.0) चर आवश्यक SSL/TLS और RSA फ़ाइलें उत्पन्न करने में मदद करते हैं, कनेक्शन के दौरान ऐसी किसी भी आवश्यकता के बिना सामान्य उपयोगकर्ता के साथ अभी भी होगा असुरक्षित। उदाहरण के लिए, चलिए dbadmin नाम का एक यूजर बनाते हैं।

mysql> create user 'dbadmin'@'192.168.40.%' identified by '[email protected]';
Query OK, 0 rows affected (0.01 sec)

mysql> GRANT ALL PRIVILEGES ON *.* TO 'dbadmin'@'192.168.40.%';
Query OK, 0 rows affected (0.01 sec)

फिर सत्यापित करें कि क्या वेरिएबल सही तरीके से सेट हैं जिन्हें सक्षम किया जाना चाहिए क्योंकि वे डिफ़ॉल्ट रूप से हैं:

mysql> show global variables where variable_name in ('auto_generate_certs','sha256_password_auto_generate_rsa_keys','caching_sha2_password_auto_generate_rsa_keys');
+----------------------------------------------+-------+
| Variable_name                                | Value |
+----------------------------------------------+-------+
| auto_generate_certs                          | ON    |
| caching_sha2_password_auto_generate_rsa_keys | ON    |
| sha256_password_auto_generate_rsa_keys       | ON    |
+----------------------------------------------+-------+
3 rows in set (0.00 sec)

यह सत्यापित करना कि फ़ाइलें तदनुसार पथ /var/lib/mysql/ (या इस MySQL के लिए डेटादिर का पथ) में उत्पन्न की गई हैं:

$ find /var/lib/mysql -name "*.pem"
/var/lib/mysql/ca-key.pem
/var/lib/mysql/ca.pem
/var/lib/mysql/server-key.pem
/var/lib/mysql/server-cert.pem
/var/lib/mysql/client-key.pem
/var/lib/mysql/client-cert.pem
/var/lib/mysql/private_key.pem
/var/lib/mysql/public_key.pem

फिर सत्यापित करें कि SSL फ़ाइलें सही तरीके से लोड की गई हैं:

mysql> show global variables like 'ssl%';
+---------------+-----------------+
| Variable_name | Value           |
+---------------+-----------------+
| ssl_ca        | ca.pem          |
| ssl_capath    |                 |
| ssl_cert      | server-cert.pem |
| ssl_cipher    |                 |
| ssl_crl       |                 |
| ssl_crlpath   |                 |
| ssl_fips_mode | OFF             |
| ssl_key       | server-key.pem  |
+---------------+-----------------+
8 rows in set (0.00 sec)

अपने कनेक्शन की सुरक्षा निर्धारित करें

अब, यह अच्छा लग रहा है। इसका मतलब यह भी है कि MySQL एन्क्रिप्टेड कनेक्शन स्वीकार करने के लिए तैयार है। लेकिन जैसा कि कहा गया है, MySQL से कनेक्ट करना डिफ़ॉल्ट रूप से --ssl-mode=PREFFERED का उपयोग करेगा, या यदि --ssl-mode निर्दिष्ट नहीं है, तो यह अभी भी एक अनएन्क्रिप्टेड कनेक्शन का उपयोग करने में विफल रहेगा। नीचे देखें:

$ mysql [email protected] -h 192.168.40.110 -udbadmin -e "status;"|grep ssl -i

एसएसएल: उपयोग में नहीं है

इससे पता चलता है कि यह सुरक्षित कनेक्शन का उपयोग नहीं कर रहा है। यदि किसी सिफर का उपयोग किया जाता है तो एसएसएल सत्र स्थिति चर की जाँच करने से पता चलता है कि यह खाली है:

mysql> show global status like 'ssl%';
+--------------------------------+--------------------------+
| Variable_name                  | Value                    |
+--------------------------------+--------------------------+
| Ssl_accept_renegotiates        | 0                        |
| Ssl_accepts                    | 2                        |
| Ssl_callback_cache_hits        | 0                        |
| Ssl_cipher                     |                          |
| Ssl_cipher_list                |                          |
| Ssl_client_connects            | 0                        |
| Ssl_connect_renegotiates       | 0                        |
| Ssl_ctx_verify_depth           | 18446744073709551615     |
| Ssl_ctx_verify_mode            | 5                        |
| Ssl_default_timeout            | 0                        |
| Ssl_finished_accepts           | 2                        |
| Ssl_finished_connects          | 0                        |
| Ssl_server_not_after           | Aug 28 12:48:46 2031 GMT |
| Ssl_server_not_before          | Aug 30 12:48:46 2021 GMT |
| Ssl_session_cache_hits         | 0                        |
| Ssl_session_cache_misses       | 0                        |
| Ssl_session_cache_mode         | SERVER                   |
| Ssl_session_cache_overflows    | 0                        |
| Ssl_session_cache_size         | 128                      |
| Ssl_session_cache_timeouts     | 0                        |
| Ssl_sessions_reused            | 0                        |
| Ssl_used_session_cache_entries | 0                        |
| Ssl_verify_depth               | 0                        |
| Ssl_verify_mode                | 0                        |
| Ssl_version                    |                          |
+--------------------------------+--------------------------+
25 rows in set (0.002 sec)

सुरक्षित कनेक्शन लागू करना

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

mysql> set global require_secure_transport=1;
Query OK, 0 rows affected (0.00 sec)

एक अनएन्क्रिप्टेड कनेक्शन का उपयोग करके क्लाइंट के रूप में कनेक्ट करने का प्रयास विफल हो जाएगा:

$ mysql [email protected] -h 192.168.40.110 -udbadmin
ERROR 3159 (HY000): Connections using insecure transport are prohibited while --require_secure_transport=ON.

सफलतापूर्वक और सुरक्षित रूप से कनेक्ट करने के लिए, आपको ssl-ca, ssl-cert, ssl-key चर निर्दिष्ट करने की आवश्यकता है। नीचे देखें:

$ mysql [email protected] -h 192.168.40.110 -udbadmin --ssl-ca=/tmp/pem/ca.pem --ssl-cert=/tmp/pem/server-cert.pem --ssl-key=/tmp/pem/server-key.pem -e "show global status like 'ssl%'\G"
*************************** 1. row ***************************
Variable_name: Ssl_accept_renegotiates
        Value: 0
*************************** 2. row ***************************
Variable_name: Ssl_accepts
        Value: 16
*************************** 3. row ***************************
Variable_name: Ssl_callback_cache_hits
        Value: 0
*************************** 4. row ***************************
Variable_name: Ssl_cipher
        Value: TLS_AES_256_GCM_SHA384
*************************** 5. row ***************************
Variable_name: Ssl_cipher_list
        Value: TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:TLS_AES_128_CCM_SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:DHE-RSA-AES128-SHA256:DHE-DSS-AES128-SHA256:DHE-DSS-AES256-GCM-SHA384:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-DSS-AES128-SHA:DHE-RSA-AES128-SHA:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES256-SHA:CAMELLIA256-SHA:CAMELLIA128-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA
*************************** 6. row ***************************
Variable_name: Ssl_client_connects
        Value: 0
*************************** 7. row ***************************
Variable_name: Ssl_connect_renegotiates
        Value: 0
*************************** 8. row ***************************
Variable_name: Ssl_ctx_verify_depth
        Value: 18446744073709551615
*************************** 9. row ***************************
Variable_name: Ssl_ctx_verify_mode
        Value: 5
*************************** 10. row ***************************
Variable_name: Ssl_default_timeout
        Value: 7200
*************************** 11. row ***************************
Variable_name: Ssl_finished_accepts
        Value: 11
*************************** 12. row ***************************
Variable_name: Ssl_finished_connects
        Value: 0
*************************** 13. row ***************************
Variable_name: Ssl_server_not_after
        Value: Aug 28 12:48:46 2031 GMT
*************************** 14. row ***************************
Variable_name: Ssl_server_not_before
        Value: Aug 30 12:48:46 2021 GMT
*************************** 15. row ***************************
Variable_name: Ssl_session_cache_hits
        Value: 0
*************************** 16. row ***************************
Variable_name: Ssl_session_cache_misses
        Value: 0
*************************** 17. row ***************************
Variable_name: Ssl_session_cache_mode
        Value: SERVER
*************************** 18. row ***************************
Variable_name: Ssl_session_cache_overflows
        Value: 0
*************************** 19. row ***************************
Variable_name: Ssl_session_cache_size
        Value: 128
*************************** 20. row ***************************
Variable_name: Ssl_session_cache_timeouts
        Value: 0
*************************** 21. row ***************************
Variable_name: Ssl_sessions_reused
        Value: 0
*************************** 22. row ***************************
Variable_name: Ssl_used_session_cache_entries
        Value: 0
*************************** 23. row ***************************
Variable_name: Ssl_verify_depth
        Value: 18446744073709551615
*************************** 24. row ***************************
Variable_name: Ssl_verify_mode
        Value: 5
*************************** 25. row ***************************
Variable_name: Ssl_version
        Value: TLSv1.3

वैकल्पिक रूप से, उदाहरण के लिए, यदि कोई उपयोगकर्ता REQUIRED SSL के साथ बनाया गया है, तो वह आपको SSL का उपयोग करके भी कनेक्ट करेगा, भले ही आवश्यकता_सिक्योर_ट्रांसपोर्ट अक्षम हो, जो इसका डिफ़ॉल्ट मान है। ध्यान दें कि, यदि आवश्यकता_सिक्योर_ट्रांसपोर्ट सक्षम है, तो इसकी क्षमता प्रति-खाता एसएसएल आवश्यकताओं को पूरक करती है, जिन्हें प्राथमिकता दी जाती है। इसलिए, यदि किसी खाते को REQUIRE SSL के साथ परिभाषित किया गया है, तो requ_secure_transport को सक्षम करने से यूनिक्स सॉकेट फ़ाइल का उपयोग करके कनेक्ट करने के लिए खाते का उपयोग करना संभव नहीं हो जाता है।

सुनिश्चित करना कि MySQL सर्वर परिनियोजन एन्क्रिप्टेड और सुरक्षित हैं

परेशानी-मुक्त वह है जिसके लिए हम हमेशा तत्पर रहते हैं ताकि चिंता करने के लिए कोई अन्य समस्या और चिंताएं न हों। ClusterControl एन्क्रिप्टेड कनेक्शन का उपयोग करके MySQL डेटाबेस को तैनात करता है और आपके लिए SSL और RSA प्रमाणपत्र बनाता है। उदाहरण के लिए, नीचे दिया गया एक स्क्रीनशॉट आपको ClusterControl से क्लस्टर बनाएँ कमांड की कार्य गतिविधि दिखा रहा है।

यह एसएसएल और आरएसए फाइलों को सेट करता है और उन्हें /etc/ में रखता है। mysql/certs/पथ बिल्कुल नीचे की तरह:

mysql> show global variables like 'ssl%';
+---------------+--------------------------------+
| Variable_name | Value                          |
+---------------+--------------------------------+
| ssl_ca        | /etc/mysql/certs/server_ca.crt |
| ssl_capath    |                                |
| ssl_cert      | /etc/mysql/certs/server.crt    |
| ssl_cipher    |                                |
| ssl_crl       |                                |
| ssl_crlpath   |                                |
| ssl_key       | /etc/mysql/certs/server.key    |
+---------------+--------------------------------+
7 rows in set (0.00 sec)

तब ClusterControl नीचे दिखाए गए अनुसार कुंजी प्रबंधन नेविगेशन पैनल के अंतर्गत जेनरेट की गई SSL और RSA फ़ाइलों को एक केंद्रीकृत तरीके से समूहित करता है:

एक बार परिनियोजित करने के बाद, आपको बस इतना करना है कि या तो REQUIRED SSL के साथ उपयोगकर्ता बनाएं या यदि आप अपने MySQL सर्वर कनेक्शन के लिए एक एन्क्रिप्टेड और सुरक्षित परत लागू करना चाहते हैं तो requ_secure_transport होना चाहिए।