MariaDB
 sql >> база данни >  >> RDS >> MariaDB

Пълно MariaDB криптиране в покой и по време на транспорт за максимална защита на данните - първа част

В тази серия от блогове ще ви дадем пълно ръководство за това как да конфигурирате напълно криптиран MariaDB сървър за криптиране в покой и по време на транспортиране, за да осигурим максимална защита на данните от откраднати физически или по време на прехвърляне и комуникация с други хостове. Основната идея е, че ще превърнем нашето "обикновено" внедряване в напълно криптирана репликация на MariaDB, както е опростено на следната диаграма:

Ще конфигурираме редица компоненти за криптиране:

  • Шифроване при транспортиране, което се състои от:
    • Клиент-сървър криптиране
    • Криптиране на репликация
  • Криптиране в покой, което се състои от:
    • Криптиране на файлове с данни
    • Криптиране на двоичен/релейен регистрационен файл.

Обърнете внимание, че тази публикация в блога обхваща само криптирането по време на транспортиране. Ще разгледаме криптирането в състояние на покой във втората част на тази серия от блогове.

Това ръководство за внедряване предполага, че вече имаме работещ сървър за репликация на MariaDB. Ако нямате такъв, можете да използвате ClusterControl, за да разположите нова репликация на MariaDB в рамките на минути, с по-малко от 5 щраквания. Всички сървъри работят на MariaDB 10.4.11 на системата CentOS 7.

Шифроване по време на транспорт

Данните могат да бъдат изложени на рискове както по време на пренос, така и при покой и изискват защита и в двете състояния. Шифроването по време на пренос защитава вашите данни, ако комуникациите бъдат прихванати, докато данните се движат между хостове през мрежа, или от вашия сайт и от доставчика на облак, между услуги или между клиенти и сървър.

За MySQL/MariaDB данните са в движение, когато клиент се свързва със сървър на база данни или когато подчинен възел репликира данни от главен възел. MariaDB поддържа криптирани връзки между клиенти и сървъра, използвайки протокола TLS (Transport Layer Security). TLS понякога се нарича SSL (Secure Sockets Layer), но MariaDB всъщност не използва SSL протокола за криптирани връзки, тъй като неговото криптиране е слабо. Повече подробности за това на страницата с документация на MariaDB.

Клиент-сървър криптиране

При тази настройка ще използваме самоподписани сертификати, което означава, че не използваме външни лица като Google, Comodo или който и да е популярен доставчик на сертифициращ орган, за да потвърдим самоличността си. В SSL/TLS проверката на самоличността е първата стъпка, която трябва да се премине, преди сървърът и клиентът да обменят своите сертификати и ключове.

MySQL предоставя много удобен инструмент, наречен mysql_ssl_rsa_setup, който се грижи за автоматично генериране на ключове и сертификати. За съжаление все още няма такъв инструмент за MariaDB сървър. Следователно трябва ръчно да подготвим и генерираме файловете, свързани със SSL, за нашите нужди на MariaDB TLS.

Следва списък с файловете, които ще генерираме с помощта на инструмента OpenSSL:

  • CA ключ - RSA частен ключ във формат PEM. Трябва да се пази в тайна.
  • CA сертификат - X.509 сертификат във формат PEM. Съдържа публичен ключ и метаданни за сертификат.
  • CSR на сървъра - Искане за подписване на сертификат. Общото име (CN) при попълване на формуляра е важно, например CN=mariadb-server
  • Ключ на сървъра - RSA частен ключ. Трябва да се пази в тайна.
  • Сертификат за сървър - X.509 сертификат, подписан от CA ключ. Съдържа публичен ключ и метаданни за сертификат.
  • Client CSR - Искане за подписване на сертификат. Трябва да използва различно общо име (CN) от CSR на сървъра, например CN=client1 
  • Ключ на клиента - RSA частен ключ. Трябва да се пази в тайна.
  • Сертификат на клиента - X.509 сертификат, подписан от CA ключ. Съдържа публичен ключ и метаданни за сертификат.

Първо и най-важно, създайте директория, в която да съхранявате нашите сертификати и ключове за криптиране по време на транспортиране:

$ 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)

