ClusterControl सर्वर को कैसे सुरक्षित करें

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

फ़ायरवॉल और सुरक्षा समूह

सबसे पहले और सबसे महत्वपूर्ण, हमें सभी अनावश्यक बंदरगाहों को बंद करना चाहिए और केवल क्लस्टर नियंत्रण द्वारा उपयोग किए जाने वाले आवश्यक बंदरगाहों को खोलना चाहिए। आंतरिक रूप से, ClusterControl और डेटाबेस सर्वर के बीच, केवल netcat पोर्ट मायने रखता है, जहाँ डिफ़ॉल्ट पोर्ट 9999 है। इस पोर्ट को केवल तभी खोलने की आवश्यकता है जब आप ClusterControl सर्वर पर बैकअप स्टोर करना चाहते हैं। अन्यथा, आप इसे बंद कर सकते हैं।

बाहरी नेटवर्क से, ClusterControl UI के लिए केवल HTTP (80) या HTTPS (443) तक पहुंच खोलने की अनुशंसा की जाती है। यदि आप 's9s' नामक ClusterControl CLI चला रहे हैं, तो CMON-TLS एंडपॉइंट को पोर्ट 9501 पर खोलने की आवश्यकता है। ClusterControl सर्वर के शीर्ष पर डेटाबेस-संबंधित एप्लिकेशन इंस्टॉल करना भी संभव है, जैसे HAProxy, Keepalived, ProxySQL और ऐसे। ऐसे में आपको इनके लिए भी जरूरी पोर्ट खोलने होंगे। कृपया प्रत्येक सेवा के लिए बंदरगाहों की सूची के लिए दस्तावेज़ीकरण पृष्ठ देखें।

iptables के माध्यम से फ़ायरवॉल नियम सेट करने के लिए, ClusterControl नोड पर, यह करें:

$ iptables -A INPUT -p tcp --dport 9999 -j ACCEPT
$ iptables -A INPUT -p tcp --dport 80 -j ACCEPT
$ iptables -A INPUT -p tcp --dport 443 -j ACCEPT
$ iptables -A INPUT -p tcp --dport 9501 -j ACCEPT
$ iptables -A OUTPUT -p tcp --dport 22 -j ACCEPT

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

क्लाउड में सेटअप चलाने के समान, निम्नलिखित AWS पर ClusterControl सर्वर के लिए इनबाउंड सुरक्षा समूह नियमों का एक उदाहरण है:

अलग-अलग क्लाउड प्रदाता अलग-अलग सुरक्षा समूह कार्यान्वयन प्रदान करते हैं, लेकिन बुनियादी नियम समान हैं।

एन्क्रिप्शन

क्लस्टरकंट्रोल विभिन्न स्तरों पर संचार के एन्क्रिप्शन का समर्थन करता है, यह सुनिश्चित करने के लिए कि स्वचालन, निगरानी और प्रबंधन कार्यों को यथासंभव सुरक्षित रूप से किया जाता है।

HTTPS पर चल रहा है

इंस्टॉलर स्क्रिप्ट (इंस्टॉल-cc.sh) डिफ़ॉल्ट रूप से HTTPS उपयोग के लिए एक स्व-हस्ताक्षरित एसएसएल प्रमाणपत्र को कॉन्फ़िगर करेगा। यदि आप इस एक्सेस विधि को मुख्य समापन बिंदु के रूप में चुनते हैं, तो आप बाहरी नेटवर्क से पोर्ट 80 पर चलने वाली सामान्य HTTP सेवा को ब्लॉक कर सकते हैं। हालांकि, ClusterControl को अभी भी CMONAPI (एक विरासत रेस्ट-एपीआई इंटरफ़ेस) तक पहुंच की आवश्यकता है जो स्थानीयहोस्ट पर पोर्ट 80 पर डिफ़ॉल्ट रूप से चलता है। यदि आप HTTP पोर्ट को पूरी तरह से ब्लॉक करना चाहते हैं, तो सुनिश्चित करें कि आपने क्लस्टर पंजीकरण के अंतर्गत ClusterControl API URL को बदल दिया है। इसके बजाय HTTPS का उपयोग करने के लिए पृष्ठ:

