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

Мониторинг на сигурността на базата данни за MySQL и MariaDB

Защитата на данните е един от най-важните аспекти на администрирането на база данни. В зависимост от организационната структура, независимо дали сте разработчик, системен администратор или DBA, ако управлявате производствената база данни, трябва да наблюдавате данните за неоторизиран достъп и използване. Целта на наблюдението на сигурността е двойна. Първо, за идентифициране на неоторизирана дейност в базата данни. И второ, за да проверите дали базите данни и техните конфигурации за цялата компания са съвместими с политиките и стандартите за сигурност.

В тази статия ще разделим наблюдението за сигурност в две категории. Единият ще бъде свързан с одит на дейностите на MySQL и MariaDB бази данни. Втората категория ще бъде свързана с наблюдението на вашите екземпляри за потенциални пропуски в сигурността.

Наблюдение на базата на правила за заявки и връзка

Непрекъснатият одит е наложителна задача за наблюдение на вашата среда на база данни. Чрез одит на вашата база данни можете да постигнете отчетност за предприетите действия или достъп до съдържание. Освен това одитът може да включва някои критични системни компоненти, като тези, свързани с финансови данни, за да поддържат точен набор от регулации като SOX или регламента на GDPR на ЕС. Обикновено това се постига чрез регистриране на информация за операциите на DB в базата данни във външен лог файл.

По подразбиране одитът в MySQL или MariaDB е деактивиран. Вие и го постигате, като инсталирате допълнителни плъгини или като улавяте всички заявки с параметъра query_log. Общият регистрационен файл на заявки е общ запис на това, което MySQL изпълнява. Сървърът записва известна информация в този дневник, когато клиентите се свързват или прекъсват връзката, и записва всеки SQL израз, получен от клиенти. Поради проблеми с производителността и липса на опции за конфигурация, general_log не е добро решение за целите на одита на сигурността.

Ако използвате MySQL Enterprise, можете да използвате приставката MySQL Enterprise Audit, която е разширение към собствената версия на MySQL. Плъгинът MySQL Enterprise Audit Plugin е достъпен само с MySQL Enterprise, което е търговско предложение от Oracle. Percona и MariaDB създадоха свои собствени версии с отворен код на плъгина за одит. И накрая, плъгинът McAfee за MySQL може да се използва и с различни версии на MySQL. В тази статия ще се съсредоточим върху плъгините с отворен код, въпреки че Enterprise версията от Oracle изглежда е най-здравата и стабилна.

Характеристики на MySQL приставки за одит с отворен код

Докато плъгините за одит с отворен код вършат същата работа като приставката Enterprise от Oracle – те произвеждат изход със заявка към база данни и връзки – има някои големи архитектурни разлики.

MariaDB Audit Plugin – MariaDB Audit Plugin работи с MariaDB, MySQL (от версии 5.5.34 и 10.0.7) и Percona Server. MariaDB стартира включването на Audit Plugin по подразбиране от версии 10.0.10 и 5.5.37 и може да се инсталира във всяка версия от MariaDB 5.5.20. Това е единственият плъгин, който поддържа Oracle MySQL, Percona Server и MariaDB. Предлага се на Windows и Linux платформа. Версиите, започващи от 1.2, са най-стабилни и може да е рисковано да използвате версии под тази във вашата производствена среда.

McAfee MySQL Audit Plugin – Този плъгин не използва MySQL API за одит. Наскоро беше актуализиран, за да поддържа MySQL 5.7. Някои тестове показват, че базираните на API плъгини могат да осигурят по-добра производителност, но трябва да го проверите с вашата среда.

Percona Audit Log Plugin – Percona предоставя решение за одит с отворен код, което се инсталира с Percona Server 5.5.37+ и 5.6.17+ като част от инсталационния процес. В сравнение с други плъгини с отворен код, този плъгин има повече функции за извеждане на обхват, тъй като извежда XML, JSON и в системния журнал.

Тъй като има някои вътрешни връзки към сървъра, за да бъде съвместим с функции с приставката на Oracle, той не е наличен като самостоятелен плъгин за други версии на MySQL.

Инсталиране на приставка, базирана на разширение за одит на MariaDB