Генерирайте сертификат за нашия собствен сертифициращ орган (CA) въз основа на генерирания преди това ca-key.pem с изтичане на 3650 дни:

$ 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)

Довереният сертификат трябва да бъде сертификат, подписан от сертифициращ орган, при което тук ще използваме собствен CA, защото имаме доверие на хостовете в мрежата. Преди да можем да създадем подписан сертификат, трябва да генерираме сертификат за заявка, наречен Заявка за подписване на сертификат (CSR).

Създайте CSR за MariaDB сървър. Ще извикаме сертификата като server-req.pem. Това не е сертификатът, който ще използваме за MariaDB сървър. Окончателният сертификат е този, който ще бъде подписан от нашия собствен частен ключ на 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“. Това може да бъде всяко име, но стойността не трябва да е същата като сертификата на клиента. Обикновено, ако приложенията се свързват със сървъра на MariaDB чрез FQDN или име на хост (skip-name-resolve=OFF), вероятно искате да посочите FQDN на MariaDB сървъра като общо име.

След това можем да генерираме окончателния сертификат X.509 (server-cert.pem) и да подпишем CSR (server-req.pem) със сертификата на CA (ca.pem) и частния ключ на CA (ca -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) за сървъра MariaDB. CSR (server-req.pem) вече не се изисква.

Ключ и сертификат за клиента

След това трябва да генерираме файлове с ключове и сертификати за клиента MariaDB. Сървърът на MariaDB ще приема само отдалечена връзка от клиента, който има тези файлове със сертификат.

Започнете с генериране на 2048-битов ключ за клиента:

$ openssl genrsa 2048 > client-key.pem
Generating RSA private key, 2048 bit long modulus
.............................................................................................................+++
..................................................................................................................+++
e is 65537 (0x10001)

Създайте CSR за клиента, наречен client-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 []:

Обърнете внимание на общото име, където указваме „Client1“. Посочете всяко име, което представлява клиента. Тази стойност трябва да е различна от общото име на сървъра. За разширена употреба можете да използвате това общо име, за да разрешите на определен потребител със сертификат, съответстващ на тази стойност, например:

MariaDB> GRANT SELECT ON schema1.* TO 'client1'@'192.168.0.93' IDENTIFIED BY 's' REQUIRE SUBJECT '/CN=Client2';

