Един от най-важните фактори и основи на управлението на данните е сигурността. Добра практика е да имате внедрена защита на базата данни, когато имате управление на вашите данни за корпоративно или масово потребление.
Сигурността на данните е един от най-важните аспекти на администрирането на база данни. Той играе критична роля, за която всяко управление на база данни трябва да приложи. Когато бъде внедрен и направен правилно, резултатът ще подобри не само сигурността на вашите данни, но също така ще повлияе на стабилността на системата, подобрява жизнения цикъл на разработка, повишава съответствието на вашите данни и повишава осведомеността за сигурността до ниво на екипа ви. Всеки не иска данните му да попаднат в грешни ръце. Ако данните бъдат нарушени, това не само рискува поверителността и целостта на вашите данни, но също така оставя вашата организация отворена за значителни финансови рискове. Дори само за обикновена реализация на управление на база данни, ако разберете, че някой вече е нахлул в системата ви, усещането, че сте несигурни и уплашени какви последствия ще ви доведат, е напълно неудобно.
Определянето дали връзката ви с MySQL сървър е безопасна зависи от това колко сигурно MySQL предава данни по време на пренос. С некриптирана връзка между MySQL клиента и сървъра, някой с достъп до мрежата може да наблюдава целия ви трафик и да проверява данните, които се изпращат или получават между клиент и сървър.
Когато трябва да премествате информация през мрежа по защитен начин, нешифрована връзка е неприемлива. За да направите всякакъв вид данни нечетими, използвайте криптиране. Алгоритмите за криптиране трябва да включват елементи за защита, за да се противопоставят на много видове известни атаки, като например промяна на реда на криптирани съобщения или възпроизвеждане на данни два пъти.
Но моят MySQL е безопасен, нали?
Вярването, че вашият MySQL е безопасен, без да се определя неговата стабилност и проверки за уязвимост, е като религия. Склонни сте да вярвате, дори без да го виждате, дори без да го докосвате. Проблемът е, че MySQL е технология и съществуването й не се основава на абстрактни мисли. Тя трябва да бъде тествана, трябва да бъде доказана и изисква безопасност и следва най-добрите практики, които са били тествани и от други.
Определянето дали връзките ви към MySQL сървъра, т.е. по време на пренос, са безопасни или дали е криптиран разчита на „как настроихте вашата база данни?“ или "кой настройва вашата база данни?".
MySQL поддържа криптирани връзки между клиенти и сървъра, използвайки протокола TLS (Transport Layer Security). TLS понякога се нарича SSL (Secure Sockets Layer), но MySQL всъщност не използва SSL протокола за криптирани връзки, тъй като неговото криптиране е слабо и SSL вече е отхвърлен в полза на TLS. TLS използва алгоритми за криптиране, за да гарантира, че данните, получени през публична мрежа, могат да бъдат доверени. Той има механизми за откриване на промяна, загуба или повторно възпроизвеждане на данни. TLS също така включва алгоритми, които осигуряват проверка на самоличността, използвайки стандарта X.509. SSL или TLS се използват взаимозаменяемо, но за контекста на криптиране с MySQL се използва TLS, за който MySQL поддържа криптирани връзки с помощта на протоколите TLSv1, TLSv1.1, TLSv1.2 и TLSv1.3.
X.509 прави възможно идентифицирането на някого в Интернет. Най-общо казано, трябва да има някакъв обект, наречен „сертифициращ орган“ (или CA), който присвоява електронни сертификати на всеки, който има нужда от тях. Сертификатите разчитат на асиметрични алгоритми за криптиране, които имат два ключа за криптиране (публичен ключ и таен ключ). Собственикът на сертификат може да представи сертификата на друга страна като доказателство за самоличност. Сертификатът се състои от публичния ключ на собственика. Всички данни, криптирани с този публичен ключ, могат да бъдат декриптирани само с помощта на съответния таен ключ, който се държи от собственика на сертификата.
Точно както спартанците са използвали Scytale
Известно е, че Scytale се използва като начин за криптиране и декриптиране на съобщение, което е било използвано около 400 г. пр.н.е. от спартанците. Те щяха да напишат съобщение на лист папирус (вид хартия), който беше увит около тояга. Получателят може да дешифрира съобщението само ако е правилният диаметър и размер на тоягата. Той служи като начин за криптиране и избягване на неоторизирано извличане на съобщения или данни до целевата дестинация.
Точно както при MySQL, използването на SSL/TLS протоколи и шифри е начин да избегнете извличане на вашите данни или отвличане на данните ви, докато те преминават по кабел или през интернет.
По подразбиране MySQL програмите се опитват да се свържат чрез криптиране, ако сървърът поддържа криптирани връзки, като се връщат към нешифрована връзка, ако криптирана връзка не може да бъде установена. Тъй като версия MySQL>=5.7, TLS/SSL и RSA файлове могат да се създават или генерират с поддръжка на променливи. За MySQL дистрибуции, компилирани с помощта на OpenSSL, MySQL сървърът има способността автоматично да генерира липсващи SSL и RSA файлове при стартиране. 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 да е компилирана с OpenSSL, стига командата openssl да е налична.
След като тези файлове са налични и/или генерирани, MySQL пак няма да използва криптиращи връзки поради следните причини. Както бе споменато по-рано, по подразбиране, MySQL клиентските програми се опитват да установят криптирана връзка, ако сървърът поддържа криптирани връзки, като допълнителен контрол е наличен чрез --ssl-mode (или --ssl <=5.7.11, тъй като това вече е отхвърлено) опция:
-
По подразбиране, ако връзката с MySQL не е маркирана с --ssl-mode, стойността по подразбиране е зададена на --ssl-mode=ПРЕДПОЧИТАН. Следователно клиентите се опитват да се свържат с помощта на криптиране, като се връщат към некриптирана връзка, ако криптирана връзка не може да бъде установена.
-
С --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/ (или пътя на datadir за този 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
SSL: Не се използва
Това разкрива, че не използва защитена връзка. Проверката на променливите на състоянието на SSL сесията, ако се използват някакви шифри, показва празно:
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 въвежда променливата require_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Алтернативно, ако потребител е създаден с ИЗИСКВАЩ SSL например, това също трябва да ви свърже чрез SSL, независимо че require_secure_transport е деактивиран, което е неговата стойност по подразбиране. Обърнете внимание, че ако require_secure_transport е активиран, неговите възможности допълват изискванията за SSL за всеки акаунт, които имат предимство. Следователно, ако акаунтът е дефиниран с REQUIRE SSL, разрешаването на require_secure_transport не прави възможно използването на акаунта за свързване чрез Unix файл на сокет.
Уверете се, че внедряванията на MySQL сървъра са криптирани и безопасни
Безпроблемно е това, което винаги очакваме с нетърпение, за да няма други проблеми и притеснения, за които да се притеснявате. ClusterControl разгръща MySQL бази данни, използвайки криптирани връзки и генерира SSL и RSA сертификатите вместо вас. Например екранна снимка по-долу, показваща дейността на командата Create Cluster от ClusterControl.
Той настройва SSL и RSA файловете и ги поставя в /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 файлове по централизиран начин в навигационния панел за управление на ключове, както е показано по-долу:
Веднъж разгърнат, всичко, което трябва да направите, е или да създадете потребители с ИЗИСКВАЩ SSL, или да имате require_secure_transport, ако искате да наложите криптиран и защитен слой за вашите връзки към MySQL сървъра.