Инсталирането на MySQL плъгини с отворен код е доста подобно за версиите на MariaDB, Percona и McAfee.
Percona и MariaDB добавят своите плъгини като част от двоичните файлове на сървъра по подразбиране, така че няма нужда да изтегляте плъгини отделно. Версията на Percona поддържа официално само своя собствен разклонител на MySQL, така че няма директно изтегляне от уебсайта на доставчика (ако искате да използвате този плъгин с MySQL, ще трябва да получите приставката от сървърен пакет на Percona). Ако искате да използвате приставката MariaDB с други разклонения на MySQL, тогава можете да го намерите от https://downloads.mariadb.com/Audit-Plugin/MariaDB-Audit-Plugin/. Приставката McAfee е достъпна на https://github.com/mcafee/mysql-audit/wiki/Installation.

Преди да започнете инсталацията на приставката, можете да проверите дали приставката присъства в системата. Местоположението на динамичния плъгин (не изисква рестартиране на екземпляра) може да се провери с:

SHOW GLOBAL VARIABLES LIKE 'plugin_dir';

+---------------+--------------------------+
| Variable_name | Value                    |
+---------------+--------------------------+
| plugin_dir    | /usr/lib64/mysql/plugin/ |
+---------------+--------------------------+

Проверете директорията, върната на ниво файлова система, за да се уверите, че имате копие на библиотеката на плъгините. Ако нямате server_audit.so или server_audit.dll вътре в /usr/lib64/mysql/plugin/, тогава е по-вероятно вашата версия на MariaDB да не се поддържа и трябва да я надстроите до най-новата версия..

Синтаксисът за инсталиране на приставката MariaDB е:

INSTALL SONAME 'server_audit';

За да проверите инсталираните плъгини, трябва да изпълните:

SHOW PLUGINS;
MariaDB [(none)]> show plugins;
+-------------------------------+----------+--------------------+--------------------+---------+
| Name                          | Status   | Type               | Library            | License |
+-------------------------------+----------+--------------------+--------------------+---------+
| binlog                        | ACTIVE   | STORAGE ENGINE     | NULL               | GPL     |
| mysql_native_password         | ACTIVE   | AUTHENTICATION     | NULL               | GPL     |
| mysql_old_password            | ACTIVE   | AUTHENTICATION     | NULL               | GPL     |
| wsrep                         | ACTIVE   | STORAGE ENGINE     | NULL               | GPL     |
| MRG_MyISAM                    | ACTIVE   | STORAGE ENGINE     | NULL               | GPL     |
| MEMORY                        | ACTIVE   | STORAGE ENGINE     | NULL               | GPL     |
| CSV                           | ACTIVE   | STORAGE ENGINE     | NULL               | GPL     |
| MyISAM                        | ACTIVE   | STORAGE ENGINE     | NULL               | GPL     |
| CLIENT_STATISTICS             | ACTIVE   | INFORMATION SCHEMA | NULL               | GPL     |
| INDEX_STATISTICS              | ACTIVE   | INFORMATION SCHEMA | NULL               | GPL     |
| TABLE_STATISTICS              | ACTIVE   | INFORMATION SCHEMA | NULL               | GPL     |
| USER_STATISTICS               | ACTIVE   | INFORMATION SCHEMA | NULL               | GPL     |
| PERFORMANCE_SCHEMA            | ACTIVE   | STORAGE ENGINE     | NULL               | GPL     |
| InnoDB                        | ACTIVE   | STORAGE ENGINE     | NULL               | GPL     |
| INNODB_TRX                    | ACTIVE   | INFORMATION SCHEMA | NULL               | GPL     |
| INNODB_LOCKS                  | ACTIVE   | INFORMATION SCHEMA | NULL               | GPL     |
| INNODB_LOCK_WAITS             | ACTIVE   | INFORMATION SCHEMA | NULL               | GPL     |
| INNODB_CMP                    | ACTIVE   | INFORMATION SCHEMA | NULL               | GPL     |
...
| INNODB_MUTEXES                | ACTIVE   | INFORMATION SCHEMA | NULL               | GPL     |
| INNODB_SYS_SEMAPHORE_WAITS    | ACTIVE   | INFORMATION SCHEMA | NULL               | GPL     |
| INNODB_TABLESPACES_ENCRYPTION | ACTIVE   | INFORMATION SCHEMA | NULL               | BSD     |
| INNODB_TABLESPACES_SCRUBBING  | ACTIVE   | INFORMATION SCHEMA | NULL               | BSD     |
| Aria                          | ACTIVE   | STORAGE ENGINE     | NULL               | GPL     |
| SEQUENCE                      | ACTIVE   | STORAGE ENGINE     | NULL               | GPL     |
| user_variables                | ACTIVE   | INFORMATION SCHEMA | NULL               | GPL     |
| FEEDBACK                      | DISABLED | INFORMATION SCHEMA | NULL               | GPL     |
| partition                     | ACTIVE   | STORAGE ENGINE     | NULL               | GPL     |
| rpl_semi_sync_master          | ACTIVE   | REPLICATION        | semisync_master.so | GPL     |
| rpl_semi_sync_slave           | ACTIVE   | REPLICATION        | semisync_slave.so  | GPL     |
| SERVER_AUDIT                  | ACTIVE   | AUDIT              | server_audit.so    | GPL     |
+-------------------------------+----------+--------------------+--------------------+---------+

