Сигурността на данните е основен приоритет в наши дни. Понякога е наложено от външни регулации като PCI-DSS или HIPAA, понякога е защото се грижите за данните на клиентите и репутацията си. Има много аспекти на сигурността, които трябва да имате предвид - достъп до мрежата, сигурност на операционната система, грантове, криптиране и така нататък. В тази публикация в блога ще ви дадем 10 съвета какво да гледате, когато защитавате настройката на MySQL или MariaDB.
1. Премахване на потребители без парола
MySQL се предлагаше с набор от предварително създадени потребители, някои от които могат да се свързват с базата данни без парола или, още по-лошо, анонимни потребители. Това се промени в MySQL 5.7, който по подразбиране идва само с root акаунт, който използва паролата, която сте избрали по време на инсталацията. Все пак има MySQL инсталации, които бяха надградени от предишни версии и тези инсталации запазват наследените потребители. Също така, MariaDB 10.2 на Centos 7 идва с анонимни потребители:
MariaDB [(none)]> select user, host, password from mysql.user where user like '';
+------+-----------------------+----------+
| user | host | password |
+------+-----------------------+----------+
| | localhost | |
| | localhost.localdomain | |
+------+-----------------------+----------+
2 rows in set (0.00 sec)Както можете да видите, те са ограничени само до достъп от localhost, но независимо от това, не искате да имате такива потребители. Въпреки че техните привилегии са ограничени, те все още могат да изпълняват някои команди, които могат да покажат повече информация за базата данни - например версията може да помогне за идентифициране на други вектори на атака.
[[email protected] ~]# mysql -uanonymous_user
Welcome to the MariaDB monitor. Commands end with ; or \g.
Your MariaDB connection id is 19
Server version: 10.2.11-MariaDB MariaDB Server
Copyright (c) 2000, 2017, Oracle, MariaDB Corporation Ab and others.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
MariaDB [(none)]> SHOW GRANTS\G
*************************** 1. row ***************************
Grants for @localhost: GRANT USAGE ON *.* TO ''@'localhost'
1 row in set (0.00 sec)
MariaDB [(none)]> \s
--------------
mysql Ver 15.1 Distrib 10.2.11-MariaDB, for Linux (x86_64) using readline 5.1
Connection id: 19
Current database:
Current user: [email protected]
SSL: Not in use
Current pager: stdout
Using outfile: ''
Using delimiter: ;
Server: MariaDB
Server version: 10.2.11-MariaDB MariaDB Server
Protocol version: 10
Connection: Localhost via UNIX socket
Server characterset: latin1
Db characterset: latin1
Client characterset: utf8
Conn. characterset: utf8
UNIX socket: /var/lib/mysql/mysql.sock
Uptime: 12 min 14 sec
Threads: 7 Questions: 36 Slow queries: 0 Opens: 17 Flush tables: 1 Open tables: 11 Queries per second avg: 0.049
--------------Моля, имайте предвид, че потребителите с много прости пароли са почти толкова несигурни, колкото потребителите без парола. Паролите като „password“ или „qwerty“ не са наистина полезни.
2. Тесен отдалечен достъп
На първо място, отдалечен достъп за суперпотребители - това се полага по подразбиране при инсталиране на най-новия MySQL (5.7) или MariaDB (10.2) - достъпен е само локален достъп. Все пак е доста често да видите, че суперпотребителите са достъпни по различни причини. Най-често срещаният, вероятно защото базата данни се управлява от хора, които искат да улеснят работата си, така че ще добавят отдалечен достъп към своите бази данни. Това не е добър подход, тъй като отдалеченият достъп улеснява използването на потенциални (или проверени) уязвимости в сигурността в MySQL – не е необходимо първо да установявате връзка с хоста.
Друга стъпка - уверете се, че всеки потребител може да се свърже с MySQL само от конкретни хостове. Винаги можете да дефинирате няколко записа за един и същ потребител ([email protected], [email protected]), това би трябвало да помогне за намаляване на нуждата от заместващи знаци ([email protected]’%’).
3. Премахване на тестова база данни
Тестовата база данни по подразбиране е достъпна за всеки потребител, особено за анонимните потребители. Такива потребители могат да създават таблици и да пишат в тях. Това потенциално може да се превърне в проблем само по себе си - всяко записване би добавило допълнителни разходи и ще намали производителността на базата данни. В момента, след инсталацията по подразбиране, само MariaDB 10.2 на Centos 7 е засегната от това - Oracle MySQL 5.7 и Percona Server 5.7 нямат налична „тестовата“ схема.
[[email protected] ~]# mysql -uanonymous_user
Welcome to the MariaDB monitor. Commands end with ; or \g.
Your MariaDB connection id is 13
Server version: 10.2.11-MariaDB MariaDB Server
Copyright (c) 2000, 2017, Oracle, MariaDB Corporation Ab and others.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
MariaDB [(none)]> SHOW GRANTS\G
*************************** 1. row ***************************
Grants for @localhost: GRANT USAGE ON *.* TO ''@'localhost'
1 row in set (0.00 sec)
MariaDB [(none)]> USE test;
Database changed
MariaDB [test]> CREATE TABLE testtable (a INT);
Query OK, 0 rows affected (0.01 sec)
MariaDB [test]> INSERT INTO testtable VALUES (1), (2), (3);
Query OK, 3 rows affected (0.01 sec)
Records: 3 Duplicates: 0 Warnings: 0
MariaDB [test]> SELECT * FROM testtable;
+------+
| a |
+------+
| 1 |
| 2 |
| 3 |
+------+
3 rows in set (0.00 sec)Разбира се, все още може да се случи, че вашият MySQL 5.7 е надстроен от предишни версии, в които „тестовата“ схема не е била премахната – трябва да се погрижите за това и да проверите дали сте я създали.
4. Закриване на достъпа до MySQL
Добре известно е, че MySQL работи на порт 3306, а неговият суперпотребител се нарича „root“. За да направите нещата по-трудни, е доста лесно да промените това. До известна степен това е пример за сигурност чрез неизвестност, но може поне да спре автоматизираните опити за получаване на достъп до „root“ потребител. За да промените порта, трябва да редактирате my.cnf и да зададете променлива „port“ на някаква друга стойност. Що се отнася до потребителите – след като MySQL бъде инсталиран, трябва да създадете нов суперпотребител (ПРЕДОСТАВЯТЕ ВСИЧКИ... С ОПЦИЯ ЗА ПРЕДОСТАВЯНЕ) и след това да премахнете съществуващите акаунти „[email protected]“.
5. Мрежова сигурност
В идеалния случай MySQL не би бил достъпен през мрежата и всички връзки ще се обработват локално, чрез Unix сокета. При някои настройки това е възможно - в този случай можете да добавите променливата „skip-networking“ в my.cnf. Това ще попречи на MySQL да използва каквато и да е TCP/IP комуникация, само Unix сокет ще бъде наличен в Linux (наименовани тръби и споделена памет на хостове на Windows).
През повечето време обаче такава строга сигурност не е осъществима. В такъв случай трябва да намерите друго решение. Първо, можете да използвате вашата защитна стена, за да разрешите трафик само от конкретни хостове към MySQL сървъра. Например, хостове на приложения (въпреки че те трябва да са наред с достигането до MySQL чрез прокси сървъри), прокси слоя и може би сървър за управление. Други хостове във вашата мрежа вероятно нямат нужда от директен достъп до MySQL сървъра. Това ще ограничи възможностите за атака на вашата база данни, в случай че някои хостове във вашата мрежа ще бъдат компрометирани.
Ако случайно използвате прокси сървъри, които позволяват съвпадение на регулярни изрази за заявки, можете да ги използвате, за да анализирате SQL трафика и да блокирате подозрителни заявки. Най-вероятно хостовете на вашите приложения не трябва да изпълняват „DELETE * FROM your_table;“ редовно. Ако е необходимо да се премахнат някои данни, може да се изпълни ръчно, локално, в MySQL екземпляр. Можете да създадете такива правила, като използвате нещо като ProxySQL:блокирайте, пренаписвайте, пренасочвайте такива заявки. MaxScale също ви дава възможност да блокирате заявки въз основа на регулярни изрази.
6. Плъгини за одит
Ако се интересувате от събиране на данни за това кой какво е изпълнил и кога, има няколко налични плъгини за одит за MySQL. Ако използвате MySQL Enterprise, можете да използвате MySQL Enterprise Audit, който е разширение към MySQL Enterprise. Percona и MariaDB също имат своя собствена версия на плъгини за одит. И накрая, плъгинът McAfee за MySQL може да се използва и с различни версии на MySQL. Най-общо казано, тези плъгини събират повече или по-малко едни и същи данни - събития за свързване и прекъсване, изпълнени заявки, достъп до таблици. Всичко това съдържа информация кой потребител е участвал в такова събитие, от кой хост е влязъл, кога се е случило и т.н. Резултатът може да бъде XML или JSON, така че е много по-лесно да го анализирате, отколкото да анализирате общото съдържание на дневника (въпреки че данните са доста сходни). Такъв изход може също да бъде изпратен до syslog и, освен това, до някакъв лог сървър за обработка и анализ.
7. Деактивирайте LOAD DATA LOCAL INFILE
Ако и сървърът, и клиентът имат възможност да изпълняват LOAD DATA LOCAL INFILE, клиентът ще може да зарежда данни от локален файл на отдалечен MySQL сървър. Това потенциално може да помогне за четене на файлове, до които клиентът има достъп - например на сървър на приложения човек може да получи достъп до всеки файл, до който HTTP сървърът има достъп. За да го избегнете, трябва да зададете local-infile=0 в my.cnf
8. Файлови права
Трябва да имате предвид, че сигурността на MySQL зависи и от настройката на операционната система. MySQL съхранява данни под формата на файлове. MySQL сървърът записва много информация в регистрационните файлове. Понякога тази информация съдържа данни - бавен журнал на заявки, общ дневник или двоичен дневник, например. Трябва да се уверите, че тази информация е безопасна и достъпна само за потребители, които трябва да имат достъп до нея. Обикновено това означава, че само root и потребителят, под чиито права се изпълнява MySQL, трябва да имат достъп до всички файлове, свързани с MySQL. През повечето време това е специален потребител, наречен „mysql“. Трябва да проверите конфигурационните файлове на MySQL и всички регистрационни файлове, генерирани от MySQL, и да се уверите, че те не са четими от други потребители.
9. SSL и криптиране на данни при пренасяне
Предотвратяването на достъп до конфигурационни и регистрационни файлове е едно нещо. Другият проблем е да се уверите, че данните се прехвърлят сигурно по мрежата. С изключение на настройките, при които всички клиенти са локални и използват Unix сокет за достъп до MySQL, в повечето случаи данните, които формират набор от резултати за заявка, напускат сървъра и се прехвърлят към клиента по мрежата. Данните могат да се прехвърлят и между MySQL сървъри, например чрез стандартна MySQLreplication или в рамките на клъстер на Galera. Мрежовият трафик може да бъде подслушван и чрез тези средства вашите данни ще бъдат разкрити.
За да предотвратите това да се случи, е възможно да използвате SSL за криптиране на трафик, както от страна на сървъра, така и от страна на клиента. Можете да създадете SSL връзка между клиент и MySQL сървър. Можете също така да създадете SSL връзка между вашия главен и вашите подчинени или между възлите на клъстер на Galera. Това ще гарантира, че всички прехвърляни данни са безопасни и няма да бъдат подслушвани от нападател, който е получил достъп до вашата мрежа.
Документацията на MySQL обхваща подробно как да настроите SSL криптиране. Ако го смятате за твърде тромав, ClusterControl може да ви помогне да разгърнете сигурна среда за MySQL репликация или клъстер Galera с няколко щраквания:
10. Криптиране на данни в покой
Осигуряването на данни при транзит чрез SSL криптиране само частично решава проблема. Трябва да се погрижите и за данните в покой - всички данни, които се съхраняват в базата данни. Криптирането на данни в покой също може да бъде изискване за разпоредби за сигурност като HIPAA или PCI DSS. Такова криптиране може да се реализира на няколко нива - можете да шифровате целия диск, на който се съхраняват файловете. Можете да шифровате само базата данни MySQL чрез функционалност, налична в най-новите версии на MySQL или MariaDB. В приложението може да се приложи и криптиране, така че да криптира данните, преди да ги съхрани в базата данни. Всяка опция има своите плюсове и минуси:криптирането на диска може да помогне само когато дисковете са физически откраднати, но файловете няма да бъдат криптирани на работещ сървър на база данни. Шифроването на базата данни MySQL решава този проблем, но не може да предотврати достъпа до данни, когато root акаунтът е компрометиран. Шифроването на ниво приложение е най-гъвкавото и сигурно, но тогава губите силата на SQL – доста е трудно да използвате криптирани колони в клаузите WHERE или JOIN.
Всички варианти на MySQL предоставят някакъв вид криптиране на данни в покой. MySQL на Oracle използва прозрачно криптиране на данни за криптиране на пространства за таблици InnoDB. Това е достъпно в търговското предложение на MySQL Enterprise. Той предоставя опция за криптиране на пространства за таблици InnoDB, други файлове, които също съхраняват данни под някаква форма (например двоични регистрационни файлове, общ дневник, бавни дневници на заявки) не са криптирани. Това позволява на веригата от инструменти (MySQL Enterprise Backup, но също и xtrabackup, mysqldump, mysqlbinlog) да работи правилно с такава настройка.
Започвайки от MySQL 5.7.11, общностната версия на MySQL също получи поддръжка за криптиране на пространството за таблици InnoDB. Основната разлика в сравнение с корпоративното предлагане е начинът, по който ключовете се съхраняват - ключовете не се намират в защитен хранилище, което е необходимо за спазване на нормативните изисквания. Това означава, че започвайки от Percona Server 5.7.11, е възможно също да се криптира пространството за таблици InnoDB. В наскоро публикувания Percona Server 5.7.20 е добавена поддръжка за криптиране на двоични регистрационни файлове. Възможно е също така да се интегрира със сървъра на Hashicorp Vault чрез плъгин keyring_vault, съпоставяйки (и дори разширяване - шифроване на двоичен журнал) на функциите, налични в изданието MySQL Enterprise на Oracle.
MariaDB добави поддръжка за криптиране на данни в 10.1.3 - това е отделна, подобрена реализация. Той ви дава възможност не само да шифровате пространствата за таблици на InnoDB, но и да шифровате регистрационни файлове на InnoDB. В резултат на това данните са по-сигурни, но някои от инструментите няма да работят в такава конфигурация. Xtrabackup няма да работи с криптирани регистрационни файлове за повторно изпълнение - MariaDB създаде разклонение, MariaDB Backup, което добавя поддръжка за MariaDB криптиране. Има и проблеми с mysqlbinlog.
Без значение кой вкус на MySQL използвате, стига да е най-нова версия, ще имате опции за внедряване на криптиране на данни в покой чрез сървъра на базата данни, като се уверите, че данните ви са допълнително защитени.
Защитата на MySQL или MariaDB не е тривиална, но се надяваме, че тези 10 съвета ще ви помогнат по пътя.
Резюме
В днешния пейзаж сигурността на данните е основен приоритет за всеки администратор на база данни. Независимо дали мотивацията ви е спазването на регулаторните изисквания или защитата на вашите клиенти и репутацията на вашия бизнес, тези десет съвета за защита на вашите MySQL и MariaDB бази данни ще ви помогнат да защитите допълнително вашата инфраструктура и ще ви осигурят спокойствие.
Има многобройни мерки, които трябва да вземете предвид, когато гарантирате, че инфраструктурата на вашата база данни е защитена. В тази публикация разгледахме основите като криптиране на данни, контрол на достъпа до мрежата, удостоверяване на потребителя и привилегии, сигурност на операционната система и други.
Софтуерът за автоматизация на управление на бази данни, като ClusterControl, може да бъде чудесен инструмент за подпомагане на цялостните ви усилия за сигурност на базата данни. Ако търсите по-задълбочено потапяне във всяка стъпка, която трябва да предприемете, за да защитите своите MySQL бази данни, не забравяйте да разгледате Част 1 и Част 2 от нашата поредица за Как да защитите MySQL. За да сте информирани за други най-добри практики за управление на бази данни, следвайте ни в Twitter, LinkedIn и се абонирайте за нашия бюлетин за актуализации.