ClusterControl द्वारा कॉन्फ़िगर किए गए स्व-हस्ताक्षरित प्रमाणपत्र की वैधता 10 वर्ष (3650 दिन) है। आप निम्न आदेश (CentOS 7 सर्वर पर) का उपयोग करके प्रमाणपत्र की वैधता को सत्यापित कर सकते हैं:

$  openssl x509 -in /etc/ssl/certs/s9server.crt -text -noout
...
        Validity
            Not Before: Apr  9 21:22:42 2014 GMT
            Not After : Mar 16 21:22:42 2114 GMT
...

ध्यान दें कि ऑपरेटिंग सिस्टम के आधार पर प्रमाणपत्र फ़ाइल का पूर्ण पथ भिन्न हो सकता है।

MySQL क्लाइंट-सर्वर एन्क्रिप्शन

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

इस उद्देश्य के लिए निम्नलिखित विन्यास विकल्प समर्थित हैं:

cmondb_ssl_key - सीएमओएन और सीएमओएन डीबी के बीच एसएसएल एन्क्रिप्शन के लिए एसएसएल कुंजी का पथ।
cmondb_ssl_cert - सीएमओएन और सीएमओएन डीबी के बीच एसएसएल एन्क्रिप्शन के लिए एसएसएल प्रमाणपत्र का पथ
cmondb_ssl_ca - सीएमओएन और सीएमओएन डीबी के बीच एसएसएल एन्क्रिप्शन के लिए एसएसएल सीए का पथ

हमने कुछ समय पहले इस ब्लॉग पोस्ट में कॉन्फ़िगरेशन चरणों को शामिल किया था।

हालांकि एक पकड़ है। लेखन के समय, ClusterControl UI में cmon उपयोगकर्ता का उपयोग करके SSL के माध्यम से CMON DB तक पहुँचने की एक सीमा है। वर्कअराउंड के रूप में, हम Cmonui नामक ClusterControl UI और ClusterControl CMONAPI के लिए एक अन्य डेटाबेस उपयोगकर्ता बनाने जा रहे हैं। इस उपयोगकर्ता की विशेषाधिकार तालिका में SSL सक्षम नहीं होगा।

mysql> GRANT ALL PRIVILEGES ON *.* TO 'cmonui'@'127.0.0.1' IDENTIFIED BY '<cmon password>';
mysql> FLUSH PRIVILEGES;

नए बनाए गए डेटाबेस उपयोगकर्ता, cmonui के साथ क्रमशः ClusterControl/bootstrap.php और cmonapi/config/database.php पर स्थित ClusterControl UI और CMONAPI कॉन्फ़िगरेशन फ़ाइलों को अपडेट करें:

# <wwwroot>/clustercontrol/bootstrap.php
define('DB_LOGIN', 'cmonui');
define('DB_PASS', '<cmon password>');

# <wwwroot>/cmonapi/config/database.php
define('DB_USER', 'cmonui');
define('DB_PASS', '<cmon password>');

जब आप पैकेज मैनेजर के माध्यम से अपग्रेड करते हैं तो इन फाइलों को बदला नहीं जाएगा।

CLI एन्क्रिप्शन

ClusterControl भी 's9s' नामक कमांड-लाइन इंटरफ़ेस के साथ आता है। यह क्लाइंट कमांड लाइन विकल्पों को पार्स करता है और पोर्ट 9500 (CMON) या 9501 (TLS के साथ CMON) पर सुनने वाली नियंत्रक सेवा को एक विशिष्ट कार्य भेजता है। बाद वाला अनुशंसित है। डिफ़ॉल्ट रूप से इंस्टॉलर स्क्रिप्ट s9s CLI को 9501 को ClusterControl सर्वर के एंडपॉइंट पोर्ट के रूप में उपयोग करने के लिए कॉन्फ़िगर करेगी।

भूमिका-आधारित अभिगम नियंत्रण