Ако имате нужда от допълнителна информация, проверете таблицата PLUGINS в базата данни information_schema, която съдържа по-подробна информация.

Друг начин да инсталирате приставката е да активирате приставката в my.cnf и да рестартирате инстанцията. Пример за основна конфигурация на плъгин за одит от MariaDB може да бъде:

server_audit_events=CONNECT
server_audit_file_path=/var/log/mysql/audit.log
server_audit_file_rotate_size=1073741824
server_audit_file_rotations=8
server_audit_logging=ON
server_audit_incl_users=
server_audit_excl_users=
server_audit_output_type=FILE
server_audit_query_log_limit=1024

Горната настройка трябва да бъде поставена в my.cnf. Плъгинът за одит ще създаде файл /var/log/mysql/audit.log, който ще се върти на размер 1GB и ще има осем ротации, докато файлът не бъде презаписан. Файлът ще съдържа само информация за връзките.

В момента има шестнадесет настройки, които можете да използвате, за да коригирате приставката за одит на MariaDB.

server_audit_events
server_audit_excl_users
server_audit_file_path
server_audit_file_rotate_now
server_audit_file_rotate_size
server_audit_file_rotations
server_audit_incl_users
server_audit_loc_info
server_audit_logging
server_audit_mode
server_audit_output_type
Server_audit_query_log_limit
server_audit_syslog_facility
server_audit_syslog_ident
server_audit_syslog_info
server_audit_syslog_priority

Сред тях можете да намерите опции за включване или изключване на потребители, задаване на различни събития за регистриране (CONNECT или QUERY) и превключване между файл и syslog.

За да сте сигурни, че приставката ще бъде активирана при стартиране на сървъра, трябва да зададете
plugin_load=server_audit=server_audit.so в настройките на my.cnf. Такава конфигурация може да бъде допълнително защитена от server_audit=FORCE_PLUS_PERMANENT, което ще деактивира опцията за деинсталиране на приставката.

UNINSTALL PLUGIN server_audit;

ERROR 1702 (HY000):
Plugin 'server_audit' is force_plus_permanent and can not be unloaded

Ето някои примерни записи, създадени от приставката за одит на MariaDB:

20180817 20:00:01,slave,cmon,cmon,31,0,DISCONNECT,information_schema,,0
20180817 20:47:01,slave,cmon,cmon,17,0,DISCONNECT,information_schema,,0
20180817 20:47:02,slave,cmon,cmon,19,0,DISCONNECT,information_schema,,0
20180817 20:47:02,slave,cmon,cmon,18,0,DISCONNECT,information_schema,,0
20180819 17:19:19,slave,cmon,cmon,12,0,CONNECT,information_schema,,0
20180819 17:19:19,slave,root,localhost,13,0,FAILED_CONNECT,,,1045
20180819 17:19:19,slave,root,localhost,13,0,DISCONNECT,,,0
20180819 17:19:20,slave,cmon,cmon,14,0,CONNECT,mysql,,0
20180819 17:19:20,slave,cmon,cmon,14,0,DISCONNECT,mysql,,0
20180819 17:19:21,slave,cmon,cmon,15,0,CONNECT,information_schema,,0
20180819 17:19:21,slave,cmon,cmon,16,0,CONNECT,information_schema,,0
20180819 19:00:01,slave,cmon,cmon,17,0,CONNECT,information_schema,,0
20180819 19:00:01,slave,cmon,cmon,17,0,DISCONNECT,information_schema,,0