След това можем да генерираме окончателния сертификат X.509 (client-cert.pem) и да подпишем CSR (client-req.pem) със сертификата на CA (ca.pem) и частния ключ на CA (ca -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

Всички сертификати, които са ни необходими за настройка на криптиране по време на транспортиране, се генерират. Проверете дали и двата сертификата са правилно подписани от CA:

$ 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/

Уверете се, че собственикът на директорията certs е на потребителя "mysql" и променете разрешенията на всички ключови файлове, така че да не се чете глобално:

$ cd /etc/mysql/transit
$ chown -R mysql:mysql *
$ chmod 600 client-key.pem server-key.pem ca-key.pem

Ето какво трябва да видите, когато изброявате файлове в директория "transit":

$ 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

След това ще активираме SSL връзката за MariaDB. На всеки хост на 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

След рестартиране, MariaDB вече е в състояние да приема обикновени връзки, като се свързва с него без никакви свързани с SSL параметри или с криптирани връзки, когато посочите параметър, свързан с SSL в низа за връзка.

За потребители на ClusterControl можете да активирате криптиране клиент-сървър само с кликвания. Просто отидете на ClusterControl -> Security -> SSL Encryption -> Enable -> Create Certificate -> Certificate Expiration -> Enable SSL:

ClusterControl ще генерира необходимите ключове, X.509 сертификат и CA сертификат и настройте SSL криптиране за връзки клиент-сървър за всички възли в клъстера. За репликация на MySQL/MariaDB, SSL файловете ще се намират под /etc/ssl/replication/cluster_X, където X е идентификаторът на клъстера на всеки възел на базата данни. Едни и същи сертификати ще бъдат използвани на всички възли и съществуващите може да бъдат презаписани. Възлите трябва да бъдат рестартирани поотделно, след като тази задача завърши. Препоръчваме ви първо да рестартирате подчинен сървър за репликация и да проверите дали настройките за SSL работят.

За да рестартирате всеки възел, отидете на ClusterControl -> Nodes -> Node Actions -> Restart Node. Рестартирайте един възел в даден момент, като започнете от подчинените. Последният възел трябва да бъде главният възел с активиран флаг за принудително спиране:

Можете да разберете дали даден възел е в състояние да обработва криптиране клиент-сървър чрез гледайки зелената икона на заключване точно до възела на базата данни в решетката за преглед:

В този момент нашият клъстер вече е готов да приеме SSL връзка от MySQL потребители.

Свързване чрез криптирана връзка

Клиентът на MariaDB изисква всички свързани с клиента SSL файлове, които сме генерирали в сървъра. Копирайте генерирания клиентски сертификат, CA сертификат и клиентски ключ на клиентския хост:

$ cd /etc/mysql/transit
$ scp client-cert.pem client-key.pem ca.pem [email protected]:~

**ClusterControl генерира клиентските SSL файлове под /etc/ssl/replication/cluster_X/на всеки възел на базата данни, където X е идентификаторът на клъстера.

Създайте потребител на база данни, който изисква SSL на главния:

MariaDB> CREATE SCHEMA sbtest;
MariaDB> CREATE USER [email protected]'%' IDENTIFIED BY 'mysecr3t' REQUIRE SSL;
MariaDB> GRANT ALL PRIVILEGES ON sbtest.* to [email protected]'%';

От клиентския хост се свържете със сървъра на MariaDB с параметри, свързани с SSL. Можем да проверим състоянието на връзката, като използваме оператор "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
...

Обърнете внимание на SSL реда, където шифърът се използва за криптиране. Това означава, че клиентът е успешно свързан със сървъра на MariaDB чрез криптирана връзка.

В този момент ние криптирахме връзката клиент-сървър към сървъра MariaDB, както е представено от зелената двупосочна стрелка на следната диаграма:

В следващата част ще криптираме връзките за репликация между възлите.

Криптиране на репликация

Настройването на криптирани връзки за репликация е подобно на това за връзки клиент/сървър. Можем да използваме едни и същи клиентски сертификати, ключ и CA сертификат, за да позволим на потребителя за репликация да получи достъп до главния сървър чрез канал за криптиране. Това косвено ще даде възможност за криптиране между възли, когато подчинената IO нишка изтегли събития за репликация от главния.

Нека да конфигурираме това на един подчинен наведнъж. За първото подчинено устройство, 192.168.0.92, добавете следния ред под секция [client] в конфигурационния файл на 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
...

Уверете се, че можете да се свържете с главния хост без грешка. След това, на подчинения, посочете оператора CHANGE MASTER с SSL параметри, както следва:

(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
...

Подчиненото устройство вече се репликира от главния по сигурен начин чрез TLS криптиране.

Повторете всички горепосочени стъпки на останалия подчинен, 192.168.0.93. Единствената разлика е операторът alter user, който трябва да се изпълни на главния, където трябва да променим съответния хост:

(master)MariaDB> ALTER USER [email protected] REQUIRE SSL;

На този етап завършихме криптирането по време на транспортиране, както е илюстрирано със зелените линии от главен към подчинен на следната диаграма:

Можете да проверите връзката за криптиране, като погледнете изхода на tcpdump за интерфейс eth1 на роба. Следва пример за стандартна репликация без криптиране:

(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

Заключение

В следващата част от тази серия от блогове ще разгледаме завършването на нашата напълно криптирана настройка с MariaDB криптиране в покой. Останете на линия!


  1. Database
    2.   
  2. Mysql
    3.   
  3. Oracle
    4.   
  4. Sqlserver
    5.   
  5. PostgreSQL
    6.   
  6. Access
    7.   
  7. SQLite
    8.   
  8. MariaDB

  1. Какво е MariaDB Enterprise и как да го управляваме с ClusterControl?

  2. Как да проектираме географски разпределен MariaDB клъстер

  3. 6 често срещани сценария за неуспехи за MySQL и MariaDB и как да ги поправите

  4. Разбиране на детайлността на заключване в MySQL

  5. MariaDB JSON_DEPTH() Обяснено