ClusterControl, क्लस्टर और उनके संबंधित परिनियोजन, प्रबंधन और निगरानी सुविधाओं तक पहुँच को प्रतिबंधित करने के लिए रोल-बेस्ड एक्सेस कंट्रोल (RBAC) का उपयोग करता है। यह सुनिश्चित करता है कि केवल अधिकृत उपयोगकर्ता अनुरोधों की अनुमति है। कार्यक्षमता तक पहुंच ठीक-ठाक है, जिससे पहुंच को संगठन या उपयोगकर्ता द्वारा परिभाषित किया जा सकता है। ClusterControl एक अनुमति ढांचे का उपयोग यह परिभाषित करने के लिए करता है कि उपयोगकर्ता प्रबंधन और निगरानी कार्यक्षमता के साथ कैसे इंटरैक्ट कर सकता है, जब उन्हें ऐसा करने के लिए अधिकृत किया गया हो।

RBAC यूजर इंटरफेस को ClusterControl -> User Management -> Access Control . के जरिए एक्सेस किया जा सकता है :

सभी सुविधाएं स्व-व्याख्यात्मक हैं, लेकिन यदि आप कुछ अतिरिक्त विवरण चाहते हैं, तो कृपया दस्तावेज़ीकरण पृष्ठ देखें।

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

कस्टम पोर्ट पर चल रहा है

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

एसएसएच - डिफ़ॉल्ट 22 है
HTTP - डिफ़ॉल्ट 80 है
HTTPS - डिफ़ॉल्ट 443 है
MySQL - डिफ़ॉल्ट 3306 है

ClusterControl के ठीक से काम करने के लिए कस्टम पोर्ट पर उपरोक्त सेवाओं को चलाने के लिए आपको कई चीजों को बदलना होगा। हमने कस्टम पोर्ट पर चल रहे प्रलेखन पृष्ठ में विवरण में इसे शामिल किया है।

अनुमति और स्वामित्व

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