Отчет за промените в схемата

Ако трябва да проследявате само промени в DDL, можете да използвате оперативния отчет на ClusterControl за промяна на схемата. Отчетът за откриване на промени в схемата показва всички промени в DDL във вашата база данни. Тази функционалност изисква допълнителен параметър в конфигурационния файл на ClusterControl. Ако това не е зададено, ще видите следната информация:schema_change_detection_address не е зададен в /etc/cmon.d/cmon_1.cnf. След като това е на място, примерен изход може да бъде като по-долу:

Може да се настрои с график и отчетите да се изпращат по имейл до получателите.

ClusterControl:График за оперативен отчет

Оценка на сигурността на базата данни на MySQL

Проверка за надграждане на пакета

Първо, ще започнем с проверките за сигурност. Актуализирането с MySQL пачове ще помогне за намаляване на рисковете, свързани с известни уязвимости, присъстващи в MySQL сървъра. Можете да поддържате средата си актуална, като използвате хранилището за пакети на доставчиците. Въз основа на тази информация можете да създавате свои собствени отчети или да използвате инструменти като ClusterControl, за да потвърдите вашата среда и да ви предупредят за възможни актуализации.

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

ClusterControl:Отчет за надграждане ClusterControl:Подробности за доклада за надграждане

За да ги сравните ръчно, можете да стартирате

SHOW VARIABLES WHERE variable_name LIKE "version";

С бюлетини за сигурност като:
https://www.oracle.com/technetwork/topics/security/alerts-086861.html
https://nvd.nist.gov/view/vuln/search- резултати?adv_search=true&cves=on&cpe_vendor=cpe%3a%2f%3aoracle&cpe_produ
https://www.percona.com/doc/percona-server/LATEST/release-notes/release-notes_index.html
https://downloads.mariadb.org/mariadb/+releases/
https://www.cvedetails.com/vulnerability-list/vendor_id-12010/Mariadb.html
https://www. cvedetails.com/vulnerability-list/vendor_id-13000/Percona.html

Или хранилища на доставчици:

На Debian

sudo apt list mysql-server

На RHEL/Centos

yum list | grep -i mariadb-server

Акаунти без парола

Празните пароли позволяват на потребителя да влезе без да използва парола. MySQL се предлагаше с набор от предварително създадени потребители, някои от които могат да се свързват с базата данни без парола или, още по-лошо, анонимни потребители. За щастие това се промени в MySQL 5.7. И накрая, той идва само с root акаунт, който използва паролата, която сте избрали по време на инсталацията.

За всеки ред, върнат от одитната процедура, задайте парола:

SELECT User,host
FROM mysql.user
WHERE authentication_string='';

Освен това можете да инсталирате плъгин за валидиране на парола и да приложите по-сигурна политика:

INSTALL PLUGIN validate_password SONAME 'validate_password.so';

SHOW VARIABLES LIKE 'default_password_lifetime';
SHOW VARIABLES LIKE 'validate_password%';

Добро начало може да бъде:

plugin-load=validate_password.so
validate-password=FORCE_PLUS_PERMANENT
validate_password_length=14
validate_password_mixed_case_count=1
validate_password_number_count=1
validate_password_special_char_count=1
validate_password_policy=MEDIUM

Разбира се, тези настройки ще зависят от нуждите на вашия бизнес.

Наблюдение на отдалечен достъп

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

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

Изпълнете следния SQL оператор, за да оцените тази препоръка (уверете се, че не са върнати редове):

SELECT user, host FROM mysql.user WHERE host = '%';

Тестова база данни

MySQL инсталацията по подразбиране идва с неизползвана база данни, наречена test и тестовата база данни е достъпна за всеки потребител, особено за анонимните потребители. Такива потребители могат да създават таблици и да пишат в тях. Това потенциално може да се превърне в проблем само по себе си - и записите биха добавили някои допълнителни разходи и биха намалили производителността на базата данни. Препоръчително е тестовата база данни да бъде премахната. За да определите дали тестовата база данни е налице, изпълнете:

SHOW DATABASES LIKE 'test';

Ако забележите, че тестовата база данни е налице, това може да е скриптът mysql_secure_installation, който премахва тестовата база данни (както и други дейности, свързани със сигурността), не е изпълнен.

ЗАРЕЖДАНЕ НА ИНФАЙЛ С ДАННИ

Ако и сървърът, и клиентът имат възможност да изпълняват LOAD DATA LOCAL INFILE, клиентът ще може да зарежда данни от локален файл на отдалечен MySQL сървър. Параметърът local_infile диктува дали файловете, намиращи се на компютъра на MySQL клиента, могат да бъдат заредени или избрани чрез LOAD DATA INFILE или SELECT local_file.

Това потенциално може да помогне за четене на файлове, до които клиентът има достъп - например на сървър на приложения може да има достъп до всички данни, до които HTTP сървърът има достъп. За да го избегнете, трябва да зададете local-infile=0 в my.cnf.

Изпълнете следния SQL оператор и се уверете, че полето Value е зададено на OFF:

SHOW VARIABLES WHERE Variable_name = 'local_infile';

Монитор за некриптирани пространства за таблици

Започвайки от MySQL 5.7.11, InnoDB поддържа криптиране на данни за таблици, съхранявани в пространства за таблици файл на таблица. Тази функция осигурява криптиране в състояние на покой за файлове с данни за физическо пространство за таблици. За да проверите дали вашите таблици са криптирани, изпълнете:

mysql> SELECT TABLE_SCHEMA, TABLE_NAME, CREATE_OPTIONS FROM INFORMATION_SCHEMA.TABLES
       WHERE CREATE_OPTIONS LIKE '%ENCRYPTION="Y"%';

+--------------+------------+----------------+
| TABLE_SCHEMA | TABLE_NAME | CREATE_OPTIONS |
+--------------+------------+----------------+
| test         | t1         | ENCRYPTION="Y" |
+--------------+------------+----------------+

Като част от криптирането трябва да помислите и за криптиране на двоичния дневник. MySQL сървърът записва много информация в двоични регистрационни файлове.

Проверка на връзката за криптиране

В някои настройки базата данни не трябва да бъде достъпна през мрежата, ако всяка връзка се управлява локално, чрез Unix сокета. В такива случаи можете да добавите променливата „skip-networking“ в my.cnf. Пропускането на мрежата не позволява на MySQL да използва каквато и да е TCP/IP връзка и само Unix сокет би бил възможен в Linux.

Това обаче е доста рядка ситуация, тъй като е обичайно за достъп до MySQL през мрежата. След това трябва да следите дали връзките ви са криптирани. MySQL поддържа SSL като средство за криптиране на трафик както между MySQL сървъри (репликация), така и между MySQL сървъри и клиенти. Ако използвате клъстер Galera, подобни функции са налични - както вътрешноклъстерната комуникация, така и връзките с клиенти могат да бъдат криптирани чрез SSL. За да проверите дали използвате SSL криптиране, изпълнете следните заявки:

SHOW variables WHERE variable_name = 'have_ssl'; 
select ssl_verify_server_cert from mysql.slave_master_info;

Това е засега. Това не е пълен списък, уведомете ни, ако има други проверки, които правите днес на вашите производствени бази данни.


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Как да извадите минути от стойност на дата и час в MariaDB

  2. HA за MySQL и MariaDB - Сравняване на главен-главен репликация с клъстер Galera

  3. Част 1:Класификация на изображения с MariaDB сървър и TensorFlow – общ преглед

  4. Как да инсталирате MariaDB 10 на Debian и Ubuntu

  5. MariaDB GROUP_CONCAT()