$ chown root:root /etc/cmon.cnf /etc/cmon.d/*.cnf
$ chmod 700 /etc/cmon.cnf /etc/cmon.d/*.cnf

MySQL सेवा के लिए, सुनिश्चित करें कि MySQL डेटा निर्देशिका की सामग्री "mysql" समूह के लिए स्वीकार्य है, और उपयोगकर्ता या तो "mysql" या "रूट" हो सकता है:

$ chown -Rf mysql:mysql /var/lib/mysql

ClusterControl UI के लिए, Apache उपयोगकर्ता के लिए स्वामित्व की अनुमति होनी चाहिए, या तो RHEL/CentOS के लिए "apache" या डेबियन-आधारित OS के लिए "www-data"।

डेटाबेस होस्ट से जुड़ने के लिए SSH कुंजी एक और बहुत महत्वपूर्ण पहलू है, क्योंकि इसमें पहचान होती है और इसे उचित अनुमति और स्वामित्व के साथ रखा जाना चाहिए। इसके अलावा, एसएसएच रिमोट कॉल शुरू करते समय असुरक्षित कुंजी फ़ाइल के उपयोग की अनुमति नहीं देगा। सत्यापित करें कि क्लस्टर द्वारा उपयोग की जाने वाली SSH कुंजी फ़ाइल, /etc/cmon.d/ निर्देशिका के अंतर्गत जेनरेट की गई कॉन्फ़िगरेशन फ़ाइलों के अंदर, osuser के लिए अनुमेय पर सेट है। केवल विकल्प। उदाहरण के लिए, osuser . पर विचार करें "उबंटू" है और कुंजी फ़ाइल /home/ubuntu/.ssh/id_rsa है:

$ chown ubuntu:ubuntu /home/ubuntu/.ssh/id_rsa
$ chmod 700 /home/ubuntu/.ssh/id_rsa

एक मजबूत पासवर्ड का प्रयोग करें

यदि आप ClusterControl को स्थापित करने के लिए इंस्टॉलर स्क्रिप्ट का उपयोग करते हैं, तो इंस्टॉलर द्वारा संकेत दिए जाने पर आपको एक मजबूत पासवर्ड का उपयोग करने के लिए प्रोत्साहित किया जाता है। अधिकतम दो खाते हैं जिन्हें इंस्टॉलर स्क्रिप्ट को कॉन्फ़िगर करने की आवश्यकता होगी (आपके सेटअप के आधार पर):

MySQL cmon पासवर्ड - डिफ़ॉल्ट मान 'cmon' है।
MySQL रूट पासवर्ड - डिफ़ॉल्ट मान 'पासवर्ड' है।

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

=> Set a password for ClusterControl's MySQL user (cmon) [cmon]
=> Supported special password characters: [email protected]#$%^&*()_+{}<>?

/etc/cmon.cnf और /etc/cmon.d/cmon_*.cnf की सामग्री को सत्यापित करें और सुनिश्चित करें कि आप जब भी संभव हो एक मजबूत पासवर्ड का उपयोग कर रहे हैं।

MySQL 'cmon' पासवर्ड बदलना

यदि कॉन्फ़िगर किया गया पासवर्ड आपकी पासवर्ड नीति को संतुष्ट नहीं करता है, तो MySQL cmon पासवर्ड बदलने के लिए, आपको कई चरणों को पूरा करने की आवश्यकता है:

ClusterControl के MySQL सर्वर के अंदर पासवर्ड बदलें:

$ ALTER USER 'cmon'@'127.0.0.1' IDENTIFIED BY 'newPass';
$ ALTER USER 'cmon'@'{ClusterControl IP address or hostname}' IDENTIFIED BY 'newPass';
$ FLUSH PRIVILEGES;

/etc/cmon.cnf और /etc/cmon.d/*.cnf:
के अंदर नियंत्रक सेवा के लिए 'mysql_password' विकल्पों की सभी घटनाओं को अपडेट करें
```
mysql_password=newPass
```
/var/www/html/clustercontrol/bootstrap.php और /var/www/html/cmonapi/config/database.php:
के अंदर ClusterControl UI के लिए 'DB_PASS' स्थिरांक की सभी घटनाओं को अपडेट करें।
```
# <wwwroot>/clustercontrol/bootstrap.php
define('DB_PASS', 'newPass');
```
```
# <wwwroot>/cmonapi/config/database.php
define('DB_PASS', 'newPass');
```
ClusterControl द्वारा मॉनिटर किए गए प्रत्येक MySQL सर्वर पर पासवर्ड बदलें:
```
$ ALTER USER 'cmon'@'{ClusterControl IP address or hostname}' IDENTIFIED BY 'newPass';
$ FLUSH PRIVILEGES;
```
परिवर्तन लागू करने के लिए CMON सेवा को पुनरारंभ करें:
```
$ service cmon restart # systemctl restart cmon
```

सत्यापित करें कि /var/log/cmon.log को देखकर सीमोन प्रक्रिया सही ढंग से शुरू हुई है या नहीं। सुनिश्चित करें कि आपको नीचे जैसा कुछ मिला है:

2018-01-11 08:33:09 : (INFO) Additional RPC URL for events: 'http://127.0.0.1:9510'
2018-01-11 08:33:09 : (INFO) Configuration loaded.
2018-01-11 08:33:09 : (INFO) cmon 1.5.1.2299
2018-01-11 08:33:09 : (INFO) Server started at tcp://127.0.0.1:9500
2018-01-11 08:33:09 : (INFO) Server started at tls://127.0.0.1:9501
2018-01-11 08:33:09 : (INFO) Found 'cmon' schema version 105010.
2018-01-11 08:33:09 : (INFO) Running cmon schema hot-fixes.
2018-01-11 08:33:09 : (INFO) Schema auto-upgrade succeed (version 105010).
2018-01-11 08:33:09 : (INFO) Checked tables - seems ok
2018-01-11 08:33:09 : (INFO) Community version
2018-01-11 08:33:09 : (INFO) CmonCommandHandler: started, polling for commands.

इसे ऑफ़लाइन चलाना

संबंधित संसाधन ClusterControl 1.5.1 की घोषणा - MySQL, MongoDB और PostgreSQL के लिए बैकअप एन्क्रिप्शन की विशेषता, क्लस्टर नियंत्रण के साथ MySQL और MariaDB के लिए PCI अनुपालन MySQL/MariaDB सर्वर को कैसे सुरक्षित करें

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

ClusterControl और डेटाबेस क्लस्टर को बाहरी दुनिया से अलग करके, आपने एक महत्वपूर्ण हमलावर वेक्टर को हटा दिया है।

सारांश

ClusterControl आपके डेटाबेस क्लस्टर को सुरक्षित करने में मदद कर सकता है लेकिन यह अपने आप सुरक्षित नहीं होता है। Ops टीमों को यह सुनिश्चित करना चाहिए कि ClusterControl सर्वर भी सुरक्षा की दृष्टि से कठोर है।